fix perf

Interesting bits:
let allColors = [/*...*/]
let allText = document.body.textContent
let usedColors = allColors.filter(c => allText.includes(c))
let colorExp = new RegExp(`\\b(${usedColors.join("|")})s?\\b`, 'i')
let instance = new Mark(document.body);
instance.markRegExp(colorExp)

@JamesMitofsky bump

Looks gucci — merged. :)
Currently pending review from Chrome Web Store team; might take a few weeks.


Create an icon for the plugin

The Chrome Web Store requires each and every plugin to have an icon with 128 x 128 pixels. Ideally, this icon would also be recognizable when down-scaled to 48 x 48 or even 16 x 16 pixels in order to double as a favicon.
Other than that, I have no requirements. Be creative!
For more details, please see Chrome's documentation on extension icons

It's my first time on hacktober, I have an icon for you, saved both as png and svg, do I need to clone your project and make a pull request or do I send it here as a comment?


Metrics server should be deployable as an addon and working on every Rancher deployed cluster

Rancher versions:
rancher/server or rancher/rancher: 2.0.2
rancher/agent or rancher/rancher-agent: 2.0.2
metrics-server should be an add-on, and kubelet and apiserver configured in manner that allows the metrics server and thus HPA to work on a rancher deployed cluster

@lonewulf While this is being worked on, you can get metrics-server working on rancher 2.0
https://github.com/JasonvanBrackel/metrics-server-on-rancher-2.0.2

@JasonvanBrackel Thanks, that's exactly the thing I ended doing yesterday :)

I get error:
Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)

We're going to add this add-on as an option for RKE managed clusters, where by default, it will be turned on and you will have the option to disable it.

rancher/rancher:master at july 23rd
I was able to confirm that metrics server has been deployed successfully to every cluster created:
# Run kubectl commands inside here
# e.g. kubectl get all
> kubectl top nodes
NAME      CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
rke-do1   87m          4%        1635Mi          42%
rke-do2   102m         5%        1504Mi          39%
rke-do3   125m         6%        1596Mi          41%
> kubectl top pods --all-namespaces
NAMESPACE       NAME                                    CPU(cores)   MEMORY(bytes)
cattle-system   cattle-cluster-agent-5d8d4b5c6f-476wf   0m           15Mi
cattle-system   cattle-node-agent-7tnwc                 6m           28Mi
cattle-system   cattle-node-agent-qtq99                 0m           11Mi
cattle-system   cattle-node-agent-tjfl9                 0m           11Mi
default         nginx-4gjps                             0m           1Mi
default         nginx-5fzl7                             0m           1Mi
default         nginx-6qbcf                             0m           1Mi
ingress-nginx   default-http-backend-797c5bc547-74zmd   0m           2Mi
ingress-nginx   nginx-ingress-controller-cm26n          2m           43Mi
kube-system     canal-68bkz                             19m          45Mi
kube-system     canal-8q9sj                             12m          46Mi
kube-system     canal-ndvjp                             14m          45Mi
kube-system     kube-dns-7588d5b5f5-fnsjj               0m           22Mi
kube-system     kube-dns-autoscaler-5db9bbb766-gtswl    0m           5Mi
kube-system     metrics-server-97bc649d5-v6grf          0m           12Mi

Hi, I have created a cluster using RKE v0.1.9-rc9 and Rancher Server v2.0.7-rc2, should I be able to see the metrics on this version or it has not been released yet? Thanks!
$ kubectl --kubeconfig=kube_config_rancher-cluster.yml get hpa/site
NAME      REFERENCE         TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
site      Deployment/site    / 20%   2         5         2          16m

Hi I have deployed the Kubernetes cluster using latest rke v0.1.9 .The metric server gets deployed successfully .Kubectl top nodes and kubectl top pods command works fine.But when I open up the kubernetes dashboard then I am not able to see the metrics on Dashboard like CPU usages .When I look at the logs of the Kubernetes dashboard pod I am seeing following messages
No metric client provided. Skipping metrics
2018/09/24 02:34:59 Metric client health check failed: the server could not find the requested resource (get services heapster). Retrying in 30 seconds


rust-version = “1.79” Is this really necessary right now?

1087b4a199584a8163aa4a718938a752875a2746
Is it too radical to lose support for windows 7 just for the convenience of a few syntax lines

You can still compile for Windows 7. You just have to setup the appropriate rustup tier 3 target.
(Note: I'm just a user/contributor and do not make decisions for the project, so the rest is just opinion.)
To answer the question: The Rust Organization, and even Microsoft themselves, have indeed deemed it too radical to continue to support Windows 7. It (Windows 7) has past both its official "end of life" date and "extended security updates" date, so anyone still using it should question that decision.
It will be very difficult, and frankly impractical, for anyone working on vizia to actually test for Windows 7.
We could avoid the version constraint, but it'd just be pushing the decision down the road until the next release when something appealing comes along. Considering vizia isn't even publicly released yet, and thus doesn't have legacy usage to worry about, now seems like the best time there ever will be to set a high minimum version.


Navigation is slow (freezes on the fade-in animation) on Android with version 1.0.0

Hi,
When upgrading to the latest and final version of Angular 2 (2.0.0) and nativescript-angular (1.0.0) I started getting an issue where navigation via Router's  .navigate() method causes the navigation to be really slow (it looks like the fade-in animation gets stuck). I tested the navigation with nsRotuerLink but the issue is inconsistent when navigating forwards , on the other hand the backwards is always slow and has the described issue.
You can observe this behavior in the nativescript-ui-samples-angular repo's project, here us a direct link to the branch with the latest version.

Hi @hdeshev ,
After debugging the issue it looks like it is caused by the latest "tns-core-modules" version 2.3.0 the 2.2.1 version is ok and does not experience this issue.

Shall we move the issue to NativeScript/NativeScript then?

It looks like it yes.


Create a discord weather bot

I would like to contribute to this project as a part of @GSSOC'23.
Please assign the task to me. Thank you.

I would like to solve the issue, if any. Kindly assign me the issue as part of GSSoC'23!

assigned to @malikamujahid

assigned to @malikamujahid

can u kindly guide me a bit, where to start from?


Refactor: datanode TinyExtentDeleteRecord sync MinDeleteRecordSize ch…

Refactor: datanode TinyExtentDeleteRecord sync: MinTinyDeleteRecordSize  change to 5MB
Signed-off-by: awzhgw<EMAIL_ADDRESS>

Please format code by using goimport tool before commit.


Bug Report: Issue with Tag Generation Format

Model: GPT-4o-mini
Version: 1.131.1
Problem Description:
Tags generated by the model are not formatted as nested tags (with a slash / as instructed) but instead use an underline _ between words. While the generated tags are correct in terms of content, the format does not align with the given instructions.
Example:
Expected Format: IT/Docker
Actual Output: IT_Docker

Instructions Provided to the Model:

Generate tags that capture the main topics, themes, and type of content in the document. Focus on specific, meaningful tags that will >help with organization and retrieval.
Create Nested Tags with the following format if there is a subtype: "MainTopic/SubTopic"
Example: "theme/home"

Question:
Is this an issue with the model's output logic (bug)?
Or do I need to modify the instructions to ensure the correct tag format (e.g., nested tags with /)?

Expected Outcome:
Tags generated in the correct nested format, as per the instructions (e.g., MainTopic/SubTopic).

thx for reporting, we fixed this last week after you brought it to our attention 🙏


⚠ Remove v1alpha3 types

/test-integration

Looks good, apart these two questions:

what about this kustomization file?
and metadata yaml

I have kept those two intentionally to show the contract

I have kept those two intentionally to show the contract . Not sure if its needed to be removed.

To be honest, why do we need and what is the reason behind showing the contract, when we have removed the same thing for v1a2?

Since this was brought to today's (16.6.21) community meeting, it was proposed to have a week of lazy consensus to see if there are any objections on this change before going ahead with it.
/hold

I have kept those two intentionally to show the contract . Not sure if its needed to be removed.

To be honest, I am not getting why do we need and what is the reason behind showing the contract, when we have removed the same thing for v1a2?

The same thing like provider contract was there for v1a2? I wasnt aware of it. Anyways I ll remove it.

The same thing like provider contract was there for v1a2? I wasnt aware of it. Anyways I ll remove it.

Yes, here and here. Change on Kustomize should be just removing v1a3 most probably and could be similar to this?
commonLabels:
      cluster.x-k8s.io/v1alpha3: v1alpha4
      cluster.x-k8s.io/v1alpha4: v1alpha5

That's how other providers handling it here and here.

/test-integration

The same thing like provider contract was there for v1a2? I wasnt aware of it. Anyways I ll remove it.

Yes, here and here. Change on Kustomize should be just removing v1a3 most probably and could be similar to this?
commonLabels:
      cluster.x-k8s.io/v1alpha3: v1alpha4
      cluster.x-k8s.io/v1alpha4: v1alpha5

That's how other providers handling it here and here.

You managed to convince me :). I have removed them.

/cc @maelk

Since this was brought to today's (16.6.21) community meeting, it was proposed to have a week of lazy consensus to see if there are any objections on this change before going ahead with it.
/hold

Are we ready to merge this or we need to give more time?

/lgtm

Since this was brought to today's (16.6.21) community meeting, it was proposed to have a week of lazy consensus to see if there are any objections on this change before going ahead with it.

Considering there were no objections on this change and a week of lazy consensus has already passed, merging this.
/unhold
/approve


feat: Better Web3Modal support for the website

What does this PR do?
Chains logos for Web3Modal and WalletConnect support
Type of change

[ ] Chore
[ ] Bug fix
[X] New feature
[ ] Documentation update

Check list

[ ] Unit tests for any smart contract change
[ ] Contracts and functions are documented

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

Comparison is base (a1924be) 93.63% compared to head (717123b) 93.63%.

Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #507   +/-   ##
=======================================
  Coverage   93.63%   93.63%
=======================================
  Files          20       20
  Lines         330      330
  Branches       76       76
=======================================
  Hits          309      309
  Misses         10       10
  Partials       11       11

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


Integration 'lutron_caseta_pro' not found.

Hi,
Does this repo still work?  The latest update seems one year ago at Feb 2022.
I am trying to use this custom component since the Home Assistant build-in integration (which uses LEAP?) seems not support/cannot be triggered by wired in wall switch/dimmer button (NOT pico).
I am new to HA and I just followed the First Time Setup steps 1-3 and tried to restart HA.  Then I got this error
The system cannot restart because the configuration is not valid: Integration error: lutron_caseta_pro - Integration 'lutron_caseta_pro' not found.

Here's my file structure
├── configuration.yaml
├── custom_components
│   └── lutron_caseta_pro
│       ├── casetify.py
│       ├── cover.py
│       ├── fan.py
│       ├── __init__.py
│       ├── light.py
│       ├── manifest.json
│       ├── scene.py
│       ├── sensor.py
│       └── switch.py

And added following to configuration.yaml
lutron_caseta_pro:
    bridges:
      - host: <IP_ADDRESS>
        mac: 48:5e:aa:bb:cc

Env: Home Assistant 2022.12.1  in docker in ubuntu 20.04.
p.s. It has "version" key in custom_components/lutron_caseta_pro/manifest.json so this probably not the issue.
Any help or pointers are appreciated!

It’s working fine for me…strongly recommend using HACS to install it.

It does indeed still work and your file structure looks okay.
With that being said, this custom component uses the telnet protocol and it does not generate any events for buttons presses on dimmers or switches. The only thing you will see is the change in the light level.
This question often comes up when people are trying to add secondary functions or special tap sequences to existing dimmers or switches. In the Lutron world, you would do this by adding a pico remote. They are inexpensive, require no extra wiring and come with an adapter plate to mount directly to the wall. It only requires replacing your light switch face plate with an extra gang and you will never know there is no box behind it.
The pico remotes, particularly the 4 button (e.g. PJ2-4B-GWH-L31) and 2 button scene remotes, offer a better user experience and a world of possibilities when integrated with Home Assistant. You program the lighting scenes through the Lutron app and then use automations in Home Assistant to integrate garage doors, Zigbee bulbs, HVAC etc. and can go far beyond even the high end Lutron HomeWorks QS, which is orders of magnitude more extensive than Caseta. It may take some adjustment to start thinking of lighting in terms of scenes instead of devices, but it is well worth the effort. You can also label the pico remotes with a label maker with transparent-backed labels and it will be easy to understand for all users.

Thank you @cajuncoding for confirming and @upsert for the detailed explanation and suggestions!  Yea, I just realized that , even this repo cannot generate event for wired switch button press, by reading from other solved issues in this repo.
I think I will stick with pico or use a scene pad then.  Thanks again and closing this issue.


https://100r.co/site/work_station.html appears to be broken

:blush:

Where was that page linked from?

I believe it wa linked from here https://100r.co/site/off_the_grid.html#computers_and_software

thanks :) fixed it.


all: low hanging test coverage bump

This also adds make cover-test and make cover-web so you can get the HTML view easily.
See: https://blog.golang.org/cover

Codecov Report

Merging #23 into master will increase coverage by 3.31%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master      #23      +/-   ##
==========================================
+ Coverage   33.52%   36.84%   +3.31%
==========================================
  Files          12       12
  Lines        1375     1376       +1
==========================================
+ Hits          461      507      +46
+ Misses        826      779      -47
- Partials       88       90       +2

Impacted Files
Coverage Δ

common.go
77.55% <ø> (+8.16%)
:arrow_up:

http.go
73.33% <0%> (+22.48%)
:arrow_up:

customers.go
27.47% <0%> (+0.9%)
:arrow_up:

originators.go
34.5% <0%> (+1.4%)
:arrow_up:

gateways.go
40% <0%> (+2.1%)
:arrow_up:

transfers.go
37.89% <0%> (+2.73%)
:arrow_up:

depositories.go
29.26% <0%> (+3.48%)
:arrow_up:

sqlite.go
66.66% <0%> (+41.66%)
:arrow_up:

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 7862230...b403a3f. Read the comment docs.

I'm not sure what's up with codecov..
$ go test ./... -count 1 -cover
ok  	github.com/moov-io/paygate	0.126s	coverage: 37.8% of statements
?   	github.com/moov-io/paygate/internal/version	[no test files]
ok  	github.com/moov-io/paygate/pkg/achclient	0.057s	coverage: 80.0% of statements


[Bug]: .dc() fails to work with more than one column

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
import towhee
dc = towhee.dc(["num","val"]([[1,"one"],[2,"two"]])
Throws an error.
Fix
return DataFrame(iterable).map(lambda x: Entity(**{index: x})) -------> return DataFrame(iterable).map(lambda x: Entity(**dict(zip(index, x))))
Expected Behavior
To get a dc with two columns.
Steps To Reproduce
No response
Environment
- Towhee version(e.g. v0.1.3 or 8b23a93):
- OS(Ubuntu or CentOS):
- CPU/Memory:
- GPU:
- Others:

Anything else?
No response

@filip-halt
Could you help to verify this?
And please close it if it is fixed. Thanks.


Finder fixes

For #11521

fixed path that is saved in the cache
changed the name of the cache file
catch exception if what is saved in cache is not a string
avoid search if the kernel name is the default

Codecov Report

Merging #11525 into master will decrease coverage by 0.05%.
The diff coverage is 82.35%.

@@            Coverage Diff             @@
##           master   #11525      +/-   ##
==========================================
- Coverage   60.48%   60.43%   -0.06%
==========================================
  Files         618      618
  Lines       33739    33761      +22
  Branches     4760     4761       +1
==========================================
- Hits        20407    20402       -5
- Misses      12323    12351      +28
+ Partials     1009     1008       -1

Impacted Files
Coverage Δ

...client/datascience/kernel-launcher/kernelFinder.ts
64.60% <82.35%> (-16.78%)
:arrow_down:

src/datascience-ui/react-common/arePathsSame.ts
75.00% <0.00%> (-12.50%)
:arrow_down:

src/client/common/utils/platform.ts
64.70% <0.00%> (-11.77%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0.00%> (-2.23%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0.00%> (-1.57%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0.00%> (-0.73%)
:arrow_down:

src/client/telemetry/constants.ts
100.00% <0.00%> (ø)

...ent/interpreter/locators/services/pipEnvService.ts
84.61% <0.00%> (+1.63%)
:arrow_up:

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 0950f21...625dac3. Read the comment docs.


Migrate JSONInput to TypeScript

What does it do?

Migrates the JSONInput component to TypeScript
Upgrades react-codemirror to latest (I no longer have the bug I had before that forced me to lock the version 🤷♂ )
Adds missing peer dependencies for @uiw/react-codemirror

Why is it needed?
To gradually migrate the codebase to TypeScript
How to test it?

Make sure the input still works as expected in Storybook and Strapi (Content manager and audit logs)

For Strapi I recommend creating a build in the DS copying the dist to replace the dist in Strapi (for some reason with a link I get this error: "setTableValues must be initialized via the RawTableContext.Provider" when opening the modal for audit logs)

Check the types (I am not a TypeScript expert 🙃 )
There should be no warnings in the console for @uiw/react-codemirror peer deps

About the updates on Button and Typography components, did you make them on purpose, or is it because you had a different base branch or something like that?

After I rebased release/1.6.4 to resolve yarn conflicts I pushed and the lint test didn't pass. I'm not sure why I had that but I just ran yarn prettier:check and the yarn prettier:write since it was just a formatting diff. Does something not look right to you?


Feature yaml_files still try to load json if using leptos_i18n_router

Feature yaml_files still try to load json if using leptos_i18n_router

Woops, forgot to disable default features on the crate, will fix it asap


Scoverage Integration

Changelog

WorkflowHelper added
ci.yml regenerated
build.sbt updated

closes #416

Could we add below functionalities,

Check if we can show the coverage summary, on the checks, instead of checking the details.
Add label called coverage decrease on the PR if the coverage check fails

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/next@eaece0f). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff               @@
##             release/next     #473   +/-   ##
===============================================
  Coverage                ?   56.90%
===============================================
  Files                   ?       65
  Lines                   ?     1420
  Branches                ?       45
===============================================
  Hits                    ?      808
  Misses                  ?      612
  Partials                ?        0

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 eaece0f...a221990. Read the comment docs.

Try coveralls


Make mutating webhooks required

What this PR does / why we need it:
By accident mutating webhooks were defaulting to ignoring the webhook in
case of errors. This led to not properly defaulted VMIs which can cause
issues pretty much everywhere.
This got discovered by CI, where a failing webhook led to incomplete VMI and which could therefore never be scheduled.
In https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4795/pull-kubevirt-e2e-k8s-1.17/1349614846416523264 the service account disk did not get the disk defaulted:
                        "disks": [
                            {
                                "name": "disk0",
                                "disk": {
                                    "bus": "virtio"
                                }
                            },
                            {
                                "name": "default-disk",
                                "serial": "D23YZ9W6WA5DJ487"
                            }

which led to this xml snipped without the device being set:
		<disk device="" type="file">
			<source file="/var/run/kubevirt-private/service-account-disk/service-account.iso"></source>
			<target></target>
			<driver cache="none" io="native" name="qemu" type="raw"></driver>
			<alias name="ua-default-disk"></alias>
		</disk>

which led to this strange error:
 "message": "server error. command SyncVMI failed: \"LibvirtError(Code=67, Domain=20, Message='unsupported configuration: unknown disk device ''')\""

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
This should fix some flakes which I have seen lately, however I expect that instead of green tests we will see failing webhook calls instead, which need to be investigated next.
Release note:
Make the mutating webhooks for VMIs and VMs  required to avoid letting entities into the cluster which are not properly defaulted

/cc @davidvossel

/cc @davidvossel

/retest

/retest


Add more papers

Matt,
Here a few additions. I am currently doing a lit review, so there will be more additions. I can leave this PR open for a few weeks.

Cool, thanks @petulla!
I'll leave this open until you say otherwise

@mathisonian
Matt, this is ready when you're ready. I'll make a separate PR focused on visualizing uncertainty.

Thanks! I cut out a lot of papers I didn't think were so great. But I may be more forthcoming about uncertainty. If you'd like me to add more on any one topic, just let me know. @mathisonian


Remove destructive methods in tuple type

I think, tuple type should not have destructive methods because these methods break consistency between the interface and actual properties.

Array#push
Array#pop
Array#shift
Array#unshift
Array#splice

var t: [boolean, number];
t.shift(); // now actual t type is [number]

I'm not sure we'd be willing to take that breaking change, but there is discussion at https://github.com/Microsoft/TypeScript/issues/4988#issuecomment-145705203 regarding an alternative interface from tuple types.

@falsandtru, you might also find the following helpful, provided whole awkwardness of tuples in TypeScript:
interface T2<a, b> {
	1: a;
	2: b;
}
function t2<a, b>(one: a, another: b) : T2<a, b> {
	return <any> [one, another];
}

let pair = t2('hey', true);
let text = pair[1];
let flag = pair[2];
let problem = pair[3];

Tuples are just arrays. and thus can have these methods. at least this is the current design. @aleksey-bykov's answer should allow you to limit your tuples to a more strict subset.


Feature requests

Server should send a message to all clients when a channel is created
Server should send a message to a channel when a user joins or parts
when a user sends a message to a channel, the server should send the message to all users in the channel, including the author

on 3, why including the author?

so that the message will show up in the chatlog of the author. currently to do this, the client would need to send the message to itself (timestamping it, formating it to the server message protocol, etc). The server already does all this, no reason to be redundant

ok

If you get some time can you split this into 3 separate issues? It will help with organization. If you don't i can do it later.

yeah sure

created #6 #7 and #8


Make swatch background/text reactive to their partner.

I assume this will require some javascript magic to identify when something has too little contrast.

I'm not sure I can guarantee that this returns >= 0  and <= 255, but otherwise it works.
<?php
////	Get Brightness
// Returns a brightness value from 0 to 255
// for a given 6-digit hexadecimal color string
function get_brightness(string $hex): number {
	// strip off any leading #
	$hex = str_replace('#', '', $hex);
	$c_r = hexdec(substr($hex, 0, 2));
	$c_g = hexdec(substr($hex, 2, 2));
	$c_b = hexdec(substr($hex, 4, 2));
	return ( ($c_r * 299) + ($c_g * 587) + ($c_b * 114) ) / 1000;
}


⚠ ClamAV has degraded performance

In 0d7867e, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 422 ms

Resolved: ClamAV performance has improved in 9048397.


THORN-2064, update to use smallrye-jwt 1.1.0 implementation

[x] Have you followed the guidelines in our Contributing document?
[x] [v2] Have you created a JIRA and used it in the commit message?
[x ] Have you checked to ensure there aren't other open Pull Requests for the same issue?
[x] Have you built the project locally prior to submission with mvn clean install?

I've done a couple of comments, it looks good from my non-expert point of view. I'd like to ask Ladislav to give it a good look as well :-), and then I'll merge

Is this ready for integration?

Added a couple of small comments. Also a full CI build would be nice.

retest this please

How is this progressing @starksm64?

I'm trying to track down what is causing the tests to not even start up. Some dependency looks to be missing as the swarm.application module is not being loaded.
Sun Jul 15 23:07:26 PDT 2018 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO.
java.lang.ClassNotFoundException: org.wildfly.swarm.arquillian.adapter.AnnotationBasedMain
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.wildfly.swarm.bootstrap.MainInvoker.getMainClass(MainInvoker.java:117)
	at org.wildfly.swarm.bootstrap.MainInvoker.<init>(MainInvoker.java:49)
	at org.wildfly.swarm.bootstrap.Main.run(Main.java:131)
	at org.wildfly.swarm.bootstrap.Main.main(Main.java:85)
Exception in thread "main" java.lang.ClassNotFoundException: org.wildfly.swarm.arquillian.adapter.AnnotationBasedMain
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.wildfly.swarm.bootstrap.MainInvoker.getMainClass(MainInvoker.java:117)
	at org.wildfly.swarm.bootstrap.MainInvoker.<init>(MainInvoker.java:49)
	at org.wildfly.swarm.bootstrap.Main.run(Main.java:131)
	at org.wildfly.swarm.bootstrap.Main.main(Main.java:85)

Maybe try rebasing onto the latest, as there may have been a change somewhere that is causing an issue?
io.thorntail:arquillian is definitely in the pom of the testsuite, so only thing I can think is for some reason it's not looking for that one?

I had merged the upstream changes previously, and remerged them yesterday.
The issue was some problem with the org.wildfly.swarm.configuration.microprofile.config module not be resolved despite there being a dependency on the io.thorntail:config fraction. I ended up copying the metrics fraction dependencies as that seemed to worked.

Looks like CI is all good.
I started taking a look at the changes to review and it looks like the rebase went funny, as there are changes in /docs and other places that I wouldn't expect as part of this PR. Could you take a look?

I'll redo the PR at this point because things seem strange between my local repo, origin and upstream.


Real Boxing 3D - crash

Build version:
Latest
Game version:
1.0.1 [R]
Game resolution:
176x220
Device model:
Realme 9 pro+
Android version:
12
Description of the issue:
When i play game immediately crash.
https://user-images.githubusercontent.com/81209454/172134496-f25f7d1f-1489-483d-a193-7dcbbb3b3bb3.mp4
Log
log.txt
Crash log
crash.txt

It is necessary to limit the FPS.
The problem due to too high speed of the game.

Oh, but game only work with 30fps limit otherwise  it will crash. 30fps is very slow speed🥺

Moreover, you need to choose the FPS that was on the target device - otherwise the animations do not work correctly (animation frames are designed for a certain frame rate).

Thank you!😀, I will do that!

Here JL-Mod compatibility list, I hope it will be useful for you.
[Mascot Capsule 3D compatibility list


Code readability improve and used switch over if conditional

@alanchiao Could you PTAL and approve.

Can one of the admins verify this patch?

@Dayananda-V Can you please resolve conflicts? Thanks!

I'm going to go ahead and close this PR, because it seems to have stalled. If you're still interested in pursing this (and responding to my comments), please feel free to reopen!


chore: release main

:robot: I have created a release *beep* *boop*
@opentelemetry/auto-instrumentations-node: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-dns bumped from ^0.26.0 to ^0.27.0
@opentelemetry/instrumentation-express bumped from ^0.26.0 to ^0.27.0
@opentelemetry/instrumentation-graphql bumped from ^0.26.1 to ^0.27.0
@opentelemetry/instrumentation-ioredis bumped from ^0.26.0 to ^0.27.0
@opentelemetry/instrumentation-koa bumped from ^0.27.0 to ^0.28.0
@opentelemetry/instrumentation-mongodb bumped from ^0.26.0 to ^0.27.0
@opentelemetry/instrumentation-mysql bumped from ^0.26.0 to ^0.27.0
@opentelemetry/instrumentation-pg bumped from ^0.26.0 to ^0.27.0
@opentelemetry/instrumentation-redis bumped from ^0.26.0 to ^0.27.0

@opentelemetry/auto-instrumentations-web: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-document-load bumped from ^0.26.0 to ^0.27.0
@opentelemetry/instrumentation-user-interaction bumped from ^0.26.0 to ^0.27.0

@opentelemetry/browser-extension-autoinjection: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-document-load bumped from ^0.26.0 to ^0.27.0

@opentelemetry/contrib-test-utils: 0.28.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-aws-lambda: 0.28.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-aws-sdk: 0.4.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-bunyan: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-cassandra-driver: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-connect: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-dns: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-express: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-generic-pool: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-graphql: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-hapi: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-ioredis: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-knex: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-koa: 0.28.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-memcached: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-mongodb: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-mysql: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-mysql2: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-nestjs-core: 0.28.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-net: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-pg: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-pino: 0.28.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-redis: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/instrumentation-restify: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-router: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-winston: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-document-load: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/instrumentation-user-interaction: 0.27.0
Features

use latest instrumentation base (#769) (7aff23e)

@opentelemetry/resource-detector-alibaba-cloud: 0.26.1
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/resource-detector-aws: 1.0.2
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

@opentelemetry/resource-detector-gcp: 0.26.1
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.27.0 to ^0.28.0

This PR was generated with Release Please. See documentation.

@dyladan does the bot rebase automatically ? I'm not sure i'm supposed to merge the branch or not ?

@vmarchaud when the branch is merged the release is done automatically. merging is a manual step required so that we can look at the PR and ensure it is what we want before we merge

In the future, we may be able to automate the merge of this PR once a maintainer approves or something. for now i think the manual step is ok

:robot: Release for @opentelemetry/resource-detector-alibaba-cloud is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-alibaba-cloud-v0.26.1 :sunflower:

:robot: Release for @opentelemetry/resource-detector-aws is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-aws-v1.0.2 :sunflower:

:robot: Release for @opentelemetry/resource-detector-gcp is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-gcp-v0.26.1 :sunflower:

:robot: Release for @opentelemetry/auto-instrumentations-node is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-node-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/auto-instrumentations-web is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-web-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/browser-extension-autoinjection is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/browser-extension-autoinjection-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/contrib-test-utils is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/contrib-test-utils-v0.28.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-aws-lambda is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-lambda-v0.28.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-aws-sdk is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-sdk-v0.4.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-bunyan is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-bunyan-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-cassandra-driver is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-cassandra-driver-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-connect is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-connect-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-dns is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-dns-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-express is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-express-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-generic-pool is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-generic-pool-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-graphql is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-graphql-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-hapi is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-hapi-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-ioredis is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-ioredis-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-knex is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-knex-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-koa is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-koa-v0.28.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-memcached is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-memcached-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-mongodb is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongodb-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-mysql is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mysql-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-mysql2 is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mysql2-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-nestjs-core is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-nestjs-core-v0.28.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-net is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-net-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-pg is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-pg-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-pino is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-pino-v0.28.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-redis is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-redis-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-restify is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-restify-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-router is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-router-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-winston is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-winston-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-document-load is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-document-load-v0.27.0 :sunflower:

:robot: Release for @opentelemetry/instrumentation-user-interaction is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-user-interaction-v0.27.0 :sunflower:


Releasing version 2.0.4?

Hi,
The lastest release was made in September 2023. There's been a bug fix since and no new releases.
Could you please make a new release?
We need gps_msgs for Space ROS, which we are releasing in a few days (tomorrow is our build day), so it'd be great to depend on a version that includes the very latest bug fixes. Thanks!

I'm not sure, but gps_msgs is in the package.xml for the packages in this repo. Can you be more specific about what's going on?

The last release of this package was made in September 2023. There is a tag 2.0.3 with that date.
A new bug fix has been included since then. It's also been quite a long time.
Would the maintainers be able to make a release 2.0.4 that includes that change?
It would help packages that depend on gps_msgs depend on a specific version, instead of depending on a moving HEAD or a commit hash (which is not a great version number).

2.0.4 is released, and bloomed for Rolling, Iron, and Humble.


Compile fix for Windows provided by UsernameIsAReservedWord

Forgot to add the new function to the header, sorry.

This has been fixed already (no idea why GH doesn't see a merge conflict as your commit adds a string which is already present in master, but hey).


Error: Overflow of Theme Toggling Button

https://github.com/user-attachments/assets/5ac6f05e-4ba5-4573-ad0f-5dcf0f2b77eb
I cant see it over flowing can you tell me how to reproduce what you have mentioned

Blogs.-.Google.Chrome.2024-10-17.22-15-15.mp4
I cant see it over flowing can you tell me how to reproduce what you have mentioned @Shariq2003

https://github.com/user-attachments/assets/8a5025db-1bd7-4585-9f88-661e1b4c5fef
Look in this, its showing here, in my laptop, even though in the deployment of the website too.

@HimangshuSharma01 Sorry, actually my branch was 2 commits behind

@HimangshuSharma01 Sorry, actually my branch was 2 commits behind

👍


Dump threads when network fails to start in order to find the blockin…

…g thread.
@bratseth or @bjorncs or @jonmv PR

Nice. I wonder if this could help with some unit tests that also fail with this error occasionally, if those weren't already fixed.


Smoke test: Flaky Multiroot - shows results from all folders

This specific test is failing more often than not, on macOS. It failed on every single red cross in the screenshot below. The location test also failed, but let's fix this one first to see if that also fixes the localization test. cc @dbaeumer
It's surprising that it succeeds sometimes. What's especially strange is that an exception still appears in the logs, even when it succeeds.

@TylerLeonhardt related to recent changes maybe? The smoke test looks for this:
Error: Active element not found. Current active element is 'HTML > BODY.mac > DIV.file-icons-enabled.monaco-workbench.mac.chromium.nopanel.vs-dark.vscode-theme-defaults-themes-dark_plus-json > DIV.monaco-grid-view > DIV.monaco-grid-branch-node > DIV.monaco-split-view2.vertical > DIV.monaco-scrollable-element.mac > DIV.split-view-container > DIV.split-view-view.visible > DIV.monaco-grid-branch-node > DIV.monaco-split-view2.horizontal > DIV.monaco-scrollable-element.mac > DIV.split-view-container > DIV.split-view-view.visible > DIV.monaco-grid-branch-node > DIV.monaco-split-view2.vertical > DIV.monaco-scrollable-element.mac > DIV.split-view-container > DIV.split-view-view.visible > DIV#workbench.parts.editor.part.editor.has-watermark > DIV.content > DIV.grid-view-container > DIV.monaco-grid-view > DIV.monaco-grid-branch-node > DIV.monaco-split-view2.vertical.separator-border > DIV.monaco-scrollable-element.mac > DIV.split-view-container > DIV.split-view-view.visible > DIV.editor-group-container.active > DIV.editor-container > DIV.editor-instance > DIV.gettingStartedContainer.width-semi-constrained.animationReady'. **Looking for .quick-input-widget .quick-input-box input**

Wait, this smells:
gettingStartedContainer.width-semi-constrained.animationReady

@JacksonKearl ?

Maybe related to https://github.com/microsoft/vscode/issues/122317

I wonder what's different between Linux/Windows and macOS, which makes the latter fail very often.

Startup editor is now empty, via https://github.com/microsoft/vscode-smoketest-express/commit/a65be2a6b5b65536550e901b7ea33b384d73ff63 and https://github.com/microsoft/vscode/commit/4cda850edf57f244260b7b534cbb8d7c3717f58a
I suspect we run some random getting started experiment only in built form.

Thanks, we could also disable experiments entirely, "workbench.enableExperiments": false

👍  pushed that too.


[Telemetry-Otel] Added support for OtlpGrpcSpanExporter exporter

Description
Added support for OtlpGrpcSpanExporter. OtelSpanExporterFactory expects exporter has method create() (For details link) OtlpGrpcSpanExporterProvider creates an instance of OtlpGrpcSpanExporter with https endpoint.
Related Issues
Resolves #[Issue number to be closed when this PR is merged]

Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@reta @shwetathareja @Gaganjuneja Please review.

Add test cases in OTelSpanExporterFactoryTests and for the provider if needed.

@reta @shwetathareja @Gaganjuneja Please review.

@Shephalimittal apologies, I do not have time left this week to review it, but will pick it up next week first thing

Waiting for gradle check to fix, before merging the PR

@Shephalimittal my sincere apologies for the delay, I was confused how this implementation supposed to work in general (it looked to me like we are missing dependencies) but it is cleared out now: we use pretty old Otel version 1.26.0 whereas the latest release is 1.29.0.
The OtlpGrpcSpanExporter has been refactored to use the service discovery mechanism instead of bundling the OkHttp based span exported by default. I think we should bring our dependencies up to date, I will send over the pull request shortly.

@Shephalimittal my sincere apologies for the delay, I was confused how this implementation supposed to work in general (it looked to me like we are missing dependencies) but it is cleared out now: we use pretty old Otel version 1.26.0 whereas the latest release is 1.29.0.
The OtlpGrpcSpanExporter has been refactored to use the service discovery mechanism instead of bundling the OkHttp based span exported by default. I think we should bring our dependencies up to date, I will send over the pull request shortly.

@reta I have removed the wrapper over OTLPGrpcSpanExporter here and added support to use it with default implementation instead of configuring it through settings. We need some basic support of exporter for testing and visualising spans for adding instrumentations in various code paths. We can incrementally provide support for adding configurable settings in exporter.

We need some basic support of exporter for testing and visualising spans for adding instrumentations in various code paths. We can incrementally provide support for adding configurable settings in exporter.

@Shephalimittal sure, please rebase, the change needs adjustment for Otel Java Sdk 1.30.1

Thank you @Shephalimittal !


Rework how the 3D editor viewport's resolution scale is changed

Removed the Half Resolution per-viewport setting in favor of an editor setting that applies to all 3D viewports in all projects.
Use an automatic rendering scale by default that's set to 100% on loDPI displays and 50% on hiDPI displays (editor scale >= 1.667).
Add 25% and 33% scaling options in the Editor Settings. This is useful for low-end hardware with hiDPI displays (such as 4K laptops).

The rendering scale is updated when the editor setting changes, so no restart is required to apply rendering scale changes (as before).
This pull request can be remade for the 3.2 branch if we agree on this one.
This closes https://github.com/godotengine/godot-proposals/issues/2125.

I agree with this PR but it looks that the main concern is about hiDPI displays,
I have a laptops that has 3000x2000 resolution and an Nvidia 940m. I use to connect an external FullHD monitor, and always I am facing that 1920x1080 is too much for my laptop with the viewport at 100% but 50% looks very bad.
Therefore I would like to have the 75% option, in my case there is no use case either 33% nor 25%.
On the other hand I like a lot how Unreal has a 0-100% parameter that you can tweak according to your need.
Why we don't expose to the viewport the project-settings option "Shrink":
Under display/window/stretch/shrink
Or maybe a 0-100% viewport resolution scale

Therefore I would like to have the 75% option, in my case there is no use case either 33% nor 25% because I set a low resolution in my system.

A 75% option requires linear filtering to look correct, and this option isn't available yet in Godot.


webmock doesn't play nice with MiniTest hooks

I'm using webmocks to replace expensive calls to Facebook to create test users. I  was previously using Minitest-hooks (https://github.com/jeremyevans/minitest-hooks) to do the creation in before_all and deletion in after_all blocks. However, webmock/minitest.rb monkey patches MiniTest's teardown causing code in after_all to fail.
I'm looking for the best way to manually control when webmock calls reset!.

was able to get this working by adding this to the bottom of my projects test/test_helper.rb
ActiveSupport::TestCase.class_eval do
  alias_method :teardown, :teardown_without_webmock
  alias_method :after_all_without_webmock, :after_all

  def after_all_with_webmock
    after_all_without_webmock
    WebMock.reset!
  end

  alias_method :after_all, :after_all_with_webmock
end

Hi @kwasimensah ,
Do you need further help on this or we can close this issue?

Oh, haven't looked at this in a while. I believe my code still has the monkey patch. Are you asking if it works without that?

@kwasimensah do you have any suggestions on how to change https://github.com/bblimke/webmock/blob/master/lib/webmock/minitest.rb in order to support minitest hooks?

Facing this very same issue, with Rails 7, minitest 5.18.0 and minitest-hooks 1.5.0 and webmock 318.1
I guess the problem nowadays lies in the fact we run the tests in separate threads, so the "mocks" are not available in the running threads.


Remove deprecated functions and warnings that came with elixir 1.6

The deprecated functions are in the core elixir and phoenix.


Proposal: Use Node's native coverage when available or specified

Expected Behavior

nyc node test.js should work when test.js imports ES6 modules

Likewise nyc mocha and other similarly invoked test frameworks should work when the tests import ES6 modules.

Be able to generate coverage using tsc transpiled Typescript (or any other transpiler for that matter) rather than requiring the use of ts-node and --require ts-node/register.

Simpler
Does not force people with already established use of tsc to figure out how to also integrate ts-node into their builds just to get test coverage reports.
ts-node does not support ES6 modules.

Tools that integrate with nyc/Istanbul such as Webstorm inherit all of the above automatically.

nyc I believe was supposed to make Istanbul use simple and "just work". In at least the above cases, and possible many others, @bcoe's c8's use of Node's built-in coverage reporting fulfills that promise far better.
Observed Behavior
Empty coverage reports (a few lines all zeros) or errors.
Troubleshooting steps
I'll not try to remember and record the day and a half of trial and error after error here because I've learned that this is a known issue, though I'm not sure if it's a ts-node problem or an nyc limitation (because it can't hook into into imports like it does require?)
I did confirm nyc is able to instrument the files using nyc instrument.
Then by chance on the Istanbul homepage I saw:

Like nyc, c8 just magically works:
npm i c8 -g
c8 node foo.js

I installed c8 and boom, it worked instantly, and yes, magically. Whether running a homemade test.js, Mocha based-tests, or even non-test code. No special nyc configuration for Typescript (it automatically picked up the source-maps), no need to install ts-node and inject it into the mocha command line (--require ts-node/register).
But only on the command line. I use Webstorm, which has specific integrations with nyc and so does not pick up the coverage report from c8 even though it reports using the same Istanbul's reporters Webstorm reads.
Proposal
Merge c8 into nyc, or have nyc wrap c8 and it's original code, so that all tools that work with nyc will transparently benefit from the optional improved compatibility of Node's native coverage instrumentation.
I can wait and hope the Webstorm folks integrate with C8. But in my above hunt for a solution I've come across many other people in other situations whose woes I suspect would disappear if Node's native functionality were leveraged, either optionally or automatically.
Environment Information

  System:
    OS: macOS 10.15.5
    CPU: (4) x64 Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz
    Memory: 81.98 MB / 8.00 GB
  Binaries:
    Node: 14.8.0 - /usr/local/bin/node
    npm: 6.14.8 - /usr/local/bin/npm
  npmPackages:
    eslint-plugin-babel: ^5.3.1 => 5.3.1
    source-map-support: ^0.5.19 => 0.5.19
    typescript: ^4.0.2 => 4.0.2

@bcoe I would very much appreciate your thoughts on this.

Please see @istanbuljs/esm-loader-hook.  This adds the ability to get experimental support for Node.js ES modules to nyc.  The situation with this additional module will only improve, in particular it relies on functionality which is flagged as experimental by Node.js itself.
At this time I have not considered integrating c8 into nyc.  There are a few issues I have with the node native coverage (really issues with v8) which lead me to think that both projects have a place.  In particular v8 native coverage sometimes does not detect all branches and it does report per-statement coverage.

Thanks for the reply.  Ok. I gave the esm-loader-hook a shot. It works if I invoke it directly on some JS:
npx cross-env 'NODE_OPTIONS=--experimental-loader @istanbuljs/esm-loader-hook' nyc test/test.js

But invoking it on mocha exactly as directed by the esm-loader-hook instructions produces:
$ npx cross-env 'NODE_OPTIONS=--experimental-loader @istanbuljs/esm-loader-hook' nyc mocha
(node:12502) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:12503) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
internal/process/esm_loader.js:74
    internalBinding('errors').triggerUncaughtException(
                              ^

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension "" for /Users/vas/Repos/projects/TextPlainly/TextPlain.js/node_modules/mocha/bin/mocha
    at Loader.defaultGetFormat [as _getFormat] (internal/modules/esm/get_format.js:65:15)
    at Loader.getFormat (internal/modules/esm/loader.js:101:42)
    at Loader.getModuleJob (internal/modules/esm/loader.js:230:31)
    at async Loader.import (internal/modules/esm/loader.js:164:17)
    at async Object.loadESM (internal/process/esm_loader.js:68:5) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}
----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |       0 |        0 |       0 |       0 |
----------|---------|----------|---------|---------|-------------------

Also, feel free to close this issue if you wish.

@vassudanagunta I think the issue you saw with Unknown file extension "" may have been a bug in specific versions of node.js.  Maybe try again with current version of 14.x or 15.x?  Keep in mind this is all experimental so issues like this are expected from time to time.
Another thought mocha says it supports all node flags which are supported by the current version of node, maybe you could try:
npx nyc mocha --experimental-loader=@istanbuljs/esm-loader-hook

c8 is a great tool but it is a separate project.  I'm going to close this issue as nyc will not be merging with c8, both tools have their place and in some niche cases c8 might not be best (likewise in some niche cases nyc is not best).  I think the current situation is best where package maintainers choose which tool is best for their usage.

@coreyfarrell, sorry for my not following up earlier. I've been occupied by other things in these crazy times.

Another thought mocha says it supports all node flags which are supported by the current version of node, maybe you could try:
npx nyc mocha --experimental-loader=@istanbuljs/esm-loader-hook

This works!  Thank you!

@istanbuljs/esm-loader-hook no longer works in Node.js ≥ 16.12.0 due to an incompatible change in the experimental ESM loader hook API (istanbuljs/esm-loader-hook#6).


how to set eval_set and eval_group when fitting the XGBRanker model?

I'm not understand the state of eval_group in fit function that

A list that contains the group size corresponds to each (X, y) pair in eval_set.

When I set eval_set to be list of (X, y) pair, eval_group to be the list of length of each group, return Error: the length of eval_set must be match with the length of eval_group.
But when I set eval_set to be list of (X, y)pair where X and y is one group of X and y, it also does not work.

Take a look at the demo here. In particular, pay attention to the lines
https://github.com/dmlc/xgboost/blob/986fee60229c77920e93ae3b374c2e674faee78d/demo/rank/rank_sklearn.py#L33-L34

Take a look at the demo here. In particular, pay attention to the lines
https://github.com/dmlc/xgboost/blob/986fee60229c77920e93ae3b374c2e674faee78d/demo/rank/rank_sklearn.py#L33-L34

Thank you for you replay!
And I have one more question. How to set eval_set and eval_group when I want to useing RandomizedSearchCV. I want to train a lamdbamart ranking model.


Having two DetectedEntity doesn't work

Within the same outlook web addin, I'm trying to add two different contextual detection with different regular expression. (each RegEx rules match will have it's own source location.)
However, it doesn't work.
I was wondering if it's a limitation. If not, could you please provide any example to have more than 1 DetectedEntity?

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

ID: 06e092f1-aa6a-45b5-50ce-a1afca772776
Version Independent ID: fa9c31b7-b63a-9867-f298-4d579b899c30
Content: ExtensionPoint element
Content Source: docs/reference/manifest/extensionpoint.md
Product: office 365
GitHub Login: @o365devx
Microsoft Alias: o365devx

@Vivihung can you please post this question to Stack Overflow, tagged with the office-js tag and the outlook-web-addins tag? By posting how-to questions such as this one to Stack Overflow, you're not only more likely to get a response, but that response may also benefit other developers who might be facing the same challenges. When you post the question to Stack Overflow, be sure to include code that shows what you've tried, along with a detailed description of the outcome that your code produces (i.e., something more specific than "it doesn't work"). Thanks!

Posted here:
https://stackoverflow.com/questions/53074478/outlook-web-add-in-having-two-detectedentity-doesnt-work-for-contextual-detect