[POOLS] Add common filters

Context:
THORChain is designed for the economically significant assets on the economically significant chains ie. the short tail. We can therefore estimate the number of assets based on current altcoin mcap to be roughly 500-1000.
This presents a challenge for the pool list, and will require several filters (not sorting) to help users find what they need.
Feature Request
Add a filter component where several common filters can be added to rapidly filter out pools & aid discovery of relevant pools.
Examples:
chain - Filtering by eth for example will rapidly narrow the results so that I can search for relevent ERC20 tokens.
asset - Filter by asset name eg. btc will yield renbtc, wbtc, tbtc, btc etc; eth = eth, weth etc.
depth - Relevant for searching for economically significant assets/deep pools.
favorite - Related to https://github.com/thorchain/asgardex-electron/issues/1075

chain - Filtering by eth for example will rapidly narrow the results so that I can search for relevent ERC20 tokens.
asset - Filter by asset name eg. btc will yield renbtc, wbtc, tbtc, btc etc; eth = eth, weth etc.

^ DONE by #2275

depth - Relevant for searching for economically significant assets/deep pools.

^ Not sure how such search will look like - feel free to re-open this issue with more details

favorite - Related to #1075

^ Will be another PR


sql/postgres: make index storage check continue

Fixes #1472 I have no idea if this causes issues downstream, but it seems to fix the immediate issue I have with Atlas. Looking at the logic itself, I don't see a good reason to fail the param parsing though; non-kvp-pairs in storage params doesn't indicate a bad state, as evidenced by our use case. They just aren't the specific params that are trying to be parsed.

🫤


Widget Replacement button too high on z-axis

Description
The widget replacement for Facebook has a button that appears to be hoisted into the heavens on the z-axis.
This may be a result of how Downdetector's header is styled, but if the button was just laid on top of the widget, I wouldn't think this would happen.
Steps to Reproduce

Navigate to https://downdetector.com
Scroll down until the position of the "Unblock" button of replacement widget is in the same space as the top nav

Expected behavior:
Button tucks under the heading
Actual behavior:

Versions

Extension: 2022.3.30
Browser: Firefox 99
OS: Windows 10 Home

Hey! @jonathanKingston
I would love to contribute to DuckDuckGo privacy extension.
Can I take up this issue for starters?
Thanks!

Hey @mighty-phoenix thanks for the PR. I think this might be the correct fix as the injected DOM elements sits inside with the original page and so most of the time should inherit the z-index from it's parent element.
There are 2 other cases in this code that also inject high z-index values and I suspect they should get the same fix; whatever that is.
I think when @Charlie-belmer first made this code there were some cases where we were sitting behind the pages elements and perhaps he can remember as test cases. If that is the case I think we may want to use JS to actually inspect the page z-index and use the correct values based on the surrounding nodes; this however might be equally fraught with the same issues.

    <button>Facebook button</button>

Picking the correct value for the above element is difficult as using the same z-index will be incorrect on some sites but also +1 is also incorrect in the case above.
I'm inclined to suggest this is the correct fix but will defer to @Charlie-belmer, @kzar or @ladamski but as mentioned I think the other z-index items should be removed too if it's deemed correct.

I definitely don't know how the DDG widget is getting displayed, but the "Unblock Content" button is a child of your widget, right? Why would you hoist the button? If a website is setting z-index and the button happens to occupy the same or a tad higher z-index, then that's not DDG's problem. That's just a poorly made website. The best you could do is as you suggest, setting the z-index of what you're injecting, to the same z-index of what you are replacing AND the widget would have to be completely flat. (no parents, all sisters, to guarantee that everything is displayed at that "layer". instead of injecting a parent element with children, inject a list of elements all at the z-index layer. this implementation is not pretty, but it would help ensure that at least DDG's widget would look pretty)
I'd have to really dig in to understand how the widget is getting injected to help propose a solution.
And I would also be interested in the test cases that drove the decision to hoist the button in the first place.

The button isn't always embedded within the section as shown on this site. You can see some other examples here: https://privacy-test-pages.glitch.me/privacy-protections/click-to-load/ I think the single button case is what we saw breakage with rather than the whole panel element; we could choose to remove the z-index when embedded within the panel as we're not applying a z-index to the panel and the panel will already broken in these edge cases.

That's just a poorly made website. The best you could do is as you suggest, setting the z-index of what you're injecting, to the same z-index of what you are replacing.

If I understand correctly there are sites that are setting the z-index on the DOM nodes created by Facebook; which may not be able to understand we have modified the output. We are replacing the nodes before they are created so can't establish what the z-index might be.
I think we need some clear test cases that were breaking and were the rationale for the original decision to make a decision on the next steps here.
DuckDuckGoPrivacyEssentialsHoverableText we probably always want to be positioned above the rest of the DOM which probably would be better served by  showModal().

I went back through the original test cases (real, popular global sites) - unfortunately many of those have changed or removed FB content, so I couldn't find the original sites causing this issue.
If I recall, the root of the problem was sites with global button styles that would set z-index below the facebook parent element, effectively hiding the button and making it impossible to click. At the time, I chose to ensure clickability over cosmetics, but it's entirely possible the current z-index causes more problems than it solves. Either way, I think we risk some breakage.
I think it's up to @kzar  and @ladamski  to make the call since they own this feature now.

Is making it impossible to unblock a tracker a bad thing? (ha) I originally thought this would be one of those simple requests that would be a good first issue. (Thank you @mighty-phoenix for finding this and dedicating time to investigate, as well as @jonathanKingston and @Charlie-belmer for spending valuable time researching the origins of this.)
"global button styles that would set z-index below the facebook parent element"....acknowledged, and I can appreciate function over fashion. Would setting "z-index: revert" undo that global style if it existed? (I've honestly never used "revert" before, but if I understand correctly, this sounds really useful for this use case, if not other "click to play" features?)

I'm not sure what z-index: revert does, I've never used it myself and am not familiar with it. On the other hand, there may be other creative ways to solve this using stacking contexts. It would be helpful to first create at test case with some global styles that replicate the original & current issues (maybe in https://github.com/duckduckgo/privacy-test-pages/tree/main/privacy-protections/click-to-load)?
Then we could be more confident that whatever fix we implement solves both issues.


dev-libs/collada-dom and media-libs/collada-dom in gentoo

Greetings,
I tried to install ROS kinect on gentoo but decided to deviate from the official install guide [1][2] occasionally. Most notably I decided against using ros-overlay since all relevant packages seem to be present in portage.
After running
rosinstall_generator desktop --rosdistro kinetic ...
the next command fails as follows (other packages were installed too but are not displayed here)
$ rosdep install --from-paths src --ignore-src --rosdistro kinetic
executing command [sudo -H emerge -a media-libs/collada-dom]
Password:
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds to satisfy "media-libs/collada-dom".
emerge: searching for similar names...
emerge: Maybe you meant any of these: dev-libs/collada-dom, media-libs/opencollada, media-libs/ladspa-sdk?
ERROR: the following rosdeps failed to install
portage: command [sudo -H emerge -a media-libs/collada-dom] failed
After some investigation I found out that media-libs/collada-dom is contained in ros-overlay (seems it was created at a point of time where no such packages existed in portage) so I wonder if dev-libs/collada-dom could be added to base.yaml now that portages provides it and allow an overlay-free install alltogether (unless there is more to the overlay's existence apart from historical reasons).
Kind regards
Additional information:
William Woodall added the code in question [3] by merging it to base.yaml from gentoo.yaml [4]
[1] http://wiki.ros.org/kinetic/Installation/Gentoo
[2]

setting python's default version to 2.7 is not recommended and should be covered by gentoo's python-wrapper
it uses layman which is practically deprecated by the extended functionality of portage (via repos.conf)
it recommends to run pip install as root which will mess with portage

[3] https://github.com/ros/rosdistro/blame/master/rosdep/base.yaml
[4] https://github.com/ros/rosdistro/blame/52a9adacd4cdc62de793ac1c0f58fa98315b3cc9/rosdep/gentoo.yaml

@allenh1 thoughts

You make a lot of good points here. The main purpose of the overlay, as I see it, is to keep the builds being stable with one another. Gentoo portage trees have a tendency to fall behind in version numbers, or jump way too far ahead in version numbers. This overlay ensures that ROS users can use compatible builds for ROS installations. Though, yes, conflicts are rare, they certainly happen.

setting python's default version to 2.7 is not recommended and should be covered by gentoo's python-wrapper

This is true, but ROS is still not fully working with Python 3 (at least as far as I know). So the guide says 2.7 to ensure compatibility with existing ROS packages.

it uses layman which is practically deprecated by the extended functionality of portage (via repos.conf)

This should definitely be changed in the install guide. Please feel free to update it accordingly.

it recommends to run pip install as root which will mess with portage

This is also a good point, and is not even a necessary step in the install (I forgot to remove it, and will do so now).

Thanks @allenh1 for your effort.
I'll get to updating the wiki this week or next.
My initial issue for this report still stands though:
collada-dom is in dev-libs (portage) and media-libs (overlay). Having collada-dom in two places when the overlay is used seems suboptimal to me. Possible fixes:

move collada-dom to dev-libs/collada-dom in the overlay and update base.yaml (probably best solution)
move collada-dom to media-libs/collada-dom in portage (not likely)
update base.yaml to allow dev-libs/collada-dom as well as media-libs/collada-dom (cheap and dirty)

If there is a good reason to have collada-dom in different places in portage and overlay please state them here for future reference and close this issue.

I had contact with Alexis Ballier, who is a gentoo dev and worked on ROS for gentoo [1].

He suggested to take it one step further and go with 'ros-meta/desktop' or 'ros-meta/desktop_full' (part of gentoos package management system portages)
He agrees that base.yaml should be fixed and "media-libs/collada-dom removed from ros-overlay, unless ros-overlay's version adds some missing features to gentoo's portage tree version."

As a consequence I created a pull request [2] which will allow portage to provide collada-dom in order to move away from the overlay.
[1] https://github.com/aballier https://wiki.gentoo.org/wiki/User:Aballier
[2] https://github.com/ros/rosdistro/pull/11724

INTERMEDIATE WORKAROUND:
Add my base.yaml to your ROS-sources. That will replace the dependency on media-libs/collada-dom with a dependency on dev-libs/collada-dom

# touch /etc/ros/rosdep/sources.list.d/10-fix-collada-dom.list [1]
# echo "yaml https://raw.githubusercontent.com/benkinooby/rosdistro/ros_from_portage_instead_of_overlay/rosdep/base.yaml" >> /etc/ros/rosdep/sources.list.d/10-fix-collada-dom.list
$ ros update

[1] Please note that the filename is chosen in a way that ensures precedence of my file.

A small improvement to @benkinooby's workaround (https://github.com/ros/rosdistro/issues/11687#issuecomment-223975311): You are able to use "file://" links in the sources.list.d/*.list files.
So I used the following:

echo "yaml file:///etc/ros/rosdep_hacks/collada-dom_fix.yaml" > /etc/ros/rosdep/sources.list.d/10-collada-dom_fix.list
Content of "/etc/ros/rosdep_hacks/collada-dom_fix.yaml":

collada-dom:
  gentoo:
    portage:
      packages: [dev-libs/collada-dom]

The reasoning mentioning this, is the fact that the current base.yaml has also a very similar problem regarding pkg-config: It uses "dev-util/pkgconf", while I have "dev-util/pkgconfig" installed (notice the additional two letters "…ig"). So I had to write another fix for that. The situation was that I would have to explicitly disable pkconf's "pkg-config" use flag to merge this package, which seems to do the same job as "pkgconfig". Imho "virtual/pkgconfig" seems to be the better dependency. @allenh1, you changed the previous "dev-util/pkgconfig" to "dev-util/pkgconf" in https://github.com/ros/rosdistro/commit/d29bd69cd75a33ee325637398712e870afa88b74. Do you mind changing it to the virtual package? (Sorry for hijacking this issue a bit.)

@SvenWe That is a sensible change.

@benkinooby @SvenWe nice workaround
@tfoote this issue is obsolete since https://github.com/ros/rosdistro/pull/15101

Great. Thanks for noticing. I'll close this out.


Starter Packs

Wizard

[x] Details
[x] Profiles

[x] Search
[x] List of those that have been added
[ ] Use typeahead query over follows

[x] Feeds
[x] Edit existing starter packs

Logged In

[x] Starter pack list on profiles
[x] QR code generation for sharing starter packs

[x] Tweak style of this thing
[x] Dark mode

[x] Starter pack screen showing name, description, profiles, and feeds
[x] Sharing by a short link
[x] Newskie badge on profiles

[x] Dialog that shows the starter pack used if applicable

Logged Out

[x] Landing

[ ] iOS (App Clip)
[x] Android (Android Referrer API)
[x] Web (Basic)

[x] Follow suggested profiles on account creation
[x] Pin suggested feeds
[x] Set created at date
[x] Land on the first-most feed if there were feeds in the pack
[x] Land on the following feed if there were only profiles and there were 25 or more profiles in the pack

Stats

[x] Created an account w/ a starter pack

[x] Which one?

[x] Followed accounts or pinned feeds from the starter pack page

What the fucks

[ ] Make sure nothing weird happens if the starter pack still exists but the list is deleted
[ ] Make sure we only fetch 50 profiles even if the list has some other number (and restrict the follows to that limit)

Lets start reviews here now. Going to continue iterating in separate PRs.
Note you need to do a yarn because this relies on an RC atproto package


Getting started page should be on top

@wiese My part is done now. :) Thanks for updating the folders and reviewing.

@raja-wmde Makes sense to me. I did the rename (hopefully) as discussed. Mind checking that I got it right?

Rebased and removed the one merge commit


Feature Request - Add Player Names Property

Hi,
just wanna ask if you can add a Property like minecraft_player_online_names or something?
Or even better tracking individual online Player times as a property
thanks love your Mod <3

Hi!
Thank you for the suggestion! That's an interesting idea.
The first idea I have is to track Login Start packets to retrieve names of players connecting to the server, but it would not provide a list of online players. Handling the list of online players will be harder to implement. I think it will make sense to add an individual counter of online time for each player ever joined the server.
As soon as I have some free time, I will try to do so

I suggest you take the next step right away and export all player statistics as metrics:

Life, armor, hunger, experience
Game Mode
Imposed statuses (poisoning, weakness, etc.)
All statistics available on the player statistics page


ModuleNotFoundError("No module named 'src.models.components.uedm'")  Where can I find the uedm file, please?

Traceback (most recent call last):
File "/home/bishr/.local/lib/python3.10/site-packages/hydra/_internal/utils.py", line 650, in _locate
obj = import_module(mod)
File "/usr/lib/python3.10/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'src.models.components.uedm'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/bishr/.local/lib/python3.10/site-packages/hydra/_internal/instantiate/_instantiate2.py", line 134, in _resolve_target
target = _locate(target)
File "/home/bishr/.local/lib/python3.10/site-packages/hydra/_internal/utils.py", line 653, in _locate
raise ImportError(
ImportError: Error loading 'src.models.components.uedm.UEDM':
ModuleNotFoundError("No module named 'src.models.components.uedm'")
Are you sure that 'uedm' is importable from module 'src.models.components'?
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/bishr/Pansharpening/src/utils/utils.py", line 68, in wrap
metric_dict, object_dict = task_func(cfg=cfg)
File "/home/bishr/Pansharpening/src/train.py", line 63, in train
model: LightningModule = hydra.utils.instantiate(cfg.model)
File "/home/bishr/.local/lib/python3.10/site-packages/hydra/_internal/instantiate/_instantiate2.py", line 226, in instantiate
return instantiate_node(
File "/home/bishr/.local/lib/python3.10/site-packages/hydra/_internal/instantiate/_instantiate2.py", line 342, in instantiate_node
value = instantiate_node(
File "/home/bishr/.local/lib/python3.10/site-packages/hydra/_internal/instantiate/_instantiate2.py", line 333, in instantiate_node
target = _resolve_target(node.get(_Keys.TARGET), full_key)
File "/home/bishr/.local/lib/python3.10/site-packages/hydra/_internal/instantiate/_instantiate2.py", line 139, in _resolve_target
raise InstantiationException(msg) from e
hydra.errors.InstantiationException: Error locating target 'src.models.components.uedm.UEDM', set env var HYDRA_FULL_ERROR=1 to see chained exception.

This bug was caused by the name change of our model (UEDM → CMFNet), which has been fixed. You can try cloning the code again.


Fix refill

Open date and prescription modal before save on refill

 Not working drug refill action

Coverage increased (+0.03%) to 70.767% when pulling b5de156b214f9529c445eaf179639ff8ac2cccc5 on ynurmahomed:refill into 3087af7191326391c1c0cbd029fdbe384c51f2de on esaude:master.

@Guimino PR updated


Parameters not described well enough

For the input, where does the caller get the hub name? There should be a link to where this comes from or an example on how to create it.
Is the output string ANSI or UNICODE?

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

ID: b568710f-d50e-2b6a-7e7f-b0dd5815195c
Version Independent ID: 2e90d9e8-1cf1-e7df-4f7b-7a59d0eeca3b
Content: IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME
Content Source: wdk-ddi-src/content/usbioctl/ni-usbioctl-ioctl_internal_usb_get_controller_name.md
Product: windows-hardware
GitHub Login: @windows-driver-content
Microsoft Alias: windowsdriverdev

Hi @BrianCatlin,
I’ve created an internal work item for myself to investigate this with the USB team, and I’ll make a note here when I complete the changes. In the meantime, I’m closing the GitHub issue while it’s tracked in the bug. Thanks again for helping to improve the docs.


Number of transfers incorrect

Describe the bug
The number of transfers is incorrect. There is only 1 transfer and 1 successful deployment and 1 failed deployment.
The explorer shows 3 transfers and two deployments

Account:
https://explorer.stacks.co/address/SP497E7RX3233ATBS2AB9G4WTHB63X5PBSP5VGAQ?chain=mainnet
Expected behavior
1 transfer, 1 contract

I'm closing this since it's quite old, but please reopen if it's still actively relevant / you see it as a general pattern.


Can't activate the integration.

Hi Kevin, thank you for the great work you did! I'm almost there and love to see it work. I just can't find how to start the integration. I have tried to add the Ecostream's IP address in the name field and also its name and serial number but that did not do the trick.
Can you tell me in what format I have to enter the information in the integrations-item field?

Add the file enable_buva.py in de folder: /homeassistant/pyscript
This is mine:
enable_buva.py.txt
Make sure you got python working, it should autorun all .py scripts in de pyscript folder on boot.
I also placed this in configuration.yaml for the dashboard functions:
input_number:
buva_timeout:
name: "Duur in minuten"
initial: 15
min: 15
max: 60
step: 15
unit_of_measurement: "minuten"
input_select:
buva_setting:
name: "Ventilatiestand"
options:
- "0"  # Auto
- "1"  # 60 m²/u
- "2"  # 110 m²/u
- "3"  # 175 m²/u
initial: "1"


Error when running styled-components template

When performing clean install with styled-components,  via yarn create r3f-app next test5 styled
Installation goes fine (though regardless of whether -ts is provided or not, the following occurs:
> Success! Installed dependencies for styled-components

> Initializing for styled-components...

> Downgraded to<EMAIL_ADDRESS>in order to fix styled-components (see DefinitelyTyped/issues/59765)

On yarn run dev  receive error:
wait  - compiling /_error (client and server)...
error - ./src/components/dom/Layout.jsx:2:0
Module not found: Empty dependency (no request)
  1 | 'use client'
> 2 | import {} from ''
  3 |
  4 | import { useRef } from 'react'
  5 | import dynamic from 'next/dynamic'

Looking at the file, besides the aforementioned import {} from '', there is no difference between this file and the tailwind generated (default) version [which does work].
Deleting the failed import results in the project building, but not correctly and no assets loading and no styling being applied.
Following the solution provided at #125 only works if styled is omitted.
Node version v16.19.1, macOS 13.3.1

experiencing the same issue.

Thanks for the report, latest version of create-r3f-app should fix this issue.


GlobalMarineNet.xocml version 1.31a

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

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

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

/AzurePipelines run

Automatic Validation ended with:

Use the switch.

Use the switch.

Could you be more specific about which switch should be used here?

Use the switch.

Could you be more specific about which switch should be used here?

/NCRC

Automatic Validation ended with:

Screenshot?

It's unchanged.
https://user-images.githubusercontent.com/114952565/240073035-e80fc952-0f3f-4b66-9481-317c90eca4f8.png
(saving bandwidth)

[Policy] Interactive-Only-Installer

[Policy] Blocking-Issue


action to obtain secret-key

There should be an action to obtain a secret key that has been randomly generated and is set here as the default.

"MINIO_ACCESS_KEY": self.config["access-key"],
adding this line to charm.py will allow to get acces and secret key fom config file

Yes, I know.  I have no problem getting the secret key from relation with Minio. Howerver I need to have access to the secret key in the CLI as well.

BTW is there any way to create tenant in minio operator by not using GUI but on backend using CLI

I'm not aware that this could be done right now. Maybe it could be done with this plugin, but I'm not an expert here.


Implementing check for pyproject file

Codecov Report

Merging #124 (a44ccee) into main (7247e3a) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Current head a44ccee differs from pull request most recent head ae6dbbd. Consider uploading reports for the commit ae6dbbd to get more accurate results

@@            Coverage Diff             @@
##             main     #124      +/-   ##
==========================================
- Coverage   94.10%   94.09%   -0.01%
==========================================
  Files           4        4
  Lines        2306     2303       -3
==========================================
- Hits         2170     2167       -3
  Misses        136      136

Flag
Coverage Δ

unittests
94.09% <100.00%> (-0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

qoqo_calculator/src/calculator_float.rs
87.28% <100.00%> (-0.04%)
:arrow_down:

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 f066dce...ae6dbbd. Read the comment docs.


No way to specify TLS disabled for Kafka scaler

Report
When using the Apache Kafka scaler, you can set the auth parameter tls to enabled for the underlying kafka client to use tls when connecting to the brokers. There is no way however to set tls to anything else to configure tls to be disabled. See here. Now I know that the default behavior is that tls is off but the current behavior is counter-intuitive.
Expected Behavior
tls: disabled is not invalid and means the same as not specifying the parameter
Actual Behavior
The scaler throws an error
Steps to Reproduce the Problem

Create a trigger authentication resource that exposes the tls parameter as "disabled"
Create a kafka scaler that references the trigger auth
The scaler can't be created because the tls value is invalid

Logs from KEDA operator
No response
KEDA Version
2.6.0
Kubernetes Version
1.20
Platform
Amazon Web Services
Scaler Details
Kafka
Anything else?
No response

Thank you for the PR!


[1.1] Server crash on startup

Issue description:
Server crashes on startup with Refined Storage v1.1 installed. I noticed this with other mods installed at first, and then tested it with the mod alone and the crash still occurred.
I am using the latest version of MCMultipart, Forge and Refined Storage.
What happens:
Server crashes during startup.
What you expected to happen:
Server to start.
Steps to reproduce:

Start server with Refined Storage and MCMultipart installed.

Version (Make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: <IP_ADDRESS>4
Refined Storage: 1.1

Does this issue occur on a server? [yes]
If a (crash)log is relevant for this issue, link it here:
http://pastebin.com/F2zKm5cZ

I'm Having the same issue.
Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/gui/GuiScreen
at refinedstorage.proxy.CommonProxy.preInit(CommonProxy.java:73)
at refinedstorage.RefinedStorage.preInit(RefinedStorage.java:55)

I"m getting the same issue as well, running a dedicated server. Issue does not occur in the client. I believe the mod is trying call on a class only present in the client, not the dedicated server.


Readme steps to generate site cause error

I installed the newest node and npm, as requested. npm install went smoothly. npm run build caused an error on the unfold site.json
Error: File to import not found or unreadable: ./node_modules/node-bourbon/node_modules/bourbon/app/assets/stylesheets/bourbon

This is caused because npm install will install node-bourbon and node-neat but does not do an npm install in those packages, causing the paths in src/css/main.scss to fail because the inner level of "node_modules" does not exist.
One solution is to add bourbon and bourbon-neat to the dependencies and then change the paths in main.scss. I should have a pull request ready soon.

@jcottrell Did you install Node 5.x? The 4.x "LTS" versions don't work because we need NPM 3, which is bundled in Node 5.

Yes, node -v gives me v5.10.1 and npm -v gives 3.8.6

Ah sorry, I was a little fuzzy about where I left this issue. I actually have a branch at https://github.com/louisvilleio/louisville.io/tree/fix-paths-npm-3 that fixes this issue, but I haven't merged it to master because it would break everyone on NPM 2, so I was waiting a while.

Ah, ok. Very good.

Sorry for the confusion.


Update icon definitions to new figma export format

Pull Request Description
Related to #8387
Updated icons file to match the export format of figma plugin.
Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

I tried to test it, but typecheck fails with error:
src/components/widgets/PlaceholderWidget.vue:7:6 - error TS2345: Argument of type '{ width: number; height: number; name: "underscore"; }' is not assignable to parameter of type '{ readonly name: Icon | URLString; style?: unknown; class?: unknown; key?: string | number | symbol; ref?: VNodeRef; ref_for?: boolean; ref_key?: string; onVnodeBeforeMount?: VNodeMountHook | VNodeMountHook[]; ... 6 more ...; readonly width?: number; } & Record<...>'.
  Type '{ width: number; height: number; name: "underscore"; }' is not assignable to type '{ readonly name: Icon | URLString; style?: unknown; class?: unknown; key?: string | number | symbol; ref?: VNodeRef; ref_for?: boolean; ref_key?: string; onVnodeBeforeMount?: VNodeMountHook | VNodeMountHook[]; ... 6 more ...; readonly width?: number; }'.
    Types of property 'name' are incompatible.
      Type '"underscore"' is not assignable to type 'Icon | URLString'.

7     <SvgIcon :width="24" :height="16" name="underscore" />
       ~~~~~~~

Code wise it's accepted, I just wanted to make sure no important icon disappeared (their visibility is not covered by e2e tests)

The marketplace icon issue might be using the mask tag in the SVG. It is not supported when importing SVGs with use, as we do: https://stackoverflow.com/questions/72027981/mask-tag-in-svg-is-ignored-if-used-from-an-external-svg-sprite-file

Fixed marketplace icon in PR, but not in figma.


fix(mobile-back-button): fix back button on mobile

see https://gitlab.skypicker.com/frontend/frontend/merge_requests/5753#note_746276

:tada: This PR is included in version 1.3.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

I think, that it is ok... Please, for future don't put description during skypicker. I haven't an access here. Thanks :)


Send function unrecoverable exception

Describe the bug
Send function unrecoverable exception for event
[1;31m05:31:48.440 [pool-2-thread-1151][9315]
FATAL-ALERT gov.cdc.prime.router.azure.SendFunction -
Success: sftp upload of CDCPRIME_11D2030855_20220404051543.hl7 to SFTPTransportType(host=sftp-edts.hhs.texas.gov, port=22, filePath=./, credentialName=null),
Send function unrecoverable exception for event.
Mo intervention required: report&SEND&c33d0c82-0c9b-43ae-bd2d-6f3283407b66&false[m

Impact
Unknown:

Mo intervention required: report&SEND&c33d0c82-0c9b-43ae-bd2d-6f3283407b66&false[m

To Reproduce

Attempt sftp upload of CDCPRIME_11D2030855_20220404051543.hl7

Expected behavior

PagerDuty failed SFTP alert

Logs

Logged alert

Resolution Note: Another false alarm.
Richard Hawes 11:19am


MAINT: stats: Some changes for gumbel_r.fit (and therefore gumbel_l.fit).

Reformulate some expressions in gumbel_r.fit to avoid overflow of
exponential terms.
Use root-finding for just a scalar equation instead of simultaneously
solving two equations.
Add a test for the fit method of gumbel_l and gumbel_r that has
a precomputed known solution that was computed using mpmath.

@swallan, the PR for the gumbel_r and gumbel_l fit methods looks good.
A while back you asked about the warnings that occur when the scale is small.  I did some experimenting, and I think a reformulation of the expressions that are summed in func can avoid some of those warnings.
In the ratio of the sums, a problem arises when a term in exp(-data/b) overflows.  This will happen when an element of data is negative and b is small enough.  We can avoid that issue by using the same technique that is used to avoid overflow in the logsumexp function in scipy.special.
The expression has the form
sum(x[i]*exp(c[i]))
-------------------
  sum(exp(c[i]))

where I'm writing pseudo-ascii-math, and I use x instead of data and c instead of -data/b.  That expression can be rewritten as
exp(M)*sum(x[i]*exp(c[i] - M))    sum(x[i]*exp(c[i] - M))
------------------------------ =  -----------------------
  exp(M)*sum(exp(c[i] - M))         sum(exp(c[i] - M))

where M = max(c).  Now all the terms in the exponents are less than or equal to 0, so we don't get overflow.  If we define p[i] = exp(c[i] - M), the expression is
sum(x[i]*p[i])
--------------
  sum(p[i])

That expression is the weighted average of x, with weights p. We can compute that with numpy.average.  Here's a function that does that, taking the arguments of the exponentials as a parameter:
def _average_with_log_weights(x, logweights):
    x = np.asarray(x)
    logweights = np.asarray(logweights)
    maxlogw = logweights.max()
    weights = np.exp(logweights - maxlogw)
    return np.average(x, weights=weights)

Next, note that the equation for the scale does not depend on the location.  So instead of simulaneously solving for (loc, scale), we can use optimize.root to solve the (scalar) first equation for the scale, and then plug the scale into the second equation to get the location.
Finally, note that the expression np.log(sum_exp_x_b / n) can be implemented in terms of logsumexp as logsumexp(-data/p) - np.log(b). So we won't need to explicitly compute sum_exp_x_b, and that avoids more potential overflow.
The changes here implement the above reformulations.
With this version, we can do, for example,
In [6]: z = np.array([3, 3, 3, 3, 3, 3, 3, 3.00000001])

In [7]: gumbel_r.fit(z)
Out[7]: (3.00000000016679, 1.249522263435665e-09)

or
In [14]: rng = np.random.default_rng(998877665544332211)

In [15]: z = rng.gumbel(loc=10, scale=1e-9, size=100)

In [16]: gumbel_r.fit(z)
Out[16]: (9.999999999901666, 9.83443065337164e-10)

and not get any warnings.
(Ping @mdhaber, @sethtroisi.)

Thanks for taking the time do to this - I took a look and it seems to work the exact same.


[desktop/tellurida] telluride does not shutdown when frostwire is shutdown

I just noticed that telluride does not exit when I shutdown frostwire.  Is that the intended behavior and if so can this be optional? not sure why I would want the daemon running when frostwire isn't

Thank you for letting me know this is happening, that is not the intentional behaviour.
FrostWire sends a shutdown command to the server on exit, perhaps something broke with one of the python library updates.
I'll check and let you know if I can replicate/fix

can't replicate on macOS (arm64), with FrostWire 6.9.9.
Will test on Windows.
(On what operating system are you on @jjgalvez)

can't replicate on macOS (arm64), with FrostWire 6.9.9.
Will test on Windows.
(On what operating system are you on @jjgalvez, please make sure you're running FrostWire 6.9.9)

sorry the OS is a valuable piece of information I should have included.
OS Arch Linux
Forstwire version 6.9.9
installed form the official targz file.
An interesting note is that when I ran telluride_linux -h I saw that I should hve been able to shut down the service with the shutdown command but trying
curl 'http://<IP_ADDRESS>:47999/?shutdown=1'
echos a shutdown message but does not shutdown the server.
happy to provide any additional info that might be helpful as well as test things agian if its helpful.

FYI running the server.py code locally I noticed that request.environ.get('werkzeug.server.shutdown') returned none, so I modified the code:
I imported os and signal and then edited your route_handler function
@app.route('/')
    def root_handler():
        '''
        http handler, rejects connections not coming from localhost|<IP_ADDRESS>
        url parameters:
        url=<url encoded video page url to obtain json metadata from>
        [shutdown=1] if passed it will shutdown the server
        '''
        gtfo = reject_remote_requests()
        if gtfo is not None:
            return gtfo

        query = request.args.to_dict()
        print(query)
        for k,v in request.environ.items():
            print(f'{k}:\t{v}')
        print(request.environ.keys())
        if 'shutdown' in query and (query['shutdown'] == '1' or query['shutdown'].lower() == 'true'):
            shutdown_function = request.environ.get('werkzeug.server.shutdown')
            if shutdown_function is not None:
                shutdown_function()
            else:
                try:
                    os.kill(os.getpid(), signal.SIGINT)
                except:
                    print("can't kill service")
            return jsonify({'message':'shutdown'})
        if 'url' in query:
            return query_video(query['url']), 200
        return jsonify({'build' : build_number, 'message': 'no valid parameters received'})

that killed the service on my rig, hope it helps. not sure if it works for windows and mac which is why I wrapped it in a try-except statement

Not sure if I want to add more imports (perhaps I've already imported those on other modules).
Can you please start a branch and send a PR so I can see exactly what you changed?
We should first understand why we're not getting the shutdown function in your environment and not patch around with a kill and what not, we'd like to shutdown gracefully and include as little as possible to minimize the size of the executable.

Finding stuff out there:

The 'environ['werkzeug.server.shutdown']' function is deprecated and will be removed in Werkzeug 2.1.

This was added in #36 as a way to shutdown local applications, environ["werkzeug.server.shutdown"]().
However, the advice for quite some time has been to use a production server even when running local applications;
the development server is  only for development.

The issue and code comments both describe the implementation as "horrible".

The implementation of it is in fact pretty  weird, having to touch a double underscore "really private" variable, as well as jump through hoops to work with the  HTTP server loop and handle reloader processes.

Additionally, users see this and then are confused why they can only shut down their application when using the
development server.
Or they want to be able to do more process management such as reloads, which is definitely out of
scope.

it appears they've added a server.shutdown() command, perhaps we should play with that instead and not depend on the request.environ.get('werkzeug.server.shutdown') which also looks like a pretty bad hack reaching out for something that seems to be a global reference.

Learning more, it seems the root cause of our problem is that we're currently running Flask with the Flask.run() method which is meant only for development environment. This server isn't efficient at all according to the documentation and they recommend you embed Flask into a real WSGI server.
They recommend a few and it seems Waitress could be a good option
https://flask.palletsprojects.com/en/2.2.x/deploying/waitress/
If this becomes too heavy to add, then I'll just go for the os.kill() solution. Although I don't know how effective that will be across all the different OSes.

Like I said happy to test anything I'll fork and send a pr later this evening

Going with your solution for now @jjgalvez
https://github.com/frostwire/frostwire/commit/427ea7482debc5732f66f91d7ea19f3b01a6dc18

awesome, please git pull and give it a try now.

tested on linux arch and now it exits as expected with shutdown=1, I have not tested on windows yet but will. I don't have access to a mac so I can't test there

just tested on windows 11 and it also seems to be working

Thank you so much for testing.
Will go ahead and close this.


Unable to scan EAN+5

This plugin works amazingly well, but I can't find a way to scan the EAN+5 barcodes. I've attached an example.

I guess this issue can help.
You would have to add an additional barcode format, say EAN13+5 on the zxing lib, and play with the code.


[BEAM-10961] enable strict dependency checking for sdks/java/extensions/sketching

Split from #13686
R: @ibzib

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PreCommit

Run Java PreCommit


TH to statically turn a list into a vector?

At the moment, you either have to manually construct the vector using Cons, or use fromList, which causes a runtime overhead and requires you to specify the length.
I know there is a function which infers the length, but often it is not able to do so.
I propose the addition of a Template Haskell function which allows the user to specify a Vector using the List-sugar, without needing to specify redundant information like the length.
(This is important. If you later want to add an element and forget to update the length, you will only notice at runtime that you have a problem. Not exactly ideal)

Thank you for suggestion! I added sized and sized' TH macro to build sized vectors statically.
Usage:
a = $(sized [1,2,3::Integer])

-- b = let a = "foo" in $(sized [a, "bar", "baz"])
b = let a = "foo" in $(sized' [[|a|], [|"bar"|], [|"baz"])


_build/release/_deps: Np such file or directory

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

git clone https://github.com/oap-project/gluten.git
git checkout e6def13f50d86353e7e059b1bb881bf8c5ef66b5
./dev/builddeps-veloxbe.sh

Expected behavior
A clear and concise description of what you expected to happen.
Additional context
Add any other context about the problem here.

Hi @jiangjiguang,
can you please try the main branch today? It's due to some changes included in https://github.com/oap-project/gluten/pull/1384
-yuan

closing, should be fixed in main branch


Dummy change to trigger jenkins

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[ ] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[ ] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[ ] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

retest this please

retest this please

retest this please

retest this please

Obsolete? Close?

Coverage increased (+0.2%) to 69.796% when pulling 620d9be978f2759554581e4e2b66174741fd384a on jasonkuster:dummy into f3cff3695ff86220a0277d2132b8ae0b87e284fe on apache:master.

Coverage increased (+0.1%) to 69.672% when pulling 620d9be978f2759554581e4e2b66174741fd384a on jasonkuster:dummy into f3cff3695ff86220a0277d2132b8ae0b87e284fe on apache:master.


[Feature Request] Nested maxUsages and disabled Attributes for Taxonomy and Choice Tags

Is your feature request related to a problem? Please describe.
I'm always frustrated when using the Taxonomy tag in Label Studio and needing to limit the number of selections one level down. Currently, the maxUsages attribute restricts the total number of selections across all levels, which doesn't provide the granularity I need for specific use cases. Additionally, there's no straightforward way to disable certain choices within the taxonomy structure.
Describe the solution you'd like
I would like an attribute similar to maxUsages that limits the number of selections one level down in the Taxonomy tag. This attribute, which I'll refer to as maxLevelUsages, should allow setting specific limits for each level of the taxonomy. Furthermore, I would like the ability to disable certain choices using a disabled attribute within the Choice tag.
Describe alternatives you've considered
I have considered manually enforcing selection limits through external validation scripts, but this approach is cumbersome and not integrated within Label Studio's interface. Another alternative is nesting multiple Taxonomy tags with separate maxUsages attributes, but this complicates the labeling schema and user experience.
Additional context
Additional Attributes Requested

maxLevelUsages: An attribute to limit the number of selections at each level of the taxonomy.
disabled: An attribute to disable certain choices, preventing them from being selected while still allowing selection of other choices within the same category.

Example with Requested Features
This is a fictional example to illustrate how the feature might work conceptually
<Taxonomy name="Living Things" toName="image" maxLevelUsages="1">
  <Choice value="Animal" maxLevelUsages="2">
    <Choice value="Mammal" maxLevelUsages="2">
      <Choice value="Dog" />
      <Choice value="Cat" />
      <Choice value="Elephant" />
    </Choice>
    <Choice value="Bird" maxLevelUsages="1">
      <Choice value="Eagle" />
      <Choice value="Sparrow" />
    </Choice>
  </Choice>
  <Choice value="Plant" maxLevelUsages="2">
    <Choice value="Tree" maxLevelUsages="1">
      <Choice value="Oak" />
      <Choice value="Pine" />
    </Choice>
    <Choice value="Flower" maxLevelUsages="1" disabled="true">
      <Choice value="Rose" />
      <Choice value="Tulip" />
    </Choice>
  </Choice>
</Taxonomy>

Explanation

At the top level Living Things, only one item can be selected.
Under Animal, up to 2 items can be selected.

Selecting Animal allows choosing up to 2 items under Mammal (e.g., Dog and Cat), or 1 item under Bird (e.g., Eagle).

Under Plant, up to 2 items can be selected.

Selecting Plant allows selecting up to 1 item under Tree (e.g., Oak), and 1 item under Flower (e.g., Rose), but not 2 items under Tree.

disabled: Prevents selection of certain choices (Flower in this example), while still allowing selection of other choices (Rose and Tulip).

Please note that this example is purely fictional and simplified for illustrative purposes. Actual use cases and configurations may vary based on specific labeling tasks and requirements.
These enhancements, including the addition of the disabled attribute, would significantly enhance the flexibility of Label Studio for complex labeling tasks, improving user experience by allowing finer control over choice selections and reducing the need for manual enforcement of selection limits.

/jira create

hi @ProfBrickz - thanks for this feature request! I'll discuss with the team.


v0.10.0 proposal

Upgraded core packages to 0.11.0
Fixes after upgrade
Added lerna changelog in package.json to support plugin_request label
Renamed package plugins-node-all to plugins-node-core-and-contrib

Draft Release: https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/untagged-4839a22120767d5485a8

@dyladan looks like the node-plugins-all package was renamed as a part of this PR... as such, should I still do a rename of that package only to the "instrumentation" convention like we discussed before OR should I just roll that in with the full rename of everything?
Originally, I was going to do that first to fix the versioning issues per our discussions in the meeting. Seems like that probably is no-longer needed?


chore: update the readme

Update the README.md file to reflect the current state of the project. This includes adding a section on how to build and contribute to the project and updates the note about who is currently maintaining the project.
This change-set also removes the CHANGELOG.md file as most Deno projects don't include this and it was mostly a change log of the Astro project.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

NPM link to the changelog should be removed: https://www.npmjs.com/package/@deno/astro-adapter#changelog

NPM link to the changelog should be removed: https://www.npmjs.com/package/@deno/astro-adapter#changelog

Good catch. Actually that entire page is out-of-date. I've updated the README, but it's not reflected there. I wonder who has access to update the NPM description.


:wrench: [2.2] fix: #10263 datagrid dropdown improvements done

Info
#10263

Checked and Found that the Improvement has been done and verified. I have checked the details in below section and found it working properly.
Catalog -> Products
Catalog -> Categories
Catalog -> Attributes
Customers -> Customers
Marketing  ->Promotions -> Cart Rule
Marketing  ->Promotions -> Catalog Rule
Marketing  -> Communications -> Email Templates
Marketing  -> Communications -> Campaigns
Marketing  -> Communications -> Newsletter Subscriptions.
Settings -> Inventory Sources
Settings -> Users
Settings -> Themes


Automated Package Upgrade

:tada: This PR is included in version 5.0.487 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Race condition between InsertLeave and TextChanged (neovim)

I have the following ale config:
let g:ale_lint_delay = 500
let g:ale_lint_on_text_changed = 'normal'
let g:ale_lint_on_insert_leave = 1
let g:ale_lint_on_save = 1
let g:ale_lint_on_enter = 1
let g:ale_fix_on_save = 0

and what I'm seeing is after I made changes in insert mode and go back to normal mode — is that errors are being cleared. I've added logging to relevant places (callsites of ale#Queue()):
insert_leave
LINT NOW
TIMER: 0
text_changed
LINT WITH DELAY
TIMER: 9

Seems like neovim fires TextChanged for changes made in insert mode too but only when I exit insert mode. Thus I have both TextChanged and InsertLeave triggered.
If I change my config to
let g:ale_lint_on_insert_leave = 0

then it's working fine.

I'm closing this as it's not an issue with recent neovim.

It would be nice to know which version it was fixed in, so we can tell people what version they have to update to.

I'm on neovim's HEAD now. I will reopen if I see something weird with it.


Helm - Use Pod Disruption Budget to ensure Dapr remains up

In what area(s)?

/area runtime
/area operator
/area placement

/area docs
/area test-and-release

Describe the feature
Use Pod Disruption Budget to survive voluntary removal such as node update, rollout of new version, etc which defines how many % of instances can be removed at the same time.
This could potentially only be enabled when running in HA is enabled.
Release Note

RELEASE NOTE: ADD Use Pod Disruption Budget to ensure Dapr remains up

A PR for this would be great and most welcomed.

I'll work on this!


MINOR: Give correct instructions for retaining previous unclear leader election behaviour

@rajinisivaram, maybe you can review this trivial change. cc @astubbs

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6253/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6237/
Test PASSed (JDK 8 and Scala 2.12).

Merging to trunk and 0.11.0.

@ijuma
I have opened a PR for this one 19 days ago. No one reviewed it.
https://github.com/apache/kafka/pull/3481

@Kamal15, I was on holiday when that was posted and I missed it. Sorry about that.

@ijuma
It's ok.


text_on_image Creator - Web design #127

https://images01.nicepagecdn.com/page/98/14/html-template-981443.jpg Design a text_on_image like the above image
Create a file "text_on_image_NUM_by_(YourName).html" in the modules/text_on_image folder.
Use simple HTML and CSS and JAVASCRIPT to create the text_on_image animation. You can use the interface development https://kwickerhub.com/ (This project) or you can write the lines of code yourself.
Step by Step Guide.
Fork this project(Use the 'fork' button in the top right corner) and Clone your Fork.
git clone https://github.com/YOUR_USERNAME/frontend
Open your code Editor and Create a file "text_on_image_NUM_YOUR_NAME_.html" in the "modules/text_on_image" folder of this project you just cloned. No need to create head, title and body tags, Just Add a div tag with some embedded style(i.e use the style tag) and the script tag where necessary.
If you want to add an image resource, please add it in the folder ••
"modules/text_on_image/images_and_icons"
We recommend you use an svg for your image/icon.
Push your Code: You need to push your recent changes back to the cloud. Use the command below in the main directory of this Repository
git push origin dev
or use a GUI tool to avoid mistakes or complexity. LOL.
Then make you Pull Request...
Below is a example of the code structure we need:
<div>
    <!---YOUR CODE---->
</div>

<style>
    /* YOUR STYLE */
</style>

<script>
    // YOUR SCRIPT if any
</script>

The goal of this issue is to create modules that other people/dev/designers can use or easily import into their projects. Avoid the desire to style all elements in the page by using codes like:
<style>

*{

}
/* OR */

div, a, h1, pre{

}

</style>

use classes or id to style the elements to avoid a collision of styles.
Remember to make your module usable across different screens(Make your design responsive).
For more examples:
modules->buttons
modules->cards
for examples of contributions or Pull request accepted in to the project.
And please do not wait for this issue to be assigned to you as we have limited hands but have a lot to do/cover. Please send in your PR.
Good-luck and thank you.

Hello @NtemKenyor. It's my first open-source contribution project, and I am working on this issue.

okay that's good to know... Welcome and well done 👍
On Nov 9, 2023 07:15, "Abrar Faiz Mohammed" @.***>
wrote:
Hello @NtemKenyor https://github.com/NtemKenyor. It's my first
open-source contribution project, and I am working on this issue.
—
Reply to this email directly, view it on GitHub
https://github.com/KwickerHub/frontend/issues/627#issuecomment-1803224788,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOKWIBIXSUZ5CMAC7V2K323YDRYGLAVCNFSM6AAAAAA6LW22Y2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBTGIZDINZYHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I want to solve it and start working on this task.

Hello Akshitha. I have already fixed the issue and my PR is already accepted.


Create a tag for Symfony 7 support

Hi,
Would it be possible to create a new tag, at least for runtime/frankenphp-symfony?
Currently, it's not possible to install the package with Symfony 7, and breaks projects relying on FrankenPHP such as Symfony Docker.
Thanks!

Maybe, while you're at it it would be nice if you could merge in #155 and #156 as well? :)

Working on a release now. Just fixing CI first.
Thank you for the ping

Thank you!!


Log: rework setup_from_env and defaults

Fixes #9041

The Log.setup_from_env call is now included by default
The default source level is *

These two things will make all logs of info and above to show in stdout.

The setup_from_env named arguments were changed to allow simpler overrides of defaults (for when env variables are not set).

Since the builders can be reconfigured the effect of calling Log.setup_from_env by default is that some logs might appear in the STDOUT if they are emitted before the framework / application reconfigure it as pleased. Either by calling setup_from_env again or manually defining the bindings.

Do we not want to leave calling Log.setup_from_env to the end application?  The second bullet point and added documentation should address #9041.

Enforcing a default logging setup allows the following small programs to work out of the box.
require "log"

Log.warn { "hello world" }

Since the Log.builder can be reconfigured entirely, as long as there are no entries emitted before the last configuration there is no real difference.
So, I think there are no actual downsides on this approach.

Proposal iterated.

Defaults that that not use environment variables.
Configurations are now overwritten entirely without needing to call builder.clear.
Actually, Log::Builder is no longer exposed.

The Log.setup overloads should allow simple configurations straight away, and the yielding method can be used for more complex binding, still without exposing the builder.

Implemented the proposal in https://github.com/crystal-lang/crystal/pull/9145#discussion_r413963144
I left the default_sources argument since that is still handy to narrow the source you want with the LOG_LEVEL=<severity> without path.
The LOG_LEVEL="<source1>=<level1> <source2>=<level2>" syntax support will come in a later PR.


[ALLUXIO-3163] Pass -X args to the JVM instead of the shell

https://alluxio.atlassian.net/browse/ALLUXIO-3163
-Xmx=8g was ending up after the classname when
calling the JVM. This made it an argument to the
CLI instead of a JVM arg.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19257/
Test PASSed.


Client readable view - fetch only certain columns

Moving this feature request over from the anvil Forum, but here was the original discussion: https://anvil.works/forum/t/querying-client-readable-tables/16567?u=neeeco
I'd like to use the app_table option from Tabulator, but only fetch certain columns which I know I'll use. Currently, if we set the app_table option in Tabulator, all the columns are fetched. I don't mind having links to the unused columns, although perhaps that might be beneficial to avoid as well. But ideally, I would like to only fetch columns that I specify in a list, similar to the q.fetch_only(*my_columns) query that we can use with app_tables.my_table.search(q.fetch_only()) in anvil.

there is already a set_query() option and you could do self.tabulator_1.set_query(q.fetch_only(...))
but that doesn't help with the first load
i've just added an initial_query to the available options.
from tabulator.Tabulator import Query

...

    self.tabulator.options = {
        ...
        "initial_query": Query(q.fetch_only(...)),
    }

You'll need to switch to the development dependency to try it out

@NicoN13  is that working out for you?

Hi @s-cork, yes was testing it this morning and seems to be working as expected. I am noticing an improvement in the loading time. Thanks


Update to Go API v2 for Protocol Buffers

github.com/gogo/protobuf currently has the following bug with https://blog.golang.org/protobuf-apiv2: https://github.com/gogo/protobuf/issues/678, reverted this example to use github.com/golang/protobuf

Thanks @zeidoo


Field sort not suitable

I change some codes for oracle db. It's work well.
There is one problem is field sort not suitable. How to change field sort?

I'm not sure I understand the issue.  Looks like the issue is that your column names are capitalized, which is not an OracleDB requirement (as far as I know).  I'm not against using strtolower() for comparison purposes wherever that may be needed, but not for display.


Add mute to application taskbar menu

Menu on right click in taskbar icon could allow user to mute the application.

Implemented for macOS, currently not planned for other OS due to complicated or missing API.

Feature implemented in tray icon for other OS. Seems that it does not work on Linux/Gnome but works fine on Windows.


ELT run fails when more than 64KiB of state is written

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2166
Originally created by @rahul168 on 2020-07-14 17:21:15

What is the current bug behavior?
Running meltano elt with tap-salesforce and target-jsonl throws error after a long run and downloading more than 800 objects.
What is the expected correct behavior?
Running meltano elt with tap-salesforce and target-jsonl should complete successfully without any error.
Steps to reproduce
Run meltano elt tap-salesforce target-jsonl with all objects (.) and after downloading more than 800 objects the meltano throws error.
Relevant logs and/or screenshots
ERROR exception calling callback for <Future at 0x7fb9db662110 state=finished returned NoneType>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/lib64/python3.7/asyncio/futures.py", line 365, in _call_set_state
    dest_loop.call_soon_threadsafe(_set_state, destination, source)
  File "/usr/lib64/python3.7/asyncio/base_events.py", line 732, in call_soon_threadsafe
    self._check_closed()
  File "/usr/lib64/python3.7/asyncio/base_events.py", line 479, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Task exception was never retrieved
future: <Task finished coro=<SingerRunner.bookmark() done, defined at /home/ec2-user/.venv/meltano/lib64/python3.7/site-packages/meltano/core/runner/singer.py:133> exception=ValueError('Separator is found, but chunk is longer than limit')>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/asyncio/streams.py", line 496, in readline
    line = await self.readuntil(sep)
  File "/usr/lib64/python3.7/asyncio/streams.py", line 592, in readuntil
    'Separator is found, but chunk is longer than limit', isep)
asyncio.streams.LimitOverrunError: Separator is found, but chunk is longer than limit
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/ec2-user/.venv/meltano/lib64/python3.7/site-packages/meltano/core/runner/singer.py", line 135, in bookmark
    last_state = await target_stream.readline()
  File "/usr/lib64/python3.7/asyncio/streams.py", line 505, in readline
    raise ValueError(e.args[0])
ValueError: Separator is found, but chunk is longer than limit
ELT could not complete, an error happened during the process: Subprocesses didn't exit cleanly: tap(1), target(0)

Possible fixes
The error indicates that the tap is writing a state line (that the target is forwarding) of more than 64KiB in length, or that the total state emitted up to that point is over 64KiB in length (see https://stackoverflow.com/a/55458913)
That's a lot of state, but not necessarily out of character for Salesforce
It will also help if meltano persist state in system database more frequently, may be after each object download completion.
Further regression test
Ensure we automatically catch similar issues in the future

[ ] Write additional adequate test cases and submit test results
[ ] Test results should be reviewed by a person from the team

/label ~bug
/label ~"To Do"

View 4 previous comments from the original issue on GitLab


could not launch playwright when updating to v0.4101.0

Could not launch playwright when updating to v0.4101.0 using docker
RUN go mod download
RUN go run github.com/playwright-community/playwright-go/cmd/playwright@latest install --with-deps
RUN make build

2024/01/24 15:46:34 could not launch playwright: could not start driver: fork/exec /root/.cache/ms-playwright-go/1.40.1/playwright.sh: no such file or directory

Rolling back to v0.4001.0 fixed the issue for me
RUN go mod download
RUN go run<EMAIL_ADDRESS>install --with-deps
RUN make build

take a look go.mod, you need run go get -u github.com/playwright-community/playwright-go upgrade, not only install new driver and deps

is there any working Dockerfile example with alpine or ubuntu?

same problem

Look at the example below. Please make sure the playwright-go version in go.mod is the same as v0.4201.0 in the Dockerfile.


md-select (& placeholder) do not line up with md-input

Underline is lower, placeholder is higher
http://plnkr.co/edit/fxwn4I2zIUJ5PN3tNFwa?p=preview

Thanks for reporting!  Since this is really similar to your issue #2124, let's just track the issue there.


Add Type Checking On Channel Args

Addressed #8694
Will also add a linter. Eventually the promise should be that no code is using GRPC_ARG_* explicitly, but is always interacting with the args via the channel arg API

This change is

About halfway done on this. Just want to get thoughts before I continue. Since the channel arg re write is pretty far out in the future, I figure we should tackle this now

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +3.5%    +144 src/core/lib/channel/channel_args.cc                                                    +144  +3.5%
      [NEW]    +131 grpc_channel_arg_get_pointer                                                            +131  [NEW]
      +7.0%     +13 [Unmapped]                                                                               +13  +7.0%
  +1.0%    +112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  +112  +1.0%
      +3.4%    +110 grpc_core::(anonymous namespace)::PickFirst::UpdateLocked                               +110  +3.4%
      +0.8%      +2 [Unmapped]                                                                                +2  +0.8%

 -------------- SHRINKING                                                                            --------------
  -0.1%    -392 [None]                                                                               -6.94Ki  -0.1%
      -0.1%    -328 [Unmapped]                                                                           -6.88Ki  -0.1%
      [DEL]     -32 vtable for grpc_core::RefCounted<grpc_core::FakeResolverResponseGenerator>               -32  [DEL]
      [DEL]     -32 vtable for grpc_core::FakeResolverResponseGenerator                                      -32  [DEL]
  -6.0%    -960 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                          -960  -6.0%
     -94.3%    -966 grpc_core::(anonymous namespace)::GrpcLbFactory::CreateLoadBalancingPolicy(grpc_core    -966 -94.3%
      -0.5%      -6 grpc_core::(anonymous namespace)::GrpcLb::ProcessChannelArgsLocked                        -6  -0.5%
  -3.5%     -56 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb_channel_secure.cc            -56  -3.5%
      -6.3%     -56 grpc_lb_policy_grpclb_modify_lb_channel_args                                             -56  -6.3%
  -1.7%     -32 src/core/ext/filters/client_channel/resolver/fake/fake_resolver.cc                       -32  -1.7%
     -46.2%     -24 grpc_core::FakeResolverResponseGenerator::GetFromArgs                                    -24 -46.2%
      -5.2%      -8 [Unmapped]                                                                                -8  -5.2%
  -1.8%     -24 src/core/ext/filters/client_channel/lb_policy_factory.cc                                 -24  -1.8%
     -46.2%     -24 grpc_lb_addresses_find_channel_arg                                                       -24 -46.2%
  -0.1%     -16 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                 -16  -0.1%
      -0.6%     -16 grpc_core::(anonymous namespace)::RoundRobin::UpdateLocked                               -16  -0.6%

  -0.1% -1.20Ki TOTAL                                                                                -7.75Ki  -0.1%

****************************************************************

libgrpc++.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++
  [ = ]       0 [None]     +40  +0.0%

  [ = ]       0 TOTAL      +40  +0.0%

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Thanks, this is useful improvement.

Reviewed 8 of 8 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

src/core/lib/channel/channel_args.h, line 122 at r1 (raw file):

    Otherwise, emits a warning log, and returns nullptr.
    If arg is nullptr, returns nullptr, and does not emit a warning. */
void* grpc_channel_arg_get_pointer(const grpc_arg* arg);

Every caller who uses this will need to static_cast the result to the right type.  We could make it a bit more convenient by templatizing this and putting the static_cast here.  So instead of a caller doing this:
static_cast<mytype*>(grpc_channel_arg_get_pointer(arg))

they can do this:
grpc_channel_arg_get_pointer<mytype*>(arg)

src/core/lib/channel/channel_args.cc, line 372 at r1 (raw file):

    return nullptr;
  }
  GPR_ASSERT(arg->value.pointer.p != nullptr);

I think this can be removed -- if we've already got the semantic that we return nullptr on error, we can do the same if the actual value is nullptr.

Comments from Reviewable

I added a linter. Now we don't ever use GRPC_ARG* directly. All code interacts through the helpers that will warn upon type mismatch.
We might consider turning the warning into hard errors (if possible). Being stricter is always a good idea. What do you think?

Review status: 0 of 24 files reviewed, 2 unresolved discussions (waiting on @markdroth, @ncteisen, @dgquintas, and @AspirinSJL)

src/core/lib/channel/channel_args.h, line 122 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Every caller who uses this will need to static_cast the result to the right type.  We could make it a bit more convenient by templatizing this and putting the static_cast here.  So instead of a caller doing this:
static_cast<mytype*>(grpc_channel_arg_get_pointer(arg))

they can do this:
grpc_channel_arg_get_pointer<mytype*>(arg)

Great call. Done

src/core/lib/channel/channel_args.cc, line 372 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
I think this can be removed -- if we've already got the semantic that we return nullptr on error, we can do the same if the actual value is nullptr.

Done

Comments from Reviewable

[trickle] No significant performance differences

We might consider turning the warning into hard errors (if possible). Being stricter is always a good idea. What do you think?

I'm not sure exactly which warnings you're talking about here.  You mean have the getter methods fail instead of just logging if the specified type is incorrect?  I think that would take a lot more work.  I wouldn't want it to just assert, since that can cause crashes in production code.  So instead, we would need to change the getter API to allow them to return an error, and then we'd need to update all of the callers to do something intelligent with that error.  I think that might be a good idea, but it also might be more work that you're interested in taking on right now.

Reviewed 18 of 19 files at r2, 7 of 7 files at r3.
Review status: all files reviewed, 14 unresolved discussions (waiting on @ncteisen, @dgquintas, and @AspirinSJL)

src/core/ext/filters/http/client/http_client_filter.cc, line 443 at r3 (raw file):

  grpc_mdelem valid_schemes[] = {GRPC_MDELEM_SCHEME_HTTP,
                                 GRPC_MDELEM_SCHEME_HTTPS};
  if (channel_args != nullptr) {

grpc_channel_args_find() returns null if the channel args are null, so there's no need to check this here.

src/core/ext/filters/http/client/http_client_filter.cc, line 460 at r3 (raw file):

static size_t max_payload_size_from_args(
    const grpc_channel_args* channel_args) {
  if (channel_args != nullptr) {

grpc_channel_args_find() returns null if the channel args are null, so there's no need to check this here.

src/core/ext/filters/http/client/http_client_filter.cc, line 463 at r3 (raw file):

    const grpc_arg* arg =
        grpc_channel_args_find(channel_args, GRPC_ARG_MAX_PAYLOAD_SIZE_FOR_GET);
    // TODO(mark): is 0 a correct minimum for this value?

Ask @makdharma about this.

src/core/ext/transport/inproc/inproc_transport.cc, line 1208 at r3 (raw file):

  grpc_arg default_authority_arg = grpc_channel_arg_string_create(
      const_cast<char*>(GRPC_ARG_DEFAULT_AUTHORITY),

While you're at it, it might be nice to do something about all of these const_casts.  One possibility is to change the grpc_channel_arg_*_create() functions to accept args as const and do the cast internally.  Another option (slightly cleaner, although more invasive) would be to change the grpc_arg struct itself to require the parameters to be const.

src/core/lib/channel/channel_args.h, line 112 at r3 (raw file):

/** Returns the value of \a arg, subject to the contraints in \a options. */
int grpc_channel_arg_get_integer(const grpc_arg* arg,

It looks like it's a common pattern to call grpc_channel_args_find() and then use one of these functions on the result.  Given that, it might be a good idea to provide alternative versions of each of these getters that compose those two steps.  That way, instead of doing this (just to use one example):
    const grpc_arg* arg =
        grpc_channel_args_find(args, GRPC_ARG_USE_CRONET_PACKET_COALESCING);
    bool use_packet_coalescing = grpc_channel_arg_get_bool(arg, false);

the application can just do something like this:
  bool use_packet_coalescing = grpc_channel_args_get_bool(
      args, GRPC_ARG_USE_CRONET_PACKET_COALESCING, false);

src/core/lib/iomgr/tcp_client_posix.cc, line 82 at r3 (raw file):

  err = grpc_set_socket_no_sigpipe_if_possible(fd);
  if (err != GRPC_ERROR_NONE) goto error;
  if (channel_args) {

No need for this check, since it's already done inside of grpc_channel_args_find().

src/core/lib/iomgr/tcp_client_posix.cc, line 87 at r3 (raw file):

    grpc_socket_mutator* mutator =
        grpc_channel_arg_get_pointer<grpc_socket_mutator>(arg);
    if (mutator) {

Prefer != nullptr for pointers, so it's clear at a glance that this isn't a bool.

src/core/lib/iomgr/tcp_server_posix.cc, line 66 at r3 (raw file):

  s->expand_wildcard_addrs = false;
  for (size_t i = 0; i < (args == nullptr ? 0 : args->num_args); i++) {
    // TODO(roth): I chose that these both default to true. Is this reasonable?

I think we should stick as close to the original behavior as possible.  It's true that we're no longer going to fail, but we should still stick with the original defaults.  So so_reuseport should default to grpc_is_socket_reuse_port_supported(), and expand_wildcard_addrs should default to false.

src/core/lib/iomgr/tcp_server_utils_posix_common.cc, line 174 at r3 (raw file):

  if (err != GRPC_ERROR_NONE) goto error;

  if (s->channel_args) {

No need to check this here, since it's done in grpc_channel_args_find().

src/core/lib/iomgr/tcp_server_utils_posix_common.cc, line 179 at r3 (raw file):

    grpc_socket_mutator* mutator =
        grpc_channel_arg_get_pointer<grpc_socket_mutator>(arg);
    if (mutator) {

Prefer != nullptr.

src/core/lib/security/context/security_context.cc, line 329 at r3 (raw file):

}

grpc_auth_context* grpc_auth_context_from_arg(const grpc_arg* arg) {

This function is declared in security_context.h, and it may be used internally.  Please verify that it's not before removing it (and update the header file accordingly).

src/core/lib/security/credentials/credentials.cc, line 171 at r3 (raw file):

}

grpc_channel_credentials* grpc_channel_credentials_from_arg(

Same issue here -- this may be used internally and is declared in credentials.h.

src/core/lib/security/credentials/credentials.cc, line 266 at r3 (raw file):

}

grpc_server_credentials* grpc_server_credentials_from_arg(const grpc_arg* arg) {

Same here.

src/core/lib/security/security_connector/security_connector.cc, line 258 at r3 (raw file):

}

grpc_security_connector* grpc_security_connector_from_arg(const grpc_arg* arg) {

Same issue here.

Comments from Reviewable

[microbenchmarks] No significant performance differences

Ok, I left left all behavior as is for now. I also added the helpers you suggested and used them I saw a find followed by a get

Review status: all files reviewed, 14 unresolved discussions (waiting on @markdroth, @ncteisen, @dgquintas, and @AspirinSJL)

src/core/ext/filters/http/client/http_client_filter.cc, line 443 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
grpc_channel_args_find() returns null if the channel args are null, so there's no need to check this here.

Done.

src/core/ext/filters/http/client/http_client_filter.cc, line 460 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
grpc_channel_args_find() returns null if the channel args are null, so there's no need to check this here.

Done.

src/core/ext/filters/http/client/http_client_filter.cc, line 463 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Ask @makdharma about this.

Done. 0 was the correct clamping value

src/core/ext/transport/inproc/inproc_transport.cc, line 1208 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
While you're at it, it might be nice to do something about all of these const_casts.  One possibility is to change the grpc_channel_arg_*_create() functions to accept args as const and do the cast internally.  Another option (slightly cleaner, although more invasive) would be to change the grpc_arg struct itself to require the parameters to be const.

I feel like pushing the const case deeper into the library is a little dangerous. As it is now, it is clear looking at the functions call that the const casts are safe, since they are casting string literals. I am worries that if we bury the casts deeper, then it could lead to bad bugs where people call the helpers, not realizing there is a cast underneath

src/core/lib/channel/channel_args.h, line 112 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
It looks like it's a common pattern to call grpc_channel_args_find() and then use one of these functions on the result.  Given that, it might be a good idea to provide alternative versions of each of these getters that compose those two steps.  That way, instead of doing this (just to use one example):
    const grpc_arg* arg =
        grpc_channel_args_find(args, GRPC_ARG_USE_CRONET_PACKET_COALESCING);
    bool use_packet_coalescing = grpc_channel_arg_get_bool(arg, false);

the application can just do something like this:
  bool use_packet_coalescing = grpc_channel_args_get_bool(
      args, GRPC_ARG_USE_CRONET_PACKET_COALESCING, false);

Done.

src/core/lib/iomgr/tcp_client_posix.cc, line 82 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
No need for this check, since it's already done inside of grpc_channel_args_find().

Done.

src/core/lib/iomgr/tcp_client_posix.cc, line 87 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Prefer != nullptr for pointers, so it's clear at a glance that this isn't a bool.

Done.

src/core/lib/iomgr/tcp_server_posix.cc, line 66 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
I think we should stick as close to the original behavior as possible.  It's true that we're no longer going to fail, but we should still stick with the original defaults.  So so_reuseport should default to grpc_is_socket_reuse_port_supported(), and expand_wildcard_addrs should default to false.

Done.

src/core/lib/iomgr/tcp_server_utils_posix_common.cc, line 174 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
No need to check this here, since it's done in grpc_channel_args_find().

Done.

src/core/lib/iomgr/tcp_server_utils_posix_common.cc, line 179 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Prefer != nullptr.

Done.

src/core/lib/security/context/security_context.cc, line 329 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This function is declared in security_context.h, and it may be used internally.  Please verify that it's not before removing it (and update the header file accordingly).

Can't find any users internally (or on github via a quick search).

src/core/lib/security/credentials/credentials.cc, line 171 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Same issue here -- this may be used internally and is declared in credentials.h.

Done.

src/core/lib/security/credentials/credentials.cc, line 266 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Same here.

Done.

src/core/lib/security/security_connector/security_connector.cc, line 258 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Same issue here.

Done.

  Thanks for doing it!

Reviewed 38 of 38 files at r4.
Review status: all files reviewed, 6 unresolved discussions (waiting on @markdroth, @ncteisen, @dgquintas, and @AspirinSJL)

src/core/ext/filters/http/client/http_client_filter.cc, line 460 at r4 (raw file):

      channel_args, GRPC_ARG_MAX_PAYLOAD_SIZE_FOR_GET,
      {kMaxPayloadSizeForGet, 0, kMaxPayloadSizeForGet});
  return kMaxPayloadSizeForGet;

This statement is no longer needed.

src/core/ext/transport/inproc/inproc_transport.cc, line 1208 at r3 (raw file):
Previously, ncteisen (Noah Eisen) wrote…
I feel like pushing the const case deeper into the library is a little dangerous. As it is now, it is clear looking at the functions call that the const casts are safe, since they are casting string literals. I am worries that if we bury the casts deeper, then it could lead to bad bugs where people call the helpers, not realizing there is a cast underneath

Yeah, that's why I prefer the second option: change the grpc_arg struct to use const.  Maybe see how hard it would be to do that?  I'm not sure how invasive that would be.

src/core/lib/channel/channel_args.h, line 115 at r4 (raw file):

                                 const grpc_integer_options options);
/** convinience helper for the above that finds the arg first. */
inline int grpc_channel_arg_find_and_get_integer(

Suggest just calling this grpc_channel_args_get_integer().

src/core/lib/channel/channel_args.h, line 127 at r4 (raw file):

char* grpc_channel_arg_get_string(const grpc_arg* arg);
/** convinience helper for the above that finds the arg first. */
inline char* grpc_channel_arg_find_and_get_string(const grpc_channel_args* args,

Similarly, suggest calling this grpc_channel_args_get_string().

src/core/lib/channel/channel_args.h, line 146 at r4 (raw file):

/** convinience helper for the above that finds the arg first. */
template <typename Type>
inline Type* grpc_channel_arg_find_and_get_pointer(

grpc_channel_args_get_pointer()

src/core/lib/channel/channel_args.h, line 152 at r4 (raw file):

bool grpc_channel_arg_get_bool(const grpc_arg* arg, bool default_value);
inline bool grpc_channel_arg_find_and_get_bool(const grpc_channel_args* args,

grpc_channel_args_get_bool()

Comments from Reviewable

Addressed all comments

Review status: all files reviewed, 6 unresolved discussions (waiting on @ncteisen, @markdroth, @dgquintas, and @AspirinSJL)

src/core/ext/filters/http/client/http_client_filter.cc, line 460 at r4 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This statement is no longer needed.

Done.

src/core/ext/transport/inproc/inproc_transport.cc, line 1208 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Yeah, that's why I prefer the second option: change the grpc_arg struct to use const.  Maybe see how hard it would be to do that?  I'm not sure how invasive that would be.

The complexity of that definitely is out of scope for what I want to accomplish in this PR since grpc_arg is part of the core API. That change would need changes to wrapped language bindings:
https://github.com/grpc/grpc/blob/17684374f5a17c43a1b213d853ca03025abd95ed/src/python/grpcio/grpc/_cython/_cygrpc/grpc.pxi?utf8=✓#L180-L183
I can put in an issue and tackle that one next fixit week :)

src/core/lib/channel/channel_args.h, line 115 at r4 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Suggest just calling this grpc_channel_args_get_integer().

Done. Somehow I forgot that we were C++ now and that overloading is ok....

src/core/lib/channel/channel_args.h, line 127 at r4 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Similarly, suggest calling this grpc_channel_args_get_string().

Done.

src/core/lib/channel/channel_args.h, line 146 at r4 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
grpc_channel_args_get_pointer()

Done.

src/core/lib/channel/channel_args.h, line 152 at r4 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
grpc_channel_args_get_bool()

Done.

Reviewed 1 of 34 files at r5.
Review status: 9 of 42 files reviewed, 4 unresolved discussions (waiting on @markdroth, @dgquintas, and @AspirinSJL)

src/core/ext/transport/inproc/inproc_transport.cc, line 1208 at r3 (raw file):
Previously, ncteisen (Noah Eisen) wrote…
The complexity of that definitely is out of scope for what I want to accomplish in this PR since grpc_arg is part of the core API. That change would need changes to wrapped language bindings:
https://github.com/grpc/grpc/blob/17684374f5a17c43a1b213d853ca03025abd95ed/src/python/grpcio/grpc/_cython/_cygrpc/grpc.pxi?utf8=✓#L180-L183
I can put in an issue and tackle that one next fixit week :)

Sounds good.

src/core/lib/channel/channel_args.h, line 115 at r4 (raw file):
Previously, ncteisen (Noah Eisen) wrote…
Done. Somehow I forgot that we were C++ now and that overloading is ok....

Sorry, I guess I should have been more explicit: I meant grpc_channel_args_get_integer(), not grpc_channel_arg_get_integer().   Using the plural here is more appropriate, since this is a method of grpc_channel_args instead of a method of grpc_arg, and it means that there's no need for overloading.

src/core/lib/channel/channel_args.h, line 127 at r4 (raw file):
Previously, ncteisen (Noah Eisen) wrote…
Done.

Same here.

src/core/lib/channel/channel_args.h, line 146 at r4 (raw file):
Previously, ncteisen (Noah Eisen) wrote…
Done.

Same here.

src/core/lib/channel/channel_args.h, line 152 at r4 (raw file):
Previously, ncteisen (Noah Eisen) wrote…
Done.

Same here.

Comments from Reviewable

Sublime has great find and replace functionality :)

Review status: 9 of 42 files reviewed, 4 unresolved discussions (waiting on @markdroth, @dgquintas, and @AspirinSJL)

src/core/lib/channel/channel_args.h, line 115 at r4 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Sorry, I guess I should have been more explicit: I meant grpc_channel_args_get_integer(), not grpc_channel_arg_get_integer().   Using the plural here is more appropriate, since this is a method of grpc_channel_args instead of a method of grpc_arg, and it means that there's no need for overloading.

Oops, I misread the original comment. Done.

Review status: 8 of 42 files reviewed, 5 unresolved discussions (waiting on @dgquintas, @markdroth, @ncteisen, and @AspirinSJL)

src/core/ext/filters/http/client/http_client_filter.cc, line 446 at r5 (raw file):

      grpc_channel_arg_get_string(channel_args, GRPC_ARG_HTTP2_SCHEME);
  if (scheme != nullptr) {
    for (i = 0; i < GPR_ARRAY_SIZE(valid_schemes); i++) {

why not do the usual for (size_t i = 0 ... instead of declaring i separately? It seems that's just a relic of our former C89 codebase.

Comments from Reviewable

Addressed all comments

Review status: 8 of 42 files reviewed, 5 unresolved discussions (waiting on @dgquintas, @markdroth, and @AspirinSJL)

src/core/ext/filters/http/client/http_client_filter.cc, line 446 at r5 (raw file):
Previously, dgquintas (David G. Quintas) wrote…
why not do the usual for (size_t i = 0 ... instead of declaring i separately? It seems that's just a relic of our former C89 codebase.

Done.

Comments from Reviewable

[trickle] No significant performance differences

[microbenchmarks] Performance differences noted:
Benchmark                         cpu_time    real_time
--------------------------------  ----------  -----------
BM_ErrorGetStatusCode<ErrorNone>  +11%        +11%

@yashykt just added a new call site that needs to be fixed in #15699.  Otherwise, this looks great!

Reviewed 33 of 34 files at r6, 1 of 1 files at r7.


optional feature to use aws-lc-rs rustls feature

Motivation
Fix #1562 .
Solution
Add a aws-lc-rs option feature and initialize the default CryptoProvider when building a kube::Client from a kube::Config.

All looks good to me, but the --all-features lib tests are complaining, not sure why all features is not calling the provider setup.

All looks good to me, but the --all-features lib tests are complaining, not sure why all features is not calling the provider setup.

oidc test is not using Client::try_from, so it's not getting automatic the aws-lc-rs (which is as I intended). I've added the manual setup.

upon inspection of the error in kube-client::api::tests::entry_create_missing_object, I realized rustls::crypto::CryptoProvider::install_default sets the value of a once_cell::sync::OnceCell, so it only fails if a value is already there. Which means it's not an error for this usecase. Commented about that, removed the error I created.

I've added OpenSSL to the allowed licenses, we should be ok on every test here :)

I wouldn't worry abou the deny failure, that should be from duplicate dependencies (transitively through the tree) and it's often flagging up things that's hard to do things about. The explicit license allow here I don't think is necessary.

OpenSSL appeared in aws-lc-rs-sys's Cargo.toml

OpenSSL appeared in aws-lc-rs-sys's Cargo.toml

ew, i see :(
yeah, then your change makes sense here then.

here we are, only the duplicate dep error you mentioned remains :)

If you have time to make a ignore for it to make the branch green you could just list rustls-native-certs in the deny.toml and it should clean up :-)


Error saving colourbar_XX.png in production mode

In production mode, the python script doesn't have the permissions to save the new "colourbar_XX.png" files. My guess is that there is a list of predefined filepaths that are writable (to reduce security risks) which currently only has "colourbar.png" added. I've sent Richard Rigby an email to check if this is the case and how we can go about adding new filepaths if so. In the meantime, I've ftp'd the 3 currently used colourbar pngs onto the server manually, and commented out the line of python code that writes the png file.

Richard has now sorted this


Updated eventmetrices.go

Closes: #973

Hi @RickDeb2004, thanks for the contribution! There are a few issues with your code that prevent compilation. Could you please fix them up?

Hi @RickDeb2004, thanks for the contribution! There are a few issues with your code that prevent compilation. Could you please fix them up?

ok @willfindlay

It has been a while since we have any updates on that PR. As this also has compilation issues I am closing that for now. Feel free to re-open that if you want to work on that!


Explorer: view total number of coins held in address results

Problem
The Address Results in the SuiExplorer website shows each coin object individually even though these are fungible tokens. Instead there should be a Preview Card that shows the total number of coins held.
See the SuiExplorer website for how this issue is currently being handled: https://explorer-demo.sui.io/addresses/09818aac3edf9cf9b006b70c36e7241768b26386

This issue is handled by now merged PR https://github.com/MystenLabs/sui/pull/1741


[cxx-interop] Fix lookup of class template instantiations

To fix a crash during deserialization, we need to store the mangled names of C++ class template instantiations in the lookup table.
For example, std::string will be serialized as __CxxTemplateInstNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE, and when another instance of the Swift compiler will later attempt to deserialize a decl referencing this instantiation, it will query the SwiftLookupTable for a decl with this name. If this instantiation is not referenced from the module that is currently being compiled, Swift will not instantiate std::string during typechecking, and the mangled name will be missing from SwiftLookupTable, leading to a deserialization failure. This happens when compiling with cross-module optimization enabled, and the current module does not reference std::string, but one of its dependencies does.

This is a requirement for https://github.com/apple/swift/pull/42297

@swift-ci please smoke test


Circuits invisible on Gitpod

Describe the bug
On setting up CircuitVerse through Gitpod, I saw that circuits on home page under Editor's Pick and Recent Circuits were not visible.
To Reproduce
Steps to reproduce the behavior:

Go to SETUP.md
Follow Gitpod instructions to set up CircuitVerse
On successful setup, open the preview in browser
Scroll down to see error on homepage

Expected behavior
Circuits should be visible as this might cause confusion to young users who are getting started with the platform
Screenshots

Device Information [optional]:

OS: Windows
Browser: Microsoft Edge

Additional context
Add any other context about the problem here.
Are you working on this issue? (Yes/No)
No

I think this is because rails db:seed is not run and so there are no circuits available ?

What is the issue? Can anyone explain?

I am using Gitpod as well, the recent circuits are being shown in the preview.
Browser: Chrome
OS: Mac OS

I think it's because some circuits are hardcoded (in the featured section) by the team and if you want to see your recent circuits, you need to make your own, and then it will be shown there. @tachyons could you please confirm ?

I think it's because some circuits are hardcoded (in the featured section) by the team and if you want to see your recent circuits, you need to make your own, and then it will be shown there. @tachyons could you please confirm ?

Gitpod creates a fresh setup, so there won't be any circuits in the recent circuits section, you create new circuits to get items in recent circuits section, also there is an option to set a circuit as featured

Gitpod creates a fresh setup, so there won't be any circuits in the recent circuits section, you create new circuits to get items in recent circuits section, also there is an option to set a circuit as featured


add Django robots.txt and sitemap framework

Add django-robots and django.contrib.sitemaps applications and provide some configuration for the sitemaps.
The sitemap is configured at the moment to include the 200 most recently updated media items and the index page. As we add channel views, etc, we should add them to the sitemap to help Search Engines out.
The actual configuration of the robots.txt is via the Djano sites framework and is performed in the admin so, once deployed, there is a chore to go and configure all the sites.
The sites framework records the domain name of the site in the database.  The default post_migration hook creates an "example.com" entry which also needs modifying in the admin on all the deployed sites.
Closes #173

All seems good but I think we need to add a complementary PR in media-deploy and/or a env variable to reject any indexing unless it is the production environment. Otherwise we have the risk of index non-prod environments by mistake. Something like always forbid to index except if it is the production one. The complementary PR in media-deploy could also include the data migration for the database with the correct domain name? So we avoid deploying incorrectly in the future (knowledge gets lost and we may forget to change example.com in the future)

Having a site specific migration is slightly going against the grain of the way this is supposed to work but we can probably work something out.

So, having pondered this, we can probably do it with a YAML fixture in the deploy repo and have the migration container also run load data. I think load data does the right thing if the data is already there.

Yes, something like that I was thinking of or perhaps an env variable like SITEMAP that is only True in media-deploy if production and then add to the script that gets executed everytime we start a container (that currently only executes migrations) a check that the database contains the right content regarding sitemap (correct URL and index everything in production, no index anything otherwise)