ReportServer connection string as reference

When loading a report from the ReportServer DB, is it possible to use a reference for the "source" attribute? What would the settings section look like?
I use references for the dataset connection string, that works, but for the source, it keeps complaining:
NBi.NUnit.Runtime.TestSuite.ExecuteTestCases:
System.NullReferenceException : A reference named 'RS_CS' has been found, but no element 'report' has been defined

			<execution>
				<report
				  source="@RS_CS"
				  connectionString="@works_fine"> ...
				</report>
			</execution>`

<settings>
<reference name="RS_CS">
      <connectionString>...</connectionString>
  </reference>
</settings>`

Thanks

At this page of documentation, you've an example of settings (reference/default) for a report. Have you tried this notation?

The default did the trick. Thanks a lot!

Thx for feedback


allow create keypair and share

KeyPairs

For the fist time deployment, you can create a keyPair for instance ssh login by using export CREATE_KEYPAIR=true.
We use key name pal-server-keypair-${region} for all servers in the same region.

ⓘ If you do not have the keyPair in the deployment region and do not set export CREATE_KEYPAIR=true to create the keyPair, the deployment will fail.


DGJ-821 Initial push for camunda DEV deployment

Summary
Change Camunda workflow. Generate build on github and push it to openshift.
Changes

Update forms-flow-bpm-cd file with required changes
Add new environment specific param in git.
Add new bpm_bc and bpm_dc files to support build and deployment config.

Notes
Added separate files other than existing camunda deployment flow.

Works for me. I'm curious why we're adding the step to print the environment variables.

@matbusby-fw My bad forgot to remove dependancy in steps. We print env parallel in steps to keep an eye from which branch and on which environment it is deploying. No strong reason here.


Expiration time for alert activity list

We don't seem to have this documented anywhere. When an alert is triggered, we will also make available a list of messages that matched the alert, list that can be viewed by the customer when selecting the alert in the Alerts dashboard. After 7 days, instead of being able to access the messages that matched the alert, we see "The activities for this alert have expired".
Please confirm with the Engineering team what is the expected behavior and update the article accordingly. The URL would be https://protection.office.com/viewalerts and when you click on a given alert to resolve it for example, you also have the ability to click on "View activity list" on the alert details. This is where after 7 days, we have the message "The activities for this alert have expired" instead "View activity list" on a given alert.

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

ID: 9f2879ba-e58e-cd47-f488-10d153c31418
Version Independent ID: 391a2c05-d63d-e84e-7c7d-80c3b3518419
Content: Alert policies in the security and compliance centers - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/alert-policies.md
Service: o365-seccomp
GitHub Login: @markjjo
Microsoft Alias: markjjo

@Alex-Catalin Please go ahead and update the article with this change and submit a pull request. Thanks.


Invalid EventHub Name/Connection causing excessive error logs

Create an EventHub triggered function from our template with an invalid hub/connection info. This seems to put the host into a fast retry error loop that generates excessive logs.

Looked at this a bit, basically the webjobs sdk throws an exception at runtime when it tries to start the EventHubListener for a non-existent event hub.
We could add a test for existence in the core sdk in EventHubConfiguration.AddReceiver() when the connection string is specified. In functions, this occurs in ServiceBusScriptBindingProvider GetAttributes call, which bubbles up to GetFunctionDescriptors in ScriptHost.  That should log the error in the offending EventHub function and not kill the host.

Thanks for taking a look. While we could add binding specific handling like you suggest, I think if we wanted to handle this across the board for all bindings including extensions, we'd make fundamental changes to the core SDK listener startup path to catch listener errors - I've logged a bug for that here: https://github.com/Azure/azure-webjobs-sdk/issues/996.


feat(tutorial): complete step 5 by cbai

Step 5:
https://www.carbondesignsystem.com/tutorial/react-step-5/
IBM Cloud deployment:
http://carbon-tutorial-baisystems.mybluemix.net/#/

@kellychurchill
I added IBM cloud mybluemix,net URL in the description above. Please check.


Maintenance: Remove transitional flags to complete upgrade to Rails 5.2

This removes flags that were added as part of the upgrade process to Rails 5.2, in preparation for upgrading to 6.0 next.
It's possible that per_form_csrf_tokens interacts with some JS in a way that wasn't revealed in integration tests, so I'll test this manually on the demo site first.

FWIW, I don't think this per-form CSRF flag actually provides additional protection as far as I can tell.  The UJS adapter also seems to blow away any per-form tokens and set them all to the global token (eg, https://github.com/rails/rails/blob/b2eb1d1c55a59fee1e6c4cba7030d8ceb524267c/actionview/app/assets/javascripts/rails-ujs/utils/csrf.coffee#L25).  The global token seems like it is always also valid based on their test cases (eg, test_accepts_global_csrf_token in https://github.com/rails/rails/blob/99d12b950756c7d2a4afff538bcf04b40eda82bf/actionpack/test/controller/request_forgery_protection_test.rb#L910).  Other issues confirm this (see github/rails/rails/32930, closed without a fix).

selfie


Change format of _GIT_SINCE in help

The format _GIT_SINCE is what git --since takes in which is YYYY-MM-DD.
Ref: https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History

Thank you for your pull request! Could you also update the README.md and git-quick-stats.1 manpage to both reflect these new changes and to make sure the documentation is unified?

Ah, didn't catch those occurrences. Fixed!

Sweet, thank you again for your contribution :)


Day 11 - Pointers in Array

Select the Day of Content
Day 11
What information is missing?
All information about Pointers in Array.

@subhadipbhowmik I have already raised a PR for pointers in CPP. Kindly assign this issue to me for continuing with the pointers in array for the content of Day 11


Error "Maximum call stack size exceeded" with custom plugin

I'm developing a custom Superset plugin for displaying a graph. The plugin works fine when I test it using Storybook and also when I package it and use it in a minimal React app. However, as soon as I try to use it with Superset and start the frontend using npm run dev-server, I get the following error:
ERROR in plugins_plugin-graph_src_PluginChartGraph_tsx.483f7114.chunk.js
Maximum call stack size exceeded

When I run npm run build, I get this:
[webpack-cli] HookWebpackError: Maximum call stack size exceeded
    at makeWebpackError (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack/lib/HookWebpackError.js:48:9)
    at /home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack/lib/Compilation.js:2517:12
    at eval (eval at create (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:94:1)
-- inner error --
RangeError: Maximum call stack size exceeded
    at String.match (<anonymous>)
    at OriginalSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/OriginalSource.js:64:32)
    at module.exports (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
    at ReplaceSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/ReplaceSource.js:176:44)
    at module.exports (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
    at streamAndGetSourceAndMap (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
    at CachedSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/CachedSource.js:208:35)
    at module.exports (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
    at ConcatSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/ConcatSource.js:112:55)
    at module.exports (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
caused by plugins in Compilation.hooks.processAssets
RangeError: Maximum call stack size exceeded
    at String.match (<anonymous>)
    at OriginalSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/OriginalSource.js:64:32)
    at module.exports (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
    at ReplaceSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/ReplaceSource.js:176:44)
    at module.exports (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
    at streamAndGetSourceAndMap (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
    at CachedSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/CachedSource.js:208:35)
    at module.exports (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
    at ConcatSource.streamChunks (/home/goto-loop/Superset/superset-test/superset-frontend/node_modules/webpack-sources/lib/ConcatSource.js:112:55)

The output suggests an issue with Webpack, which I also use for bundling my plugin (maybe some conflicts there?). On the other hand it seems to be connected to one dependency of my plugin: elkjs, which I use for layouting the graph. It's basically the Java library ELK transpiled to JS. Without this dependency, Superset loads the plugin with no problems.
Environment

browser type and version: Firefox 110.0.1
superset version: latest in branch master
python version: Python 3.9.13
node.js version: v16.18.0
any feature flags active: None

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

I don't think we're going to be able to help resolve custom plugins in general, especially without more details available. Closing this as stale since it's been silent for so long, and we're trying to steer toward a more actionable Issues backlog. If people are still encountering this in current versions (currently 3.x) please re-open this issue, open a new Issue with updated context, or raise a PR to address the problem. Thanks!


fix for aqcu-680? pushing to dev to test further

Coverage increased (+0.02%) to 87.494% when pulling 2bc36f1253ca272a918e5018d31190ca484995dc on mhines-usgs:master into 6c4c5c95036c9c140e68df5b8d47c6be5df5c303 on USGS-R:master.


Frontend: Working Signup with firebase

git fetch origin
git checkout 9-frontend-working-signup-with-firebase

Closed issue because branch was accidentally deleted.


panctl error: gi seems to have renamed to pgi

Describe the bug
The module gi seems to have renamed to pgi.
Not sure if it's specific for my build or a global rename.
To Reproduce
$ panctl
Traceback (most recent call last):
  File "/home/ltlnx/anaconda3/bin/panctl", line 5, in <module>
    from pantalaimon.panctl import main
  File "/home/ltlnx/anaconda3/lib/python3.8/site-packages/pantalaimon/panctl.py", line 26, in <module>
    from gi.repository import GLib
ModuleNotFoundError: No module named 'gi'

$ python
Python 3.8.8 (default, Apr 13 2021, 19:58:26)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import GLib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'gi'
>>> from pgi.repository import GLib
>>>

Having the same issue

Docker container is also affected


Pin kubernetes_asyncio to 29.0.0

Reference Issues or PRs
A recent release in kubernetes_asyncio has broken JupyterHub and jhub-apps.
Fixes #163
https://github.com/nebari-dev/nebari-docker-images/pull/161 needs to get in first to make the CI work again.
│   File "/opt/conda/lib/python3.9/site-packages/kubernetes_asyncio/config/kube_config.py", line 38, in <module>                                                                                │
│     KUBE_CONFIG_DEFAULT_LOCATION = os.environ.get('KUBECONFIG', (pathlib.Path.home() / '.kube/config').as_posix())                                                                                │
│   File "/opt/conda/lib/python3.9/pathlib.py", line 1143, in home                                                                                │
│     return cls(cls()._flavour.gethomedir(None))                                                                                │
│   File "/opt/conda/lib/python3.9/pathlib.py", line 390, in gethomedir                                                                                │
│     return pwd.getpwuid(os.getuid()).pw_dir                                                                                │
│ KeyError: 'getpwuid(): uid not found: 1000'

It was released on Jun 9, 2024
Pull request in upstream, that potentially caused it: https://github.com/tomplus/kubernetes_asyncio/pull/307
I have verified the error is gone in the previous version.

What does this implement/fix?
Put a x in the boxes that apply

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[x] Did you test the pull request locally?
[ ] Did you add new tests?

Documentation

Access-centered content checklist
Text styling

[ ] The content is written with plain language (where relevant).
[ ] If there are headers, they use the proper header tags (with only one level-one header: H1 or # in markdown).
[ ] All links describe where they link to (for example, check the Nebari website).
[ ] This content adheres to the Nebari style guides.

Non-text content

[ ] All content is represented as text (for example, images need alt text, and videos need captions or descriptive transcripts).
[ ] If there are emojis, there are not more than three in a row.
[ ] Don't use flashing GIFs or videos.
[ ] If the content were to be read as plain text, it still makes sense, and no information is missing.

Any other comments?

Do we need to report the kubernetes_asyncio issue somewhere upstream so that it is fixed once we do need to migrate?

@aktech do we need to get this in for the next Nebari release?

@marcelovilla Yes, absolutely.


EventStream not working

Hello. My apologies - while upgrading to tokio 0.3, I introduced a bug which causes some problems with reading events from an EventStream instance. Only one or two events get read, the rest becomes lost.
Minimal reproducible example, try this with inotify 0.8.3 and inotify 0.9.0. Move your mouse or type on your keyboard and watch the output of this program.
#[tokio::main]
async fn main() {
    let mut inotify = Inotify::init().unwrap();
    inotify
        .add_watch("/dev/input", WatchMask::ALL_EVENTS)
        .unwrap();

    let mut stream = inotify.event_stream([0; 512]).unwrap();
    while let Some(event) = stream.next().await {
        let event = event.unwrap();
        println!("{:?}", event);
    }
}

I suggest that you yank the 0.9.0 release from crates.io until a fix is made. I think it will be something trivial, probably a missing task wake up or something like that.

Fixed in #161. Closing.


Implement --silent for smithy build

Issue #, if available: #1062
Description of changes:
This commit adds the --silent flag to smithy build, which suppresses all non-error output during build. This includes validation statistics and information about plugins and projections. In the event that an error is encountered, output is printed and execution halted as normal.
For now, this PR only extends the build command. Validation is used in several places, such as validate and ast, but in these instances it is already passed a feature set containing QUIET. The code is a little hacky but I've started by making the changes as minimally invasive as possible. Additionally some test cases have been added to try and guard the functionality of the need case. Feedback welcome!
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

A better way to handle this flag would be to configure the stdout Consumer<String>
member in https://github.com/awslabs/smithy/blob/main/smithy-cli/src/main/java/software/amazon/smithy/cli/Cli.java to a no-op when the --silent flag is picked up. After setting that up, the rest of the command execution can stay the same. All of the Cli.stdout(...) statements can remain without check and it'll still go nowhere.

Ah of course, I can't believe I missed that. However, this would disable error and danger outputs in the validator, wouldn't it? We'd want to change that logic there so that it used stderr, or something else?

I agree, and think we need associated changes needed to what is going to stdout and stderr in smithy-build. Errors observed in the smithy build logic should go into stderr.

So the plot thickens on this. I can make the necessary changes, but because the setStdout and associated methods are static on Cli, other tests start to fail because the change persists throughout the suite. Two options I can see here:

Have BuildCommand clean up after itself, restoring Cli's stdout property when it has executed.
Look at redesigning Cli so that we create instances of it, in which case the stdout change will be localised to the (presumably singleton) instance used in a single CLI execution (as in each test case, for instance).

Thoughts on this/any other solutions?

Awe, sorry this is more work than it first seemed. The only public API surface area of the CLI we need to not change are the arguments and how it's invoked. All the innards of it can be completely changed if needed. We can also add this to our backlog of things to work on if it's more than you can commit to right now.

I started working on https://github.com/awslabs/smithy/pull/1257 which should make this easier to implement.


Fix typos and grammatical errors

There are some grammatical errors in the /internships/applicant-guide/ page that needs to be fixed.

Should be contacting in place of contact.

Should be Also, in place of Also.

Also, we can replace open source with open-source.

@rajat2502 thank you for reporting these. Please go ahead and fix the first two issues you mentioned.
Re: "open source", we prefer to use it unhyphenated.

Sure, I will make a PR to fix both of them.

Hey @kgodey, I am not able to make a pull request, I think the rights are disabled right now.

@rajat2502 are you sending in a PR for this

@fakela Yeah, I just made a PR for the same.


Game Menu Bug

By pressing escape you open a game menu, in the game menu I have crossed kkthnxUI bar with Log Out bar, which is pretty annoying.
https://imgur.com/a/7WbWTsm
I tryed to fix it in settings, but there is no setting for it, neither in move anything or in any other addons.

Fixed in latest github version.


Implement integration test for web3signer API

web3signer API is used in each eth2 client, there should be implemented integration test to test this API to be triggered in every new release

To be implemented in anothe repository


Implement best practices for linkerd-bundle app

Coming from here.
The goal of this issue is to have the App eventually adhere to standard cloud-native best-practices. The points below are to be considered non-exhaustive. Feel free to add some that make sense and remove some that don't. If this issue does not make sense (e.g. is a duplicate or covers a deprecated app) please close it.
Expected outcome:

[x] the app has properly set PDBs (as percentages)
[x] the app can scale horizontally based on Custom Metrics (if it makes sense)
[x] the app runs with more than 1 replica by default (if it needs HA)
[x] the app does not use emptyDir volumes if not strictly necessary

It's a bundle, no actual workload.


Store Search-API-relative URL for all saved searches.

As well as saving some bytes, and making our saved search data portable between environments, this removes a theoretical attack vector i.e. where a client sends a malicious URL into the API as a 'saved search'.
https://trello.com/c/jjVWnK1e/722-security-fixes-for-save-search-feature

For added clarity: the weird prefix-removal is necessary in order for the last two test cases to pass, neither of which we expect to happen in real life in our application, but I think are necessary if the function is to have well-defined behaviour in all the edge cases. (Including the case of our search API being mounted somewhere other than /, which seems like a terribly bad idea but not entirely impossible.)


Implement named export support for CJS modules

Adds the ability for a worker module definition to define a list of named exports. So if the CJS module exports something like...
exports.foo = 42;

Then the worker can import foo directly from the module:
import { foo } from 'cjs-module';

This just enables the exports in workerd, a separate internal PR will be required to enable it's use in production.
The runtime does very little lifting here. It will be up to whomever is constructing the worker module configuration to identify the exports that should be provided. The runtime will not try to automatically detect the exports. if an export is named but not actually defined by the CJS module, then it's value will be undefined. Only exports that are defined when the initial evaluation of the module completes will be supported (CJS generally allows exports to be modified dynamically), and the exports will only work if the module.exports value is a non-null object.
This feature was requested by the frameworks team.
Fixes: #2189

I thought about this a bit this morning and I was wondering if we could make this an internal feature similar to the fallback service to limit the exposure.
We don't need this functionality in the prod where users can easily work around the lack of this feature by using namespace imports rather than named/destructured or star imports.
We only need this functionality in combination with the module fallback service which deals with 3rd party code that we don't control and don't want to augment.

I think it makes sense to expose it and implementing this way is the easiest thing to do for the fallback service as well.

I'll leave it to y'all to decide. I'm just suggesting reducing the scope so that we don't needlessly expand the API surface we need to support in edgeworker/prod.
While this feature is critical for the Vite integration that uses the fallback service, it is not very useful for normal users as they control the code in the bundle, so adding it to edgeworker is just a liability IMO especially given the potential to misconfigure the named experts, etc. But again, I'll defer to y'alls decision.

... given the potential to misconfigure the named experts, etc

There's really not much risk here. At worse they specify a non-existent export and the value gets set to undefined. There's very little actual risk in the runtime for this.

... to have a test for the case when the expected namedExports are not exports...

That's already covered by the test here https://github.com/cloudflare/workerd/pull/2194/files#diff-d670df980d58c3fa6e9288fc2791fcd96c65a684afe41d98dbb36c7749227fcc ... specifically, the namedExports defines a bar export that is not actually exported by the module. It's value ends up being undefined on import. I would not expect there to be an exception thrown.


Alt improvements

Addresses https://github.com/mamaral/xkcd-Open-Source/issues/10

Changes Unknown when pulling 61e25d45838d3524e8046486899372753fa2a000 on alt-improvements into ** on v1.1**.


Clean: application-local.properties

Not sure it is really used, so I think we need to remove it
So no need to maintain it in our modules

IMHO it's useful to have a dedicated Spring profile for configuration dedicated to development.
It should even be enabled by default, and disabled in CI/CD, in order to improves developer experience: you just need to checkout the sources, and have the fewest as possible steps to have things working locally.

I can understand, but I don't want to follow generator-jhipster, with 'dev', 'prod', 'testdev', 'testprod' profiles, which are so confusing :-D
For my own use, what I put in application-local:

change logging level, to DEBUG
activate devtools

And that's all. Can you share me your own use ?

I agree that 'dev', 'prod', 'testdev', 'testprod' profiles are confusing :-D
But I'm sure we can find a balanced in-between :-)
Use cases I see in real world enterprise applications:

disable sending metrics and logs for observability
use a different authentication method and/or oauth2 provider
distinct timeouts or scheduler duration
configure a specific maps layers provider
specific kafka configuration (topics, timeouts, ...)
...

Another usage I was thinking about: activating AsyncSpringLiquibase for development (which is BTW the only useful usage of AsyncSpringLiquibase)

We can close this, as we can keep this file


[docs] Build docs only when doc files change

Build docs only when change happens in docs/source
See for example https://github.com/huggingface/api-inference/blob/main/.github/workflows/build_documentation.yml#L3-L8

Thanks !


Removing tvservice

Changing buggy tvservice to vcgencmd display_power to fix #125

Hey, thanks a lot, this seems to work a lot better!

There's also now a new image with everything updated to the latest versions, which includes this change.


[RFE] add the option to deploy the hosted engine when the DWH deploy on different machine

Since there are situations that we need the DWH on a different machine
the current option is to do the regular deploy and just after it complete to do the following:
https://www.ovirt.org/documentation/data-warehouse/Migrating_Data_Warehouse_to_a_Separate_Machine.html#migrating-the-data-warehouse-service-to-a-separate-machine
it will be great if we have this option in the deployment process.

@arachmani , @eslutsky can you please review?


Wrong documentation link for Identities section

[Enter feedback here]
For the deployment objective of privileged identities in the second point, the wrong documentation link is provided
https://learn.microsoft.com/en-us/security/zero-trust/user-access-productivity-validate-trust#deployment-objectives

Deploy Azure AD Privileged Identity Management (PIM) for a time-bound, just-in-time approval process for the use of privileged user accounts. | IT implementer | Plan a Privileged Identity Management deployment

As you can see it says Plan a Privileged Identity Management deployment but when you click on it the link which open is for MFA https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted
Please provide the correct link and also update the documentation.

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

ID: 3a4bb5ca-6112-c452-45bf-e580086b4b5f
Version Independent ID: 3a4bb5ca-6112-c452-45bf-e580086b4b5f
Content: RaMP Checklist — Explicitly validate trust for all access requests
Content Source: zero-trust/user-access-productivity-validate-trust.md
Service: security
GitHub Login: @Dansimp
Microsoft Alias: dansimp2. Deploy Azure AD Privileged Identity Management (PIM) for a time-bound, just-in-time approval process for the use of privileged user accounts.	IT implementer	Plan a Privileged Identity Management deployment

@subodhpatil  This has been corrected. Thanks so much for letting us know.


Detect size only change

This PR builds on #94
Sometimes the watcher would not detect file changes if successive changes to a file happened very quickly, specifically within the min resolution that the underlying file system could represent for mod time stamps. In my case, I was testing on a file system which had 1 second mod time stamp resolution. If I edited a file twice in 1 second, then the second write event was lost.
This was principally visible in some unit tests where a series of quick modifications to files happened to occur, but it could happen in real situations also I guess, hence this fix.
The fix simply emits a Write event if the mod time changes OR if the size changes.

Note, although this PR builds on #94, it only needs it because the unit test uses ScanNow(). If you want to take this without #94 that is possible, but you'll have to just take the change to watcher.go and leave the tests behind.


Applying zonal_statistics function across all images in Image Collection

geemap version: 0.7.13
Python version:  3.5
Operating System: Windows/Jupyter Notebook

Description
Hi,
Thank you for the excellent tutorials and hands on approach to using geemap libraries.  I have an ImageCollection ("MODIS/006/MOD11A1") which is filtered by dates - roughly 150 images.  Goal of my project would be iterating each image through a feature collection "TIGER/2018/Counties") and storing results in CSV files.
What I Did
I followed the example on geemap/examples/notebooks/12_zonal_statistics.ipynb and modified it for my purpose and was succesful in taking out first image and running it through zonal_statistics function and storing the results in CSV file. But I was unable to do a for loop or iterate through rest 149 images.
My Code:
'''
#Importing Image Collection Dataset
imagecollectionL8 = ee.ImageCollection("MODIS/006/MOD11A1").filterDate('2020-02-01', '2020-06-30');
imagecollectionL8   #I have about 150 individual images. Each day corresponds to one day in my filtered period.
#CollectionSize
collectionSize = imagecollectionL8.toList(imagecollectionL8.size());
#FeatureCollection
Counties = ee.FeatureCollection("TIGER/2018/Counties")
#FilteringOutFirstImage
firstImage = ee.Image(collectionSize.get(0));   // Not sure how to replace this with a for loop
firstImage
#UploadingToCSVOnOutput
out_dir = os.path.join(os.path.expanduser('~'), 'Downloads')
out_dem_stats = os.path.join(out_dir, 'Counties .csv')
geemap.zonal_statistics(firstImage, Counties, out_dem_stats,  statistics_type='MEAN', scale=1000)
'''
Are there any different approaches to iterate?  The docs on google earth editor were on Javascript and I wanted to work through it using python.
Any inputs would be helpful.
Thanks and Regadrs
Niranjan Ravi.

Simply convert your imageCollection to image (e.g., image=collection.toBands()) and then pass the image argument into the zonal statistics function.

Hi,
 Thank you, it worked. Meanwhile, i tried this approach:

for i in range(collectionSize):
firstImage = ee.Image(collectionList.get(i));
out_dem_stats = os.path.join(out_dir, str(i) + 'stats.csv')
geemap.zonal_statistics(firstImage, Counties, out_dem_stats,  statistics_type='MEAN', scale=1000)
This also worked.
Both approaches are correct?

Do NOT use for loop. It is not recommended. See https://developers.google.com/earth-engine/guides/client_server#looping


Make the conversion from geo::Polygon to geom::Polygon fallible

Towards the quest of making geom::Polygon always internally just wrap a geo::Polygon.
Why is this necessary?
geom tries to be stricter than geo, rejecting "bad" geometry upfront to try to isolate a problem at its source. A Ring must not have any duplicate points (adjacent or not), except for the first = last point. This is further complicated by "duplicate" points being defined a bit strictly. Every Pt2D trims its f64's down to a few decimal places.
I'm starting to question if this attempt at upfront strictness is even helpful. In the beginning, it was an attempt to "clean up" a bunch of crazy OSM geometry I was encountering or algorithmically producing, but I've lost context on many of the original motivating problems. Many might've been solved in another way by now. Also, the strictness isn't even complete -- my mental model of a Ring is that there are no self-intersections at all, but nothing looks for this right now.
The strictness is actually only useful in geom::PolyLine code anyway. Most of the hand-written geometry logic is there now. Operations like finding a point some distance along the polyline, or projecting a polyline left or right for buffering are easier to reason about without duplicate adjacent points, or even without internal points that're "redundant" from an angle perspective (aka a polyline [(0, 0), (10, 0), (20, 0)] has a redundant middle point, it could just be [(0, 0), (20, 0)]).
There've been countless times somebody sends me a bug report with an unhelpful error about duplicate points in a ring. Even when the stack trace shows something, it's not easy to reconstruct context about which object in the map caused the problem. My fear has been that if invalid geometry "sneaks in", then there will be rendering, hitbox testing, etc bugs downstream that're hard to catch. But in reality, I can't really say all the strict checks have caught that many problems.
Alternative
I feel like I just convinced myself that the validity checks should actually go away now. The heftier bits of logic in PolyLine can just be made to deal with duplicate adjacent points and the like. Any opinions?
Next steps
Back to the original goal of making geom::Polygon less weird. After this PR (or rethinking the validity checks), I think it'll be:

Dealing with geom::Polygon transforms sometimes destroying the internal rings through operations like scaling. For this reason, strip_rings is often used. But then, if the validity checks go away, maybe this isn't actually a problem.
Figuring out what Circle::to_polygon and PolyLine::make_polygons should return. They pre-tessellate right now, which is useful for performance. But many callers also need the real Polygon too, to produce outlines or do other operations.
Changing the internal geom::Polygon representation to either wrap geo::Polygon or just be exterior: Ring, holes: Vec<Ring>

Validation
Oh yeah, and this PR has some impacts on bits of downstream code. I'll comment inline in the changed code. I will need to reimport all maps, where I might hit a few new problems, but I think I understand all the effect right now

The regressions are in code complexity, not observable behavior -- I haven't found a single example where convex hull fails to return something valid, for example.
I'm still in a mild existential crisis about whether or not geom should try to be enforcing all of this extra strictness about duplicate points or not. But for the moment, this PR makes things more consistent and gets us closer to cleaning up geom::Polygon, so i'll go forward with it. Thanks for the review!


[feat] add a link to clubnfts backup service to help ppl with backing up their NFTs

Describe the problem
This has been brought up in summer 22 on our discord (https://discordapp.com/channels/908672304236625970/941924294701748294/983438137499987988)
clubnft has built a backup solution with which users can backup their creations and/or collection from IPFS files locally so in case something happens to the pinned files on ipfs users can easily restore the content associated with their NFTs.
this is an easy and free solution to make our ecosystem more robust and resilient. if everyone does this regularly, we have an extremely strong layer of protection for all the media of our NFTs.
butiq and versum have already "integrated" the backup tool into their UI by simply linking to it in their "integrations tab"
like here on versum:
https://versum.xyz/settings/integrations

the "protect your collection" button is a simple link to: https://app.clubnft.com/
Describe the solution you'd like
add a link to https://app.clubnft.com/  in the "config" tab of teia
the text could say something like:

Save the content of all your NFTs on your own harddrive for free with ClubNFTs backup Tool
learn more about how it works here

Alternatives considered
No response
Additional context
No response

Oh I did not realize that was what "integration" meant when we mentioned it. Awesome.
Do we have the "official" logos somewhere ?

hey mel i will get in touch with their team and ask for a logo and just check the general idea.
will get back to you when i have news

Surf wanted to make a backup, so we looked if clubnft was still a thing. It was, but a bit too expensive for us.
So I quickly made backup.teia.art (code: https://github.com/Zir0h/teia-backup) as a POC. It's meant to be used with the browser addon https://www.downthemall.net/
The idea is that you put a wallet address and it generates a list of ipfs links that you can easily download with DTA.


Improve release process around exported submodules

PR https://github.com/signalfx/splunk-otel-collector/pull/2090 and https://github.com/signalfx/splunk-otel-collector/pull/2092 have helped in moving the smartagent, timestamp and oracledb receivers/processors/extensions into their own go modules, but there is still extra work to make them readily accessible by external code which wants to integrate them into a custom OpenTelemetry Collector build.
As described in this PR's RELEASING.md explanation, exported go modules need to also be tagged appropriately in the source repo such that go get<EMAIL_ADDRESS>(for example) can fetch them directly from github.com.
The primary changes here are

Modify the names of the exported go modules to exactly match their subdirectory paths inside the repo. While this is not a problem within the repo where replace directives are used to point directly to the in-repo source, for external users, the names of the modules should match the names of the subdirectories.
Create a release process that creates the correct tags on the repo to allow go get to find the specific submodule within the repo. Specifically, if a module is located inside the pkg/receiver/smartagentreceiver subdirectory, then external sources can only reference a specific version x.y.z of the module if there is also a tag pkg/receiver/smartagentreceiver/vx.y.z on the repo.
Finally, to verify that tags have been created correctly after a release, adding an example which will build an OpenTelemetry Collector binary that uses those externally referenced modules without any replaces directives is a good method of validating that the tags are in the correct place.

I've mostly cribbed the release process for this multimodule versioning and tagging by reusing the multimod tool developed for the opentelemetry-go and opentelemetry-collector-contrib repos.
Feel free to change, reuse portions, or discard this PR. There are likely places where I'm not following Splunk standard conventions given I'm an outside contributor.

Thank you for the PR! We appreciate it and will review asap.

@evantorrie thank you for taking the time to build this exhaustive PR. We appreciate it.
There are elements of this PR that we should look at integrating right away, such as fixes to paths or package declarations for examples. I will peel them off from this PR into their own PRs, making them easier to distinguish from the main work you performed here. This will allow our engineers to work on reviewing your main body of work, specifically the RELEASING.md file and accompanying artifacts.

Closing in favor of #2644 which addresses directory names/module names and a subsequent separate PR to address the tagging/release process.


Should build-plans be deleted?

The cargo team has been talking about this for some time now, and this is an issue I'd like to open to cc others and get some discussion about this.
The build-plan feature of Cargo is broken, and has always been broken. It has never actually accounted for all the build intricacies of crate graphs that Cargo supports. It was landed to unblock initial work with the understanding that it wouldn't be stabilized before it was fleshed out more, but the work to flesh it out more hasn't happened since then. The build plan does not support, for example:

Transitively passing arguments from build scripts to later crates
Encoding information about pipelining
Requires implementors to have their own parsing of build script outputs and such

There is not a known great solution for these fundamental issues, and there has not been much effort to investigate this. Cargo has received very little maintenance of build plans and new features in Cargo typically don't consider keeping build plans working, leading to issues like https://github.com/rust-lang/cargo/pull/7604. Additionally build plans are only very lightly tested, so there's not a huge amount of protection against regressions.
Given all this the Cargo team is leaning towards deleting this feature. The existence of the feature seems to give the guise that it's supported and officially recommended, when in fact it's neither supported nor recommended. The feature, as implemented, seems dead in the water without significant refactorings that may require starting from scratch anyway.
The feature, however, currently has what we believe is enough users that we don't want to just outright delete it. We'd like to cc some folks who we believe are using this feature on this issue. If you're not using the feature or you're not interested, sorry for the cc but feel free to unsubscribe yourself!
The Cargo team is specifically interested in asking others if they are aware of the downsides of the build plan feature, and also if others are available to help fix this feature and implement a working system. The Cargo team does not have the bandwidth to either design a working build plan or implement it at this time, so both the design and implementation work is what we're interested in getting help for.
While it's useful to list out the bugs in the current build plan, the Cargo team is hesitant to land fixes such as https://github.com/rust-lang/cargo/pull/7604 at this time. These "small fixes" perpetrate the sub-par integration of build plans into Cargo today and makes the codebase harder to maintain. What we're particularly interested is figuring out a way to get build plans onto more solid footing such that they can actually be supported.
cc @edwin0cheng
cc @vlad20012
cc @matklad
cc @Manishearth

FWIW, IntelliJ IDEA and rust-analyzer are only (atm) using build-plan to get the value of OUT_DIR. If there were some other way to get at it (e.g. #7546), then they wouldn't have any reason to use it anymore.

I'm not the right person to cc for this, you should ping someone who works on Firefox

In IntelliJ Rust we use build-plan only to locate buildscript output directory (env!("OUT_DIR") in build.rs) for each crate in the graph. The ability to locate these directories is critical (but not really enough) to support code generation in the IDE. So, I'd be happy with a thing like #7546 as a replacement.
(but in long-term, we need something like #7178 with the ability to get all outputs of all buildscripts in a dependency graph)

cc @Xanewok , I think build plans play a role in the non-cargo story for RLS.
I’ll write a bigger response once I am a the real keyboard, but in-short, my opinion is:

OUT_DIR and build.rs produced cfgs should be communicated to the IDEs somehow
build plan seems to be a conceptually wrong way to do this, +1 to removal (unless 3rd party build system integration benefits from build plans)
I don’t know how a good solution for IDE problem should look like, current cargo semantics make this non-trivial
given that IntelliJ already needs OUT_DIR, and rust-analyzer will need it “soon” (soon — someone has a spare weekend) it might make sense to prototype some replacement for the narrow IDE use-case. It’s ok if it’s nightly only.

The core problem is that IntelliJ Rust needs a way to get OUT_DIR. They already implemented all the machinery for processing include!(concat!(env!("OUT_DIR"), "bindings.rs")). And handling such includes is important for user-experience of those who use code-generation.
It would be great to have some replacement feature for sniffing OUT_DIR. It doesn't have to be stable: tools have to track nightly for various reasons anyway.
Ideally, this info should be a part of cargo metadata, because IDEs really love the static picture of dependencies between the crates. Unfortunately, this can't work, because build scripts are fundamentally associated with units, and not with packages. That is, cargo build and cargo build --release will use (I think) different OUT_DIRs.
Long-term, we probably should do something like #7178, and maybe even try to move to "build.rs per package", and not "build.rs per unit" model.
For the time being, I like @ehuss suggestion: https://github.com/rust-lang/cargo/issues/7546#issuecomment-551948375. Basically, we just include OUT_DIR to the build-script json message, as if it printed cargo:rustc-env:OUT_DIR=/foo/bar. This seems like something we should just do. Should I send a PR ? :) This is forward compatible (and even a required part of) #7178. IntelliJ can then have a special UI action like "scrape build config", which is explicitly invoked by the user, runs cargo build --message-format=json and fishes out OUT_DIR (and cfg as well). That's a pretty awkward UX, but it is much better than nothing at all.
Just to give a better understanding of IDE requirements here, I believe the following small data-structure captures the information a Rust IDE needs pretty well:
https://github.com/rust-analyzer/rust-analyzer/blob/f4b1fb1554b639374adeffa50d4719f834a0d475/crates/ra_db/src/input.rs#L67-L110
It is much simpler than Cargo's internal representation, and the question is, how we lower Cargo's repr to this CrateGraph.

Note also that IDE use-case seems to be over-represented in this issue, while the original and main motivation for build plan was integration with other build systems. Should we cc folks from Facebook or Google maybe?

Basically, we just include OUT_DIR to the build-script json message, as if it printed cargo:rustc-env:OUT_DIR=/foo/bar. This seems like something we should just do. Should I send a PR ? :)

If that works for you. I'm not familiar with how rust-analyzer or intellij works. I would maybe just add a new key to the structure (out_dir) instead of stuffing it in the env array (to avoid confusion about what the script sets vs what cargo sets).

cc @Xanewok , I think build plans play a role in the non-cargo story for RLS.

Yes, that's currently how our support for external build systems work. We parse the --build-plan output and do the compilation ourselves in the RLS.
FWIW I tried to address the build plan integration and (by accident) #7178 while working on Buck integration in the PR #6213.
To generate a detailed build plan (where you only need to run rustc) one had to run and parse the output of build scripts before a full, static build plan could be generated. The original motivation for that PR was to emit file dependencies per each unit but as it turns out that's also only available in the post-build-script phase, so that's what was implemented.
We agreed with @alexcrichton then that approach from #6213 seemed too 'bolted-on' and would require more effort to get it right. Maybe now would be a good time to design together a better way forward? Until then, I think it'd be good not to outright remove delete them (maybe we could deprecate/destabilize it?) until we know how to proceed.

Thanks for all the responses everyone! With the merge of https://github.com/rust-lang/cargo/pull/7622 it sounds like we may be on good track to delete build plan support? I suspect that'll want to propagate through for a few weeks/cycles, but once all the tools switch over to that I believe we'll have no active users of the build plan support.

cc @jsgf

I have a pretty solid tool for generating Buck build rules from Cargo, and build plans have played no part in that. I did try to use them, but found the information was at the wrong level of abstraction.
I'm fine with removing build plans and trying again from scratch.

Ok I'm going to set myself a TODO for ~2 months from now to delete build plans. In the meantime we can update documentation and such and make sure to comment on issues that the intention is to delete this feature.

There is a tool, I'm actively developing, that uses build plans - cargo-wharf.
The tool is an integration layer for BuildKit build system and effectively is "cargo in docker". It uses the build plan feature to construct a BuildKit graph.
It didn't get much attention yet, but I believe in its potential since I think many people might use Rust for creating async scalable microservices now. This often involves containerization and Docker is a popular choice.
Interesting enough, the current implementation and its limitation are perfectly fit into my use case. For instance, the independent (from Cargo) build scripts running made possible to have a system-wide build script results caching.

On the other hand, I understand that there is no reason to keep an unstable feature that is not being widely used. Especially if its maintenance often makes a hard time for contributors. For quite a while, I was under the impression that Cargo uses build plans internally.
Would it possibly make sense to gradually make Cargo to first generate a build plan and then only to execute it? Right now it probably won't give any benefits, but in the future, it might lead to interesting possibilities. I have a feeling the refactoring might also improve maintainability and testability of the Cargo code.

@denzp that was sort of the theory for build plans all along, but it never manifested. Build plans, as is today, are suitable to drive Cargo's own compilation. I think most here want to see a world where Cargo build plans exist, but the problem is that we're not there today and we don't have any manpower to actually make it a reality, so the team decided it's best to reflect reality and delete the build plan feature rather than let it linger and give the false impression that it will ever be stabilized near as-is.

I've used build plans to reduce compile times*.
Using --build-plan to get the final rustc invocation seemed less brittle than parsing the output of cargo build --verbose, but as the mentioned issues show that turned out not to be the case.
The introduced cache-busting forcing all dependencies to be recompiled made --build-plan useless for me, and I'm fine with it being removed as I have alternatives.
*: I was implementing code reloading for a game, and had noticed that running the final rustc command directly was slightly (but noticeably) faster than cargo build.
I'm aware of having to run build scripts as I noticed missing linker flags. That was unexpected, but I implementing running them. (The time savings from reduced compile times certainly haven't paid off, but time passes faster when writing code than when waiting for other code to compile :wink:)

I've been planning (heh) on adding Cargo integration to Meson using the build-plan feature, so I was surprised and disappointed to hear that no one else has been working on it or using it actively.
However, I'm glad to hear that the Cargo team wants something like build-plans to exist, since if I do find time to work on Cargo integration in Meson in the future, I would like to pick this up again.
Thanks for the clear communication around this deprecation.

@alexcrichton would you recommend me to investigate and propose build-plans v2 and estimated steps how the Cargo internals can be "rebased" on top of a build plan? If that's something Cargo Team is still interested in, I'd like to give it a shot.

@denzp we're still very interesting in having something done in this space, but unfortunately the cargo team doesn't have a lot of time to help out with it right now. We'd like to see iteration and development on build plans, though, so it's trying to find a good balance of getting this feature designed/implemented with not halting other work to focus all efforts on this.
That's unfortunately not a great answer, but if you're ok being pretty independent in investigating a "v2 build plans" that'd be best!

Disclaimer: I haven't followed the whole conversation here, and I'm not even a cargo/rust user. But as a Meson and GStreamer developer (not maintainer) I tried to have a plan to integrate with Cargo.
The big challenge is how do we pass dependency information from Meson to Cargo and vice-versa. I came to the conclusion that pkg-config's -uninstalled.pc are exactly that. With the Meson PR https://github.com/mesonbuild/meson/pull/4436 we can generate a -uninstalled.pc for each library built by Meson, and we can set PKG_CONFIG_PATH pointing to the directory where Meson gen them when invoking Cargo, and it will use them (it works with gst-plugins-rs).
The missing part is doing the other way around: Use libraries built by Cargo in Meson. For that we would need Cargo to be able to generate -uninstalled.pc files at configure time (that concept does not yet exist in Cargo, AFAIK). So I think adding in cargo a mode that would:

Download all crates
For each crate, tell them to generate their -uninstalled.pc files.
Return the path to the directory where it all got created.

That way, Meson could invoke that Cargo configuration step, then set PKG_CONFIG_PATH to the location of -uninstalled.pc files, so future dependency() calls in Meson will find them.
I'm sure there still would be rough edges, but that would be a good start.

@vlad20012 https://github.com/rust-lang/cargo/pull/7622

cargo-raze is an interesting tool that works at what I'd consider to be the correct level of abstraction (it is literally built for integrating into another build system).
On Fuchsia we were discussing adapting cargo-raze for our build system (GN) and using that as a template for build plans v2, but we haven't had time to push that forward yet.

cargo-raze is an interesting tool that works at what I'd consider to be the correct level of abstraction (it is literally built for integrating into another build system).

I was literally just leaving a comment on a cargo-raze issue that referenced the build plan output. cargo-raze currently uses cargo as a crate dependency which makes its build times very long and isn't ideal from anyone's perspective. Figuring out a path forward for the build plan work so that it meets the needs of tools like that and @jgsf's buck tool sounds ideal to me. (My current work environment has a Rust project built via cargo and also gradle and XCode in the mix and I'd love to replace it all with bazel TBH.)

@luser My tool is in production use in house, and I've started the process to open source it. I think its output will likely work with Bazel as well (or wouldn't take much to make it work).

I've put up https://github.com/rust-lang/cargo/pull/7902 to carry through the conclusion of this.

To follow up on @chmanchester's previous comment, we did carry out the prototype to integrate cargo --build-plan with the Firefox build. The proof of concept is hacky and not production-ready (even setting aside the fact that build plan support in cargo is apparently being deleted imminently), but what we're seeing so far is that using Cargo to fetch the build plans which we then convert into make recipes:

works (i.e., is not clearly broken and can be used to construct all the .rlibs and .rmeta files that cargo would make much in the same way);
has somewhat lower overall end-to-end latency than just using cargo to build all the Rust libraries/binaries in tree, as we currently do at HEAD; and
gives us a more granular and precise view of how our Rust code is built, giving us more knobs to tweak when optimizing the Firefox build for better parallelism/scheduling compared to what we currently have, which is a series of cargo rustc calls that we essentially have to treat as black boxes.

So even if we won't have the option to hitch our star to --build-plan, the results of this prototype suggest that something along these lines would be a very fruitful approach for optimizing the Firefox build in the future. If --build-plan is doomed in its current form then we on the build team at Mozilla would be interested in discussing other possible ways forward here, especially since a production-ready v2 of this feature seems generally useful and applicable to several different projects, like the Bazel and Buck tools mentioned above.

In the spirit of cargo-raze, we use a tool called cargo-GNaw for our builds now.
https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/tools/cargo-gnaw/
It consumes cargo metadata and outputs GN files. I'm not going to go so far as to call cargo-metadata the ideal way of doing this, but it is sufficient.

cc https://github.com/rust-lang/cargo/issues/8002 which might cover some of the plausible use-cases for build-plans.

Should build-plan be removed, what would the alternative be? I'm interested in using something like this in cargo-raze and I think it'll greatly benefit the Bazel Rust rules as well. Perhaps one of the code owners from that project would be able to chime in here.
@acmcarther @mfarrugi @damienmg @smklein @dfreese

The current approach I would prefer would be to step outside of build plans to use build manifest although this is a lot of work.

@damienmg do build manifests currently contain all the necessary information? What is the outstanding work here? (If you don't mind 😅)

Build plan contains all the information we need, manifest does not contains the version resolution, which is not the job of Bazel so we would have to have a tool to do it. Other than version resolution I don't see any issue that cannot be done on Bazel side (and the fact that parsing toml would need a custom tool).

cargo-metadata does indeed have version resolution info. Docs are sparse but Resolve gets you a graph which you can use to look up resolved packages by ID. Each package has its version attached.
This is how cargo-gnaw works (linked above).

BTW I did end up releasing my tool reindeer, which automatically (as possible) generates Buck build rules from Cargo dependencies.

Removing sounds good to me. I think a future version of this should be more actively dog-fooded by Cargo: in "normal mode" it just executes the plan it would spit out. That would of course require lot of work, but I really think that level of fidelity really is necessary to get decent value.
Relatedly, if build.rs got replaced with, say, build.ninja, it would be very interesting to merge that into the Cargo plan and get something nice and granular.

Out of curiosity, what exactly is the status of this? --build-plan still appears to be available in nightly, but it looks like intellij no longer depends on it- is the fact that it's still in the codebase a consequence of no one having gotten around to cleaning it up?

The holy grail for production users is fine-grained caching of dependencies with reproducible builds.
I have been trying to find some solutions in this space for a while - cargo-chef is an attempt that plays nicely with Docker, but the cache is busted every time one crate changes in the dependency tree. The implementation is a glorified hack, trying as hard as possible not to re-implement cargo logic outside of cargo.
I spent the last couple of weeks exploring alternative nix-based build systems for Rust projects (the various crate2nix, cargo2nix, naersk, etc.) - they are all, to various degrees, trying to re-implement cargo outside of cargo, based on partial information (cargo metadata, usually).
The only way to have a robust integration point for other build systems would be to ensure that cargo is actually using the same set of information to execute than it is providing to those other build systems - dog-fooding it, as @Ericson2314 mentioned.
Is --unit-graph supposed to be the replacement of build-plans? Can it be relied upon, or is there a risk to see "diverging" builds because it is missing some information?

@LukeMathWalker We're using https://github.com/facebookincubator/reindeer in production with good success. It uses cargo to do version resolution and vendoring, then uses the output of cargo metadata to generate a complete set of build rules for Buck (which I suspect would very nearly work with Bazel, gn and similar build systems).
I initially tried using build plans but they're just at the wrong level. I don't want a trace of what cargo would do, but a more declarative description of what needs to be done not how to do it.
The main blocker here are build scripts since they can do unconstrained things with undescribed dependencies.

We use a very similar approach for gn: cargo-gnaw along with developer scripts to update vendored crates using cargo's version resolution.

I do have a use case in mind that I was hoping could be accommodated before removing build-plans. We have extended Rustc to generate other kinds of artifacts and we use the same name schema as Rustc, which includes the metadata suffix.
AFAIK, build-plans is the only way we can reliably figure out the name of the files that we generate, especially when cargo build finds that everything is fresh. In that case, our compiler doesn't get invoked, and there is no easy way for us to tell which artifacts we should be using.
We tried to extract the artifact name from the artifact messages, but for things like binaries, static / shared libraries, the list of filenames do not include the original files that were generated by the compiler.
E.g.: For a static library, this is what I get:
"filenames":["/tmp/test/static_lib/target/debug/libstatic_lib.a"]

while for a rust library, I get:
"filenames":["/tmp/test/libA/target/debug/liblibA.rlib","/tmp/test/libA/target/debug/deps/liblibA-728fd0386e8e49d7.rmeta"]


feat: Add redirection support via raising subclasses of HTTPStatus

Define a set of HTTPStatus subclasses that can be raised to perform
various types of HTTP redirects. This should avoid the problem of
hooks and responder methods possibly overriding the redirect. Raising
an instance of one of these classes and will short-circuit request
processing similar to raising an instance of HTTPError.
Specifically, if raised in a before hook, it will skip any remaining
hooks and the responder method, but will not skip any process_response
middleware methods. If raised within a responder, it will skip the
rest of the responder and all after hooks. If raised in an after hook,
it would skip remaining after hooks but not middleware methods. And
finally, if raised within a middleware method, execution would perceive
as described at the bottom of 1.
The above behavior is inherited from HTTPStatus and so is not re-tested
in the subclasses.
Closes #406
Supersedes #486

Reviewer: Please pay particular attention to docstrings, class and variable names, etc. to ensure everything is correct.

Other than my two comments, this LGTM.

@jmvrbanac IIRC the text for those docstrings came from the RFCs. Let me see if I can improve the prose per your comments.

:+1: LGTM

@rouge8 We are getting ready to merge this. Does this approach look good?

Awesome! :+1: Ran my project's tests using this branch (and the minor code changes necessary). API worked as expected and the tests passed. Admittedly, I only used the 301, but this looks good!

when the redirectspy can merge to the master?  I need redirects :)


Bookmarklet to download extensions from Chrome Web Store

Is your feature request related to a problem? Please describe.
I needed a simple and clean solution to install extensions easier from the Store.
Describe the solution you'd like
Based on the wiki instructions I made this:
javascript:location.href='https://clients2.google.com/service/update2/crx?response=redirect&acceptformat=crx2,crx3&prodversion='+(navigator.appVersion.match(/Chrome\/(\S+)/)[1])+'&x=id%'+'3D'+(location.pathname.split('/').pop())+'%'+'26installsource%'+'3Dondemand%'+'26uc';
So first I set the chrome://flags/#extension-mime-request-handling flag to "Always prompt for install", restarted UngooChromium, went to the webstore page, clicked on the bookmarklet, and boom.
Describe alternatives you've considered
There is already a website and an extension, but my bookmarklet is simpler :)
https://github.com/Eloston/ungoogled-chromium/issues/767#issuecomment-523059611 https://github.com/Eloston/ungoogled-chromium/issues/734

I like this, except apparently it's possible to not have the app ID as the last path element. Most of the time this should be fine, so I'll add this. Thanks!

Hi, thanks for adding it. :)
But do you happen to have an example url which is different than these? I haven't found other url schemes:
https://chrome.google.com/webstore/detail/EXTENSIONID
https://chrome.google.com/webstore/detail/EXTNAME/EXTENSIONID
https://chrome.google.com/webstore/detail/EXTNAME/EXTENSIONID?hl=en

@biziclop You won't get there by any normal means, but it's possible to add path elements yourself. These path elements won't be removed after you visit the CWS. If the extension is being linked from somewhere else, it's possible (but unlikely) that the URL may contain unwanted path elements.

Thanks for your answer.
I found another solution, by finding the 'report' link, which is available even for Google's own cr*p:
document.querySelector('a[href^="https://chrome.google.com/webstore/report/"]').pathname.match(/[^\/]+\/*$/)[0]
Full bookmarklet:
javascript:location.href='https://clients2.google.com/service/update2/crx?response=redirect&acceptformat=crx2,crx3&prodversion='+(navigator.appVersion.match(/Chrome\/(\S+)/)[1])+'&x=id%'+'3D'+(document.querySelector('a[href^="https://chrome.google.com/webstore/report/"]').pathname.match(/[^\/]+\/*$/)[0])+'%'+'26installsource%'+'3Dondemand%'+'26uc';

A simple solution is to go to this site that extracts the source code from crx, for some reason on windows when I drag crx in the extensions tab nothing happens.
https://crxextractor.com/

@Clebersonc you need to unpack it to get the source code, the unzip the folder somewhere.
Then load the unpacked extension in extension part.

Old issue but just want to say I think it would help this project a lot if the bookmarklet came pre-installed

@qpwo There exist more convenient ways nowadays: https://github.com/NeverDecaf/chromium-web-store

The Chrome Web Store page changed sometime after mid-September, which broke the bookmarklet.
The report link element now looks like this:
Report a concern

One possible fix:
document.querySelector('a[href$="/report"]').pathname.split('/')[2]

javascript:location.href='https://clients2.google.com/service/update2/crx?response=redirect&acceptformat=crx2,crx3&prodversion='+(navigator.appVersion.match(/Chrome\/(\S+)/)[1])+'&x=id%'+'3D'+(document.querySelector('a[href$="/report"]').pathname.split('/')[2])+'%'+'26installsource%'+'3Dondemand%'+'26uc';


Publish plugin zips to maven repo

Description
With existing setup the plugin jars are only published to maven repo, but not the generated plugin zips.
Related META issue
https://github.com/opensearch-project/opensearch-build/issues/1916
Current Behavior
Existing all maven publications target the jar files to publish to maven, but not the generated distribution zips.
Expected Behavior
Along with plugin jars, plugin zips should also be published to maven repo with right maven coordinates, so user can download these plugins using dependancy model.
Steps To Reproduce

Run the gradle assemble task that outputs jar and zips.
Using build setup the jars are published to local staging maven repo.
Zip's are just added to distribution's folder during build runtime.
Finally once build is done, just the jar files are added to local maven repo and updates to the manifest file, but not the zips.

Proposed solution
A custom gradle plugin solution that can create the publication task for the zips to get published to local staging maven repo with right maven coordinates.
Add/Configure the custom gradle plugin openseearch.pluginzip to the gradle project and test the generated plugin zip's to upload to local maven repo.
More details on how to use the Plugin:
https://github.com/prudhvigodithi/opensearch-plugins/blob/main/GRADLE_CUSTOM_PLUGINS.md
PR

Closing this issue as the feature for publishing plugin zips to maven repo is not required for this repository.
Common-utils is a library for OpenSearch focused on providing reusable Java components for OpenSearch plugins. The final plugin distribution ZIPs should have the required library dependencies.


bug: New lazy loading broken for vim-ledger

Did you check docs and existing issues?

[X] I have read all the lazy.nvim docs
[X] I have searched the existing issues of lazy.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.9.2
Operating system/version
macOS 14.0
Describe the bug
vim-ledger started throwing startup errors due to undefined variables upon opening a ledger file.
The error is:
Error detected while processing BufReadPost Autocommands for "*.ledger"..FileType Autocommands for "*"..Syntax Autocommands
 for "*"..function <SNR>24_SynSet[25]..script /root/.repro/plugins/vim-ledger/syntax/ledger.vim:
line   15:
E121: Undefined variable: g:ledger_is_hledger
line   22:
E121: Undefined variable: b:is_hledger
line   70:
E121: Undefined variable: s:line_comment_chars
line   74:
E121: Undefined variable: b:is_hledger
line   88:
E121: Undefined variable: b:is_hledger
line  147:
E121: Undefined variable: b:is_hledger

The error has started appearing since a recent commit, https://github.com/folke/lazy.nvim/commit/ef2a5d0bd1a4995539b93be69fc760be7d9f62be. @JulesNP also reports there an initialization error, which suggest that something happened to lazy-loading logic.
Steps To Reproduce

touch ledger.ledger
nvim ledger.ledger

Expected Behavior
No error is thrown at start up.
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "ledger/vim-ledger", ft = "ledger" },
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")

Should be fixed now!

Looks good. Thank you!


Stepper Component

Hi,
I've been looking for a stepper component document but couldn't find it. Is there an alternative for stepper in coreui?
please add this component.
Thanks

Hi,
any update?


Show Event Item Totals

Pull Request Test Coverage Report for Build ac29efbc23d80aac7bc96769a73a754dc113685a-PR-183

0 of 14 (0.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.9%) to 71.429%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/athena_web/router.ex
0
1
0.0%

lib/athena_web/frontend/live/dashboard/item_stats_live.ex
0
13
0.0%

Totals

Change from base Build 436d690ebebc6135d8ea75a2e450ef416f7fa401:
-1.9%

Covered Lines:
380

Relevant Lines:
532

💛  - Coveralls


cxxtools: init at 2.2.1

Motivation for this change
Things done

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

[X] NixOS
[ ] OS X
[ ] Linux

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

Fails to build on darwin/clang, see the travis log. Either fix the bug or remove darwin from meta.platforms.

Ok. I changed the platform to linux (I don't use darwin so I can't fix the bug easily).

See https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/text/zimreader/default.nix.

The tntnet framework is a set of 3 libraries: cxxtools (generic C++ library), tntdb (C++ database access library) and tntnet (C++ web application framework). I think these libraries deserve their own packages hence this first PR. Zimreader includes an older version of tntnet/cxxtools and doesn't include tntdb.

I think these libraries deserve their own packages hence this first PR.

I agree.

Zimreader includes an older version of tntnet/cxxtools and doesn't include tntdb.

Please check whether it can use the latest versions you're about to add.

After patching, zimreader seems ok with this version of tntnet: https://github.com/juliendehos/nixpkgs/commit/fbdf87f11b1cdbbc33b5cdfa4288c21700d208dc .

@juliendehos Thanks. So then zimreader can use the expressions you're adding and won't need its own ones anymore.

Yes. I can send PR for tntnet, tntdb and zimreader when cxxtools is merged.

PR created for tntnet (#17813) and tntdb (#17814).


Added "author" in footer instead of double title

I wrote this PR because I thought that having site.title shown twice in the footer was redundant, so I introduced the "author" variable in _config.yml to be shown just above the email address. Moreover, this behavior is optional, since if you don't define the "author" variable it falls back to the "title" variable.

LGTM.
Thanks @Lorthirk!


Amd torch_directml support for Windows amd GPU

Add feature to run on AMD GPU with torch_directml

Second this. Please?


Get chnnale message

How to get messages from a channel

GetHistory is what you are looking for.
Also take a look at https://stackoverflow.com/a/71067663/16518789


UPDATE Workflow (security, cleanup)

REMOVE raw output in generated PR comment. ADD quality check workflow and separate checks from planning and applying.

Terraform Format and Style 🖌``
Terraform Initialization ⚙skipped
Terraform Plan 📖skipped
Terraform Validation 🤖``
Pusher: @RazvanBerbece, Action: pull_request

Terraform Format and Style 🖌skipped
Terraform Initialization ⚙skipped
Terraform Validation 🤖skipped
Pusher: @RazvanBerbece, Action: pull_request

Terraform Format and Style 🖌success
Terraform Initialization ⚙success
Terraform Validation 🤖success
Pusher: @RazvanBerbece, Action: pull_request

Terraform Format and Style 🖌``
Terraform Initialization ⚙success
Terraform Plan 📖success
Terraform Validation 🤖``
Pusher: @RazvanBerbece, Action: pull_request

Terraform Format and Style 🖌success
Terraform Initialization ⚙success
Terraform Validation 🤖success
Pusher: @RazvanBerbece, Action: pull_request

Terraform Status Update 🤖
This is an automated message generated by the Terraform-Quality-Check workflow run.
It displays the statuses of the formatting, initialisation and validation of the Terraform source files.
See the statuses below :
Terraform Format and Style 🖌success
Terraform Initialization ⚙success
Terraform Validation ✅success
Pusher: @RazvanBerbece, Action: pull_request

Terraform Status Update 🤖
This is an automated message generated by the Terraform-Quality-Check workflow run. It displays the statuses of the formatting, initialisation and validation of the Terraform source files.
See the statuses below :
Terraform Format and Style 🖌 -> success
Terraform Initialization ⚙ -> success
Terraform Validation ✅ -> success
Pusher: @RazvanBerbece, Action: pull_request

Terraform Status Update 🤖
This is an automated message generated by the Terraform-Quality-Check workflow run. It displays the statuses of the formatting, initialisation and validation of the Terraform source files.
See the statuses below :
Terraform Format and Style 🖌 -> success
Terraform Initialization ⚙ -> success
Terraform Validation ✅ -> success
Pusher: @RazvanBerbece, Action: pull_request


[BUG] 7.0.X Monitoring doesn't provide Compute Resource/Pod

Describe the bug
Pod CPU and memory monitoring is not being provided in 7.0 within prometheus.  That prevents monitoring and usage of horizontal pod autoscaler.
To Reproduce
Deploy a cluster with 7.0.X. The below command will not return metrics for pods within those namespaces.  6.X does return metrics for this.
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/"
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/default/pods/"
Also view the Compute Resources /Pod page within the Monitoring screens.
Expected behavior
Expect to get this kind of output:
{“kind”:“PodMetrics”,“apiVersion”:“metrics.k8s.io/v1beta1 13”,

“metadata”:{“name”:“podname”,“namespace”:“default”,“selfLink”:"/apis/metrics.k8s.io/v1beta1/namespaces/default/pods/podname",

“creationTimestamp”:“2019-06-26T03:41:25Z”},“timestamp”:“2019-06-26T03:41:00Z”,“window”:“1m0s”,

“containers”:[{“name”:“cassandra”,“usage”:{“cpu”:“4m”,“memory”:“816388Ki”}}]}

Environment (please complete the following information):

OS [e.g. Redhat 7.4]: ubuntu 18.04
Gravity [e.g. 5.5.4]: 7.0.4
Platform [e.g. Vmware, AWS]: GCP

This was addressed in 7.0.5, to resolve this entirely:

[ ] @r0mant to review https://github.com/gravitational/monitoring-app/pull/162.
[ ] @UnderGreen to merge ^ and update monitoring-app in master.
[ ] @UnderGreen to double-check if this was done in 6.1.

@r0mant  I am seeing metrics in 7.0.11.  This can be closed for 7.

@UnderGreen I'm gonna close this ticket, added ports to 6.1 (to double-check) and master to our meta tracking ticket: https://github.com/gravitational/gravity/issues/1740.


Update netty-tcnative-boringssl-static to 2.0.42.Final

Updates io.netty:netty-tcnative-boringssl-static from 2.0.39.Final to 2.0.42.Final.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.netty", artifactId = "netty-tcnative-boringssl-static" } ]

labels: library-update

Superseded by #420.


Update analyze-cost-management.md

increased by 15? ---> increased by 15%?
Percentage (%) is missing

Thanks for catching and fixing that, @shigeooooooooooo !
#sign-off


Validation: multiple meta-attribute fixes

Fixes ONLY the issues with meta-attributes.
This PR fixes issues in *** files.

Global effort to fix build validation errors
@pahallis
The Content & Learning team is fixing build validation errors on docs.microsoft.com for the rest of H2. This will eliminate potential accessibility, security, and usability issues. This PR includes only build validation fixes and does not change other content. Please review within five business days and merge or comment in the PR with any changes you’d like to see. Thank you!

Docs Build status updates of commit 41e595d:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/preview/virtualmachines.md
:warning:Warning
View (azure-java-preview)
Details

docs-ref-services/preview/resourcemanager-purview-readme.md
:bulb:Suggestion
View (azure-java-preview)
Details

docs-ref-services/preview/resourcemanager-relay-readme.md
:bulb:Suggestion
View (azure-java-preview)
Details

docs-ref-services/preview/resourcemanager-privatedns-readme.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/resourcemanager-redis-readme.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/virtualmachines.md

Line 2, Column 1: [Warning: ms-prod-missing - See documentation] Missing attribute: 'ms.prod'. If you specify 'ms.technology', you must also specify 'ms.prod'.
Line 12, Column 13: [Warning: ms-service-subservice-invalid - See documentation] Invalid value for 'ms.service': 'compute'.
Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

docs-ref-services/preview/resourcemanager-purview-readme.md

Line 38, Column 3: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/java/azure/jdk/' will be broken in isolated environments. Replace with a relative link.

docs-ref-services/preview/resourcemanager-relay-readme.md

Line 24, Column 3: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/java/azure/jdk/' will be broken in isolated environments. Replace with a relative link.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit d758fc4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-services/preview/resourcemanager-purview-readme.md
:bulb:Suggestion
View (azure-java-preview)
Details

docs-ref-services/preview/resourcemanager-relay-readme.md
:bulb:Suggestion
View (azure-java-preview)
Details

docs-ref-services/preview/resourcemanager-privatedns-readme.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/resourcemanager-redis-readme.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/virtualmachines.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/resourcemanager-purview-readme.md

Line 38, Column 3: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/java/azure/jdk/' will be broken in isolated environments. Replace with a relative link.

docs-ref-services/preview/resourcemanager-relay-readme.md

Line 24, Column 3: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/java/azure/jdk/' will be broken in isolated environments. Replace with a relative link.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 507f780:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-services/preview/resourcemanager-purview-readme.md
:bulb:Suggestion
View (azure-java-preview)
Details

docs-ref-services/preview/resourcemanager-relay-readme.md
:bulb:Suggestion
View (azure-java-preview)
Details

docs-ref-services/preview/resourcemanager-privatedns-readme.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/resourcemanager-redis-readme.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/virtualmachines.md
:white_check_mark:Succeeded
View (azure-java-preview)

docs-ref-services/preview/resourcemanager-purview-readme.md

Line 38, Column 3: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/java/azure/jdk/' will be broken in isolated environments. Replace with a relative link.

docs-ref-services/preview/resourcemanager-relay-readme.md

Line 24, Column 3: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/java/azure/jdk/' will be broken in isolated environments. Replace with a relative link.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Solar zenith angle and Earth-Sun distance

Adds the calculation of solar zenith angle and Earth-Sun distance needed as inputs to TUV-x.
closes #163
closes #164
Both calculations required functions that are currently in shared code in CAM here and here that I put in a modified form in the to_be_ccppized/ folder. @nusbaume @peverwhee - if there is a better way to handle these functions, let me know and I can update the PR.
Requires an update to CAM-SIMA that is in review to make certain variables available through CCPP (https://github.com/ESCOMP/CAM-SIMA/pull/325)

Thanks @mattldawson! I have a couple of minor suggestions but nothing that holds up the PR. Just a reminder that the Earth eccentricity, etc. parameter need a SIMA update (ESCOMP/CAM-SIMA#325) to be merged before they're available for use by code in this PR.

Good point. I added a note to the PR description. thanks!


the envoy document has cluster_header,but when config show error?

Title: One line description
Description:

Describe the desired behavior, what scenario it enables and how it
would be used.

config.route.v3.WeightedCluster.ClusterWeight¶
[config.route.v3.WeightedCluster.ClusterWeight proto]

{
  "name": "...",
  "cluster_header": "...",
  "weight": "{...}",
  "metadata_match": "{...}",
  "request_headers_to_add": [],
  "request_headers_to_remove": [],
  "response_headers_to_add": [],
  "response_headers_to_remove": [],
  "typed_per_filter_config": "{...}",
  "host_rewrite_literal": "..."
}
name
(string) Only one of name and cluster_header may be specified. Name of the upstream cluster. The cluster must exist in the cluster manager configuration.

cluster_header
(string) Only one of name and cluster_header may be specified. Envoy will determine the cluster to route to by reading the value of the HTTP header named by cluster_header from the request headers. If the header is not found or the referenced cluster does not exist, Envoy will return a 404 response.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpconnectionmanager
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: GATEWAY
      listener:
        portNumber: 8080
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
              name: envoy.filters.network.http_connection_manager
              typedConfig:
                '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                route_config:
                  name: test
                  virtual_hosts:
                  - name: test
                    domains:
                    - "*"
                    routes:
                    - name: testroute
                      match:
                        path: /productpage
                        case_sensitive: false
                      route:
                        weighted_clusters:
                          clusters:
                          - cluster_header: upstream_cluster
                            weight: 100
                          total_weight: 100
                          runtime_key_prefix: test

[root@node01 httpconnectionmanager]# kubectl apply -f ef-route_config-virtual_hosts-routes-route-weighted_clusters-cluster_header.yaml -n istio-system
Warning: Envoy filter: can't unmarshal Any nested proto type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager: unknown field "cluster_header" in envoy.config.route.v3.WeightedCluster.ClusterWeight

[optional Relevant Links:]

Any extra documentation required to understand the issue.

ok，I see


Fix js initializer merging

Fixes exponential merging behaviour of special js initialisers. Some baselines change because it fixes some previously incorrect merged symbol structure.
I have not tested it with Visual Studio, but it's basically the same as the fix we had working this afternoon, except that it doesn't break any of our existing tests.
Fixes #24015

Porting to 2.8

I added a test case and an assert that immediately catches the problem (1) in compilation (2) in fourslash (3) in interactive VS Code usage, so I think this is ready to go.

Looks good. Can you add another fourslash test for the other repro we got?

@RyanCavanaugh can you send me the other minified repro? Since we didn't change the definition of getJSInitializerSymbol, and the binder code that creates symbols based on getJSInitializer is a single code path, I don't think it will prove anything new, but the cost of adding a second test is low.
Note that without the fix the assert fires for existing tests too: to wit, the ones that had changed baselines.

The two repros I have are
// file1.js
blah.prototype = {
    m: "q"
};

// file2.d.ts
declare class blah { }

and
// file1.js
var N = {};
N.X = function() { };

// file2.d.ts
declare namespace N {
    class X { }
}


Enhancement: when we have app config and application.yaml in application, can we set the priority to application.yaml?

Expected Behavior

We have both application.yaml and app config enabled.
Some developers want to override this property in their local environment and use it. Because overriding in the app config because that will impact the whole team. But when they do it, app config property is taking the precedence. As a workaround each developer is duplicating the property with the new label and using that label in the app config bootstrap file.
is there a way we can achieve this some configuration so that application.yaml will take precedence?

Current Behaviour

If there is duplicate key in application.yaml and app config, the app config is taking the precedence.

Possible Solution

expose some config so that application.yaml will take precedence.

Your Environment

Version used: 1.2.5
Operating System and version (desktop or mobile): Java 11
SDK version: 1.2.5

@Karthickramk I am unsure of a way to do this. The issue comes from spring-cloud-azure-appconfiguraiton-config loading in the Spring Boot process. The best work around I can give at the moment is instead of each developer creating there own label have 1 label for all developers. Then instead of putting a value in the configuration put a placeholder i.e. ${another.configuration}

@Karthickramk  I will look into this more to see if there is anything else that can be done about this.


Xcode - iOS Csound error - Sound not working in iPhone Simulator?

0dBFS level = 32768.0
Csound version 6.05 (float samples) Sep 18 2015
libsndfile-1.0.26pre6
2015-10-25 22:30:02.544 TestPrg1[29291:738144] 1 MIDI sources

2015-10-25 22:30:02.546 TestPrg1[29291:738144] MIDI source 0: Session 1
0dBFS level = 32768.0
Csound version 6.05 (float samples) Sep 18 2015
libsndfile-1.0.26pre6
2015-10-25 22:30:03.614 TestPrg1[29291:738168] 1 MIDI sources
2015-10-25 22:30:03.614 TestPrg1[29291:738168] MIDI source 0: Session 1
2015-10-25 22:30:04.574 TestPrg1[29291:738168] ***Failed to disable audio input.
2015-10-25 22:30:04.575 TestPrg1[29291:738168] ***Failed to enable audio output.
2015-10-25 22:30:04.620 TestPrg1[29291:738170] Csound Error: INIT ERROR in instr 1:
2015-10-25 22:30:04.620 TestPrg1[29291:738170] Csound Error: Invalid ftable no. 2000.000000
2015-10-25 22:30:04.620 TestPrg1[29291:738170] Csound Error:
2015-10-25 22:30:04.621 TestPrg1[29291:738170] Csound Error:  - note deleted.  i1 had 1 init errors
2015-10-25 22:30:04.621 TestPrg1[29291:738170] Csound Error:
Csound tidy up: Terminated
(lldb)

i am also not getting any sound out from the simulator... using swift here

Audio is not able to be used on your system for some reason:
"***Failed to enable audio output."
There is very little information to investigate in this issue, so I am closing it for now.

I've had the same problem after setting up the project looking at the first videos.
The problem is just with the simulator, putting a small delay solves the error.
With

NSThread.sleepForTimeInterval(1)

before

instrument.play()

It works in the simulator too.

@Yanakyl That's good to know...definitely sounds like more of a bug with the simulator than with anything else.

Well, I think its a common enough problem that I'll add a plist entry for it.  Instead of implement a NSThread sleep like this, can you see if changing the runOrchestra method works as well?  Basically change cycles > 100 to cycles > 200 to add another second.  You can experiment to minimize the cycles.

@aure I'm sorry but I don't find any runOrchestra method, it's all new to me.
Anyway in a real scenario playing a note is not the first thing you do when the program is loading up. The sleep was just to check the idea of the simulator not having time to load everything.

In any event, the latest code in the development branch allows a wait time to be set in AudioKit.plist.

Ok I've seen it, I'm using the master branch now. I'll give it a try later on then.


Undefined dependencies for running apisonator.

Hi,
I am attempting to test the apisonator project on Fedora 28.
The Running tests suggests using the script
$ script/test
But I am finding this script is expecting some tools/software in the /opt directory (amongst other locations).
I would have expected the documentation on testing to have listed the following as dependencies

Redis
PostgreSQL
Nutcracker

Do you agree ?

Hi @whitingjr ,
Are you using the development docker image?
If you are using it, those tools should already be installed. The script that you mentioned takes care of starting all the dependencies: https://github.com/3scale/apisonator/blob/fbf22506249ce485b9847aac543b4c9493f89f98/script/test#L46

@davidor ok that's maybe where I am going wrong. I was not using the dev image. I am happy for this issue to be closed.

:+1:


CHEF-1940:Patch for https://github.com/opscode/chef/issues/1940

Attached patch for - https://github.com/opscode/chef/issues/1940

Can you look at signing the CLA in supermarket and address dan's point about the method argument whitespace and the tests?

@rekhajoshm  have you had a chance to look at the CLA? It's pretty easy to sign now: https://supermarket.getchef.com/contributors?page=27. Once we have the CLA, along with some tests, we can merge this.
Thank you for the submission.

@rekhajoshm are you going to get a chance to address the review suggestions and sign the CLA?

@rekhajoshm if you can sign the CLA and address dan's comment we can accept this, but closing this for now.


Print json output for multi-document YAML

Describe the bug
Multi-doc YAML not being printed.
I can see that multi-doc YAML work with YAML output thanks to https://github.com/TomWright/dasel/issues/29
To Reproduce
Steps to reproduce the behavior:

Run simple scripts like below

$ cat <<EOF | dasel -f /dev/stdin -p yaml
---
document: 1
---
document: 2
---
document: 3
EOF
document: 1
---
document: 2
---
document: 3

$ cat <<EOF | dasel -f /dev/stdin -p json
---
document: 1
---
document: 2
---
document: 3
EOF
Error: could not load input: could not unmarshal data: invalid character '-' in numeric literal

$ cat <<EOF > example.yaml
---
document: 1
---
document: 2
---
document: 3
EOF

$ dasel -f example.yaml -p json
Error: could not load input: could not unmarshal data: invalid character '-' in numeric literal

Include (sanitized) input files and commands to help along the way.
---
document: 1
---
document: 2
---
document: 3

Expected behavior
A clear and concise description of what you expected to happen.
similar results like yq
$ cat example.yaml | yq
{
  "document": 1
}
{
  "document": 2
}
{
  "document": 3
}

Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: macOS
Version: 1.17.0

Hey @ryuheechul,
I believe this is a misunderstanding of how to use certain flags with dasel.
See the following that works:
Read from file, output to JSON.
$ dasel -f example.yaml -w json
{
  "document": 1
}
{
  "document": 2
}
{
  "document": 3
}

Read from stdin. Read parser is YAML, write parser is JSON.
$ cat example.yaml | dasel -r yaml -w json
{
  "document": 1
}
{
  "document": 2
}
{
  "document": 3
}

Read from stdin using EOF. Read parser is YAML, writer parser is JSON.
$ cat <<EOF | dasel -r yaml -w json
---
document: 1
---
document: 2
---
document: 3
EOF
{
  "document": 1
}
{
  "document": 2
}
{
  "document": 3
}

Read specifically from stdin using EOF. Read parser is YAML, writer parser is JSON.
$ cat <<EOF | dasel -f stdin -r yaml -w json
---
document: 1
---
document: 2
---
document: 3
EOF
{
  "document": 1
}
{
  "document": 2
}
{
  "document": 3
}

For more information please see the select docs, specifically those regarding the following flags:

-f,--file
-r,--read
-w,--write
-p,--parser

I believe this should solve your problem 👍

Hey @TomWright,
Thank you very much for your answer.
It's my bad of misunderstanding about what -p was.
Somehow I automatically thought it was for "print" by looking at examples in README.md 😅 .
You perfectly educated me on this and thanks for the clarification 👍🏼.


Update copyright year in licence

Updating (c) 2011-2021 to (c) 2011-2022.

View rendered LICENSE.md

Ngon hà...

Verify
On Tue, May 31, 2022, 7:51 PM DANG VAN DONG @.***>
wrote:

@.**** commented on this pull request.
??
—
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/pull/25483#pullrequestreview-991261236, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AW6EM4UIFMHOXU43P4SESMDVM2QYBANCNFSM5W4B5C6Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>