on operator restart, some GETs fail with 404

If you restart the operator while there are existing kdclusters, the manager will immediately fire off reconciler handlers to process those existing resources.
If this is a mildly "busy" K8s with a not completely trivial number of resources, I've noticed that this first reconciler pass can fail in odd ways because of 404 results when it tries to fetch various resources (both CRs and native-K8s). Subsequent handlers are then OK.
My first thought is that this is related to the "caching client" that the manager sets up for us to use. I do see our code logging that mgr.GetCache().WaitForCacheSync has completed before any of the manager controller and workers even start. I believed that this meant the client was now aware of the current set of resources in the cluster but maybe not.
This isn't a functional showstopper since each handler should be robust to the client telling it that something doesn't exist when it actually does. Worst case = we try to re-create an object, fail, and the handler exits to try again later. Subsequent handler invocations always seem to be fine.
However it makes the logs look ugly after restart, hiding possible actual bugs.
I've found that I can prevent almost all occurrences of this in my test clusters by having the reconciler handler do a test read of the KD deployment resource first, just to make sure that the K8s client is live. Sometimes even with this in place though I do see a bogus "not found" result on an initial handler pass, so that does still make me think that it's a matter of the cache still being gradually populated (even after waiting a second or two) rather than the client just being generally not live yet.
That being the case, "GET the KD deployment" may not be the most reliable sanity check since who knows when it might arrive in the cache relative to other objects. Maybe I should just do a general wait of several seconds on the first handler pass.
The real/best solution is to figure out what is really up with the client and/or cache, but the 0.4.0 release doesn't need to be blocked on that.

It can be more problematic than I thought. If reconcile fails to GET a statefulset that should be backing a role, it puts those members into delete-pending state to be able to send notifies about them to all other ready nodes. The way that the members reconcile logic work, this means that if a future handler pass then DOES find the statefulset, it will shrink it to 0 to reconcile it with the current "desired" state of the members. After those shrinks are done, we can go back and take a look at the spec to see the next desired state, which resizes the statefulset back out to its original size.
If PVs are being used this is not a harmless operation, because the intentional shrink will also cause PVC to be deleted (and therefore PVs). So the statefulset returns to its original size but has lost important on-disk state.
The handlers need to be robust against the cached reads lagging behind reality, but in this case the cached read is showing us a discontinuity. We had previously created the statefulset (and stored that fact), but now the read says it has gone away. That's alarming.

Waiting for some amount of time does not help. The first handler after restart is always susceptible to bogus 404s.
For now I'm going to rearrange our GET calls so that they fall back to a non-cached client on a 404 from the split client.

Removing the milestone on this one and lowering priority since we have a workaround.

Doesn't seem to be a resolution for this imminent in the split-client code, and we have a workaround, so closing this.


cmd/godoc: redundant results from pkg/bootstrap

What version of Go are you using (go version)?

tip (go:d68f52a tools:264bffc)
What operating system and processor architecture are you using?

linux/amd64
What did you do?

http://localhost:6060/search?q=notwithstanding
What did you expect to see?

result from /src/cmd/internal/gc/lex.go
What did you see instead?

result from /src/cmd/internal/gc/lex.go
additional redundant result from /pkg/bootstrap/src/bootstrap/internal/gc/lex.go (with a broken link too)
I'd suggest to exclude /pkg/bootstrap (or perhaps the entire /pkg tree) from indexing. Installing a Corpus.IndexDirectory filter function seems like a straightforward way to implement it.

Sent https://golang.org/cl/7267 with the proposed approach. Now that tip.golang.org has search enabled, the problematic behavior can also be observed there; e.g. https://tip.golang.org/search?q=notwithstanding


do not save multiple profiles with the same date

If a reporter updates an inventory record, it will fire an "updated
record" message on the egress topic. However, not all of these updates
actually update the system profile. This results in duplicate system
profiles in the historical DB.
This change to the archiver checks to ensure a record does not already
exist before saving it to the DB.
We could do this more elegantly via a DB uniqueness constraint;
however this way does not require a data migration to clean old
records. We may eventually want to add a constraint once the data is
unique.
Note that this does not do the select and insert in the same
transaction.  I don't anticipate issues arising from this since the
"fail" case (which should be rare) is that we insert two records which
is the current behavior.  Adding a constraint would also let us avoid
having to add a transaction with a select and insert.

Codecov Report

Merging #71 into master will increase coverage by 8.65%.
The diff coverage is 52.00%.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
+ Coverage   50.14%   58.79%   +8.65%
==========================================
  Files          13       13
  Lines         357      398      +41
==========================================
+ Hits          179      234      +55
+ Misses        178      164      -14

Impacted Files
Coverage Δ

historical_system_profiles/archiver.py
0.00% <0.00%> (ø)

historical_system_profiles/deleter.py
0.00% <0.00%> (ø)

historical_system_profiles/listener_metrics.py
0.00% <0.00%> (ø)

historical_system_profiles/db_interface.py
68.29% <20.00%> (+1.62%)
:arrow_up:

historical_system_profiles/config.py
94.44% <100.00%> (+0.50%)
:arrow_up:

historical_system_profiles/views/v1.py
98.57% <100.00%> (+31.90%)
:arrow_up:

historical_system_profiles/models.py
94.44% <0.00%> (+24.07%)
: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 fd99404...c23062e. Read the comment docs.

Is it possible to have a unit test that covers this ?

ya I can add a test to confirm the save doesn't fire if the date is duplicated


merge from arlac77/npm-package-template-esm-only

.travis.yml

chore(travis): (jobs.include)
chore(travis): add 13.0.0 (jobs.include.node_js)
chore(travis): (script)

:tada: This PR is included in version 3.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Every example fails with an Assertion Error

I am currently experimenting with this tool / library, but every example that I want to try fails with the following assertion error:
a.out: /path/to/easy-just-in-time/runtime/pass/InlineParameters.cpp:31: easy::HighLevelLayout GetNewLayout(const easy::Context &, easy::HighLevelLayout &): Assertion `C.size() == HLL.Args_.size()' failed.

Since I have no Idea about the internals of this project I do not know what to do. Do you have any idea whats wrong (or what I am missing?)?
Additional Information:

Happens during the call of easy::jit

Command used to compile the tests: clang++ --std=c++14 test.cpp -Xclang -load -Xclang /path/to/easy-just-in-time/build/bin/EasyJitPass.so   -I /path/to/easy-just-in-time/include   -L /path/to/easy-just-in-time/build/bin -lEasyJitRuntime -stdlib=libc++

Hi Marius. Thanks for posting the Issue.
Do the tests of the library compile?
Can you show me the code that you're trying to compile?

No the library tests did not work either I think....
I used the following code to test:
#include <iostream>
#include <easy/jit.h>

using namespace std;

static void EASY_JIT_EXPOSE kernel(const int a, const int b, int  * const res)
{
    for(int x = 1; x < a; x++)
    {
        for(int y = 1; y < b; y++)
        {
            *res += a*b - b
        }
    }
}

int main(int argc, char **argv)
{
    int res = 0;
    kernel(1000, 250000, &res);

    using namespace std::placeholders;
    auto kernel_opt = easy::jit(kernel, 1000, 250000, _1);
    kernel_opt(&res);

    cout << res << endl;
    return 0;
}

It works for me in my local configuration. I created a pull request where I added the code as a new test to see what the Continuous Integration says.
What version of the llvm are you using?

As I am using a pretty old Debian System, I build a custom LLVM 6.0.1

That's strange.
Could you try to send me the generated CMakeCache.txt ?
And also compile the previous code that you send with the options -S
-emit-llvm to obtain an .ll and send it to me. The command line should be
something like "clang -S -emit-llvm -I /easyjitdir/include issue_43.cpp -O2
-o issue_43.ll" .
Thanks for the help!
On Thu, 21 Feb 2019 at 15:37, Marius Messerschmidt<EMAIL_ADDRESS>wrote:

As I am using a pretty old Debian System, I build a custom LLVM 6.0.1
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/jmmartinez/easy-just-in-time/issues/43#issuecomment-466022812,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5536WClF_dUFqcTU2ZeIijuuAlcrRlks5vPq8-gaJpZM4bG0Vf
.

Sorry that it took so long, but here are the files that you requested.
CMakeCache.txt
issue_43.ll.gz
(I had to gzip the LLVM file, as GitHub would reject it otherwise)

is there still activity in this?

Sorry for the delay @mame98 . I wasn't able to reproduce it, and I did not have enough time to test with more configurations to see if I could trigger the error.


MLGST log-likelihood _objective_func_probs functions take vectorGS …

Pretty sure someone must have split up these functions without realizing they needed vectorGS in scope.
Was causing test.test_packages.algorithms.testCore.TestCoreMethods.test_MLGST to fail

(I wanted this reviewed because I'm not 100% sure this was the intended functionality)

Made redundant by a8992a10585e4752d6fcc803777e8159fb9da15b -- ignore me!


Updated titles

Did a mass check for typos in titles and ids of entity components and behaviors
Additionally, added information for knockback_resistance after testing and for navigation.walk

Resolved the conflicts and made a small mistake, but fixed now I believe


js/ts ci

Current Behavior
no ci
Proposed Behavior

[ ] add js/ts lint ci
[ ] add compile checker
[ ] add ui release

#262


Bug Report: Game crashes

When compiling, it just crashes when I run it.

More info please? Like console logs and screenshots.

Closing due to inactivity.


TreeDataProvider/TreeItem does not process item's command's tooltip

VSCode Version: 1.14.2
OS Version: Win10-x64

Steps to Reproduce:

Use VSCode tree-view-sample
Add tooltip to the initialization of the tree node via the command object:
https://github.com/Microsoft/vscode-extension-samples/blob/master/tree-view-sample/src/nodeDependencies.ts#L86-L93

super(label, collapsibleState);
// add code below
this.command = {
	command: 'vscode.open',
	title: 'test command',
	tooltip: 'My Tooltip.....',
	arguments: [Uri.file('some file')],
};

Observe tooltips rendering item's title instead of the tooltip value.

It seems like there is no any work around for showing a custom tooltip for a tree-view extension.

@oleg-shilo Entries shown in the tree view correspond to the items contributed. They are not commands of the items. Hence the tooltip always show the title of the item. Item command is an action to be executed when user selects the item.

Sorry, I understand your logic but it's hard for me to see any valid reason for rejecting this issue.
I understand that the appearance and the action of the item are not the same thing. I appreciate that you may have reservations against reusing the "action tooltip" instead of an "item tooltip". But the truth is that the item just does not have an API for a tooltip. And this is the primary problem.
VSCode in all native tree-views does support visual paradigm allowing the item title and the tooltip to be different. See image below:

But the custom tree-view does not. And... there is no way around.
If you believe that tunneling the "action tooltip" is not the way then please consider reopen the issue as a feature request. I can create a separate dedicated feature request if it helps.
Thank you.

@oleg-shilo Good point. I agree that contributed item miss tooltip. Re-opening it.

Excellent. Thank you. The item is still closed though :)

Any way to get this bumped up -- I would love to be able to customize the tooltip of tree items. For example in GitLens, I truncate the tree item to not show the full commit message (because that would be nuts), but it would be great to have the tooltip contain the full message.

+1

Would also love this for the extension I’m working on.

Noooo, not the backlog ;)

@eamodio I have to bring it up my backlog features in our planning meeting to commit for a milestone.
We have this feature for this milestone.

Hehe. Sweet - thank you!


Swap node internal packages out for fetch in Resource

Description
Working on updating cesium-webpack-example and creating cesium-vite-example I realized there are 2 main sticking points to using Cesium in various JS build environments.

Copying the required static files for workers (https://github.com/CesiumGS/cesium/issues/10619)
Marking select node modules as external, http, https, url and zlib, which are only used in Resource.js when on node

This PR aims to remove that second point by swapping out the "node only" logic for fetch() which has been enabled by default since Node v18.
As far as I can tell I was able to mimic the existing behavior except for one issue with an error that's thrown. There's currently no Specs set up for running in a Node environment so running the smoke screen tests Specs/test.cjs and Specs/test.mjs was the only way to verify and that works correctly.
I'd really appreciate more eyes on this as I know Resource is a fairly core class to cesium and I don't want to negatively impact anything.
Issue number and link
No issue
Testing plan

run node Specs/test.cjs
run node Specs/test.mjs

Author checklist

[x] I have submitted a Contributor License Agreement
[x] I have added my name to CONTRIBUTORS.md
[ ] I have updated CHANGES.md with a short summary of my change
[ ] I have added or updated unit tests to ensure consistent code coverage
[ ] I have update the inline documentation, and included code examples where relevant
[ ] I have performed a self-review of my code

@ggetz @jjhembd updated with pr comments. I wasn't sure if this counts as a breaking change or not but put it under that category anyway because it does affect build tools.

Thanks @jjspace! I'll take a final pass on this shortly.

I wasn't sure if this counts as a breaking change or not but put it under that category anyway because it does affect build tools

I agree this counts as a breaking change and should be listed as such.

Looks good @jjspace. I have tested the packed npm module locally as well. Everything is working as expected!


x/playground: formatting a modern go.mod file fails incorrectly with "invalid go version"

Consider a playground snippet that includes a go.mod file as if generated by go mod init play.ground using the latest stable version of Go: https://go.dev/play/p/ZtkN19wIOev.
Pressing the "Format" (not "Run") button fails with an incorrect error message:
go.mod:3: invalid go version '1.22.0': must match format 1.23

I suspect this might be fixed if x/playground is updated to a more recent version of x/mod. It's currently using v0.9.0.
(Most x/ repos get automatic monthly updates of x/ dependencies, but x/playground is currently skipped because of #24823. So fixing that might also indirectly fix this issue.)
Issues #32980 and #32614 are also related.

This was indeed fixed by CL 566275.


Doesnt work with the new smartthings mobile app, it doesnt show "RingAlarm" as a device

Resolved by adding the device manually using https://graph-na02-useast1.api.smartthings.com -> My Devices - Add new device -> Pick RingAlarmV2 for Type

Thanks for the update. I haven't checked this with the new app as I am still on the classic version.


Listening 2.0

This is an epic that can contain thoughts/suggestion on improving any listening related functionality.
This is only for Features and Enhancements, bugs should be raised as individual issues.

https://github.com/deepstreamIO/deepstream.io/issues/338

Listener Groups
Load Balancing Strategies
"change mind"

In regards to "change mind" I would like to be able to do this:
Observable.defer(() => Observable.create(o => {
  // Fetch next job
  const callback = (match, isSubscribed, response) => {
    if (isSubscribed) {
      response.accept()
      o.next(match)
      ds.record.unlisten(jobPattern, callback)
    }
  }
  ds.record.listen(jobPattern, callback)
}))
.mergeMap(match => {
  // Process job if not already done...
}, null, 4)

@yasserf: Not sure where this is documented. But will the server retry un accepted records:

A: when a new listener register
B: retries all rejecting listeners after a timeout?

Listening was simplified massively in V4, and added a rematchInterval. Currently it just randomly selects providers and its a free grab for all with a distributed lock system when in a cluster (any server can provide the subscription, may be less efficient than previous where it was always on the same node). Will open an issue at some point to allow stopping providing a subscription. Would be cool to do this:
ds.record.listen ((name, response) => {
  response.onStop(() => {
    const record = ds.record.getRecord(name)
    record.on('hasProvider', () => {
      // actually stop. This allows the user to ensure you can close a micro service without actual downtime
      record.close()
    })
  })
  setTimeout(response.stop, 5000) // stop for some reason)
})


Storing a ShapeHandle in a struct.

Currently trying to integrate the masterpiece that is nphysics into my component-entity style game engine and having difficulty finding a way to wrap the ShapeHandle instance in a struct that fits the trait bounds required by RigidBody::new(). Currently my struct looks like:
#[derive(Clone)]
pub struct RigidBody {
    shape: ShapeHandle<na::Point3<f64>, na::Isometry3<f64>>,
    body_type: BodyType,
}

But when I attempt to pass this shape handle to create a new RigidBody I get the following:
error[E0277]: the trait bound `ncollide::shape::ShapeHandle<nalgebra::Point<f64, nalgebra::U3>, nalgebra::Isometry<f64, nalgebra::U3, nalgebra::Unit<nalgebra::Quaternion<f64>>>>: nphysics3d::volumetric::Volumetric<_, nalgebra::geometry::point::PointBase<_, nalgebra::core::dimension::U3, nalgebra::core::matrix_array::MatrixArray<_, nalgebra::core::dimension::U3, nalgebra::core::dimension::U1>>, nalgebra::core::matrix::Matrix<_, nalgebra::core::dimension::U3, nalgebra::core::dimension::U3, nalgebra::core::matrix_array::MatrixArray<_, nalgebra::core::dimension::U3, nalgebra::core::dimension::U3>>>` is not satisfied
  --> src/physics/physics.rs:72:25
   |
72 |                         Body::new_dynamic(body.shape.clone(), dens, res, fric)
   |                         ^^^^^^^^^^^^^^^^^ the trait `nphysics3d::volumetric::Volumetric<_, nalgebra::geometry::point::PointBase<_, nalgebra::core::dimension::U3, nalgebra::core::matrix_array::MatrixArray<_, nalgebra::core::dimension::U3, nalgebra::core::dimension::U1>>, nalgebra::core::matrix::Matrix<_, nalgebra::core::dimension::U3, nalgebra::core::dimension::U3, nalgebra::core::matrix_array::MatrixArray<_, nalgebra::core::dimension::U3, nalgebra::core::dimension::U3>>>` is not implemented for `ncollide::shape::ShapeHandle<nalgebra::Point<f64, nalgebra::U3>, nalgebra::Isometry<f64, nalgebra::U3, nalgebra::Unit<nalgebra::Quaternion<f64>>>>`

Which makes sense as I have not ensured that the specific incarnation of ShapeHandle I am using fits the bounds of that function. What I am curious about is the best approach to get around this. Will I simply have to parameterize my struct in order to ensure these same bounds are met?

Assuming the Body type here is an alias for the nphysics' RigidBody type, the issue here is that ::new_dynamic expects to be given a concrete shape type that implements some traits, including Volumetric (i.e. not a trait-object which is what ShapeHandle are).
So if you which to create a rigid body from a ShapeHandle, you have to use the Body::new method. It won't automatically compute the mass properties of the shape so they must be input to the new function.

@sebcrozet: Works perfectly, thanks!


Add links to dropdowns

Is it possible to add links into a dropdown menu button?
For example like in the blogroll of this page:
https://kkulma.github.io/aboutblog/

Yes, this is documented on the Academic documentation website.


Limits the ressources available for the container

In order to avoid too much pressure on rpi memory (and eventually a crash) this PR is fixing hard limits on containers' resources.
These limits are calculated thanks to a batch script which is launched when using the "make run" command
The limits: keyword is available only in the V3 of docker-compose

@MateoLostanlen sorry I thought that it would be very small and there is already so much PR open so that I prefered move forward

@RonanMorgan what do you mean you're not going to continue with this PR?

TODO : if we use the precommit hook, we should remove the linting part in the makefile and also clean up the workflows...


MXKRoomDataSource: Support server sync v2.

Reload data source when the local history has been flushed on limited timeline room sync.

Related to https://github.com/matrix-org/matrix-ios-sdk/pull/23

LGTM


Supporting GTK4

Maybe you don't want to merge this. Read carefully.
I updated to Ubuntu 21.10, which is based on GTK4. I found that this Gnome extension didn't work because of that, and that nobody was around to fix that. So I gave it a try, and it's working.
There is one major bug with this currently as far as I could find: When changing the provider, the provider page doesn't update. You'd need to disable and re-enable the extension to make it update. I don't really have any experience with GTK but I'm decent at fiddling. I could probably fix that issue at some point if I get around to it, but I really don't have much of an idea of what I'm doing. The only front-end framework I've really used is Qt. So I'm also publishing this PR as a draft in the hope that someone comes around to see what I did wrong.
I didn't test it, but this change probably means that older versions of GTK are not supported any more. And that's a problem with many people still on GTK3 (especially since Ubuntu LTS still is). This could be a reason not to merge this and perhaps split the code bases permanently.
I know you don't want to maintain this extension any more though, so there's a couple of things we can do (after that bug is fixed):

You could just merge it, upload a new version on extensions.gnome.org. However that means that people on GTK3 won't be able to use it.
You could try and make it work for both GTK3 and GTK4. It's probably possible. I'm not up for that task though.
I'm also willing to take over the project permanently as a maintainer. I maintain several other small projects like this. However when I do that, I'd Keep It Simple, Stupid and probably delete/hide the whole mechanism of extensible providers as soon as the first bug with that is discovered, just have it put up random files from a folder. That's what I'm using it for anyway. I would publish that as "v3" of the extension, just like you did as "v2".

I'm not in it for the fame or anything. Just want to help.

I have no plans to go back to Gnome again, so you're more than welcome to take the project over.

https://github.com/ssk101/gnome-wallpaper-changer-v2/pull/6
@Ghostkeeper If you rename/delete your fork I can transfer the repo to you.

Okay, will rename it then.

Okay, will rename it then.

Looks like you'll have to delete the fork for a transfer to work, actually.

Right. It's deleted now.
I still have the commits in a local clone (and I'm actively using it right now), in case your PR doesn't survive the transfer.

I'm sorry, the transfer apparently expired. Could you try again?

I'm sorry, the transfer apparently expired. Could you try again?

Done


Add missing listener suggestion to the default unhandled error message

This pull request improves the default warning message for unhandled requests by printing suggested code snippets as below:
$ python examples/socket_mode.py
⚡ Bolt app is running!

Unhandled request ({'token': 'xxx', 'team_id': 'T111', 'api_app_id': 'A111', 'event': {'client_msg_id': 'xxx', 'type': 'message', 'text': 'Hi there!', 'user': 'U222', 'ts': '1620202537.001600', 'team': 'T111', 'channel': 'C111', 'event_ts': '1620202537.001600', 'channel_type': 'channel'}, 'type': 'event_callback', 'event_id': 'Ev111', 'event_time':<PHONE_NUMBER>, 'authorizations': [{'enterprise_id': None, 'team_id': 'T111', 'user_id': 'U222', 'is_bot': True, 'is_enterprise_install': False}], 'is_ext_shared_channel': False, 'event_context': '1-message-T111-C111'})
---
[Suggestion] You can handle this type of event with the following listener function:

@app.event("message")
def handle_message_events(body, logger):
    logger.info(body)

With this suggestion, developers, particularly the ones new to bolt-python, can easily understand what to do for handling the requests in their app. This pull request covers all the possible patterns with corresponding code snippets. Refer to the added unit test code (tests/slack_bolt/logger/test_unmatched_suggestions.py) to learn the actual suggestion messages.
If a developer does not want to have the message, we would recommend having raise_error_for_unhandled_request=True in the App/AsyncApp constructor arguments and having their own global error handler (see "Customize Unhandled Error Handling" in the v1.5.0 release notes for more details).
Category (place an x in each of the [ ])

[x] slack_bolt.App and/or its core components
[x] slack_bolt.async_app.AsyncApp and/or its core components
[ ] Adapters in slack_bolt.adapter
[ ] Document pages under /docs
[ ] Others

Requirements (place an x in each [ ])
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've run ./scripts/install_all_and_run_tests.sh after making the changes.

@stevengill

Only question I have is that we are logging req.body for unhandled requests. In Bolt-js, usually we have stayed away from logging this in case folks are piping logs to some system and don't want sensitive information such as token in their logs. Are you concerned about that?

Thanks, this is a good point. Basically, I don't think logging request payloads is a problem as payloads do not have any access tokens and credentials. Payloads can include the legacy verification token (we don't recommend using anymore and Bolt relies on only signature verification) and confidential data in text messages. I don't think we call these data as credentials. For this reason, I think logging the payload in debug-level logging does not have any issues as we already do in Bolt for JS's Developer Mode.
With that being said, this logging is warning-level and it's not easy to omit only the log if a developer has to eliminate the possibility of including confidential information in product app logs. I will adjust the log message for this warning-level log and will add another debug level log for knowing the whole payload (in the development phase). Thanks for the great input 👍


Close all buffers?

I'm trying to get my vimrc to work as a terminal multiplexer like tmux. Basically I want to map qa to Bufdel all so that terminals will get closed properly but it will still complain about files with pending edits.

Awesome, I appreciate it!


use  elements for author photo

Deploy preview for pixelsonly-production processing.
Built with commit 98417c41699f3b8ff7de1134da7f9f9c80137da5
https://app.netlify.com/sites/pixelsonly-production/deploys/5a81188d295b5556407c15c4


Tomatos can float in the air

Destroying dirt under tomato vine doesn't break the wine itself, so it continues to grow in the air.

Loader: Fabric 0.15.7
Minecraft: 1.20.1
Farmer's Delight: 1.4.3

Is this always the case? Or just some times?

And did you destroy the dirt with a tool, or with commands?

Is this always the case? Or just some times?

Always

And did you destroy the dirt with a tool, or with commands?

Just by hands.

We'll have to look into this.


Serialize ids as strings

@rudigiesler ready for review

Looking at the IntegerField implementation, I'm wondering if we should inherit from that instead: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/fields.py#L818 , and just replace its to_representation command with the one above, since it does some other useful checks (like guarding against malicious strings, and descriptive error messages).
At the moment we won't use any of these, since it's a read only field, I just think it would be nice to guard against it if in the future we use the field in a non read-only matter.

Also, I think maybe the docs need to be updated? Other than that, looks good to me :)

@rudigiesler ready for review

:+1:


chore: Added JSON Schema input processor and tests

Description
This PR adds the input processor for JSON Schema together with integration tests.

@magicmatatjahu should the CommonInputModel models property be a map of models instead of an array? 🤔 Easier to lookup

@magicmatatjahu should the CommonInputModel models property be a map of models instead of an array? 🤔 Easier to lookup

@jonaslagoni Yeah, sure :) But what we'll use as a key?

@jonaslagoni Yeah, sure :) But what we'll use as a key?

@jonaslagoni Yeah, sure :) But what we'll use as a key?

Should be the name/id of the model. We might end up with duplicated ids which we need to figure out how to handle, but we would have to do that with an array anyway 😄

@jonaslagoni Yeah, sure :) But what we'll use as a key?

Should be the name/id of the model. We might end up with duplicated ids which we need to figure out how to handle, but we would have to do that with an array anyway 😄

@magicmatatjahu it is ready to be reviewed 😄

@magicmatatjahu it is ready to be reviewed 😄


S32Z: Add I2C driver over I3C HW IP

The I3C IP on S32Z device only support I2C mode, this PR introduces I2C driver for this device.
Due to some internal issues, the IP does not support I3C functionality, only I2C
Tested with tests\drivers\eeprom

The I3C IP on S32Z device only support I2C mode

I don't understand this here... An i3c IP that only supports I2C? Does this 'not' support i3c, but it's called i3c? I'm rather confused here
The I3C API already supports the I2C API nested within it. If this does support I3C, it would be implemented under the i3c/ with all the functions that are already implemented here just within the i2c_api struct within the i3c_driver_api

Hi @XenuIsWatching, right the IP is named I3C, but due to some internal issues, the IP does not support I3C functionality, only I2C, I updated PR description.

The I3C IP on S32Z device only support I2C mode

I don't understand this here... An i3c IP that only supports I2C? Does this 'not' support i3c, but it's called i3c? I'm rather confused here
The I3C API already supports the I2C API nested within it. If this does support I3C, it would be implemented under the i3c/ with all the functions that are already implemented here just within the i2c_api struct within the i3c_driver_api

Hi @XenuIsWatching, right the IP is named I3C, but due to some internal issues, the IP does not support I3C functionality, only I2C, I updated PR description.

Oh wow 😮 , that's unfortunate.... but I wouldn't call an I3C device 'fully' compatible with I2C, there are some limitations, but still covers >90% of existing i2c devices out there. Is there a public errata on that?
Also, IIRC you had a PR from while ago, but I was on leave during that time about an issue where you've got only an I2C device (that at24 eeprom) on an I3C bus (without any other I3C devices) that is what is 'forcing' you have this under I2C. I did take a quick look at this just now with https://github.com/zephyrproject-rtos/zephyr/pull/75979. Hopefully that solves your issue 😄 .

The I3C IP on S32Z device only support I2C mode

I don't understand this here... An i3c IP that only supports I2C? Does this 'not' support i3c, but it's called i3c? I'm rather confused here
The I3C API already supports the I2C API nested within it. If this does support I3C, it would be implemented under the i3c/ with all the functions that are already implemented here just within the i2c_api struct within the i3c_driver_api

Hi @XenuIsWatching, right the IP is named I3C, but due to some internal issues, the IP does not support I3C functionality, only I2C, I updated PR description.

Oh wow 😮 , that's unfortunate.... but I wouldn't call an I3C device 'fully' compatible with I2C, there are some limitations, but still covers >90% of existing i2c devices out there. Is there a public errata on that? Also, IIRC you had a PR from while ago, but I was on leave during that time about an issue where you've got only an I2C device (that at24 eeprom) on an I3C bus (without any other I3C devices) that is what is 'forcing' you have this under I2C. I did take a quick look at this just now with #75979. Hopefully that solves your issue 😄 .

Unfortunately, the errata document is not public.
Beside that one, there is another issue that is in order to build the i3c mcux driver (https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/i3c/i3c_mcux.c), i have to define a lot registers (mostly for I3C functionality) which are not available on I3C IP on this device (see https://github.com/zephyrproject-rtos/hal_nxp/pull/310/files). If just using I2C API (inside the i3c mcux driver) at this moment, these unavailable registers are seems not touched but i'm not sure what could be changed in the future.

Beside that one, there is another issue that is in order to build the i3c mcux driver (https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/i3c/i3c_mcux.c), i have to define a lot registers (mostly for I3C functionality) which are not available on I3C IP on this device (see https://github.com/zephyrproject-rtos/hal_nxp/pull/310/files). If just using I2C API (inside the i3c mcux driver) at this moment, these unavailable registers are seems not touched but i'm not sure what could be changed in the future (e.g inside init function).

I3C hw IP is the same as the one already supported through MCUX-SDK driver. Each chip might include device-specific integration options at the time of instantiating the hw IP, so not all registers might be present in all devices for the same hw IP. MCUX-SDK is not made for NXP S32 devices, so adaptions are needed to make it work, as it has been done for many of other peripheral drivers on these devices.
The alternative to the proposed changes on this PR, that aims to keep a single I3C driver for all NXP devices, is to:

reuse existing I3C driver (https://github.com/zephyrproject-rtos/zephyr/pull/65265)
submit patches to MCUX-SDK to support S32Z I3C variant which may have not all registers defined (https://github.com/zephyrproject-rtos/hal_nxp/pull/310), e.g. by adding I3C_FEATURE_HAS_* macros and guarding offended code
document the hw errata and limitation in board's documentation so that user is aware I3C on this device is not working as expected.

hi @XenuIsWatching, we need to get this through to enable I2C communication on this board.
@Dat-NguyenDuy will close this PR and re-open another with an implementation similar to https://github.com/zephyrproject-rtos/zephyr/pull/65265 (reuse existing I3C driver, document errata in board's doc to use only I2C within I3C API). But we need your changes merged on https://github.com/zephyrproject-rtos/zephyr/pull/75979. Any plan on completing this work, or else we can help getting that through as well? Thanks

hi @XenuIsWatching, we need to get this through to enable "I2C" communication on this board.
@Dat-NguyenDuy will close this PR and re-open another with an implementation similar to #65265 (reuse existing I3C driver, document errata in board's doc to use only I2C within I3C API). But we need your changes merged on #75979. Any plan on completing this work, or else we can help getting that through as well? Thanks

I just pushed up another way of 'hopefully' getting something that'll work and should pass all the checks

Closing this PR, will open the alternative implementation


Notes/TODOs Hugo 0.123.0

Front matter vs params
title
linkTitle
type
layout
markup
weight
date
lastmod
publishDate
expiryDate
slug
url
description
summary
draft
headless
isCJKLanguage
keywords
aliases
cascade
outputs
resources
translationkey
sitemap
build (or _build, rename)
REMOVE? taxonomies
Move to params:
audio
videos
images

We also have taxonomic weights:
title = 'Post 1'
tags = ['tag-a']
tags_weight = 30

I'm skipping the taxonomy "problems" for now, we're not breaking anything.
Re. related, I think that's a documentation "challenge" -- we're certainly not breaking anything.


maybe self.member instead of self->member in class?

Though class is based on the struct.

self->member is same as (*self).member, where *self takes the value of the self pointer. So using . instead of -> would mean that self is not a pointer. For example, consider this:
class Foo:
    x: int
    def increment(self) -> None:
        self->x++

def main() -> int:
    f = Foo{x=3}
    f.increment()
    printf("%d\n", f.x)  # Output: 4
    return 0

It is basically same as:
class Foo:
    x: int

def Foo_increment(f: Foo*) -> None:
    f->x++

def main() -> int:
    f = Foo{x=3}
    Foo_increment(&f)
    printf("%d\n", x)  # Ouptut: 4
    return 0

But if we did this instead, it would not work:
def Foo_increment(f: Foo) -> None:
    f.x++

Now Foo_increment() gets a copy of a Foo instance, and ++ would only affect the copy. Therefore the instance in main() wouldn't change at all. Basically, passing self as a pointer just works like you would expect things to work.
It would be possible to make self work as expected without making it a pointer, but it would mean doing more magic in the Jou compiler.


feat: remove azure account extension depends

Overall looks good. Just need to check if there are any more strings needed to put into uiStrings.ts

@formulahendry The ui string all updated, please review again


using class style of coding instead of "this" when using es6

is there a way to use the standard way of writing ES6 , so instead of this,
<example>
                <div>{ summary() }</div>

              <script type="es6">
              this.data = [{v: 1}, {v: 2}, {v: 3}, {v: 4}]
              this.summary = () => `there are ${this.data.length} elements,
            sum = ${this.data.map(d => d.v).reduce((a, b) => a + b)}`
              </script>
</example>

i would want to write it
public class Example{
 constructor(){
 this.data = [{v: 1}, {v: 2}, {v: 3}, {v: 4}];
}
summery (){
return  `there are ${this.data.length} elements,
            sum = ${this.data.map(d => d.v).reduce((a, b) => a + b)}`
}
}

Your code is not even valid es6. Please do not pollute our issues with invalid requests thanks

Hmm,
I was wondering the same thing, and even if that person's code may not be "valid" ES6, I'm sure you're getting the point he's trying to make. But if this is the level of 'support' and the attitude around riotjs, I'm gonna find myself another framework, because I'm far from javascript-guru and these things make people who want to learn afraid to ask questions..
So byebye


Update README.md

should be pip3 since its require python3

Thank you, merged. An oversight as on my system 'pip' and 'python' are py3 by default (on Ubuntu it's the opposite).


Using a single Connection for CloudBigtableConnectionPool.

Moving the BigtableBufferedMutator offer() method.  This should also fix some of the issues in #630.  Each Connection opens up multiple channgles

I removed PoolEntry.  I removed the key variable from createConnection.  I kept createConnection so that the test can override it.

LGTM


Incorrect nullability of MainDocumentPart.Document and corresponding root elements of other OpenXmlParts

Description
The Document property of the MainDocumentPart is defined as follows:
        /// <summary>
        /// Gets or sets the root element of this part.
        /// </summary>
        public DocumentFormat.OpenXml.Wordprocessing.Document Document
        {
            get
            {
                if (_rootElement is null)
                {
                    LoadDomTree<DocumentFormat.OpenXml.Wordprocessing.Document>();
                }

                return _rootElement!;
            }

            set
            {
                if (value is null)
                {
                    throw new ArgumentNullException(nameof(value));
                }

                SetDomTree(value);
            }
        }

Other subclasses of OpenXmlPart (e.g., WorkbookPart) define their respective root elements (e.g., Workbook) in the same way.
Firstly, this is inconsistent with the more generic RootElement property of OpenXmlPart, which correctly flags nullability:
        /// <summary>
        /// Gets the root element of the current part.
        /// Returns null when the current part is empty or is not an XML content type.
        /// </summary>
        public OpenXmlPartRootElement? RootElement
        {
            get
            {
                return PartRootElement;
            }
        }

Secondly, when nullability is enabled, the definition suggests that Document, for example, will not be null. However, the following unit test demonstrates that this is not the case:
    public class MainDocumentPartTests
    {
        [Fact]
        public void Document_NewMainDocumentPart_DocumentIsNull()
        {
            using var stream = new MemoryStream();
            using var wordDocument = WordprocessingDocument.Create(stream, WordprocessingDocumentType.Document);
            MainDocumentPart mainDocumentPart = wordDocument.AddMainDocumentPart();

            Assert.NotNull(mainDocumentPart);
            Assert.Null(mainDocumentPart.Document);

            // ReSharper disable HeuristicUnreachableCode
            Assert.Throws<NullReferenceException>(() => mainDocumentPart.Document.Body);
        }
    }

You will also see the comment telling ReSharper to disable the HeuristicUnreachableCode check after asserting that mainDocumentPart.Document is null. Owing to the incorrect nullability, ReSharper believes the assertion will throw and, thus, the next assertion will never be reached. This is not correct, of course.
Information

.NET Target: all
DocumentFormat.OpenXml Version: latest

Repro
See the unit test above.
Observed
The nullability of root elements is stated as non-nullable.
Expected
The nullability of root elements should be stated as nullable.

Good catch. Happy to accept a PR on this!

@twsouthwick, this is generated code. Not sure whether anybody outside of Microsoft can help in this case.

@twsouthwick, are you addressing this? As I said above, this is generated code, so the code generator will have to be fixed.

The change needed:

Annotate property with [DisallowNull]
Mark the property as nullable

We'll try to get that in for 2.14


fix(cypress): Cypress tests intermittently failing

This will hopefully make the Cypress tests less flaky when running
on the Build, Test, Deploy workflow.
closes #214

For clarity's sake, I am trying out things from https://spin.atomicobject.com/2021/07/20/reduce-flakiness-cypress-tests/.
The majority of the time, it seems the tests fail when in the navToEditorByDrawer function. I'm hoping fixing this function up makes the test fail less.


Added most popular item section at home page #7725

Coverage remained the same at 70.11% when pulling becbb0f473ef74e185438bd74c768d10986de513 on gautampanday:task-7725 into d9423c0ff49b92fe1e7acb7312f49ed84fd21212 on openlabs:develop.


Stablize CI build

To continue "issue844" branch, we need one stable CI build. Check this comment of #932 for detailed info.

I don't understand the problem with the organization name. What should we change?

I am not mean the organization name, but I find CI environment changed meanwhile.

This repo's CI migrated from travis-ci.org to travis-ci.com. I am not sure whether there exist some differences between them, or some issues got left during our migration, but I feel it is exactly this change that affected CI build.

Agree, but I don't understand the root cause and I don't see what and where to change. Any idea?

I have no idea, either.
I am trying to make all test files run as separate jobs, as one temporary solution.

Hey @monperrus
Maybe the root cause is the inaccessibility of old builds. It blocks our testing job and let CI build fail for "The job exceeded the maximum time limit for jobs, and has been terminated".
For example, we are not able to visit build380717778 any more. Some test cases need to access old builds.
Based on documentation:
Previous build history - your builds from before the migration to travis-ci.com will remain on travis-ci.org until the complete build- history migration (sometime in early Q3 2019)
So it should not be one big deal if we just migrate from travis-ci.org to travis-ci.com. It is the change of owner that made our situation weird.

WDYT?

Very nice analysis, thank!
Yes, link https://travis-ci.org/Spirals-Team/repairnator/builds/380717778 is dead but
https://travis-ci.org/eclipse/repairnator/builds/380717778 now exists.
At the API level, it's still OK: https://api.travis-ci.org/v3/build/380717778
Since we query the Travis API with only the build id, I still don't completely understand.
Test PR: https://github.com/eclipse/repairnator/pull/945

It is found that CI env-variables are only set at travis-ci.org, ignoring travis-ci.com.

We're getting closer to a CI fix. It seems that the update of Astor causes the build to fail. I suspect that a dependency change in Astor causes AssertFixer to crash. I'm on it.

Fixed

For the record, here is the explanation
When we updated Astor (https://github.com/eclipse/repairnator/commit/a51387928a6789279a8e98c8aa2118856e846b0c), the new version of Astor came with newer version of the dependencies. Since Astor was before assert-fixer in the pom.xml, this changed the runtime dependencies of assert-fixer. One such change was not backward compatible for assert-fixer. The fix was to switch the two dependencies https://github.com/eclipse/repairnator/commit/3b30054f18f4de797e45145af879d9d00350ecc9#diff-9ab40a54cf9289815466c35ec158c2d9L86


Disable Mode650 on 32-bit platforms

Related: https://github.com/AdoptOpenJDK/openjdk-tests/issues/2137
Signed-off-by: lanxia<EMAIL_ADDRESS>

Should Mode150 be disabled as well? The Mode150 is skipped for now for hotspot with spec set as without suffix  _mixed. With the plan to enabled Mode150 for hotspot later the same issue will be hit https://github.com/AdoptOpenJDK/openjdk-tests/issues/2137#issuecomment-758167085?

Should Mode150 be disabled as well? The Mode150 is skipped for now for hotspot with spec set as without suffix  _mixed. With the plan to enabled Mode150 for hotspot later the same issue will be hit https://github.com/AdoptOpenJDK/openjdk-tests/issues/2137#issuecomment-758167085?

Mode150 is disabled on 32-bit platforms

Mode150 is disabled on 32-bit platforms

Target
Impl
Platform
Grinder

sanity.openjdk
openj9
x86-64_linux
https://ci.adoptopenjdk.net/job/Grinder_TKG/99

sanity.openjdk
hotspot
x86-64_linux
https://ci.adoptopenjdk.net/job/Grinder_TKG/100

sanity.openjdk
hotspot
x86-32_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/101

sanity.openjdk
openj9
x86-32_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/102

sanity.openjdk
hotspot
x86-64_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/103

sanity.openjdk
openj9
x86-64_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/104

sanity.openjdk
openj9
x86-64_windows_xl
https://ci.adoptopenjdk.net/job/Grinder_TKG/106

Target
Impl
Platform
Grinder

sanity.openjdk
openj9
x86-64_linux
https://ci.adoptopenjdk.net/job/Grinder_TKG/99

sanity.openjdk
hotspot
x86-64_linux
https://ci.adoptopenjdk.net/job/Grinder_TKG/100

sanity.openjdk
hotspot
x86-32_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/101

sanity.openjdk
openj9
x86-32_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/102

sanity.openjdk
hotspot
x86-64_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/103

sanity.openjdk
openj9
x86-64_windows
https://ci.adoptopenjdk.net/job/Grinder_TKG/104

sanity.openjdk
openj9
x86-64_windows_xl
https://ci.adoptopenjdk.net/job/Grinder_TKG/106

The plan to add new NoOptions to run on 32bit only (in another PR)

The plan to add new NoOptions to run on 32bit only (in another PR)


Minor color fix

fixes a couple things.

Looks good. But the travis check doesn't pass. Is it an issue?

not sure why its failing, when i run my test locally, it works... taking a closer look.

@ktp242 tests passing now. thanks for your help.

Is this still applicable? Can be merged.


Attach screenshot in readme :)

Will do once the re-write is finished (Sorry for this god-level delay!)

no worries at all


Fix flatcar vagrant for Kubernetes 1.26

Fix flatcar vagrant for Kubernetes 1.26

What type of PR is this?

/kind bug
What this PR does / why we need it:
Fixes the vagrant for Flatcar Linux to work with Kubernetes 1.26 which requires containerd 1.6.x which is only available in Flatcar sable stream.
Also we have to use a temporary vagrant box because there was still an issue with ssh which was fixed by Flatcar but not yet released.
See for details: https://github.com/flatcar/Flatcar/issues/916
Which issue(s) this PR fixes:

Fixes #1377
Does this PR have test?

Yes
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Fix vagrant for Flatcar Linux to work with Kubernetes 1.26.

/assign @saschagrunert @jhrozek

Codecov Report

Merging #1392 (b42224f) into main (9108c0a) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1392   +/-   ##
=======================================
  Coverage   44.21%   44.21%
=======================================
  Files          50       50
  Lines        5640     5640
=======================================
  Hits         2494     2494
  Misses       3026     3026
  Partials      120      120

/test e2e-flatcar

/test pull-security-profiles-operator-test-e2e

/test all

/lgtm
/approve


Intructions for Hyperpartisan preparation?

Great paper, and really clean and explainable repo, Thanks!
Any plans to release the Hyperpartisan dataset and benchmark utils?
It could really help future researchers go through your pipeline of cleaning and evaluating the data.
Thanks!

We can't upload the data ourselves, but you can get access to it here. For the code, we are busy right now with the EMNLP deadline but can upload it afterwards.

Definitely!
Good luck with EMNLP:)
I'll bump later:)

+1 on looking forward to Hyperpartisan code & hope EMNLP goes well!

In the paper 8 of this paper, it is said that " For Hyperpartisan we split the training data into
train/dev/test sets using standard 90/10/10 splits", I think there is a typo error about the split ratio.
I think the correct description should be the training data is splited into train/test sets using 90/10 splits, am I right?

Another question is it is said that 'For Hyperpartisan we, ..., performed each experiment five times with different seeds to control variability associated with the small dataset', so how the final f1-score calculated?
Is the final score calculated by mean of best score of each run, or mean of last score of each run?

@OleNet
Re splits: Yes, 90/10/10 was a typo. We meant 80/10/10 (10% for dev and 10% for test).
Re final F1: Final F1 score was calculated based on the mean of the test F1 scores from the each run. For each run we evaluated the checkpoint with the best dev performance.

Got it, Thanks for your replying！

Hi,
I tested RoBERTa on randomly split Hyperpartisan dataset (80/10/10). The F1 score is 0.734370 (0.047247) for 6 runs.
And I found the 1st team on leaderborad only got 0.809.
The above scores are much lower than the one reported in Longformer paper (0.874 for RoBERTa), and it puzzled me a lot. I guess the problem is due to the small size of Hyperpartisan dataset (only 645 samples).

Could you kindly provide the final train/dev/test data for this dataset? I think it's a key step to get consistent result and make fair comparison with your model.

As described in the paper we split the original "training" set of this dataset into 3 parts.
The dataset is small and using different splits could change the results considerably.
We also did some preprocessing/cleaning on this data that could affect the results.
We've added instructions, a preprocessing script and the exact splits we used.
Please check out this PR: https://github.com/allenai/longformer/pull/112


After restarting a docker container, CouchDB replication does not replicate between the databases

Created replication between Host A database DB1 and Host B database DB1
 curl -vX POST http://hostA:5588/_replicate -d '{"source":"http://hostA:5588/db1","target":"http://hostB:5599/db1", "create_target":true,"continuous":true}' -H "Content-Type: application/json"
Replication completed and  both database are consistent.
Any updates on Host A are pushed to Host B as expected.
If I stop and restart the docker container for Host A and then carry out updates on Host A database DB1. These updates are not replicated to Host B database DB1
Attaching the local.ini used to build the docker images for Host A and Host B
[couchdb]
;max_document_size =<PHONE_NUMBER> ; bytes
uuid = bde13c5e11ca49a9c6d1931738ac2f11
database_dir = /usr/local/var/lib/couchdb
; view_index_dir = /usr/local/var/lib/couchdb

[httpd]
port = 5588
bind_address = <IP_ADDRESS>
; Options for the MochiWeb HTTP server.
;server_options = [{backlog, 128}, {acceptor_pool_size, 16}]
; For more socket options, consult Erlang's module 'inet' man page.
;socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}]

; Uncomment next line to trigger basic-auth popup on unauthorized requests.
;WWW-Authenticate = Basic realm="administrator"

; Uncomment next line to set the configuration modification whitelist. Only
; whitelisted values may be changed via the /_config URLs. To allow the admin
; to change this value over HTTP, remember to include {httpd,config_whitelist}
; itself. Excluding it from the list would require editing this file to update
; the whitelist.
;config_whitelist = [{httpd,config_whitelist}, {log,level}, {etc,etc}]

[query_servers]
;nodejs = /usr/local/bin/couchjs-node /path/to/couchdb/share/server/main.js

[httpd_global_handlers]
;_google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>}

[couch_httpd_auth]
; If you set this to true, you should also uncomment the WWW-Authenticate line
; above. If you don't configure a WWW-Authenticate header, CouchDB will send
; Basic realm="server" in order to prevent you getting logged out.
; require_valid_user = false

[log]
level = debug
file = /usr/local/var/log/couchdb/couch.log
; file = /usr/local/var/lib/couchdb/log/couch.log

[log_level_by_module]
; In this section you can specify any of the four log levels 'none', 'info',
; 'error' or 'debug' on a per-module basis. See src/*/*.erl for various
; modules.
;couch_httpd = error

[replicator]
; Maximum replicaton retry count can be a non-negative integer or "infinity".
max_replication_retry_count = infinity
; More worker processes can give higher network throughput but can also
; imply more disk and network IO.
worker_processes = 4
; With lower batch sizes checkpoints are done more frequently. Lower batch sizes
; also reduce the total amount of used RAM memory.
worker_batch_size = 5000
; Maximum number of HTTP connections per replication.
http_connections = 20
use_checkpoints = true
socket_options = [{keepalive, true}, {nodelay, true}]

Use the replicator database instead of the _replicate endpoint to have persistent replication http://docs.couchdb.org/en/1.6.1/replication/replicator.html


Correct spelling for "Exposure"

Changes
This updates the spelling of the word "Exposure"
Type of change

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

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

Thanks @iancanderson


Better way for decoding image

I'm looking into pin_decodedImageWithData method and wandering can't we find better way for decoding ? With current implementation in order to decode an image we are creating additional bitmap with the same size and draw on it. We could draw into 1x1 context like done here , concrete implementations are here. If there may be issues with image orientation(in which I'm not sure) we can do this way only when image is in portrait mode. By doing this way we can save temporary memory of image size.

We can set CGContextSetInterpolationQuality to kCGInterpolationNone  it should be more performant than default one. Here is the documentation link.

There are cases where suggested solution(drawing on 1x1 canvas) will not work correctly. Specifically if we get HEIC encoded image which alpha is not premultiplied we will get wrong decoded image because when compositing layers iOS considers that alpha should be premultiplied. So I think current solution works right, we still can disable interpolation to have better drawing speed.


Implemented Fyne receive page.

@Sirmorrison please provide instructions on how to test the changes in this PR. I built the program and ran it, but I could not figure out how to get to the receive page. I got only the following screen.

This is because you don't have any wallet account. You will need to create a wallet before you will be able to test this PR.

This is because you don't have any wallet account. You will need to create a wallet before you will be able to test this PR.

No, I do. I had a wallet account before we changed direction on the fyne UI.
@Sirmorrison

@barisere yes, it seems dcrlibwallet-wip branch and dcrlibwallet master branch detect/creates wallet in different ways

About the bug notice from the generate new address feature, It is a bug from dcrlibwallet  at it returns the initial wallet address and when generated again, returns a new address.
/Users/macbookair/Desktop/Screenshot 2019-10-24 at 6.19.35 PM.png/Users/macbookair/Desktop/Screenshot 2019-10-24 at 6.20.38 PM.png

About the bug notice from the generate new address feature, It is a bug from dcrlibwallet at it returns the initial wallet address and when generated again, returns a new address.

https://user-images.githubusercontent.com/27733432/66244031-8ccf7a80-e6fe-11e9-9e8c-c21a77054790.png
we should instead increase the height of the popup instead of the width

Can we make popup width same as the account selector so as to allow uniformity?

https://user-images.githubusercontent.com/27733432/67986619-bb704080-fc2b-11e9-9461-61c5b2fef594.png
We should right align balance label and left align account name and spendable label.

We should right align balance label with the checkmark icon and left align account name and spendable label.

We should right align balance label with the checkmark icon and left align account name and spendable label.

icons cannot be aligned left or right.

Account dropdown content isn't correctly aligned, I think to do this we'll need to implement tables, this would be treated on a different PR.


Adding compute.VirtualMachine GetByComputerName

Wrapper function to make it easier to "Get" a virtual machine by it's computer name. More complex queries are already supported by Query().
GetByComputerName will be invoked by CSI and MOC Provider etc.
Example usage:
vms, err := vmclient.GetByComputerName(ctx, group, "nickcluster-md-0-nzdkw")

I was thinking we might support wildcards here, so there would be potential for multiple matching VMs to be returned.


[question] Question regarding RecurrentPPO and the magnitude of approx_kl / clip_fraction / entropy_loss

While using RecurrentPPO, I noticed rather high values for approx_kl and clip_fraction. On further investigation it also seems that the entropy_loss indicates that the policy does not start from a (mostly) random policy.
More concretely, I used RecurrentPPO and PPO (as a reference) to solve the LunarLander-v2 environment. Since this has an action space of four discrete actions we expect the starting (random) policy to have an entropy close to $-\log{1/4} \approx 1.39$. Which happens with PPO, but  the RecurrentPPO run it starts off lower, which seems odd to me.
But more apparent is the difference in magnitude of the approx_kl for the two runs.
Question
Is the magnitude difference of the approx_kl and starting point of the entropy_loss expected behaviour?
Code example
I used the following (pseudo) code to perform the test, while not one-to-one, I tried to get the model architectures to be roughly similar.
vec_env = DummyVecEnv([lambda: Monitor(gym.make("LunarLander-v2"), filename = None) for _ in range(32)])
vec_env = VecNormalize(vec_env, norm_reward = True, gamma = .999)

policy_kwargs = dict( net_arch = [64, 64])
lstm_policy_kwargs = dict( net_arch = [64],
    lstm_hidden_size = 64, n_lstm_layers = 1, shared_lstm = True, enable_critic_lstm = False)

model = (Recurrent)PPO('Mlp(Lstm)Policy', vec_env, policy_kwargs = (lstm_)policy_kwargs,
    n_steps = 512,  batch_size = 128, n_epochs = 4,
    ent_coef = 0.01, vf_coef = .5, gamma = 0.999, gae_lambda = .98,
    normalize_advantage = True,
    verbose = 1, tensorboard_log = PATH + '/tensorboard')

TensorBoard results
Here the orange run corresponds to PPO, while the blue run corresponds to RecurrentPPO

Interesting insights! Though, my immediate knee-jerk reaction is "did you run for multiple runs per setup"? This could very well be results from random initialization.
But yes, there are no guarantees that that the random initialization of the network will lead to totally random actions (or, maybe there are some studies into this, but as far as I am aware, it is nowhere guaranteed). Beyond that the blame is on the recurrent network architecture used in RecurrentPPO. I have not seen others doing similar studies as you did now (although it might be studied in some paper or be noted there). While it is not expected behaviour, I am not surprised the different architecture changes the behaviour so much :)
But please, try running both setups multiple times, and compare the average results of the two setups for a more solid insight.

I just came to the repo to ask the exact same question.
I can see the same behavior in my custom environment. Default PPO works great with the same hyperparameters where RecurrentPPO fails (just changed bs and steps due to RPPO consuming much more RAM). The actions chosen are much less variated in the later (multiDiscrete action scheme).
My last step to 'match' the previous set up is defining a custom LSTM policy architecture (custom feature extractor is the same for both). I will share it here in case it changes this strange behavior, which definitely is not working out on my env.

@Miffyli That's fair. I came across this issue while modifying RecurrentPPO to allow for PopArt normalisation and reward transformations in order to solve a custom environment. Coming from PPO2 from Stable Baselines, the magnitude difference of the approx_kl in RecurrentPPO struck me immediately when I first tried to solve the custom environment.
After that I did a couple of runs of the LunarLanderNoVel-v2 environment with the hyper parameters taken from the RL Zoo, seeing if my messing around in de code introduced bugs. But all runs were consistent with the results stated on https://wandb.ai/sb3/no-vel-envs/reports/PPO-vs-RecurrentPPO-aka-PPO-LSTM-on-environments-with-masked-velocity–VmlldzoxOTI4NjE4. And all had the apparent magnitude discrepancy of the approx_kl and entropy_loss (the examples provided are representable for these tests)
But to make a better apples to apples comparison I'll do multiple runs comparing PPO2 with RecurrentPPO, that should at least rule out the network architecture difference.
One thing that immediately pops out is that PPO2 asserts that "For recurrent policies the number of environments run in parallel should be a multiple of nminibatches." when trying to use n_env = 32, n_steps = 512, batch_size = 128 (where batch size is given as batch_size = n_env * n_steps / nminibatches) as given by RL Zoo.

I performed multiple runs trying (four) to compare PPO2 with RecurrentPPO. The results show that all three metrics, approx_kl, clip_fraction and entropy wildly differ in shape and magnitude.
And as I was taught to always show my work :)
class NoVel_v2(gym.ObservationWrapper):
    def __init__(self, env: gym.Env):
        gym.ObservationWrapper.__init__(self, env)
        self.env.observation_space = gym.spaces.Box(-np.inf, +np.inf, shape = (6, ), dtype = np.float32)
    def observation(self, obs: np.ndarray) -> np.ndarray:
        return obs[[True, True, False, False, True, True, True, True]]

*As I am looking through the documentation of LunarLander, I realise I did not mask the angular speed during these tests, i.e. obs[5] should also be masked in addition to obs[2] and obs[3].. But that shouldn't change these results.
PPO2 (SB)
from stable_baselines.common.tf_layers import ortho_init

vec_env = DummyVecEnv([lambda: Monitor(NoVel_v2(gym.make("LunarLander-v2")), filename = None) for _ in range(32)])
vec_env = VecNormalize(vec_env, norm_reward = True, gamma = .999)

policy_kwargs = dict(
    act_fun = tf.nn.relu,
    net_arch = ['lstm', dict(pi = [64], vf = [64])],
    n_lstm = 64)

model = PPO2('MlpLstmPolicy', vec_env, policy_kwargs = policy_kwargs,
    n_steps = 512,  nminibatches = 8, noptepochs = 4,
    ent_coef = 0.01, vf_coef = .5, gamma = 0.999, lam = .98,
    verbose = 1, tensorboard_log = PATH + '/tensorboard')

## Ortho init LSTM
params = model.get_parameters()

wx = params['model/lstm1/wx:0']
wh = params['model/lstm1/wh:0']
b  = params['model/lstm1/b:0']

h = wx.shape[1] // 4
for i in range(4):
    wx[:, i * h : (i + 1) * h] = ortho_init(1.0)(shape = (wx.shape[0], h))
    wh[:, i * h : (i + 1) * h] = ortho_init(1.0)(shape = (wh.shape[0], h))

b[h : 2 * h] = 1.

model.load_parameters(params)

Note that I opted to also orthogonally initialise the values of the LSTM module.
RecurrentPPO (SB3)
vec_env = DummyVecEnv([lambda: Monitor(NoVel_v2(gym.make("LunarLander-v2")), filename = None) for _ in range(32)])
vec_env = VecNormalize(vec_env, norm_reward = True, gamma = .999)

policy_kwargs = dict(
    net_arch = [dict(pi = [64], vf = [64])],
    activation_fn = th.nn.ReLU,
    lstm_hidden_size = 64,
    shared_lstm = True,
    enable_critic_lstm = False,
)

model = RecurrentPPO('MlpLstmPolicy', vec_env, policy_kwargs = policy_kwargs,
    n_steps = 512,  batch_size = 2048, n_epochs = 4,
    ent_coef = 0.01, vf_coef = .5, gamma = 0.999, gae_lambda = .98,
    verbose = 1, tensorboard_log = PATH + '/tensorboard')

## Ortho init LSTM
lstm = model.policy.lstm_actor

wx = lstm.weight_ih_l0
wh = lstm.weight_hh_l0
bx = lstm.bias_ih_l0
bh = lstm.bias_hh_l0

h = wx.shape[0] // 4
for i in range(4):
    nn.init.orthogonal_(wx[i * h : (i + 1) * h]);
    nn.init.orthogonal_(wh[i * h : (i + 1) * h]);

nn.init.zeros_(bx);
nn.init.constant_(bx[h : h * 2], .5);
nn.init.zeros_(bh);
nn.init.constant_(bh[h : h * 2], .5);

TensorBoard results
The top row corresponds to PPO2 while the bottom row corresponds to RecurrentPPO. It useful to mention that Stable Baselines reports the normalised reward values, so we should focus on the difference in magnitude there (only the sign). Looking at the crossover point this might indicate that PPO2 learns faster, but this should be taken with a grain of salt.

Hello,

I noticed rather high values for approx_kl and clip_fraction.

yes, I observed that too, but RecurrentPPO was able to solve the different envs.
(btw, the mask wrapper is defined here: https://github.com/DLR-RM/rl-baselines3-zoo/blob/master/utils/wrappers.py#L344

Which happens with PPO, but the RecurrentPPO run it starts off lower, which seems odd to me.

that's weird indeed, probably initialization is not right.

One thing that immediately pops out is that PPO2 asserts that "For recurrent policies the number of environments run in parallel should be a multiple of nminibatches."

yes, this was an annoying limitation that I removed by doing some masking magic. The code should be fine but if there is a bug that's probably there.

The top row corresponds to PPO2 while the bottom row corresponds to RecurrentPPO

Thanks for running that small study =)
To me, it looks like the two are similar (same magnitude and same dynamic for the different values), no?
and the entropy value is now around 1.4 for RecurrentPPO too?

I still find it highly suspicious that the entropy of RecurrentPPO seems to follow the same dynamics of approx_kl and clip_value, i.e. it bends back down (getting increasingly random) at 300k steps. While the entropy of PPO2 continues to decline after that point.
I observed this to a greater extend in a custom environment but, haven't been able to replicate it with standard environments..

yes, there seems to be an issue

I've been investigating that a bit, and at initialization, nothing is suspicious for RecurrentPPO, the sampled actions are uniformly distributed as long as you don't take sequences into account...
==== Uniform actions in randomly sample obs ====
-log(1/4)            = 1.3862943611198906
Entropy RecurrentPPO = 1.3862944841384888
Entropy PPO          = 1.3851330280303955
Log prob RecurrentPPO = -1.386294960975647
Log prob PPO         = -1.3884332180023193
==== Sample actions in randomly sample obs ====
Log prob RecurrentPPO = -1.3862946033477783
Log prob PPO         = -1.3862944841384888
==== Sampled actions stats ===
Should be close to 1/num_actions = 1/4 = 0.25
uniform
2    0.260667
1    0.249000
0    0.245667
3    0.244667
Name: uniform, dtype: float64
ppo
3    0.269667
1    0.250667
0    0.241000
2    0.238667
Name: ppo, dtype: float64
RecurrentPPO
1    0.258667
2    0.249333
0    0.248333
3    0.243667
Name: RecurrentPPO, dtype: float64

import numpy as np
import torch as th
from sb3_contrib import RecurrentPPO
from sb3_contrib.common.recurrent.type_aliases import RNNStates
from stable_baselines3 import PPO

n_random_actions = 3000

recurrent_model = RecurrentPPO(
    "MlpLstmPolicy",
    "LunarLander-v2",
    verbose=0,
    # to have a big enough rollout buffer
    # in order to create dummy lstm states
    n_steps=n_random_actions,
)

ppo_model = PPO(
    "MlpPolicy",
    "LunarLander-v2",
    verbose=0,
    policy_kwargs=dict(ortho_init=False),
)

env = recurrent_model.get_env()
num_actions = env.action_space.n

# Taking uniform actions in uniformly sampled observations

random_obs = np.array([env.observation_space.sample() for _ in range(n_random_actions)])
single_obs = np.array([random_obs[0] for _ in range(n_random_actions)])
random_actions = np.array([env.action_space.sample() for _ in range(n_random_actions)])

observations, _ = recurrent_model.policy.obs_to_tensor(random_obs)
actions = th.tensor(random_actions, device=observations.device).float()

# Recurrent PPO

# we assume a new episode for each observation
# therefore we don't use lstm states
episode_starts = th.ones_like(actions)
n_layers = 1
n_seq = len(observations)
lstm_states_pi = (
    # (n_steps, n_layers, n_envs, dim) -> (n_layers, n_seq, dim)
    recurrent_model.rollout_buffer.hidden_states_pi[:n_seq].reshape(
        n_layers, n_seq, -1
    ),
    recurrent_model.rollout_buffer.hidden_states_pi[:n_seq].reshape(
        n_layers, n_seq, -1
    ),
)

distribution, new_lstm_states = recurrent_model.policy.get_distribution(
    observations,
    lstm_states=lstm_states_pi,
    episode_starts=episode_starts,
)
log_prob_recurrent = distribution.log_prob(actions)
entropy_recurrent = distribution.entropy()

# PPO
distribution = ppo_model.policy.get_distribution(observations)
log_prob_ppo = distribution.log_prob(actions)
entropy_ppo = distribution.entropy()

print("==== Uniform actions in randomly sample obs ====")
print(f"{'-log(1/4) ':20} = {-np.log(1/4)}")
print(f"{'Entropy RecurrentPPO':20} = {entropy_recurrent.mean().item()}")
print(f"{'Entropy PPO':20} = {entropy_ppo.mean().item()}")
print(f"{'Log prob RecurrentPPO':20} = {log_prob_recurrent.mean().item()}")
print(f"{'Log prob PPO':20} = {log_prob_ppo.mean().item()}")

# Taking actions in uniformly sampled observations

# Recurrent PPO
# we assume a new episode for each observation
# therefore we don't use lstm states
random_actions_recurrent = recurrent_model.predict(observations, deterministic=False)[0]
actions_recurrent = th.tensor(
    random_actions_recurrent, device=observations.device
).float()

distribution, new_lstm_states = recurrent_model.policy.get_distribution(
    observations,
    lstm_states=lstm_states_pi,
    episode_starts=episode_starts,
)
log_prob_recurrent = distribution.log_prob(actions_recurrent)

# PPO
random_actions_ppo = ppo_model.predict(observations, deterministic=False)[0]
actions_ppo = th.tensor(random_actions_ppo, device=observations.device).float()

log_prob_ppo = distribution.log_prob(actions_ppo)

print("==== Sample actions in randomly sample obs ====")
print(f"{'Log prob RecurrentPPO':20} = {log_prob_recurrent.mean().item()}")
print(f"{'Log prob PPO':20} = {log_prob_ppo.mean().item()}")

# Stats about action sampling
import pandas as pd

df = pd.DataFrame(
    {
        "uniform": random_actions,
        "ppo": random_actions_ppo,
        "RecurrentPPO": random_actions_recurrent,
    }
)

print("==== Sampled actions stats ===")
print("Should be close to 1/num_actions = 1/4 = 0.25")

for name in df.keys():
    print(name)
    print(df[name].value_counts() / n_random_actions)

@rnederstigt I know what is going on for the entropy at least.
Because we allow any batch size, we do some masking (to not back-propagate through padded states) and therefore the entropy loss is biased towards zero:
entropy_loss = -th.mean(entropy * rollout_data.mask)

(I'm not 100% sure this is the way to compute it though :/)
if you remove the masking, you get the expected value of -1.4:
entropy_loss = -th.mean(entropy)

For the same reason (masking), the approx kl might be off, I would highly appreciate if someone could double check that ;)

Let me have it double checked on my custom env;)

For the same reason (masking), the approx kl might be off, I would highly appreciate if someone could double check that ;)

I meant double check the logic. The implementation actually works (cf. link to the benchmark in the doc).

@araffin That's great to hear!
On the top of my head a correct masked entropy loss could be of the form,
entropy_loss = -th.sum(entropy * rollout_data.mask) / th.sum(rollout_data.mask)

@araffin I have a bit of trouble following the padding logic, but I assume the sequences are just padded with zeros?

I have a bit of trouble following the padding logic, but I assume the sequences are just padded with zeros?

yes, that's the high level idea (and the result of the hacky code). The padding code is a bit tricky because we have environments in parallel and different reshape that must keep the sequence order (I tried to add as many comments to ease the understanding of that part).

Applying a correct masked mean and standard deviation on all relevant quantities resolves the issue.
In favour of readability, I used a masked mean of the form,
# Convert mask from float to boole
mask = rollout_data.mask > 1e-8
entropy_loss = - th.mean(entropy[mask])

rather than,
# Calculate the correct masked mean norm
mask_norm = 1 / th.sum(rollout_data.mask)
entropy_loss = -th.sum(entropy) * mask_norm

which might incur a performance hit.


Fixing bug in pyflakes output parsing. Pyflakes sometimes puts a colu…

…in Travis. This fixes #142.

Codecov Report

Merging #157 into master will decrease coverage by 0.06%.
The diff coverage is 94.11%.

@@            Coverage Diff            @@
##           master    #157      +/-   ##
=========================================
- Coverage   94.36%   94.3%   -0.07%
=========================================
  Files          44      44
  Lines        2149    2161      +12
=========================================
+ Hits         2028    2038      +10
- Misses        121     123       +2

Impacted Files
Coverage Δ

statick_tool/plugins/tool/pyflakes_tool_plugin.py
97.18% <94.11%> (-2.82%)
:arrow_down:

statick_tool/discovery_plugin.py
89.47% <0%> (-0.53%)
:arrow_down:

statick_tool/plugins/tool/make_tool_plugin.py
80.72% <0%> (-0.46%)
:arrow_down:

...k_tool/plugins/discovery/cmake_discovery_plugin.py
77.33% <0%> (-0.3%)
:arrow_down:

statick_tool/plugins/tool/cppcheck_tool_plugin.py
83.9% <0%> (-0.19%)
:arrow_down:

...tatick_tool/plugins/tool/clang_tidy_tool_plugin.py
95.31% <0%> (-0.08%)
:arrow_down:

statick_tool/exceptions.py
98.19% <0%> (-0.04%)
:arrow_down:

statick_tool/plugins/tool/cccc_tool_plugin.py
99.31% <0%> (-0.01%)
:arrow_down:

statick_tool/tool_plugin.py
100% <0%> (ø)
:arrow_up:

...atick_tool/plugins/tool/catkin_lint_tool_plugin.py
100% <0%> (ø)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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

An example of the type of file that would give multi-line output for pyflakes is:
$ echo "import filename" > pyflakes_test.py; echo "print 'Resizing %s' % input_filename" >> pyflakes_test.py

That script will give valid output:
$ python pyflakes_test.py
Resizing

The output from pyflakes is 3 lines:
$ pyflakes pyflakes_test.py
pyflakes_test.py:2:19: invalid syntax
print 'Resizing %s' % input_filename
                  ^


Right Click to Navigate History (Round 2)

PR Checklist

[x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[x] I have checked that this PR does not introduce a breaking change

PR Type

[x] Feature

Fixes
Issue Number: #3474
What is the current behavior?
In order to navigate history, the user must do so one step at a time.
What is the new behavior?
User is able to right click the navigation buttons to move forward or backward multiple steps.

Other information
Possible improvements

[x] Limit the size of the history. Showing only 12 historical entries on either side. This is consistent with chrome.
[x] Configure the list to dropdown the same height as the other header buttons.
[x] If there is no "forward" or "backward" action to be taken, disable the button.

Awesome. Sorry I've been a little slow getting to this. We will be able to give this a closer look. On the last PR I added a commit to clean up the styling. Could you add that back?

@seanyesmunt no worries. I added the changes you made back into this PR. I did one last check and I'm seeing the following (slightly differs from original images)

Do we want to keep this or trim the second half out?


AUTH-2: reenable PodSecurity on privileged level

This enables the PodSecurity admission with baseline level (for now). I suspect it might break tests, which is where @s-urbaniak's upstream involvement in the e2e framework might come handy.
/cc @s-urbaniak
/cc @openshift/openshift-team-auth-maintainers

yes i see the reason failures in the e2e logs, however audit doesn't contain them, i.e. from https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_cluster-kube-apiserver-operator/1308/pull-ci-openshift-cluster-kube-apiserver-operator-master-e2e-aws-serial/1491066281317634048:
% gzcat *-audit-*log.gz | jq '. | select(.annotations | has("pod-security.kubernetes.io/audit"))' | wc -l
       0

@stlaz can you check why we have no audit entries for pod-security?

xref'ing https://github.com/openshift/kubernetes/pull/1128
this is the backport PR which I am keeping up-to-date with upstream.

gzcat *-audit-*log.gz | jq '. | select(.annotations | has("pod-security.kubernetes.io/audit"))' | wc -l

@s-urbaniak  I see what's the issue - upstream changed the annotation to pod-security.kubernetes.io/audit-violations in the meantime.

changed the annotation to pod-security.kubernetes.io/audit-violations in the meantime.

doh, you're right. now we get nice result of e2e test offenders:
% gzcat *-audit-*log.gz | jq '. | select(.annotations | has("pod-security.kubernetes.io/audit-violations")) | {namespace: .objectRef.namespace, resource: .objectRef.resource, podSecurityReason: .annotations["pod-security.kubernetes.io/audit-violations"] }' | jq -C -s --sort-keys '. | unique' | head
[
  {
    "namespace": "e2e-disruption-131",
    "podSecurityReason": "would violate PodSecurity \"baseline:latest\": hostPort (container \"donothing\" uses hostPort 5555)",
    "resource": "pods"
  },
  {
    "namespace": "e2e-disruption-131",
    "podSecurityReason": "would violate PodSecurity \"baseline:latest\": hostPort (container \"donothing\" uses hostPort 5555)",
    "resource": "replicasets"
...

I am wrapping up the upstream e2e tests, once I have a :+1: from ligitt we can ping on merging the downstream backport and fix the downstream e2e tests.

/retest

/retest

retesting, as the first one most likely didn't have the necessary changes yet. I will:

Verify the most recent retest has https://github.com/openshift/kubernetes/pull/1128 included
Iterate over the failures and start fixing tests

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest
o/origin vendor bump with fixed tests merged, let's see what's gonna happen

/retest

Moving the enforce to privileged so that we can reiterate on tests easier. We'll move to restricted soon(-ish maybe).

/retest
weeee, infra quota issues again

/lgtm

/retest-required

/retest-required

/hold
this can't merge until the relevant Network test is fixed

/hold cancel
/test all
the related tests were hopefully all fixed with the privileged policies merging as default for tests in o/origin

/hold
Looks like there was a bug in the policies PR that made the PSa label values be empty strings

/hold cancel
/retest
:crossed_fingers:

/test e2e-aws-serial
looks like everything is fine with w/ PodSecurity, this run had events that seem to have been reported in a BZ previously

/hold
upstream tests have improper PSa levels set :|

/retest

/hold cancel
/retest-required

/test e2e-aws-serial
looks like an infra failure

/test e2e-aws
perhaps the fixed tests were not picked up yet?

perhaps the fixed tests were not picked up yet?

checking that concrete failing test

@stlaz I think we're at the point where we need to fix origin e2e tests. Submitting a PR 👍

/retest-required

/hold cancel
/retest-required
let's pick up the latest o/origin changes

/hold
@s-urbaniak discovered some discrepancies in the upgrade code

/hold cancel
/retest-required


Add quota form in README/FAQ

moving incoming changes to internal repo for testing first before mirroring here


*: return rpctypes.Err in clientv3

For https://github.com/coreos/etcd/issues/5211.

Still need to implement tests...

@xiang90 @heyitsanthony Please review.

lgtm -- should another PR return it as rpctypes.RpcError (or whatever) instead of grpc.rpcError so that type asserts can work?

Yeah right now just call convert function, doesn't do anything with type-assert. Will do it in a separate PR.
Thanks.

@xiang90 All addressed. PTAL. Thanks.

LGTM! Thanks!

Will merge in greens. Thanks all.


python3.pkgs.jupyter-packaging: fix tests with setuptools 67.5.0+

Description of changes
Extracted from https://github.com/NixOS/nixpkgs/pull/245509. When setuptools is updated to 67.5.0+, a new deprecation warning is emitted that fails the tests. We can pull in a patch that ignores this deprecation warning in tests.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1054

@ofborg build python310Packages.jupyter-packaging


chore: remove fonts hosted by google

Closes #532
Proposed Changes

Remove the fonts hosted by Google in the following packages:

landingpage
storybook

No replacement is needed because the fonts were not in use

Do we not need to replace the font source with static.inovex.de? Or is this already done?


AI: Train hyper parameters through Machine Learning against good AI's

One way to train the hyper parameters like, piece values, piece tables, possibly how much weight should a is in check have, etc., is to train these through Reinforcement Learning where they play against an AI that can think in much higher depths (i.e. one that is written in Rust or C). This way the AI could potentially learn tricks that could help when playing against AI's that should completely destroy it.
Though I don't think that this is work too well, I do think that it could at least help a bit. It also seems like a fun little experiment and it also gives me an excuse to write some more Rust (or potentially C).
One big issue here is the question of how to reward the AI. Obviously it will fail most of the time, if not all. So a reward purely on winning and loosing is pretty meaningless. Instead, I think it would be smart to reward the AI for "surviving" longer, i.e. playing more moves, and punish it when it loses very quickly. It should also be rewarded when it looses with a smaller difference in evaluation compared to a huge difference.
I don't think this will be too great of an improvement, but I think it could be very fun and teaching.

This would take too much time and it might not even yield results.


form.hidden_tag() generates unnecessary div

If the input types are already hidden, what is the purpose of the div?
<input id="csrf_token" name="csrf_token" type="hidden" value="1452782070##2b535ebc0d609f21b85bb776d59247560414b7ff">
<input id="next" name="next" type="hidden" value="">

is a cleaner output than

<input id="csrf_token" name="csrf_token" type="hidden" value="1452782070##2b535ebc0d609f21b85bb776d59247560414b7ff"><input id="next" name="next" type="hidden" value="">

and avoids inlined css.

Search for DIV tag on https://flask-wtf.readthedocs.org/en/latest/quickstart.html?highlight=div tag

@lepture Omitting the div appears to be valid HTML 5, but not 4.  No decent HTML parser would be confused by the briefer syntax.  Maybe it's time to re-evaluate removing this?

@davidism aye

Noticed that the docs contradicted themselves by rendering another field without a wrapping block right after the hidden block.  So we weren't even following our own rules. ;-)


fix: Test fixes

closes https://github.com/ansys/pyfluent-parametric/issues/308

@mkundu1 @seanpearsonuk
https://github.com/ansys/pyfluent-parametric/blob/main/src/ansys/fluent/parametric/local/__init__.py#L227 creates sessions parallelly and there is no way to call exit() explicitly in the tests therefore many sessions are keep running in the background.


Manga updates not showing up in latest updates

Steps to reproduce
Is there a reason Manga updates would not show on history or Kate's updates?
Manga example:
Kabushiki Gaisha Magi Lumiere
Enter latest updates or updates from history
No chapter found
Used search function to fun the Manga manually.
Shows the chapters was updated 11 hours ago
Checked updates Manga its not there.
Expected behavior
The updates would show in the latest updates list,
Actual behavior
Updates only show if I manually look for the Manga by name and look at the updates on it.
Crash logs
None
Neko version
App version: 2.12.7 (standard, 0558cf98f, 181, 2023-01-27T13:55:03.770967)
Android version
Android version: 11 (SDK 30) Android build ID: RPAS31.Q2-59-17-4-3-9
Device
Device brand: motorola Device manufacturer: motorola Device name: odessa Device model: moto g(9) plus Device product name: odessa_retail
Other details
If makes me feel like I've missed a lot of updates because they did not appear on my list.
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have tried the troubleshooting guide.
[X] I have updated the app to the newest version Latest.
[X] I have filled out all of the requested information in this form.

Can you attach a screenshot of your recents settings?

Sorry for the late reply, here, I kinda figure it out, it's the source that is the problem, all releases by Mangaplus do not show on played updates for donde reason but if I search by group then they do show, kinda odd, not sure of its a settings issue

Tried but unable to replicate this


ARROW-11222: [Rust] [Arrow] Catch up with flatbuffers 0.8.1 which had some UB problems fixed

The major change of flatbuffers 0.8.1 since 0.8.0 is https://github.com/google/flatbuffers/pull/6393, which fixed some possible memory alignment issues.
In this PR, the ipc/gen/*.rs files are generated by regen.sh as before, without any manual change.

The crate flatbuffers is not pinned to 0.8.1, so let's  run cargo update to pull it locally.

The crate flatbuffers is not pinned to 0.8.1, so let's  run cargo update to pull it locally.

I suggest we hold off merging this PR until the Arrow 3.0 release is completed (happening in the next day or two) to minimize the chance we break something right before the release

I suggest we hold off merging this PR until the Arrow 3.0 release is completed (happening in the next day or two) to minimize the chance we break something right before the release

I suggest we hold off merging this PR until the Arrow 3.0 release is completed (happening in the next day or two) to minimize the chance we break something right before the release

@alamb thanks for the review! Since there are no direct evidence that this PR can fix something in arrow, it's OK to me to hold off merging this PR.
BTW, I've exploring the cause of test_struct test failure for several days, filed several issues, but can't figure out the exact reason. The latest issue is filed and commented at https://issues.apache.org/jira/projects/ARROW/issues/ARROW-11239. It looks like ArrayRef::slice() is not bug-free. I suggest you evaluate this problem seriously before the 3.0 release.
CC @jorgecarleitao I'm glad if you can take time for this possible problem at this weekend, as you said :)

I suggest we hold off merging this PR until the Arrow 3.0 release is completed (happening in the next day or two) to minimize the chance we break something right before the release

@alamb thanks for the review! Since there are no direct evidence that this PR can fix something in arrow, it's OK to me to hold off merging this PR.
BTW, I've exploring the cause of test_struct test failure for several days, filed several issues, but can't figure out the exact reason. The latest issue is filed and commented at https://issues.apache.org/jira/projects/ARROW/issues/ARROW-11239. It looks like ArrayRef::slice() is not bug-free. I suggest you evaluate this problem seriously before the 3.0 release.
CC @jorgecarleitao I'm glad if you can take time for this possible problem at this weekend, as you said :)

I apologize for the delay in merging Rust PRs -- the 3.0 release is being finalized now and are planning to minimize entropy by postponing merging  changes not critical for the release until the process was complete. I hope the process is complete in the next few days. There is more discussion in the mailing list

I apologize for the delay in merging Rust PRs -- the 3.0 release is being finalized now and are planning to minimize entropy by postponing merging  changes not critical for the release until the process was complete. I hope the process is complete in the next few days. There is more discussion in the mailing list

I apologize for the delay in merging Rust PRs

@alamb I understand the common releasing process that freezes pushing/merging unless for those fully tested or fatal bug fix, this is really important. You are welcome, no need to apologize at all 👍

I apologize for the delay in merging Rust PRs

@alamb I understand the common releasing process that freezes pushing/merging unless for those fully tested or fatal bug fix, this is really important. You are welcome, no need to apologize at all 👍

I merged this branch (locally) to master and re-ran the tests to verify things still work. Everything still looks good, so merging it in.

I merged this branch (locally) to master and re-ran the tests to verify things still work. Everything still looks good, so merging it in.


Catch failing connection to directline WebSocket endpoint

I am trying to figure out a way to catch failing connections to the WebSocket stream endpoint of directline (for example wss://europe.directline.botframework.com/v3/directline/conversations/...) to be able to fall back to the polling mechanism.
Use case example: In some corporate networks WebSocket stream connections are blocked by a proxy etc or some plugins block WebSocket streams. If that is the case (resulting in a console error by direcline.js that the connection could not be established) I want to fall back to the polling so the affected users are still able to use the bot.
I already have the functioning fallback if the directline connectionStatus is 4 / FailedToConnect resulting in the DIRECT_LINE/CONNECT_REJECTED action in the store. But if the connection via wss fails, the directline connectionStatus is still 2 / Online resulting in the DIRECT_LINE/CONNECT_FULFILLED store action. Also the directline object including the connectionStatus object does not change when the error is thrown and connectionStatus.hasError stays false and the connectionStatus.thrownError stays null. Directline then tries again to establish a connection every few seconds.
This scenario can be reproduced in combination with the webchat by using for example the uBlock Origin browser plugin and setting a filter to block websockets (add *$websocket to My filters). To get the connections status one can use the following line directLine.connectionStatus$.subscribe(connectionStatus => {}) and listen to the actions in a store middleware of the webchat.
Is it expected behavior that the connectionStatus does not change on the failing wss connection?
I would be glad if you could help me figure out, how I am able to catch that the connection has failed.
Thank you very much.

@Jakob-vdH,
As you know, ConnectionStatus is a function of Direct Line and reports the status of the connection it and the Direct Line channel is maintaining. However, if that connection is broken, the Direct Line object used by Web Chat (or any client) won’t be able to report that status until the connection is re-established. Once re-established, the various store action types (for instance, DIRECT_LINE/DISCONNECT_PENDING) will then be able to respond, but only after the fact.
In simpler terms, imagine the power unexpectedly going out at your home. You may have an alert set up at your home to say, “Hey, the power is about to drop!”, but because of the unexpected nature, the power drops before the alert can fire and there is no way to delay it from happening. The alert can’t fire until the power (connection) is back up, after the fact.
I’ve been able to test the above in Web Chat, successfully. However, because 1) Direct Line’s default is to attempt to reconnect when the wss stream fails, 2) it does not fallback to polling, and 3) it doesn’t report the status until the connection has been restored, there is no Web Chat / Direct Line method for live capturing a failed connection.

@stevkan thank you for clarifying.
I am still wondering why the ConnectionStatus is 2 / Online, even though the wss connection has not been established yet, since in this use case it has been blocked from the beginning. Like in your example, why does it say we have power, even though we never had any.
I understand the case though when an existing connection is interrupted/broken.
Is there a way to "manually" test, if a wss connection to directline can be established, so we could tell the webchat if it is able to use wss? Otherwise, my first idea would be to host a simple echo server to run a wss connection test against, before establishing the directline connection.
Or do you know of best practices for such scenarios by any chance?
Thank you very much for your help and time.

@Jakob-vdH, thank you for your patience. The reason ConnectionStatus shows as 2 / Online is because that is the last known status when the web socket fails. And, because the connection is no longer functional, it is unable to update to a more proper status. In fact, the Direct Line client has no functionality what so ever, at this point.
Unfortunately, I do not know of a method to manually test the wss connection. Without further research, I don't have a better suggestion than your idea to host a server to test the connection beforehand.