[New game]: 3d Red Light Green Light

🎮 Game Request
This a very fun and amazing game and is totally based on HTML, CSS, JavaScript and Three.js Library. In this game there will be a doll which will try to catch our activity whenever we move. The catching action of the doll is totally random and we have to avoid the glare of the doll to win the game. It's based on the popular series Squid Game. I will really have so much fun making this game and will try to add my own design elements into the game.
Point down the features
This game will contain a 3d Doll which is designed to catch the user moving. A background will be set and our object will try to cross a certain distance without the doll noticing anything. If the doll notices anything then the game will be over and if she doesn't then we will win this game.
I am really excited to build this game and I request you to assign this issue to me under the tag of GSSoC'23.
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @uzmaansari23 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

please assign me this issue

Hey @uzmaansari23 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Update date-range-rag-days-left.json to replace 100-level deep if statement

Q
A

Bug fix?
yes

New sample?
no

Related issues?
fixes #384

Fixes the display of the current field to the displayValue
Replaces the 100+ level if statement that was unnecessary and would easily cause JSON overflows in SharePoint list rendering.
Added forward and backward date handling and friendlier display messages (Today / Yesterday / Tomorrow etc.)

Thanks @zylantha! This is a great improvement!
When the sample was first added there was no friendly display, floor, or ceiling operators making the results decimals with multiple levels of precision without the crazy nesting.


Fix typo

I think the read me should have a pun on "you're going to love", instead it says "lava" which I don't think means anything other than molten rocks in any other language!

I'm not taking any responsibility for it but that's a pun made on purpose, please look at the repo description cc @gsimone

Leva/lava/love 🐸


Make error - "redefinition of ‘bios_version_34’"

Highly appreciate your work!
On the latest version, when running make I get the following error:
/yoga-bios-unlock$ make
cc -o ./yoga-bios-unlock ./src/yoga-bios-unlock.c -O2 -Wall -Wextra -Wfloat-equal -Wshadow -Wstrict-prototypes -Wstrict-overflow=5 -Wcast-qual -Wconversion -Wunreachable-code
./src/yoga-bios-unlock.c: In function ‘is_yoga’:
./src/yoga-bios-unlock.c:66:17: error: redefinition of ‘bios_version_34’
   66 |   dmi_strings_t bios_version_34 = { .string = __BIOS_VERSION_34, .next = &bios_version_36 };
      |                 ^~~~~~~~~~~~~~~
./src/yoga-bios-unlock.c:65:17: note: previous definition of ‘bios_version_34’ was here
   65 |   dmi_strings_t bios_version_34 = { .string = __BIOS_VERSION_36, .next = &bios_version_38 };
      |                 ^~~~~~~~~~~~~~~
./src/yoga-bios-unlock.c:66:75: error: ‘bios_version_36’ undeclared (first use in this function); did you mean ‘bios_version_34’?
   66 |   dmi_strings_t bios_version_34 = { .string = __BIOS_VERSION_34, .next = &bios_version_36 };
      |                                                                           ^~~~~~~~~~~~~~~
      |                                                                           bios_version_34
./src/yoga-bios-unlock.c:66:75: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:4: yoga-bios-unlock] Error 1

It is a copy paste error.

damn. sarvasana is right I messed up the code copying that line. I'm sorry for that


about the wallet create command parameters...

hi everyone,
can I pass the name, passphare values of "wallet create" command as directly like that
./bin/neo-go wallet create -p ./wallet-data/my-wallet.path **--name BLABLA --passphrase BLABLAPASS**
because I would like create the address from remotely access.After send create wallet the node is waiting for answers like this:
Enter the name of the account >...
Enter passphrase >...
Confirm passphrase >...

I would like to send these parameters  as directly...
do you have any solution suggestions??
thank you

Not currently possible directly, but you can always use some expect.


MRG: Add support for data from NIRx Aurora 2021.9 software

Reference issue
https://github.com/mne-tools/mne-testing-data/pull/89
What does this implement/fix?
The NIRx vendor has released their new acquisition software Aurora 2021.9. This software exports in two formats 1) their native format and 2) the community developed common SNIRF format.
A user already reported that SNIRF files from this software did not load with MNE (https://github.com/mne-tools/mne-nirs/issues/393) and I fixed the issue in https://github.com/mne-tools/mne-python/pull/9777. But we did not have any test data to confirm the issue was sufficiently resolved.
Since then, the vendor has kindly acquired some test data for us and emailed it to me (I don't have their newer devices that use the new software, my device is old and stuck with old software). They also sent the same data with the native file format.
The native file format has also changed.

The string used to encode dates has changed.
And now the age field is optional.

Additional information
Bit of a moving target 😢 these file formats.

One test failed due to 60 min timeout. I just added @larsoner as a co-author
I think this is good to merge. @larsoner and @agramfort can you please review and merge if happy.


Repository refactor

I liked Repository pattern and Domain Entity approach rather than Contexts and passing byte arrays.

already changed that ... it's align with the diagram that I post on Discord


Announce order

The ordering of announce seems a bit different to me in the case of connect from manage and connected handler. @acud Could you pls take a look and verify if this is more correct?
It seems to me that in manage it is first announced and then clean-ed up from maps, and in connected is vice versa + there is a manageC triggered in between, but I might be wrong 🙈

Let's make the base to pull-0-update so that we test with it on the cluster.

can we please have a problem statement?

@acud I saw that there is a race condition that is happening somewhere around announce, so I investigated and saw there is a different ordering. I am not sure this is the cause of the problem, just wanted to check with you if this makes sense. This is why I thought that connected handler should have a uniform code with connect call from managec, as it is basically, the same.  From what I sere here, it is similar, but the ordering is different.

@janos I have changed the base, sorry did not see before.


Use php-pm in dev environment for performance improvements

Guys, let me know your thoughts. I think it would be awesome not to rely on vhost configuration or anything like that in dev environment, and also benefit from the speed improvements.
https://github.com/php-pm/php-pm
@henriquemoody @aferrandini @mathewpeterson @ivoba @sergeyklay

Looks good to me


How do I un-publish a TLE?

Not really a bug, but don't think documentation tag either.
Once a TLE is published can I remove it?
I did a test TLE that is useless but can't find a way to remove it.
I understand that could be an issue if people have installed and may be why it does not exist.
Just want to confirm I'm not missing something.

Currently we don't have a method to remove a TLE. We might add a command to dbdev CLI similar to cargo yank in future.


Laravel mix production working on local server but not remote

Hello,
I am having a weird issue, when I try to version my app.js and custom.css it works locally(even when compiled in production), but as soon as I upload all the files from the public folder to my public_html in the remote, the versioning of the files do not working.
npm run production
   "laravel/framework": "6.2",
    "laravel-mix": "^5.0.5",

Here is what I tried:
webpack:
mix.js('resources/js/app.js', 'public/js')
   .sass('resources/sass/app.scss', 'public/css')
   .styles(['resources/css/custom.css'], 'public/css/custom.css');

if (mix.inProduction()) {
    mix.version();
}

Also tried this:
mix.js('resources/js/app.js', 'public/js')
   .sass('resources/sass/app.scss', 'public/css')
   .styles(['resources/css/custom.css'], 'public/css/custom.css');

mix.version();

In my blade files:
I tried:
<script src="{{ asset(mix('css/custom.css')) }}"></script>
<script src="{{ asset(mix('js/app.js')) }}"></script>

and
<script src="{{ mix('css/custom.css') }}"></script>
<script src="{{ mix('js/app.js') }}"></script>

As I said it is working on my local but not on the production server.
I compile everything locally and upload all to the remote.
Is there a file on the local that is needed on the remote for this to work correctly please?
Thank you.

Make sure your mix-manifest.json file is being uploaded to your server.
Without know the exact error you’re seeing, it’s difficult for me to order any other hints.

Yes it has been uploaded. And no errors are output.
I have opened a thread here but no luck either:
https://laracasts.com/discuss/channels/laravel/bug-in-laravel-6-laravel-mix-version-working-locally-but-not-in-remote

I just ran into a problem like this too, after doing some npm library upgrades. The build was running fine locally, but when deploying on a 1GB DigitalOcean instance, it failed without a clear error.
Turned out it was running out of memory. I confirmed this by monitoring htop while the build process was running.
I solved it by simply freeing up some memory. In this case I disabled an unneeded service (snapd) and restarted a long-lived service that had been eating up some RAM over time (php7.4-fpm). To prevent this from happening in the future, I am considering to move the build process over to GitHub Actions.


Wont open on Iphone SE (first gen)

Im on IOS ver 14.7.1 and have jailbreaked. When I install it with troll store, it crashes whenever I open it. If this is normal, I have still not got it to work with spice tools. Help would be much appreciated.

Hello!
Sadly, iPhone SE 1st gen is not supported. iPhone 8 or newer is required.
But... it should at least not crash though.
Can you send me the crash log in Settings -> Privacy -> Analytics -> Analytics Data -> Real-Card related logs?

Real Card-2023-08-14-222116.txt
Thats a bummer that the 1st gen doesn't work. I saw that it had NFC but I looked deeper and its not able to be used by developers and only used by apple pay.

Real Card-2023-08-14-222116.txt
Heres the log
Thats a bummer that the 1st gen doesn't work. I saw that it had NFC but I looked deeper and its not able to be used by developers and only used by apple pay.

Thanks for the log!
Seems like iOS 14 doesn't have Swift concurrency(async/await) support. I should've mention this on README.md.


Docker support

I placed broadlinkgo in a docker container along with some other code wrapped around it. Altough broadlinkgo is cross-platform already and Docker won't add any value for that matter. It is great to manage Broadlinkgo in an existing infrastructure along other Docker containers (also mostly API's), with tools such as Portainer.
I could share some thoughts on it if you'd like. It would be fairly simple to arrange this. It basically only requires one configuration file and some documentation in the case of this project.

Done: https://github.com/brianpierson2020/broadlinkgo-docker

Great, thanks! :)


Codegen manifest

This PR adds a new manifest type: polywrap.codegen.yaml. The purpose of the codegen manfiest is to give developers a nice UX for managing binding generation.
It will be especially useful for target-specific codegen instructions, such as disabling the serde package in Rust Wasm wrapper bindings.
The codegen manifest schema currently looks like this:
format: 0.1.0
codegenDir: ./src/wrap # codegen output will go here
skipOnBuild: false # if true, codegen will not be run when building Wasm wrapper
publishDir: ./build # when codegen is run for a plugin, wrap.info will be output here
config: # target-specific config, determined by ext schema

I also updated the build manifest with a bindings option that allows users to specify a directory other than ./src/wrap for the location of their generated bindings.
Closes https://github.com/polywrap/toolchain/issues/1278, https://github.com/polywrap/toolchain/issues/1279
Related: https://github.com/polywrap/toolchain/issues/1178

Overall, apart from two minor comments I left, this looks awesome!
One nitpick that came to mind is that there was some duplicated code in PluginProject, AppProject and PolywrapProject. Namely, all the codegenManifest related functions seem like they could be extracted into the parent Project abstract class.
This might also apply to other extension manifests, so it could very easily be a separate issue/PR.

Yeah, definitely. I moved the codegen manifest methods and config props to the Project abstract class. I looked at the other extensions, but I left their methods in the PolywrapProject. All the extensions are in all of the project manifests, but I think right now we only use the other ones for Wasm wrappers (build, deploy, meta). Do you think that makes sense, or does it make more sense to move the methods to Project?

I believe we're more than good with just this as part of this PR. I agree with your sentiment!

It turns out Serde is already successfully removed by wasm-snip, and this was the original motivation for this feature. Is there any interest in this for its own sake, or should we scrap it for now and revisit it in the future if there is a need?

It turns out Serde is already successfully removed by wasm-snip, and this was the original motivation for this feature. Closing for now. We can revisit the idea in the future if there is a reason to.


Test compilation failure

Preprocessing test suite 'test' for ip-0.9.2..
Building test suite 'test' for ip-0.9.2..
[...]
test/Test.hs:47:9: error:
    Ambiguous occurrence ‘testCase’
    It could refer to either ‘Test.Framework.Providers.HUnit.testCase’,
                             imported from ‘Test.Framework.Providers.HUnit’ at test/Test.hs:8:46-53
                          or ‘Test.QuickCheck.Property.testCase’,
                             imported from ‘Test.QuickCheck.Property’ at test/Test.hs:11:63-72
   |
47 |       , testCase "Decode an IP" testIPv4Decode
   |         ^^^^^^^^

This was fixed in f480474db568b72b01c76391aa4a95be6d724a5d. I'll release it to hackage.

Released in 0.9.3.


HBDM Swap API docs still reflect Futures Contracts related values in the example JSON fields to the right

https://huobiapi.github.io/docs/coin_margined_swap/v1/en/#query-trigger-order-open-orders
specifies contract_type | string | true | Contract Type but the example to the right has no such field.

https://huobiapi.github.io/docs/coin_margined_swap/v1/en/#place-trigger-order : same

https://huobiapi.github.io/docs/coin_margined_swap/v1/en/#subscribe-order-data-sub : the example to the right shows a snippet JSON with contract_code and contract_type set to BTC200626 and quarter, respectively

The issue has been moved to the Python issue zone.


Flare filter

Codecov Report

Merging #70 into master will decrease coverage by 4.31%.
The diff coverage is 5.08%.

@@            Coverage Diff             @@
##           master      #70      +/-   ##
==========================================
- Coverage    70.6%   66.29%   -4.32%
==========================================
  Files          18       18
  Lines         837      896      +59
==========================================
+ Hits          591      594       +3
- Misses        246      302      +56

Impacted Files
Coverage Δ

src/problemgenerator/filters.py
74.92% <5.08%> (-14.12%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8150e3b...ed29e88. Read the comment docs.


fix(community rules): Close modal after upload

Closes the modal after a rule upload. This way we force to user to refetch all rules when reopening the modal.

:tada: This PR is included in version 1.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Request update to 8u92

http://www.oracle.com/technetwork/java/javase/8u92-relnotes-2949471.html

@FireballDWF Thank you for pinging me back. Unfortunately, I will be able to push the update only on Friday.

Done!


Resource not closed

Hey, I was skimming through the sources and noticed that https://github.com/sajari/storage/blob/master/hash.go#L79 will return early without calling Close if copy fails. Just wanted to let you know.
p.s. thanks for the interesting talk yesterday at Golang Syd!

Good spot - thanks for the report!
I have a lot of updates coming which will bring this package more in line with what I was talking about, so be sure to check back for that!


Playback-time continues even when stopped/paused

When I connect to my device within Spotify on Window, the playback-time starts/continues even when in pause-state.
It happens always, when I connect while in pause state, or when pausing in between.
Once the track is continued, the playback-time is updated with the real playback-time, but once I pause the playback, the timer continues within Spotify.
Is this a common issue or just happening to me?

This does not happen with the Spotify-app on Android, so maybe it's a bug in the Spotify-application for Windows. But there this bug does not happen if I select another SpotifyConnect-enabled device.
Can anyone reproduce/check if the timer is always counting with the current dev-branch?

I tested with the linux desktop client and there is no issue. Playback-time is pausing on the desktop once I pause on the mobile device.

Just tested with librespot-java on 77a558475d860bd5c672bc58dac7baeb17e219c6 and the Windows desktop client on <IP_ADDRESS>0.g2ae50076 and I cannot reproduce it either. What are your versions?

My Windows client is on <IP_ADDRESS>0.g2ae50076-a and I am using the latest xyz.gianlu.librespot:librespot-player:1.5.6-SNAPSHOT:thin.
I will try to find the reason for this or otherwise interpret it as a temporary Spotify-bug ;-)

Now I see it. Do you have the new UI?

It looks this way:

This is an issue for me when using spotify-qt with librespot-java. There's also a web remote here that reacts the same way with librespot-java. The Rust version of librespot did not have this issue from what I can tell, but it has another issue that was non-negotiable for me here (still not fixed) which is why I moved to the more supported Java version, even with the higher RAM requirement. Just throwing my hat in this ring.


Task-69-For-Testing

@hnbmunoz I see a lot of redundancies surrounding your implementation. We can discuss this in-depth through call.

Hint: Code reuse component between DialogBox, child dialogbox and parent dialogbox

Rejecting this PR since we found better solutions. Do this implementation from scratch.


Payment Gateway Integration for a cause

Description
This is a web app totally based on front end and it's for a NGO donation related to environment.

[* ] New feature (non-breaking change which adds functionality)
[ *] Documentation Update

Checklist:

[* ] My code follows the style guidelines(Clean Code) of this project
[* ] I have performed a self-review of my own code
[* ] I have commented my code, particularly in hard-to-understand areas
[* ] I have created a helpful and easy to understand README.md
[* ] I have made corresponding changes to the documentation
[* ] My changes generate no new warnings
[ *] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

PR Close due to no activity


chore: Fix inconsistent color scheme term usage in the README

Hey @tjdevries !
Cool project! Just about to create my own with colors I've had in mind for a while 🎉
The term colorscheme in the README caught my attention, because I thought myself that it was a real word for so long 😅. It turns out that it is not.
Have a good one!

Sorry, but I like typing colorscheme :laughing: I don't know if it's just because it's the command in vim or some other reason.
Thanks for the PR though! have a good one :smile:


change profit color output to green and red

Actually the number is always green.
I change the color to red when the filesize is increased.

Hey! Thanks for reporting this and submitting a fix. I rebased it for you, since there were conflicts.
This will be released in SVGO v3.0.5.


fix: set cache control on lambda response

Cache Control headers are currently set at the internal res level, the lambda itself needs to pass the headers back to CF/Browser.

Caching happens on Cloudfront. There is no need for S3, Lambda or ApiGw to return Cache-Control information back as we are using cache policy for this route.
See
		const assetsCachePolicy = new CachePolicy(this, 'NextPublicCachePolicy', {
			queryStringBehavior: CacheQueryStringBehavior.all(),
			enableAcceptEncodingGzip: true,
			defaultTtl: Duration.hours(12),
		})

Make sense, but what happens if you set a different cache control data on individual items in the bucket? Will it respect those cache-controls, or will it just use the assetsCachePolicy?
The image optimization reads the cache control from the bucket:
if (response.CacheControl) {
   res.setHeader('Cache-Control', response.CacheControl)
}

Bucket's cache-control is ignored. I cannot really see use of setting cache-control for individual items, could you provide some business scenario when this might be needed? I'm striving for simple out-of-the-box solution, not to cover all edge cases.


How to Publish to Mac App Store?

I’m looking at the documentation between this package and Electron, and am having trouble lining the two up. Are there any guides or pointers on how to get it working?

Basically meteor-desktop is tightly integrated with electron-builder so you need to check:
https://www.electron.build/configuration/configuration
https://medium.com/@jondot/shipping-electron-apps-to-mac-app-store-with-electron-builder-e960d46148ec
You have electron-builder settings in builderOptions field in your .desktop/settings.json.
I was not publishing anything yet to app store so I can not help with any experience.
Also https://github.com/wojtkowiak/meteor-desktop/issues/127

Let me know if you encounter anything that seems to be problematic/impossible on meteor-desktop side preventing you from doing it. Will make changes if necessary.

@wojtkowiak could I hire you for an hour to help me figure this out 😁 I can make a tutorial after as well

Reach me on<EMAIL_ADDRESS>Let me know what you need assistance with as like I said I have zero experience with app store so I do not want to waste your time ;)


chore: migrate to new prow reviewing

Description
Add prow OWNERS file

Type of changes

[ ] Bug fix (change which fixes an issue)
[ ] New feature (change which adds functionality)
[ ] Refactoring (no functional changes, no api changes)
[ ] Code style update (formatting, local variables)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[x] Other... Please describe: review configuration

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Backgroup: https://internals.tidb.io/t/topic/854
Ref: https://github.com/ti-community-infra/configs/issues/824

/hold It should be merge after bot's config updated, but we can review and approve it at current stage.

/merge

/unhold

/lgtm

/approve


[Storage] Add ADLSgen2 APIs into blob SDK

@jiacfan is added to the review. #Closed

/azp run js - storage-blob - tests


Restructure postgres Client connections

getClientConfig() is called in many places throughout the postgres code. Needs restructuring to remove any possible gaps in the functionality.
Original discussion: https://github.com/microsoft/vscode-cosmosdb/pull/1663#discussion_r477471014

This issue has become stale and is at risk of being closed. The community has 60 days to upvote the issue. If it receives 5 upvotes we will keep it open and take another look. If not, we will close it. To learn more about how we handle issues, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this issue has received less than 5 community upvotes and we closed it. Still a big Thank You to you for taking the time to create it! To learn more about how we handle issues, please see our documentation.
Happy Coding!


How to set route parent?

I can't see any way of defining what the routes parent should be.
Again to use an example from vue-2-crumbs it allows:
meta: {
    breadcrumb: { parent: 'dashboard' }
}

Unfortunately that plugin doesn't appear to work with SSR was hoping this one would!

@dahousecat Hi, great option, I will implement this soon

@dahousecat Hi

Unfortunately that plugin doesn't appear to work with SSR was hoping this one would!

I just checked it out and it worked out for me demo, could you tell me what problems you encountered ?

how to set parent with query params?


Origins saving issue

Minecraft version: 1.18.2
Forge version: 40.0.49
Origins version: <IP_ADDRESS>
Origins do not save after they have been chosen. Closing the world allows me to reselect my origin. Choosing a different origin than last time combines the two, picking the ability of one and the cooldown of the other, before crashing.

Thanks :)


Cannot read property 'create' of undefined

Hi, it fire this error if used in Ionic: Cannot read property 'create' of undefined.
<ion-item ng-repeat="venue in venues" viewport-watch>
   ...
</ion-item>

You need to load scrollMonitor,js first


chore: Adding environmentName parameter in datasource test flow and required decomposition and refactors.

Description

TL; DR , small Pr to add environmentName to controller to test different environments. and a refactor to make code reusable.
With Introduction of multiple environments we would have configurations corresponding to each environment. In order to test these configurations, we would require an environment parameter to be passed as an argument,  this could be done by passing an environment header with the current datasource test flow, however, since our community and enterprise flow uses the same code. We require our community code to include the header which however, will not be used in the community edition but it will have complete usage in enterprise edition.

Type of change

Chore (housekeeping or task changes that don't impact user perception)

How Has This Been Tested?

Manual
Jest
Cypress

Existing test cases are adequate, just tweaked a few test cases to accommodate changes.
Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

@sondermanish - Checked the Test button for AmazonS3, MySQL, PostGreSQL, Dynamo DB, Firestore, Mongo. Test goes through fine. Able to Save the datasources and also create a simple query against each datasource without any issues.

/ok-to-test sha=10fc2b3

/ok-to-test sha=57b11b46ce5356a90de9ec53b822a70d6211ee89

/ok-to-test sha=57b11b46ce5356a90de9ec53b822a70d6211ee89

/ok-to-test sha=57b11b46ce5356a90de9ec53b822a70d6211ee89

/ok-to-test sha=57b11b4

/ok-to-test sha=57b11b4


Fixed typo

@Rodrigossz
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

@Rodrigossz
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-team

Done


Displaying the number of viewers

Bug Report
Problematic behavior/code
One viewers connected
Expected Behavior
Improve pluralization: One viewer connected vs Two viewers connected
Note that when recording is activated, the number of viewers and the date are split on two lines.
It would be nicer to display the number of viewers on a single line and the date also on a single line below it.

Steps to Reproduce

Start a live being alone in the live

Environment

Marsha version: 4.0.0-beta.11
Platform: Docker

Actually, after discussing with @lunika I now realize that we show "1 viewers connected" for a live where I was alone as a teacher. In this case we should show 0 viewers connected.


implement marshaling JWK

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

71 of 251 (28.29%)  changed or added relevant lines in 10 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-2.8%) to 38.685%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/jsonutils/decode.go
0
1
0.0%

jwk/okp.go
0
1
0.0%

jwk/symmetric.go
0
4
0.0%

jws/jws.go
0
4
0.0%

jwk/ecdsa.go
8
19
42.11%

jwk/ed25519.go
4
15
26.67%

jwk/rsa.go
23
46
50.0%

internal/jsonutils/encode.go
0
41
0.0%

jwk/jwk.go
34
118
28.81%

Files with Coverage Reduction
New Missed Lines
%

jwk/ecdsa.go
1
60.47%

Totals

Change from base Build<PHONE_NUMBER>:
-2.8%

Covered Lines:
347

Relevant Lines:
897

💛  - Coveralls


feat: don't inject generated files into hook command

this fixes 1 spot that afterAllFilesWritten was missed

i will revert it back to allFilesWrite then even though it is grammatically incorrect.  ITs an easier fix in the short term

Just revert the documentation in https://github.com/anymaniax/orval/pull/1181, I'll accept the PR quickly.

Yep PR submitted


I can't run it after install successfully

Hi, When I installed whisper in the virtual environment, I found that he could not run.
Python version
(graphite) [root@centos whisper]# python --version
Python 2.7.5

Virtual environment
/opt/graphite

VM
CentOS Linux release 7.2.1511 (Core)

Whisper setup
(graphite) [root@centos whisper]# python setup.py install
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'long_description_content_type'
  warnings.warn(msg)
running install
running bdist_egg
running egg_info
writing requirements to whisper.egg-info/requires.txt
writing whisper.egg-info/PKG-INFO
writing top-level names to whisper.egg-info/top_level.txt
writing dependency_links to whisper.egg-info/dependency_links.txt
reading manifest file 'whisper.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files found matching '.*'
warning: no previously-included files matching '__pycache__' found anywhere in distribution
warning: no previously-included files matching '*.py[co]' found anywhere in distribution
writing manifest file 'whisper.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build/bdist.linux-x86_64/egg
copying build/lib/whisper.py -> build/bdist.linux-x86_64/egg
byte-compiling build/bdist.linux-x86_64/egg/whisper.py to whisper.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
installing scripts to build/bdist.linux-x86_64/egg/EGG-INFO/scripts
running install_scripts
running build_scripts
creating build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/rrd2whisper.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-update.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-dump.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-merge.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/find-corrupt-whisper-files.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/update-storage-times.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-info.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-auto-update.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-resize.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-set-aggregation-method.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-set-xfilesfactor.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-create.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-fetch.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-diff.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-auto-resize.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
copying build/scripts-2.7/whisper-fill.py -> build/bdist.linux-x86_64/egg/EGG-INFO/scripts
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/rrd2whisper.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-update.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-dump.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-merge.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/find-corrupt-whisper-files.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/update-storage-times.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-info.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-auto-update.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-resize.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-set-aggregation-method.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-set-xfilesfactor.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-create.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-fetch.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-diff.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-auto-resize.py to 755
changing mode of build/bdist.linux-x86_64/egg/EGG-INFO/scripts/whisper-fill.py to 755
copying whisper.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying whisper.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying whisper.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying whisper.egg-info/not-zip-safe -> build/bdist.linux-x86_64/egg/EGG-INFO
copying whisper.egg-info/requires.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying whisper.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
creating 'dist/whisper-1.2.0-py2.7.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing whisper-1.2.0-py2.7.egg
removing '/opt/graphite/lib/python2.7/site-packages/whisper-1.2.0-py2.7.egg' (and everything under it)
creating /opt/graphite/lib/python2.7/site-packages/whisper-1.2.0-py2.7.egg
Extracting whisper-1.2.0-py2.7.egg to /opt/graphite/lib/python2.7/site-packages
whisper 1.2.0 is already the active version in easy-install.pth
Installing rrd2whisper.py script to /opt/graphite/bin
Installing whisper-update.py script to /opt/graphite/bin
Installing whisper-dump.py script to /opt/graphite/bin
Installing whisper-merge.py script to /opt/graphite/bin
Installing find-corrupt-whisper-files.py script to /opt/graphite/bin
Installing update-storage-times.py script to /opt/graphite/bin
Installing whisper-info.py script to /opt/graphite/bin
Installing whisper-auto-update.py script to /opt/graphite/bin
Installing whisper-resize.py script to /opt/graphite/bin
Installing whisper-set-aggregation-method.py script to /opt/graphite/bin
Installing whisper-set-xfilesfactor.py script to /opt/graphite/bin
Installing whisper-create.py script to /opt/graphite/bin
Installing whisper-fetch.py script to /opt/graphite/bin
Installing whisper-diff.py script to /opt/graphite/bin
Installing whisper-auto-resize.py script to /opt/graphite/bin
Installing whisper-fill.py script to /opt/graphite/bin

Installed /opt/graphite/lib/python2.7/site-packages/whisper-1.2.0-py2.7.egg
Processing dependencies for whisper==1.2.0
Searching for six==1.12.0
Best match: six 1.12.0
Adding six 1.12.0 to easy-install.pth file

Using /opt/graphite/lib/python2.7/site-packages
Finished processing dependencies for whisper==1.2.0

Run
(graphite) [root@centos whisper]# python /opt/graphite/bin/whisper-fetch.py
Traceback (most recent call last):
  File "/opt/graphite/bin/whisper-fetch.py", line 4, in <module>
    __import__('pkg_resources').run_script('whisper==1.2.0', 'whisper-fetch.py')
  File "/opt/graphite/lib/python2.7/site-packages/pkg_resources/__init__.py", line 745, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/opt/graphite/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1493, in run_script
    raise ResolutionError("No script named %r" % script_name)
pkg_resources.ResolutionError: No script named 'whisper-fetch.py'

strange, is this the last version from git?

@piotr1212  Yes, reinstalling the virtual environment and whisper is restored.


docs(*): document the breaking change introduced in e1da4be

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Docs update.
What is the current behavior? (You can also link to an open issue here)
Although e1da4be introduced a breaking change, it wasn't documented as such.
What is the new behavior (if this is a feature change)?
The breaking change is documented.
Does this PR introduce a breaking change?
No.
(In a way. "Let me introduce you this breaking change. It has been around for 2 releases, but I don't think you've met.)"
Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

Good work @gkalpak as usual you put me to shame by being much more fastidious than me :-)

Nah! We're rather taking turns at that :smiley:
(Although you do use fancier words 😛)


[WIP] RYA-144 Entity index.

hey @kchilton2 can you close this since it overlaps with RYA-144 (PR #135)

hey @kchilton2 can you close this pr?


Not working file m3u8 in chromecast

I use file: https://kor.hanvid.com/file/045156a11886e576169f8721d9a61644/playlist.m3u8 to add chromecast but it doesn't work with this file

It should be solved when #118 is released.

This is supposed to be fixed with the merging of 118 but I could not make it work.
I have a test page here:
https://couchtofitness.com/session/407 which does not work as expected. The Chromecast player attempts to load the source for a few seconds then gives up and displays the Chromecast icon. The browser is still connected to Chromecast.
We are loading the plugin from //cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>The vide file link is: https://player.vimeo.com/external/887203408.m3u8?s=e209ffa7f9b282b57843370fc91a55f8b56b14ae

It seems that you haven't configured the modifyLoadRequestFn. It should be configured like this:
options = {
   techOrder: [ 'chromecast', 'html5' ], // Required
   chromecast: {
      modifyLoadRequestFn: function (loadRequest) { // HLS support
         loadRequest.media.hlsSegmentFormat = 'fmp4';
         loadRequest.media.hlsVideoSegmentFormat = 'fmp4';
         return loadRequest;
      }
   },
   plugins: {
      chromecast: {
      },
   }
};

Thanks, I confirm that I can cast now using the Chrome desktop cast icon from the browser's top bar.
The cast icon in player has now disappeared.
Is there something I needed to add for that one to show again?

Did it solve your issue?

I had a version which was casting but the cast button was not showing up in the player. Now I fixed that but it's not casting. I have the same test link https://couchtofitness.com/session/407
I see a blank screen on Chromecast. I'd like to know how to debug this.

Had same issue but probably because of a different problem, hls is packaged not only in .fmp4 but also in .ts and in our case we use ts only, it's probably worth mentioning in the docs this fact, or even think of a more flexible solution that would allow player to support both

More information from my testing:
The link above that was not working is now working: https://couchtofitness.com/session/407
I added a new test link which does not work: https://couchtofitness.com/session/408
They are using the same code, I replaced fmp4 with ts in modifyLoadRequestFn
I struggle to debug the differences between these two feeds. I work with the assumptions that the codec used by Vimeo is the same for both links. The one I can't cast works fine with the Vimeo player so it's definitely possible to fix.

I managed to get a working version by downloading the 4k version of the video file from Vimeo and re-uploading it. The only thing that I saw different was that the non-working hls url did not have the SUBTITLES entry. After re-uploading the auto-generated captions option was enabled on the Vimeo video settings page and it seems to cast fine.
This bit was in the working feed:
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English (auto-generated)",LANGUAGE="en-x-autogen",URI="https://165vod-adaptive.akamaized.net/exp=1702418400~acl=%2Fe39db795-dd34-4da0-8102-171719e15f24%2F%2A~hmac=90bf07f1c1fab7b4a84b7915063557bf516663b715d72b2eddedfba4b5190282/e39db795-dd34-4da0-8102-171719e15f24/subtitles/119986868/playlist.m3u8?d=41.474767&f=dash&subtoken=5c0019d5d8f74f8e59fd72e3ec0681ecb219d69567543bcb880eb9974ba5ef23",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog",AUTOSELECT=YES,DEFAULT=NO

@nickopris Sorry for late answer. Can you try the demo at https://github.com/silvermine/videojs-chromecast/pull/166
Do you remember to run player.chromecast() after videojs initilazation?
   videojs('video_1', videojsOptions, function() {
      this.chromecast();
      loadVideo(videos[videoSelector.value]);
   });


draft: allow users to augment their jinja context with python objects

This is a bit of a proposal and proof of concept at the same time.
It gives a handle to people over their jinja context, allowing them
to inject python objects in there under a extra_jinja_context
namespace.
how?
export PYTHONPATH=~/.dbt

Assuming a file ~/.dbt/dbt_config.py
# anything added into `extra_jinja_context` becomes available
# in the jinja context under a namespace of the same name
extra_jinja_context = {
    'hello': 'world',
    'test': lambda x: x,
}

assuming a model test.sql
SELECT '{{ extra_jinja_context.hello }}' AS test
UNION ALL
SELECT '{{ extra_jinja_context.test('print me') }}' AS test

why?
Writing Jinja is ok when you're writing a lot of SQL with a bit of logic
in it, but highly suboptimal when writing complex logic with a bit of
string outputs. Clearly python is superior to Jinja in many ways:

access to the full python standard lib
access to external/powerful libs
Turing complete, object oriented
testable using sane mechanisms

use cases
Use cases are limitless. Bind, hook, trigger, generate SQL.
In order of legitimacy:

string processing, what you'd typically use Jinja macros for, but
maybe you prefer python functions over jinja macros. Our main use
case is creating a generate_incremental_load_date_bounds() where
we'll look at vars to offer different loading modes (catchup, date
range, date list, offsets, ...)
custom logging similar to
this but much more
flexible, we happen to use BigQuery and this particular approach
doesn't work for BigQuery
custom logic for hooks
trigger external things (webhooks!)
...

need more thinking / conversation

I'm introducing dbt_config.py, a new place where python logic can be
injected into dbt-core, it can be powerful, but can lead to
environment issues / complexity. People need to not abuse this file.
No import pandas as pd in there please! Where should this live?
~/.dbt/?
Seems like it'd be great to do this at the project level too, so a
project can be packaged with the extra jinja context it needs to
operate. macros/my_macros.py anyone!? Conceptually that makes a dbt
project also a python app in some ways and that may not be ideal.
interoperability: people sharing projects may need to also share
dbt_config.py and put it in their pythonpath. It's not that outrageous
but raises the complexity of the project / env setup. This kind of
complexity already exist with stuff like profiles.yml

TODO

agree this is useful
agree on an approach
write tests
write docs
hand off?

@mistercrunch Thanks for the PR, and for the thoughtful accompanying writeup!
I like this idea better than giving people the ability to write custom Jinja filters, or hooking into other Jinja-specific "extensions." There's a very old issue proposing just that: https://github.com/dbt-labs/dbt-core/issues/480. I find myself agreeing with the two most-recent comments there: This feels like a case for plugins!
I'll leave some more detailed thoughts below. I'm indebted to @jwills @gshank @nathaniel-may for talking through this with me yesterday. Maybe this PR actually wants to be a discussion?
Why not?

it can be powerful, but can lead to environment issues / complexity. People need to not abuse this file. No import pandas as pd in there please!

This is the name of the game. The limitation of Jinja is one of the best things about it :)
At definite risk of mixing my mythological metaphors, custom Python code within the dbt project environment opens a Pandora's box of anti-pattern practices, and books us a one-way passage over the river ~Styx~ Pipx to dependency hell. That risk is present to some degree in dbt Python models, too, but those dependencies will be installed on the warehouse, in per-model or per-cluster sandboxes. They will not be installed "globally" in the dbt environment, which is the terrifying part. We already fight enough with our dependencies as is. Imagine if we had to know every single PyPI package that everyone depended on at any point in time, before we felt confident upgrading any?
[One other quick note about Python models: It will of course be possible to write and use generate_date_filter_clause() as a Python function, insofar as it's Python code that runs remotely in the warehouse. In some cases, we think it will be desirable for a Python model (?) to actually register its result as a UDF in the database, which can be called from SQL models—but this makes more intuitive sense for ml_predict() or business_minutes_between() than it does for fancier SQL templating. The risk is much lower visibility for the end user, since dbt isn't "compiling" that more-concise function down to some more-verbose "actual" SQL, as it does with macros.]
So what then?
Here's my take, with which you're more than welcome to disagree: I think what you're describing is actually a dbt plugin, written in Python, which has the ability to register and expose some of its methods in the user's Jinja context. That plugin would be installed alongside dbt-core, and discovered by the dbt-core application by namespacing its modules in a well-understood way.
We have a pattern for that today, in the form of adapter plugins. We've understood for a long time that the work of translating between dbt <> Another Analytical Database is a much bigger lift than translating business/transformation logic into Jinja-SQL. Adapter authors need the ability to write and test their functionality in a real programming language, and in many cases to access data platform APIs that simply aren't exposed via SQL. (BigQuery is the most prominent example.)
It's also a recognition that the "adapter maintainer" persona is a very different one from "dbt user" / project code writer. There are many fewer adapter maintainers; we (as dbt-core maintainers) have a much closer relationship with them; they're opt into a higher maintenance burden, to do a more complex thing; and they understand that they're creating a product on top of dbt, with all the thinking about longer-term repercussions that entails, not just hacking a thing that needs to work right now.
Concretely, we allow adapter maintainers to write whatever Python code they need, and to register some of them as class methods and members on the adapter object—which end users experience call as "macros" from the adapter namespace. To your point about "string processing," for instance: as dbt-bigquery maintainers, we wrote the logic for validating user-provided partition_by config, and it rendering it as an appropriate string to BigQuery's specifications, in Python here. We then call it from within the Jinja context here and here.
How could this be better?
Down the line, I could see a generalized pattern for supporting dbt plugins that don't actually want to be database adapters. They could register custom namespaces, instead of over-loading the adapter namespace. Perhaps there could be a dbt-logging plugin, which makes available methods like logging.fire_event() in the Jinja context—although I'll note that we've meaningfully reinvested in the core eventing and structured logging interface for real-time metadata. We're still building the companion tooling for it, but we definitely recommend it instead of this package.) Such a plugin almost exists today for dbt + Openlineage, but openlineage-dbt has to be a wrapper around the dbt-core CLI, rather than a plugin registered within it.) Not today, but eventually, we'd want to support totally custom plugins in dbt Cloud, whether written by technology partners or community members or in-house dbt pros.
In the meantime: What do you think of forking of dbt-bigquery? Or an extension off it, in the same way that dbt-materialize is an extension of dbt-postgres? That requires a conscious choice, and a separation between Special Methods and Actual dbt Project Code. If you write methods that solve for a common problem, one which you think other folks would benefit from, a PR upstream to the main dbt-bigquery repo is always on the table.

I'm going to close this pr since we're not going to merge these changes. Please continue the conversation if you're so inclined.

Hey @mistercrunch - did you ever continue with something like this? I just proposed a similar thing (#8000) and agree that it would be very useful to have this sort of flexibility within dbt.


Development under progress ?

Is this project under development  ?
Or stopped
Please let me now .
I am  very excited to run php on jvm . PHP 7.2

Project is under development, but I spend a lot of time on a project which depends on jphp - https://github.com/jphp-compiler/develnext.

I have no plan to implement the PHP 7+ language features in the near future. Maybe 2018 year...


fix: backup exception with array

Description

Motivation and Context

How Has This Been Tested?

Types of changes

[] Bug fix (non-breaking change which fixes an issue)
[] New feature (non-breaking change which adds functionality)
[] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[] My code follows the code style and structure of this project.
[] I have updated the documentation accordingly.

:tada: This PR is included in version 0.3.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Keyword attribute/field is not present in AMA

Hello Team,
I am working on implementation that requires keyword field to identify whether Audit is failed or success, But in Recent AMA logs, I am not able to find keyword field.
Example :
In old logs format For example below URL mentioned logs has Keyword field associated with it. Which is not present in new log format.
0x8020000000000000
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4740
In new log format : keyword field is not present. How can I check whether Security Auditing event is success or failed.
https://learn.microsoft.com/en-us/azure/azure-monitor/agents/data-sources-windows-events
Any help would be much appreciated.
Thanks In Advance
Dhavalkumar Chauhan

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

ID: 705ea04e-c7d0-8357-b016-6371e2d85e1c
Version Independent ID: 7529775d-4f01-ab69-0e77-7a55ba0e5595
Content: Collect Windows event log data sources with Log Analytics agent in Azure Monitor - Azure Monitor
Content Source: articles/azure-monitor/agents/data-sources-windows-events.md
Service: azure-monitor
Sub-service: agents
GitHub Login: @guywi-ms
Microsoft Alias: guywild

@Dhaval8951
Thanks for your feedback! We will investigate and update as appropriate.

The Azure Monitor team is urgently working to resolve this issue.  I do not have an ETA, but multiple engineers are currently working on this issue.

@JeffreyWolford
Much appreciated response, Thank you for this.
May I know that mentioned will going to be introduced in AMA logs or if it is possible what kind of solution will be provided for this to identify whether security audit is success or failure ?
Warmest Regards,
Dhavalkumar Chauhan
CC @PesalaPavan

Hi @guywi-ms
Greetings of the Day !
Can you please provide any kind of update you have that you can share with us ?
It is blocking us, because of Audit Success or Audit Failure is identification is not present in AMA Security logs.
Warmest Regards
Dhavalkumar Chauhan

Hi @Dhaval8951
Hope you're well!
@JeffreyWolford can you please update @Dhaval8951? I believe this is a product issue.


Uppercase nullto NULL

Yaml has two valid null types: ~ and null as per snake yaml documentation
Both currently translate to null in output SQL code. We need to uppercase null so it becomes NULL and to cover this scenario with tests:

~ -> NULL
null -> NULL
Null -> NULL
nULL -> NULL
nulla -> 'nulla'

PR https://github.com/vkorobkov/jfixtures/pull/93

issue fixed and released v1.0.27


All my chats are gone

Describe the bug
All my chats are gone!!!
Link to the Bolt URL that caused the error
All my chats are gone!!!
Steps to reproduce
All my chats are gone!!!
Expected behavior
All my chats are gone!!!
Screen Recording / Screenshot
All my chats are gone!!!
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context
All my chats are gone!!!

Hi @HolmBIM,
Current workarounds and upcoming solutions are being tracked here: #39.


storage: update BlobPrefetchRequest fields type from u32 to u64

Blobfs relies on the BlobPrefetchRequest structure that field of "offset"
and "len" are both u32, the maximum support is 4G. But the maximum blob file
will exceed 4G, so change the define of "offset" and "len" to u64.

LGTM!

Besides there're clippy warnings that should be fixed.


Regarding how to train on other datasets

I would like to ask if you, the author, are familiar with the Babel dataset？ I am interested in training this dataset on your model. Could you please provide me with some suggestions?

Babel is a action-labelled dataset built on AMASS, which is similar to HumanML3D. So it should be easy to convert Babel motions to our 263 motion vectors. You just need to properly slice them according to Babel annotation and convert them using HumanML3D preprocessing scripts.


Fix/lightbox media spacing

Related Ticket(s)
#1092
Description
This updates layout and spacing for the LightboxMediaViewer for various aspect ratios, as well as responsive layouts for these ratios.
Draft pending review from @wonilsuhibm
Changelog
New

adds additional image aspect ratios to Storybook

Changed

update LightboxMediaViewer css to handle various aspect ratios at all breakpoints

Deploy preview created for package "Carbon Expressive":
https://carbon-expressive.s3.us-south.cloud-object-storage.appdomain.cloud/deploy-previews/1781/index.html
Built with commit: 2af93a5a535347ef5af23713a9c437eaf3579986

@kennylam fyi, this is built from the package: styles label.

Deploy preview created for package "Carbon Expressive":
https://carbon-expressive.s3.us-south.cloud-object-storage.appdomain.cloud/deploy-previews/1781/index.html
Built with commit: 2af93a5a535347ef5af23713a9c437eaf3579986

@kennylam fyi, this is built from the package: styles label.

yep


Missing GridFieldSortableRows

Hi there,
Your code seems to use this class GridFieldSortableRows which I think is here I feel that your composer.json file should be requiring this or at least your documentation should.
Happy to put a PR together to fix this but was hoping you could confirm that this is the right codebase

Yeah your right, it requires that plugin. Its been added to composer now, thanks

You're welcome


Implement rule zig_shared_library

Solves #102
This is what I have so far. I'm not sure what command to run for the cross-platform tests. @aherrmann please advise.

Updated to fix the tests and address the comments:

renamed library target name to shared (was library), so make it more obvious the the name libshared.so is what's intended
added prefix for linux and macos
fixed soname
fixed tests and added more (threaded and mode)

Fixed tests failures related to defs import


Add support for shared and detached pools

Current version of F5 agent code still assumes pools must be associated with a listener. Mitaka introduced the ability to create detached pools (pools not associated with a listener) and shared pools (pools associated with multiple listeners).  Add support to create, update, delete detached and shared pools, and update associated listener.

Fixed in Commit in PR #412


net: Dialer should use specific LocalAddr to do dns resolve

If use custome LocalAddr in Dialer, the localaddr changed,but the remoteaddr according to dns resolve  is not changed.
For example: two different ip IpA and IpB belongs to different isp in my computer. DomainC is what i want to send request to. So i use custome Dialer to choose which ip i want to use as my localaddr. Linux dig tool can resolve different ip use -b option sets the source IP address to IpA or IpB of the query. But in golang the ip resolved is the same. I use httptrace to find localaddr changed but remote ip is the same.

I'm afraid this is not how any resolver library actually works. dig is very special in that it is a debugging tool that sends DNS requests itself.
You'll need to explicitly send DNS requests yourself if you want to have this behavior. Perhaps using a library like https://godoc.org/github.com/miekg/dns

This is a reasonable request,i use ip of ispA, how can the resolver resolve ip to ispB ?

        // LocalAddr is the local address to use when dialing an
        // address. The address must be of a compatible type for the
        // network being dialed.
        // If nil, a local address is automatically chosen.
        LocalAddr Addr

Perharps it should do every net request using LocalAddr, including dns query.

This seems like a reasonable request. Or something in the new Resolver type.

/cc @mikioh

I think it's reasonable to support this feature because unlike conventional DNS APIs we can provide both DNS RR exchange control and DNS transport control through the combination of Dialer and Resolver structs. If there is a reason to hesitate to do this it must be overkill, but nowadays we see the complicated circumstances; multiple IP links/interfaces, two IP address spaces. Probably just following the existing APIs/behaviors wouldn't be much help for the circumstances.

I'm working on this - specifically I'm working on a way to configure the Dialer that a Resolver will use for to make its connections. Note that this can only work when the go (not cgo) resolver is used, and that's not available on some platforms.

@Tevic, can you clarify your situation?  When you look up domainC on ispA (using dig), do you get an IP address back? What about on ispB? If both lookups succeed, do you get the same or different IP addresses?

A domain set two A Records : ispA->ipA, ispB->ipB
A Server with 2 IPs: ip1(belongs ispA), ip2(belongs ispB). Default route is ip1.
Golang Behavior: Set LocalAddr: ip1,RemoteAddr get ipA.  Set LocalAddr: ip2,RemoteAddr still get ipA.
Expected Behavior: Set LocalAddr: ip1,RemoteAddr get ipA.  Set LocalAddr: ip2,RemoteAddr still get ipB.
Using dig's -b option get the expected behavior.

@Tevic, please understand that what you are asking for is very unusual behavior. DNS is not designed to work the way you are requesting. We are working on a way to allow you to get that behavior, but I don't think we can make it the default. You would need to create a Dialer, set a custom Resolver in that Dialer, and use that Dialer to make your connection. As long as you own the code doing the dialing, that should work out OK.

Yes,you're right. Thanks for your working on custom resolver. Previous golang has no resolver option.


Fix the way accessor method names are determined for the fields of an entity

Currently, the accessor methods for a field are determined with -
	"set" + Character.toUpperCase(fieldName.charAt(0)) + fieldName.substring(1);
	"get" + Character.toUpperCase(fieldName.charAt(0)) + fieldName.substring(1);
	"is" + Character.toUpperCase(fieldName.charAt(0)) + fieldName.substring(1);

While this works in most cases, there are some situations where this does not work right/not compatible with IDE's generated setter and getter methods. For example, if a field name is iPhone, the IDEs generate setiPhone and getiPhone methods. Note the small i in the method names. The code above instead looks for setIPhone and getIPhone and ends up not finding the methods.
The fix is to examine the second character of the field name, if it is upper case, do not do anything and use the field name as is and prepend set/get/is. Otherwise, fallback to the existing code.
See https://github.com/sai-pullabhotla/catatumbo/issues/95 for more details.

Fixed and added test cases.


Attempt to Auto Update CLogs from collectionlog.net

We don't want to require users to sign up for collectionlog.net to use the rank system, but we want to support automatic updating for those that are registered in their system.

I believe jagex has said they want to add clogs to the hiscores, so we should probably wait for that as it'll be far easier to implement.


How to represent areas of no data in GeoTIFF

It's not clear how areas of no data should be represented in GeoTIFF coverages.  For numeric-type coverages (such as DEMs), the GDAL NODATA tag is a fairly standard mechanism for this.  However, for RGB coverages, the NODATA tag is ill-defined and not interoperable.  For this reason, the CubeWerx coverage server returns RGB GeoTIFF coverages with an alpha channel to indicate areas of no data.  But this raises further issues.  For example, should the coverage/rangeType endpoint report this alpha channel, and if so, how?  And what should the value range of the alpha channel be?
These issues arose during interoperability experiments during the recent "OGC API - Coverages" sprint (specifically between the Ecere client and the CubeWerx server).
I think the OGC API - Coverages" specification should provide guidelines for this.

for such situations we have the corresponding conformance class in CIS, allowing a canonical "header" followed by one or more binary files. The spec says, paraphrased,
"If you request GeoTIFF (or GRIB or...) you know there are limitations, if you want it all request an informationally complete format/mix."
To enhance information transported in TIFF the right spec to amend would be the CIS GeoTIFF mapping (editor: @Schpidi).

I'd argue that when using an alpha channel the rangeType should report this accordingly. Otherwise clients expecting 3 bands but getting 4 would be confused. Note that RGB coverages are a special case, admittedly a quite common one, but for example in EO we constantly have the issue that we have 4 band coverages (RGBNir) where the software wrongly interprets the 4th band as being alpha although clearly indicated otherwise in the metadata.
Regarding the NODATA tag, could you elaborate why you think it is ill-defined?

How should an alpha channel be conveyed by the coverage/rangetype endpoint?  The following doesn't seem adequate for conveying alpha-channel semantics to the client:
  {
    "type": "DataRecordType",
    "field": [
      {
        "type": "QuantityType",
        "id": "1",
        "name": "Numeric-sample channel",
        "definition": "ogcType:signedShort"
      },
      {
        "type": "QuantityType",
        "id": "alpha",
        "name": "Alpha channel (-32768=transparent, 32767=opaque)",
        "definition": "ogcType:signedShort"
      }
    ]
  }

I believe the value of the NODATA tag is intended to be a single number representing the sample value that indicates the absence of data.  That's fine for independent numeric bands, but makes no sense for RGB, where all three bands together convey a single piece of information.  A NODATA value of "0", for instance, would indicate that the color (0,34,192) indicates how much green and blue there is, but not how much red.  That's obviously not the intended semantic.  Apparently there's a convention that the NODATA value be represented as an r,g,b tuple (e.g., "(0,0,0)"), but I'm not aware of any specification anywhere that actually spells this out, leading to guesswork and finger-crossing.  Also, there's no way to indicate a NODATA value that's not actually in the range of valid colors.  This leads to the common problem of black (or white) pixels disappearing in the actual imagery because they're being treated as NODATA.

Well, I'd say it is the responsibility of the data provider to make sure there is no clash between nodata value and an actual value.
In the tiff tag registration I read: "If the image has more than one sample it is assumed that all samples have the same nodata value." (https://www.awaresystems.be/imaging/tiff/tifftags/gdal_nodata.html).

@Schpidi wrote:

In the tiff tag registration I read: "If the image has more than one sample it is assumed that all samples have the same nodata value." (https://www.awaresystems.be/imaging/tiff/tifftags/gdal_nodata.html).

I take this to mean that a NODATA value can't be specified separately for each band.  That is, each band must have the same NODATA value.  So for three-band GeoTIFF, if NODATA="0", then band 1 has a NODATA value of 0, band 2 has a NADATA value of 0, etc.
Since RGB images are encoded as three separate bands, this implies that NODATA="0" means the red band has a NODATA value of 0, the green band has a NODATA value of 0, and the blue band has a NODATA value of 0.  That means each of the pure colors black, blue, green, cyan, red, purple, yellow and white will be treated as having at least one transparent component.  This obviously isn't what's desired.

Discovering this issue only now, I am not fully sure on the result / convergence for this discussion.
For sure, the GDAL_NODATA tag for multi-band or RGB (e.g. with a value of 0, implies 0 for each band, therefore pure black value for RGB. This is also the way it is specified in DGIWG GeoTIFF profile (OGC BP  20-095).
For product such as orthoimagery, it seems it is not an issue to reserve Pure black for void or transparent pixels.
The other pure colors are not supposed to be impacted.
By the way, in addition to the TIFF alpha channel (based on the TIFF ExtraSample tag), there is also the option of handling a Transparenyc MAsk as a bilevel image, handled in an additional TIFF IFD. This option is documented in the DGIWG GeoTIFF profile.

SWG 2022-02-16: Reviewing this issue, we can recommand three potential approaches to handle NODATA:

Use the GDAL_NODATA tag, which applies to all bands
Use an alpha channel where 0 transparency means NO DATA
Specify a per-band NODATA value as part of a suggested encodingInfo extension to the RangeType DataRecord fields (which also addresses the scale factor and offset)

Note that the photometric interpretation TIFF tag should be set correctly to prevent the alpha channel from being interpreted incorrectly. These recommendations could be included as part of a GeoTIFF conformance class in OGC API - Coverages.
Another possibility is a transparency mask band, but in practice it is difficult to implement and does not work with a wide range of software.
Some data products (e.g. LANDSAT-8) have a dedicated quality assessment band with more detailed information as a set of bits (see https://www.usgs.gov/landsat-missions/landsat-collection-2-quality-assessment-bands).


add concurrency limit for data generation

Description
This change makes use of async_utils.run_jobs to limit the number of concurrent LLM requests when generating datasets.
I noticed that the current notebook on dataset generation use the deprecated dataset generator. if its desired, i can update it to use RagDatasetGenerator.
Type of Change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Added new unit/integration tests
[ ] Added new notebook (that tests end-to-end)
[x] I stared at the code and made sure it makes sense

Suggested Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I ran make format; make lint to appease the lint gods

@clarencenhuang feel free to make a pr for if its desired, i can update it to use RagDatasetGenerator. thanks!


Confusing behavior of bcf log and --raw not working

I just realized, in a hard way, that bcf log supressess log lines that do not start with the character '#':
https://github.com/hardwario/bch-firmware-tool/blob/52587f6a5b86b1ce3ef104b339791576f78ee22c/bcf/log/log.py#L47-L85
I then tried to use --raw, but that option doesn't appear to be working. Even with bcf log --raw -d /dev/ttyUSB0 I am still not seeing lines that do not match the pattern.
Case in point: When I perform a hard reboot in my firmware, the first character of the first log line that is produced after the reboot is garbage:
pi@rover:~/lora/firmware2 $ tail -f /dev/ttyUSB0
�# 0.00 <I> LoRa Module v1.1.1-37-gfa069eeb (modified) [LoRaMac v4.6.0-25-gae588f35] built on 2022-Jun-15 10:21:16 EDT
# 0.00 <D> part: Opened block 0x20000b50 (6144 B), 8 parts of 8
# 0.00 <D> Restoring system configuration from NVM
# 0.00 <D> LoRaMac: Initializing for region US915, regional parameters RP002-1.0.1
...

but bcf log --raw -d /dev/ttyUSB0 throws the entire line away:
pi@rover:~/lora/firmware2 $ bcf log --raw -d /dev/ttyUSB0
0.00 <D> part: Opened block 0x20000b50 (6144 B), 8 parts of 8
0.00 <D> Restoring system configuration from NVM
0.00 <D> LoRaMac: Initializing for region US915, regional parameters RP002-1.0.1
...

This is, in my opinion, very confusing behavior. Would it be possible to modify bcf log to always display all output so that there would be no need for --raw?

@janakj Just a bit of background story for clarification: This # log-prefix character is a future preparation for TOWER to be able to combine console functionality (i.e. ATCI) and log in the same serial stream. The --raw parameter of the bcf log command is there just to avoid colored output.
Of course, we can extend the CLI functionality, so it will do what you would expect - maybe --raw would really print the serial stream as it comes, and --no-color would avoid terminal escape sequences. The options --raw and --no-color are mutually exclusive.
I would keep bcf log doing what it is supposed to do - to display log messages only.
We are working on a unified HARDWARIO CLI tool (already available for CHESTER), that will absorb all this functionality. There will be a command:

hardwario tower console - Opens ncurses-based dual-pane window with interactive shell on the left side and logs on the right side
hardwario tower log - Opens stdout stream to log messages

We can eventually introduce the hardwario tower monitor command to pass-thru everything as-is.
How about that? Thanks.
BTW: If you don't know the tool picocom, it is my favorite serial port terminal (just a hint before we put it in the CLI tool 😄).

@janakj Well, based on the --help listing, I can say that --raw truly does not work as expected then.
Honestly, I really prefer introducing a monitor command that would work as a pass-thru pipe, rather than hacking the log domain and mixing up the terminology. But let's explain the --raw behavior first.
Addressing @blavka as the author of the package. Could you please look into that? Thanks.

In my opinion, the problem is not in the --raw parameter, but in string decoding
here:
https://github.com/hardwario/bch-firmware-tool/blob/52587f6a5b86b1ce3ef104b339791576f78ee22c/bcf/log/log.py#L109
How about sending the first new line and then the first log message.

Yes, years later, I would choose --all instead of --raw

In my opinion, the problem is not in the --raw parameter, but in string decoding here:
https://github.com/hardwario/bch-firmware-tool/blob/52587f6a5b86b1ce3ef104b339791576f78ee22c/bcf/log/log.py#L109

That sounds likely. It probably fails because it's not a valid UTF-8 stream.

How about sending the first new line and then the first log message.

I am not sure how that would help.

Ok, that would fix this particular issue, yes. But what if the firmware sends a non UTF-8 character explicitly, or what if there is line noise? It seems to me that the proper fix would be to modify bcf to ignore UTF-8 decoding errors and output the line nonetheless.

How about sending the first new line and then the first log message.

I am not sure how that would help.

Clear buffer you get on serial:
�\r\n
# 0.00 <I> LoRa Module v1.1.1-37-gfa069eeb (modified) [LoRaMac v4.6.0-25-gae588f35] built on 2022-Jun-15 10:21:16 EDT\r\n
# 0.00 <D> part: Opened block 0x20000b50 (6144 B), 8 parts of 8\r\n

and bcf log --raw :
# 0.00 <I> LoRa Module v1.1.1-37-gfa069eeb (modified) [LoRaMac v4.6.0-25-gae588f35] built on 2022-Jun-15 10:21:16 EDT\
# 0.00 <D> part: Opened block 0x20000b50 (6144 B), 8 parts of 8

I released with fix: bcf==1.8.3
Can you try ?

Thanks a lot for the release, @blavka! This indeed fixes my problem (since I run with --raw), I see a message that looks as follows now:
b'\xf3# 0.00 <I> LoRa Module v1.1.1-43-gf86592d2 (modified) [LoRaMac v4.6.0-23-g50155c55] built on 2022-Jun-20 00:25:27 EDT\r\n'

However, I would like to suggest two improvements to the fix, if you don't mind:

Why not pass errors='replace' to the decode function instead of printing the string manually with repr? This would give you a nicer output and all UTF-8 decoding errors will be handled automatically.
I think errors='replace' should be passed to the decode function unconditionally, even when --raw is not in effect. Without this, you are assuming that the log produced by the firmware is a valid UTF-8 stream. I don't think that's generally the case, especially not in C/C++ (twr-sdk doesn't even have proper support for multi-byte encodings). bcf log can try to interpret the data as UTF-8, however, the message should be shown even if that fails since the firmware could simply be sending you arbitrary 8-bit ASCII data. `decode(errors='replace') will accomplish that.


Package plugin: implement complex config callback

Hi octo,
This pull request covers the implementation of the complex_config callback. It allows plugin authors to define a struct that both specifies and holds a desired configuration structure from the main config file. I've tried to be helpful to both the plugin author and end-user by validating the configuration and struct as far as possible.

The RequestConfiguration(name string, c Configuration) (chan struct{}, error) function registers the configuration callback and kicks off the process of parsing the configuration. On success it returns a chan struct{} which is only closed when the configuration is fully parsed and validated. This acts as the semaphore preventing concurrent memory access by allowing the plugin author to block until the parsing functions are finished.

The Configuration interface requires a method Validate() error to be implemented, which allows the plugin author to specify any configuration validation they feel necessary. The function is called once the struct is filled and if it returns != nil collectd exits with the error message provided.

Documentation including examples will follow shortly but your review of this code would be greatly appreciated.
-- alowde

Hi @octo,
A massive thanks for your code review on this one. You've identified a couple of core issues but nothing that won't be soon resolved, if I've understood the issues correctly and you're happy with the proposed solutions.
I'll go ahead and implement the initialisation callback and move the appropriate function calls there, and if you could let me know how you'd prefer to proceed with the multi-value option issue and the two-phase config validation I'll implement them soon.
Kind regards,
Ashley

Hi @octo,
These changes are expected to resolve the minor issues and also to properly handle validating and signalling config load for multiple plugins. One thing I've noticed when testing is that if the init callback returns non-zero the daemon attempts to unload the plugin's read function even when it doesn't have one. I've had a look at the daemon code but it wasn't clear to me how the init callback should indicate which functions are to be unloaded - could you have a look?
I've held off implementing multi-value options so far; could you please let me know if you have a preference for how they're implemented? I like maps as a direct analogue to the configuration format, but I can implement tags or something more interesting if you prefer.
Thanks very much for your time and the opportunity to contribute to this project, it's much appreciated.
Kind regards,
Ashley

This PR looks exactly like what I need, is this something we can bring back to life?

Hi @MovieStoreGuy, thanks for your interest. This PR presupposes a given approach for mapping Go structs to Collectd config that might not be the best fit for Collectd, so there's potentially some discussion and refactoring required before it would be in a state to be merged. If the code would be useful to someone I'm happy to go back and work through both that and the points raised by @jereyjb.
@octo would you be interested in discussing a design proposal for mapping Go structs to config? Do you have any starting points in mind?

My interest in this is that I am writing a new monitor and I would like to be able to read the config provided rather than discard it or do some funky work arounds with reading alternative paths or envs.
I haven't look in too much detail what this PR introduces but I'd be happy to be part of any discussions that you guys have in mind @alowde  @octo .

Hi all,
sorry for the long delay. If you have since moved on, I understand. I'd appreciate if you'd let me know though so I can pick this up myself.
Before I dive into a code review, I think we should discuss the API first. By that I mean the interface that users (Go programmers) program against. I see two fundamental decisions:

First, (in C) config callbacks may be called multiple times, for example if the plugin's configuration is split over multiple files. I think we can deal with this in a few different ways:

Leaky abstraction: document that Go plugins' config callback may be called multiple times, too.
Defer calling configuration callbacks until all config has been processed (i.e. when the init callbacks are called) and merge the configs together somehow. (hint: how to deal with multiple children with the same key?)
Document that splitting the configuration in that way is not supported for Go-based plugins. This may cause hard to debug issues though.

Second, should the callbacks receive a generic Config structure, like the C-based plugins do, and iterate over it themselves – or should there be some unmarshalling into a Go structure, like the code is aiming for now. A third option would be to allow for either, by providing two possible callback prototypes.

Personally, I think we should defer calling config callbacks and merge multiple configuration blocks transparent to the user. To do this, we would convert the C structs into a Go struct like the one below:
type Config struct {
  Key      string
  Values   []ConfigValues // basically implementing the union, see below
  Children []Config
}

// Merge appends other's children to c's children.
// Returns an error if Key or any Values differ.
func (c *Config) Merge(other *Config) error {…}

I think the cleanest interface would be to pass this *Config to the user-provided callback, i.e. the user's code would look something like the below.
func (myPlugin) Configure(ctx context.Context, c *plugin.Config) error {…}

plugin.RegisterConfig("myPlugin", myPlugin{})

This avoids holding a reference to the user-provided struct, which only becomes usable at a later point in time. Users also don't need to deal with channels, i.e. not every plugin needs to either block until the config is available (potentially indefinitely if no configuration is found; might starve threads if done from the Read() or Write() callback) or figure out how to check if a channel is closed without blocking.
The Config structure should have a Unmarshal method, allowing users to elegantly map this generic struct to a more useful config struct in their code:
// Package plugin:
func (c *Config) Unmarshal(v interface{}) error {…}

// User code:
func (p *myPlugin) Configure(_ context.Context, c *plugin.Config) error {…}
  // myPlugin only exports configuration options;
  // private fields are not modifiable by plugin.Config.Unmarshal().
  return c.Unmarshal(p)
}

What do you think? What do you see as the benefits of the "pass a reference and then block on a channel" approach?
Best regards,
—octo
Appendix: ConfigValue would look somewhat like this:
func (c *Config) Unmarshal(v interface{}) {…}

type ConfigValue struct {
  typ configValueType
  s   string
  f   float64
  b   bool
}

func (v ConfigValue) String() (string, bool) {
  return v.s, v.typ == configTypeString
}

// Dito for Number() and Bool()

I realize I have totally dodged the "how to implement this magical Unmarshal() method" question. First of all, I would normalize the (Go) struct, so that
Opt "foo"
Opt "bar"

— and —
Opt "foo" "bar"

produce the same result. If one key has values of different type, I'd return an error. So these would be rejected:
Host "example.com" 443
Opt 42
Opt true

And then we can go over some common data types and discuss how a Config should be unmarshalled into it. For example:

struct: c.Children[i].Key is mapped to a field name, then c.Children[i] is unmarshalled into that field. c.Values is unmarshalled into a field called BlockValues (alternative: use a collectd:"block_values" field tag)
map: map must be string-keyed. c.Values must be empty. Each c.Children[i] is unmarshalled into a map-element.
slice: c.Children must be empty. Each c.Values[i] is unmarshalled into a slice-element.
string, float64, bool, …: c.Children must be empty, c.Values must have length 1.
chan: unsupported for now.

Example config:
<Plugin "myPlugin">
  <Host "example.com">
    KeepAlive true
    Expect "foo"
    Expect "bar"
  </Host>
</Plugin>

Example Go struct:
struct {
  Host []struct{
    HostName  string `collectd:"block_values"`
    KeepAlive bool
    Expect    []string
  }
}

Does this help?
—octo

Hi Florian, thanks for picking this up again. I've requested clearance from
my current employer to continue contributing (should be fine) and I should
be able to check in again soon.
Kind regards,
Ashley
On Thu, Apr 16, 2020 at 5:31 AM Florian Forster<EMAIL_ADDRESS>wrote:

I realize I have totally dodged the "how to implement this magical
Unmarshal() method" question. First of all, I would normalize the (Go)
struct, so that
Opt "foo"
Opt "bar"
— and —
Opt "foo" "bar"
produce the same result. If one key has values of different type, I'd
return an error. So these would be rejected:
Host "example.com" 443
Opt 42
Opt true
And then we can go over some common data types and discuss how a Config
should be unmarshalled into it. For example:

struct: c.Children[i].Key is mapped to a field name, then
c.Children[i] is unmarshalled into that field. c.Values is
unmarshalled into a field called BlockValues (alternative: use a
collectd:"block_values" field tag)
map: map must be string-keyed. c.Values must be empty. Each
c.Children[i] is unmarshalled into a map-element.
slice: c.Children must be empty. Each c.Values[i] is unmarshalled
into a slice-element.
string, float64, bool, …: c.Children must be empty, c.Values must
have length 1.
chan: unsupported for now.

Example config:
<Plugin "myPlugin">
<Host "example.com">
KeepAlive true

Expect "foo"

Expect "bar"

Example Go struct:
struct {
Host []struct{
HostName  string `collectd:"block_values"`

KeepAlive bool

Expect    []string

}
}
Does this help?
—octo
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/collectd/go-collectd/pull/30#issuecomment-614251309,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQEVYDUDDCJMTPWZXFJGYTRMYHA7ANCNFSM4DKVA3ZQ
.

Hi Florian,
After going through the code and from what I recall, the intention of receiving a plugin-provided struct was to allow the plugin author to easily define a valid configuration, differentiating between invalid structure (config in file doesn't match plugin struct) and invalid values (structure in file is as expected, but doesn't validate for some other reason). This would allow us to programatically give hints to the end-user about why a structure was invalid (expected a key: "x" but didn't find it).
The intention was that each configuration callback would write values to the provided config struct, handling merges with last-writer-wins. This does introduce the complication of signalling to the plugin that configuration has been provided, hence the channel to be closed when all configs are loaded.
Looking through the code now I would say that while the concept is valid the insertion of config into a referenced variable is problematic. Returning a config value from a blocking call would be easier to handle. In addition, merging the callLooking through the code now I would say that while the concept is valid the insertion of config into a referenced variable is problematic - returning a config value from a blocking call would be easier to handle. I think merging configs at each callback and then calling the plugin-provided Configure function just before init would be ideal. Accepting the merge of heterogenous values by storing them as a []ConfigValues sounds like a perfect solution for simplifying the code.
For the implementation of Unmarshal I would like to emulate the stdlib JSON package and support the use of struct tags to allow assignment of values to arbitrary fields. I feel that this would be the most familiar design to Go developers who are not familiar with Collectd. Additional potential advantages of struct tags that I see:

Decouples variable names from configuration field names
Supports a simple and clear method for defining compulsory values
Optionally, a degree of flexibility in the unmarshal function (for instance, accepting scalars as well as slices and int/float32/float64. This would support the plugin developer in defining a specific interface. For example an error from the unmarshal function ("when unmarshalling field x: could not parse []int as int") would be relatively helpful bubbled up to the end user without adding complexity to the plugin.

If the use of tags in this way is acceptable I'll add a proposed list of tags and scenarios for handling them for discussion.
Thanks very much for this detailed feedback. I'd like to discuss this further and once you're happy with the proposed API potentially drop this PR and raise a new one, as it seems that a full rewrite might be in order.
Kind regards,
Ashley

Hi Ashley,
it reads like we're in agreement. Let me give a more complete example of how I picture the API to be used to illustrate my thoughts:
type myPlugin struct {
  // Host is the address to connect to. User-provided in the config.
  Host string

  // private fields are *not* config options.
  conn *client.Connection
}

func (p *myPlugin) Config(ctx context.Context, rawConfig *api.Config) error {
  if err := rawConfig.Unmarshal(p); err != nil {
    return fmt.Errorf("mapping user-provided config to Go struct failed: %w", err)
  }
  return nil
}

func (p *myPlugin) Read() error {
  if p.conn == nil {
    if p.Host == "" {
      return errors.New(`configuration error: the "Host" option is required`)
    }
    p.conn = client.Connect(p.Host)
  }
  // use p.conn to read metrics
}

func init() {
  p := &myPlugin{}
  plugin.RegisterConfig("myPlugin", p)
  plugin.RegisterRead("myPlugin", p)
}

Please let me know if any of this doesn't sit right with you.
I agree with the notion of copying the encoding/json behavior. I'm happy to push the implementation of field tags to a second iteration though, as fields tags should, ideally, be fully optional, making their addition backwards compatible. (That doesn't mean that we can't or shouldn't discuss the field tags yet, though.)
What do you mean by "degree of flexibility in the unmarshal function"? My intuition was to copy the "encoding/json".Unmarshaler interface, i.e. if the target implements an appropriate interface, we'd delegate unmarshaling to that method. Example interface:
type ConfigUnmarshaler interface {
  func Unmarshal(rawConfig *api.Config) error
}

Best regards,
—octo

Hi Florian,
The above example makes sense. When I was imagining the API previously I'd assumed separate structs for config and read functions, but plugin==[struct with appropriate methods] is a neat little package.
I agree that if the target implements an appropriate interface we would delegate to it. By flexibility I mean that I'd like to consider support for unmarshaling a ConfigValue with ConfigValue.configValueType == configTypeNumber to target types Int, Int8, Int16, Float32, Float64 etc. I think that this would cover nearly all use cases. On the other hand this might open up too many edge cases where we're silently converting data - what do you think?
In any case the set of rules looks good so far, and I'm happy to leave struct tags for a second iteration. Continuing your example for how a Config should be unmarshalled into a Go variable (and skipping maps, tags for now):

Field Type
Unmarshal Behaviour
Ashley's Notes

ConfigUnmarshalers
Delegate unmarshaling to UnmarshalConfig function
Highest priority - if the field meets this interface we should override normal behaviour. Suggesting function name UnmarshalConfig to avoid collisions and for consistency with other packages.

struct
c.Children[i].Key is mapped to a field name, then c.Children[i] is unmarshalled into that field. c.Values is unmarshalled into a field called BlockValues if present.
Lack of BlockValues field is not an error. Dropping tags for now. I assume if there's more than one value in c.Values then BlockValues must be a slice?

[]struct{} (slice of structs)
c is unmarshalled into a struct and appended to the slice.
Should this be each of c.Children is unmarshalled as a struct and appended to the slice?

[]string, []float64, []bool, …
c.Children must be empty. Each c.Values[i] is unmarshalled and appended to the slice.

string, float64, bool, … (slice of scalars)
c.Children must be empty, c.Values must have length 1.
Do we want to support coercion to string type for Number and Bool values? Do we want to support coercion to the various number types for Number values?

chan
unsupported for now.

pointer
dereferenced and treated as above
Assuming this is fine

encoding.TextUnmarshalers
Fallback only if concrete types abover are not matched. Error if configValueType != configTypeString. Return result of UnmarshalText.
Sound reasonable, leave to next iteration, or flawed?

If I've missed anything above that we should support please let me know.
Once you've advised how to proceed on the questions above, if this looks good then I'd be happy to start a new draft PR with the interfaces and types described in your examples. I can then add the config merge function and unmarshal functions and once that's confirmed OK I think it'll be straightforward to reimplement the C-Go portion of the code.
Before we move to that phase though, are you happy with PR comments for discussion of the API or would wiki/IRC/email suit better?
Thanks,
Ashley

By flexibility I mean that I'd like to consider support for unmarshaling a ConfigValue with ConfigValue.configValueType == configTypeNumber to target types Int, Int8, Int16, Float32, Float64 etc.

I'd argue it's up to the plugin author to chose a suitable type. We can use Type.ConvertibleTo and Value.Convert() for all non-assignable (Type.AssignableTo) values.

Field Type
Unmarshal Behaviour
octo's Notes

ConfigUnmarshalers
Delegate unmarshaling to UnmarshalConfig function
ACK, "UnmarshalConfig" SGTM

struct
c.Children[i].Key is mapped to a field name, then c.Children[i] is unmarshalled into that field. c.Values is unmarshalled into a field called BlockValues if present.
Upon further reflection, I'd prefer the name "Args" or "Arguments" for the struct field into which we unmarshal. If c.Values is non-empty and no Args field is found, an error is created. The other way around (c.Values is empty but Args exists) is not an error. Args must be a scalar (string, int, float64, …) or a slice of scalars ([]string, []int, []float64, …)

[]struct{} (slice of structs)
c is unmarshalled into a struct and appended to the slice.
“Should this be each of c.Children is unmarshalled as a struct and appended to the slice?”No, I don't think so. Basically do the above to convert to a struct, but then also append to the slice. The c.Children are handled recursively, i.e. they may be scalars, too.

[]string, []float64, []bool, …
c.Children must be empty. Each c.Values[i] is unmarshalled and appended to the slice.
LGTM

string, float64, bool, … (slice of scalars)
c.Children must be empty, c.Values must have length 1.
“Do we want to support coercion to string type for Number and Bool values?”Didn't think this through, but my gut feeling is not to, because it destroys type safety. After field tags have been implemented, we might add tags for "port number" (automatically converting "http" to 80) and the like.“Do we want to support coercion to the various number types for Number values?”I'd say yes, convert everything where Type.ConvertibleTo returns true.

chan
unsupported for now.
ACK

pointer
dereferenced and treated as above.
LGTM

encoding.TextUnmarshalers
Fallback only if concrete types above are not matched. Error if configValueType != configTypeString.Used only for string values. The ConfigUnmarshaler interface takes precedence. Returns result of UnmarshalText.
Sounds like a great idea! Throwing an error if a type implements a specific interface is not helpful and potentially very annoying.

I think PR comments work best to discuss concrete code. If that works for you, too, I'd like to stick to Github for that.
Thanks for all you hard work!
—octo

Closing in favor of #63, which has been merged today.