Extension proposal for zarr accumulation

This PR contains the Zarr extension proposal for a method that we developed at NASA GESDISC -- Zarr-based Chunk-level Accumulation, which provides fast and cost-efficient data analysis services based on chunk level statistics. The proposal mainly includes the Zarr group structure and attribute schema for the chunk level statistics.
This related PR against zeps repo is here.

Thanks for this proposal.   It seems like it may make sense to specify the stride in units of elements rather than chunks.  Then this would more generally also cover downsampling.

Thanks for this proposal. It seems like it may make sense to specify the stride in units of elements rather than chunks. Then this would more generally also cover downsampling.

Thanks for your feedback @jbms !
Yes, it will be great that we can make this approach more flexible by specifying the stride in units of elements rather than chunks, but I think it probably okay to save the aggregation statistics at the chunk level since:

Chunk is the smallest transaction unit (IO, compression, filtering and etc), and performance-wise it should be okay to have the aggregation statistics aligned along the chunk boundary (since we need to load the whole chunk anyway).

Setting strides at element level may increase the coding complexity quite a lot.

More importantly, setting strides at chunk level doesn't mean the averaging/aggregation service can only be provided at chunk level. The end users can specify any random temporal range or bounding box, and the internal stride setup should be transparent to them. The application needs to locate the strides at the corner of the averaging boundary, and the averaging/aggregation result will be some simple linear combination of the accumulation values of these strides and internal values inside these chunks at the boundary.

@hailiangzhang As I mentioned at the meeting today, it would be very helpful if you can provide some mathematical formulas or pseudocode that describes which cumulative sums you are storing.  Your proposal describes the attribute schema but doesn't seem to describe exactly which sums are actually being stored, or how to compute the weighted sums based on the stored values.
It occurs to me that the following strategy would accomplish the goals of your proposal and might be similar to what you are doing:

A summed area table A for a variable X(i, j, k) is defined by: A(i, j, k) = sum_{i1<=i, j1<=j, k1<=k} X(i1,j1,k1).  I think this is the strategy you described in your presentation as the standard accumulation strategy.  This can be computed in linear time, and allows the sum over any region to be computed with 2^n reads of A, where n is the number of dimensions (3 in this case), but as you noted can run into numerical precision issues.
Instead of storing A fully, we can store only the values A(i, j, k) where i, j, or k is a multiple of some stride ci, cj, ck (e.g. the zarr chunk size), i.e. just the positions on a chunk boundary.  This can be computed with the same cost as computing A fully.  The storage cost will be approximately 1 / ci + 1 / cj + 1 / ck.
To compute the sum over any region, we need to be able to read the 2^n values from A.  To do this, for each read we can reconstruct the necessary chunk of A by reading the stored values of A at the boundary of the chunk, and reading the content of the corresponding chunk of X.  This takes time linear in the size of the chunk.
To efficiently store the values of A only at chunk boundaries, we need to somehow pack it into some number of dense arrays.  The simplest way to do that would be to have a separate array for each dimension, i.e. Ai(i, j, k) = A(i * ci, j, k), Aj(i, j, k) = A(i, j * cj, k), Ak(i, j, k) = A(i, j, k * ck).  This does mean we redundant store values that are on the boundary in more than one dimension, though; a more complicated stored representation could potentially avoid that.
This strategy still does not solve the numerical precision issues, so I suspect it is not exactly the same as what you are doing.

Any clarification you can offer would be very helpful.

@hailiangzhang As I mentioned at the meeting today, it would be very helpful if you can provide some mathematical formulas or pseudocode that describes which cumulative sums you are storing. Your proposal describes the attribute schema but doesn't seem to describe exactly which sums are actually being stored, or how to compute the weighted sums based on the stored values.
It occurs to me that the following strategy would accomplish the goals of your proposal and might be similar to what you are doing:

A summed area table A for a variable X(i, j, k) is defined by: A(i, j, k) = sum_{i1<=i, j1<=j, k1<=k} X(i1,j1,k1).  I think this is the strategy you described in your presentation as the standard accumulation strategy.  This can be computed in linear time, and allows the sum over any region to be computed with 2^n reads of A, where n is the number of dimensions (3 in this case), but as you noted can run into numerical precision issues.
Instead of storing A fully, we can store only the values A(i, j, k) where i, j, or k is a multiple of some stride ci, cj, ck (e.g. the zarr chunk size), i.e. just the positions on a chunk boundary.  This can be computed with the same cost as computing A fully.  The storage cost will be approximately 1 / ci + 1 / cj + 1 / ck.
To compute the sum over any region, we need to be able to read the 2^n values from A.  To do this, for each read we can reconstruct the necessary chunk of A by reading the stored values of A at the boundary of the chunk, and reading the content of the corresponding chunk of X.  This takes time linear in the size of the chunk.
To efficiently store the values of A only at chunk boundaries, we need to somehow pack it into some number of dense arrays.  The simplest way to do that would be to have a separate array for each dimension, i.e. Ai(i, j, k) = A(i * ci, j, k), Aj(i, j, k) = A(i, j * cj, k), Ak(i, j, k) = A(i, j, k * ck).  This does mean we redundant store values that are on the boundary in more than one dimension, though; a more complicated stored representation could potentially avoid that.
This strategy still does not solve the numerical precision issues, so I suspect it is not exactly the same as what you are doing.

Any clarification you can offer would be very helpful.

Hi @jbms , thank you so much for writing down what's in your mind! I believe we're mostly aligned, except for some lower level details. As you suggested, I will provide some code so you can look into it closely, but it may take some time as I mentioned. But I can try to provide the formula (similar to what you have done) ASAP.
Meanwhile, just to make sure we are on the same page, in this formula you listed above Ai(i, j, k) = A(i * ci, j, k), is i, j, or k still "a multiple of some stride ci, cj, ck (e.g. the zarr chunk size)"?

Meanwhile, just to make sure we are on the same page, in this formula you listed above Ai(i, j, k) = A(i * ci, j, k), is i, j, or k still "a multiple of some stride ci, cj, ck (e.g. the zarr chunk size)"?

Sorry, I realize my notation wasn't very clear.  I updated my comment to use the notation: Ai(ic, j, k) = A(ic * ci, j, k), so that I'm not using i in two different ways, and added an example with the sizes of the different arrays.

Independent of these details, I think it is clear now that this exists as an additional layer entirely on top of zarr itself.  I'm still interested in learning more about this proposal, and happy to provide further review/feedback, but per discussion at the ZEP meeting today, it appears that this proposal may not be a good fit for the ZEP process itself.
The ZEP process is intended for changes to the zarr specification itself, and is intended to gather feedback from zarr implementors.  This proposal more naturally exists as a layer entirely on top of zarr itself and requires no changes to zarr implementations like zarr-python.  Therefore, it may make more sense for you to publish this standard independent of the zarr specification, as an external extension, similar to OME-zarr.  If in the future we have a website that links to external extensions it could be included there.

Independent of these details, I think it is clear now that this exists as an additional layer entirely on top of zarr itself. I'm still interested in learning more about this proposal, and happy to provide further review/feedback, but per discussion at the ZEP meeting today, it appears that this proposal may not be a good fit for the ZEP process itself.
The ZEP process is intended for changes to the zarr specification itself, and is intended to gather feedback from zarr implementors. This proposal more naturally exists as a layer entirely on top of zarr itself and requires no changes to zarr implementations like zarr-python. Therefore, it may make more sense for you to publish this standard independent of the zarr specification, as an external extension, similar to OME-zarr. If in the future we have a website that links to external extensions it could be included there.

Hi @jbms , yes, I was totally aware that this proposal is on top of Zarr itself. Actually I did mention this concern at some point, and was suggested to file a Zarr extension, instead of spec, proposal. Honestly I got a feeling before as well that this proposal may not be necessary to stay in Zarr core spec repo, and yes, we can host the spec as an external extension, similar to OME-zarr, and I will provide a link when it's in-place. Thanks a lot for your suggestions!

A more precise specification of this proposal would definitely help, as the current proposal does not seem to indicate precisely what calculated values are stored.
To me, a zarr extension is something that must be implemented by the zarr implementation itself, e.g. zarr-python.  In contrast, something like ome-zarr is "layered on top of zarr", and makes use of a zarr implementation but does not require any changes to the zarr implementation.  In principle the same package could implement both zarr and ome-zarr together, but likely would still employ a layered architecture where there is a lower-level "zarr" layer and then an ome-zarr layer on top.
This proposal seems like it falls under the "layered on top of zarr" category:

It can, and has been, implemented without any changes to the zarr implementation.
The additional information is stored as additional regular zarr arrays and zarr user attributes.
It relates to an operation (computing certain weighted sums) that is not normally provided by the zarr implementation itself.
The additional information is, I think, computed as a batch operation after the base array has already been written.  Likely this would be done using a distributed processing framework like dask, which might be outside the scope of a zarr implementation.

Thanks for your responses @rabernat and @jbms !
Actually this proposal is probably comparable to the approach used in the Xarray library, which introduces specific fields such as _ARRAY_DIMENSIONS within Zarr attributes to facilitate the implementation of the Xarray library, allowing it to provide labels and support operations on named dimensions within Zarr arrays. Similarly, this proposal introduces schemas to the data group and array attribute to describe the chunk level statistics and facilitate accumulation-based data analysis.
I remember at some point it was mentioned that the Xarray spec should have been incorporated into the Zarr specification, so I thought this proposal may be a candidate too. However, I must acknowledge that there may be some finer details or guidelines that I've overlooked. Regardless, I am comfortable proceeding in whichever direction aligns best with the existing guidelines:)
BTW, @jbms , despite this, I remember you have been asking for some source codes to help you understand some low level details. My apologies for not being able to dedicate more time to this task, but a cleaner version of library to prepare the accumulation data should be coming up very soon and will keep you updated.

Hi @MSanKeys963 @jbms @joshmoore @rabernat - we would like to submit this work for consideration of a The White House Office of Science & Technology Policy Open Science Recognition Challenge - https://www.challenge.gov/?challenge=ostp-year-of-open-science-recognition-challenge. Do I have your permission to list you all as collaborators? The form is rather simple, there is no formal way (i.e. adding emails etc), just wanted to at least list the names/affiliations. Also am I missing anyone else that may have helped push this forward (@hailiangzhang)?

I don't think my own involvement in reviewing this proposal is sufficient to be listed as a collaborator.
I actually would still very much welcome some clarifications about precisely how the cumulative sums are stored during the precomputation step and how they are used to compute the result of a query, so that I can better understand this proposal.

Hi @briannapagan. No objection to being listed, and generally happy to do what I can to recognize open science! 😄

Same as Jeremey, I don't think I've done anything to merit authorship here. IMO lots more work needed to move this forward.

Thank you for the responses all! @hailiangzhang will provide some updates as there's been quite some work done since March. However, I think at this time we will skip submitting anything for recognition but might be of interest for your other zarr efforts! Cheers.

Thanks for the update, @briannapagan.
This a bit of short notice, but it'd be great if you or @hailiangzhang could join the ZEP meeting today or the next one on (12/14) so that we can move this forward and assist you in any way possible. Thanks!


ensure sane handles

All kinds of special characters that are not explicitly replaced as transliterations are currently allowed in handles, which sometimes leads to strange side effects. Proposing a saner approach here.

This can be rebased and resubmitted for merging now

the new handle function is createHandleOptimised and it uses the new function truncateHandle.

I found the truncateHandle function a bit hard to understand, so I went with a simpler approach.

it now includes code to allow the handlizer to be configured

Since we're now aiming for a 3.0.0 release, this is no longer necessary and I simply changed the existing function.

I created a simple benchmark to compare the old and new versions

Could you please update and re-run your benchmark with my new version?

Regarding migration, I guess we need a way to update existing handles in the database with the new function. For the most part, there won't be any differences between old and new handles. But some might  still contain nasty characters that are no longer allowed for new handles.

The only way to update handles in the database is to blanket assume that every single column in the Symphony schema (tbl_) that is named handle was produced by Symphony. Are we ok with that?
Do we actually have any concrete examples of handles before and after this change? Or is this 'in theory the code allows it'?

Are we ok with that?

I am!

Are we ok with that?

I'm pretty much in the dark regarding possible side effects, so I really can't make an informed decision here. I trust you with this.

I'm pretty much in the dark regarding possible side effects, so I really can't make an informed decision here. I trust you with this.

It means if a field or extension also has a handle column, but it's not actually been generated by Symphony, then potentially we will erase/modify data. It also depends on the answer to my previous question

Do we actually have any concrete examples of handles before and after this change? Or is this 'in theory the code allows it'?

Do we have a clean cut example to say, if you're handle was big-red-dog, it will now be big-red-cat. This is important for the release notes, because usually handles form URL's, so if there is someone who is using a URL, such as example.org/big-red-dog/, it would be great to warn them and say, that link is actually now going to be example.org/big-red-cat/. Particularly important if the link is being referenced elsewhere (other websites, or worse, in print).
So, do the benefits of this change outweigh the risks?

if you're handle was big-red-dog, it will now be big-red-cat

All non-word characters ^/w except - will be stripped out and truncation of very long handles might be slightly different. So I don't expect too many changed handles except a few edge cases, which might have caused problems anyway.

So, do the benefits of this change outweigh the risks?

Definitely. I actually ran into issues a couple of times when clients copy pasted text with certain characters that weren't replaced by transliterations and remained in the handle.

Rebased and edited as suggested.

Oh, this would make my last issue pointless of course.


added the issuer checker, with node in-built test functionality

please let me know what logic i need to revisit

dropping this pull request as deprecated


automatic import confuses relative paths and package imports

TypeScript Version:  3.0.0-dev.20180628

Search Terms: import path, relative
Code

clone https://github.com/fimbullinter/wotan
yarn

creates a symlink node_modules/@fimbul/<name> for each packages/<name>

create a new file packages/mimir/src/test.ts and paste the following content:expressionNeedsParensWhenReplacingNode;
getWrappedNodeAtPosition;
AbstractRule;

add imports for all identifiers using quick fixes

Expected behavior:
import { expressionNeedsParensWhenReplacingNode } from "./utils";
import { getWrappedNodeAtPosition } from 'tsutils';
import { AbstractRule } from '@fimbul/ymir';

expressionNeedsParensWhenReplacingNode;
getWrappedNodeAtPosition;
AbstractRule;

Actual behavior:
import { expressionNeedsParensWhenReplacingNode } from "@fimbul/mimir/src/utils";
import { getWrappedNodeAtPosition } from '../../../node_modules/tsutils';
import { AbstractRule } from '../../../node_modules/@fimbul/ymir/src';

expressionNeedsParensWhenReplacingNode;
getWrappedNodeAtPosition;
AbstractRule;

Playground Link:
Related Issues:
#25029

Fixed by #25364.

@trichetriche Could you check to make sure you're using typescript@next in the editor?

I'm home now but I will definitely do that tomorrow. Is that at project level, or should I install it in VSCode ?

Install globally with npm install -g typescript@next, then set typescript.tsdk to point to npm's global install location. (See the linked instructions from above.)

Okay, I installed typescript@next and set up VSCode to use the local version of typescript and it works like a charm ! I didn't know you could do that, thank you for teaching me this :)

forcing people to install stuff globally. not cool 👎 but I guess that's a quick fix right ?

@andy-ms :+1:

@Hotell I fixed this yesterday just by creating a new folder somewhere, runnint npm init and then npm install typescript@next in that folder. Then I linked the VS Code setting to that folder:
{
    "typescript.tsdk": "/PATH/TO/MY/FOLDER/node_modules/typescript/lib"
}

That works perfectly (and without global installs) for me, using VS Code on MacOs.

This works if there is only one node_modules directory in the project structure. In my case the structure is as follows:
|-- Project
    |-- Core
    |   |-- src
    |   |-- node_modules
    |       |-- redux
    |   |-- tsconfig.json
    |   |-- package.json
    |-- App
        |-- Source
        |   |-- client
        |   |-- node_modules
        |       |-- redux
        |   |-- tsconfig.json
        |   |-- package.json
        |-- App.code-workspace

I'm working with the workspace that references both folders (App, Core).
When working on files within Core/src, import autocomplete works fine:
import { Reducer } from "redux";
But when I work on files within App/Source/client, IDE suggests relative path:
import { Reducer } from "../../../Core/node_modules/redux";
Is there something that needs to be added in tsconfig.json files?
Please note, in 2.9.x both cases didn't work, in 3.x.x the first case works as expected.

Please reopen this issue

it's exactly the same issue.
clone this repo: https://github.com/gizm0bill/multi-apps and yarn (it's using yarn workspaces)
try to edit any file from ./src/pkg and select some import from the autosuggest list

@gizm0bill Could you be more specific? I went to src/pkg/app-three-js/app/index.ts and commented out NgModule and added a completion for it and it correctly added import { NgModule } from '@angular/core';. Also, are you using typescript@next?

ah no no, I'm on 2.9 in fact. would that be the problem?

You should be able to npm install -g typescript@next for a global install independent of the one angular uses; then set up your editor to use that.


Menu hotkey testing

FINALLY!!

Coverage decreased (-0.1%) to 29.083% when pulling 2afd3aa5cfad240b396cfd5089c9fb3f1ea2cd9c on jsantell:menu-hotkey-testing into 1c03222edc80d83440e794d107bafb80c1205972 on mozilla:master.

Coverage decreased (-0.1%) to 30.547% when pulling 1c70ef693fe47bd2b6b1951ebe6975be6944c5be on jsantell:menu-hotkey-testing into f80713d7ae1d356083e66241bc0204e938c3d6eb on mozilla:master.

I have two thoughts about this PR:

I think we should work out how to add this type of test-only message up front, before it gets hard to do so.  Can we use Spectron to trigger the addition of the listener?  Or do we need to set an environment variable or a command line option?

I think it's not wise to test this type of interaction using the UI.  I tried to test link clicking (option-click, target=_blank) in this style and it's even harder to do using the UI.  I rigged up a Web Socket server to let the test ask all BWs for their state, which made for much better testing.  However, I think the better thing to do is find a way to add "test middleware" to the UI store which reflects to the test (which then captures) the actions (and not the state) flowing through the UI Redux loop, so that our tests can assert "interaction X produced Redux action Y".  This is better than "interaction X produced Redux state Y", since we then have freedom to change the details of what actions do.  And it's much better than "interaction X produced UI DOM Z", which is just frustrating to work with.

In many ways, we have an opportunity to tap the message stream of the browser at a very low level.  Imagine how much easier Firefox testing would be if we could do this!

I have two thoughts about this PR:
I think we should work out how to add this type of test-only message up front, before it gets hard to do so. Can we use Spectron to trigger the addition of the listener? Or do we need to set an environment variable or a command line option?

If we can determine if we're in a testing environment in the main process, we can do that; but that depends on kinds of tests we're running. I don't think this is implemented yet AFAIK?

I think it's not wise to test this type of interaction using the UI. I tried to test link clicking (option-click, target=_blank) in this style and it's even harder to do using the UI. I rigged up a Web Socket server to let the test ask all BWs for their state, which made for much better testing. However, I think the better thing to do is find a way to add "test middleware" to the UI store which reflects to the test (which then captures) the actions (and not the state) flowing through the UI Redux loop, so that our tests can assert "interaction X produced Redux action Y". This is better than "interaction X produced Redux state Y", since we then have freedom to change the details of what actions do. And it's much better than "interaction X produced UI DOM Z", which is just frustrating to work with.

We do this for action tests -- tap into action/state cycles. There's no way to use electron outside of spectron. The UI interaction here is just closing tabs (which I agree isn't great, but neither is having hotkeys break every week) and isn't looking deep into the browser chrome state. To deal with frustrating of windows being indistinguishable in webdriver, maybe we could expose an ipc command in a browser window to return state so that tests can use it. Also, dispatching actions via IPC (similar to main->renderer communication) to do things like close tabs -- is that what you're suggesting?

Coverage increased (+0.03%) to 30.717% when pulling 56d86a50d56aef309fdc63d39b8180e4706b0868 on jsantell:menu-hotkey-testing into f80713d7ae1d356083e66241bc0204e938c3d6eb on mozilla:master.


TestFrameworks: Add Boost.Test support for discovering test cases

Add heuristics for guessing available test cases for Boost.Test binaries. This uses the symbol naming and namespaces to make a best guess of the available test cases, which works fine as long as the developer is using the boost provided macros for defining test cases and suites. Doing a real detection that covers all corner cases around manually registered tests would pretty much require running the test binary and extracting the list from internals after the program has started.
To do:

[x] add unit test
[x] remove some debug spam
[x] Handle templated test cases (might be affected by -fno-rtti)

Doing a real detection that covers all corner cases around manually registered tests would pretty much require running the test binary and extracting the list from internals after the program has started.

There is exactly the same problem with GoogleTest: if it's not a simple or more-or-less simple test, then we are screwed. So far the strategy was to ignore such edge cases, but it may change :)

I think this is ready for review now.

TBH the effort to fake the test framework was a lot bigger than I originally expected. I believe that other frameworks may be lower effort though because, Boost...


Fixed issue #9514

Issue Reference
Fixed issue #9514

@shivendra-webkul
Checked and Found that the issue has been fixed as validation is working fine and also we are unable to save the details.
Screenshot
https://prnt.sc/Vh0REm_Ymka8
https://prnt.sc/4PA33fc-0ExK


feat: allow remote chrome instance

Depends on #53
Fixes #41
Fixes #42

Firstly, thanks a lot for working on this. Really appreciate your time and effort. Globally, I see that we are in a good direction. However, I have few ideas and suggestions to improve it further.
Major:

I think the signatures of functions would be greatly simplified if we use remote chrome instance always. The difference will be who manages the life cycle of the chromium instance.

In k8s context when chromium is deployed as side car container, it is k8s that will manage the life cycle of chromium. The operator will configure the plugin to use the chromium instance running in sidecar by setting up the chromium URL in the plugin config.
In bare metal deployment when there is no external chromium instance running, the plugin will start a chromium instance in a sub process and it sets the chromium URL in the config.

In both cases chromium will run outside of plugin and the difference will be the manager of chromium instance. This way, we always use the same chromium instance and avoid spinning up a new chromium for each request in bare metal deployments. This will also allows us to do all chromium related config in NewApp function and just use the remote chromium instance to make requests from client and report methods. What do you think?

Minor:

I dont see the need of ability to configure chromium URL from Grafana UI. I mean in k8s context, we cannot change URL (either name or port of sidecar container) without restarting the pod. So, it should be like the config parameters appUrl, skipTlsCheck that should be provisioned in the config file during deployment. What I think a better enhancement will be able to configure these parameters from env vars. Currently, plugin reads appUrl from GF_APP_URL env var. We can fix a env var for skipTlsCheck (like IGNORE_HTTPS_ERRORS like grafana-image-renderer does) and one for remoteChromeAddr (like CHROME_URL) so it will simplify deployments in k8s as there is no need to maintain a config file.

These are some initial thoughts. Let me know what do you think. If you dont have time to implement these changes, it is totally fine. I can work on them on the top of your branch. You have already done great job in putting up these PRs.

Looking closely into the PR, I see that we are still creating a new browser instance for each request (either remote or local). However, in your gist you were using the same browser instance with different tabs. Is there any reason why you did not implement it that way? I mean using multiple tabs on same instance of browser.

Thanks a lot for your patience.

in general a fan of small, minimal PRs instead big PRs which refactor everything.

I agree this strategy when we are working with well refined code base. However, the current plugin is far from ideal. I had to hack something fast from existing reporter app for our needs and I managed to do so. But as you must have noticed, the code base is bit distorted. So, I prefer not to fragment the code more but to re-organise it.
I managed to clean it up a bit and I hope the backend is more easy to follow now. Consequently there are lot of conflicts now. Sorry about that!

Normally, the local chrome instance could be also something which is starting at plugin start and then, each requests just creates a new tab, but then, failure tolerance needs to be implemented.

This is a big change I managed to do during this code clean up. Now a local chrome instance will be spun up when app instance is created and this instance will be reused everywhere by opening new tabs. Now if we find a remote chrome URL in the config, we instead create a RemoteAllocator here and return the context. Maybe we can rename that function as newBrowserContext which will be more appropriate. Normally that would be the only change and all the downstream code should work out-of-the-box. I think we should do a connectivity test if remote chrome is being used and to check if the remote instance is actually usable. What do you think?

Make a new network request for each report request resolve the issue of maintain a long-living connection.

This is what we are going to do. Create a new tab for each request and there is no need to maintain long living connection. When using local chrome instance, it is chromedp's reponsibility to manage life cycle of browser instance and this is what NewAllocExecutor does.

Grafana plugins should avoid using any environment variables, except something like GF_*

For appUrl we are already using GF_APP_URL and for skipTlsCheck, I added GF_REPORTER_PLUGIN_IGNORE_HTTPS_ERRORS. So, for chrome URL we can use GF_REPORTER_PLUGIN_CHROME_URL.

Grafana is planning to restrict environment variables for any plugin

The PR has been merged and it seems like it is operator that should opt out of passing server env vars to plugin. So, we are fine for backward compatibility. By supporting env vars, we give options to the operators.
If it is too much of a hassle to resolve conflicts, feel free to put up a new PR. I think the changes should be more straight forward now. Please let me know your thoughts!!
Cheers

What do you think?

By opening a network connection at the start of the application, we need to maintain and monitor the connection. What happens if the remote Chrome instance no longer exists? If we choose this method, we need to account for many factors.
On the other hand, creating a new connection for each report is efficient. The remote instance will not spin up a dedicated Chrome instance for each incoming connection. Instead, all connections share the same context. Chrome fully supports multiple remote debugging connections to the same browser, as detailed here: https://developer.chrome.com/blog/new-in-devtools-63#multi-client.
Setting up a connection for each report request has additional benefits. Users can choose different architectures on their own and run multiple Chrome instances as separate pods in Kubernetes. Since each report creates a new connection, the connections can be well load-balanced.
Additionally, instead of running and maintaining Chrome locally, end-users have the option to use Chrome clouds, such as https://testingbot.com/support/puppeteer/chromedp.html.
It is likely that some long-lived connections over the internet will be terminated from time to time.

By supporting env vars, we give options to the operators.

But it's not compliant with the standard interface for configuring a Grafana Plugin.
In context of Kubernetes, system operators could use different technics to provision plugins, for example with a sidecar.
operators has todo app provision anyways. https://grafana.com/docs/grafana/latest/administration/provisioning/#plugins
There are a lot of other options like logo and so on. They need it anyways I highly recommend to use that existing interface to configure that plugin.
Environment variables always requires a restart of Grafana.
Plugin configuration can be reload at anytime. In context of Kubernetes, system operators may use the sidecar for plugins anyways. (Example for datasources: https://github.com/grafana/helm-charts/tree/91d549c8e2b682f56919fa33115da04e507e263c/charts/grafana#sidecar-for-datasources ; but it exists for plugins as well https://github.com/grafana/helm-charts/blob/91d549c8e2b682f56919fa33115da04e507e263c/charts/grafana/values.yaml#L1059)
The benefits of using the plugin configuration interfaces is that settings can be changes without restarting grafana. Without restarting the reporter-app, which would affect running requests. Provision config configurations can be reload via HTTP as well (https://grafana.com/docs/grafana/latest/developers/http_api/admin/#reload-provisioning-configurations)
From that point of view, use environment variable instand the designed plugin interface would be a terrible design choice and has close to zero benefits.

For appUrl we are already using GF_APP_URL

Which is not necessary. The grafana SDK provide a public interface to get this information, without using os.getenv
https://github.com/grafana/grafana-plugin-examples/blob/0fd2458bc19d8925d1267998992a00c4c7b22622/examples/app-with-service-account/pkg/plugin/resources.go#L25-L26

I added GF_REPORTER_PLUGIN_IGNORE_HTTPS_ERRORS

I highly recommend to mark this as deprecation and remove it in the next major instance. Instead, provide a configurable setting via admin portal.
Sorry, but I highly recommend to avoid using environment variables. System operators should use the provision configuration.
Other Grafana tools like https://github.com/grafana/grafana-operator will never ever support this.

By opening a network connection at the start of the application, we need to maintain and monitor the connection. What happens if the remote Chrome instance no longer exists? If we choose this method, we need to account for many factors.

On the other hand, creating a new connection for each report is efficient. The remote instance will not spin up a dedicated Chrome instance for each incoming connection. Instead, all connections share the same context. Chrome fully supports multiple remote debugging connections to the same browser, as detailed here: https://developer.chrome.com/blog/new-in-devtools-63#multi-client.

You have a valid point for the deployments that use remote chrome instances. But for baremetal deployments this translates to spinning up a chrome instance for each request (which is how the actual implementation works and I guess we could improve that). I agree that in the case of plugin using remote chrome instances, a drop in ws connection can render the plugin unusable. So, I guess it is better to open a new connection for each request when we use remote chrome instance as you suggested.
In the deployments using local chrome instances, we can still spin up a single chrome instance when the plugin app is loaded. And we can interact with this single instance using remote debugging protocol using URL ws://localhost:9222 within each request. This way we can have same design pattern either for local or remote chrome instances. Both will open a new connection for each request. In the local instance, the plugin app will control life cycle of chrome instance.

There are a lot of other options like logo and so on. They need it anyways I highly recommend to use that existing interface to configure that plugin.

There is some misunderstanding here. I am not and never proposed to deprecate provisioning the plugin app with config file. To sum up, there are two ways to provision the plugin right now:

Using a config file installed at $GF_PATHS_DATA/plugins/reporter.yml as instructed in docs
From Grafana UI where users can modify the provisioned config.

Currently, all config parameters except, appUrl and skipTlsCheck can be modified from the Grafana UI after plugin has been provisioned. The reason why these two parameters are not configurable via Grafana UI is that they both are strongly tied to Grafana instance and it does not make to modify them without restarting the Grafana instance.
So, what I am proposing here is besides allowing configuring appUrl and skipTlsCheck using provisioning method, we can let operators to configure them using env vars. This is what the actual implementation does: defines JSON tags appUrl and skipTlsCheck in the Config struct, unmarshall the provisioned config into config instance and if env vars are passed, the provisioned values are overridden.
We are by no means obliging the operators to configure the app using env vars. They can use their regular provisioning methods by config file to configure the plugin and that will be always supported.
Imagine a use case where an operator is happy to live with "default" config for their deployment and the only thing that need to configure for the plugin to work is appUrl. So, instead of having to maintain and install a config file just to set this one parameter, they can simply inject that parameter into env vars. This is more relevant in baremetal deployments like ours where setting up a new env var in systemd is far more easier and practical. I hope that makes it clear.

Which is not necessary. The grafana SDK provide a public interface to get this information, without using os.getenv

Not quite sure about it. I remember playing around it (during december/january) and it always gave me empty config. Unless something has changed recently, we wont get App URL from the plugin context. But if SDK does expose this info now, that would make installing plugin far more simpler. It would be plug-and-play situation where operators do not have to worry about provisioning.

The refactoring PR #52 which include this PR also make appURL and skipTLS configurable.
In my case, appURL points to an external URL. In that case, the reporter plugins would go over the internet back to the public LB to the grafana.
The solution with define GF_APP_URL may not work, since Grafana will override the env variable again. Thats the reason, why I plan to make this configurable.
In general, #52 is replacing this PR.

In my case, appURL points to an external URL. In that case, the reporter plugins would go over the internet back to the public LB to the grafana pod. I have to set http://localhost:3000/ to skip any unnecessary hops.

I think you might have a point here. Could you please provide more details? You have configured server section on Grafana to point the domain to external URL? If so, how are you configuring it? Using .ini file or GF_APP_URL env var. If you are pointing something like GF_APP_URL=https://myserver.grafana.com for your Grafana, I agree with you that the plugin will always take this into account and will never be able to make requests to configured appUrl in the provisioned config. In that case we should use an env var that does not clash with Grafana config env vars. Maybe something like GF_REPORTER_PLUGIN_CALLBACK_URL.
Ok, I will look into the other PR and we continue the discussion over there.
Thanks a lot for your valuable inputs.


Osx test experimental, modify PATH in before_script section (travis)

export PATH in before_script section and maybe passing

fix PATH for sed. That's not a directory


Prevent the "Start a build for this project to get the freshest data?" notification from spamming

It pops up every time when a file is opened.
I don't even know what this notification means.
There should be an option for disabling this notification (in fact, every notification)
This is just annoying.

It seems like the notification would appear only when the .bsb.lock is missing.
https://github.com/rescript-lang/rescript-vscode/blob/9bbacb44196726549f36df2b3a205b0a701ff50f/server/src/server.ts#L144-L147
The notification becomes spammy if .bsb.lock is too short-lived.
Sometimes my .bsb.lock would keep getting deleted, but I don't know who did it.

IIRC .bsb.lock gets created/delete by compiler. As long as some bsb process is watching, .bsb.lock exists.

Sometimes my .bsb.lock would keep getting deleted, but I don't know who did it.

It might happen when you rebuild project often.

It should only pop up for the first file of a project you open? Is that not the case for you? Got a video?

Unfortunately I can't seem to reproduce it.
It happened after I converted everything from ReasonML to ReScript.
The problem only occurred in the first few hours, but I'm not sure what I did to stop it from spamming.
@arafatamin, @thezjy, @mickeyvip, @BlueHotDog, @darenju, @kgtkr, @FilipKittnar.
Hey sorry for tagging you, could you share your experiences and observations about this problem?

Now that you mention it, I think I had the same problem than you: converting from ReasonML to ReScript.
I have not tried to make a new project using ReScript directly (partly because of the incomplete syntax highlighting), so I cannot say if the problem goes away after some time, or just after the first file was open.

It should only pop up for the first file of a project you open? Is that not the case for you? Got a video?

@chenglou , this happens very inconsistently but this morning it actually happened so I took a video. It can be seen how the .bsb.lock keeps appearing and disappearing when switching between .res files. But as I said, this happens inconsistently. Yesterday it was fine.
https://u.pcloud.link/publink/show?code=XZ9oY4XZA5FnABEd1qf7DraQFzJsbYaIlday

I'm suspecting that this happens when there's only ONE .res file opened at a time.

I'm suspecting that this happens when there's only ONE .res file opened at a time.

If that's the case, then I think it's a logical design rather then a bug.
But we still need to make it less annoying.
We need some sort of "debouncing" to make .bsb.lock live longer.
I'm wondering if it's possible to store "timestamp" in .bsb.lock (now it's just some number)

I'm not 100% sure about this but it seems to help to really wait a while (around 1 minute) after you click "Build" and before you switch to another file. After that it seems that the .bsb.lock file doesn't disappear.
Or of course you have the good old way of disregarding the plugin build and do your own bsb -make-world -clean-world -w .

There's some design discussion on an alternative workflow that does not depend on starting a watcher from within the editor. Still, it's speculative at the moment.

Maybe this should be made configurable? So that you can at least turn it off if it annoys you.
Happy to help guide anyone interested in taking a stab at contributing a PR that makes showing that dialog configurable.

@zth Hello :) I would be happy to start my journey of becoming a contributor to rescript ecosystem with this issue.

@carere awesome! 😄 I'll get back to you this weekend with some ideas of how I think this one could be implemented.

@carere ok, here's a rough breakdown of the task as I see it. This can be a bit tricky due to a few reasons, so bear with me (cc @cristianoc so you can weigh in on the solution too).
Essentially, what we'll want to do is:

Register a global configuration option for disabling the message.
Ensure that the message never shows unless the configuration allows it.

A crash course in how the extension works (this is only half true, but should be enough for this task):

There's a client and a server. The client and the server communicates back and forth via messages.
Our client is very thin - it's essentially just the stock VSCode language server client, and a few other things bolted on top. The server itself (server.ts) is what's doing all of the heavy lifting.

For this particular functionality, what happens is the server initiates in a new ReScript project, sees the compiler isn't running, and sends a message to the client to show a window message asking if the user wants to start the compiler. This is all done here: https://github.com/rescript-lang/rescript-vscode/blob/master/server/src/server.ts#L186-L210
The client will present that message with an action that sends another message back to the server, asking the server to start the compiler. That's done here: https://github.com/rescript-lang/rescript-vscode/blob/master/server/src/server.ts#L916-L938
Now, configuration options are defined in VSCode, which the client has easy access to, but not the server. Therefore, I think we'll need to change the architecture slightly for this to be as simple as possible (which I think we should make sure it is, so we don't complicate things more than we need). Keeping the server from needing to know about the config option means we don't need to sync state back and forth between the server and client, given that the configuration option can change at any time, and the server would need to know about that, etc.
This is what I envision:

Register the new configuration option in the extension.
Register a new command (but don't expose it via package.json) that will do the same prompting for starting the compiler as is done automatically now via the window/showMessage message, but after checking the global configuration option.
Change the server so that it sends a message to the client to invoke the new command we just registered (plus whatever config it needs to present the message), instead of the current window/showMessage message that prompts the user directly. (you can check out the language server spec for how to tell the client to invoke a command)

This way we avoid the server needing to know about the configuration option all together.
Does that make sense? Please feel free to open a WIP PR as soon as you want, and we can continue the discussion in there.

@zth I have a small question about your envision. It seems that all we need is a global configuration before prompting the showMessage Start build only in client side. Do we need to change the server?

Looping back to this, me and @cristianoc talked some and we think it's best if we do indeed forward configuration to the server, because we'll have other use cases for that too. So @carere if you don't mind, please hold off on this for a little while as we sort out how we'll handle configuration on the server, and the work here will be much more straight forward.
Will reply back here once we've fixed that centrally.

@zth I have a small question about your envision. It seems that all we need is a global configuration before prompting the showMessage Start build only in client side. Can you explain your design to change the server?

Forgot to answer this, sorry... 😄  I think we mean the same thing, but call them different names. This is my view:

The client is the thin, stock VSCode language client we start in extension.ts
The server is in server.ts, and is a standalone process that the client communicates with via messages/responses
The analysis bin is the OCaml binary we use for more advanced functionality, and is a fully separate binary that the server calls into

@carere I ended up fixing this in https://github.com/rescript-lang/rescript-vscode/pull/432 because I needed something to test my changes with, and this was the only config I could figure out 😅

Ok, well I was waiting for further info since your last message 😅, anyway great news. I'll tag you on another issue 😉

@carere yes, sorry, I know I told you to wait. I'll make it up to you in the next one, I promise!

@carere if you're still looking for issues, there's one: if you miss accepting the notification when the editor is started, and the notification is gone, there's currently no way to start the build later (except restarting the language server). Also, presumably now that one can opt out of it via config, there's no way to start it manually just once, without going into the config.

@cristianoc Ok, so I guess we have to create a new command which can launch the build process in background?

I guess so. Another option is having a button just like the one for "Stop Code Analyzer".
It's totally possible to create too many of these things and clutter things up, so worth thinking about what's best. E.g. there's more real estate for commands than for buttons, and I don't know if all the rescript-specific things that look like a button can be grouped together etc.
Perhaps @zth. has some thoughts on this.

My 5c - I'm not a fan of running processes automatically like this from the extension. I've done a lot of this previously in the RescriptRelay extension, and I've had so many issues with orphaned watch processes staying around etc that I had to remove that feature. So my inclination would be to avoid auto running the watcher process at all because of the complexity/potential issues it brings.

There's also the completely opposite approach in the spectrum.
I.e. assume that it's always the user's responsibility to start the build and give the user hints on how to start a build if it's not started already. But don't do anything in the editor except for this information dialog.
In addition, offer a setting where the build is always started automatically without asking, so it's always the editor's responsibility and never the user's. If the user wished to opt into that.

In that scenario, one also needs to define what happens if it's not inside a project. Should the editor tell the user that the file is not part of a project.

We may create another issue and continue there ?
But it seems that the scope is more about handling the opening of a rescript file or a project folder.

@cristianoc oh yes, it's possible, but when I saw your recent messages, it feels like you were talking about what the extension should do when opening a file or a project.
Anyway, I'll work on the setting 😉


Fix: Dragging crew members to new roles throws an error

Dragging previously added crew members to a new role after reloading or restarting the application (for example when starting a new gaming session) throws the following error and you can't change roles.
starship.js:355 Uncaught TypeError: Cannot read property 'id' of null  at ActorSheetStarfinderStarship._onDragCrewStart (starship.js:355)
For some reason the Actor token is being referenced (which is not always available) when the actorId is already available in a constant in the same function. This small change fixes that bug so that reassigning crew members always works.

Nice catch! Gotta love weird edge cases ;) Merging.


Pcb interest

Hello, I saw your keyboard on kbd.news and was very interested. I want to make a hot-swappable zmk pcb. Can you provide the step file and frame dxf of the pcb?

I've updated the files you needed here:
https://github.com/EagleVee/keyboards/tree/master/vua-split/pcb


Expose sqlx Unsafe option

sqlx offers an Unsafe option, which prevents StructScans from erroring
out if they encounter an unexpected column. This is useful because it
allows adding a new column to a table without immediately updating the
corresponding model struct.
I exposed this option by adding a new connection details attribute,
"unsafe".

Superseded by #539


Rewrite

I started out fixing the issue with pasted in styles not saving, and ended up rewriting the script!
The rewrite is currently available in the rewrite branch. Once everything checks out, I'll merge it into the master.
I tried to test it as thoroughly as I could. Please put it through the ringer!
Here are a few changes to note:

jQuery dependency has been removed.
Settings have reset - the script now saves data instead of each individual setting.
Debug changes:

Enable debug - add ?debug=on to URL.
Disable debug - add ?debug=off to URL.
The change allows logging to continue when switching tabs.

I'm trying to start using ES2015 more, but because you will need to load babel to make it work, I've limited the script to use implemented parts. I'm still learning, so feel free to do whatever!

jQuery dependency has been removed.

Good call, that ought to give it a bit more speed. If you still want some of the convenience of jQuery, you could try bling.js, or my enhanced version.

Debug changes

Another alternative could be to use Greasemonkey's built-in "User-Scripts Commands" menu.

I'm trying to start using ES2015 more

With Safari Extenstions being unable to bypass GitHub's CSP, we only have to support Chrome and Firefox which should give us nearly 100% of ES2015, so no need for Babel.

I tried using template literal placeholders, but Chrome didn't seem to like it. Maybe I did something wrong.

Hmm, I've noticed that when I use the "Force update" button, after the page reloads the style doesn't apply. I see this error in the console

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src assets-cdn.github.com".

But if I reload the page using the browser button, everything is fine.

I tried using template literal placeholders, but Chrome didn't seem to like it. Maybe I did something wrong.
They should definitely work in Chrome since at least a few months.

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script

Hmm, smells like a Tampermonkey bug. Did you check the box to circumvent CSP in the Tampermonkey options?

Or you know, you could just drop the paste feature altogether. Recently, I just push changes to the style's master and force-update. If something doesn't work, I just force-push to master (yeah it's evil) to get rid of the commit.
Alternatively, you could set up a dev branch on the style and force-update from the URL to that branch on demand.

Tampermonkey is set to add itself to the CSP and I like the paste feature.

Hmm, can you narrow down that unsafe-eval error to a particular code line? If I recall correctly, the conditions for it to trigger can be pretty weird sometimes.

Took a look at the rewrite. Good job eliminating the ghd object. Overall, I'm not a big fan of those $variables when they're not jQuery object, but I guess old habits die hard :laughing:
If I might suggest, with my "helper" library, instead of
$files = $$('#files .file-actions'),
indx = $files.length;

while (indx--) {
  $el = $files[indx];
  // do something with $el
}

you could do
$('#files .file-actions').forEach($el => {
  // do something with $el
});

Sorry, just had to bring it up, feel free to ignore me :wink:

Isn't using while faster than forEach?... Well, I guess it doesn't matter in this case.
And naw, I appreciate the suggestions! I did look at your library, I will probably end up copying the on code over; but I'm trying to catch up with my TV shows on my day off. :wink:

Yeah, classic for and while are likely a tiny bit faster, but it won't matter unless you're iterating millions of elements. I exclusively use the array functions forEach (and some, every and the new favorite find) nowadays, they're just so convenient and easy to read!

Still gotta work on that library, by the way. For one, I'd like to have Node methods on NodeList too, so one can use the same syntax for one or multiple elements. Probably need a Proxy or something for that.

The script was tweaked again in https://github.com/StylishThemes/GitHub-Dark-Script/commit/e473ab96e196aed3b13c32fe8712499ebbbdd698 ... the debug setting is now set through the GM settings panel... and I removed almost all the $ from the variables :stuck_out_tongue:

I'm not sure which is better, but I found that you can use Array.from(NodeList) instead of NodeList.prototype.__proto__ = Array.prototype;.
I don't know if you'd want to change that in your squery library, or not.

The script appears to be stable, since I've been using it for a few weeks.


count_flops_params in nas,return 0

Describe the issue:
i use count_flops_params or thop.profile in nas
import nni.retiarii.nn.pytorch as nn
the flops/parameters is return 0
Environment:

NNI version:
Training service (local|remote|pai|aml|etc):
Client OS:
Server OS (for remote mode only):
Python version:
PyTorch/TensorFlow version:
Is conda/virtualenv/venv used?:
Is running in Docker?:

Configuration:

Experiment config (remember to remove secrets!):
Search space:

Log message:

nnimanager.log:
dispatcher.log:
nnictl stdout and stderr:

How to reproduce it?:

Please refine your issue by using compression template, thanks.

What‘s your network?

i find the problem and solve it
In counter.py，count_flops_params only count the flops of nn.Conv1d etc.
In this file，nn is torch.nn，only count the flops of torch.nn
but in nas task， nn is nni.retiarii.nn.pytorch，so replace the ‘import torch.nn as nn‘ by ‘nn is nni.retiarii.nn.pytorch’
count_flops_params  can work

Similarly，the thop.profile in nas count_flops task also return 0


x1219 (core)—As TS (Katy) I want to link the run name of the Xenium Analyser to the QC step and for the view to support this, in case labware is run twice

Scan in labware(s)
Select run name (given in Xenium Analyser operation)
Show on the view if the labware linked to the run name

Seems to refer to the Xenium QC operation.

View update: https://github.com/sanger/stan-sql/blob/devel/views/x1219_xenium_qc_run.sql


Transcribe Column Names

could you use better names than column_one, eg. instead of focus on the order, focus on what is to be displayed in column one?

Renamed columns variables to be more specific to the source that is represented in each particular function. The columns are defining which fields from the original data source should be represented in each column of our form. Kept column_one (two, three), but added a suffix to define the data source that is determining the values within the columns


webhook: handle error when reading request body

Pull Request Test Coverage Report for Build 3228

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 89.867%

Files with Coverage Reduction
New Missed Lines
%

data-access-layer/cf/TokenIssuer.js
1
98.57%

Totals

Change from base Build 3111:
0.0%

Covered Lines:
9350

Relevant Lines:
10057

💛  - Coveralls

Hi @shivansh ,
As discussed, closing this PR. Please include this commit with https://github.com/cloudfoundry-incubator/service-fabrik-broker/pull/704 if necessary.
Regards,
Subhankar


Debug Info: Encode let-bindings using DW_TAG_const_type.

This allows the debugger to distinguish constant "let" values from mutable "var" variables.
rdar://problem/16042546

test with https://github.com/apple/swift-lldb/pull/2015

Sorry for the long patch, it will get shorter, once https://github.com/apple/swift/pull/27238 has landed.

test with https://github.com/apple/swift-lldb/pull/2015
@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - ba52022f6144c238458992afdd51875ac8bbc4ff

test with https://github.com/apple/swift-lldb/pull/2015
@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 9bd1231a1efb72b6655f9a4388e62d16e9f48cb3

test with https://github.com/apple/swift-lldb/pull/2015
@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 2434f1772d6608d0727ca3c7251f522ffee74311

Build failed
Swift Test OS X Platform
Git Sha - ba52022f6144c238458992afdd51875ac8bbc4ff

test with https://github.com/apple/swift-lldb/pull/2015
@swift-ci test

test with https://github.com/apple/swift-lldb/pull/2015
@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - dadf3d6ff775c3e59eb70ca7be0728bc065ebd38

Build failed
Swift Test OS X Platform
Git Sha - dadf3d6ff775c3e59eb70ca7be0728bc065ebd38


Prepare ui mask for Angular 1.3

Tests are failing right now for 1.2 (but working on 1.3) because the ngMocks dependency is ancient (1.0.8), $error object in ngModel now aren't set to false/true anymore, but it doesn't exist when it's successiful, goes to the $$success object.

This PR seems to be obsolete. Moreover UI.Utils modules was split in individuals repositories. If still valid, please consider re-submitting on the dedicated repository.
See the README for details.


[WIP] feat: Upgrade native sdk 4.3.0

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/7139449052/agora_rtc_engine_android_6.2.6_20231208091850.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7139449052/agora_rtc_engine_ios_6.2.6_20231208092243.zip

https://nightly.link/littleGnAl/hoe/actions/runs/7139449052/agora_rtc_engine_windows_6.2.6_20231208091324.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7139449052/agora_rtc_engine_web_6.2.6_20231208091004.zip

This comment is commented by bot, do not edit it directly

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/7204152015/agora_rtc_engine_android_6.2.6_20231214034416.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7204152015/agora_rtc_engine_ios_6.2.6_20231214034153.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7204152015/agora_rtc_engine_macos_6.2.6_20231214033905.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7204152015/agora_rtc_engine_windows_6.2.6_20231214033818.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7204152015/agora_rtc_engine_web_6.2.6_20231214033523.zip

This comment is commented by bot, do not edit it directly

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/7666447510/agora_rtc_engine_android_6.2.6_20240126095730.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7666447510/agora_rtc_engine_ios_6.2.6_20240126095823.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7666447510/agora_rtc_engine_macos_6.2.6_20240126095559.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7666447510/agora_rtc_engine_windows_6.2.6_20240126095053.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7666447510/agora_rtc_engine_web_6.2.6_20240126094849.zip

This comment is commented by bot, do not edit it directly

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/7721244644/agora_rtc_engine_android_6.2.6_20240131044153.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7721244644/agora_rtc_engine_ios_6.2.6_20240131044306.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7721244644/agora_rtc_engine_macos_6.2.6_20240131043722.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7721244644/agora_rtc_engine_windows_6.2.6_20240131044458.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7721244644/agora_rtc_engine_web_6.2.6_20240131043434.zip

This comment is commented by bot, do not edit it directly

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/7800507841/agora_rtc_engine_android_6.2.6_20240206134247.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7800507841/agora_rtc_engine_ios_6.2.6_20240206134130.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7800507841/agora_rtc_engine_macos_6.2.6_20240206133635.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7800507841/agora_rtc_engine_windows_6.2.6_20240206133550.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7800507841/agora_rtc_engine_web_6.2.6_20240206133356.zip

This comment is commented by bot, do not edit it directly

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/7956084072/agora_rtc_engine_android_6.2.6_20240219074751.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7956084072/agora_rtc_engine_ios_6.2.6_20240219074432.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7956084072/agora_rtc_engine_macos_6.2.6_20240219074035.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7956084072/agora_rtc_engine_windows_6.2.6_20240219074125.zip
https://nightly.link/littleGnAl/hoe/actions/runs/7956084072/agora_rtc_engine_web_6.2.6_20240219073752.zip

This comment is commented by bot, do not edit it directly

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/8015165679/agora_rtc_engine_android_6.2.6_20240223054451.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015165679/agora_rtc_engine_ios_6.2.6_20240223054738.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015165679/agora_rtc_engine_macos_6.2.6_20240223053935.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015165679/agora_rtc_engine_windows_6.2.6_20240223054212.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015165679/agora_rtc_engine_web_6.2.6_20240223053533.zip

This comment is commented by bot, do not edit it directly

Examples built:

https://nightly.link/littleGnAl/hoe/actions/runs/8015449562/agora_rtc_engine_android_6.3.0_20240223062301.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015449562/agora_rtc_engine_ios_6.3.0_20240223062307.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015449562/agora_rtc_engine_macos_6.3.0_20240223062058.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015449562/agora_rtc_engine_windows_6.3.0_20240223062216.zip
https://nightly.link/littleGnAl/hoe/actions/runs/8015449562/agora_rtc_engine_web_6.3.0_20240223061720.zip

This comment is commented by bot, do not edit it directly


feat: Add notebook for Wide & Deep on Vertex Pipelines

REQUIRED: Add a summary of your PR here, typically including why the change is needed and what was changed. Include any design alternatives for discussion purposes.

Adding a notebook to show how to use Wide & Deep on Vertex Pipelines.

REQUIRED: Fill out the below checklists or remove if irrelevant

If you are opening a PR for Official Notebooks under the notebooks/official folder, follow this mandatory checklist:

[x] Use the notebook template as a starting point.
[x] Follow the style and grammar rules outlined in the above notebook template.
[x] Verify the notebook runs successfully in Colab since the automated tests cannot guarantee this even when it passes.
[x] Passes all the required automated checks. You can locally test for formatting and linting with these instructions.
[x] You have consulted with a tech writer to see if tech writer review is necessary. If so, the notebook has been reviewed by a tech writer, and they have approved it.
[x] This notebook has been added to the CODEOWNERS file under the Official Notebooks section, pointing to the author or the author's team.
[x] The Jupyter notebook cleans up any artifacts it has created (datasets, ML models, endpoints, etc) so as not to eat up unnecessary resources.

If you are opening a PR for Community Notebooks under the notebooks/community folder:

[ ] This notebook has been added to the CODEOWNERS file under the Community Notebooks section, pointing to the author or the author's team.
[ ] Passes all the required formatting and linting checks. You can locally test with these instructions.

If you are opening a PR for Community Content under the community-content folder:

[ ] Make sure your main Content Directory Name is descriptive, informative, and includes some of the key products and attributes of your content, so that it is differentiable from other content
[ ] The main content directory has been added to the CODEOWNERS file under the Community Content section, pointing to the author or the author's team.
[ ] Passes all the required formatting and linting checks. You can locally test with these instructions.

File /workspace/workspace/env/lib/python3.9/site-packages/google/cloud/aiplatform/pipeline_jobs.py:461, in PipelineJob._block_until_complete(self)
Step #5: Step #4:     458 # Error is only populated when the job state is
Step #5: Step #4:     459 # JOB_STATE_FAILED or JOB_STATE_CANCELLED.
Step #5: Step #4:     460 if self._gca_resource.state in _PIPELINE_ERROR_STATES:
Step #5: Step #4: --> 461     raise RuntimeError("Job failed with:\n%s" % self._gca_resource.error)
Step #5: Step #4:     462 else:
Step #5: Step #4:     463     _LOGGER.log_action_completed_against_resource("run", "completed", self)
Step #5: Step #4:
Step #5: Step #4: RuntimeError: Job failed with:
Step #5: Step #4: code: 9
Step #5: Step #4: message: "The DAG failed because some tasks failed. The failed tasks are: [exit-handler-1].; Job (project_id = python-docs-samples-tests, job_id =<PHONE_NUMBER>404274688) is failed due to the above error.; Failed to handle the job: {project_number =<PHONE_NUMBER>416, job_id =<PHONE_NUMBER>404274688}"


pybricks.common: Add new BLE class.

This adds a new BLE class that is used for connectionless broadcasting/ observing on hubs with built-in Bluetooth Low Energy.
Also see https://github.com/pybricks/pybricks-micropython/pull/158.

Thanks for the review. Updated (fixup! commit can be squashed).


start to stop

I guess you meant stop there @hectorj2f ?

@puja108 Your guess is correct :)

LGTM


Add support for current Operating Systems

The list of supported Operating Systems is outdated.  Update it and add some basic acceptance tests to ensure the code is valid.
Also include:

#98
#99

If we drop EOL Puppet, CI will be all green.  Do we want to do a minor release first or should we proceed with removal of legacy stuff and do a major release for the next release?

The module has been migrated to Vox Pupuli and not seen a release yet. I'd go for a full major release that sets a new baseline.


Trimming defaults don't use advised trimming behavior

Trimming defaults vary by build configuration:

By default, Android and Mac Catalyst builds use partial trimming when the build configuration is set to a release build.

However, the trimming behavior advice says not to:

The $(TrimMode) build property shouldn't be conditioned by build configuration.

Either the behavior should be changed to match the advice or the advice should be updated to indicate when it is and is not recommended to condition TrimMode by configuration.

Associated WorkItem - 350513

Hi @breyed
The intent here is that users should either accept the trimming defaults or if they're going to change the defaults, do so across all build configurations. I appreciate that the language could use some clarification.

@davidbritch What are the underlying technical reasons for the default of partial trimming for release but not debug on Android and Mac Catalyst? Intuitively, I would expect that if for example the user switched to full trimming, the same release/debug distinction would apply. I'm trying to understand why the guidance would be in the example to use full trimming in both release and debug.

The guidance in the docs should be reconciled with guidance from @jonathanpeppers in dotnet/maui#26509 to not use "<PublishTrimmed>true</PublishTrimmed> in Debug mode on Android".

Generally, I don't think you should have to set $(PublishTrimmed) on mobile or know this setting exists. It should pick the right thing by default for you. On Android, there isn't really a good reason to turn it on in Debug mode, or turn it off in Release mode. Doing either of those will cause issues. And then behavior differs on iOS or other platforms.
This has some details about the current behavior, that we might improve in .NET 10:

https://github.com/dotnet/android/issues/9526


Add ESP32 Support

As the ESP32 is available for some time now, that would be great to see how to port rboot to that chip if possible. My first impression is that it's pretty close to ESP8266 in terms of architecture and the RTOS sdk seems very similar in features / boot image format.
But there are two cores and new features so it might be just an impression.
Did someone try rboot on ESP32 already?

Just saw espressif last sdk (esp-idf). It seems much more open than the ones for esp8266 (the bootloader source is available), so might not be so important to have rboot on the esp32 after all...

Agreed, I don't think there is the same need for rBoot on esp32 as there was on the original.


need help for crypto trading

hello .
I want to train a agent on BTCUSD and i read the tutorial in finrl site but it was all about stocks . when I'm trying to run my custom dataset on from  StockTradingEnv i get a lot of errors . can someone help me ? is the a example code for crypto trading with finrl . also is it ok that i use custom dataset ? i did it because YahooDownloader didn't work well for me .

YahooDownloader  may not work in some countries. pls use VPN


microk8s.enable juju fails on curl step on Centos7

Hello,
'microk8s.enable juju' fails to pull juju-2.7.0-centos7.tar.gz from typepad.net with curl error 77. Centos 7's native curl pulls the file ok, there seems to be an issue using the snap's version of curl:
`#  /var/lib/snapd/snap/microk8s/1176/usr/bin/curl -L https://launchpad.net/juju/2.7/2.7.0/+download/juju-2.7.0-centos7.tar.gz -o /root/1176/tmp/juju.tar.gz
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (77) Problem with the SSL CA cert (path? access rights?)
[root@centos7 ~]# /bin/curl -L https://launchpad.net/juju/2.7/2.7.0/+download/juju-2.7.0-centos7.tar.gz -o /root/1176/tmp/juju.tar.gz
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  116M  100  116M    0     0  1239k      0  0:01:36  0:01:36 --:--:--  943k
[root@centos7 ~]# uname -a
Linux centos7.localdomain 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 23:58:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@centos7 ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
`
So far I've yum installed ca-certificates based on another post, microk8s.enable juju still still with the came curl error.   Would there be any unexpected microk8s management issues if the enable.juju.sh script is run manually outside of microk8s.enable?
Thanks!
-Dan
inspection-report-20200224_171509.tar.gz
Please run microk8s.inspect and attach the generated tarball to this issue.
We appreciate your feedback. Thank you for using microk8s.

@dliebsterwb: There won't be any issues if you manually download the Juju binary and place it at /var/snap/microk8s/current/bin/juju. The step that downloads Juju just checks for the existence of that binary, and skips downloading it if it's already there.

@knkski I have the same issue, and I have downloaded juju.tar.gz, unpack it and moved juju file into folder that you have mentioned - get new issue:
Enabling dns...
Enabling storage...
Enabling dashboard...
Enabling ingress...
Enabling rbac...
Enabling juju...
Deploying Kubeflow...
Kubeflow could not be enabled:
ERROR cannot load ssh client keys: mkdir /var/snap/microk8s/1222/juju: permission denied```

@sphinks: Can you paste the output from ls -lah /var/snap/microk8s/current/juju?

Nothing, there is no such folder. I just picked up juju file from tar and put it into current/bin. Should I put whole unpacked folder in current/?

@sphinks: You'll need to run the commands found here:
https://github.com/ubuntu/microk8s/blob/050e98b/snap/hooks/configure#L380-L382
https://github.com/ubuntu/microk8s/blob/050e98b/snap/hooks/configure#L386
Where $SNAP_DATA is /var/snap/microk8s/current
Additionally, #989 will fix this issue generally, as it just includes the juju binary in the snap, instead of downloading it after snap install.

@knkski looks like we do not need manual download. It can be done with
snap install juju --classic. But next that will be new issue:
Enabling dns...
Enabling storage...
Enabling dashboard...
Enabling ingress...
Enabling rbac...
Enabling juju...
Deploying Kubeflow...
Kubeflow could not be enabled:
ERROR connection is shut down

Command '('microk8s-juju.wrapper', 'add-model', 'kubeflow', 'microk8s')' returned non-zero exit status 1
Failed to enable kubeflow

I manage to resolve issue with manual executing commands, but get some new strange thing:
microk8s.enable kubeflow
Enabling dns...
Enabling storage...
Enabling dashboard...
Enabling ingress...
Enabling rbac...
Enabling juju...
Kubeflow has already been enabled.
Failed to enable kubeflow

I try to stop/start microk8s, disable/enable kubeflow... Microk8s hurts me.

@sphinks: When it hangs, does it eventually complete and print any output, or does it never complete? Are you able to run microk8s.juju --debug show-controller uk8s manually?

@knkski output that I have posted above shows all input I get. Process hangs at Running microk8s-juju.wrapper --debug show-controller uk8s but then finished with:
KUBEFLOW_DEBUG=true microk8s.enable kubeflow
Enabling dns...
Enabling storage...
Enabling dashboard...
Enabling ingress...
Enabling rbac...
Enabling juju...
Running `microk8s-juju.wrapper --debug show-controller uk8s`
Kubeflow has already been enabled.
Failed to enable kubeflow

Yes, manual run of microk8s.juju --debug show-controller uk8s looks ok.
microk8s.juju --debug show-controller uk8s
15:11:41 INFO  juju.cmd supercommand.go:83 running juju [2.7.3 9da5b593fa1d096220230143f1e1fea5c4eb56ad gc go1.12.17]
15:11:41 DEBUG juju.cmd supercommand.go:84   args: []string{"/snap/microk8s/1245/bin/juju", "--debug", "show-controller", "uk8s"}
15:11:41 INFO  juju.juju api.go:67 connecting to API addresses: [<IP_ADDRESS>:17070]

@sphinks: You'll need to disable kubeflow before enabling it again. The main way would be microk8s.disable kubeflow, though you might have to do sudo snap remove microk8s && sudo snap install microk8s --classic if you've done any manual twiddling to get around the main issue.

Closing this issue, since microk8s now comes packaged with the juju binary, and doesn't need to download it.


Unnecessary map initialization performance penalty caused by delaying composing GoogleMap() subcomposition until after GoogleMap object is available

android-maps-compose 4.3.0
From code inspection I've noticed that there is an undue performance penalty caused by delaying the GoogleMap() subcomposition until after the GoogleMap object has been made available via suspending MapView.awaitMap().
While the GoogleMap object is required during the "apply changes" phase of the subcomposition, it should not be required to perform the initial composition of the subcomposition, prior to "apply changes".
Initial composition phase of subcomposition and MapView.awaitMap() should and can be performed in parallel.

Just as an aside thought, not directly linked to this issue: the initial composition phase of the GoogleMap() subcomposition theoretically would not need to be performed on the main thread, which would free the main thread for other concurrent initialization tasks. This may be too risky to attempt for now.

Another element to consider here: MapsInitializer may need to be a part of an app's map initialization pipeline: the GoogleMap() subcomposition composition phase should not be delayed until after MapsInitializer is done; it can run in parallel.

@wangela Just FYI: the 4.3.3 release says that it fixes this issue, but that is not the case. I think this mixup happened because I mentioned this issue in one of the commits for 4.3.3 ("see #501", I was not aware that this has "fixes" semantics, maybe some problem with release automation, or maybe I shouldn't do this in commit messages?).

@bubenheimer Where are you seeing that the release says it fixes this issue 501? I only see it mentioning that it fixes issue 466 which was tagged intentionally on your PR number 478.

@wangela That link says it "closes" #501

Strange, may be human error. I've deleted that mention from the release notes.

I've added two related issues on the Google issue tracker:
https://issuetracker.google.com/issues/340494390
https://issuetracker.google.com/issues/340476594


The recipe for distcc cannot be build on R2018.2.

Hello there,
I'm hoping that this is the correct place for this issue.
Earlier on, I tried building a yocto recipe for the ZCU106 based on this layer, and it failed at building distcc as shown:
| In file included from /usr/include/python2.7/Python.h:8:0,
|                  from /home/brainiarc7/source.build/zcu106/build/tmp/work/aarch64-xilinx-linux/distcc/3.2-maint-r0/git/include_server/c_extensions/distcc_pump_c_extensions_module.c:24:
| /usr/include/python2.7/pyconfig.h:12:12: fatal error: aarch64-linux-gnu/python2.7/pyconfig.h: No such file or directory
|  #  include <aarch64-linux-gnu/python2.7/pyconfig.h>
|             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| compilation terminated.
| error: command 'aarch64-xilinx-linux-gcc' failed with exit status 1
| Makefile:570: recipe for target 'include-server' failed
| make: *** [include-server] Error 1
| ERROR: oe_runmake failed

On the host system, all python related dependencies, ie python-dev, are installed.
How can I fix this error?
Thanks.

same error,,need help

Do you still have this issue in latest release?

@mharth I'll retest and report back.


testutils: fix GoroutineAssistant and httputils

Closes #1595.
Fixes #1590.

Perhaps we need to start thinking about it as a gexpect helper, and use Close during shutdown.

I tend to agree with krnowak that ultimately this should live in the context, but I think this is OK as a stopgap for now.

@krnowak PTAL. rktRunCtx now takes care of registered child processes. It does add a little overhead to kill and wait every child process, but that's a small price to pay for correctness.
I've added one usage example in the TestNetHost* tests and we could use this in all tests that spawn children.

The RegisterChild is good for now. Maybe in the follow-up PR we could modify the spawnOrFail function to take the context and register the child immediately.
Also, is the commit "tests/net: one call to ga.Add(1) per goroutine" needed? I suppose we can drop it.

LFAD if green.

@steveeJ https://www.youtube.com/watch?v=AR5FEQnmOcc

This PR is dragging on and on and is gathering more and more changes. I'd like to merge ASAP, but first some of my notes/questions first:

Calling t.Fatal itself does not kill the "child" goroutines, only the goroutine that called it. They can outlive the goroutine that created them easily (actually, my commit "functional tests: Return from a goroutine when the ACI server closes" is a kind of a proof of it - I decided to fix that when I noticed the serverHandler goroutine in stacktrace resulting from some panic in a completely unrelated test). And to be clear - I'm talking about T.Fatal, not GoroutineAssistant.Fatal.
Do we want to require that all goroutines created by the test should be killed together with the test? I am strongly in favor of this.
We have some prior art with tackling the logging issue - it is in the ACI test server. I, instead of providing a logging interface, just provided two channels - one for getting logs and one for letting know when the service is closed. Today, I would say that just one channel is enough (when it's closed, the service stopped). The code:

runServer and serverHandler in auth tests: https://github.com/steveeJ/rkt/blob/6a22db07df544d127b3e955ec776e1e71cd45cd3/tests/rkt_auth_test.go#L145
serverHandler (the other one that the one in previous point) in test aci server: https://github.com/steveeJ/rkt/blob/6a22db07df544d127b3e955ec776e1e71cd45cd3/tests/test-auth-server/aci/server.go#L45
Server and NewServer in test aci server: https://github.com/steveeJ/rkt/blob/6a22db07df544d127b3e955ec776e1e71cd45cd3/tests/test-auth-server/aci/server.go#L159

But can we please merge it already? It fixes those pesky failures in networking tests and we are good. I'd prefer to address the other issues (no leftover goroutines, agree on logging solution, proper rkt registration for all tests and so on) in separate, uh, issues. Github issues.

SGTM


Fix: ColorSelect2 component doesn't close if outside click target stops propagation

What this PR does
This PR is a bugfix: https://vimean.atlassian.net/browse/CEWK-2823
The Color Picker component uses the useOutsideClick utility hook.
The hook listens to clicks everywhere in the editor, and checks if the click target is inside the picker or not. If not, it triggers the closing of the picker.
The bug: If the click target calls event.stopPropagation(), the event doesn't bubble up to the outside click listener, and hence is not handled and the picker remains open.
Screenshots & Recordings
Here is the bug:
https://github.com/vimeo/iris/assets/36724484/556903b5-5092-4896-8dc2-7c6f6f65ae9d
How it does that

This PR adds an optional parameter to the useOutsideClick hook, to allow for using the useCapture parameter in the click listeners.
The useCapture parameter triggers the click listener targets immediately, instead of upon propagation. This way, the event is handled even if the target called stopPropagation.
The PR added a usage of the new useCapture option in the color picker.

Testing

Open a blank canvas in the new editor
In the left sidebar, click on Graphics, then on "Add solid background"
Open the color picker and change the color of the solid background. DON'T CLOSE THE PICKER.
With the picker open, go to the timeline, and drag the solid to trim/expand it, and release the mouse button.

Current behavior (bug):
The solid color resets to the default/previous color
Expected behavior (after fix):
The newly selected color remains the same after trimming.
Editor works as it should in all other aspects (no slowness, no issues with style resets...)

Just a heads up, since this is a public GitHub repo we probably don't want to link to our internal tickets in prs.

@juliewongbandue
Hi Julie,
I'm not a contributor, I can't merge this by myself, could you merge this please?


feat: allow for relative parts when specifying a path to a file on the CLI

Summary
While using the CLI (to load data for example) we are required to pass the location of a file. It seems like the location has to be a full path else the load fails and the error message reports Internal Error
For example
./kaskada-cli load \
     --table Purchase \
     --file-path file:///purchase.parquet

See

https://github.com/kaskada-ai/kaskada/issues/202#issuecomment-1496483413
#208

Describe the solution you'd like

It would be nice to have a working example that allows passing in local paths instead of full paths
The error message when the file provided in the path argument is missing or otherwise unavailable should be more informative, e.g., "Cannot find/open file " or similar.

For the CLI, I would expect to say something like ./kaskada-cli load --table Purchase --file-path ./purchase.parquet and have the CLI take care of making that work. That would be more consistent with how basically every CLI works with local files, right?


Nextjs: access site url and distribution id at runtime

It's obviously not possible to link itself
discord: https://discord.com/channels/983865673656705025/1177071497974648952/1223082317828853821

Leaving a note there that the site url can be accessed from the host header, ie.
import { headers } from "next/headers";

export default async function Page() {
  const headersList = headers();
  const host = headersList.get("host");
  ...
}

Was also just needing to do this. Not sure how we can revalidatePath on Next.js apps until there is a way to get the current CF Distribution ID. Happy to hear if there are any workarounds in the meantime.


Add LeakSanitizer support in report-converter

Describe the solution you would like
Add support for LeakSanitizer reports in report-converter, so running with -t lsan finds and converts the leaks to plists. Lsan is described in more detail here: https://clang.llvm.org/docs/LeakSanitizer.html
Additional context
We're using codechecker to sanitize our codebase, and many of the issues are detected by LeakSanitizer, but we currently can't convert them to codechecker reports (report-converter does not find the LeakSanitizer entries in the logs)

@OmniTroid This can be implemented similarly as the ub sanitizer is implemented: https://github.com/Ericsson/codechecker/tree/master/tools/report-converter/codechecker_report_converter/sanitizers/ub.
Unfortunately we are very busy in these days, so if you or somebody in your team has some free time you can help us to implement this and if you are stucked, we can help you.

@OmniTroid Can you share the sample output of the leak sanitizer? Or probably steps to reproduce it on Linux Kernel.
I would like to get my hands on this one 😄

@jay24rajput I think the output is the same as in the official site what @OmniTroid linked (https://clang.llvm.org/docs/LeakSanitizer.html). So I think we can start with it:
==23646==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
    #0 0x4af01b in __interceptor_malloc /projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52:3
    #1 0x4da26a in main memory-leak.c:4:7
    #2 0x7f076fd9cec4 in __libc_start_main libc-start.c:287
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s)

Also as far as I see this output is very similar to the memory sanitizer output, so you can implement it on the similar way as the memory sanitizer parser implemented: https://github.com/Ericsson/codechecker/tree/master/tools/report-converter/codechecker_report_converter/sanitizers/memory.

Hey @csordasmarton
Sorry for being late on this issue. I started developing the report-converter, I am attaching the git branch here as well. But when I run make package in tools/report-converter the following error is displayed:
# Install package in 'development mode'.
python3 -m pip install -e . -e ../codechecker_report_hash/
Obtaining file:///home/jay/codechecker/tools/report-converter
Obtaining file:///home/jay/codechecker/tools/codechecker_report_hash
ERROR: Could not find a version that satisfies the requirement codechecker_report_hash (from report-converter==0.1.0) (from versions: none)
ERROR: No matching distribution found for codechecker_report_hash (from report-converter==0.1.0)
make: *** [Makefile:43: package] Error 1

Can you please tell me what is going wrong here?
Github Branch: https://github.com/jay24rajput/codechecker/tree/leak_sanitizer

@jay24rajput What is the output of this command: python3 -m pip -V. My pip version is pip 21.0.1 and I didn't get any error during the make package target. Try to update your pip version, I think that will solve this problem: python3 -m pip install --upgrade pip

Thanks, @csordasmarton. That helped solve the error 👍🏻


Add support JXTaskPane

I Added support at the JXTaskPane for resolved the issue #57
This is my work

ps: You like my test for fixed problem pixelated font in all system os? Click me

Sorry haven't been active on Github lately - thank you so much for adding support for this :)

don't worry I can understand you I finished the exams recently and I was holed up to study 😁


Spelling Mistakes in the song Akkini Neruppai

Romanised lyrics in the song has some spelling mistakes.

Akkini Neruppai Iranggi Vaarum (Fr. S. J. Berchmans {பெர்க்மான்ஸ்}).xml.zip


App updates in release mode but not in debug mode

Steps to Reproduce
After updating my flutter install, migrating to the new gradle plugin and updating my dependencies (share and admob plugin), my app only runs the current version if I use flutter run --release. When running flutter run, the old app is displayed even though I add new buttons etc.
In the log, I get an error that does not really tell me anything. Logs for both cases are attached. I'm at a loss to what I can do here. For migrating I followed this guide:  https://github.com/flutter/flutter/wiki/Updating-Flutter-projects-to-Gradle-4.1-and-Android-Studio-Gradle-plugin-3.0.1
Logs
Flutter_release.txt
Flutter_debug.txt
Flutter_analyze.txt
Flutter Doctor
[andreas@andreas-desktop Idiotentest]$ flutter doctor -v
[  +17 ms] [/run/media/andreas/Andreas/Programmieren/flutter/] git rev-parse --abbrev-ref --symbolic @{u}
[  +19 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/alpha
[        ] [/run/media/andreas/Andreas/Programmieren/flutter/] git rev-parse --abbrev-ref HEAD
[   +2 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] alpha
[        ] [/run/media/andreas/Andreas/Programmieren/flutter/] git ls-remote --get-url origin
[   +4 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter.git
[        ] [/run/media/andreas/Andreas/Programmieren/flutter/] git log -n 1 --pretty=format:%H
[   +5 ms] Exit code 0 from: git log -n 1 --pretty=format:%H
[        ] 2e449f06f0a3be076e336ad6b30b0e9ec99dbdfe
[        ] [/run/media/andreas/Andreas/Programmieren/flutter/] git log -n 1 --pretty=format:%ar
[   +3 ms] Exit code 0 from: git log -n 1 --pretty=format:%ar
[        ] 9 days ago
[        ] [/run/media/andreas/Andreas/Programmieren/flutter/] git describe --match v*.. --first-parent --long --tags
[   +3 ms] Exit code 0 from: git describe --match v*.. --first-parent --long --tags
[        ] v0.0.21-0-g2e449f06f
[ +152 ms] [✓] Flutter (on Linux, locale en_US.UTF-8, channel alpha)
[        ]     • Flutter version 0.0.21 at /run/media/andreas/Andreas/Programmieren/flutter
[        ]     • Framework revision 2e449f06f0 (9 days ago), 2018-01-29 14:26:51 -0800
[        ]     • Engine revision 6921873c71
[        ]     • Tools Dart version 2.0.0-dev.16.0
[        ]     • Engine Dart version 2.0.0-edge.da1f52592ef73fe3afa485385cb995b9aec0181a
[  +80 ms] java -version
[  +35 ms] [✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
[        ]     • Android SDK at /home/andreas/Android/Sdk
[        ]     • Android NDK at /home/andreas/Android/Sdk/ndk-bundle
[        ]     • Platform android-27, build-tools 27.0.3
[        ]     • Java binary at: /opt/android-studio/jre/bin/java
[        ]     • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)
[   +1 ms] [✓] Android Studio (version 3.0)
[        ]     • Android Studio at /opt/android-studio
[        ]     • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)
[  +54 ms] [✓] IntelliJ IDEA Community Edition (version 2017.3)
[        ]     • Flutter plugin version 21.2.3
[        ]     • Dart plugin version 173.4548.30
[   +3 ms] /home/andreas/Android/Sdk/platform-tools/adb devices -l
[   +3 ms] Exit code 0 from: /home/andreas/Android/Sdk/platform-tools/adb devices -l
[        ] List of devices attached
FUH7N17220000709       device usb:3-5 product:VNS-L31 model:HUAWEI_VNS_L31 device:HWVNS-H
[  +10 ms] /home/andreas/Android/Sdk/platform-tools/adb -s FUH7N17220000709 shell getprop
[  +58 ms] ro.hardware = hi6250
[        ] ro.build.characteristics = default
[   +1 ms] [✓] Connected devices
[        ]     • HUAWEI VNS L31 • FUH7N17220000709 • android-arm • Android 7.0 (API 24)
[   +9 ms] "flutter doctor" took 370ms.
[ +175 ms] ensureAnalyticsSent: 173ms
[   +3 ms] exiting with code 0

did you try flutter clean?

Oh wow. I didn't know that exists, thanks! I probably should have tried removing the build directory ;)

You shouldn't need to call flutter clean.
Can you reproduce this? If we can figure out what causes us to get confused, we should fix it.

Sorry for the delayed answer, but I tried this again today. Luckily I have it all versioned in git. It can reproduce it every time when jumping between commits.

Checkout old version of my app and run flutter clean (one local plugin in pubspec points to a local admob plugin):
     path: ../plugins/packages/firebase_admob/

Build it with the current flutter version, this creates a bunch of errors probably related ot the older plugin I am using
-> realize I have to update gradle and the plugins.

Next I did multiple steps at once: Change the plugin from local to dartpub and use a newer version, update gradle, create a signingconfig with my keystore and add one button in my app

The problem initially mentioned in this issue occurs.

I have an idea why this could be happening though: When I migrated to the new gradle I noticed that my app had com.yourcompany.projectname instead of my actual package name (at this point the yourcompany package didn't even exist), so I changed it to my actual package. Could be related to this since the app does not update when running in non-release mode?
Diff that creates the problem
I hope this helps.

We did discover a problem a few months ago around this. We've fixed it. I just checked and it seems to work ok now, so I'm going to close this.


error: failed to run custom build command for libp2p-core v0.34.0

Weird issue, where "cargo test" failed to run custom build command for libp2p-core v0.34.0
Caused by:
process didn't exit successfully: /...../target/release/build/libp2p-core-574ed7c49c431a25/build-script-build (exit status: 101)
--- stderr
thread 'main' panicked at 'called Result::unwrap() on an Err value: Custom { kind: NotFound, error: "failed to invoke protoc (hint: https://docs.rs/prost-build/#sourcing-protoc): No such file or directory (os error 2)" }', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-core-0.34.0/build.rs:30:6
warning: build failed, waiting for other jobs to finish...
make: *** [Makefile:158: test-e2e] Error 101
We are running github actions. This particular test works fine when not using cachepot.
If we enable cachepot, and run this test (meaning the cache is empty) the test will complete successfully, but on the next run (when it already cached something) it doesn't work, fails giving this same error above every time.
Tried caching locally and in Redis server, both same outcome.
Tried installing that library manually (after failed job), and re-running the test. but the same error.
We have successfully run many other tests using cachepot, both locally and with redis server, but it only fails when this library is present.
I'm going to run it 1 more time using 'RUST_BACKTRACE=1' and will post the backtrace (if required)
Please let me know if more information is required.
Thanks guys!

I assume you're using the distributed compilation? In this case, protoc is not part of the binary being compiled.
There were a few solution attempts, the right solution would be to have println!("cargo:rerun-if-changed={}", which::which("protoc")); and this will add the file as a dependency which will subsequently be picked up properly by sccache.

Thanks for that, however, after multiple testing of different things to solve it, was just impossible.
I solved it just by using pre-compiled version: cachepot-0.1.0-rc.2-x86_64-unknown-linux-musl.tar.gz
Thanks.

U can't really follow. The fix would be needed upstream in libp2p and possibly in cachepot - I don't think the solution is contained in a precompiled cachepot artifact.