abstract out h2oSplitFrameOutput

This PR abstracts out the function H2O.SplitFrameOutput from index.js

I'll blog about the process of abstracting a function out of the monolith index.js here

in it's current state, H2O.SplitFrameOutput() is an IIFE - an Immediately Invoked Function Expression inside of index.js

let's select the body of the IIFE by placing the cursor just inside the opening brace on line 15043 and pressing  Ctrl - m, which is the Sublime Text shortcut to select all of the text inside of a closure like a pair of curly braces.
then, let's cut our function, removing it from index.js and placing it on the clipboard.
then , we comment out the leftover skeleton of the IIFE that remains

now, we create a new file called h2oSplitFrameOutput.js in the src directory
in that new file, let's paste the function text from the clipboard
then, we prepend export function and delete function =
which yields this file:

now, let's import h2oSplitFrameOutput() over in index.js so that we can use it there

then, a bit farther down in index.js, let's find the one place we used the old H2O.SplitFrameOutput and replace it with our new h2oSplitFrameOutput()

we test it out, and find out that lodash is not defined over in src/h2oSplitFrameOutput.js

we fix that by defining lodash
note that we use a global variable on the window. a better way to use lodash would be to import it.  we'll solve that problem later, and continue to use this legacy way of including dependencies for now.  one change at a time 😄

once again, here is what h2oSplitFrameOutput.js looks like all together, with lodash defined.

now we run npm run build and hop over to flow to test splitting a frame again.
it works this time 🎉


Error when running datapackage.skeleton()

I tried running datapackage.skeleton() with a range of arguments, and none at all, and I keep getting this error.

library(preprocessData)
datapackage.skeleton()
Error in !have : invalid argument type

R.Version()
$platform
[1] "x86_64-unknown-linux-gnu"

$arch
[1] "x86_64"
$os
[1] "linux-gnu"
$system
[1] "x86_64, linux-gnu"
$status
[1] ""
$major
[1] "3"
$minor
[1] "1.1"
$year
[1] "2014"
$month
[1] "07"
$day
[1] "10"
$svn rev
[1] "66115"
$language
[1] "R"
$version.string
[1] "R version 3.1.1 (2014-07-10)"
$nickname
[1] "Sock it to Me"

I can't reproduce this. Does this happen in a fresh R session? Other R versions?

It happens in a fresh R session in 3.1.1. I may not be using the most recent version of preprocessData, because I get an install error when trying to install the most recent version due to a dependency on pandoc version >= 1.12.3 for the vignettes. From what I can find online, it is nontrivial to get pandoc installed on SUSE enterprise, which is what I use. Is that dependency necessary?
Curiously, I don't get the pandoc error when installing the latest preprocessData in R 2.15.1. But I still get the "Error in !have : invalid argument type" error when running datapackage.skeleton() in a clean session.

Solved by google. It's not this package. It's in issue or at least quirk of utils::package.skeleton(). http://r.789695.n4.nabble.com/Creating-a-package-skeleton-with-no-flesh-td3906538.html


RFC: Aurora streams handler to process Kinesis events

Key information

RFC PR:
Related issue(s), if known:
Area: Aurora Postgresql streams
Meet tenets: Yes

Summary
Processing database activity streams from Amazon Aurora in AWS Lambda requires heavy lifting work to process the events from kinesis (encryption, serializing, ...).
Motivation
Improve the developer experience reducing the heavy lifting work to process aurora streams
Proposal
With this new module, and a simple functional interface the customers can process easily the event without worrying to decrypt and use the SDK to get the java object with the stream information
A functional interface (like the SQS module) to process every single aurora stream event to allow developers get the stream information to do something with it.
This functional interface includes the sdk utilities to decrypt the message from the KinesisEvent object and serialize the object
More details here: https://github.com/joanbonilla/aws-lambda-powertools-java/tree/aurora-das-handler
Example of use: https://github.com/joanbonilla/sample-db-stream-pw
Drawbacks
At the moment is has been tested for postgresql streams only

What other designs have been considered? Why not them?
What is the impact of not doing this?

Unresolved questions
mysql implementation

Thanks @joanbonilla For opening the RFC. I am wondering at this point, if it would be worth it combine the efforts and actually make it part of new batch utility which we are starting to work upon as part of this RFC for java too https://github.com/awslabs/aws-lambda-powertools-roadmap/issues/64

We are rewriting the batch module (see #797). We can think of an additional module to handle Database Activity Stream.
Thanks for your code sample. Also adding this link as a reference implementation. Note that it's available both for Aurora Postgres and MySQL. Looks like there is something for Oracle and SQL Server: doc.
Similar to the large message handling (#1259), we could think of an annotation to put on the processRecord method:
@DatabaseActivity
public void processRecord(KinesisEvent.KinesisEventRecord record, Context context) {

}

The record would then contain the decrypted activity, so that developers don't spend time on the boilerplate code of kinesis client library.


[Frontend][AST] Add min-runtime-version option.

This is intended for use within the compiler build itself; it is not envisaged that third parties will use it.
The goal here is to avoid a situation where a single PR that adds code to call a new runtime function makes the compiler hard to build on Linux and/or Windows, simply because you need a Swift build installed that has the new runtime function in order to perform a successful build.
On Darwin we already have a way around this, namely the OS version based availability mechanism.  This PR adds an equivalent for Linux and Windows based on the Swift version number itself; when building the Swift code within the compiler proper, this will be set to match the version of the compiler that's being used, and thereby provide a way to gate the use of newer runtime APIs by the compiler during the build.
rdar://121522431

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test

Hmmm. Looks like I have a few issues to iron out with this first.

Closing for now while I work out how to proceed. We need to do something like this, but the detail is more complicated than it originally looked.


Epsilon Annealing bug

Epsilon annealing disregards the requested epsilon final in the slope calculation.

Top: Current behavior, Bottom: Expected behavior
Code to replicate
import matplotlib.pyplot as plt
import numpy as np
ea = EpsilonAnneal(epsilon_final=0.4, epsilon_timesteps=100)
anneal = [ea(0, x) for x in range(101)]
plt.subplot(2, 1, 1)
plt.plot(anneal)
plt.subplot(2, 1, 2)
plt.plot(np.linspace(1.0, 0.4, 100))
plt.show()

Hey @Islandman93, you're right, actually the implementation seemed to be completely wrong (although producing sensible values for the predefined parameters). The latest commit fixed the problem, hopefully, and renamed the arguments (!!!). I haven't actually run the code, so if it's not working, please re-open.


Use CSS position: sticky to simplify dialog window management

When the content of a dialog is too big for its window, we render scrollbars. It is desirable to have the scrollbar span the entire height of the dialog. However, we also keep the header and dialog buttons at fixed positions in the window.
To achieve the desired combination of behaviors, we inject extra elements into the dialog window with the exact same dimensions as the header and dialog buttons such that the scrollable content is not hidden by the header or dialog buttons. This solution works, but has been prone to errors in the past and requires careful synchronization.
The same outcome should be achievable by using the position: sticky CSS property value. We should replace the more complex solution with this very simple CSS property.

Related to #6084.

Developed a proof-of-concept with Electron Fiddle and can confirm that the proposed solution is viable.
The only question now is how to implement it in Storage Explorer. As this is CSS, it will require cooperation/coordination for all dialogs. At the very least, it will require a package update with the style changes for all extensions that provide dialogs.

Can you demo the POC to the rest of the team? We are curious about what exactly this work will buy is, if we put in the effort to do it in standalone?

This is already implemented for React-based dialogs, which was recently merged. It's now working for CORS Rules and custom message boxes.


Updates

use bioformats2raw 0.4.0 to convert all images to zarr
metadata consolidation in a separate process
will parse metadata in the build_config process when the mds are valid

Looks good to me to merge

Looks good to me to merge


Fix gaps in mesh slice

When the mesh slice intersects with an edge, the line for it is not drawn properly. This case is typically quite rare. Although if you set the plane based on picking a vertex, the plane already precisely intersects that vertex, so it's more likely to happen. If you then have artificial data (e.g. a generated sphere), you may actually see it a lot :)
Before:

After:

Note that we're dealing with weird shader arithmetic here. In this line:
let t1 = -(plane.x * p.x + plane.y * p.y + plane.z * p.z + plane.w) / dot(n, u);

The dot(n, u) can be zero, but the resulting t1 wont be inf. We can detect the case and fix it relatively easily, but I agree that it looks a bit weird because it makes assumptions about the resulting t1 t2 t3 that feel somewhat counterintuitive.

Mmm, seeing some occasional artifacts, so perhaps this now shows pieces of faces that it should not.

Wow, that looks like a very subtle bug.

Wow, that looks like a very subtle bug. How'd you figure it out?

The one with the coor value encoding? In the mesh morph example, as you move the mouse over the mesh slice, the location being picked is shown in the 3D view (using the pick coords). I saw the location sometimes jumped when transitioning to a new face. After double-checking the logic that handles the pick coords (and not finding anything) I checked the encoding.

I still observed some wobbly behavior in how the position indicator moves over the 3D surface as you move the mouse along the mesh slice line:

A minor "shaking" behavior seen everywhere.
A jump when approaching/leaving a new face.

I found that the first is just because of the 6-bit precision. Because of this, the contribution of the three vertices, as defined by the pick coords is rounded, and as such there is a limited number of spots on the face that can be addressed.
The observed jump is because the joins (and ends) of the line pieces are round, extending beyond the actual edge. Inside the join, the pick coords are set to the last value on the edge, but since the join covers the next line piece, a jump is observed.

I looked into fixing this:

Not drawing joins. This looks quite a bit worse, and when you want to click om the mesh slice, there is a chance that you click right in between two line pieces.
Drawing the joins with alpha 0.99, so that they are visible, but not clickable. Although this helps solve the problem, there is now a new problem that it looks like you click the mesh slice, but no picking occurs.
As I wrote this down I realized that we can also curve the joins away from the camera, so they won't overlap with the next line piece. This worked!

Rrrready!

Very nice! 😊


Possible cycle error

I just did some testing, and noticed that while cycle through sets ("shift + alt + c"), exactly 1 item do not cycle (always highlighted). This stubborn item always has the utmost upper left position.

is this with the latest version (0.1.2)?

yep

https://i.imgur.com/UOQFilx.png
https://i.imgur.com/Xu0ypFn.png
https://i.imgur.com/jDVhvyI.png

Ah, I think this was introduced because of the fix for working with ilvl 75+ items (#4)...
So basically the old behavior was to prevent using items over ilvl 74 altogether, breaking the recipe even if you had at least one low item level item, and the rest 75+. The new behavior is to find one valid unid rare within the right ilvl range (60-74) and then cycle the rest of the items in the stash tab with 60+ (with no upper limit).
One way to fix this would be to find multiple "first items" (i.e. items within 60-74), which is doable, but I think the better solution is something I had planned to look into but would require considerable development: that is, either provide a hotkey to re-index items from your stash tab after you remove them and sell sets, or detect when sets are sold (or at least removed from the stash) and re-index automatically. The server currently re-indexes automatically every 10 seconds to avoid hitting rate-limiting with the PoE API.
TLDR: Try waiting at least 10s after selling a set and then re-run the hotkey (remember to hit Esc to clear the overlay after using it once), I think cycling is going to be bricked until I figure out a solution to the issues described above. :( Hopefully that still works, and if that doesn't, then that's another bug entirely. I don't have enough rares in standard atm to thoroughly test cycling, but I will try to find a solution to this issue first if possible.

No problem, glad I could help xD

can you try this build?
https://github.com/darvid/stashvision/suites/815771597/artifacts/8944296

extract to the stashvision-go directory
delete the stash_items.bleve directory

should be fixed in v0.1.3
https://github.com/darvid/stashvision/releases/tag/v0.1.3

Nice! will test at blood aqueduct ;)


Query error when using the same workflow in two versions of the application

If two versions of the Site Selector application are opened in the same browser session, and the same workflow is used in both, the first app will work as expected, but the second app will give an error while running the query.
Steps to repro:
Using http://<IP_ADDRESS>/SiteSelector0.8/ and http://<IP_ADDRESS>/EconDevSiteFinder_SP8/ as examples:

Clear browser cache

Open one tab pointing to one of the two URLs above

Select either the Buildings, Sites or Communities tab

Give an address and a search distance (or for the community tab, provide a search in the textbox), then run the search.

Search will be successful

Open a new tab in the same browser

Navigate to the other URL listed above

Follow the same workflow as steps 3-5.  Will encounter an error with the query:

All subsequent queries in the second application will give an error, while all subsequent queries in the first app (first tab) will continue to complete successfully.  If you open a third tab with the same URL as the first, that app will also work.

I am no longer able to reproduce this issue.


Add support for sortType of "simple".

The sortable columns in the angular-data-table directive normally toggle between three states: "asc", "desc" and undefined.
This PR adds the option "sortType" (possible values 'default' and 'simple', defaults to 'default'). If simple is set then the columns will only toggle between ascending an descending, and if you sort a new column it stops trying to sort by all other columns.

@amcdnl this is the feature that you and I discussed, @tristanpendergrass got to it before I did, he's on my team.

Lets rename it 'sortType: single' or 'sortType: multiple'  What do you think @brianfeister ?

Just to clarify: if options object has sortType: 'simple' then it will have this new behavior. If it has any other string ('default', 'multiple', etc) or just lacks the property all-together then it will behave exactly as it does before this PR. So it is entirely a non-breaking change, and using 'default' as opposed to 'multiple' or anything else is just a convention and not part of the code. I could change the expectation of "simple" to "single", though.

Sure, single makes sense as that expresses the intent of sortability UX.

Yes; this is all i mean't - " "simple" to "single", though."

@amcdnl made the change.

@tristanpendergrass one more small changed, commented on line with directions and i'll merge.

Changed.

Beautiful!


Fix zero power

This PR fixes a regression introduced in PR #486. It is now possible to use power with a power of 0. Of course it also forbids 0^0, as it is undefined.

Yep sorry, my bad, I misremembered rust has having stricter requirements on float exponentiation, I have no idea where this idea came from, glad you caught it, thanks! 💯


Make git dependency revisions explicit in Cargo.toml

Tikv has a number of git dependencies. Today the exact revision of those deps is maintained only in the lockfile.
It is more foolproof though to specify git revisions directly in Cargo.toml. If it's not there then the process of updating the lockfile can get unpleasant.
Find all the git deps in all the projects in the workspace and add a "rev = $sha" entry to each.
It may be the case that multiple projects in the workspace have the same git dep. I'm not sure if it's best to specify the revision in one project or all, but I suspect it's more foolproof to do it everywhere, with the hope that if the rev is only updated in one place that the build will fail.

The PR is close due to a bug of cargo (rust-lang/cargo#5478).

Thanks for trying @andylokandy.
patch doesn't seem like the right solution to me since it's for forcibly overriding crate implementations, not really what we are trying to do.
I previously expected the git rev to act like a version constraint causing the crate resolver to pick that rev for every instance of the same git dep, but that's clearly not what happens.
And on further consideration, requiring the rev to be specified in every manifest is the right thing to do - consider that every crate is an independent project, and can be published and linked independently. If any of the crates do not specify the rev they depend on then they are broken.
I know the previous decision was not to specify the rev in every crate because of duplication, but having duplicate revs specified in each crate is not significantly different than having duplicate version numbers specified in every crate.
Anyway I did file an issue against cargo describing this, but I would expect it to be closed https://github.com/rust-lang/cargo/issues/6921

Here's another idea. I don't know the details of patch offhand, but we could try a different scheme that would put all the git repos and revs in a single place:

for each git dep, only specify the version number, as if it lived on crates.io
in the workspace manifest, use [patch] to specify that that crate is actually from a git repo with revision

That would eliminate both the repo duplication and the rev duplication, at the cost of making it less clear which deps are not actually published.

Or we may just release all the git dependency to crates.io. Rev is hard to read, not easy to be updated and duplicated with what's inside Cargo.lock.
On the other hand, repositories like kvproto is expected to be released on crates.io to make it more community friendly.


Uptime kuma exe version not working status page on iframe

⚠ Please verify that this question has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
I am using Uptime Kuma windows exe version. I want to display status pages as iframe. but I was not successful. I run the application via cmd with the following code
uptime-kuma.exe --disable-frame-sameorigin=true
uptime-kuma.exe --disable-frame-sameorigin=false
I tried both commands and it didn't work. The version I use is
https://github.com/louislam/uptime-kuma/releases/download/1.23.1/uptime-kuma-windows-x64-portable-1.23.1-2.zip
I would be happy if you help
📝 Error Message(s) or Log
no error log
🐻 Uptime-Kuma Version
1.23.1 exe version
💻 Operating System and Arch
Windows
🌐 Browser
Chrome
🐋 Docker Version
No response
🟩 NodeJS Version
No response

I am using Uptime Kuma windows exe version.

We don't offer the windows portable anymore due to maintainability issues with Windows Defender and other Malware scanners (See https://github.com/louislam/uptime-kuma/issues/3935 for further context).
Please refer to our installation instructions: https://github.com/louislam/uptime-kuma/wiki/🔧-How-to-Install
How to configure an iframe is documented here: https://github.com/louislam/uptime-kuma/wiki/Status-Page#custom-subdirectory--custom-html-on-status-pages
Closing as not planned, as maintaining the exe is not something that we can offer as decided in #3935

I solved this problem
Edit line:124 server.js
const disableFrameSameOrigin = true;
its worked iframe


Cannot have working filename-based rules and avoid .editorconfig loading at the same time.

Expected Behavior
To be able to process code snippets with a virtual file path with the following two behaviors:

To not check the filesystem for .editorconfig files
To have rules that depend on the file path such as standard:filename work correctly

Observed Behavior

If we use Code.fromSnippetWithPath, the standard: filename rule works, but editorconfig files are checked.
If we use Code.fromSnippet, .editorconfig files are ignored but rules such as standard:filename will not work.

Context

I lint kotlin files using the ktlint API. I want to use rules such as standard:filename that depend on the filepath, but I do not want the filesystem to be checked for .editorconfig files. I do use a .editorconfig file, but I handle the IO with it myself and provide it to the engine as a specially constructed EditorConfigDefaults.

Suggested Solution
RuleExecutionContext.createRuleExecutionContext is hardcoded such that Code.filePath is used both for providing the filePath to the psiFile for use in rules (PsiFileFactory.createFileFromText) and for loading .editorconfig files. (EditorConfigLoader.load). Somehow this should be refactored so that API users may provide file paths to the psi file and/or provide file paths for .editorconfig loading separately. They should not be required to use both features in an all-or-nothing way since they are not interdependent.

I lint kotlin files using the ktlint API. I want to use rules such as standard:filename that depend on the filepath, but I do not want the filesystem to be checked for .editorconfig files. I do use a .editorconfig file, but I handle the IO with it myself and provide it to the engine as a specially constructed EditorConfigDefaults.

Out of curisosity, why do you to handle the IO regarding .editorconfig yourself? One of the key features of Ktlint is that it does respect the .editorconfig when it does find it on the path. The .editorconfig standard offer more functionality than it seems to do at first glance. Implementing this yourselves might lead to deviations from that standard. Of course that is not problem when you are the only user of your API. But if you would expose this API to others, it can lead to confusion, and in the end to complaints about Ktlint not working correctly.
Instead of using EditorConfigDefaults it might be better to the EditorConfigOverride. The latter takes precedence on settings found in real .editorconfig file(s), while the EditorConfigDefaults only is used whenever a setting is not found in the real .editorconfig file(s).

Thanks for explaining this.
When looking at the timespan of a build (a couple of minutes on your local machine), versus the frequency in which an .editorconfig file is modified, it feels to me like overengineering if Ktlint would facilitate this.
More important is that from a technical perspective this is unneeded. Ktlint only reads an .editorconfig file once, and then stores it into a cache. For bigger projects having a lot of files and/or lots of directories it is just to performace costly to read the .editorconfig for each file/directory being accessed. Ktlint won't clear the cache itself as long as the KtlintRuleEngine instance is kept alive. So as long as the API Consument is not instructing KtlintRuleEngine to clear the cache, this problem will not occur.

Might I suggest API users be offered a minimalistic option to just disable .editorconfig loading altogether? It seems this would solve all of these issues, since an API user can already parse a .editorconfig manually and pass it to the engine in the form of EditorConfigDefaults and therefore don't technically need to rely on the library's built-in configuration file IO.

I am not worried about complexity needed to implement a feature like. However, if I would implement it, I would take a different approach and just implement a flag in the KtlintRuleEngine instead of passing it via the Code Snippets.
The reason that I do not want to implement a functionality like this, is that there is no need for it for a larger group of users. Implementing functionalities that benefits a single user or a small group of users will add up to a lot of complexity in the long term. Once it is added to the public API, it has to be maintained. Usually the developer who has added the specific functionality is by then gone, or not using ktlint anymore. I have seen dozens of functionalities that ended up like that in Ktlint, and it has cost me a lot of time and lots of breaking changes to get rid of it.
So I am not saying that it is a bad idea, but merely that I do not see the value in it for the general user base of Ktlint. Next to that, you just seem to dismiss my remarks about why I think it is not needed in your use case:

More important is that from a technical perspective this is unneeded. Ktlint only reads an .editorconfig file once, and then stores it into a cache. For bigger projects having a lot of files and/or lots of directories it is just to performace costly to read the .editorconfig for each file/directory being accessed. Ktlint won't clear the cache itself as long as the KtlintRuleEngine instance is kept alive. So as long as the API Consument is not instructing KtlintRuleEngine to clear the cache, this problem will not occur.

Thanks a lot for elaborating on this.
I am not very familiar with the Gradle eco system. But your explanation did rang a bell.

I have a custom gradle task. I am devoted to developing my gradle plugin to do all of its work lazily as much as possible and to adhering to best practices. So, adhering to idiomatic gradle here means that the .editorconfig file should either be a configuration input or a task input. With configuration caching enabled, all configuration and task inputs must be calculated prior to any tasks executing.

In https://github.com/pinterest/ktlint/issues/1446 you can read more about a similar use case. This was resolved by adding the method below to the KtlintRuleEngine:
    /**
     * Get the list of files which will be accessed by KtLint when linting or formatting the given file or directory.
     * The API consumer can use this list to observe changes in '.editorconfig' files. Whenever such a change is
     * observed, the API consumer should call [reloadEditorConfigFile].
     * To avoid unnecessary access to the file system, it is best to call this method only once for the root of the
     * project which is to be [lint] or [format].
     */
    public fun editorConfigFilePaths(path: Path): List<Path> = EditorConfigFinder(editorConfigLoaderEc4j).findEditorConfigs(path)

I might still not be exactly what you want, but it seems to work for the ktlint Gradle plugin.

Edit: Actually, its not as helpful as I thought. It requires constructing the ktlint engine which I would like to avoid doing at gradle configuration time. And it cannot prevent the engine from reloading the editorconfig files which might be edited during the build. It could help with input tracking on the gradle side, but in my opinion, we need a way to pass .editorconfig as arguments instead of disk IO, or at least an off switch for disabling all editorconfig disk IO.

I can understand this. But still I feel the same objection, I had before:

The reason that I do not want to implement a functionality like this, is that there is no need for it for a larger group of users. Implementing functionalities that benefits a single user or a small group of users will add up to a lot of complexity in the long term. Once it is added to the public API, it has to be maintained. Usually the developer who has added the specific functionality is by then gone, or not using ktlint anymore. I have seen dozens of functionalities that ended up like that in Ktlint, and it has cost me a lot of time and lots of breaking changes to get rid of it.
So I am not saying that it is a bad idea, but merely that I do not see the value in it for the general user base of Ktlint.

I am closing the issue for now. I am willing to reopen it when it would be beneficial and requested by at least one or two other integrators like the ktlint gradle-plugin, or detekt.


Kubectl label command accepts a filename param

address part of issue #10628

@JanetKuo @caesarxuchao  Could you please review this PR?

@JanetKuo @caesarxuchao Added a comment for line 587, please review,

@kargakis  OK

LGTM. Thank you. Leave it to @JanetKuo to add the LGTM label.

Please rebase

@JanetKuo I have rebased, please review.

@JanetKuo  Please review

@feihujiang looks good, thanks!


Document usage of ?include query param

This will close #659.
Let me know if we should say anything about a comma separated list of relationships paths or dot-serperated relationships paths.

Awesome work! Few things:

Incorporate my in-line feedback
I think we should drop the json example. The docs are getting long as it is and it just adds a bit too much noise. I think we can do without the example at all, just keep the rest of the explanation as you have it.

I agree with removing JSON example. I didn't squash the commits yet so that the diff of my changes is still on Github but I will squash before this is good to merge.

I can do it now from GH 💃
Thanks!


Fixes 182: change api errors to error objects

Adds error object that returns on API errors to satisfy this standard. It looks like:
errors: [
   {
      status: 400,
      title: "error creating repo",
      detail: "url already exists"
   }
]

Also specifies error object in openAPI spec for 400,404,500 for all endpoints.
This replaces the default echo error handler with customHTTPErrorHandler in pkg/config/config.go. It also moves custom errors (DaoError and HandlerError) to a package named errors. This way they can be imported by everything, including pkg/config.go
TODO

[x] Tests (I'll fix the tests once direction of PR is okay)
[x] Return most common error code as error code for bulk create. See "generically applicable".

To test:
This changes the error response for all API errors, so cause errors and check that the response is as expected. Also check the API spec has been updated to correctly reflect the changes.

https://issues.redhat.com/browse/HMSCONTENT-182

I got a new idea for this I am trying where ErrorResponse is
type ErrorResponse struct {
    Errors []Error{ Status, Detail, Title }
}

This way returning multiple errors works more directly with the handler. Instead of creating a new response like in BulkCreate.

Changed ErrorResponse struct to have a slice of HandlerError, this way error handling more directly supports returning multiple errors like with BulkCreate.
To support this change I created a new errors package. Otherwise, I could not find a way to do this without causing circular dependencies.

overall +1 to the structural changes.

updated with TestNewErrorResponseFromEchoErrorOtherType and TestDBErrorToApi suggestions. Thanks @avisiedo

lgtm

Tested, all API test pass.

Tested, all API test pass.

but after merging and rebuilding test EE, I get ApiRepositoryBulkCreateResponse has no attribute 'uuid' at ['received_data'][0]['uuid'].


Extract the Sponsors Section Code into a Reusable Component

Is your feature request related to a problem? Please describe.
The Sponsors section is similar across different screens. This will result in repetition of code, violating the DRY principle
Describe the solution you'd like
Extract the code into a reusable component. This will make the code more maintainable as changes relating to sponsors will be made from one place in the code base.
Describe alternatives you've considered
N/A
Additional context
N/A

@brianwachira please assign me this issue


[Bug] Block Production slows as Transaction Rate Increases

The first golden hour occurred this morning, and lead to block height ceasing to increase for ~3 hours.
This is a graph of blocks proposed sorted by their parent block. 36 blocks were proposed on top of block 163. Once some internal state caught up, block production returned to normal.

This graph is the Block Production rate at 5-minute intervals (roughly every slot).
The rate of production has been pretty constant throughout this event, possibly pointing towards some consensus parameters that need to be tuned.

Block production by Host:

@jkrauska noticed that blocks were only being chosen from one block producer, so one producer was restarted and its blocks began to be chosen again. This might indicate something amiss with the internal state of a producer that gets reset when it is restarted.

This is a graph of "Useful Gossip (external transitions)":

https://search-testnet-djtfjlry3tituhytrovphxtleu.us-west-2.es.amazonaws.com/_plugin/kibana/app/kibana#/discover/f275ac10-d4e8-11e9-b1f9-bb4ea8c68935?_g=(refreshInterval:(pause:!t,value:0),time:(from:now-24h,mode:quick,to:now))&_a=(columns:!(message,agent.hostname,metadata.peer,metadata.transition.protocol_state.body.consensus_state.blockchain_length),filters:!(),index:'4cb11720-adb9-11e9-a438-dbd7f50e05cf',interval:m,query:(language:kuery,query:'%22Trust_system.Actions.Sent_useful_gossip%20(external%20transition%20$state_hash)%22'),sort:!('@timestamp',desc))

was cpu usage pegged perhaps?

Not particularly

The root cause of this is an invalid transaction snark in the snark pool of the block producers. Currently we do not verify incoming transaction snarks from snark workers before adding them to the snark pool. They get verified when creating/validating a block. If any transaction snark fails to verify then blocks don't get produced/accepted,
The 36 blocks being proposed on top of block163 were mere attempts and eventually failed with the error: Error building breadcrumb from proposed transition. Invalid staged ledger diff -- Verification failed for proof for including invalid snarks. O1's snarks costed more and probably other snark workers' as well and therefore, could not replace the invalid transaction snark that was already in the snark pools of the block producers.
The spell broke when one of the block producers crashed (#3433) losing all the transactions and snarks in its pool. When restarted, it began producing empty blocks. Later, other block producers were manually restarted producing more empty blocks.
There were no transactions being included in any of the blocks until some new snark workers broadcasted their snarks.
o1 snark coordinator was also restarted during this period but for some reason they were not being broadcasted as suggested by the log message printed during block production: Number of proofs ready for purchase: 0. Snark coordinator logs are all overwritten by the excessive "Waited too long" messages and therefore are not very useful

This ought to be fixed since invalid proofs are now rejected.


fb/latency(cdc): agent to be table state awared, to handle different p2p messages.

What problem does this PR solve?

Issue Number: ref #4757
What is changed and how it works?
let the agent handle different table state, this makes the message report table's state more accurate.
Check List
Tests

Unit test

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
`None`.

/run-verify

/run-all-tests

failure by dm_unit_test https://ci2.pingcap.net/blue/organizations/jenkins/cdc_ghpr_test/detail/cdc_ghpr_test/16801/pipeline
cdc related test passed.


Smaller updates to a few sections

Smaller updates to a few sections

Learn Build status updates of commit 6157d50:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/active-directory/governance/using-multi-stage-reviews.md
:white_check_mark:Succeeded

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

@amsliu

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


denormalizr?

(I'm new to redux/normalizr so tell me if I'm totally off-base)
It's often more convenient to pass nested objects down as props, so I find myself writing selectors like so:
    return {
        foo: {
            ...foo,
            bars: foo.bars.map(id => state.bars[id])
        }
    };

Am I doing it wrong, or would it be nice to have a denormalizr that converts the normalized objects back to nested objects (perhaps using the same schema definition?)

I am working on this. As suggested it is entirely possible to use the same schema definition to convert back to nested objects. I will add a PR within the next days to see what you guys think about it. Stay tuned.

Closing, as this is duplicate of https://github.com/gaearon/normalizr/issues/1.
See also the discussion there.


README broken links

The links on educational-material/README.md are broken due to a questionable directory restructure in e78c1e7e1611bf56bde3a8f75007386a0207c5a4.

Bug Fixed in Commit a12cb7ae951d51be253e74722595ab5374414056


Specs approach for AMOF files

As with issue #16, I have also made some progress on the idea of using specs to check AMOF files. In this approach, I have created a number of spec files, one that looks at land variables, and one that does common global attributes.

land variables also includes a dimension and a variable that isn't real, just as part of checking it's working
common global attributes refers to a new vocab file amof.json, although I think the info in here might also be in the AMF CVs, I didn't look because I did this first.

To accommodate this, I made some changes to generic.py, where the functions run by the spec checker live

lines 31, 40, 50-54, function check_global_attrs: added regex checks
lines 59-86: added two new functions - check_var_exists and check_dim_exists. Quite self-explanatory

This approach doesn't (currently) check the values of variable attributes, just that they exist. This is better suited for checking valid_min (compare with discussion in issue #16), but not for checking units, for example.
I think this approach will also work well when all variables have the same attributes; however, that's not the case (e.g. quality control variables have flag_values and flag_meanings, which don't exist in other variables). I guess that the specs can be written to do checks on QC variables separately to other variables.
Example of running check against these spec files:
checksit check -t off --specs=amof-land-common,amof-global-attrs-common /gws/nopw/j04/ncas_obs/public/cdao/ncas-radar-wind-profiler-1/ncas-radar-wind-profiler-1_cdao_20221020_snr-winds_low-mode_15min_v1.0.nc

Running with:
	Template: OFF
	Datafile: /gws/nopw/j04/ncas_obs/public/cdao/ncas-radar-wind-profiler-1/ncas-radar-wind-profiler-1_cdao_20221020_snr-winds_low-mode_15min_v1.0.nc

---------------- Running checks ------------------

[WARNING] Template checks switched off!
[FAILED] with 3 errors:

	01. [variable**************:cows]: Does not exist in file.
	02. [dimension**************:fields]: Does not exist in file.
	03. [global-attributes:******:instrument_serial_number]: '' does not match regex pattern '.{3,}'.

Update through commit 65cdf5c:

added make_specs.py - I imagine this will probably live in amf-check-writer but I've added it here for now so it is somewhere. This takes (most of) the json CV files created by amf-check-writer and creates spec files that can be used by checksit.

currently this creates a product-specific spec file with variables and dimensions, and a start of doing common global attributes, although this still needs a bit of work
still to do:

[ ] complete common global attributes
[ ] common land/sea/air/trajectory variables and dimensions
[ ] product-specific global attributes

added function check_var to generic.py and added rules_attrs keyword argument to check_global_attrs function to help with global attribute spec check

In general, these product specific spec checks work, e.g.
$ checksit check -t off --specs=amof-snr-winds ncas-radar-wind-profiler-1_cdao_20221017_snr-winds_high-mode_15min_v1.0.nc

Running with:
	Template: OFF
	Datafile: ncas-radar-wind-profiler-1_cdao_20221017_snr-winds_high-mode_15min_v1.0.nc

---------------- Running checks ------------------

[WARNING] Template checks switched off!
[INFO] File is compliant!

and
$ checksit check -t off --specs=amof-surface-met ncas-aws-10_iao_20220301_surface-met_v1.0.nc

Running with:
	Template: OFF
	Datafile: ncas-aws-10_iao_20220301_surface-met_v1.0.nc

---------------- Running checks ------------------

[WARNING] Template checks switched off!
[FAILED] with 8 errors:

	01. [variable**************:downwelling_longwave_flux_in_air]: Does not exist in file.
	02. [variable**************:downwelling_shortwave_flux_in_air]: Does not exist in file.
	03. [variable**************:downwelling_total_irradiance]: Does not exist in file.
	04. [variable**************:net_total_irradiance]: Does not exist in file.
	05. [variable**************:qc_flag_radiation]: Does not exist in file.
	06. [variable**************:qc_flag_downwelling_total_irradiance]: Does not exist in file.
	07. [variable**************:qc_flag_net_total_irradiance]: Does not exist in file.
	08. [dimension**************:index]: Does not exist in file.

In the second case, the variables that checksit reports as not existing do not exist in the file but should not necessarily be in the file - while they are valid variables for that data product, the ncas-aws-10 instrument does not measure radiation, and so the product-specific variables relating to radiation are omitted from the file, rather than being left in empty.
The index dimension should not appear in this spec - while in the middle of writing this I have found the error in make_specs.py and will correct this shortly.

make_specs.py fixed in commit d527361, with updated spec file for the surface-met product.

Commit c72106f adds making spec files for deployment modes, e.g. for land

Added section to check.py which, if template is auto (default), checks to see if the file given is a netCDF file, if so checks Conventions global attribute against known AMOF standard Conventions vocab. If so, gets spec files for that file based on data product and deployment mode, sets template to off, and runs checksit using those specs. For example:
$ checksit check ncas-radar-wind-profiler-1_cdao_20221017_snr-winds_high-mode_15min_v1.0.nc

AMOF file detected, finding correct spec files

Running with:
	Template: OFF
	Datafile: ncas-radar-wind-profiler-1_cdao_20221017_snr-winds_high-mode_15min_v1.0.nc

---------------- Running checks ------------------

[WARNING] Template checks switched off!
[INFO] File is compliant!

Doesn't currently add in the global attributes spec file because that has not been created correctly/in a useful manner. Also still need to work on product-specific attributes.
I've not tested this against a non-netCDF file, but I have tested against a non-AMOF netCDF file, which is correctly ignored in the AMOF-checking process.

One issue with global attributes spec was the licence global attribute, which includes a URL. The check code is splitting the string based on a colon, which meant half of the attribute was not included. This is fixed in commit defa3b1, joining the list with a colon, and only applies to the regex checks.

In the general global attributes, there are two that have vocab checks - source and platform.

platform is taken from the AMF_platfrom CV file, with any of the locations being acceptable. In vocab speak - __vocabs__:AMF_CVs/AMF_platform:platform:* where * represents any
source is from the AMF_ncas_instrument (or AMF_community_instrument) CV file, however this then depends on instrument name, i.e. __vocabs__:AMF_CVs/AMF_ncas_instrument:ncas_instrument:<instrument_name>:description

To help toward this, commit 6c5b8a0 introduces the idea of wildcard to cvs.py. The wildcard can be used in specifying the vocab check, however at the moment it will only work if the wildcard is the last argument in the check. This means that platform will work, but source will not. The reason for this is that the vocab check is going through dictionaries until it gets to the required value(s) at the end, either a single value or a list of values. The wildcard returns a list of values. If the wildcard is used before the end, the vocab check will get confused at the next stage trying to take a key of a list. I think I would too.

Commit 1d75c78 allows for wildcard to appear anywhere in specs vocab check.

When a wildcard is encountered by a vocab check, checksit looks to see if the wildcard is the last key in the vocab lookup.

If it is, the wildcard returns a list of all keys of the dictionary being checked.
If it isn't, the wildcard returns a list of all the values within the object being checked, but without the keys to those values. When this list then gets checked at the next stage of the vocab check, each element in the list will be checked independently, with a new list being returned.

A (hopefully not too confusing) generic example to help (mostly me) understand, considering the very generic dictionary
{'a' : {'b' : 'c', 'd' : {'e' : 'f', 'g' : 'h'} },
 'i' : {'b' : 'j', 'd' : {'e' : 'k', 'g' : 'l'} },
 'm' : {'b' : 'n', 'd' : {'e' : 'o', 'g' : 'p'} } }

The following checks get the (also) following results:
"__all__" => ['a', 'i', 'm']
"a:__all__" => ['b', 'd']
"a:d:__all__" => ['e', 'g']
"__all__:b" => ['c', 'j', 'n']
"__all__:d" => [{'e' : 'f', 'g' : 'h'}, {'e': 'k', 'g' : 'l'}, {'e' : 'o', 'g' : 'p'}]
"__all__:d:e => ['f', 'k', 'o']

Final issue that needs dealing with for AMOF spec checks (I think) - how to deal with product-specific variables that are not in the netCDF file? The AMOF standard allows for these variables to not be there, but at the moment checksit expects all possible variables to be present.
One option - create a function similar to checksit.generic.check_var that returns info or warning rather than error if variable is not present?

Great work @joshua-hampton,
I wonder if we should have a way of specifying that any component (i.e. a dimension, variable or an attribute) could be optional. If so, we just need a nice clean way of identifying them.

Couple of thoughts on how we could do that:

Have the option to append names with something like __optional__, then within the checksit.generic.check_XXX function check to see if that string is present before running check on that value.
Add an extra parameter to the checksit.generic.check_XXX functions called required which takes a boolean value for each variable/dimension/attribute name being passed to the function (or the inverse parameter called optional)

Another thought - global attributes sampling_interval and averaging_interval have a Compliance Checking Rule in the spreadsheets that they should be a string with at least two characters - do we want to add an extra check that they should have units of time in them?

Idea on applying optional status to things in spec checks (commit https://github.com/cedadev/checksit/commit/c4fe779ae940517768963cf542d63477b9653549). When making spec files for data products, variables and dimensions being checked have :__OPTIONAL__ appended to them (e.g. see amof-surface-met.yml). The functions in generic.py then check the variables and dimensions to see if :__OPTIONAL__ is in each one. If it is, the check still happens, but (currently) no error is reported if the variable/dimension is not present. If :__OPTIONAL__ is not in the variable/dimension name, then the check happens as it previously did.

@joshua-hampton: sounds good 👍

Commit https://github.com/cedadev/checksit/commit/31a02090abad1a61dc25d3f5c4b5e5702d87bb4e - Added "warnings" as a returned parameter from generic.py. When optional product-specific dimensions or variables are missing, a warning is added, which passes back up the chain through specs.py to check.py, where they are printed out along with errors/file compliance, e.g.
(checksit_env) (base) [earjham@rsg1-202206011551 checksit]$ checksit check ncas-aws-10_iao_20220301_surface-met_v1.0.nc

AMOF file detected, finding correct spec files

Running with:
	Template: OFF
	Spec Files: ['amof-common-land', 'amof-surface-met', 'amof-global-attrs']
	Datafile: ncas-aws-10_iao_20220301_surface-met_v1.0.nc

---------------- Running checks ------------------

[WARNING] Template checks switched off!
[FAILED] with 5 errors:

	01. [global-attributes:******:creator_email]*** Value 'CHANGE: E-mail address of the person who made the file. Valid email' does not match regex rule: 'valid-email'.
	02. [global-attributes:******:creator_url]*** Value 'CHANGE: ORCID URL of the person who made the file. Valid URL' does not match regex rule: 'valid-url'.
	03. [global-attributes:******:calibration_certification_date]*** Value 'CHANGE: when bought' does not match regex rule: 'datetime-or-na'.
	04. [global-attributes:******:processing_level]*** Value '1' is not of required type: 'integer'.
	05. [global-attributes:******:platform_altitude]*** Value 'CHANGE: Altitude of the deployment position above MSL. Enter Not Applicable for air. Exact match: <number> m' does not match regular expression: '^\d+\.?\d*\sm$'.

[WARNING] 7 warnings about file:

	01. [variable**************:downwelling_longwave_flux_in_air]: Optional variable does not exist in file.
	02. [variable**************:downwelling_shortwave_flux_in_air]: Optional variable does not exist in file.
	03. [variable**************:downwelling_total_irradiance]: Optional variable does not exist in file.
	04. [variable**************:net_total_irradiance]: Optional variable does not exist in file.
	05. [variable**************:qc_flag_radiation]: Optional variable does not exist in file.
	06. [variable**************:qc_flag_downwelling_total_irradiance]: Optional variable does not exist in file.
	07. [variable**************:qc_flag_net_total_irradiance]: Optional variable does not exist in file.

I've also added a flag to the check command in cli.py - -w/--ignore-warnings which means the warnings don't print out, e.g.
(checksit_env) (base) [earjham@rsg1-202206011551 checksit]$ checksit check -w ncas-aws-10_iao_20220301_surface-met_v1.0.nc

AMOF file detected, finding correct spec files

Running with:
	Template: OFF
	Spec Files: ['amof-common-land', 'amof-surface-met', 'amof-global-attrs']
	Datafile: ncas-aws-10_iao_20220301_surface-met_v1.0.nc

---------------- Running checks ------------------

[WARNING] Template checks switched off!
[FAILED] with 5 errors:

	01. [global-attributes:******:creator_email]*** Value 'CHANGE: E-mail address of the person who made the file. Valid email' does not match regex rule: 'valid-email'.
	02. [global-attributes:******:creator_url]*** Value 'CHANGE: ORCID URL of the person who made the file. Valid URL' does not match regex rule: 'valid-url'.
	03. [global-attributes:******:calibration_certification_date]*** Value 'CHANGE: when bought' does not match regex rule: 'datetime-or-na'.
	04. [global-attributes:******:processing_level]*** Value '1' is not of required type: 'integer'.
	05. [global-attributes:******:platform_altitude]*** Value 'CHANGE: Altitude of the deployment position above MSL. Enter Not Applicable for air. Exact match: <number> m' does not match regular expression: '^\d+\.?\d*\sm$'.

Another thought - global attributes sampling_interval and averaging_interval have a Compliance Checking Rule in the spreadsheets that they should be a string with at least two characters - do we want to add an extra check that they should have units of time in them?

@joshua-hampton: I think all structural rules like this should be referred to Barb.

Testing this with a file that isn't mine has produced some results of note:

This particular file uses the global attribute feature_type instead of featureType. In this case, checksit has correctly identified an error with the file, however I wonder if it would be helpful/possible to write something that identifies a "close mistake" and offers a suggestion on how to fix.
Similarly, this file calls a dimension altitudes rather than altitude. As altitude is an optional dimension, checksit raises a warning about the file, but would still call it compliant, which in this case is probably wrong. Again, a "did you mean this" or "I wasn't expecting to see this" would provide the user with more information when they might be thinking "I'm sure I put altitude in".
The platform global attribute requires an exact match to one of the platform_ids here. For an instrument not at any of those locations (e.g. anything on fieldwork I'd guess), none of these options might make sense.

@joshua-hampton: I really like your ideas for giving people hints on what they might have meant.

I've found another issue, when doing a rule check on a global attribute. Specifically, this one from specs/groups/amof-global-attrs.yml
geospatial_bounds: rule-func:string-of-length:8+

In one netCDF file, the attribute was spelt incorrectly, and dct['global_attributes'].get(attr, UNDEFINED) (line 61 in generic.py) returned UNDEFINED. However, UNDEFINED matches rule-func:string-of-length:8+, and so passed the checker.
Suggested fix - the check for attribute existence is done separately. This may need to be done in other places too.

Played around a bit with the idea of giving hints on potentially misspelt items (https://github.com/cedadev/checksit/commit/da93da709d73099f347d648a0b8824cdc1c5ccee). If a variable/attribute/dimension specified in the spec file is not found in the netCDF file, a function is called that takes the name of what should be there, produces a set of possible "close matches" defined as up to two errors, and then looks through these close matches to see if any of them match anything in the file. For example, if a file had the variable yr instead of year, and the global attribute sauce rather than source, then checksit would return
1. [variable**************:year]: Does not exist in file. 'yr' was found in this file, should this be 'year'?
2. [global-attributes:**************:source]: Attribute 'source' does not exist. 'sauce' was found in this file, should this be 'source'?

There are a few limitations on this method. Firstly, I've assumed that the first character will be correct. This is mostly because you could otherwise get
23. [dimension**************:altitude]: Optional dimension does not exist in file. 'latitude' was found in this file, should this be 'altitude'?

Secondly, if there are similar variable/attribute/dimension names intended to be in the file, they can come up as suggestions. For example, the snr-winds data product has variables skew_of_beam_1, skew_of_beam_2, and skew_of_beam_3. If one of those was spelt incorrectly, e.g. skew_of_bem_2, you might end up with the following return
1. [variable**************:skew_of_beam_2]: Optional variable does not exist in file. 'skew_of_beam_1' was found in this file, should this be 'skew_of_beam_2'?

The functions that are doing this are currently in checksit/generic.py, but I guess if they are useful they could be moved somewhere else (checksit/utils.py?) to be available elsewhere.

Also found a bug when logging in "compact" mode, checksit would attempt to run template check regardless of whether one was required or not (e.g. AMOF netCDFs only using specs). This is fixed in https://github.com/cedadev/checksit/commit/15183b0a88f8c8ec65a4d53117120612cb423cdc

CLI option to skip spellchecking added in https://github.com/cedadev/checksit/commit/51f7f8e5af094bde15737c4b994ca782db36fe31. Creating a pull request to main with latest changes


Fixed #24241 - Fixed copying models in StateApps

Fixed the issue that StateApps.clone did not create a copy of the
models in self.all_models. Changed copy method of all_models to use
a ModelState rather than deepcopy to create a new model class.
Ticket: https://code.djangoproject.com/ticket/24241

buildbot, test this please.

Do you have any numbers how long the "new" clone() method takes compared to the previous one?

Yeah, what I expected. This approach is not an option. It takes way too long rendering all the apps and models. (The former repetitive call to render() and not "deep-copying" apps was even faster.

We cannot afford to re-render each model, as Markus noticed. We have to find a way to quickly copy.


Config: add tests for the --generator= argument

Description
In preparation for a PR to address #709, this PR adds tests to cover the current behavior of the code in the Config class that handles setting the generator property when the --generator= argument is passed in the command line.
Related issues/external references
Related to #709
Types of changes

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

[ ] This change is only breaking for integrators, not for external standards or end-users.

[ ] Documentation improvement

PR checklist

[x] I have checked there is no other PR open for the same change.
[x] I have read the Contribution Guidelines.
[x] I grant the project the right to include and distribute the code under the BSD-3-Clause license (and I have the right to grant these rights).
[ ] I have added tests to cover my changes.
[x] I have verified that the code complies with the projects coding standards.
[ ] [Required for new sniffs] I have added XML documentation for the sniff.

I presume a test with the argument being passed an invalid value will follow in the PR to address #709 ?

Yes, I opted not to include it, as the code does not currently check for invalid values. But now I see that I could have included it to document the code's current behavior and then update the test in the subsequent PR.

Do you still want to do that or would you prefer for this PR to be merged and the next one to document handling of invalid values ?

Do you still want to do that or would you prefer for this PR to be merged and the next one to document handling of invalid values ?

The easiest for me would be to have this PR merged and include the other test in the subsequent PR. But I'm happy to update this PR if you prefer.

Okay, done. Looking forward to the follow-up PR.


[as2_platform_dji_osdk] Uplink and downlink topic name as parameters

          Uplink and downlink topic name may be a parameter too

Originally posted by @RPS98 in https://github.com/aerostack2/aerostack2/pull/309#discussion_r1266593944

@pariaspe it has already be done?

No, it's not done yet


Category bucket question/comparison with Builder

@davidmanzanares
Heyyy,
I'm seeing two different results between Builder and the renderer when I symbolize two categories in my data.
With the renderer, I am using buckets to symbolize fires caused by lightning and arson:
width: 5
color: ramp(buckets($cause_descrip,"Lightning","Arson"),Prism)

result
In Builder, I'm doing the same with TurboCARTO:
  marker-fill: ramp([cause_descrip], (#5F4690, #f28423,rgba(50,50,50,0.8)), ("Lightning","Arson"), "=");

result
As you can see, I'm getting two different results... any ideas why?
thanks!

Could this be related to https://github.com/CartoDB/renderer-prototype/issues/110?

Yes, it is completely related, and they should probably be tackled together.

Closing this since https://github.com/CartoDB/renderer-prototype/issues/110


Add renter/host interfaces and logic

Moves most protocol logic into the siad repo keeps base interfaces and shared logic. We can move pieces into separate PRs as they're finalized.

MDM implementation
Registry implementation
Interfaces for data stores
Contract helpers

looks pretty good -- I do wonder if we need separate packages for rhp and renterhost though

A split between the netcode and protocol objects in net/rhp and validation logic into a top-level renterhost made sense, but I don't feel particularly strongly either way.

Hmm. I can see the rationale, but ultimately I don't think the packages are different enough to outweigh the downsides of having both a renterhost and an rhp package. We can always split out new packages later without breaking compatibility, but we can't remove an existing one. In the same vein, I'd probably consolidate the mdm and registry packages; they're not very big, and they don't have any consumers that wouldn't also be importing net/rhp anyway. It's ok for net/rhp to be a large package; it's a large protocol.

ok, structure looks good to me. Any blockers keeping this a WIP, or are we good to merge?

I think we're good, but we'll probably have a few more iterations. I'll push up the siad side of this PR.


[KYUUBI #1536] Add engine conf provider

Why are the changes needed?

Closes https://github.com/apache/incubator-kyuubi/issues/1536
How was this patch tested?

[x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #1537 (0d289cb) into master (609bb5a) will increase coverage by 0.06%.
The diff coverage is 89.65%.

@@             Coverage Diff              @@
##             master    #1537      +/-   ##
============================================
+ Coverage     59.29%   59.35%   +0.06%
  Complexity      172      172
============================================
  Files           241      243       +2
  Lines         12224    12248      +24
  Branches       1501     1502       +1
============================================
+ Hits           7248     7270      +22
- Misses         4364     4366       +2
  Partials        612      612

Impacted Files
Coverage Δ

...apache/kyuubi/plugin/DefaultEngineConfAdvisor.java
0.00% <0.00%> (ø)

...n/scala/org/apache/kyuubi/engine/ProcBuilder.scala
91.00% <ø> (ø)

...ache/kyuubi/engine/spark/SparkProcessBuilder.scala
85.18% <83.33%> (+0.42%)
:arrow_up:

...in/scala/org/apache/kyuubi/config/KyuubiConf.scala
95.41% <100.00%> (+0.03%)
:arrow_up:

.../scala/org/apache/kyuubi/plugin/PluginLoader.scala
100.00% <100.00%> (ø)

...ain/scala/org/apache/kyuubi/engine/EngineRef.scala
84.94% <100.00%> (+0.16%)
:arrow_up:

.../org/apache/kyuubi/session/KyuubiSessionImpl.scala
84.21% <100.00%> (ø)

...g/apache/kyuubi/session/KyuubiSessionManager.scala
97.50% <100.00%> (+0.13%)
:arrow_up:

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 609bb5a...0d289cb. Read the comment docs.

Seems the branch repo is error, let me create a new one

created a new one https://github.com/apache/incubator-kyuubi/pull/1892


Standar api call working with curl (console and php) but forbidden with Guzzle

guzzle:
    clients:
        aws_lambda:
            base_url: "https://XXXXXXXX.amazonaws.com/prod"
            options:
                headers:
                    #Accept: "application/json"
                    User-Agent: 'custom agent'
                    x-api-key: 'somekey'

With this config when I use it I get 403 forbidden error.
If I make the same request from console or with plain php curl, it works perfectly. I have tried to move the x-api-header to the controller and it's still failing.
Quite confused.

My mistake! The base url contains part of the endpoint url and just after oppening this issue I realized that.


I haven't finished the book

A question received via email:
haven't finished the book.
what should I submit to the Proposal Draft on Thursday?

The week 5 Proposal assessment is not your final proposal, but is an initial draft that touches upon some key points -- see the video we have prepared, and the teaching material your course coordinator has given you. While we would have preferred you would have finished reading the background reading by now, we recognise that it is not necessary for you to have finished these in order to submit the draft proposal.
However, make sure you read (and understand) the background material quickly. You could use the week 6 project meeting for discussing any doubt you may have on the material.


Allow configuring a client id prefix

Rather than using a single client id for all consumers it would make sense to have a per-consumer client id. This would allow monitoring the low-level operations of each consumer separately.
In order to do this, we could allow users to configure a client id prefix and construct the client id based on the consumer name, e.g. my-prefix.my-consumer.

On second thought, it might be better to just configure the full client id on a per-consumer basis when launching Racecar, e.g. RACECAR_CLIENT_ID=some-id bundle exec racecar SomeConsumer.


Prefix increment operator not working in for loops

Some of us use 2-statement style for loops using the prefix increment operator. These don't seem to compile, although in COVERAGE.md it says that prefix increment operators are implemented. Example:
var x: number[] = [];
for (var i = -1; ++i < x.length;)
{
  console.log(i);
}

(Side note: This is a very interesting project. Years ago I posted this on the TypeScript forum and have been following many TypeScript => !JavaScript compiler projects.)

Hi, the actual reason was empty increment part of the for loop. Now fixed and your example compiles fine.

Years ago I posted this on the TypeScript forum
Yeah I actually saw this post and it was part of inspiration to create this project, all those super-experts telling that it is not possible 😃 Still convinced that everything can be transpiled except eval and new Function.


wg-stories Working Group Update - June 2019

This is the stories working group update, presented at the 2019-06-19 AMP design review
What was accomplished

Built AMP viewer features to allow tapping and swiping to the next/previous stories

Best practices guideSee the full guide on amp.dev

Built easier templating features

Allow specifying focal points for media

Added support for live stories (#21714)

Launched embedded components

Add built in CSS for text with a colored background to make text more legibleWithout text highlightingWith text highlighting

Media playback reliability

Performance improvements

Better support for prerendering stories

amp-story 0.1 deprecation

What's next

Allow opening remote URLs inside of page attachments

Allow users to react inline to story content, to provide social feedback

Update the story progress bar

Improving story analytics

Providing options for specifying alt text when text is baked into video assets

Give publishers better assurance about the aspect ratio of the story

Allow easily embedding stories in other webpages

Closed in favor of the new working group update #17


Intuition behind the augmentation trick for flow?

I am curious about what is the intuition behind the last line of pyActionRec/utils/io.py ? It doesn't make sense to me. Is this just a trick you happened to find working well in practice?
crops[5:, range(0, stack_depth, 2), ...] = 255 - crops[5:, range(0, stack_depth, 2), ...]

This is not any trick but simple  math. When one flips the flow field horizontally, the x-direction of motion ought to be negated, which, in our representation, leads to the operation you mentioned.


Process stack needs to store data

We want to carry actual data with process stack but we can't because of size bounds are varying. We need to find a way to do this to make simpler callback implementation.
pub struct ProcStack<S> {
    pub state: S,

    pub before_start: Option<Arc<dyn Fn(&mut S) + Send + Sync>>,
    // ...
}

@azastrael mentioned to not move whole environment to Fn.


Tensorflow Implementation of Focal Frequency Loss

As I couldn't find a tensorflow implementation of Focal Frequency Loss, so I created it.
Please visit the Github Repo and PyPi Project.
Use case notebook is included in the Repo. Any feedback is appreciated.
@EndlessSora If you find this implementation useful, kindly do mention it on your README.
Thanks for releasing this.

Thank you so much for the nice TensorFlow implementation! Have you tested the code and its performance compared with this official repo?

I have tested the code for sure. The Tensorflow version gives an exact numerical answer as the Pytorch version. Code for test attached  below:
from focal_frequency_loss import FocalFrequencyLoss as FFL
from tf_focal_frequency_loss import FocalFrequencyLoss as TFFL

# Pytorch
import torch

ffl = FFL(loss_weight=1.0, alpha=1.0)  # initialize nn.Module class

fake = torch.randn(4, 3, 64, 64)
real = torch.randn(4, 3, 64, 64)

pt_loss = ffl(fake, real)  # calculate focal frequency loss

# Tensorflow
import tensorflow as tf

tffl = TFFL(loss_weight=1.0, alpha=1.0)  # initialize tf.keras.layers.Layer class

fake = tf.convert_to_tensor(fake.numpy(), tf.float32)
real = tf.convert_to_tensor(real.numpy(), tf.float32)

tf_loss = tffl(fake, real)  # calculate focal frequency loss

# Check
import numpy as np
assert np.isclose(pt_loss.numpy(), tf_loss.numpy()) , "Results don't match"

I have trained a Pix2Pix model and it does give better results (compared to training without it), but I haven't recreated the official repo results to compare its performance.

Thanks a lot for the nice support. I have already mentioned this unofficial TensorFlow implementation in our README.

Thanks a lot for the support.


UTF-8 support

Summary of changes:

Don't store position metrics, but instead store newlines + char/code unit lengths. By not storing positions, we can subtract metrics and sometimes avoid some measurements.
Add UTF-8 modules.
Add UTF-8 operations to mixed rope.

Some benchmarks on my machine:
ghc-9.0.2 (UTF-16-native text)
  master
    Split at position
      Unicode
        text-rope:       OK
          7.11 ms ± 389 μs
        text-rope-mixed: OK
          7.49 ms ± 701 μs
      UTF-16
        text-rope:       OK
          2.71 ms ± 179 μs
        text-rope-mixed: OK
          6.46 ms ± 337 μs
    Split at offset
      Unicode
        text-rope:       OK
          12.6 ms ± 674 μs
        text-rope-mixed: OK
          13.8 ms ± 777 μs
      UTF-16
        text-rope:       OK
          2.63 ms ±  89 μs
        text-rope-mixed: OK
          6.66 ms ± 342 μs
  this branch
    Split at position
      Unicode
        text-rope:       OK
          4.05 ms ± 253 μs
        text-rope-mixed: OK
          3.89 ms ± 378 μs
      UTF-16
        text-rope:       OK
          3.50 ms ± 250 μs
        text-rope-mixed: OK
          3.81 ms ± 365 μs
      UTF-8
        text-rope:       OK
          3.17 ms ± 268 μs
        text-rope-mixed: OK
          3.68 ms ± 194 μs
    Split at offset
      Unicode
        text-rope:       OK
          2.36 ms ± 202 μs
        text-rope-mixed: OK
          2.52 ms ± 170 μs
      UTF-16
        text-rope:       OK
          2.11 ms ±  90 μs
        text-rope-mixed: OK
          2.45 ms ± 173 μs
      UTF-8
        text-rope:       OK
          1.97 ms ± 170 μs
        text-rope-mixed: OK
          2.40 ms ± 199 μs

ghc-9.4.8 (UTF-8-native text)
  master
    Split at position
      Unicode
        text-rope:       OK
          4.43 ms ± 353 μs
        text-rope-mixed: OK
          6.05 ms ± 588 μs
      UTF-16
        text-rope:       OK
          3.57 ms ± 190 μs
        text-rope-mixed: OK
          5.66 ms ± 221 μs
    Split at offset
      Unicode
        text-rope:       OK
          5.08 ms ± 361 μs
        text-rope-mixed: OK
          6.66 ms ± 359 μs
      UTF-16
        text-rope:       OK
          3.93 ms ± 200 μs
        text-rope-mixed: OK
          6.06 ms ± 397 μs
  this branch
    Split at position
      Unicode
        text-rope:       OK
          4.05 ms ± 253 μs
        text-rope-mixed: OK
          3.89 ms ± 378 μs
      UTF-16
        text-rope:       OK
          3.50 ms ± 250 μs
        text-rope-mixed: OK
          3.81 ms ± 365 μs
      UTF-8
        text-rope:       OK
          3.17 ms ± 268 μs
        text-rope-mixed: OK
          3.68 ms ± 194 μs
    Split at offset
      Unicode
        text-rope:       OK
          2.36 ms ± 202 μs
        text-rope-mixed: OK
          2.52 ms ± 170 μs
      UTF-16
        text-rope:       OK
          2.11 ms ±  90 μs
        text-rope-mixed: OK
          2.45 ms ± 173 μs
      UTF-8
        text-rope:       OK
          1.97 ms ± 170 μs
        text-rope-mixed: OK
          2.40 ms ± 199 μs

In summary, it's faster on almost every benchmark, but the pure UTF-16 rope is slightly slower with text-1 because it doesn't benefit from the measurement avoidance (since getting the UTF-16 length is then constant time).
Addresses https://github.com/Bodigrim/text-rope/issues/3.

OK, I'll wait for a full review until working further on this.

Okay, I think I've addressed most comments.
A couple of notes and questions in line.

@ollef could you please get CI green?

@ollef I regenerated CI jobs, could you please rebase atop of the latest master?

@Bodigrim Done, cheers.

Awesome, thanks!

@ollef do you need a release of text-rope soon to publish your changes?

@Bodigrim: Not urguently, but it might be nice to get it out there eventually. :) I can try using the Github version in the meantime.

Thanks, I'll wait for #6 to land before making a release then.

@ollef published as https://hackage.haskell.org/package/text-rope-0.3


Update imported docs

Update imported docs and keep the v1.5 new style reference docs, remove old style docs for api-reference and kubectl

This change is

/assign @devin-donnelly @pwittrock

/lgtm

@devin-donnelly Rebased.

@ymqytw Looks like there's a conflict with docs/admin/kube-scheduler.md that needs to be resolved before we can merge this. Thx

@chenopis Rebased. PTAL

@ymqytw Sorry, there are a lot of docs changes going on at the moment. It looks like there is a conflict with docs/user-guide/kubectl/kubectl_completion.md now. :(

@chenopis It seems that people are keep changing the auto-generated files. We should prevent that and direct them to update the source.

Rebased.

@ymqytw Ok, I'll keep an eye out for that. Is there an easy way to know which files are auto-generated? Also, there still seems to be a conflict.

@chenopis I have resolved the conflict.

@ymqytw Great, thanks!

@chenopis @ymqytw kube-scheduler.md should not be removed.

@zhangxiaoyu-zidif Sorry. It seems that the this file has kube-scheduler.md. It seems this file should be kept by the script. Not sure how it has been deleted.
Can you send a PR to roll back that file? Thanks.

I guess maybe something went wrong in multiple time of rebase :/

@ymqytw @chenopis  I add the file at https://github.com/kubernetes/kubernetes.github.io/pull/3340.
I have no right to revert the PR. If you both have some way to roll back it or revert it, you can close #3340.

It's being added back in PR #3320.

Thanks


Update introduction.md

🚀 Deployed on https://651ef9d90422640c5c9a1617--cozy-fox-0defec.netlify.app


allow Squash and RemoveSourceBranch in CreateMrRequest

Feature Description
Currently it's possible to squash commits and request the source branch to be removed when accepting a MR. I'd like to be able to specify these options already when creating a MR, so that I don't have to go to the website to do this.

Hi @harrisoncramer It seems that adding the parameters should be fairly straightforward. I'll be glad to submit a PR if you agree.

Yes, this would be a nice addition. Currently we do not support this at time of merging (glM) or creating (glO) an MR, or make it visible to the user in the MR summary. I'd be open to an MR that implements this. Might be worth considering adding settings that would allow the user to specify default behaviors for this as well.


Request: Support for FM RDS

FM RDS would be a great feature. It would be nice to see what the name of the song is that is playing (that is, if the station supports RDS).
Thanks!

Hi! A year or so ago I experimented with decoding RDS, but I couldn't make it work reliably. Perhaps now that I'm more knowledgeable about DSP I could pull it off, and I'll probably try again, but likely not in the near future :-)

Hi Jason, any chance you might be able to get to this?

No, I'm not really working on Radio Receiver anymore.


Add Stackbit Integration

This pull request add's Stackbit to this Jekyll theme. It add's the stackbit.yaml file which makes this theme work with several headless CMS automatically (including Forestry, NetlifyCMS, DatoCMS & Contentful) and it deploys the site to Netlify in 1 click.
You can try it out: https://app.stackbit.com/create?theme=https://github.com/stackbithq/startbootstrap-clean-blog-jekyll (note the "create with stackbit" button in the readme will import the theme from your repo so until the PR is merged it wont work)
I think this is really valuable and is a very low impact addition on your existing theme structure. Pretty much just the stackbit.yaml file. If you have questions or feedback I'm happy to discuss.
Darko

I think this is a very use-case-specific change and I would not want to stray too far from baseline Jekyll. Users can definitely reference this though if they want to integrate in this way.


Feature: release arm artifacts

arm is becoming a popular runtime, we should support arm based artifacts / CLI tools.
See https://github.com/pact-foundation/pact-js-core/issues/347 for background.

and it will perform better on Apple Silicon than dockerised amd64, considering Apple has dropped Intel

Is there any update on this? The current Rust based beta of pact-js is still failing to install in Linux/arm64.

If you have any proposals on how we can add an arm build we are all ears. GitHub actions doesn't yet support arm and we don't have access to an arm machine to run the builds on.
Amazon hasn't yet approved our access to use their arm instances to use as a GH hosted agent.

We already have aarch64 artifacts (Apple M1), which are cross-compiled on the OSX agents.
What other arm targets would we need to support?

linux arm64 artifacts, some people need to use docker desktop on Apple M*, and x86_64 emulation in docker can have problems with interoperability with other software needed in the same image.
Github Actions can use docker buildx to provide emulation in qemu if cross-compilation not possible directly. The artifacts can then be exported from the images.

For docker, you should be able to use --platform linux/amd64. See above, until we have a reliable way to compile for linux arm64 we can't produce shared modules.

as I said, this is when needing pact in the same image as other software, so that other software would have to be stable and performant on emulation, which it often isn't

Github Actions can use docker buildx to provide emulation in qemu to build targets if cross-compilation not possible directly. The artifacts can then be exported from the images.

Ah, sorry I missed this bit.
PR welcome :)

Just a quick note on cross-compiling, we are using the onig library to have compatible regular expressions with the original Ruby version of Pact. Onig requires a C compiler, so setting up cross compiling is a lot harder to do than with just Rust code (which seems to work ok).

Looks like cross-compiling using cross works.
pact-reference/rust/pact_ffi on  feat/arm64 [?] is 📦 v0.3.6 via △ v3.22.1 via 🦀 v1.62.1
❯ cross build --target  aarch64-unknown-linux-gnu
   Compiling proc-macro2 v1.0.43
   Compiling unicode-ident v1.0.3
   Compiling quote v1.0.21
   Compiling syn v1.0.99
   Compiling libc v0.2.129
   Compiling autocfg v1.1.0
.
.
.
    Finished dev [unoptimized + debuginfo] target(s) in 38.94s

pact-reference/rust/pact_ffi on  feat/arm64 [?] is 📦 v0.3.6 via △ v3.22.1 via 🦀 v1.62.1 took 1m
❯ ls -l ../target/aarch64-unknown-linux-gnu/debug/
total 1120356
drwxr-xr-x 39 ronald ronald      4096 Aug 15 11:57 build
drwxr-xr-x  2 ronald ronald     69632 Aug 15 11:58 deps
drwxr-xr-x  2 ronald ronald      4096 Aug 15 11:57 examples
drwxr-xr-x  6 ronald ronald      4096 Aug 15 11:58 incremental
-rw-r--r--  2 ronald ronald 724354670 Aug 15 11:58 libpact_ffi.a
-rw-r--r--  1 ronald ronald      2894 Aug 15 11:58 libpact_ffi.d
-rw-r--r--  2 ronald ronald  96193140 Aug 15 11:58 libpact_ffi.rlib
-rwxr-xr-x  2 ronald ronald 326599104 Aug 15 11:58 libpact_ffi.so

pact-reference/rust/pact_ffi on  feat/arm64 [?] is 📦 v0.3.6 via △ v3.22.1 via 🦀 v1.62.1
❯ file ../target/aarch64-unknown-linux-gnu/debug/libpact_ffi.so
../target/aarch64-unknown-linux-gnu/debug/libpact_ffi.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e8dc754d62f3a6fa1ff8e7a1ba85fc6cef6725d8, with debug_info, not stripped

I'll see if this works with the GitHub actions, but it should because it uses docker images to provide the target build environments.

Confirmed the cross-compiled library works with Pact-JS using an Ubuntu aarch64 VM on QEMU

Awesome - thanks! I'll create a tracking item for JS and Golang to implement.


Show docs for old version of package

Is your feature request related to a problem? Please describe.
we can display docs for old version packages when select a version in LastSync section. And also load all versions of a package in drop-down list so we can choose required version documentation rather currently supported last three versions and this change impacts other sections in package sidebar.so please provide some solution for this use-case.

@juanpicado Do you think that this issue to be good for the first issue? I would like to develop this improvement.

Sorry @kwarpechowski I did not see your message.
V4 will display all versions, but not navigation enabled yet. We are not storing all READMEs files, only the latest one. Store multiple files might require big changes and if someone is willing to do it, I'm cool, but I would enable it only by demand, I don't think this has to be enabled by default.

We will ship soon a new beta with this feature. Stay tuned. I'll close this one since is done in one of our branches.


Inject install config with proxy

In order to take advantage of the benefits the conduit proxy gives to deployments, this PR injects the conduit proxy into the control plane pod. This helps us lay the groundwork for future work such as TLS, control plane observability etc.
Fixes #311
Signed-off-by: Dennis Adjei-Baah<EMAIL_ADDRESS>

We need to add TestConduitInstall unit test that includes a golden file of what we expect the default output of conduit install to be. Then the reviewer (myself) can verify that the output is the same as conduit install | conduit inject and we'll be able to see in future reviews how each change to conduit install changes that output.

Ideally we should add this TestConduitInstall test as a separate PR, and rebase this PR on top of that one. That way this PR will include a diff of exactly what changes in the output of conduit install after these code changes.

@briansmith we have TestRender under install_test.go which has the bulk of the install code that generate which has a stripped down version of a golden test file. Does that suffice as a test for the install command?

@briansmith we have TestRender under install_test.go which has the bulk of the install code that generate which has a stripped down version of a golden test file. Does that suffice as a test for the install command?

To be a sufficient test, this PR should have had changes to testdata/install_output.golden. Since this PR didn't change install_output.golden, I think we either need a new test or we need to change TestRender and/or the implementation of of your code changes here. I don't care which strategy is used.

@briansmith I am curious to know, what is the priority order for the related PRs?

@briansmith I am curious to know, what is the priority order for the related PRs?

I would fix #303 first since that's a bug independent of this issue.
Then I would verify if conduit tap works and more generally whether the other integration tests work, and fix things if necessary.
Then I would do the localhost issue. (This might be part of getting the integration tests to pass.)

Looks like I was mistaken about the tap command. It works with the DNS name.

I think the localhost change needs to be merged directly after

I agree that we should do the localhost change regardless. However, it would be useful to know what is breaking minikube specifically since that seems surprising. From what I understand nothing should break, and the localhost change is not to fix anything but rather to avoid some overhead in metrics and networking, so if something is breaking now I'd like to know better what it is before we wallpaper over it with the localhost change.

What are the symptoms?

Symptoms seem to be exactly like #302 where nghttp the public or proxy api from a container within hangs indefinitely
root@controller-799c7d4ffc-zzxmr:/# nghttp -v http://api.conduit.svc.cluster.local:8086/api/v1/Report
[  0.001] send SETTINGS frame <length=12, flags=0x00, stream_id=0>
          (niv=2)
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
[  0.001] send HEADERS frame <length=58, flags=0x05, stream_id=1>
          ; END_STREAM | END_HEADERS
          (padlen=0)
          ; Open new stream
          :authority: api.conduit.svc.cluster.local:8086
          :method: GET
          :path: /api/v1/Report
          :scheme: http
          accept: */*
          accept-encoding: gzip, deflate
          user-agent: nghttp2/0.6.4
[  0.001] recv SETTINGS frame <length=0, flags=0x00, stream_id=0>
          (niv=0)
[  0.001] recv SETTINGS frame <length=0, flags=0x01, stream_id=0>
          ; ACK
          (niv=0)
[  0.001] send SETTINGS frame <length=0, flags=0x01, stream_id=0>
          ; ACK
          (niv=0)
^C

I can spend some time debugging what the issue is exactly. I spent a little bit of time trying to find the root cause a couple of weeks ago but wasn't able to come down to a root cause.

root@controller-799c7d4ffc-zzxmr:/# nghttp -v http://proxy-api.conduit.svc.cluster.local:8086/api/v1/Report

If I understand this correctly, you have SSH'd into a container in the controller, and you're trying to make an HTTP request GET http://proxy-api.conduit.svc.cluster.local:8086/api/v1/Report and that fails. OK.
Is the Conduit proxy bound to its external listening port? Did it accept the incoming connection? it seems like it must have since the TCP handshake was completed. Is the proxy itself stuck trying to find (via DNS) or connect to proxy-api.conduit.svc.cluster.local:8086? Has it connected to the underlying service (proxy-api pod, in this case)? These can be answered by kubectl log for the proxy container in that pod (I hope). Similarly, the kubectl log for the proxy-api container would be useful. Maybe proxy-api is having trouble discovering one of the internal components of the control plane?
Anyway, we're going to switch this to use localhost anyway, but it's still important to know why we have to--that is, why it is mandatory for correct operation instead of just a performance improvement.

That is correct. I ssh'd into the proxy-api container and tried to issue an HTTP/2 request to the proxy endpoint. Expected behavior is that it should send a GOAWAY frame since I am not sending any data along with the request.

Is the Conduit proxy bound to its external listening port?

This is just a guess but I am assuming this log lines
1519322727.927578 DBUG conduit_proxy::transport::so_original_dst "inbound", get_original_dst TcpStream { sys: TcpStream { inner: TcpStream { addr: V4(<IP_ADDRESS>:4143), peer: V4(<IP_ADDRESS>:50386), fd: 36 } }, selector_id: SelectorId { id: AtomicUsize(1) } }
1519322727.928783 TRCE conduit_proxy::inbound recognize local=<IP_ADDRESS>:4143 orig=Some(V4(<IP_ADDRESS>:9999))

indicate that the proxy is communicating with port 4143.

Is the proxy itself stuck trying to find (via DNS) or connect to proxy-api.conduit.svc.cluster.local:8086?

The proxy seems to be communicating with DNS just fine as it is able to resolve the proxy-api's DNS name.
1519322863.034206 TRCE conduit_proxy::dns "controller-client", resolve proxy-api.conduit.svc.cluster.local
1519322863.034552 INFO conduit_proxy::transport::connect "controller-client", DNS resolved proxy-api.conduit.svc.cluster.local to <IP_ADDRESS>

I plan to sync up with @seanmonstar to see if we both can figure out what the proxy is doing with the requests I am issuing. The proxy api logs don't seem to give anything actionable that we could use to debug the issue.

With help from @seanmonstar and the kubernetes docs, I was able to get this branch working on a minikube setup. While working with sean we came to the conclusion that the issue was due to some networking configuration in minikube. We tried to nghttp the controller proxy-api from the conduit-proxy with its clusterIP but that seemed to not work. When starting minikube with
minikube start --network-plugin=kubenet

I was able to run the above scenario without a hitch.  This walthrough page from Kubernetes helped in figuring out the solution. It mentioned something about setting up a nodes network to enable hairpin-mode
When looking through the minikube logs I notices the line
 Hairpin mode set to "promiscuous-bridge" but kubenet is not enabled, falling back to "hairpin-veth"

So I enabled the kubenet plugin for minikube and that seemed to do the trick.

Seems like this is probably: https://github.com/kubernetes/minikube/issues/1568
Given that this change breaks Conduit on minikube and minikube is one of our target platforms, I'd be more comfortable if the localhost change was part of this PR just so that we're not knowingly checking in broken code.

OK, if I understand this correctly, in order to work in the default mode of minikube, we have to use "localhost", right? That is, it really isn't optional.

Seems like this is probably: kubernetes/minikube#1568

Thanks!

Given that this change breaks Conduit on minikube and minikube is one of our target platforms, I'd be more comfortable if the localhost change was part of this PR just so that we're not knowingly checking in broken code.

I agree. Let's just merge #381 into this. (Make sure to address the recent feedback in #381.)

@briansmith @siggy I have added two new tests that test the new functionality that distinguishes between a controller pod in the control plane namespace. I have also done some minor refactoring in inject.go to make it more readable.


✨ Add support for Python 3.12, tests in CI and official marker

Great, thank you @ivantodorovich! 🚀


Unable to toggle between year and month selection when clicking on title

Describe the bug
If I click on the title bar of the overlay, I get the javascript error:
Cannot read property 'nativeElement' of undefined
To Reproduce
Steps to reproduce the behavior:

installed npm packages as required
setup everything as described in docs
Click on datepicker input field
Click on title
See error

Screenshot

Expected behavior
The overlay toggles between the year and months selection.
Versions (please complete the following information):

OS: macOS Mojave
Browser: Chrome 84.0.4147.135
Package Version [e.g. 1.2.3]: 8.0.6 (tried ^8.0.0)
Angular Version [e.g. 7.x]: 10

Additional context
I tried this on your examples (https://aavanzyl.github.io/ngx-tiny/project/date-picker, Angular Forms - Single Date) and there it happens sometimes, too.

@JLNNN I have updated to angular 10.. I think this was causing the issue a bit, have not yet been able to reproduce this, so still trying to solve this.

The same problem exists with v10.0.1.


What is the format of sending the event ？

hi , i want to send an event to Core Data. I query the document and find it hasn't been updated yet (I have cleared the browser cache). I also looked this up, but didn't know what format to send the event JSON.

Could you please tell me what the format is or tell me how to query ? Thanks.

Could you try the command docker logs edgex-core-data to see the error logs?

Could you try the command docker logs edgex-core-data to see the error logs?

I noticed that I missed the ApiVersion field, that's my fault. Thank you !!


libxdo-dev requirement is not documented for linux

Problem
We added muda to dioxus (as part of the wry upgrade) which brings the libxdo requirement with it, which we don't document.
We should document this.
https://github.com/tauri-apps/muda

Fixed by https://github.com/DioxusLabs/docsite/pull/214
Thanks @jonnyandrew


[Snyk] Security upgrade com.amazonaws:aws-java-sdk from 1.12.318 to 1.12.325

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `maven` dependencies of this project.
:sparkles: Snyk has automatically assigned this pull request, set who gets assigned.
As this is a private repository, Snyk-bot does not have access. Therefore, this PR has been created automatically, but appears to have been created by a real user.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

uasdm-server/pom.xml

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Upgrade
Breaking Change
Exploit Maturity

712/1000  Why? Currently trending on Twitter, Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 5.9
Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-3038426
com.amazonaws:aws-java-sdk:  1.12.318 -> 1.12.325
No
Proof of Concept

399/1000  Why? Has a fix available, CVSS 3.7
Information Exposure SNYK-JAVA-COMMONSCODEC-561518
com.amazonaws:aws-java-sdk:  1.12.318 -> 1.12.325
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
👩💻 Set who automatically gets assigned
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Denial of Service (DoS)

Out of date


Updated module to use new environment label value

/codefresh run test

/codefresh run test

Thanks for the review! That space around the equals thing has been plaguing me for a while.

/codefresh run test

@tthayer
TestExamplesComplete 2020-04-29T21:42:03Z command.go:121: Error: Unsupported argument
TestExamplesComplete 2020-04-29T21:42:03Z command.go:121:
TestExamplesComplete 2020-04-29T21:42:03Z command.go:121:   on ../../main.tf line 178, in module "autoscale_group":
TestExamplesComplete 2020-04-29T21:42:03Z command.go:121:  178:   environment = var.environment
TestExamplesComplete 2020-04-29T21:42:03Z command.go:121:
TestExamplesComplete 2020-04-29T21:42:03Z command.go:121: An argument named "environment" is not expected here.
T

/codefresh run test

/rebuild-readme

/test all

/terraform-fmt

@tthayer bump


corrupt - ccm: tag doesn't match

Hii,
I installed up1 on two different servers and tested it with two different browsers & devices.
Server and client API-Key in the config are unchanged (and equal).
Sadly I can't get it to work :(
Are there any known fixes to this?

Followed those instructions, which are almost the same as the instructions from your readme:
https://lab.uberspace.de/guide_up1.html


Assembler::CheckCodePointer messes with the stack frame layout and breaks the profiler in debug builds

@fsc8000

Which instances of CheckCodePointer do you mean?

X64, ARM, ARM64, and MIPS all push something onto the stack before the frame is setup. This subtly breaks the profiler.


Publish npm dist as rc when comming from master

Currently we publish dists as latest when coming from master.
This PR will tag those dists as rc (preprod dist).
And we will have to make them as latest dist once it's QA tested.

👍
shipit!


Hubgets- Link-ul "targhertare" is missing

ENVIRONMENT: PROD
URL: https://scrapers.peviitor.ro/src/hubgets/
browser: Chrome
STEPS TO REPRODUCE:
1)open URL in the browser
2) go to the "Hubgets" logo and check the link for "targhetare"
EXPECTED RESULTS:
"targeting" link appear
ACTUAL RESULTS:
the link is missing

Nu exista firma pe targetare


--fullpath flag to show full path only when wanted

To make it more readable and simple, by default the paths in the changes we show after a file movement in the command line should include only the filename or the directory, covering some details. If the user wants he will use --fullpath flag when using the command. I hope that's clearer if not comment right a way.

Feature not required


Refactor customUpdate hooks

Issue #, if available: N/A
Description of changes: The goal of this refactor is to align customUpdate hook code across resources so the codebase is easier to read and maintain. Changes to make the code more consistent include:

rename hook.go to hooks.go
return updated resource in customUpdate with comments
elevating API calls to customUpdate (i.e. moving addRulesToStatus out of sync)
rename methods to be more explicit about underlying API calls (i.e. addRulesToStatus --> sdkFindRules)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/retest
needed to cleanup account

/retest