text:
Parallel RFI filtering

In its current implementation, the RFI Filter step of the daily pipeline takes ~25 minutes. Most of this time is spent taking a rolling median, and it is done in a single process. This PR should address the issue by pre-calculating a median across frequencies to flatten the auto vis. data, then distributing across the frequency axis to distribute the computation across processes.

Although the products aren't quite right yet, this reduces the RFIFilter step down to ~15 seconds in a daily pipeline run

Depends on radiocosmology/caput#210

Depends on radiocosmology/caput#211

I've confirmed that this is working, running a full daily pipeline test to make sure there are no surprises and/or the data products don't get changed.

@jrs65 this produces the same mask now as previous revisions, so it should be good to go unless there are additional changes.


text:
Update Pages “about”

Automatically generated by Netlify CMS

👷 Deploy Preview for nuxt-decap-cms processing.

Name
Link

🔨 Latest commit
62753e27e5cc4de6c372da4b69461f7715d7f904

🔍 Latest deploy log
https://app.netlify.com/sites/nuxt-decap-cms/deploys/66730476e477b4000862a6c5

source: gharchive/pull-request

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 RSSinn小黑屋(主站) is down

In 5698bf3, RSSinn小黑屋(主站) (https://rssinn.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RSSinn小黑屋(主站) is back up in ce355ea.

source: gharchive/issue

repo: chinobing/upptime-rssinn


text:
Update the FAQ and add doc on versioning

Contributor Checklist

[NA] Did you add Scaladoc to every public function/method?
[NA] Did you add at least one test demonstrating the PR?
[NA] Did you delete any extraneous printlns/debugging code?
[x] Did you specify the type of improvement?
[x] Did you add appropriate documentation in docs/src?
[x] Did you state the API impact?
[x] Did you specify the code generation impact?
[x] Did you request a desired merge strategy?
[x] Did you add text to be included in the Release Notes for this change?

Type of Improvement

documentation

API Impact
No impact
Backend Code Generation Impact
No impact
Desired Merge Strategy

Squash

Release Notes

Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (3.2.x, 3.3.x, 3.4.0, 3.5.0) ?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you mark as Please Merge?

Nice! I have only looked at the raw view but content is good. Haven't checked how the table looks rendered

realized in all my refactoring I didn't actually fix https://github.com/freechipsproject/www.chisel-lang.org/issues/102 ... now this does. 🤦♀

Nice! I have only looked at the raw view but content is good. Haven't checked how the table looks rendered

You can view it in the diff: https://github.com/chipsalliance/chisel3/pull/1827/files?short_path=6959c6b#diff-6959c6be40448c233181770b98e858bacebc4a359abc27d6d06526aaaa30f23b

I am happy to approve this but I don't actually know how to properly apply the labels and such


text:
Symbiflow-classroom: Older style parameter declarations not supported

SYMBIFLOW-CLASSROOM-PROJECT
In SystemVerilog a parameter to a module can be define in one of two ways:
module riscv_mem #(parameter TEXT_MEMORY_FILENAME) (clk, rst, PC, , ...);

as well as:
module riscv_mem (clk, rst, PC, , ...);
    parameter TEXT_MEMORY_FILENAME;
    ...

The first way (the newer way) is not supported.

@mithro @acomodi @tmichalak @mkurc-ant Would be interested in any feedback you can provide.

Could you specify which tool are you trying to run and with what options? I.e. for Yosys with UHDM plugin, we have tests that cover both first and second way and both of them are supported.
If you could also provide the error output that you're seeing and a minimal complete example to reproduce, that would be really helpful.

Using original Yosys front end.

@rkapuscik Can you clarify something for us?  In our mind there are two ways to run the toolchain.  The first is the "out of the box" install which we have interpreted as being the Yosys front end (thus my answer above).  The other way we understand is Surelog+UHDM front end.  You mention Yosys with UHDM, is this a third way or is this the first way I mentioned in my response?  Thanks.

You're right. There are two main ways - original Yosys Verilog frontend and UHDM plugin frontend. Yosys with UHDM plugin is the same as Yosys with Surelog+UHDM.
One detail here is that the plugin enables two flows:

reading UHDM file created separately by using Surelog (read_uhdm command)
reading Verilog and SystemVerilog files directly, using Surelog inside the plugin as a library (and not creating a separate UHDM file, just an in-memory representation). This is done by read_verilog_with_uhdm command.

As a side note, UHDM is just an implementation detail and we are renaming the command in 2. to just read_systemverilog (see https://github.com/SymbiFlow/yosys-f4pga-plugins/pull/270), but both of the commands above will be kept for backwards compatibility.

I have done some re-testing and this does seem to work with Yosys.  I don't know if it was because the distribution was behind on Yosys (which we discovered with other issues), maybe that was the issue.  But it is working now so, I believe it can be closed.

authors: nelsobe rkapuscik


text:
Onboard Chisel as graduated project

@hcook is on this.

Chisel is already a sandbox project, but we need it to be graduated, as it's already a CHIPS project in all but the formal status.

@hcook ping!

This is being worked on in #136

repo: chipsalliance/tsc


text:
Disable kythe CI for now as it started failing w/o apparent reason.

Needs to be debugged separately. Disable for now to not shadow
other potential 'real' issues.

Codecov Report

Merging #1410 (3bcd4f0) into master (bebdb64) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1410   +/-   ##
=======================================
  Coverage   92.92%   92.92%
=======================================
  Files         340      340
  Lines       23848    23848
=======================================
  Hits        22161    22161
  Misses       1687     1687

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: codecov-commenter hzeller

repo: chipsalliance/verible

license_source: bigquery


text:
Random Mint

When somebody use my mint button i want him to receive a random NFT from this transaction.
When i use mint button (mintAmount = 2) my NFT's metadata's will be like,
ipfs://image_link/1.json
ipfs://image_link/2.json
But i dont want this. I want to receive my NFT's randomly. Like this,
ipfs://image_link/578.json
ipfs://image_link/877.json
I hope i was clear. How can i do that and can this process increase gas fees?

Just randomize the data off-chain before you store it on ipfs.

I did but everyone can see my ipfs link. So you can take my ipfs link and see what's next NFT when you use mint button. (I dont wanna use surprise box method)

The easy way is to upload to IPFS after everyone has finish minting.
Other options:

Use a centralized server to reveal on the fly (make sure you check that they are not querying a unminted tokenId), and then migrate the data to IPFS after mint has finalized.
Do all the trait randomization on-chain with Chainlink VRF.

Anyway, randomization of minting/traits is not in the scope of ERC721A.

authors: Vectorized justChargin


text:
Add payable gas optimization

Based on https://eips.ethereum.org/EIPS/eip-721, the following functions can be made payable.

safeTransferFrom
transferFrom
approve

Saves 24 gas for transferFrom.
Oh, poll here: https://twitter.com/optimizoor/status/1563757003809648640
A potential use case is for paid pull-based transfers.
Tbh, this isn't for royalties (anyone can do the trick described in https://twitter.com/optimizoor/status/1563806550971412480 to "enforce" royalties way more effectively via sheer inconvenience).

I think this makes sense. This follows the EIP and accommodates royalties. Also save that sweet sweet gas.


text:
你好，请问支持m3u8播放吗？

你好，请问支持m3u8播放吗？

试过了  不支持  也不支持 rtmp

repo: chiruom/DanmuPlayer

license: mit


text:
Add tensor_view function and show usage in 2D-1 benchmark example.

As discussed today I have written a generic function that takes vector and index as well as tensor rank and dimension to construct a matching view.
@pjaap FYI

Unfortunately, I see lots of allocations in the kernel of Example245 again when using the tensorviews. My guess is, that the compiler has difficulties to infer the return type of the tensorview? I get no allocations when I define a separate function for each rank case, e.g. scalar_view, vector_view, matrix_view.

Another thing we should discuss is where the documentation for the helper functions would fit best.
We should probably explain usage both in at least one example and the documentations for BilinearOperator and NonlinearOperator

Instead of Val{k} one could also define abstract types like TScalar, TVector, TMatrix, TRank3, TRank4 (all subtypes of <: TensorType) etc. and use them for dispatch. One could even put the dimensions into the type, i.e., use TVector{3} or TMatrix{2,2} and then use, e.g., tensorview(input, 3, TMatrix{2,2})...
Concerning the documentation, I agree. The NonlinearOperator already has an example at the end of the page for which one could add the new possibility. Another example for the BilinearOperator would be good, too. We will think about that when the rest is sorted out.

Had similar situations where I worked with wrapper structs:
Enabled Sparspak for dual numbers by implementing tailored BLAS routines:

https://github.com/PetrKryslUCSD/Sparspak.jl/blob/main/src/Utilities/GenericBlasLapackFragments.jl
The problem here is that the Sparspak code uses incompletely allocated arrays (inherited from dirty fortran tricks)

Local kernel callback routines in VoronoiFVM:

https://github.com/j-fu/VoronoiFVM.jl/blob/efced035d65304acf842e5c4c1a61ad17a17af84/src/vfvm_geometryitems.jl#L87

Added TensorDescription, updated tensor_view and added documentation for everything new.
@Da-Be-Ru FYI

looks good to me now, are we ready to merge?

From my point of view, yes

authors: chmerdon j-fu jpthiele


text:
Disabled input-group still opens the calendar

Hello!
Sometimes the date input is disabled so the user can't type on it, or open the calendar popup to select a date.
But there is a problem when using input-group with a disabled input, because the "data-toggle" or "data-open" will still open the calendar popup, even if the "data-input" has a "disabled" attribute.
Would be possible to not open the calendar popup through data-toggle or data-open, if the data-input has a disabled attribute?
I tried intercepting the click event on the data-toggle element, and calling preventDefault(), but it did not work, because flatpickr toggle event was fired first. I also tried removing the "data-toggle" attribute after the input was disabled, but even after that the calendar was still being called.
Best regards,
Rafael Pacheco.

Thank you for the report.
Disabled inputs shouldn't have calendars.
Fix coming in the next release, soon.

Fixed in latest release

authors: chmln rafael-renan-pacheco

repo: chmln/flatpickr


text:
Bring over Python 3.x minor version packages from Jack's repository

Description
This PR moves Python 3.x minor version packages from my repository as this has been suggested during a review of those on the Chocolatey Community Repository.
So far, I've only copied over the packages and updated it according to this repository's guidelines as I haven't yet been informed what I have to do to get it accepted here.
Some open questions:

When uploading these packages, I was also aiming to create a python3.9 package but as it later turned out, the name is already taken, sort of. There's actually not a single version of the package listed as the only uploaded version was fully rejected by the automatic review process yesterday. Should I be pursuing this package name through some process or is this something that you can take care of?
Looking at the current python3 Chocolatey package, I imagine I would have to add support for things that this package supports and that my package currently don't such as:

package parameters that python3 package supports
installation location folder lockdown
Maybe something else?

Should I put contents of update.ps1 scripts in some common location to avoid duplication or do I not need to concern myself with that?
The packages are currently in review so it is still possible to update them. Do I need to do anything special so that these packages get pushed with the same version number when you merge this PR or is it something that you would take care of?

Motivation and Context
It's been suggested to me by @gep13 to move my packages for Python 3.x minor versions in their review:
https://community.chocolatey.org/packages/python3.7/3.7.9#versionhistory
My words on why I think it is necessary to have a package per each minor version of Python can be found there as well.
How Has this Been Tested?
Tested using packages generated with $au_Force = $au_WhatIf = $true; ./update.ps1 in the package folder and then tested locally (installation, uninstallation, running some simple code in installed Python's REPL, verifying that created shims work) in chocolatey-test-environment. The AU scripts have also been run in AppVeyor's Windows environment which is where the currently reviewed versions of packages were uploaded from.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[x] My change requires a change to documentation (this usually means the notes in the description of a package).
[x] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[x] I have updated the package description and it is less than 4000 characters.
[x] All files are up to date with the latest Contributing Guidelines
[x] The added/modified package passed install/uninstall in the chocolatey test environment.
[ ] The changes only affect a single package (not including meta package).

Original Location

Original Repository
No Open Issues

This is a brand new package currently in review so there are no open issues.

[ ] Include the link to the opened PR that removes the package from the original location

Haven't made one yet, it sort of feels a bit early considering that this has only really been talked about in the Chocolatey package review.

[x] The migration guidelines have been followed

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

Seems like CI is mistakenly treating generated packages as versions of python3 rather than versions of respective python3.x packages which makes it fail due to trying to install a x.3.x.y.z version of python3 package rather than 3.x.y.z version of python3.x package.

Looking at the code, this is a very good start for this.
While there is nothing in the code itself that is wrong, there is a lot of duplication with more or less the exact same code.
I think this is a very good candidate to be part of streams, instead of having a distinct package for every versions (the id of the package can be changed by setting PackageName in the return hashtable).
Would this be something you would be able to change?
If not, we can get this merged into a temporary branch until we have completed that work.
With the naming of the packages though, we should avoid using dots in the package name, and in my opinion it would be better if the package name would be python36, python37, etc.
Thoughts on this @JPRuskin @pauby

I'll try switching it to streams soon, maybe later today or tomorrow.
I'll keep the package names as is until agreement on that is reaches if that's okay.

I'll try switching it to streams soon, maybe later today or tomorrow.
I'll keep the package names as is until agreement on that is reaches if that's okay.

Sure thing, keep the names as it is for now. When we decide which names to use, and if it is updated to use streams, it will be quite easy to change them later.

With the naming of the packages though, we should avoid using dots in the package name, and in my opinion it would be better if the package name would be python36, python37, etc.

I would agree. A dot should only be used if it matches one of the known package types (.extension, .powershell, .portable, .install, etc.).

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

With the naming of the packages though, we should avoid using dots in the package name, and in my opinion it would be better if the package name would be python36, python37, etc.

At the moment, the current exceptions to not having dots in the name are these:

To add a postfix to signify that a package is a specific type, like .install, .extension, etc.
If the software name itself contains a dot, the example given is paint.net
For when the package ID contains a major+minor version. Examples are netfx-4.8,dotnet-3.1-runtime, and lots of other dotnet packages.

Given that python3.minorversion fits the last case, I'm personally fine with having the dot to seperate the major and minor version.
I generally would prefer to have the dot, because then it differentiates what is the major version part and what is the minor version part. Say for python v3.10.x, if the package ID python310 was used, it is not clear if that is refering to python v30.0.x, or v3.10.x or even v310.0.x. The package title and/or version is often visable at the same time and allow someone to figure out the notation used (like in the CCR webpage), but sometimes may take more work to find (such as a non-verbose list/search on the CLI).
Or for another example, given the rate of dotnet releases, dotnet 11 is only a cople of years away, and once that happens, if there is a package named dotnet-11-runtime, it would not be clear if that is dotnet v11.x or dotnet v1.1.x, assuming the policy would be that major and minor versions in the package id should not be seperated by a dot.

:white_check_mark: Package verification completed without issues. PR is now pending human review

:white_check_mark: Package verification completed without issues. PR is now pending human review

I agree with TheCakeIsNaOH's reasoning and some of these reasons were why I chose to use the dot in the name. Debian-based distros use the same convention which may make it more familiar to some users though there are also distros that don't use dots for minor Python version packages (e.g. Fedora-based).
Anyhow, I've made significant progress towards moving this to streams, there are still some small changes I need to make before it's ready (notably, au is hanging on search & replace when processing a second stream, probably because of LICENSE.txt update, I'll try switching that to full overwrite of the file instead of a regex matching whole file contents) + I need to test it out in chocolatey VM to confirm that it's working as intended but most of the work on the code is done I would say. Moving this to a stream in python3 also means that the package parameters from python3 which I didn't add are now available as well. I did end up using package name without dots after moving it to streams but I will change it back if you agree that the package name with a dot is superior :)

:white_check_mark: Package verification completed without issues. PR is now pending human review

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:white_check_mark: Package verification completed without issues. PR is now pending human review

:white_check_mark: Package verification completed without issues. PR is now pending human review

For when the package ID contains a major+minor version. Examples are netfx-4.8,dotnet-3.1-runtime, and lots of other dotnet packages.

And neither of those packages is maintained in this repository, we have stricter rules and a few differences when comparing against the Chocolatey Community Repository.
Do note that the netfx-* naming is primarily due to historical reasons with other versions (not sure about the dotnet packages, most likely an oversight when the initial version was pushed).
After talking about it a bit with @pauby internally, we have come to the agreement that we do not accept using a . in the name for the version as this goes against the naming style referred to in the Chocolatey Documentation (https://docs.chocolatey.org/en-us/create/create-packages#naming-your-package), that there are existing packages that violate this does not change the matter in this repository.
However, as an alternative, we can accept using dashes - to separate the major and minor versions, but not the dots.

as this goes against the naming style referred to in the Chocolatey Documentation

In response to the automated review on the chocolatey community repository, I argued that 3.8 is part of the software name but I guess it's a rather weak point. The only other point I made for this name is that the naming style in Chocolatey documentation tells you to use the same package id as popular Linux distributions if they already have a package of it and this is the package id in Debian-based distros. This is just reiterating my points from that review so I don't really expect your decision to change here.

However, as an alternative, we can accept using dashes - to separate the major and minor versions, but not the dots.

I think I would prefer to not use a separator in that case. I know this goes against TheCakeIsNaOH's argument that this is making it harder to figure out the version but I think that it's more important to use a naming scheme that will be more natural to the users. I don't think I've seen any package that would use - for version separator and there are plenty of distros that use the python3x naming scheme already which would definitely make it more natural to those people as well as make it easier to just guess the name in general in comparison to python3-x.

So unless someone wants to argue really hard for python3-x name, I think this means that there's no open question for this PR anymore and it is ready for review.

:white_check_mark: Package verification completed without issues. PR is now pending human review

The only other point I made for this name is that the naming style in Chocolatey documentation tells you to use the same package id as popular Linux distributions if they already have a package of it and this is the package id in Debian-based distros.

While it is true that the documentation says to use the same package id as popular Linux distributions, remember that Debian isn't the only popular distros.
Additionally, there are so much inconsistency between linux distros to actually honor this part of the documentation (even among popular distros).
Some distros use dot separated, others doesn't separate and several doesn't even offer major+minor packages .
All in all, the decision won't be changed.
I have noticed you updated the PR, and have it on my TODO list to do another review on this PR on Monday (unfortunately won't have time until then).

I don't think I've seen any package that would use - for version separator and there are plenty of distros that use the python3x naming scheme already which would definitely make it more natural to those people as well as make it easier to just guess the name in general in comparison to python3-x.

It is true that no other packages I am aware of uses dashes as a version separator, that suggestion was mainly given as an option while still honoring the the naming guidelines, and separating major and minor version.
To be honest though, whether a separator is used or not doesn't really matter to me, as long as the package id does not use dots in it.

All in all, the decision won't be changed.
I have noticed you updated the PR, and have it on my TODO list to do another review on this PR on Monday (unfortunately won't have time until then).

@AdmiringWorm ping in case you forgot. If you just haven't had time to look at this, ignore me :smile:

@AdmiringWorm ping in case you forgot. If you just haven't had time to look at this, ignore me 😄

I still have this PR on my TODO list, but unfortunately haven't had the time yet. I plan to look at this PR tomorrow if nothing else prevents me.

Additionally, the thought is to make the python3 package a meta package that depends on the major+minor versions of the packages.
As such, it would be best to have the streams themself as part of a different package (directory), say for instance move it to a python3-streams directory, but leave the python3 package itself as is, or source the update.ps1 file in the streams directory. (See 7zip.install and 7zip as an example.)

Alright, I'll try to work on that tomorrow. One problem related to this is that I'm not sure that Test-RepoPackage will work properly with python3x packages being generated by a package named python3-streams, i.e. see the supported cases in the "How Has This Been Tested?" section in #2015 and we'll probably have to decide how to change the logic to work with those kinds of packages as well.

Alright, I'll try to work on that tomorrow. One problem related to this is that I'm not sure that Test-RepoPackage will work properly with python3x packages being generated by a package named python3-streams, i.e. see the supported cases in the "How Has This Been Tested?" section in #2015 and we'll probably have to decide how to change the logic to work with those kinds of packages as well.

While the Test-RepoPackage may not work properly with the python3-streams, it is a known issue with the helper script as it doesn't really have a knowledge about streams at all.
However, I would say feel free to ignore any failures from that script right now. It has been on my TODO list for a few years now to get it sorted, but never had time to do it unfortunately.
Also, feel free to ignore creating the python3 meta package, that is something I would like to be pushed after we have at least one version of the python3x package approved by moderators. We also need to let people know on that package that there will be changes (for instance, passing in package arguments and install arguments won't work anymore since they will not be passed down from the meta package to the python3x packages), and recommend them to directly install the major+minor versions that they want instead.
Bottom line, if you can move to the python3-streams directory, and remove the pushing of the python3 package itself this can be considered complete.

Alright, I'll try to work on that tomorrow.

Welp, that didn't work out... I should get to this some time in the second half of this week as I'm rather busy in the first half. In the meantime, thanks for the additional clarifications, it seems clear to me what I have to do now.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:white_check_mark: Package verification completed without issues. PR is now pending human review

@AdmiringWorm I think I addressed everything that you requested. Commits are a bit of a mess, I can split the changes out between them better if it were to make your review easier.
I also went ahead and reverted #2015 in this PR because it causes tests for pkgname-streams packages to fail entirely and it is no longer necessary now that this PR no longer tries to use python3.x as the package naming scheme.

:white_check_mark: Package verification completed without issues. PR is now pending human review

:white_check_mark: Package verification completed without issues. PR is now pending human review

@Jackenmen your changes have been merged, thanks for your contribution 👍. Great work.
Before merging I updated the PR to move the python3 package to a meta package, and temporarily disabled python and python3 updates (until we at least have 3.11 sub version available).
Just to be sure that we don't need to change too many packages once it they gets looked at by moderators, I also limited the amount of packages that will be pushed to the first 2 versions found (at this time that is 3.12 and 3.11). That should be removed once we have the first version approved.

Looks like the replacement of python3x was done somewhat incorrectly here, PackageSourceUrl and choco install command on description are incorrect :/ I thought I checked, maybe I didn't account for something.

The open question that remains is what the package names should be, current state of this PR has python311, without a dot rather than python3.11. I personally prefer the variant with the dot.

python311 (without a dot) is a good convention because the default install directory for this minor version is also C:\Python311 .
chocolatey upgrade overwrites the directory and does not remove it. Therefore, a parallel installation of several minor versions is possible and can only be prevented manually (cuninst and cinst again instead of cup). With own package names for minor versions this becomes more obvious.

authors: AdmiringWorm AppVeyorBot Jackenmen TheCakeIsNaOH jack1142 karig pauby


text:
(#63) Add Newly-Required Dependency of dotnet4-sdk to CCM Setup

Fixes #63
Added install of dotnetcore-sdk V 3.1.410 from the CCR to the C4bCcmSetup.ps1. Reason for this is in CCM DB 0.6.2+ this is listed as a dependency.
Also added comment explaining reasoning behind why we install the other packages in this section as well.

Apologies, @ryanrichter94. On further reflection, it would be better if we could internalize this dependency as a part of the initial Start-C4bSetup.ps1 bootstrap script. That way, it's available for the CCM script to utilize. This also keeps us more closely aligned with the CCM setup docs.
Hope that makes sense. I'll close out this PR for now.

repo: chocolatey/choco-quickstart-scripts


text:
Add docking tests and logger implementation

Description
The current docking protocol is prone to difficult debugging. This is to implement some options to help with debugging.
Related to #181
Todos
Notable points that this PR has either accomplished or will accomplish.

[ ]

Questions

[ ] Question1

Status

[ ] Ready to go

Codecov Report

Merging #192 (68cff5a) into main (47eb0a3) will not change coverage.
The diff coverage is n/a.

@apayne97 I have added the start of a test harness in test_docking.py this should be able to be adapted to your needs. :)

@hmacdope I kinda think we should leave further improvements of the unit tests to a future. I don't really have the bandwidth to make new changes on that right now and would like to get these improved logging options added

authors: apayne97 codecov-commenter hmacdope

repo: choderalab/asapdiscovery


text:
Extend TopologyProposal with convenience methods to retrieve atoms being deleted and atoms being created

Perhaps we should make TopologyProposal a real class, since we could then define convenience methods that use new_to_old_atom_map along with old_topology and new_topology to return the lists of atoms being deleted or created.  This would be helpful for creating alchemically modified systems without having to recompute these lists.

I think this is a good idea. It might also make the proposal classes cleaner.

Do you want to take a stab at this?

Yep! Sounds good!

I'll make this the next PR after fixing the test failures.

Based on #22 and the discussion there, I've implemented a full class version of the TopologyProposal. I can open a PR now, though it will require a bit of a refactor to make the tests work (since the constructor is now different).

Go for it!

Implemented in #27

authors: jchodera pgrinaway

repo: choderalab/perses


text:
Quick update to html_strip_tags

html_strip_tags now allows a custom linebreak character, just in case someone needs one. If none is provided it defaults to \n.

wouldn't it make more sense for the parameter's default value to just be "\n" rather than checking in the function body if it's None?

<value> = <default> if <value> == None else <value>

is habitual for me; you're welcome to change it if it makes it more readable for you. :)


text:
Add index.html

adding and changes index.html

changes done

repo: chrajeshdagur/intro-html


text:
Added docker compose setup and instructions

Thought this might make it even easier for people that use compose.

I'll test before merge, but it seems fine!
Thanks!

Oops, might want to update the default mount path - make build try and pull any existing weights files into the image...

I'll test before merge, but it looks great!
Thanks!

Had a convo about this tonight, going to catch the fork up to base and then look at testing/working on this.

authors: ElRoberto538 c-s-ale chris-alexiuk

repo: chris-alexiuk/alpaca-lora


text:
How do I serve static files

I apologize in advance for this newbie question ...

serves up static files with grace and aplomb (and also appropriate mimetypes)

How do I do this?  I don't see any option for static paths.  This is my set of options I'm using now...
http.createServer(beefy(
  entries: '/client-app': 'client/app.coffee'
  cwd: __dirname
  live: true
  quiet: false
  bundlerFlags: [
    '-o', "bundle.js"
    "-t", "coffeeify"
    "--extension", ".coffee"
  ]
)).listen 1340

Never mind.  I was using the wrong directory to serve from.

repo: chrisdickinson/beefy


text:
Contravariant functors

My understanding of all the Holey business only scratches the surface, so I can't be sure. I have an instinctive feeling that it makes a contravariant functor and a divisible from the "contravariant" package. Have you explored this?

It looks contravarianty, but I'm not sure exactly how.

Closing so I have zero issues.

authors: chrisdone nikita-volkov

repo: chrisdone/formatting


text:
Allow ".." in path where possible

The parsing functions do not allow .. in path at all. I believe it is because of the need of directory lookup for normalization of the path. But that is not always the case, in some cases we can normalize the path without any dir lookup even if it has ".." components.
In case of absolute paths we can always resolve a ".." component without directory lookup:
* /.. == /
* /a/.. == /
* /a/b/.. == /a
* /a/b/../c == /a/c

For relative paths some, but not all, ".." can be eliminated without dir lookup. If not all of them can be eliminated we can disallow the path:
* .. or ../a=> not allowed
* a/.. => not allowed
* a/b/.. == a
* a/b/../.. => not allowed

As a rule, if the total number of ".." upto the last ".." in the path are more than or equal to all other preceding path components then the path is not allowed.

I missed the symlink case - http://neilmitchell.blogspot.in/2015/10/filepaths-are-subtle-symlinks-are-hard.html . This won't work in case of symlinks.

repo: chrisdone/path


text:
Cluster and locking support

Wondering if this driver has cluster/lock support?

I don't think cluster support is there at the moment, which is a main showstopper for me at this point, but I'm not 100% sure as I haven't reviewed the code for some time. Main page says the following, so I think the support isn't there:

Implemented a simple distributed lock on top of Mongo to help with future cluster support based on ideas shared here.

I use it in a cluster and it seems to work for me. Have you tried it in
your scenario ?
On Thu, Aug 9, 2018 at 8:55 AM David Mumladze notifications@github.com
wrote:

I don't think cluster support is there at the moment, which is a main
showstopper for me at this point, but I'm not 100% sure as I haven't
reviewed the code for some time. Main page says the following, so I think
the support isn't there:
Implemented a simple distributed lock on top of Mongo to help with future
cluster support based on ideas shared here.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/chrisdrobison/mongodb-quartz-net/issues/12#issuecomment-411807286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABu24Ql8v9trFqGmDWopwZK3Aj4n5f_9ks5uPFt1gaJpZM4VxeQR
.

@chrisdrobison Will give it a try and ping back. Thanks.

authors: chrisdrobison dmumladze gsmith2409

repo: chrisdrobison/mongodb-quartz-net


text:
[refactoring] pull all colours in style sheet to variables

(a) to be DRY
(b) to support color schemes in the future

as far as possible, find the colours from the comfy css definitions

#213

repo: chrisgoringe/cg-controller


text:
[Bug]: gx-script prints stdout and stderr to buffer where the link was opened

Bug Description
If I try to open a link with the gx-script on linux with firefox the stdout and stderr from firefox gets printed into the buffer right where the cursor is placed over the link. The link gets opened in firefox successfully though.
Relevant Screenshot

To Reproduce

Open nvim
Paste a link (ex. https://github.com/chrisgrieser/nvim-various-textobjs)
gx with cursor placed over link

neovim version
0.8.3

Make sure you have done the following

[X] I have updated to the latest version of the plugin.

Redirecting it to /dev/null helps: os.execute(opener .. " '" .. url .. "' > /dev/null 2>&1"). Don't know if this would work on Windows.

Weird. Can't test since I am not on Linux.
Nevertheless, since piping to dev-null cannot hurt, I just added that

>/dev/null 2>&1 is preferable to &>/dev/null because &>/dev/null is bashism (but I think also understood by zsh). Users may run another shell than bash which does not understand this syntax. I for example use bash only as my interactive shell but link /bin/sh to dash which is strictly POSIX-compliant (I think on Ubuntu /bin/sh is also linked by default to dash). With &>/dev/null some parts of stderr are still printed into my buffer after opening a link with gx. Using >/dev/null 2>&1 fixes it.

authors: astier chrisgrieser

repo: chrisgrieser/nvim-various-textobjs


text:
sorting subcommands

I don't see any option to sort subcommands in the actions menu. Currently the functions are ordered randomly:
https://cloud.githubusercontent.com/assets/1408720/7950189/4411b824-0965-11e5-905a-3a2b5df0efb3.jpg

Fixed!
You were right on the randomness. Those fields on the left were populated from a dictionary, which has no respect for ordering. Now fixed.
Thanks for the report!

authors: chriskiehl umeshghosh

repo: chriskiehl/Gooey


text:
Invalid URI for NameNode address (check fs.defaultFS): seaweedfs://localhost:8888 is not of scheme 'hdfs'.

my sys is mac, Hadoop 3.3.0 , SeaweedFS version 30GB 2.22 2c5eac5 darwin amd64,
I strictly follow  https://github.com/chrislusf/seaweedfs/wiki/Hadoop-Compatible-File-System
and run ./start-dfs.sh
i get ，，ERROR: Cannot set priority of namenode process 18823
see log ，，，  /usr/local/Cellar/hadoop/3.3.0/libexec/logs，details ：
Invalid URI for NameNode address (check fs.defaultFS): seaweedfs://localhost:8888 is not of scheme 'hdfs'.
tks for helping me

similar to https://stackoverflow.com/questions/57229947/invalid-uri-for-namenode-address-s3a-is-not-of-schema-hdfs
You do not need to start name nodes.

repo: chrislusf/seaweedfs


text:
Unexpected response to s3 GET call on non-existent bucket

Describe the bug
Running a "GET /nonexistent-bucket?acl" - which is what a number of libraries use for "does this bucket exist" call, returns a ListBucketResult. According to S3 api docs, it should return a 'AccessControlPolicy' or at least a 404 for the nonexistent resource.
System Setup
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
nneul@optic:~ $ curl http://localhost:8333/nonexistent-bucket?acl
<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Name>nonexistent-bucket</Name><Prefix></Prefix><Marker></Marker><MaxKeys>10000</MaxKeys><IsTruncated>false</IsTruncated></ListBucketResult>

Expected behavior
AccessControlPolicy in response - even if it's a dummy/empty policy document, or a 404 or other error indicating it couldn't handle the request due to the bucket not being there.

I think the underlying cause is that it's ignoring the ?acl - however, even with that, it shouldn't return the bucket in the ListBucketResult if it's not there.

should it return 501 "Not Implemented"?

I'm not sure... I think that's going to be driven more on interaction with how people are using it -- i.e. would it be better to have a stubbed/dummy response, or error out. I'm not an expert on the library/api usage in this case.
I suspect that a dummy response is probably going to yield better application compatibility, but it also might open up a can of worms for how much you have to support to be "correct".
In this specific case (one of my clients) - it's being used with the library to check 'does the bucket exist' to trigger other setup/creation/deletion/etc. -- so for it, having it semi-ignore the acl request and return the 404 would be better, but then it still leaves the question of what should be returned when the bucket does exist.

I'd suggest since the resource specified in the path of the GET request does not exist that a 404 response code accompanied by a NoSuchBucket error code in the response body would achieve the behavior most consistent with the S3 protocol.
In the event that the resource does exist, then at that point any parameters/attributes present in the request (like acl) which are unsupported could produce the 501 code.

Added a fix to return 404 if bucket does not exist.

authors: Dougems chrislusf nneul


text:
Compose external className

Hey!
I'm super excited about this! Having spent the last year diving deep into multiple styling approaches, this seems very promising - at a glance.
For now I have one question, I'd like to create a component with some baked in className but I also want to accept a class from the outside.
For example:
const Button = React.forwardRef<
  HTMLButtonElement,
  React.ComponentPropsWithRef<"button">
>((props, ref) => {
  return (
    <button
      ref={ref}
      className={css.compose(
        css.color("red500"),
        css.fontSize(5),
        props.className || ""
      )}
      {...props}
    />
  );
});

export default function App() {
  return (
    <div className="App">
      <Button className={css.color("blue500")}>Test</Button>
    </div>
  );
}

What I've tried to do is to just inject props.className into css.compose function - but seems Im going about it the wrong way.
What's happening is that the className I passed in works, but the previous baked in classes are gone. I expect to see a button with font size of 5 and blue. But it's just blue.
Would I need to use something like classnames?

Ah, turns out it works but I was spreading the props in the wrong place 😂

This doesn't seem to work for me. I don't know if it's a Next issue or not but I get these errors
TypeError: cannot use 'in' operator to search for "atoms" in "MyComponent"

composeIntoMap
./node_modules/@stitches/css/es/index.js:53

  50 | var item = atoms[i];
  51 | // atoms can be undefined, null, false or '' using ternary like
  52 | // expressions with the properties
> 53 | if (item && "atoms" in item) {
  54 | ^    composeIntoMap(map, item.atoms);
  55 | }
  56 | else if (item) {

compose
./node_modules/@stitches/css/es/index.js:117

  114 |     atoms[_i] = arguments[_i];
  115 | }
  116 | var map = new Map();
> 117 | composeIntoMap(map, atoms);
  118 | return {
  119 |     atoms: Array.from(map.values()),
  120 |     toString: toStringCompose,

I just call it like this className={css.compose(css.color('red'), props.className)}. Can't really see what should be wrong.

@peduarte How did you make this work? I want to use it like className={css.compose(css.color('red'), props.className)} for example but it blows up. Would be really nice if compose could be made to work with this so we don't have to use the classnames package.

My issue was that I was spreading props {...props} after className, so it was essentially overriding the classes

authors: lauritzsh peduarte

repo: christianalfoni/stitches


text:
SecurityError when doing SSR with Next.js

Hi!
I ran into an issue when I tried to use stitches with Next.js. Here are the steps to reproduce:

install the stitches-css starter from the Next.js examples
try to load an external stylesheet by adding the following code to _document.js:

  import Document, { Html, Head, Main, NextScript } from "next/document";
  ...

  render() {
    return (
      <Html>
        <Head>
          <link
            href="https://fonts.googleapis.com/css2?family=Roboto&display=swap"
            rel="stylesheet"
          />
        </Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }

get the following error (in Chrome):

SecurityError: Failed to execute 'insertRule' on 'CSSStyleSheet': Cannot access StyleSheet to insertRule
createCss
./node_modules/@stitches/css/es/index.js:183

It looks like something like this is the problem - maybe the insertRule order is off when there's already existing stylesheets?

Im pretty sure this was fixed in the latest release. Which version you on?

Yep you're right @peduarte, the version in the Next.js was 3.0.2, once I upgraded it to 5.0.0 the problem went away. Thanks!

authors: biowaffeln peduarte


text:
Use path-to-regexp lib to match paths

This is the same lib used by express and page, so should have had a lot of real world testing.
Also included in this commit is support for '*' catch all routes.
Tests have been updated to prove the changes.

@garth looks great to me! I totally agree with using a well tested, robust package for this, as my implementation was limited and only handled basic cases. Thank you! I'm looking forward to using it!
I'll leave it to @christianalfoni to merge though.

Great stuff, just let me test this with the Cerebral-Router when I get home and I will release new version :-)
I think we could also release a new version of reactive-router using addressbar and url-mapper. As that is something other people can use with other flux implementations.

authors: bfitch christianalfoni garth

repo: christianalfoni/url-mapper


text:
[Bug]:  list indices must be integers or slices, not str

What happened?
I have chroma 0.4.4 running on a remote server in docker
i'm using the chroma httpClient (also from 0.4.4)
I can get collections
but when i create a collection i get this error
client.create_collection(name="X")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In [145], line 1
----> 1 client.create_collection(name="X")

File /opt/conda/lib/python3.9/site-packages/chromadb/api/fastapi.py:92, in FastAPI.create_collection(self, name, metadata, embedding_function, get_or_create)
     88 raise_chroma_error(resp)
     89 resp_json = resp.json()
     90 return Collection(
     91     client=self,
---> 92     id=resp_json["id"],
     93     name=resp_json["name"],
     94     embedding_function=embedding_function,
     95     metadata=resp_json["metadata"],
     96 )

TypeError: list indices must be integers or slices, not str

when using the fastApi from the server to create a collection, it works, i guess it's the way you handle the response
{
  "name": "X,
  "id": "f21cb31c-ab5b-4805-ad4e-de74af79d822",
  "metadata": null
}

Versions
0.4.4
python > 3.9
Relevant log output
No response

I am not sure how you are getting this, could you share a repro script if you don't mind?
Traceback (most recent call last):
File "", line 1, in
File "/Users/hammad/Documents/chroma/chromadb/api/fastapi.py", line 88, in create_collection
raise_chroma_error(resp)
File "/Users/hammad/Documents/chroma/chromadb/api/fastapi.py", line 385, in raise_chroma_error
raise (Exception(resp.text))
Exception: {"error":"ValueError('Expected collection name that (1) contains 3-63 characters, (2) starts and ends with an alphanumeric character, (3) otherwise contains only alphanumeric characters, underscores or hyphens (-), (4) contains no two consecutive periods (..) and (5) is not a valid IPv4 address, got X')"}
This is what I get for
client.create_collection(name="X")
For anything that conforms to the allowed names, it works just fine for me.

I'm all good for the moment, thanks

i should not have provided you with the example value X (i removed my real name which was longer)
i figured out the reason is that my remote server is https so i had not enabled ssl = True. The weird thing here is that using http (ssl =  False) (which get's redirected by our sever internally to https, returned an array with the list of all collections . So it passed the raise_chroma_server check (as status was OK) , but the resp.json() and retrieving the ID raised the error above (as the json response was an array.) Not that this is important but maybe one day you could check to ensure the response is of type what you expect and also not sure why the response was the list of collections. (maybe the server turned the Post into a Get ?)
so I solved it by setting ssl = True

Thanks

authors: HammadB huineng

repo: chroma-core/chroma


text:
Add AVIF image output support

Making this PR in anticipation of libheif/libvips adding the AV1 encoder to their mainstream binaries, it currently requires a custom built version of libvips to get working, also requires you override the compression method with 'av1' because the default is 'hevc' so browsers wont decode it.
TODO: Add new tags containing AVIF links to tests.

@googlebot I signed it!

repo: chromeos/static-site-scaffold-modules


text:
dump_tensorflow_weights.py with error

i run the following command :python3 dump_tensorflow_weights.py
and get this error:
Traceback (most recent call last):
File "dump_tensorflow_weights.py", line 95, in
tmp = caffe_weights.reshape(boxes, -1).copy()
TypeError: 'float' object cannot be interpreted as an integer
i fix it by change the code at line 71
if output_name.find('BoxEncodingPredictor') != -1:
boxes = caffe_weights.shape[0] / 4
elif output_name.find('ClassPredictor') != -1:
boxes = caffe_weights.shape[0] / 91
to
if output_name.find('BoxEncodingPredictor') != -1:
boxes = caffe_weights.shape[0] // 4
elif output_name.find('ClassPredictor') != -1:
boxes = caffe_weights.shape[0] // 91
and i wonder if  it is ok  or not ?

it ok!
this script is write by python2, if you use python3,should change '/' to '//'

File "dump_tensorflow_weights.py", line 77, in
tmp = caffe_weights.reshape(boxes, -1).copy()
ValueError: cannot reshape array of size 31104 into shape (0,newaxis)

@he-chen Thank you very much, I have merged your code to my project.


text:
Incomplete results from upstream repositories

It seems like latest updates from upstream repositories are available, e.g. if you search for set you don’t get all results from https://github.com/tldr-pages/tldr/blob/master/pages/common/set.md. Is this something that needs to be run manually?

In my case they are identical. Could you please check if you still have the problem or not?

Yes, still getting same problem. Can’t see result for set -e, or when searching for stdout I don’t get most recent changes from https://github.com/cheat/cheatsheets/blob/master/stdout and they were merged recently.
Is this some caching issue?

It should be possible to show git revision of the deployed version and also revisions on the cheat sheets at http://cht.sh/

My bad, there was a bug indeed. Not it should be fixed, please test.
I've manually triggered the update, so now all the upstream repos should be up-to-date.
The repos updated automatically each hour. So if the fix was successful, upstream changes should be visible after one hour max.
@abitrolly I agree; something like /:revs or /:reps with all upstream repositories descriptions and their revisions would be ideal.

Added reminder for /:sheets endpoint https://github.com/chubin/cheat.sh/issues/337

authors: abitrolly chubin niksy


text:
Accuracy drop on pole mounted view images

@chufengt  i tested the pre-trained model on eye-level captured videos/images and the results are acceptable but with little change, in the camera view ie pole-mounted view images the accuracy drops considerably through RAP dataset has surveillance images captured at the pole-mounted view, is re-training the only approach to get the best accuracy ??

It seems the generalization between different scenarios is not good.
I think re-training on your custom dataset may work better.


text:
Use preserve_quotes = True in ruamel.yaml

Would it be possible to add preserve_quotes = True or make it possible to configure the value in the configuration? More info on the flag here:
https://stackoverflow.com/questions/39262556/preserve-quotes-and-also-add-data-with-quotes-in-ruamel
In my case, without this flag the first changes to dbt_project.yml modifies all the lines about source-paths, macro-paths etc... removing the quotes. Not a big deal but the git history just becomes less clean that way.

Done in 0.1.18

authors: b-per ciejer


text:
fails to install with stackage lts-3.0 / ghc 7.10

This package looks useful, thanks. stack install failed for me:
$ stack install htoml
unbounded-delays-0.1.0.9: configure
logict-0.6.0.2: download
regex-tdfa-rc-1.1.8.3: download
unbounded-delays-0.1.0.9: build
logict-0.6.0.2: configure
logict-0.6.0.2: build
regex-tdfa-rc-1.1.8.3: configure
unbounded-delays-0.1.0.9: install
regex-tdfa-rc-1.1.8.3: build
logict-0.6.0.2: install
smallcheck-1.1.1: download
smallcheck-1.1.1: configure
smallcheck-1.1.1: build
smallcheck-1.1.1: install
regex-tdfa-rc-1.1.8.3: install
tasty-0.10.1.2: download
tasty-0.10.1.2: configure
tasty-0.10.1.2: build
tasty-0.10.1.2: install
tasty-hunit-0.9.2: download
tasty-hunit-0.9.2: configure
tasty-quickcheck-0.8.3.2: download
tasty-smallcheck-0.8.0.1: download
tasty-hunit-0.9.2: build
tasty-quickcheck-0.8.3.2: configure
tasty-hunit-0.9.2: install
tasty-quickcheck-0.8.3.2: build
tasty-smallcheck-0.8.0.1: configure
tasty-smallcheck-0.8.0.1: build
tasty-quickcheck-0.8.3.2: install
tasty-smallcheck-0.8.0.1: install
tasty-hspec-1.1: download
tasty-hspec-1.1: configure
tasty-hspec-1.1: build
tasty-hspec-1.1: install
htoml-0.1.0.2: download
htoml-0.1.0.2: configure
htoml-0.1.0.2: build
Completed all 10 actions.

--  While building package htoml-0.1.0.2 using:
      /Users/simon/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-osx-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/ build --ghc-options  -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1
    Logs have been written to: /Users/simon/src/hledger/.stack-work/logs/htoml-0.1.0.2.log

    Configuring htoml-0.1.0.2...
    Building htoml-0.1.0.2...
    Preprocessing library htoml-0.1.0.2...
    [1 of 3] Compiling Text.Toml.Types  ( src/Text/Toml/Types.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Text/Toml/Types.o )
    [2 of 3] Compiling Text.Toml.Parser ( src/Text/Toml/Parser.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Text/Toml/Parser.o )

    src/Text/Toml/Parser.hs:83:5:
        Non type-variable argument in the constraint: Stream s m Char
        (Use FlexibleContexts to permit this)
        When checking that ‘twoChar’ has the inferred type
          twoChar :: forall s u (m :: * -> *).
                     Stream s m Char =>
                     Char -> ParsecT s u m [Char]
        In an equation for ‘tableArrayHeader’:
            tableArrayHeader
              = between (twoChar '[') (twoChar ']') headerValue
              where
                  twoChar c = count 2 (char c)

    src/Text/Toml/Parser.hs:177:25:
        Couldn't match expected type ‘time-1.5.0.1:Data.Time.Format.Locale.TimeLocale’
                    with actual type ‘System.Locale.TimeLocale’
        NB: ‘time-1.5.0.1:Data.Time.Format.Locale.TimeLocale’
              is defined in ‘Data.Time.Format.Locale’ in package ‘time-1.5.0.1’
            ‘System.Locale.TimeLocale’
              is defined in ‘System.Locale’ in package ‘old-locale-1.0.0.7’
        In the first argument of ‘parseTime’, namely ‘defaultTimeLocale’
        In the expression:
          parseTime defaultTimeLocale (iso8601DateFormat $ Just "%X") d

Just ran into the same thing.  It looks like master fixes this.  To work around this using stack I:
Forked this version: https://github.com/HuwCampbell/htoml.
Made a dir in my project called "forks"
Cloned my fork into it.
Merged the toml4 branch into master
Added 'forks/toml' to the packages list in stack.yaml
Building works.  I haven't tested it throrougly enough to say if anything is broken but it seems to be handling my simple use cases.

@cies any chance of a hackage upload for 0.1.0.3?

Sorry guys for not replying earlier. I totally must have forgotten about the 0.1.0.3 release, I'll upload it to Hackage soon.
I'm also much interested in bringing the changes of @HuwCampbell back into master. @HuwCampbell, could you please elaborate on the state of your toml4 branch?

Hackage upload is done: https://hackage.haskell.org/package/htoml

thanks @cies!

authors: cgag cies simonmichael thumphries

repo: cies/htoml


text:
fix: refactored arrayElement and added separate iterator overloads for optimization

refactored arrayElement to randomElement and weightedArrayElement to weightedRandomElement, and sortedSizeArrayElement to sortedSizeRandomElement
Added optimizations to randomElement to support all types of iterators, optimized overloads for random_access, forward_iterator, and input_iterator.

If you'd like me to add some inline documentation since this code is kinda hard to read I can

repo: cieslarmichal/faker-cxx


text:
correzioni generali

effettuato da terminal il comando: git push --set-upstream https://github.com/ciguiro/leopardo dev
creo la pull request perche sono in dev

faccio il merge delle due versioni del progetto

repo: ciguiro/leopardo

license: Unlicense


text:
add ca.crt to TLS Secrets

This PR ensure that all the Secrets containing a TLS keypair are of kubernetes.io/tls type. This brings consistency with respect to how we generate certificates with certgen and Helm.
Besides honoring the required tls.key and tls.crt keys, we also consistently add ca.crt to theses Secrets (see https://github.com/cilium/cilium/pull/15443 for context).
Finally, use the newly added ca.crt for both Hubble and Relay. This allow compatibility with cert-manager.
After this PR we could consider a --generate-certificates=false flag preventing certificate generation from the CLI. Users could then use cert-manager go generate the TLS Secrets since the deployments are using the TLS Secrets in a compatible way.

Marking as draft until https://github.com/cilium/cilium/pull/15443 is merged, but this PR is ready for review.

Marking as ready to review as https://github.com/cilium/cilium/pull/15443 has been merged.

This PR seems to break installation of Cilium on kind (maybe others). When using cilium install on a kind cluster with 2 nodes the installation gets stuck at:
cilium install
🔮 Auto-detected Kubernetes kind: kind
✨ Running "kind" validation checks
✅ Detected kind version "0.10.0"
ℹ  Cilium version not set, using default version "v1.9.6"
🔮 Auto-detected cluster name: kind-kind
🔮 Auto-detected IPAM mode: kubernetes
🔮 Auto-detected datapath mode: tunnel
🔑 Generating CA...
2021/04/30 12:32:41 [INFO] generate received request
2021/04/30 12:32:41 [INFO] received CSR
2021/04/30 12:32:41 [INFO] generating key: ecdsa-256
2021/04/30 12:32:41 [INFO] encoded CSR
2021/04/30 12:32:41 [INFO] signed certificate with serial number 341950654555647912224012010248856335904663509460
🔑 Generating certificates for Hubble...
2021/04/30 12:32:41 [INFO] generate received request
2021/04/30 12:32:41 [INFO] received CSR
2021/04/30 12:32:41 [INFO] generating key: ecdsa-256
2021/04/30 12:32:41 [INFO] encoded CSR
2021/04/30 12:32:41 [INFO] signed certificate with serial number 650073862086065741661726551118996732934131520777
🚀 Creating Service accounts...
🚀 Creating Cluster roles...
🚀 Creating ConfigMap...
🚀 Creating Agent DaemonSet...
🚀 Creating Operator Deployment...
⌛ Waiting for Cilium to be installed...

Until it eventually times out. The Cilium pods seem stuck in Init state with kubectl -n kube-system describe pod ... showing:
[...]
Events:
  Type     Reason       Age                From               Message
  ----     ------       ----               ----               -------
  Normal   Scheduled    94s                default-scheduler  Successfully assigned kube-system/cilium-9mkxv to kind-control-plane
  Warning  FailedMount  30s (x8 over 94s)  kubelet            MountVolume.SetUp failed for volume "hubble-tls" : references non-existent secret key: ca.crt

Not sure whether that's related. CI also seems to fail on kind for latest master.
/cc @kaworu @tgraf

@tklauser I've missed one instance reported by @jrajahalme during the review, thank you for reporting this! Can you try https://github.com/cilium/cilium-cli/pull/200 please?

Thanks @kaworu, works fine in my local tests.

authors: kaworu tklauser

repo: cilium/cilium-cli


text:
sysdump: Collect also init container logs

Previously we only collected regular container logs, but missed the init
container logs. Gather these as well, they can be useful for debugging.

aks failure expected from forked repos

Multicluster failure is not expected, gke cluster creation failed 😐
btw looks like cilium command isn't there, cilium sysdump command failed to run. i guess @nbusseneau 's suspicion was right. cc @bmcustodio
https://github.com/cilium/cilium-cli/pull/414/checks?check_run_id=3032486960#step:16:48

btw looks like cilium command isn't there, cilium sysdump command failed to run. i guess @nbusseneau 's suspicion was right. cc @bmcustodio

Not sure what you're referring to but in this instance it's expected that cilium is not there because the cluster did not even start. Since we run the command in-cluster, there was not time to set that up :D

The following actions are failing:

AKS - Failed because I submitted the PR from a separate fork
External Workloads - Failed due to the "Missing or incomplete configuration info."

kubectl logs --timestamps -n kube-system job/cilium-cli-install
shell: /usr/bin/bash -e ***0***
...
error: Missing or incomplete configuration info.  Please point to an existing, complete config file:```

GKE - Failed a connectivity check by the looks

Test report says:2021-07-09T20:57:46.525388447Z 📋 Test Report
2021-07-09T20:57:46.525503713Z ❌ 1/9 tests failed (0/74 actions), 0 tests skipped, 0 scenarios skipped:
2021-07-09T20:57:46.525590033Z Test [dns-only]:
2021-07-09T20:57:46.525875565Z
2021-07-09T20:57:46.525901701Z Error: Connectivity test failed: 1 tests failed
error: cannot exec into a container in a completed pod; current phase is Failed
...
/home/runner/work/_temp/d5b10418-40fb-4e1d-9c33-5f27c4d98078.sh: line 4: cilium: command not found
Error: Process completed with exit code 127.

The only string matches for "failed" or "dns-only" or ❌ in the "Post-test installation logs" section of the action output are this on and one outside the logs. Despite reporting that there was a test failure, I can't find the failure itself.
Only other odd thing is that the CLI container is crashing:kube-system   cilium-cli-ckwld                                                 0/1     Error     0          15m   10.168.15.215   gke-cilium-cilium-cli-10-default-pool-f2d20591-55n8   <none>           <none>

Upload artifacts failed with:Warning: No files were found with the provided path: cilium-sysdump-out.zip. No artifacts will be uploaded.

Multicluster - Failed provisioning due to invalid argument:

ERROR: (gcloud.container.clusters.create) Operation [<Operation
clusterConditions: [<StatusCondition
canonicalCode: CanonicalCodeValueValuesEnum(INVALID_ARGUMENT, 3)
message: 'The network "default" does not have available private IP space in 10.0.0.0/9 to reserve a /14 block for pods for
cluster ***Zone=us-west2-a, ProjectNum=185287498374, ProjectName=***, ClusterName=cilium-cilium-cli-1016427082-mesh-1, ClusterHash=e186c3abb89943bdaf240e0b6aad55b993854d496a384d0dbe801fe7c4c858c5***.'>]```

How do we proceed?

How do we proceed?

Thanks for the detailed analysis @joestringer!
The Multicluster and the External Workloads failures look like some sort of temporary infrastructure issues to me. For the GKE workflow we lack a sysdump which would allow further investigation. Given that, I'd propose to rebase this PR onto latest master, now that #423 and #426 are merged. These should restore sysdump creation on workflow failure/cancellation and would give us at least a sysdump for the failing GKE workflow, in case it turns out not to be a flake.

Agree with Tobias, only blocking flake was the GKE one, but lacking a sysdump it's kinda hard to know which one it was :/

The only failing test is on AKS, which is expected as this PR was opened from a fork.
Merging, thanks!

authors: joestringer michi-covalent nbusseneau tklauser


text:
kind support M1

Proposal / RFE
kind should be supported in M1 Mac.
Is your feature request related to a problem?
follow the instruct here: https://docs.cilium.io/en/v1.10/gettingstarted/kind/
and leads to :
kube-system          cilium-ldtw9                                   0/1     CrashLoopBackOff    124        18h

check the log:
level=fatal msg="BPF NodePort services needs kernel 4.17.0 or newer." subsys=daemon

check kernel:
docker exec -ti cilium-worker /bin/bash
root@cilium-worker:/# uname -a
Linux cilium-worker 5.10.47-linuxkit #1 SMP PREEMPT Sat Jul 3 21:50:16 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

the kernel is 5.10.47 and higher than 4.17.0.
anything I can do manually to make all this work?
other background info
recheck the config:
cat kind-config.yml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker
networking:
  disableDefaultCNI: true

see containers:
docker ps
CONTAINER ID   IMAGE                  COMMAND                  CREATED        STATUS          PORTS                       NAMES
2e875f18a029   kindest/node:v1.21.1   "/usr/local/bin/entr…"   19 hours ago   Up 58 minutes   127.0.0.1:53490->6443/tcp   cilium-control-plane
635046d89c60   kindest/node:v1.21.1   "/usr/local/bin/entr…"   19 hours ago   Up 58 minutes                               cilium-worker3
55b2428e74d6   kindest/node:v1.21.1   "/usr/local/bin/entr…"   19 hours ago   Up 58 minutes                               cilium-worker
c222db8e2c7e   kindest/node:v1.21.1   "/usr/local/bin/entr…"   19 hours ago   Up 58 minutes                               cilium-worker2

docker version:
docker version
Client:
 Cloud integration: v1.0.20
 Version:           20.10.10
 API version:       1.41
 Go version:        go1.16.9
 Git commit:        b485636
 Built:             Mon Oct 25 07:43:15 2021
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.10
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.9
  Git commit:       e2f740d
  Built:            Mon Oct 25 07:41:10 2021
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.4.11
  GitCommit:        5b46e404f6b9f661a205e28d59c982d3634148f8
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Describe the solution you'd like
is the kind image node missing some bpf tools or settings or files?
should we mention it in the doc or QA?

level=fatal msg="BPF NodePort services needs kernel 4.17.0 or newer." subsys=daemon

That's probably because the kernel is missing config CONFIG_CGROUP_BPF. You can work around that by disabling kube-proxy-replacement.

thanks for answering.
can I manually add that config?
I wish to experience as many features of cilium as possible.

Yes, but you'll need to recompile the kernel.

so we should ask for the docker team to support this?
Recompiling the kernel seems too heavy for end users like us.
and I don't know how to for desktop docker either.

I don't know where Kind gets their kernel image, but yes, you could try to ask for that config to be enabled in the image.
I'll close this issue given it's not a bug in Cilium and the original question has been answered. Feel free to ask if you have any other questions regarding Cilium.

authors: adamzhoul pchaigno

repo: cilium/cilium


text:
CI: ClusterMesh: curl: (28) Resolving timed out after 2000 milliseconds

CI failure
[.] Action [to-entities-world/pod-to-world/http-to-google.com-0: cilium-test/client-6965d549d5-cflp6 (10.242.1.35) -> google.com-http (google.com:80)]
  ❌ command "curl -w %{local_ip}:%{local_port} -> %{remote_ip}:%{remote_port} = %{response_code} --silent --fail --show-error --output /dev/null --connect-timeout 2 --max-time 10 --retry 3 --retry-all-errors --retry-delay 3 [http://google.com:80](http://google.com/)" failed: command failed: curl: (28) Resolving timed out after 2000 milliseconds

  ℹ  curl output:

  📄 No flows recorded for peer cilium-test/client-6[96](https://github.com/cilium/cilium/actions/runs/4975949770/jobs/8903597823#step:21:97)5d549d5-cflp6 during action http-to-google.com-0
  📄 No flows recorded for peer google.com-http during action http-to-google.com-0

📋 Test Report
❌ 1/41 tests failed (1/272 actions), 9 tests skipped, 1 scenarios skipped:
Test [to-entities-world]:
  ❌ to-entities-world/pod-to-world/http-to-google.com-0: cilium-test/client-6965d549d5-cflp6 (10.242.1.35) -> google.com-http (google.com:80)

Link: https://github.com/cilium/cilium/actions/runs/4975949770
Sysdump: cilium-sysdumps-8.zip

Hit on https://github.com/cilium/cilium/pull/23219.

authors: YutaroHayakawa qmonnet


text:
datapath: Use iproute2+libbpf

See commit msgs.
Fix https://github.com/cilium/cilium/issues/16757
Use iproute2 with libbpf for loading datapath BPF programs

test-me-please

test-1.16-netnext

test-1.19-5.4

test-1.20-4.19

test-1.21-4.9

test-runtime

test-me-please

test-me-please

test-me-please

test-me-please

test-1.21-4.9

test-me-please

test-1.21-4.9

test-1.21-4.9

test-1.21-4.9

test-1.21-4.9

test-1.21-4.9

test-me-please

test-me-please

CI failures:

test-1.16-netnext - https://github.com/cilium/cilium/issues/16399 which we are currently investigating.
ci-awscni - It should be fixed by https://github.com/cilium/cilium/pull/17122.
ci-eks - It is currently unstable.

FYI, I was surprised verifier-test.sh didn't need an update for the cgroup programs, but then discovered we skip those programs in that script by error. I filed https://github.com/cilium/cilium/issues/17125 for it.

release-note/minor is to help inform users about changes that impact them. As far as I know this should not have any user-facing impact. Should this be release-note/misc instead?

authors: brb joestringer pchaigno


text:
vendor: pull in the latest changes from github.com/vishvananda/netlink

Includes fix for broken compilation on mac OS -
https://github.com/vishvananda/netlink/pull/730 while running ginkgo tests locally.

Looks like the Go lint checks didn't run. Closing and re-opening the PR trying to trigger them.

Fixed the vendor miss. Will monitor the Go link check.

/test

ci-gke failure -

"http:///var/run/cilium/cilium.sock/v1/healthz": dial unix /var/run/cilium/cilium.sock: connect: no such file or directory

Not sure where the issue is coming from since I see this log in both the cilium agent pods -

"Serving cilium health API at unix:///var/run/cilium/health.sock" subsys=health-server

GKE test didn't start -

from server for: "/home/jenkins/workspace/Cilium-PR-K8s-GKE@3/src/github.com/cilium/cilium/test/k8sT/manifests/demo_ds.yaml": Get "https://35.247.115.94/api/v1/namespaces/202201271704k8sdatapathconfigmonitoraggregationchecksthatmonito/services/test-external-ips": dial tcp 35.247.115.94:443: connect: connection refused

ci-gke

test-gke

/ci-gke

/test-gke

test-runtime failure -
Wasn't able to reproduce it locally (ran all the unit tests in pkg/datapath/linux), snippet for the failed test -
PASS: node_linux_test.go:129: linuxPrivilegedIPv6OnlyTestSuite.TearDownTest     0.120s

PASS: node_linux_test.go:973: linuxPrivilegedIPv6OnlyTestSuite.TestArpPingHandling      107.153s

/test-runtime

/ci-l4lb

Re-run of runtime was successful - https://jenkins.cilium.io/job/Cilium-PR-Runtime-net-next/1152/. Let's run it one more time as a sanity check.

/test-runtime

Marked for backport on 1.11 and 1.10 to be able to run Ginkgo test from macOS also for backports.

authors: aditighag glibsm jrajahalme tklauser


text:
ingress: Set max stream duration as 0

Description
This commit is to set maxStreamOption for both http and http2 in route
level, mainly for gRPC API.
Signed-off-by: Tam Mach tam.mach@isovalent.com
Testing
Testing was done locally with hubble-ui ingress, connection drop was no longer
happening.

[x] Conformance test was also done locally.

Just for those curious, what does it mean for this value to be 0 and why is it useful to configure this? Does Envoy otherwise terminate connections that live longer than some period?

Just for those curious, what does it mean for this value to be 0 and why is it useful to configure this? Does Envoy otherwise terminate connections that live longer than some period?

The max stream duration is the maximum time that a stream’s lifetime will span. If the value is 0, the stream duration managed by http connection manager can last indefinitely, kindly note that it's still bound by stream idle timeout (i.e. the idle stream will get closed eventually). Without this value configured, the stream connection will get closed every 15~ based on default value from envoy.
This was identified during internal testing, however similar symptom can be found in this screen shot https://cilium.slack.com/archives/C02QKQDTVDX/p1650469843731669.

/test

hit flake for test-1.23-net-next, marking ready for review

authors: joestringer sayboras


text:
[v1.14] Revert "Add support for --hubble-redact=http-url-query"

See https://github.com/cilium/cilium/issues/23887#issuecomment-1645784815 for motivation. We've determined we should create a a more flexible configuration scheme for redaction of http headers, so instead of shipping the current solution which isn't very flexible, revert it, and we'll ship in the next release with the more flexible configuration scheme.
This PR reverts 2/3 of the commits in https://github.com/cilium/cilium/pull/25746. I left the 1 commit which fixed an issue where a URL object was being mutated in some existing redaction code.

/test

/test-backport-1.14

authors: chancez joestringer


text:
Update USERS.md - add Gcore info on supporting Cilium

Updated USERS.md - added Gcore with Cilium support in Gcore Managed Kubernetes Service
Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.
[x] Are you a user of Cilium? Please add yourself to the Users doc
[x] Thanks for contributing!

Updated USERS.md - added Gcore with Cilium support in Gcore Managed Kubernetes Service
Signed-off-by: Romuald Zdebskiy zdebskiy@hotmail.com

:wave: please fix up the signed-off-by in your patch description, so that it matches https://github.com/cilium/cilium/actions/runs/8550085730/job/23427479546?pr=31763#step:3:41. The email address needs to be wrapped in <...>.

/test

authors: julianwiedmann rzdebskiy


text:
Unit test conflicting states xfrm

Please ensure your pull request adheres to the following guidelines:

[ ] For first time contributors, read Submitting a pull request
[ ] All code is covered by unit and/or runtime tests where feasible.
[ ] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[ ] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[ ] All commits are signed off. See the section Developer’s Certificate of Origin
[ ] Provide a title or release-note blurb suitable for the release notes.
[ ] Are you a user of Cilium? Please add yourself to the Users doc
[ ] Thanks for contributing!

Fixes: #issue-number
<!-- Enter the release note text here if needed or remove this section! -->

/ci-runtime

/ci-runtime

/ci-runtime

/ci-runtime

/ci-runtime

/ci-runtime

/ci-runtime

/ci-runtime


text:
[v1.15] author backport: helm: fix envoy prometheus metrics scraping with servicemonitor

[ ] #34448 (@mhofstetter) :warning: resolved conflicts

Once this PR is merged, a GitHub action will update the labels of these PRs:
 34448

/test-backport-1.15


text:
daemon: fixing cilium deadlock

When cilium was being used with kubernetes, the endpoint RLock was
called while the endpoint's Lock was already held. By calling
UpdatePolicyEnforcement with the lock held, it is not necessary use the
RLock inside this function.
Signed-off-by: André Martins andre@cilium.io

Needs rebase with #841 so tests won't fail


text:
🛑 CHPL Remote Databases / EZProxy is down

In b85e59f, CHPL Remote Databases / EZProxy (https://login.research.cincinnatilibrary.org/login) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CHPL Remote Databases / EZProxy is back up in 410cbfe.

repo: cincinnatilibrary/uptime-reports


text:
⚠ Cioos Pacific CKAN has degraded performance

In cd3ba9e, Cioos Pacific CKAN (https://catalogue.cioospacific.ca) experienced degraded performance:

HTTP code: 200
Response time: 10778 ms

Resolved: Cioos Pacific CKAN performance has improved in 2ad1b6a after 5 minutes.

repo: cioos-siooc/cwatch-upptime


text:
Published but not available data examples

Give examples of data (underlying a publication) for which you would like to have an access and why.

Raw actigraphy data from ABCD study for visualisations of the activity patterns


text:
Update discipline-scalatest to 2.1.4

Updates org.typelevel:discipline-scalatest from 2.1.3 to 2.1.4.
GitHub Release Notes - Changelog - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel", artifactId = "discipline-scalatest" } ]

labels: test-library-update, semver-patch

Codecov Report

Merging #179 (0e375c3) into master (db3df5c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #179   +/-   ##
=======================================
  Coverage   37.80%   37.80%
=======================================
  Files           3        3
  Lines          82       82
=======================================
  Hits           31       31
  Misses         51       51

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 db3df5c...0e375c3. Read the comment docs.

Superseded by #188.

authors: codecov-commenter scala-steward

repo: circe/circe-optics


text:
Make a "create Json" function in Json that accepts field-Json pairs and an existing Json

Let me begin by first saying thank you for this wonderful library.
My company recently switched from Jackson to Circe. Of course, one of the changes we want to minimize is the amount of code that has to be changed as part of this process.
What I currently plan to do is to write custom encoders and decoders for all of our traits so that they will be handled in the same way they were handled by Jackson.
One thing that would help others with this transition process from Jackson to Circe is if there was a function that created a Json class, given an already existing Json class and a String-Json pair. A generalization of the function would accept arbitrary numbers of String-Json pairs to append or prepend to the fields in an already existing Json class.
The reason for this is that Jackson handles serialization of traits by adding an extra field in the JSON to indicate what the subclass is. Circe, in contrast, by default puts this information in a fieldName and nests the JSON under that field name.
Here is an example.
trait Num{
  def valueAsDouble: Double
}
case class NaturalNumber(value: Int) extends Num {
  def valueAsDouble: Double = value
}
case class RationalNumber(value: Double) extends Num {
  def valueAsDouble: Double = value
}
case class SomeNumbers(value1: NaturalNumber, value2: RationalNumber)

Circe would parse SomeNumbers(NaturalNumber(1), RationalNumber(1.1)) as
{
  "value1": {
    "NaturalNumber": {
      "value": 1
    }
  },
  "value2": {
    "RationalNumber": {
      "value": 1.1
    }
  }
}

while Jackson would parse it as
{
  "value1": {
    "numberType": "NaturalNumber",
    "value": 1
  },
  "value2": {
    "numberType": "RationalNumber",
    "value": 1.1
  }
}

where the field numberType is specified by the user to distinguish the various subclasses of Num from each other.
What I am suggesting is that there be a function that would allow you to prepend or append an arbitrary number of fields to an existing Json class. That would allow the user to introduce the "numberType" field in the above example without having to write excessively long encoders and decoders for the entire subclass. A simple function call would prepend or append the desired fields to a Json class. It would probably be located in the Json object in io.Circe.
Even if someone implements the above function, it will not be implemented in time for me to use it. I plan to write the custom encoders and decoders by hand. However, for other people down the line, this could make the transition much smoother.

I would like to add that a prepend function would allow the user to prepend a field that describes the subclass of a trait.
Appending a function could be used to append evaluated functions to the JSON.
So for the previous example,
trait Num{
  def valueAsDouble: Double
}
case class NaturalNumber(value: Int) extends Num {
  def valueAsDouble: Double = value
}

it would be nice to be able to have an easy way to have NaturalNumber(1) be parsed as
{
  "numberType": "NaturalNumber",
  "value": 1,
  "valueAsDouble": 1
}

Here the numberType field was prepended to the JSON, and the valueAsDouble field was appended to the JSON. The automatic encoders and decoders do not create these fields, so it would be nice to have an easy way to attach them to an existing Json class to create a JSON.

Trying to figure out something slight different but a few things to help:

Recommend Circe Generic Extras for: deriveUnwrappedCodec
Decoder.prepare(acursor => acursor.up) which will move the cursor to the enclosing JsonObject.

And more directly to your point, On Encoder .mapJson (Encoder.AsObject .mapJsonObject) allows you to easily add fields. e.g.
  implicit val encoder: Encoder.AsObject[Fooo] =
      deriveConfiguredEncoder[Fooo].mapJsonObject(_.add("Bar", "Open".asJson))

Regarding the prepare Decoder, I am just working with that now. This works:
Given:
{
    "a" : "TestA",
    "workday" : 123,
    "c" : {
        "workday" : 666
    }
}

case class Fooo(a: String, c: Either[Int, String])
object Fooo {
implicit val config: Configuration = Configuration.default
implicit val encoder: Encoder.AsObject[Fooo] = deriveConfiguredEncoder[Fooo]
implicit val ee: Encoder.AsObject[Either[Int, String]] = Encoder.encodeEither[Int, String]("workday", "weekday")

implicit val dd: Decoder[Either[Int, String]] =
  Decoder.decodeEither[Int, String]("workday", "weekday").prepare(_.up)

implicit val decoder: Decoder[Fooo] = deriveConfiguredDecoder[Fooo]

}

Note: .prepare(_.up).   The cursor normally starts at the JsonObject in field 'c'
Moving up places the cursor in the enclosing JsonObject.

logger.info(s"Decoded ${json.as[Fooo]} \n ${json.spaces4}")

Gives:

 Decoded Right(Fooo(TestA,Left(123)))
 {
    "a" : "TestA",
    "workday" : 123,
    "c" : {
        "workday" : 666
    }
}

Without the prepare it would given 666.

Given all the great stuff (sometimes hidden) in Circe... I may try to document this!

Since I have the Either in *tons* of classes I am trying to figure out a better way to do the encoder with .mapJsonObject on the Fooo encoder to lift the fields, e.g.

def liftAllFields(toAddField: String, in: JsonObject): JsonObject = {
in(toAddField).flatMap(_.asObject) match {
case None      => in
case Some(obj) => JsonObject.fromIterable(obj.toVector ++ in.remove(toAddField).toVector)
}
}
deriveConfiguredEncoder[Fooo].mapJsonObject(liftAllFields("c")

There appears to be no solution that just involves making changes to
val ee: Encoder.AsObject[Either[Int, String]]

I think the easiest way to get the functionality I am talking about is to use the deepMerge function in sealed abstract class Json.
Here is an example, where I try to add "classType" field too Foo. The idea is to encode the MasterFoo trait and to add the "classType" field to the subtype's JSON.
import io.circe._
import io.circe.generic.extras.semiauto._

trait MasterFoo

object MasterFoo {
  import Foo._

  implicit val masterfooEncoder: Encoder[MasterFoo] = new Encoder[MasterFoo]{
    override def apply(a: MasterFoo): Json = {
      a match {
        case f: Foo =>
          val defaultEncoder = implicitly[Encoder[Foo]]
          val mergeMe = Json.obj(("classType", "Foo"))
          defaultEncoder.apply(f).deepMerge(mergeMe)
      }
    }
  }
}

case class Foo(count: Int) extends MasterFoo

object Foo {
  implicit val fooEncoder: Encoder[Foo] = deriveConfiguredEncoder
}

authors: allenjhan odenzo

repo: circe/circe


text:
Update scalafmt-core to 3.5.0

Updates org.scalameta:scalafmt-core from 3.4.3 to 3.5.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Codecov Report

Merging #1935 (fb1c1f9) into main (7d83746) will increase coverage by 0.28%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1935      +/-   ##
==========================================
+ Coverage   85.85%   86.13%   +0.28%
==========================================
  Files          69       69
  Lines        2488     2503      +15
  Branches      129      132       +3
==========================================
+ Hits         2136     2156      +20
+ Misses        352      347       -5

Impacted Files
Coverage Δ

...es/core/shared/src/main/scala/io/circe/Error.scala
61.76% <0.00%> (-1.40%)
:arrow_down:

...core/shared/src/main/scala/io/circe/CursorOp.scala
54.16% <0.00%> (-1.39%)
:arrow_down:

...nter/src/main/scala/io/circe/pointer/Pointer.scala
89.34% <0.00%> (-0.13%)
:arrow_down:

.../core/shared/src/main/scala/io/circe/Decoder.scala
83.37% <0.00%> (-0.05%)
:arrow_down:

.../src/main/scala-2/io/circe/EnumerationCodecs.scala
100.00% <0.00%> (ø)

...rc/main/scala-2/io/circe/EnumerationDecoders.scala
100.00% <0.00%> (ø)

.../main/scala-2.12/io/circe/CollectionDecoders.scala

...rc/main/scala-2.12/io/circe/FactoryInstances.scala

...in/scala/io/circe/pointer/PointerSyntaxError.scala

...d/src/main/scala-2.12/io/circe/CompatBuilder.scala

... and 6 more

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 7d83746...fb1c1f9. Read the comment docs.


text:
Create READMEV2

@kamelkev
New README.md file specific to the Oracle input plugin for where an Oracle database is deployed on a Windows Host.

@kamelkev You can delete the 2 existing versions along with the oracle_metrics.sh file in the folder.

LGTM

repo: circonus-labs/circonus-unified-agent


text:
Fix the Handful of AAD unit tests that are broken

🗣 Description
Modified the 4 AAD unit tests that were not working - shortest description ever -- !
Closes #1018
💭 Motivation and context
Things should not be broken.
🧪 Testing

✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] PR targets the correct parent branch (e.g., main or release-name) for merge.
[x] Changes are limited to a single goal - eschew scope creep!
[x] Changes are sized such that they do not touch excessive number of files.
[x] All future TODOs are captured in issues, which are referenced in code comments.
[x] These code changes follow the ScubaGear content style guide.
[x] Related issues these changes resolve are linked preferably via closing keywords.
[x] All relevant type-of-change labels added.
[x] All relevant project fields are set.
[x] All relevant repo and/or project documentation updated to reflect these changes.
[x] Unit tests added/updated to cover PowerShell and Rego changes.
[x] Functional tests added/updated to cover PowerShell and Rego changes.
[x] All relevant functional tests passed.
[ ] All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

[ ] PR passed smoke test check.

[ ] Feature branch has been rebased against changes from parent branch, as needed
Use Rebase branch button below or use this reference to rebase from the command line.

[ ] Resolved all merge conflicts on branch

[ ] Notified merge coordinator that PR is ready for merge via comment mention

✅ Post-merge checklist

[ ] Feature branch deleted after merge to clean up repository.
[ ] Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

@tkol2022 Note, to resolve Regal "line too long" annotated warnings (see in files changed view) you can either:

Find a way to break the string into multiple lines such as using concat() and splitting the string into an array of strings with each substring on its own line, OR
If the string really needs to be that long and better exists as a single unbroken string, decorate it with a comment above the line to exempt it from Regal evaluation for that test with # regal ignore:line-length.

It seems like this Regal warning is coming for more lines than just the ones which Ted has changed, it might possibly be better to ignore the line-length for the entire file if possible. If not then this would require changing more lines.

@nanda-katikaneni this PR is now ready to merge, thanks!

repo: cisagov/ScubaGear


text:
Update base AMI to Debian Bookworm

🗣 Description
This pull request updates the base AMI from Debian Bullseye to Debian Bookworm.
💭 Motivation and context
Debian Bookworm was officially released on June 10, 2023.
🧪 Testing
All automated tests pass.
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All new and existing tests pass.

@jsf9k Until we come to a final determination on handling the change in Bookworm from using resolvconf to systemd-resolved for DNS resolution would it be fair to mark this as blocked?

Please note that the linter failures are because this PR is lacking the changes from PR #295.  Once that PR is merged then this one should also pass its checks.

@mcdonnnj - Can you post something here and/or in #300 when your CyHy testing is complete?

@mcdonnnj - Can you post something here and/or in #300 when your CyHy testing is complete?

@mcdonnnj - Does cisagov/cyhy_amis#746 mean that your testing is complete and successful?

It does now. I meant to create that as a draft PR while I did some last verification. I have finished that verification and added a small update to #300 confirming success.

repo: cisagov/skeleton-packer


text:
idr packet lost

Hi.
After 1-2 hours sometimes the h264 output become gray - it is hard to explain how it looks so i attached screenshot.
It keeps like that until I stop the encoding.
I understand it is caused by IDR Packets lost???
My code use the openh264 Encoder ONLY.
Decoding is done on another device using 3rd party decoder (not openh264)

Can i detect in my code that IDR Packets have lost and then to restart the encoder?
If yes, how can i detect the IDR packet lose?
this image was taken when i used Encoder v1.2.
I am not sure if that still happen in encoder v1.3 (I understand you added some fixed for errors there).
Still  will your fix make the output image (after idr packet lost) as if this IDR packets lost has never happen (so no fix from my code is needed), or your fix will do some semi fix and output will not be as good as it was before the IDR packet lost

My main goal here is to prevent having this gray image and if I can not prevent it then at least to know when that happens so my code will know to restart the encoder again.

Hi, since you are using 3rd party decoder, it is possible that this is due to error concealment done by the decoder. To make sure whether it is related OpenH264 encoder, you can try to dump the bit stream after encoding and before transmission, and send it to reference software or OpenH264 decoder to see the ourput.

I am sure it is not the 3rd decoder bug.
If it is not the decoder error, Can i detect in my code that IDR Packets have lost and then to restart the encoder?
I.E can i do anything from the encoder side?

If actual packet loss happens, I assume the 3rd-party decoder can throw some error information. Then for openh264 Encoder, you can use ForceIntraFrame(), and go on encoding.
If no error information is given, I think from encoder side, you have no good choice but send IDR frame periodically.

I did not mean it is decoder bug, it may be the error concealment strategy it chose. My comments will be as stated before, to save the output bit stream of encoder before transmission, and put it through reference software or OpenH264 decoder to check the output, or you can send the dumped bit stream to us to check.

I think i can confirm it is OpenH264 encoder bug.
It happens after ~2.5 hours of encoding.
This time i let it to encode the images to h264 output that is online sent to the 3rd decoder.
When that happened (the gray images started to came) I deleted the OpenH264 encoder and re create it and continue to encode and send the output to the 3rd decoder and that fixed the issue (encoded video started to look good again).
The decoder could not have known that the encoder has been re created (unless the encoder make some specific output when you create it and send it the first image).
So if decoder did not know that encoder has been re created, and recreating the encoder make it to output good h264 then i guess that it is the encoder bug (Am I wrong?).
To duplicate it, feed the encoder with ~25 images per second (not the same images  - feed it with images from movie) for about 2.5 hours and more (for me it took encoder about 2.2 hours till that happen - it happened 3 times 100% of the time i used it after 2.3 hours).
So to sum, feed the encoder for about 3 hours with 25 images per second (different images - not the same image) - after about 2.3-2.5 hours you should see the output as the grey image i attached.

Hi, could you send us the configuration you use so we can try to reproduce? especially the temporal layer, LTR and intra-period settings.

Although your decoder did not know that encoder has been recreated, recreating the encoder will force encoding an IDR frame, which will recover the transmission error.
Your description can not confirm it is encoder bug.
A better way is to recode the bit stream before and after transmission.

close this since this issue is not being updated for needed info.


text:
Hunyuan 1.0 is bad, replace with 1.1 due to oversaturation issues.

As the title says.

1.1 works for me with the existing nodes, same with 1.1 distilled.

I moved on from Hunyuan as I have with any dit based models.  After what LyCORIS informed me, I am done with them as they can never come half the speed close to a unet/clip scheme on my 4090.