Update LOCALIZATION_CONTRIBUTORS

Adding myself to the Spanish-Mexico localization list

Summary
Details and comments

 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.

 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.

Thank you for your interest in contributing to Qiskit translations! I'm not seeing your request to join the Qiskit Translation Project on Crowdin. Please follow steps 4 and 5 in the Contributing to Qiskit documentation to register for an account and submit your request.

 All committers have signed the CLA.

 All committers have signed the CLA.

Can you please move this PR here: https://github.com/Qiskit/qiskit-translations


Update metadata: Flameshot.Flameshot 0.10.1

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] 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.0 schema?

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

Microsoft Reviewers: Open in CodeFlow

Yay! I could now help in merging the PR which are already "Moderator-Approved".

The bot is acting really weird tbh, i've seen a few which is stuck like this for a few hours, and if someone Approves it moves straight to merge, hopefully they find the issues this week instead of leaving it broken like last week...


[Bug] Unable to publish an Asset Details page

When I try to publish an Asset Details page I receive an "ERROR Failed to retrieve references for the selected page." message, and the page is not published.
Here's a screenshot of the message:

The only way I can currently publish Asset Details pages is to use the Replication -> Activate Tree functionality.

@artdirk  - I think the problem is the placeholder image has a replication status of Activated but no cq:lastReplicated property (which will throw a NPE at this point). Let me take a look at that placeholder.jpeg we ship.

@artdirk i should have fixed it in the PR above; however you might be able to work around it by just activating the Asset Details template.

Thanks for looking into this and implementing a fix so quickly, @davidjgonzalez!

Closed in v1.2.0's ui.content


[NEAT-302] [NEAT-301] test issue

description
From SyncLinear.com | NEAT-301
From SyncLinear.com | NEAT-301

test comment


Gate tests on a CMake variable

... instead of being an excluded target.

Like this one.
-DCNL_TEST
While you're there, clean up all the other cmake .. -LH names so they start with CNL_.


dodo-objection: update to use objection version latest

objection is given as peer dep and should work with all alphas, rc, beta etc. versions after 0.3.2, dodo core 0.0.5 is required because of logging feature.


Add visual regression tests for typesetting libraries

We may want to add tests to check if typesetting libraries (like derive, code2, ... etc) work properly.
My current idea is to leverage existing tools for front-end development as a first step:

jest-image-snapshot
reg-suit

Current progress is in visual-regression-test branch


kube-state-metrics installation for lens metrics is missing PSP

Describe the bug
Installing kube-state-metrics via Cluster -> Settings -> Features -> Metrics -> Install fails because it does not install Pod Security Policies. I mean, the install in the UI itself succeeds, but the end result of having kube-state-metrics running fails because of PSP.
To Reproduce
Steps to reproduce the behavior:

Have cluster that enforces PSP
Install metrics
Observe how pods are not running because of PSP violations (missing)

Expected behavior
Pods start OK with PSP.
Environment (please complete the following information):

Lens Version: 2.1.3
OS: Mojave
Download from website

Why isn't the Lens Metrics installation done through Helm or provide any way to change the values?  It is very confusing.  I want to set up the Metrics without persistent volumes, and there is no way to change the variable persistance.enabled to false from the Settings menu?

You can install Prometheus through Helm and use that with Lens. Lens should auto-detect the prometheus installation and use it out-of-the box.

Can we adjust the config (https://github.com/lensapp/lens/tree/master/src/features/metrics) on an installation?
I see where's it's located on the installation, i.e. my local copy of the config, but can I extend it with more files - i.e. does the installer simply list the files and apply each that it finds? i.e. I could juts add 07-me.yml to apply it?
If not I could just edit whats there to add the PSPs I need.


mediumroast_js: implement find_by_x in gitHubServer.js

Introduction
Implement find_by_x and find_by_name for the general case to ensure the user can filter outputs with specific focus on what they are looking to see.  Note that find_by_name is just a special implementation in the API for find_by_x where the attribute is name and the value is the name of the object in question.
Specific tasks

[x] Implement find_by_x
[x] Implement find_by_name
[x] Uncomment and enable both in mrcli-company
[x] Uncomment and enable both in mrcli-study
[x] Uncomment and enable both in mrcli-interaction
[x] Uncomment and enable both in mrcli-user

Implementation notes

It may be possible to implement in mrcli-user, additional investigation is needed to confirm if this will or will not work.  If it works then hopefully the implementation will be the same for the user CLI, but that remains to be seen.
For interactions we will want a special implementation for find_by_status which will help us as we are trying to reset the status of particular types of interactions.  This will help with an iterative test with caffeine as we are testing different LLMs with differing interaction types. UPDATE: By implementing a specific instance of find_by_x and get_by_name in the Users class this was feasible.

Status
This is now ready for testing.

@jgoodie and @miha42-github were able to test this capability in the CLI


[SPARK-17693] [SQL] [BACKPORT-2.0] Fixed Insert Failure To Data Source Tables when the Schema has the Comment Field

What changes were proposed in this pull request?
This PR is to backport the fix https://github.com/apache/spark/pull/15615 to 2.0.
CREATE TABLE tab1(col1 int COMMENT 'a', col2 int) USING parquet
INSERT INTO TABLE tab1 SELECT 1, 2

The insert attempt will fail if the target table has a column with comments. The error is strange to the external users:
assertion failed: No plan for InsertIntoTable Relation[col1#15,col2#16] parquet, false, false
+- Project [1 AS col1#19, 2 AS col2#20]
   +- OneRowRelation$

This PR is to fix the above bug by checking the metadata when comparing the schema between the table and the query. If not matched, we also copy the metadata. This is an alternative to https://github.com/apache/spark/pull/15266
How was this patch tested?
Added a test case

Test build #68189 has started for PR 15782 at commit 2b96c1a.

LGTM pending Jenkins.

Test build #68189 has finished for PR 15782 at commit 2b96c1a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/68189/
Test PASSed.

Merged build finished. Test PASSed.

LGTM. Merging to 2.0. Thanks!
Can you close?

Thanks!


Memory leak in adapter

From @zautrix on March 31, 2017 15:42
In Version 0.24 - 0.27.
File
/opt/iobroker/node_modules/iobroker.lightify/node_modules/node-lightify-soef/index.js
Line 43: Definition of global var array :
var commands = [];
Line 105: Any sent command is stored in this array:
commands.push(cmd);
Memory is never released.
There is some code which removes data from commands, but this does not work on my system:
    client.on('data', function(data) {
        var seq = data.readUInt32LE(4);
        for(var i = 0; i < commands.length; i++) {
            if(commands[i].seq === seq) {
                if(!commands[i].processer || !commands[i].processer(commands[i], data)) {
                    commands.splice(i, 1);
                }
                break;
            }
        }
    });

Result is that adapter is consuming more and more memory.
I fixed it on my system by adding a pop before the push:
    commands.pop();
    commands.push(cmd);

Copied from original issue: soef/ioBroker.lightify#4

From @GermanBluefox on June 15, 2017 19:44
Should be fixed with my pull request:
https://github.com/soef/ioBroker.lightify/pull/8


Revert "fix: setup-metabase script"

Reverts mission-apprentissage/bal#265

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

v1.54.2
GitHub release

Your semantic-release bot :package::rocket:


Ensure that an already-enrolled Validator starts to validate immediately

As a validator, it is possible that I would boot up when already enrolled (e.g. if the node is a back-up node for another node).
We should have a test that:

Starts a network with a few nodes;
Has one node enrolled that is stopped and wiped clean;
Wait at least 2 blocks;
Restart the node, verify that it catches up, and starts to validate again;

Wait at least 2 blocks;

If a Validator is offline while 2 blocks are externalized, doesn't that imply that the Validator will be slashed? Therefore this Validator shouldn't be able to validate again when it catches up.

Wait at least 2 blocks;

If a Validator is offline while 2 blocks are externalized, doesn't that imply that the Validator will be slashed? Therefore this Validator shouldn't be able to validate again when it catches up.

Right, I see what you mean. I'll modify the code of the PR #1110 accordingly.


Authentication & Security Model

Can you describe your authentication & security model somewhere?
How is ACL implemented?
From what I can tell:

You install Ledokku over Dokku, granting the ledokku user unlimited access to your Dokku instance.
Anyone can create a Ledokku account, as long as they have a GitHub username to SSO w/ GitHub.
Everyone who has access to GitHub and discovers the Ledokku service is running can read a list of apps and read all of their environment variables, and create an unlimited number of empty databases and apps.

@kidGodzilla we will add it to the documentation, that's a good question.

You install Ledokku over Dokku, granting the ledokku user unlimited access to your Dokku instance.

Indeed, if you want to be able to manage your apps and dbs imho there is no other way.

Anyone can create a Ledokku account, as long as they have a GitHub username to SSO w/ GitHub.

This is true, but in the current version of the project we only allow one user to signup, meaning that if another person tries to login via Github on your instance he will get rejected. Later we plan to let you invite more users and maybe do some team/role management for the apps.

Everyone who has access to GitHub and discovers the Ledokku service is running can read a list of apps and read all of their environment variables, and create an unlimited number of empty databases and apps.

As the API is secured via JWT, only a logged in user can actually do this. And as said earlier only one user is allowed per server for now to mitigate this risk :)
Regarding the security itself, the HTTP and WS connections are secured using a JWT. The JWT secret is generated randomly when you install ledokku on your server.

Got it! we only allow one user to signup was the missing piece

We will write some documentation to make it clear, thanks for raising this point 👍


Fix task cannot use workflow's environment

Purpose of the pull request
close https://github.com/apache/dolphinscheduler/issues/16191
Brief change log

Add EnvironmentUtils and WorkerGroupUtils to judge whether the environment and workergroup is empty

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
Pull Request Notice
Pull Request Notice
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

Codecov Report
Attention: Patch coverage is 24.24242% with 25 lines in your changes missing coverage. Please review.

Project coverage is 40.99%.

Files
Patch %
Lines

.../server/master/runner/WorkflowExecuteRunnable.java
0.00%
9 Missing :warning:

...e/dolphinscheduler/dao/utils/EnvironmentUtils.java
0.00%
5 Missing :warning:

...erver/master/runner/StreamTaskExecuteRunnable.java
0.00%
4 Missing :warning:

...e/dolphinscheduler/dao/utils/WorkerGroupUtils.java
25.00%
3 Missing :warning:

...uler/server/master/registry/ServerNodeManager.java
0.00%
3 Missing :warning:

...cheduler/scheduler/quartz/ProcessScheduleTask.java
0.00%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##                dev   #16199      +/-   ##
============================================
- Coverage     41.00%   40.99%   -0.02%
+ Complexity     5148     5144       -4
============================================
  Files          1399     1400       +1
  Lines         44877    44828      -49
  Branches       4759     4723      -36
============================================
- Hits          18404    18375      -29
+ Misses        24665    24646      -19
+ Partials       1808     1807       -1

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


[Question] How to use zmq for this?

I'm working on an app with multiple proccesses which need to transfer data between some of them and the main process needs to signal the worker processes to exit. Which solution would be the best using zmq?
I've read through the docs, but still not sure. For example the conection between main and worker_1: do i need

context in main with one socket PUB and one socket SUB,
context in worker_1 with one socket SUB and one socket PUB or
context in main with PUB/SUB socket in main and worker_1

Please, can someone give me advise how to accomplish the below:

It is pretty complicated to advise something in particular without knowing your exact requirements, in other words there are plenty of manners to implement 'working solutions' according to what you mentionned above.
I'd rather suggest to read specific parts of the documentation to be able to design it with accuracy.
You need to understand the differences between the different socket types (REQ/REP, DEALER/ROUTER, PUB/SUB, PUSH/PULL, PAIR) each one taking part in a specific messaging pattern and thus implementing specific behaviors.
Examples of questions you could tackle from there would be "Do I need synchronous or asynchronous communication?", "If one of my processes has several listeners, should the messages it send be duplicated for each listener or only be pulled once by one of them" etc.
This design step takes time, but from there the implementation should be straightforward.
Finally, to answer your specific question about how to connect your main process with worker 1, you could go for:

one PUB socket in your main
one SUB socket in your worker

You have to create a context instance in each of your processes by the way. With this setup you would have a one way communication from main to worker, this is perhaps not the pattern you'd like to select if you need the worker to be able to reply. REQ/REP or DEALER/ROUTER are best suited for that.
Cheers

I'm cleaning up a lot of issues. This isn't really a place to get design advice for zeromq applications, but rather specific pzymq bugs. Maybe asking in other channels about libzmq you will get more feedback.


Use mrustc instead of rustc with cargo

I want to build a cargo project, using mrustc for compiling a single crate and rustc for the rest. Is it possible? I'm open to using hacks, for example renaming mrustc to rustc and putting it in PATH.

It looks like mrustc has a different cli (which would be fixable using a shim between cargo and mrustc). In addition it doesn't look like it has an option to write the crate metadata in a separate file from the rlib, which cargo always does for pipelined compilation, so you may need to copy the .rlib file produced by mrustc to the location where cargo expects the .rmeta file in the shim. You also need to handle the various --print commands cargo uses for learning information about the target like expected filenames for various types of files in the shim itself instead.

mrustc for one crate is interesting... and probably not possible, given that mrustc's metadata is completely different to rustc's.
For a whole project - cargo vendor and minicargo is the way to go.


feat: allow for additional params on conditionalPut

When you add params like ContentType to your conditionalPut, those
were being sent to the GetObject call as well. Now we filter the params
sent to the GetObject call so that no unsupported params are sent to it.

Coverage remained the same at 100.0% when pulling 5ea69e4349077d1c834869f1a0c7819a4a47fe05 on jrthomer/filter-getobject-params into ee900f91a38323511f2d6a33b43653e0a7b6c323 on master.


Refactor and enhance section profiling

Now also track the time spent in:

halo-exchanges
busy-waits when streaming data on/off device

Such finer breakdown is emitted when DEVITO_PROFILING is set to advanced1 or advanced2.

Is there any strong reason why someone should use advanced1 instead of advanced2? IOW does their diff in terms of profiling justify the existence of both modes? Can we get away only with advanced2 ?

This PR is just providing the basic infrastructure for enhanced profiling, but details (and names) might change in the near future. Said that, the difference between  advanced1 and advanced2 is that the former groups consecutive halo exchanges together, while the latter provides a per-halo-exchange breakdown. I think you can see this with elastic_example. I will update the wiki once the PR lands

Is there any strong reason why someone should use advanced1 instead of advanced2? IOW does their diff in terms of profiling justify the existence of both modes? Can we get away only with advanced2 ?

This PR is just providing the basic infrastructure for enhanced profiling, but details (and names) might change in the near future. Said that, the difference between  advanced1 and advanced2 is that the former groups consecutive halo exchanges together, while the latter provides a per-halo-exchange breakdown. I think you can see this with elastic_example. I will update the wiki once the PR lands

All GPU tests were run and passed CI: https://github.com/devitocodes/devito/actions/runs/471793778
Merging

All GPU tests were run and passed CI: https://github.com/devitocodes/devito/actions/runs/471793778
Merging


Allow symfony 3 components in version 0.3.X

Hi,
laravel-medialibrary still uses v.0.3.x of Glide. Upgrading the Glide dependency to 1.0.0 would be a breaking change, and I'm not willing to make a new major version just yet.
When laravel-medialibrary in installed into Laravel 5.2, it stops with an error. I believe that problem is caused by the fact the Glide does not allow symfony 3.x components.
The problem could be solved by changing:
"symfony/http-foundation": "~2.3",
"symfony/http-kernel": "~2.3"

to:
"symfony/http-foundation": "~2.3|~3.0",
"symfony/http-kernel": "~2.3|~3.0"

Could you tag version 0.3.6 with this change?

I'm not willing to make a new major version just yet

Come on man! :)
I think this is doable, but in all honesty I'm not even sure how to go about doing this. Do you have any recommendations? I'm assuming I'd need to create a branch for the 0.3.x version, and then modify and tag from there, yes?

I'm no git hero with mask and cape myself, but I think you are correct. In detail this is what I'd do:

checkout 0dd3e4e which is the commit id of v0.3.5
standing on that commit create a new branch called v.0.3 (or whatever you prefer)
make the change
push that branch to github
create a new release in GitHub (you can choose a branch in that dialog)

I used this strategy on several of the Spatie-packages.
Thank you very much for taking the time to do this!

Okay cool, let me do this. I'm pretty sure the commit is 57a10a4 though.

Yup, you're right. Commit is 57a10a4. Sorry about that.

This should be done: https://github.com/thephpleague/glide/releases/tag/0.3.6
Let me know if you need anything further.

Thanks Jonathan, much appreciated!


ConPTY swallows SGR 3 and 23, so terminals like Alacritty are prevented from supporting italics

Windows 10 version 1903, build 10.0.18362.295. Alacritty master.
Using Alacritty as the terminal (since it supports bold and italic text rendering), italic doesn’t work, because it seems to gets swallowed by ConPTY. https://github.com/jwilm/alacritty/issues/2745 has some discussion.
Steps to reproduce
Run the following in Bash or similar under Alacritty, with the enable_experimental_conpty_backend setting enabled:
echo -e 'Normal, \x1b[1mbold\x1b[22m, \x1b[3mitalic\x1b[23m, \x1b[1;3mbold italic\x1b[22;23m'

(If you don’t have that setting enabled, it’ll use WinPTY which also doesn’t pass italics through, but that’s irrelevant here.)
Expected behavior
Output like this:

Normal, bold, italic, bold italic

Actual behavior
Italics don’t occur:

Normal, bold, italic, bold italic

Further, when I insert logging into Alacritty’s csi_dispatch method, to observe what SGR codes it’s actually hearing about and applying, I see that the 3 (italic) and 23 (stop italic) have been swallowed, presumably by ConPTY, and Alacritty never saw them.
(ConPTY also modifies the CSI [ 1 m bold code to add another SGR code to change to the high-intensity colour. I still haven’t decided how I feel about that!)
I don’t know much about how these things work, so I don’t know if this is normal, but I was caught by surprise that ConPTY was apparently rendering things before they ever got to Alacritty, so that terminals are limited in what they can implement by what ConPTY implements. I expected it to pass everything through untouched, or at least to pass unknown things through rather than swallowing them.

Alright, so we've got serious progress here. Here are some before, after screenshots:

(imagine the "Blinking" on the right blinking).
I need to add some tests, but not we'll render italics, blinking, invisible, crossed-out all through conpty. Unfortunately, double-underline and faint are a bit more complicated, so they aren't going to make the 20H1 cut, but I'll circle back with follow-up issues for them.

Thanks, sounds good! I presume these things all combine properly with bold, which isn’t depicted, as well.
Is it possible to pass unimplemented things through, even if they’re not rendered by Command Prompt or Windows Terminal? Not that I actually have any use for double-underline and faint.

Unfortunately double-underline and faint have some implementations that would run closer to some other areas. I might be able to pass them through, but implementing them (in the buffer) is more complicated than the others in this set.
Bold does work fortunately:

Great, thanks! I’m looking forward to receiving this. 🙂

Hey! The fix for this went out in Windows in the Insider channel's Fast Ring with build 19013.
There's a minor followup issue where each ext. attribute will only turn on once -- it's understood and fixed, awaiting a newer build.


Need forum where we can ask for help

Trying to see if I can use this module with a jquery-ui backed drag and drop component like fullcalendar?

jquery drag and drop is completely different, so you can't drag and drop between those, if that was your question.
I don't think you'd get more support in a forum than here or on stack overflow, since there aren't many people spending their free time solving other people's work problems ;)


Merge Bento amp-conditional-block with self-hosted

This PR merges Bento amp-conditional-block with self-hosted branch for px-newspack.rt.gw test server.

This PR is closed in reference to #28


Init core status api generation

TODO:

[x] Key status
[x] Relay status
[x] Lightning status

Done with this. The responses basically look like:
{
    "keyStatus": {
        "status": "READY"
    },
    "lightningStatus": {
        "nodeStatusList": [
            {
                "pubkey": "02c92b69bdbd1c1a17f7d88bc1e51b4961581ae3dec75335d4852ab8d6f2bbca02",
                "active": false
            }
        ]
    },
    "communicationStatus": {
        "websocketConnections": [
            "did:peer:1zQmX9pDkNmRWiTwZohLhTwPSLJNoCSDeUAZwozXycjmg9e6"
        ]
    }
}

Two notes: With lightning, the daemon technically has support for multiple lightning nodes, so this lists the pubkey and whether or not the connection is active with the lightning node.
With the "relay check", the daemon does not treat relays any different than normal peers when it comes to connections. The daemon is very indifferent to have 0, 1, or many relays that the user might want to check on. So, this lists all peers that there's a web socket connection with. If the browser wants to decide whether or not the connection to the user's relay is good, you'll have to do client side filtering with the relay DID that the browser has configured for the user.
@markhandlersec let me know if that makes sense and if that is acceptable.

let me know if that makes sense and if that is acceptable.

@tonyimpervious love it! @markcryptohash and I are reviewing it right now, will approve afterwards. 👊

works as expected


this library do not support in android?

this library do not support in android?

What part of the library is not supported on android?


Bjorn's IP address on screen? [Feature request]

Would be helpful to have Bjorn's IP address visible on the screen.
Especially useful when changing networks via the Config UI and knowing what address to open to monitor via browser.

Thank you for the suggestion, I will work on a slightly more discreet approach, i think we don’t want to constantly have the IP address on the screen.
Until today, given that the gadget usb was used (pc/ phone / tablet), we didn’t directly need to have the ip of the « target » network.
In addition, we will soon also have the sharing of ip in bluetooth.
What I can do is display the ip in bjorn comment, for 10-15 seconds as soon as he gets the network, I look at possible solutions.
Thanks to you

Thanks for the reply. Great job w/ Bjorn!
Maybe a config option to:  "Display Bjorn IP: [Always | Never | On Boot]" with On Boot the default?

Added IP address showing at startup, instead of harcoded on the screen loop

#17


Add another way to run the code; add missing test

...by using the node terminal command. This should work quickly for everyone.

I suppose this works :ok:


Missing text when enchanting dull magic shard

Missing this text when enchanting dull magic shard

Damn !
I'm on holliday for two weekends, this will be fixed AT thé end of thé mount.

Ok, in your time. When you came back, check pull requests, i made a translation to pt_br.

Problem is fixed and i've add your translation file. Thank you for your contribution.


Trying to deploy sample java app facing issue while deploying the service

Command that is failing - kubectl apply -f k8s/.
https://github.com/GoogleCloudPlatform/opentelemetry-operator-sample/blob/main/sample-apps/java/README.md
Error
2024-02-15 22:29:00.044 GMT
Error: LinkageError occurred while loading main class com.google.example.service.Main
2024-02-15 22:29:00.044 GMT
java.lang.UnsupportedClassVersionError: com/google/example/service/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
I am building and running my application in Google cloud shell.
$ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Debian-1deb11u1, mixed mode, sharing)

@psx95 or @aabmass are you more familiar with the Java build steps to debug this? Looks like it's something with the sample app image that users build in make build

Please help with the fix looks like something to do with the java version.

I'll take a look into this.

I retried the steps from Readme, but was not able to reproduce the problem.
kubectl apply -f k8s/.

// results in the following
cronjob.batch/javashowcase-app created
service/javashowcase-service created
deployment.apps/javashowcase-service created

The logs from the docker container also do not show the version mismatch error.
Where exactly do you see this message ?  Since the service runs in a docker container, version mismatch should not occur.

Steps that I am following.

Created a standard GKE Kubernetes cluster.
Connected to the GKE Cluster from google cloud shell.
Installed Open Telemetry Operator and started the collector with these steps. Readme
While following thorough these steps got issue at step two  kubectl apply -f k8s/. this command was executed in Google cloud shell.

Thank you for providing the additional information. I will take a closer look into this, following the steps you have mentioned.

Some of my suspects for the issue as per my build log as attached in the last comment.
https://github.com/runningcode/gradle-doctor/pull/195/files#diff-c0dfa6bc7a8685217f70a860145fbdf416d449eaff052fa28352c5cec1a98c06R28
https://github.com/GoogleCloudPlatform/opentelemetry-operator-sample/blob/main/sample-apps/java/gradle/wrapper/gradle-wrapper.properties#L3

I tried building go sample app it is coming up without any issue the problem is when I build the java app.
=> => naming to us-central1-docker.pkg.dev/tribal-joy-413413/otel-operator/go-sample-server                                                                                0.0s
aperumal_personalid@cloudshell:~/opentelemetry-operator-sample/sample-apps/go (tribal-joy-413413)$ kubectl apply -f k8s/.
deployment.apps/goshowcase-app created
service/goshowcase-server created
deployment.apps/goshowcase-server created
aperumal_personalid@cloudshell:~/opentelemetry-operator-sample/sample-apps/go (tribal-joy-413413)$

Hi @Santosh-Kumar-Perumal,
Thank you digging into this issue ! I was able to reproduce this issue on cloud shell through your steps. The sample does need some changes to fix this.
Background & Root Cause
We use jib to build & run the Java sample - based on the "What is jib?" - it seems like jib builds the applications without the Docker daemon - which means it is using the Java version that is locally installed on your machine to compile the code into .class files.
On Cloud Shell, this appears to be Java 17. However, jib runs the compiled code in a docker container for which the base image is Java 11. This configuration is specified here, which leads to a version mismatch error.
Fix
In order to fix this, source and target compatibility need to be explicitly defined in this build.gradle.kts file:
java {
    sourceCompatibility = JavaVersion.VERSION_11
    targetCompatibility = JavaVersion.VERSION_11
}

This would tell gradle to build the source files explicitly for Java 11.
I did a small experiment and this does seem to work, I will raise a PR to make this change and confirm, but in the mean time,  you could try this on your end too.
Other notes

Thank you for bringing the slow build issue to light, I will see if I can update the gradle version we use as well.

Thanks for the quick fix appreciate it @psx95
I was able to build the service successfully now I am trying to access the service once it is deployed but facing below issue.Can you check at your end if you can access the service ?

Thanks a lot I was using the collector-config.yaml that is outside after using the one that is present inside cloud-trace I am able to see the trace coming up.
"Big shoutout to @Google and team members @psx95  and @damemi  for their lightning-fast response and invaluable assistance in resolving my GitHub ticket. Their guidance and support throughout the process were instrumental. Thank you for your dedication and expertise! 🙌 #TechSupport #GitHubHeroes"
🌟 Major kudos for your brilliance and dedication! 🙌 #TechGeniuses #GitHubHeroes"


Release API URL change

Hi, this needs to be released. Thx in advance :)

It's on my list. Doing my best regarding my free time. AFAIK we still have several months to go. Or is it causing some immediate issues?

Sure, I just wanted to make sure you are aware. No immediate issues right now. Just that the downstream apps also need some time to migrate.

That’s a good point!
On Tue 11. 6. 2024 at 11:34, Tomáš Bedřich @.***> wrote:

Sure, I just wanted to make sure you are aware. No immediate issues right
now. Just that the downstream apps also need some time to migrate.
—
Reply to this email directly, view it on GitHub
https://github.com/honzajavorek/fiobank/issues/30#issuecomment-2160256744,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACFGMIK4OKIBNFZOZZNYCTZG3ABNAVCNFSM6AAAAABJD4NMASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRQGI2TMNZUGQ
.
You are receiving this because you commented.Message ID:
@.***>

Should be done!


TransformLayer should participate in raster caching

The framework uses RepaintBoundarys to push OffsetLayers to signify an area that should paint independently. This gets turned into a TransformLayer on the engine side, with an SkMatrix that is translate-only.
This may result in multiple pictures that are individually raster cached, but often times a repaint boundary indicates an entire area of multiple pictures that would benefit from raster caching. This is particularly true in scrolling use cases, where repaint boundaries are used to animate the offset of a layer.
It should be possible for flutter::TransformLayers to check if they are a translation only matrix and raster cache using the same heuristics as other layers today. The theory is that this will help with scrolling scenarios. We'll want to monitor impact on memory usage.
/cc @goderbauer @flar

How do we handle children changing for opacity and image shader layers?

For context, I thought we could do something like this also on Transform layer:
https://github.com/flutter/engine/blob/a5aa1d98f502d5289fd8cb96e713ecb13e670ce2/flow/layers/image_filter_layer.cc#L72
https://github.com/flutter/engine/blob/9e9522c1692a62934d586992eb779e13b61bf55b/flow/layers/opacity_layer.cc#L62

How does this request achieve that? All of that is already done (modulo SVG entries bypass some of our logic to individually cache them that is being worked on under other issues)?

This sounds like a win. One thing to look for, though, would be if it causes jank while scrolling as the entire scrolled container is invalidated when a new child is created. Caching the scrolled items has reduced jank for that situation because only the new child needs to be cached.
Another thing to consider is that in the cache list shown above we see the contents of the items being cached, but the border of the item is not. That effect suggests that the RepaintBoundary is too low in the sub-tree. The scrollable container should literally be a list of RepaintBoundaries, but it looks like it might be a list of decorations that each wrap a RepaintBoundary. Do we see an improvement if the entire item is cached rather than just its contents?
This is also driving us towards a situation where we may end up with extra nested cache items. I brought this up in the PR for caching nested Picture objects. The issue is that every layer and picture is making an independent decision about whether it should be cached - which is fine if all decisions are on leaves. But, as noted last year in https://github.com/flutter/flutter/issues/70124 if you have parents also deciding whether to cache a layer then you can end up in situations where a picture layer wants to cache its picture, but it is inside a parent layer that wants to cache its layer. At that point you end up with double-caching.
This was first noted when we added caching to Opacity and ImageFiltered layers, but we have not since introduced a solution for it. If we start caching the TransformLayers  then we might see this situation become more common. Unfortunately, I'm not sure we have a good measure of this happening, but you might spy it in the timeline traces if you see a TL see a nested child fill the cache right before the TL itself fills the cache.
I need to create an Issue for redesigning our cache strategy. We really should not be caching during PreRoll. The reason we do that is to avoid render target switching in the Paint phase, but Preroll is too early to look at the larger picture and plan the cache entries. We really need Preroll to simply identify the nodes that are good targets for caching, then another pass that chooses which to cache using a global strategy once the candidates have been identified, then a final pass to Paint. Another problem this would solve is that evictions happen after we fill the new entries because the new entries are made before we are done with the Preroll scan. This means we have to create new cache entries before we evict expired ones. If this was a separate pass then the evictions could happen before the global decision to add new entries.
My recommendation would be to investigate if the RepaintBoundary objects are too low in the list to provide the best response, raise them higher so that the scrollable container contains only RepaintBoundaries as children and compare to these results.
Then we really need to get started on redesigning the caching process and take it out of Preroll...

I think if we just reverted https://github.com/flutter/flutter/pull/29701/ it would work. Not sure what impact that has on goldens. We could probably go even further and take out the possibility ever pushing a layer.
Part of why this was done too was to help with debugging fuchsia-specific needs on non-fuchsia platforms, but the code for that has since been removed.

The scrollable container should literally be a list of RepaintBoundaries

The scrollable container is a list of repaint boundaries already.

I eventually saw that. It was the PhysicalShapeLayer that gets pushed into the RepaintBoundary that is disrupting caching the complete scrollable item.

Even if we move PhysicalShape back to not pushing a layer, one can imagine other situations where it may be beneficial to cache larger chunks, e.g. SVGs will soon be their own picture and it may still make sense to cache them as a larger unit with other stuff around them.

That could be handled by https://github.com/flutter/engine/pull/29155

There is no evaluation of complexity or stability, the cache entry is populated immediately on the first try

In my current implementation I only start caching when the content of the offset layer has been stable for three frames, similar to ImageFilterLayer.

I haven't seen the code for this experiment, but in looking back at image_filter_layer I can see that it does its own stability test.

One of the tasks I've identified for improving our RasterCache is to have a separate pass to evaluate all of the candidates for caching. With such a mechanism we would likely not need to specifically tag individual layers as candidates and the list could be inferred from examining the stability of sub-trees. This may not happen soon (it would benefit a lot from the as-yet-disabled DiffContext code which will be enabled soon).
See https://github.com/flutter/flutter/issues/91923

I've some additional data from an internal use case at b/203469933, which looks less promising.

I think that TransformLayer participating in raster caching has significantly improved the fluency of list scrolling scenarios.
But I prefer to let the user specify whether RepaintBoundary needs to participate in raster caching, as described in this Issue https://github.com/flutter/flutter/issues/32662.
I wrote experimental PRs to verify whether the performance improved, and from the benchmark results, it did reduce raster times.

We also have been steering away from adding specific caching hints to the Flutter classes, so the Issue you mention has been falling into disfavor over the past couple of years. @dnfield @zanderso

Raster caching transform widgets is already done if you add a filterQuality to their widget.
We also have been steering away from adding specific caching hints to the Flutter classes, so the Issue you mention has been falling into disfavor over the past couple of years. @dnfield @zanderso

I learned before that Transform uses ImageFilterLayer instead of TransformLayer after adding filterQuality. What I would like to discuss here is whether or how the TransformLayer corresponding to RepaintBoundary should participate in raster caching in scrolling scenes.
In experiments I found that properly caching the RepaintBoundary content to the raster cache can significantly improve scrolling performance, but it also requires more memory. So I hope the developer will have the option to control which RepaintBoundary they wants to cache and which RepaintBoundary is not.
I also tried to cache all RepaintBoundary contents if it didn't change for three frames, like @goderbauer tried before. I found cost more memory and doesn't bring further scrolling performance improvements.
It's not clear to me why we should avoid adding options to RepaintBoundary. In the process of developing flutter applications, developers have more useful information, why not give them a chance to find the best balance between scrolling performance and memory cost for their applications?

In terms of the design of the API, my hope is that we can get down to one advisory boolean flag on one widget with which the developer can suggest that raster caching may be beneficial. The Engine would be free to ignore this flag, or to decide to do it eagerly or only after a certain number of frames, and everything else about the actual policy. But in terms of the API design, if we have more than one flag, and the flags are scattered around all over the place, and they mean different things, it becomes both too hard for the developer to understand, and too difficult for the Engine to implement faithfully.
In particular, things like this:

Raster caching transform widgets is already done if you add a filterQuality to their widget.

are an implementation detail that aren't officially part of the API.
So, I'm in favor of work in this area as long as it's moving us toward a simpler, easier-to-understand API. But if we're just adding more flags with no plans to consolidate, I think we need to put more thought into this.

I like the idea about the simpler, easier-to-understand API.
It's great that Transform can participate in caching after adding filterQuality. But it can be a bit confusing for developers, especially when they find that the Transform's behavior changes a lot between filterQuality is not set and filterQuality is set to FilterQuality.none.
If Transform can also add a flag named rasterCache to decide whether to participate in the cache, and let the responsibility of filterQuality return to its literal meaning, I believe it will be easier for developers to understand. And it can also consolidate the API well.

In particular, things like this:

Raster caching transform widgets is already done if you add a filterQuality to their widget.

are an implementation detail that aren't officially part of the API.

The filterQuality property is an official part of the API and was added specifically to enable bitmap operations.
https://api.flutter.dev/flutter/widgets/Transform/filterQuality.html
https://api.flutter.dev/flutter/widgets/ScaleTransition/filterQuality.html
https://api.flutter.dev/flutter/widgets/RotationTransition/filterQuality.html
It even documents this behavior.

I like the idea about the simpler, easier-to-understand API.
It's great that Transform widget can participate in caching after adding filterQuality. But it can be a bit confusing for developers, especially when they found that the Transform's behavior changes a lot between filterQuality is not set and filterQuality is set to FilterQuality.none.
If Transform can also add a flag named rasterCache to decide whether to participate in the cache, and let the responsibility of filterQuality return to its literal meaning, I believe it will be easier for developers to understand. And it can also consolidate the API well.

What "original meaning" would filterQuality have OTHER than to enable raster caching? The property is completely meaningless unless caching is happening. Adding another flag to enable caching would end up with 2 flags doing the same thing, one of which can actually describe the quality level you want in the bitmap transform and the other basically having no input whatsoever in the quality that we implement.
Check out this design document about the alternatives that were considered. During a meeting where we discussed this document among the Flutter team the concept of a bitmap hint flag floated to the top, and turning that into the filterQuality both gave the developer a flag to enable the bitmap operation as well as a setting to control its quality.
https://docs.google.com/document/d/1Fxdlf7JsA-yAwc_RNuboMG-vhIhchRBZGvDSwg5qR0A/edit#heading=h.pub7jnop54q0

But it can be a bit confusing for developers, especially when they found that the Transform's behavior changes a lot between filterQuality is not set and filterQuality is set to FilterQuality.none.

FilterQuality.none is still bitmap caching. It's just using NearestNeighbor.
Trasnform.filterQuality = null; turns it off.

Hi, @flar
The most common place developers use filterQuality is the Image widget, which only represents the image sampling quality (original meaning), which does not mean that something should participate in raster caching, right? The filterQuality in Transform represents two things. The layer corresponding to Transform will participate in raster caching (not original meaning), and what is its image sampling quality (original meaning). As a developer, I guess this is actually not easy to understand. So probably adding a rasterCache  flag can make it easier for developers to understand what filterQuality does. Even if filterQuality must not be null when rasterCache is true, filterQuality must be null or be ignored when rasterCache is false.
But this is not the focus of what I'd like to discuss today. I would like to discuss the following things under this Issue:

Should TransformLayer participate in raster caching?
Should we only let the TransformLayer created by RepaintBoundary participate in raster caching?
Should we let the user specify which RepaintBoundary participate in raster caching.

Looking forward to your reply, thanks you :-)

@ColdPaleLight did you read the design document above?

@ColdPaleLight did you read the design document above?

I've read it (probably I didn't fully understand it due to language barrier), I think the problem mentioned in the documentation you have solved by transform's filterQuality. Maybe I have some opinions about the API, but never mind it.
What I'd like to discuss is a completely different issue. In a complex list view scrolling scene, a RepaintBoundary will be wrapped by default on the outside of each item, and this RepaintBoundary corresponds to a TransformLayer at the engine layer. If the items in the list are very complex, and may be composed of multiple layers and pictures, and its content will not change, should we cache this TransformLayer?
If we should cache it, then how should we tell engine that ·TransformLayer is generated by the RepaintBoundary? In addition, developers may not want to use this caching strategy to cache all RepaintBoundary. Maybe they only want to cache the RepaintBoundary in the list, so should we provide a flag to the user?

But this is not the focus of what I'd like to discuss today. I would like to discuss the following things under this Issue:

Should TransformLayer participate in raster caching?

Participate in what way? By directly caching its children? That is only useful in a small set of ways that are already dealt with. Please describe a scenario in which it might "participate".
In particular, the Issue that you are having this discussion in was describing a specific way in which a TransformLayer might "participate in caching", but in the end, it wasn't really the right solution. The description talks about caching children when scrolling them. But, how does it know when it is scrolling the children? Do we add another flag?
If it knows it is a scroll container's translate mechanism, then how should it participate? By caching all of its children? That would make sense if all of the children were present and stable, but they aren't. As you scroll them they constantly come and go which means the TransformLayer is constantly having to recache its children. If it encapsulates them in a RepaintBoundary then they will cache if they are stable anyway, but doing so will end up churning the cache every time an entry in the list appears or disappears. The best answer in this case is for each child to be cached depending on how complicated that child is. And we already do that if they don't change. All of that is handled in PictureLayer and DisplayListLayer.
So, it can't know whether to make this optimization, and if it did, it would have difficulty in doing it correctly with the current layer caching mechanisms, and if it doesn't then the right thing should happen if the developers construct their lists correctly (i.e. insert RepaintBoundaries to keep their list items separate) - which is along the lines of what has been suggested above, but the thing is that you don't need a flag for a RepaintBoundary to cache itself, it just needs to remain stable.
And if you think that developers instinctively know where to put RepaintBoundary objects, the entire reason this issue is here is because the RepaintBoundary objects were in the wrong place in the tree to do their job effectively. Fixing that ran into another issue related to "double caching" which is being worked on.
Now, if we expand this to consider allowing TransformLayers to cache even if their transform isn't a translate, then we end up having to have a quality heuristic that decides whether scaling a child by 1.05 looks good enough that the developer won't notice or care. We'll get that wrong because "heuristic" generally means "bug" in most cases. If we do it with linear interpolation, would that bridge the gap? What about mipmapping? For any operation that isn't a translation, we basically need to loop the developer in and they need to specify that it is OK to use a bitmap operation for this one case. That is where the filterQuality parameters come in. They both indicate that the developer is OK with doing a bitmap operation despite the quality loss, and which level of algorithm retains enough quality for their tastes and design goals.

Should we only let the TransformLayer created by RepaintBoundary participate in raster caching?

It already does. If it is just a translation, then the child will cache or not cache depending on its complexity which is what we want it to do. If TransformLayer tries to do this manually then 60-70% of the time we will end up with the child being cached twice until we fix the above "double caching" issue.

Should we let developers specify which RepaintBoundary participate in raster caching.

They already use RepaintBoundary for another purpose and they don't do that very well as it stands. If we add a flag to the widget to force caching we'll disrupt a reasonably good mechanism already built into it that does automatic caching, but there are bugs in that to be fixed. The above "double caching" issue is one of them. The other is to improve our complexity metrics so we only cache things that will speed us up.
If developers put RepaintBoundary objects in their trees at good locations then the natural picture caching code will end up turning them into bitmaps pretty effectively. Then simply translating them means that they will draw from the cache on every frame. And there you have a translation Layer "participating in caching" without it having to have a line of code added to it.

Another reason not to cache all of the children of a scrolling list together...
If any of them contains an animating stamp or other content that changes, it disrupts the caching of all of the content. If each child is cached separately then only the items that have dynamic content will have to re-render on every frame.

I think I'm getting deja vu here but - I'm pretty sure the ask here is not to cache a transform layer that wraps a bunch of scrolling children, but to cache individual children (which are each an individual TransformLayer once we get to C++ land).

@flar here is the benchmark result of making RepaintBoundary Cacheable https://github.com/flutter/flutter/issues/91648#issuecomment-1096763647
I am using the complex_layout example provided by flutter, and you can see that the average raster time is significantly improved. At the same time, I also observed that the double-cache issue does not occur in this scenario. Because TransformLayer generates a cache in the third Prepare, and its internal displaylist has no chance to generate a cache.
I think the current raster caching mechanism is not perfect. Adding a flag to RasterCache will not destroy current caching mechanism, but will give developers the opportunity to tune it.
If we can optimize complex_layout like this, then for real-world flutter applications, I am more confident that developers can optimize through it.
I'll provide a screen recording video later,  that will be more intuitive

without change
https://user-images.githubusercontent.com/31977171/163114839-52379bb7-c420-4147-93ad-ee79f628e5b8.MP4
cache RepaintBoundary in sliver
https://user-images.githubusercontent.com/31977171/163114786-eed60e2c-c8a1-4acf-b7f6-6fc877b787d1.MOV

Here's an implementation issue that I think is probably more important than playing with manual caching on various layers. I wrote a simple program to demonstrate the issue.
Currently, when you add a RepaintBoundary to an app, it splits the tree down the middle completely shattering it. You go from 1 "display list" (as the framework documentation calls it, but it really could be a combination of Layers and DisplayLists in implementation) to a new tree that one might expect to have 2 or 3 sections (a before section, a repaint boundary'd section, and an after section). In the case of my app, it goes from 1 to 21 sections. This is due to the way that the Flutter tree handles the properties it refers to as "compositing" properties. If anything in the tree is composited then all parent widgets that might otherwise just draw to the Canvas instead all become "Layers" that cause their parents to also need to "composite".

Example code!
import 'dart:math';

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'RepaintBoundary Tree Impact Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'RepaintBoundary Tree Impact Demo'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  bool _useRepaintBoundary = false;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: _NestedWidget(
          level: 10,
          rotateDegrees: 9,
          useRepaintBoundary: _useRepaintBoundary,
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => setState(() => _useRepaintBoundary = !_useRepaintBoundary),
        tooltip: '${_useRepaintBoundary ? 'Remove' : 'Add'} RepaintBoundary',
        child: Icon(_useRepaintBoundary ? Icons.remove : Icons.add),
      ),
    );
  }
}

class _NestedWidget extends StatelessWidget {
  const _NestedWidget({
    required this.level,
    required this.rotateDegrees,
    required this.useRepaintBoundary,
  });

  final int level;
  final double rotateDegrees;
  final bool useRepaintBoundary;

  @override
  Widget build(BuildContext context) {
    if (level == 0) {
      Widget child = const SizedBox(width: 200, height: 300);
      if (useRepaintBoundary) {
        child = RepaintBoundary(child: child);
      }
      return child;
    } else {
      return Transform(
        transform: Matrix4.rotationZ(rotateDegrees * pi / 180),
        alignment: Alignment.center,
        child: CustomPaint(
          painter: _MyPainter(color: Colors.blue, isHorizontal: true),
          foregroundPainter: _MyPainter(color: Colors.green, isHorizontal: false),
          child: _NestedWidget(
            level: level - 1,
            rotateDegrees: rotateDegrees,
            useRepaintBoundary: useRepaintBoundary,
          ),
        ),
      );
    }
  }
}

class _MyPainter extends CustomPainter {
  _MyPainter({required this.color, required this.isHorizontal});

  final Color color;
  final bool isHorizontal;

  @override
  void paint(Canvas canvas, Size size) {
    Paint p = Paint()
        ..color = color;
    if (isHorizontal) {
      canvas.drawRect(Rect.fromLTWH(0, size.height / 2 - 5, size.width, 10), p);
    } else {
      canvas.drawRect(Rect.fromLTWH(size.width / 2 - 5, 0, 10, size.height), p);
    }
  }

  @override
  bool shouldRepaint(CustomPainter oldDelegate) => true;
}

An observatory view of it before I click the button to add the RepaintBoundary:

And another observatory view after I click to add the RepaintBoundary. Note that the RepaintBoundary is only added to the leaf widget!

I think the current raster caching mechanism is not perfect. Adding a flag to RasterCache will not destroy current caching mechanism, but will give developers the opportunity to tune it.

But what I'm saying is that we are discussing throwing good money after bad rather than fixing the real underlying problems such as seen in the example I gave.

I am using the complex_layout example provided by flutter, and you can see that the average raster time is significantly improved. At the same time, I also observed that the double-cache issue does not occur in this scenario. Because TransformLayer generates a cache in the third Prepare, and its internal displaylist has no chance to generate a cache.

This is a delicate balance achieved as a side effect of copying the same threshold between two different mechanisms. It is fragile and someone might change the values and break this happy coincidence.
When I first observed the issue with a similar case, the double-caching was only for one frame in many cases. But, still it happened. And does the cache churn when a new item is added to the list?
I looked at the PRs and did not see anywhere you were setting the flag...? How is your proposed mechanism working?

I think the current raster caching mechanism is not perfect. Adding a flag to RasterCache will not destroy current caching mechanism, but will give developers the opportunity to tune it.

But what I'm saying is that we are discussing throwing good money after bad rather than fixing the real underlying problems such as seen in the example I gave.

Regarding RepaintBoundary, I think your example is a very special case, in your example it does seem to have side effects. But in more real flutter scenarios it is very helpful.
For example, ListView will automatically wrap RepaintBoundary for its children by default for better performance. If the ListView does not wrap the RepaintBoundary for the child, you can see that there will be a big drop in performance.
The following is also the scene of complex_layout, I set the addRepaintBoundaries of ListView to false.

addRepaintBoundaries is false

  "average_frame_build_time_millis": 5.314563106796118,
  "90th_percentile_frame_build_time_millis": 8.034,
  "99th_percentile_frame_build_time_millis": 14.562,
  "worst_frame_build_time_millis": 18.934,
  "missed_frame_build_budget_count": 1,
  "average_frame_rasterizer_time_millis": 9.54069902912622,
  "90th_percentile_frame_rasterizer_time_millis": 11.991,
  "99th_percentile_frame_rasterizer_time_millis": 23.355,
  "worst_frame_rasterizer_time_millis": 25.114,
  "missed_frame_rasterizer_budget_count": 3,
  "frame_count": 103,
  "frame_rasterizer_count": 103,
  "new_gen_gc_count": 8,
  "old_gen_gc_count": 2,
  "average_vsync_transitions_missed": 1.0,
  "90th_percentile_vsync_transitions_missed": 1.0,
  "99th_percentile_vsync_transitions_missed": 1.0,
  "average_vsync_frame_lag":<PHONE_NUMBER>776699,
  "90th_percentile_vsync_frame_lag": 393.0,
  "99th_percentile_vsync_frame_lag": 474.0,
  "average_layer_cache_count": 0.0,
  "90th_percentile_layer_cache_count": 0.0,
  "99th_percentile_layer_cache_count": 0.0,
  "worst_layer_cache_count": 0.0,
  "average_layer_cache_memory": 0.0,
  "90th_percentile_layer_cache_memory": 0.0,
  "99th_percentile_layer_cache_memory": 0.0,
  "worst_layer_cache_memory": 0.0,
  "average_picture_cache_count": 1.0,
  "90th_percentile_picture_cache_count": 1.0,
  "99th_percentile_picture_cache_count": 1.0,
  "worst_picture_cache_count": 1.0,
  "average_picture_cache_memory": 1.3732909999999978,
  "90th_percentile_picture_cache_memory": 1.373291,
  "99th_percentile_picture_cache_memory": 1.373291,
  "worst_picture_cache_memory": 1.373291,
  "total_ui_gc_time": 109.917,
  "30hz_frame_percentage": 0.0,
  "60hz_frame_percentage": 100.0,
  "80hz_frame_percentage": 0.0,
  "90hz_frame_percentage": 0.0,
  "120hz_frame_percentage": 0.0,
  "illegal_refresh_rate_frame_count": 0

addRepaintBoundaries is true (default)

"average_frame_build_time_millis": 2.5092424242424234,
  "90th_percentile_frame_build_time_millis": 4.006,
  "99th_percentile_frame_build_time_millis": 23.334,
  "worst_frame_build_time_millis": 28.724,
  "missed_frame_build_budget_count": 2,
  "average_frame_rasterizer_time_millis": 9.330151515151515,
  "90th_percentile_frame_rasterizer_time_millis": 13.054,
  "99th_percentile_frame_rasterizer_time_millis": 18.297,
  "worst_frame_rasterizer_time_millis": 18.703,
  "missed_frame_rasterizer_budget_count": 4,
  "frame_count": 99,
  "frame_rasterizer_count": 99,
  "new_gen_gc_count": 6,
  "old_gen_gc_count": 2,
  "average_vsync_transitions_missed": 1.0,
  "90th_percentile_vsync_transitions_missed": 1.0,
  "99th_percentile_vsync_transitions_missed": 1.0,
  "average_vsync_frame_lag":<PHONE_NUMBER>7142856,
  "90th_percentile_vsync_frame_lag": 459.0,
  "99th_percentile_vsync_frame_lag": 1021.0,
  "average_layer_cache_count": 0.0,
  "90th_percentile_layer_cache_count": 0.0,
  "99th_percentile_layer_cache_count": 0.0,
  "worst_layer_cache_count": 0.0,
  "average_layer_cache_memory": 0.0,
  "90th_percentile_layer_cache_memory": 0.0,
  "99th_percentile_layer_cache_memory": 0.0,
  "worst_layer_cache_memory": 0.0,
  "average_picture_cache_count": 2.91,
  "90th_percentile_picture_cache_count": 3.0,
  "99th_percentile_picture_cache_count": 4.0,
  "worst_picture_cache_count": 4.0,
  "average_picture_cache_memory": 5.4585972099999935,
  "90th_percentile_picture_cache_memory": 5.64394,
  "99th_percentile_picture_cache_memory": 7.551384,
  "worst_picture_cache_memory": 7.551384,
  "total_ui_gc_time": 30.912,
  "30hz_frame_percentage": 0.0,
  "60hz_frame_percentage": 100.0,
  "80hz_frame_percentage": 0.0,
  "90hz_frame_percentage": 0.0,
  "120hz_frame_percentage": 0.0,
  "illegal_refresh_rate_frame_count": 0

I am using the complex_layout example provided by flutter, and you can see that the average raster time is significantly improved. At the same time, I also observed that the double-cache issue does not occur in this scenario. Because TransformLayer generates a cache in the third Prepare, and its internal displaylist has no chance to generate a cache.

This is a delicate balance achieved as a side effect of copying the same threshold between two different mechanisms. It is fragile and someone might change the values and break this happy coincidence.
When I first observed the issue with a similar case, the double-caching was only for one frame in many cases. But, still it happened. And does the cache churn when a new item is added to the list?

I believe the double-caching issue will be resolved in the near future, and there are already PRs working towards it.

I looked at the PRs and did not see anywhere you were setting the flag...? How is your proposed mechanism working?

In the following two lines of code in Sliver, I set rasterCache to true for benchmarking. This was not added to the PR, just used when testing locally.
https://github.com/flutter/flutter/blob/31191dd29ae3e2bb794abdccc8ccfa5093b86c02/packages/flutter/lib/src/widgets/sliver.dart#L480
https://github.com/flutter/flutter/blob/31191dd29ae3e2bb794abdccc8ccfa5093b86c02/packages/flutter/lib/src/widgets/sliver.dart#L744

@flar Another interesting and reasonable thing is that if developers use Opacity to wrap the original ListView item and set the opacity value to 0.99, the raster times will be optimized. This is thanks to the caching mechanism of OpacityLayer.
Opacity(
  opacity: 0.99,
  child: originItem
);

Of course this is a not recommended solution. But this also proves from another aspect that developers need a correct solution.

I got a pretty good performance increase simply from drawing the PhysicalShapeLayers instead of adding them as a layer similar to what was suggested above in Dan's comment. Basically, I did a quick and dirty revert of https://github.com/flutter/flutter/pull/29701 as suggested. Also, I'm not sure I got all of the PSL's that were being used - I just rewrote the one that I saw in a stack trace, but the PR above modified multiple points in the code.
My point is that there is a bug in Flutter that affects the scrolling performance of this demo by blocking effective caching of the list items. Instead of fixing that, you are adding a new heavyweight solution to work around it when it should already be working just fine.
What you are seeing with your fix is that we are going from very incompetent caching of the children via RepaintBoundary objects and bugs that thwart them, to a very rigid forced cache through your new mechanism. You are verifying that caching will help scrolling, but another solution is to fix these bugs and we'll see true scrolling with cached items working they way it was intended and then we can see how it compares to your scrolling with the whole scrollable cached.

@flar
I don't think this issue is equivalent to the bug in PhysicalShape. Even if we fix the bug in PhysicalShape, there is no guarantee that a complex ListView's Item whose content will not change participates in raster caching. see https://github.com/flutter/flutter/issues/91648#issuecomment-1098137343 .
If we say that we cannot guarantee that a complex and stable Item of ListView can be raster cached, then can we give the developer a chance to tune it through benchmarks to see if the Item of ListView needs to be complete raster cache? (If we solve the double-caching issue)

Regarding RepaintBoundary, I think your example is a very special case, in your example it does seem to have side effects. But in more real flutter scenarios it is very helpful.

I'm sorry I haven't responded to this issue recently, I have a lot of issues that I'm mulling over.
First, of course RepaintBoundaries add value, I never said they didn't. Everything you pointed out was an example of how they add the specific value that they were designed to add.
My point is that they also have side effects. My example was extreme not because I think that is a common layout, but because it demonstrates the burden the RPB places on the rest of the system. That widget does provide stability for the children, but the way in which it is implemented also fractures the tree above it. I don't think we need that side effect to achieve the same results. A different solution could provide the results without the fracturing.
I'm pointing out that the mechanisms that we are so focused on aren't perfect.

In the following two lines of code in Sliver, I set rasterCache to true for benchmarking. Thi was not added to the PR, just used when testing locally.
https://github.com/flutter/flutter/blob/31191dd29ae3e2bb794abdccc8ccfa5093b86c02/packages/flutter/lib/src/widgets/sliver.dart#L480
https://github.com/flutter/flutter/blob/31191dd29ae3e2bb794abdccc8ccfa5093b86c02/packages/flutter/lib/src/widgets/sliver.dart#L744

Rather than force a raster cache, why not look at what is preventing the existing caching and fix that.
TransformLayer (and the ImageFilteredLayer used for cached transforms) should be transparent to caching, but currently it is not. It doesn't need to do its own caching, it just needs to not get in the way of existing caching mechanisms.
I already have a PR, still in a draft stage awaiting some more intensive tests, that will make TransformLayer and ImageFiltered transparent to opacity peephole optimization which would make many of the use cases I've seen start to behave without any further changes. In particular, the Android Q transition which is an OpacityLayer around a Transform/ImageFilterLayer will pass through the opacity peephole optimization.
Opacity around a scrolling list would transfer all of the opacity handling to the children who would apply it transparently to their cached version without Opacity needing a layer.

I think if possible, I hope that ListView can also add a flag to specify whether the RepaintBoundary generated in Sliver needs to be set to rasterCache

I don't see a need for a flag in RepaintBoundary if we just fix the existing mechanisms to work as they were originally intended.

However, this mechanism is very fragile. As you mentioned in Issue #101810, the tree can be shattered by RepaintBoundary. Actually, Opacity, Transform and many other widgets can shatter tree, resulting in a large DisplayList being split into multiple small DisplayLists, which may not be able to participate in RasterCache.

Opacity should check if its children need compositing and only use a layer in that case. The else part of that decision would just do a saveLayer with an alpha Paint.
Transform actually does the test I just mentioned and only pushes a layer if its children need compositing.
This "compositing" flag is the "split the tree up the middle" flag. Each child that sets it causes all of its parents to switch to layers instead of rendering commands.

for example. If you add an Opacity widget below the following two lines of code, then most of the contents of items will no longer be able to be cached in the raster cache, and the performance will degrade again. The reason for this is that the complex DisplayList is split into multiple DisplayLists that are not complex enough.

That's a bug. I submitted an issue to fix it: https://github.com/flutter/flutter/issues/102179

@flar Even if we fix the bug in PhysicalShape, there is no guarantee that a complex ListView's Item whose content will not change participates in raster caching. see #91648 (comment) .

That's a bug. We should be able to handle that case.

If we say that we cannot guarantee that a complex and stable Item of ListView can be raster cached, then can we give developers a chance to tune it through benchmarks to see if the Item of ListView needs to be complete raster cache? (If we solve the double-caching issue)

We should be able to (or strive to) guarantee tree stability rather than give more rope for developers to tie themselves up and prevent future optimizations on our part.

@flar
Thanks for your reply, I've learned a lot from you while discussing this issue.
I have some different opinions on this point of yours

We should be able to (or strive to) guarantee tree stability rather than give more rope for developers to tie themselves up and prevent future optimizations on our part.

Now suppose we have fixed the Opacity and PhysicalShape bugs. But I believe there are still many situations where we can fall into the original problem. For example, replace Opacity in https://github.com/flutter/flutter/issues/91648#issuecomment-1098137343 with RepaintBoundary, or a horizontal scrolling ListView (by default, every Item inside it will be wrapped by RepaintBoundary), or replace it with a Transform with a image_filter, or ColorFiltered and many more. I believe both will make the current scrolling problem of complex_layout reappear.
I believe that the original intention of @dnfield  to file this issue is to make the content of RepaintBoundary be cached as a larger unit.
It looks like you don't like adding a rasterCache flag. So can we do this without adding the flag? For example, If we find that the content inside TransformLayer is more complicated, and it has been stabilized for 3 frames, and its matrix is translate-only.

related issue: https://github.com/flutter/flutter/issues/103162

So its a bit hard to track the complete discussion of this issue, but I think I can try to summarize a few points (and @flar can correct me if I'm wrong).
We're aware that it some cases, we create more layers than necessary. We're in the process of fixing this with PhysicalShapeLayer and Opacity, and in some external packages like visibility_detector.
In the case where a picture is significantly split up, raster caching at the layer level can ameliorate some performance problems. However, I think @flar , myself, and others would rather reduce the amount of compositing (and caching) required to render a fast frame than allow more caching to cover up the bad heursitics in the framework/engine.
To that end, I don't think we'd accept https://github.com/flutter/engine/pull/32615 or the related framework PR. We'd rather not have APIs like this that will more or less tie our hands for future optimizations. While we may have originally considered a solution like that in the past, we've gotten good results from removing forced compositing so we're going to continue on that route for now.

I have closed the relevant PR, so is this issue still a valid issue? It seems that we would not intend to let TransformLayer participate in raster caching. Should we close this issue?

Sounds good, thank you @ColdPaleLight


Feature: Add ability to ignore packages by definition

Is your feature request related to a problem? Please describe.
Some packages don't have a valid "type" given. Also they are hot linked in RunTime. This makes is nearly impossible to get information about usages. Until then, we should provide the ability to ignore certain packages defined in your own composer.json
Describe the solution you'd like
We provide an entry in the extra directive of the composer.json which simple gets a list of ignored packages. These are similar to the cli parameter --excludePackage and should be merged with them.

Solved with 0.4.0


Add fixes

Hey, I added yn as you suggested and it worked, here’s a successful run.

Thanks so much!


How to pass arguments to the interpreter function Eval(..)?

How can I pass arguments to code I send to Yaegi Go's interpreter?
I have the following code:
package main

import (
	"github.com/containous/yaegi/interp"
	"github.com/containous/yaegi/stdlib"
)

const payload = `
package main

import (
	"fmt"
	"os"
)

func main() {
	argsWithProg := os.Args
	var args string
	if len(argsWithProg) < 2 {
		args = "empty"
	} else {
		args = argsWithProg[1]
	}

	fmt.Printf("Hellow World: %s\n", args)
}
`

func main(){

	i := interp.New(interp.Options{})
	i.Use(stdlib.Symbols)

	_, err := i.Eval(payload)
	if err != nil {
		panic(err)
	}
}

It send this code to Yaegi:
package main

import (
	"fmt"
	"os"
)

func main() {
	argsWithProg := os.Args
	var args string
	if len(argsWithProg) < 2 {
		args = "empty"
	} else {
		args = argsWithProg[1]
	}

	fmt.Printf("Hellow World: %s\n", args)
}

This code can get argument.
Expected result:
$ go run ./sample.go baba
// Hellow World: baba

But how can I pass arguments to i.Eval(payload) ?

I have a workaround for that, I will declare a global argument in the i.Eval(..) before running the code. But is there other way to do it?
package main

import (
	"github.com/containous/yaegi/interp"
	"github.com/containous/yaegi/stdlib"
)

const payload = `
package main

import (
	"fmt"
	"os"
)

func main() {

	var args string
	if globalVar == "" {
		args = "empty"
	} else {
		args = globalVar
	}

	fmt.Printf("Hellow World: %s\n", args)
}
`

func main(){
        var err error
	i := interp.New(interp.Options{})
	i.Use(stdlib.Symbols)

        _, err = i.Eval(`globalVar := "global var"`)
	_, err = i.Eval(payload)
	if err != nil {
		panic(err)
	}
}

Hello,
there are at least two ways you could achieve that.

If we assume you have no control over payload, and it has to stay a main as it would have been written as a Go main program, then the work-around you found is close enough. You should be able to simplify it a bit, by directly setting os.Args, since it is an exported variable, and therefore you shouldn't even need the globalVar you used. But as you probably guessed , this is pretty gross.

If you can rewrite the payload, you can make it more suitable to be called with Eval, e.g.:

package main

import (
	"log"

	"github.com/containous/yaegi/interp"
	"github.com/containous/yaegi/stdlib"
)

const payload = `
package main

import (
	"fmt"
)

func mainfunc(args []interface{}) {
	args = append([]interface{}{"Hello World"}, args...)
	fmt.Println(args...)
}
`

func main() {

	i := interp.New(interp.Options{})
	i.Use(stdlib.Symbols)

	_, err := i.Eval(payload)
	if err != nil {
		log.Fatal(err)
	}
	_, err = i.Eval(`mainfunc([]interface{}{"this", "is", "a", "message", "to", "the", "world"})`)
	if err != nil {
		log.Fatal(err)
	}
}

An even better way, would be to make mainfunc a generator, i.e. it would return the func that is to be called.
then you could do something like (I haven't tested that yet):
val, err := i.Eval(`mainfunc`)
...
hello := val.Interface().(func())
hello("this", "is", "a", "message", "to", "the", "world")

which would allow you to rely even more on the Go type system checks.

Cool, I thought when you run the first main function like that:
_, err := i.Eval(payload)    // will run the program
....
_, err = i.Eval(`mainfunc([]interface{}{"this", "is", "a", "message", "to", "the", "world"})`)

The first Eval will be called and run the program, so if my program was:
const payload = `
package main

import (
	"fmt"
)

func mainfunc(args []interface{}) {
        fmt.Println("MyTest1")
	args = append([]interface{}{"Hello World"}, args...)
	fmt.Println(args...)
}
`

It thought it will call twice to fmt.Println("MyTest1") but it didn't happen, any idea why (it called it only one time)?
I tried your last variation, it didn't work because of syntax so I changed it a bit:

const payload5 = `
package main

import (
	"fmt"
)

func mainfunc(args []interface{}) {
	//args = append([]interface{}{"Hello World"}, args...)
	fmt.Println(args[0])
	fmt.Println("a")
}

`

func main(){
	var err error
	i := interp.New(interp.Options{})
	i.Use(stdlib.Symbols)

	val, err := i.Eval(payload5)
	hello := val.Interface().(func([]interface{}))

	hello([]interface{}{"blabla"})
	if err != nil {
		panic(err)
	}
}

With the error:
panic: interface conversion: interface {} is *interface {}, not func([]interface {})

I am not sure how it wants me to provide the arguments to the hello function.
I will use your suggestion with the []interface{} idea, this looks cleaner. Thanks :)

Cool, I thought when you run the first main function like that:
_, err := i.Eval(payload)    // will run the program
....
_, err = i.Eval(`mainfunc([]interface{}{"this", "is", "a", "message", "to", "the", "world"})`)

The first Eval will be called and run the program, so if my program was:
const payload = `
package main

import (
	"fmt"
)

func mainfunc(args []interface{}) {
        fmt.Println("MyTest1")
	args = append([]interface{}{"Hello World"}, args...)
	fmt.Println(args...)
}
`

It thought it will call twice to fmt.Println("MyTest1") but it didn't happen, any idea why (it called it only one time)?

Well, there's nothing in payload that calls mainfunc, so if you only Eval payload, mainfunc itself is never run. It really is no different than if you put payload in a .go file and tried to go run it, you wouldn't see mainfunc being run either. (Well, it wouldn't work at all anyway, since I believe it's forbidden to have a package main without a main func, but that's beside the point).

okay I see, if I would call it just main it wouldn't work as expected.
Thank you for you answer, I will try the interface solution, looks like a good one. Thanks :)


能添加 VPN or proxy 翻墙回国内吗

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...].
清楚简洁地说明问题所在。例如，当[...]时，我总是感到沮丧。
Describe the solution you'd like
A clear and concise description of what you want to happen.
简洁明了地描述您想要的功能。
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
对您考虑过的所有解决方案或功能的简洁明了的描述。
Additional context
Add any other context or screenshots about the feature request here.
在此处添加有关功能请求的其他任何内容或屏幕截图。

直接用代理软件不行吗？


支持cspider数据集训练

我想用lgesql在中文数据集cspider上训练，我要怎么做呢？

Two schemes：

Use an off-the-shelf translator to translate Chinese question into English, and directly apply the model.
Use a multi-lingual PLM to replace BERT. Notice that the schema linking strategy in preprocessing script should be revised to support cross-lingual matching, or use nomatch as a baseline.


svelte-add/postcss now creates global.postcss rather than global.css

I was having a weird issue experimenting with a new project built npm init @vitejs/app (svelte, typescript) and npx svelte-add tailwindcss. The demo page looked fine but adding inline classes (e.g. Visit) had no impact.
I believe I have traced the cause to this change to  svelte-add/postcss which renames src/global.css to src/global.postcss. Unfortunately this means that  svelte-add/tailwindcss fails to add tailwind into the new global.postcss file.
Manually adding:
@tailwind base;
@tailwind components;
@tailwind utilities;

to  src/global.postcss fixes the issue (but does break the alignment of the svelte logo!).
I believe that the new filename needs to be added here.

Thanks, had this issue as well, and the fix works.
I set up my environment with the following:
npm init @vitejs/app
cd vite-project/
npx svelte-add tailwindcss --jit
npm i
npm run dev


XOR Cipher Challenge

Simple OTP cipher, which when broken gives the flag.

Layout of the challenge:

What we provide :
Plaintext.txt
Plaintext.cryp
Flag.cryp
In order to solve the challenge, one must XOR Plaintext.txt and Plaintext.cryp to get the key.
Once the key is obtained, one has to XOR key and Flag.cryp to get the flag.

Still have to test if the currently created files would satisfy this challenge.


Laggy Search/Temp Non-responsive

I was using an older version until recently, 1.8.4 I think, upgraded to 2.0.2 this week, linked my twitch account and such, compared to the older version the channel search is laggy, it eventually comes up with the videos to select, but it is considerably slower than before, and immediately does that thing where the cursor turns to a blue loading circle and the program basically freezes until it finishes.
Updating to 2.0.3 didn't fix it. Also I uninstalled and did a clean install just to see if that was causing it, no dice.
I'm on Windows 10 64 bit, this happened with all the usual channels I grab from, (temmies ProtonJon Kazeugma)
This happens whether I'm searching by a date range or X amount of videos, it seems like this is when using the Channel search specifically, I just tried putting a single video URL into the URL tab and it didn't lag or freeze up.

Yep, welcome to the new Twitch API, where "new" means "slow" and includes rate limits per application and user in order to "not overload the servers". You feel the result right there 😄
Searching for dates is the most intense search you can make, it needs a lot of requests, especially if you search for old videos.
That's not on me, sry

Ahh, damn, that's a shame, oh well, thanks for letting me know, I'm sure I can put up with it if it's not something that's fixable. ^_^ Cheers!


Async Profiler and Java Flight Recorder are missing some methods at the bottom of the stack.

From a code perspective, the correct call order should be： Thread.run -> FastThreadLocalRunnable.run -> ThreadPoolExecutor$Worker.run -> ThreadPoolExecutor.runWorker
✅using jstack:

❌using async profiler:

❌using jfr ExecutionSample event:

This doesn't seem to be a bug with async profiler, any thoughts?

Did you added DebugNonSafepoints as suggested in the readme?

@franz1981 If it's really DebugNonSafepoints problem, then jstack will also show missing stack frame, however jstack shows  correctly.

Depends. If there is a safepoint poll within an inlined method, jstack can still observe (and blame it), while, without the option I've specified, both jfr and async profiler won't be able to do the same (loop striping can still add polls to counted loops).
Regarding your method: are you using CPU profiling? If yes, jstack has captured a WAITING thread which is not something a CPU profiler would show up, because...it doesn't consume CPU (unless in the precess of contending on some process futex to do it).

If it's not an async-profiler bug, will it be better to submit an OpenJDK issue instead?
If you could provide a reproducible example, I'd be happy to analyze that.
Btw, does the issue happen with other JDK versions or with a different CPU architecture?

How does --cstack vm work? Does it show missing frame?

How does --cstack vm work? Does it show missing frame?

jdk.ActiveSetting cstack value is fp when using --cstack vm，seems a bug？
https://github.com/async-profiler/async-profiler/blob/29b78f4670b58272ce5968774baed06381f8d0aa/src/flightRecorder.cpp#L71C1-L71C1
using command:
./asprof   -e cpu --cstack vm -d 60 -f p.jfr
jfr info:
jdk.ActiveSetting {   startTime = 08:40:06.344   id = 107   name = "cstack"   value = "fp"   eventThread = "Attach Listener" (javaThreadId = 2700) }

jdk.ActiveSetting cstack value is fp when using --cstack vm，seems a bug？

Yes, thank you for pointing out. I pushed the fix.

How does --cstack vm work? Does it show missing frame?

still not working with async-profiler-2.10-linux-x64
cmd ./asprof   -e cpu --cstack vm -d 60 -f  p.html

This does not look like a vm stack trace.
cstack=vm option appeared in async-profiler 3.0-ea.

This does not look like a vm stack trace. cstack=vm option appeared in async-profiler 3.0-ea.

cstack=vm mode is correct

the same host with cstack=fp

Thank you for the update. Good to know async-profiler's own stack walker works correctly. It will eventually replace JVM's AsyncGetCallTrace and become the default.

Thank you for the update. Good to know async-profiler's own stack walker works correctly. It will eventually replace JVM's AsyncGetCallTrace and become the default.

cstack=vm reads the symbol information (gHotSpotVMStructs) exported by the JVM, then finds the offset related to PCDesc, reads the corresponding data, and obtains the call stack information. Since the vm mode is correct, it can be inferred that the information of PCDesc is correct or enough, which has nothing to do with DebugNonSafePoint?

Yes, DebugNonSafepoints option may affect accuracy of the topmost virtual frames, but not a frame at the bottom of the stack.

Let me close the issue, since there is nothing to do on async-profiler side.


Request: The blue hand

When you select a device in Live it gets the blue hand symbol and the first up to 16 parameters of the device
will be automapped to a MIDI controller if there is a remote script running for this controller. But the data to
query is not exactly 'selected device', because you can lock the blue hand to a device, decoupling it from the
selected device.
This would make it possible to have 16 faders in TouchOSC and always have the names and values
of the selected device in access.
The data to query seems to be a song property called 'appointed device'.
I would assume that it returns track number and device number.
I don't think there are dedicated parameters like 'blue hand device parameter 1', instead you would use the
already implemeted device calls to handle the device after finding out which one has the blue hand.
So this would "only" mean to implement get/set(?)/listen appointed device.

Yep, looks like this would be a Song property, appointed_device (from docs). Would need a bit of additional logic to allow the API user to specify the object path of the device (e.g., track 2 device 3) and vice versa.


Add keyvault authorizer

Depends on https://github.com/Azure/go-autorest/pull/273
Thanks you for your contribution to the Azure-SDK-for-Go! We will triage and review it as quickly as we can.
As part of your submission, please make sure that you can make the following assertions:

[ ] I'm not making changes to Auto-Generated files which will just get erased next time there's a release.

If that's what you want to do, consider making a contribution here: https://github.com/Azure/autorest.go

[ ] I've tested my changes, adding unit tests where applicable.
[ ] I've added Apache 2.0 Headers to the top of any new source files.
[ ] I'm submitting this PR to the dev branch, or I'm fixing a bug that warrants its own release and I'm targeting the master branch.
[ ] If I'm targeting the master branch, I've also added a note to CHANGELOG.md.
[ ] I've mentioned any relevant open issues in this PR, making clear the context for the contribution.

Can one of the admins verify this patch?

Ugh yes, ideally the change would have been made in the latest branch (without the changelog/version update) then cherry-picked into master with the accompanying changelog/version.

Using PRs
https://github.com/Azure/azure-sdk-for-go/pull/1749
https://github.com/Azure/azure-sdk-for-go/pull/1752


The text field is partially hidden behind the keyboard

Hey !
First of all, thank you for this package.
I noticed that on iPad (iPad Pro 4th generation) in landscape mode, the text field was partially hidden behind the keyboard, as shown in the screenshot below:

This is an issue on some mobile devices as well. It might be worth looking into it. I will work on it over this weekend.

Hi @lively-bigyan do u got news about this ?


Could not find a declaration file for module t-writer.js

Hi @ChrisCavs
Thanks so much for this library, been using it heavily (e.g. skyledge.com and fleetfoundry.com)
I'm building a new website with Angular 12 and getting this strange error when I import it into my component:
Could not find a declaration file for module 't-writer.js'. '/Users/a../node_modules/t-writer.js/dist/t-writer.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/t-writer.js` if it exists or add a new declaration (.d.ts) file containing `declare module 't-writer.js';`ts(7016)

Is there a typings file for this by any chance? Or could this be something else interfering?
Thanks in advance!

The above same issue arises here too. Any solution ????

@rakeshbaral92 it seems this library isn't maintained anymore, I ended up switching to https://github.com/tameemsafi/typewriterjs#readme
it worked with Angular 12 perfect (checkout flowbench.io - I used it there)

Getting the below issue.
Could not find a declaration file for module 'typewriter-effect/dist/core'.
On Sat, Dec 4, 2021 at 6:42 PM Ahmed @.***> wrote:

@rakeshbaral92 https://github.com/rakeshbaral92 it seems this library
isn't maintained anymore, I ended up switching to
https://github.com/tameemsafi/typewriterjs#readme
it worked with Angular 12 perfect (checkout flowbench.io - I used it
there)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ChrisCavs/t-writer.js/issues/8#issuecomment-986025345,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHH6MNH6ADBSB2KDLFWATQDUPIHU7ANCNFSM5DUPJUHQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Thanks & Regards
Rakesh Kumar Baral (Mobile Application Developer)
[image: Inline image 5]
Nexus Technoware Solution Pvt.Ltd
(Microsoft Certified & STPI Registered Company)
(CIN : U72200OR2007PTC009685)
Branch Office
DCB: #430, 4th Floor, DLF Cyber City,
Chandaka Industrial Estate, Patia, Bhubaneswar, Odisha 751024
Contact No- +91-8260003333,+91-9778209633,+91-9438148250
http://www.ntspl.co.in & http://www.ntsplhosting.com
Registered Office
Plot No- 1692/4371, Nalini Nilaya, Green Park, Kalarahanga
Near Kripalu Residency, Patia, Bhubaneswar - 751024, India
https://www.facebook.com/ntspl https://twitter.com/ntspl
https://in.linkedin.com/in/ntspl
https://www.youtube.com/user/ntsplhosting

This is an old thread and the project seems to be unmaintained for years, so I forked it and added TS type declarations and updated the build dependencies -<EMAIL_ADDRESS>Using it on an Angular 17 project and works well.


'rv-checked' not working with radio inputs

rv-checked binding works fine with checkboxes, but not with type='radio'. Can someone check this or is there some trick to make it work for radio type?
I'm using latest rivets.js version.
<input type="radio" rv-checked="opt.active" rv-name="opt.name"></input>

UPD: just realized that rv-checked on input[type=radio] converts boolean value in model to "on".
Am I misunderstood something or it's a bug?

<li rv-each-color="view.colors">
  <input type="radio" rv-value="color" rv-checked="user.selectedColor">
</li>

This correctly injects the selected value in the UI, BUT the data won't be bound and I can't figure it out for the life of me...
We need rv-each and we also need the data to be two-way-bound to the model. How can we do that?

@andras-sallai-planorama Here is a working jsfiddle similar to to the examples detailed above.
It should demonstrate that the value is properly bound. If you change the selected radio, it will change the bound input.
Can you make a jsfiddle, or give us some examples of your code to reproduce the issue you are having?

Hi Mikeric,
Could you please leave a note in the binder references about the checked binder referring to the value, and not a boolean, when bound to a radio? I would have expected it to be a boolean indicating whether the item is selected or not, I spent a long time trying to work out what I was doing wrong...

Agreed, the documentation leads a user to believe that rivets sets the model value to a boolean rather than to the value of the radio.

I second what @andrewjw1995 said. I just spent 10-20 minutes figuring this out by looking at the source code. Would be happy to submit a pull request if you're open to it, @mikeric

This is how radio inputs work normally in html. Do you think rivets should break this? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
Or is it just a problem with the docs?

Just a problem with the docs.

Hey!
I actually run into a possible related issue, where rv-show and rv-hide don't follow the state of a radio-button (even though the text interpolation is). Here are more details https://jsfiddle.net/yhy6w5z9/6/


Add lang and version labels to containers

The following labels are added org.testcontainers.lang and
org.testcontainers.version. Those are good identifiers when debugging
and sharing logs.

good catch @bsideup! thanks!


JUnit assertThrows

Code could be cleaner if it could be Java 1.8.
I could set <maven.compiler.testSource>1.8</maven.compiler.testSource>... thoughts???

I am ok with Java 8 but others might not be. May you please bring this up on the dev ML? It would be better if using Java 8 would bring benefits to the main code.

@garydgregory have continued assertThrows email about maven.compiler.testSource.
About the jdk 1.7 build failure, i'm not sure exactly what the issue is as from what i'm aware i've not touched anything to do with japicmp/maven/JApiCmpMojo

Could this get another review and try and get it merged.
I'm leaving asserting the exception messages, as it's good practice. You write a test with a set input, the output is also important.

@garydgregory breaking it out into separate pr's, as i keep needing to rebase and often face merge issues, so easier if 1 pr per test. then it might be easier to get them reviewed and merged quicker.
https://github.com/apache/commons-validator/pull/92
https://github.com/apache/commons-validator/pull/93
https://github.com/apache/commons-validator/pull/94
https://github.com/apache/commons-validator/pull/95