Events aren't being cleared properly

Bevy version 0.12.1
Events are not silently dropped the turn after they're sent but instead accumulate in the EventReader's buffer.
What I did
Here's an example:
use std::cmp::Ordering;

use bevy::prelude::*;

#[derive(Event)]
struct Ev;

fn send(mut evw: EventWriter<Ev>) {
    evw.send(Ev);
}

fn read(mut evr: EventReader<Ev>) {
    println!("{}", evr.iter().count());
}

// Generates a condition returning true on the nth frame
fn nth_frame(n: u32) -> impl FnMut() -> bool + Clone {
    let mut run = 1;
    move || match run.cmp(&n) {
        Ordering::Greater => false,
        Ordering::Equal => {
            run += 1;
            true
        }
        Ordering::Less => {
            run += 1;
            false
        }
    }
}

fn main() {
    App::new()
        .add_event::<Ev>()
        .add_plugins(DefaultPlugins)
        .add_systems(Update, send)
        .add_systems(Update, read.after(send).run_if(nth_frame(10)))
        .run();
}

What went wrong
Under version 0.11.3, this prints 2 as expected but under 0.12.1 I'm getting 10.

https://github.com/bevyengine/bevy/issues/10860
Seems like a decent amount of people stumbled over it, maybe something needs to be done.

I agree something needs to be done, this is a tremendous footgun, and not just because the behavior changes. I know there was discussion about this being the "right" way to do this in the ecs dev channel somewhere, but at this point I think it's obvious that this isn't what users are expecting.

Agreed. Even experienced Bevy devs are struggling to use events correctly, so something must be done.
It is easier said than done however. EventReaders keep track of which events they've read with a cursor stored in the system. We'll somehow need to update these cursors when the systems aren't even running or change how events are tracked entirely.

The issue description is a little strange.

Under version 0.11.3, this prints 2 as expected

Wouldn't you expect it to be 1? That is what gets printed with nth_frame(1) i.e reading events every frame.
The example given reads old events in both 0.11.3 and 0.12.1
The difference is that 0.12.1 can buffer events for more than 2 frames but with 0.11.3 you're still getting an outdated event from the previous frame.

According to the doc, this is the expected behavior.
When an event is generated, some systems may already have run in the current frame. Thus, it's already too late for them to read that event this frame. That's why events persist until the end of the next frame. And this is why 2 is the expected behavior in the example.

I see, it was more clearly documented than I thought. fair enough.

This new behavior synergizes pretty poorly with .run_if :confused:
Would it be possible to have a method on EventReader to read events' emission timestamp or frame-count? That way we would be able to easily filter out the older ones.

Adding my 2 cents that a change like this should be documented, with suggested workarounds if it is intended to stay this way and not just a bug. I am surprised this isn't talked about more, since problems arise the moment any systems with run conditions read from the same events.

To add some context, the lifetime change was deliberate and was made in #10077. (In hindsight, it was a mistake to include it in the 0.12.1 release.) I just didn't see that the EventReader docs needed to be changed.

Would it be possible to have a method on EventReader to read events' emission timestamp or frame-count? That way we would be able to easily filter out the older ones.

This is pretty much the plan (see the part about timestamps in the future work section of #10077).
If y'all want a "quick and dirty" workaround, app.remove_resource::<EventUpdateSignal>() will recover the <=0.12.0 behavior.

To add some context, the lifetime change was deliberate and was made in #10077. (In hindsight, it was a mistake to include it in the 0.12.1 release.) I just didn't see that the EventReader docs needed to be changed.

Would it be possible to have a method on EventReader to read events' emission timestamp or frame-count? That way we would be able to easily filter out the older ones.

This is pretty much the plan (see the part about timestamps in the future work section of #10077).
If y'all want a "quick and dirty" workaround, app.remove_resource::<EventUpdateSignal>() will recover the <=0.12.0 behavior.

A small correction that the fix should be app.world.remove_resource::<EventUpdateSignal>();. Without this change I was experience a memory leak even after manually draining all the events I was using.

On a personal note it's a bit disappointing #10077  was merged when it was known it would cause infinite memory usage in some circumstances. The fact this change wasn't even in the patch notes or migration guide just hurt more.
Obviously bevy is still under heavy development so things are expected to break and it is only because it normally does such a good job at making updates feel safe that this issue stands out so much. In the future I hope we can be more careful with such big changes.

I think I've ran into this problem, I have a system that zooms the camera in and out, reading mousewheel events. And I turn it off using run_if when the egui context is active so I don't zoom my main camera if I'm just scrolling an egui scroll area. As soon as egui lets go of my mouse and the system runs again, all the mousewheel events are there and my zoom level snaps to wheverever it would've been if I didn't disable the system

Just confirming my understanding here, sorry for the noise. People in this thread are saying that the default behavior of the Events no longer plays nice with run_if after the referenced PR merged.
I want to confirm that, while true, the behavior of the Events is now aligned with the behavior of change detection, right? If one prevents a system from running via run_if, and that system relies on Added<_> or Changed<_>, then that change detection is not cleared until the system has a chance to run again in the future. Additionally, when considering that RemovedComponents<_> relies on Events, not change detection, the line between the two concepts for the lifecycle of a mutated Component was already quite blurry.
I'm not trying to be dismissive of the pain caused by this change. I agree things are in a tough spot. I just want to confirm that, from a different perspective, this change was good and brought aspects of Bevy more into alignment with itself. It would be unfortunate if we were to make adjustments to Events, without affecting change detection, that resulted in these behaviors diverging again in the future.

I believe you are almost correct. Consider this snippet:
fn pan_camera(
    mut ev_motion: EventReader<MouseMotion>,
    input_mouse: Res<Input<MouseButton>>,
    query: Query<Entity, Changed<Something>>,
) {
...
    if input_mouse.pressed(pan_button) {
        for ev in ev_motion.read() {
            pan += ev.delta;
        }

        for e in query.iter() {
            // do something
        }
    }

In the case where the mouse is pressed, the behaviour of the query and the event reader are now the same. All of the motion events since the last time the system ran are iterated through, just as all of the changed entities are.
However in the case where the mouse is not pressed, the behaviour differs. For the query, it will be emptied automatically but for the event reader it won't. This means that you need to manually empty the event reader in every system, if you don't care about the events that call (by e.g. adding else { ev_motion.clear();}). If any of these are missed, you can get funky behaviour such as the panning based on all motion since the last mouse click and worse you can have unbounded memory and hit OOM.
...at least, that is my understanding of the issue. I could be wrong w.r.t. the query as I don't used fixed updates but I believe that is how it works based on the docs and some testing.

I believe you are almost correct. Consider this snippet:
fn pan_camera(
    mut ev_motion: EventReader<MouseMotion>,
    input_mouse: Res<Input<MouseButton>>,
    query: Query<Entity, Changed<Something>>,
) {
...
    if input_mouse.pressed(pan_button) {
        for ev in ev_motion.read() {
            pan += ev.delta;
        }

        for e in query.iter() {
            // do something
        }
    }

In the case where the mouse is pressed, the behaviour of the query and the event reader are now the same. All of the motion events since the last time the system ran are iterated through, just as all of the changed entities are.
However in the case where the mouse is not pressed, the behaviour differs. For the query, it will be emptied automatically but for the event reader it won't. This means that you need to manually empty the event reader in every system, if you don't care about the events that call (by e.g. adding else { ev_motion.clear();}). If any of these are missed, you can get funky behaviour such as the panning based on all motion since the last mouse click and worse you can have unbounded memory and hit OOM.
...at least, that is my understanding of the issue. I could be wrong w.r.t. the query as I don't used fixed updates but I believe that is how it works based on the docs and some testing.

Got it. Thanks for the clarification. I agree that additional condition of needing to read events, not simply run the system that declares it is interested in the events, is especially difficult to manage.

@MJohnson459 The scenario from your code snippet is different from having a run_if condition on the system.
I've noticed that for queries with filter Changed, change detection happens whenever the system runs regardless of the query being iterated or not. However, change detection does not happen if the system does not run.
This means that if you replace the condition if input_mouse.pressed(pan_button) at the beginning of your code snippet by a run_if condition on the system, I believe you will observe the same behavior for both the query and the event reader. So I would say that @MeoMix is correct that the behaviours of events and change detection are now more aligned.
I don't know about RemovedComponents which I haven't used.

@gwafotapa Wait.. you're the Wafo Tapa, aren't you?! I didn't expect to run into an ex-pro MTG player in a Bevy development thread.  I've been playing for ~20 years, seen you around at a few GPs, and I was watching LSV cube on my lunch break when you chimed in here :)
Anyway. Sorry for the off-topic comment. Just a bit shocked!

@MeoMix The world is small after all :)

@gwafotapa right, they are definitely more aligned than previous. The example was just to show the remaining case where they aren't.
It seems if we clean the events at the end of a system call then they would be identical. And add a (configurable) max size to the event queue in case the system isn't called often to avoid unbounded memory.

@maniwani is this particular bug fixed now? I know we're not at "ideal final form" yet, but I seem to remember the cache-clearing bug getting fixed in 0.13.

Is this particular bug fixed now? I know we're not at "ideal final form" yet, but I seem to remember the cache-clearing bug getting fixed in 0.13.

I believe so. 0.12.1 had a bug where events weren't getting dropped at all, and that was fixed by #11528, which should be in 0.13. So events still live longer than they did in 0.12, but they shouldn't just accumulate forever.


Create modeler api tutorial

Drafting up Modeler API tutorial. Docs to follow once this is polished up, but a few questions.

@pepopowitz I think this is ready for a first glance, but I have a few loose ends I'm not sure about.
If you'd rather, feel free to pop a half hour on my calendar and we can discuss.

@christinaausley I'll give this demo a walkthrough locally today, to finalize a review!

Note that this tutorial will need to be updated based on https://github.com/camunda/camunda-api-tutorials/pull/7, as in https://github.com/camunda/camunda-docs/pull/3708/.

@pepopowitz I've cleaned this up to mirror the updated auth -- let me know if you want to review this async, or jump on a call 👍

@christinaausley I wasn't sure where to place this feedback relative to the changed code, so I'm making a general comment.
I propose that we implement at least one API call different than we currently are.
We're implementing two methods in this tutorial: one to retrieve details of a specific file, one to delete a specific file. The challenge for the user is that they'll need to go into the Modeler to find a file suitable for deletion, and capture only its ID from the URL. The URLs for files in Modeler don't make it easy to capture the ID -- for example, the ID for https://modeler.cloud.camunda.io/process-applications/8f413a9a-ba96-4908-8c03-7887ebf161f7--basic/ is 8f413a9a-ba96-4908-8c03-7887ebf161f7 (note that the app appends the name of the file to the ID). This then becomes our problem, of having to explain to them how to capture that ID from the URL. Opportunities for things to go wrong, things that aren't really the main focus of the tutorial.
I have two proposals -- one more involved than the other.

Instead of the "retrieve" method, we provide a "list" method, like we've done in the other API tutorials. This would allow them to list out all IDs from their new CLI, and to capture one there more easily than in the Modeler URL.
Instead of the "files" resource, we implement the "projects" resource. The "projects" resource enables us to create a test item more simply than the "files" resource. Check out the specs -- a new project requires only a name property, compared to a file which requires a valid projectId, folderId, and contents. That would allow us to implement all the methods we did in the Administration API tutorial (list, add, view, delete) -- which would allow for the user to follow the tutorial without affecting existing files, which they may or may not feel comfortable deleting.

What do you think? I'm open to other suggestions too, including iterative approaches like "let's do these methods and then come back and do one of the above suggestions." I'm also happy to contribute any changes or help if you are annoyed by me kicking this review a month down the road, and then suggesting such drastic changes.

Instead of the "retrieve" method, we provide a "list" method, like we've done in the other API tutorials. This would allow them to list out all IDs from their new CLI, and to capture one there more easily than in the Modeler URL.

@pepopowitz This is an easy fix! I can probably do this today. But, do you have a preference on how we handle this? Could always open a backlog issue for iterations on these tutorials.

@pepopowitz I ended up using POST for the first API call, so the user creates a semi-meaningless file, the output reveals the name and ID, and then the user deletes it with this ID. WDYT?

@pepopowitz I ended up using POST for the first API call, so the user creates a semi-meaningless file, the output reveals the name and ID, and then the user deletes it with this ID. WDYT?

Did that work for you against the actual API? When I was playing with the API in Insomnia, I was unable to create a file that didn't have contents.

Instead of the "retrieve" method, we provide a "list" method, like we've done in the other API tutorials. This would allow them to list out all IDs from their new CLI, and to capture one there more easily than in the Modeler URL.

@pepopowitz This is an easy fix! I can probably do this today. But, do you have a preference on how we handle this? Could always open a backlog issue for iterations on these tutorials.

I don't have a preference. In case you'd like to handle it with a follow-up, I'll approve this one as-is, once I confirm that posting a file without contents functions against the real API.

@pepopowitz I ended up using POST for the first API call, so the user creates a semi-meaningless file, the output reveals the name and ID, and then the user deletes it with this ID. WDYT?

Did that work for you against the actual API? When I was playing with the API in Insomnia, I was unable to create a file that didn't have contents.

No, this API call does not work.
See my previous comment about the File resource in the modeler API. Creating a file has several requirements, all of which will make it more work for us compared to a resource like Folder. Most of the requirements are captured in the swagger description, though not all of them (like there need to be valid file contents).
If you'd like to treat the swapping of resources from Files to Folders iteratively, then I recommend reverting the changes to create the file.

This is ready for review @pepopowitz, but if you don't get to it today, I can have @conceptualshark and/or @akeller have a look while you're away 😄
Upon approval, I'll update the documentation. Thanks for your help!

Oh man, I tried to make all my suggestions from within VS code, and it botched all the line numbers. I'm going to dismiss my previous review and re-submit through the UI so that it's not suggesting misaligned changes 😭

But I think this aligns with what a user of our APIs would likely do in this situation. It doesn't appear that there's any endpoint in the Modeler API that can be used without the pre-existence of some other entity. In this case, the pre-existence required is the own user's account, which I think we can assume.

@pepopowitz Thank you for this! I'll update the documentation once this PR is finalized, and Slack you if I have any questions about how you've set it up.


ARWo 2018

Add theming and easy switching between the projects.
Add compression using UglifyJS
plus some fixing

LGTM


Updated validations.py python script.

Updated validations.py python script.
Fixed the behavior of validate_uder function in validations.py.
Closes: #1
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

@googlebot I signed it!


[Bug]: COolify won't start or run after docker-ce-5:23.0.1-1~debian.11~bullseye update

Is there an existing issue for this?

[X] I have searched the existing issues

Example public repository
coolify
Description
Docker updates prevent coolify running
Steps To Reproduce
Update:
Package:                                    Old Version:                 New Version:                                       Size:
containerd.io                               1.6.16-1                     1.6.18-1                                         28.2 MB
docker-ce                                   5:20.10.23~3-0~debian-bulls  5:23.0.1-1~debian.11~bullse                      21.9 MB
eye                          ye
docker-ce-cli                               5:20.10.23~3-0~debian-bulls  5:23.0.1-1~debian.11~bullse                      13.2 MB
eye                          ye
docker-ce-rootless-extras                   5:20.10.23~3-0~debian-bulls  5:23.0.1-1~debian.11~bullse                       8.8 MB
eye                          ye
docker-compose-plugin                       2.15.1-1~debian.11~bullseye  2.16.0-1~debian.11~bullseye                      10.2 MB
and it all breaks.
Version
latest

I'm closing this issue, because tracking features will be moved to GitHub discussions. Github issues will be only for bugs.
Version 4 is in full focus. v3 related issues will be closed, if it is not a critical bug.
Thanks for your understanding.


Question: Should alt! include a single parser variant

Looking at the definition for alt!, it should be easy to add a macro variant for the special case
named!(test, alt!(tag!("abcd")))

which reduces to
named!(test, tag!("abcd"))

This would be useful during development when you start an alt chain, but only have the first parser written, and you want to test every time you add a new parser.
Do you think this would be a good addition to the library?

It is worth noting that this kind of reduction changes ErrorKind result of IResult::Error.
playground
IMO explicit notation is better than implicit not obvious behavior as you can always add/remove a wrapping macro.

as @kamarkiewicz  using alt with a single macro changes the error type. And that combinator is really meant to test multiple alternatives, so it's not a useful addition


WIP: Update GPU CI and docker images for PyTorch 2.1 [wip]

What does this PR do?
Upgrades our GPU CI to PyTorch 2.1

:books: Documentation preview :books:: https://pytorch-lightning--18719.org.readthedocs.build/en/18719/

cc @carmocca @borda

to build images it need to be full PR and when all pass, you can dispatch the branch to upload such images to dockerhub

seems that PT was built only for CUDA 12.1 but not 12.0 or 12.2
also, NCCL has a limited build fro 12.1, see: https://docs.nvidia.com/deeplearning/nccl/release-notes/index.html


mapReady and zoomLevel

Hi,
Trying to use setZoomLevel fails if I try to execute it directly after mapReady is called. No errors are thrown / caught. Putting a 500ms timeout fixes it.
Please advise

Can't you pass the zoomlevel when initially rendering the map?


[Security] Workflow verify.yml is using vulnerable action actions/checkout

The workflow verify.yml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

Thank you for informing me about this security fix @Freakston, I wasn't aware of it. However I'm not sure your report is entirely correct. Please let me know if my reasoning is incorrect :slightly_smiling_face:
First, from what I can tell, v1 of actions/checkout isn't affected as it doesn't try to persist the credentials. Unfortunately the source code for v1 doesn't seem to be publicly available[^1] so it's a bit hard to verify.
Second, the permissions for the token in question are limited to read-only so obtaining a token doesn't gain you anything - everyone has read-only access to this project. (this was changed approximately three months ago, but logs for GitHub Actions on this repo are retained for less than that anyway).
As an aside, a more pressing issue would be that the documentation for this action currently recommends using actions/checkout@v1 (see the "Known Issues" for an explanation as to why this is the case). So if actions/checkout@v1 is actually vulnerable, updating that should probably have priority (especially given the limited permissions of the token in the "vulnerable" workflow of this repository).
[^1]: which might be reason enough to switch to v2 by itself but that's besides the point.


External Load Balancer e2e tests completely broke on Sunday night (5/3 @10pm)

The following e2e tests are failing 100% of the time on our CI systems since 5/3/2015 22:00 PST.
There are no PR's in that vicinity that seem to be causing it.  Underlying GCE problems?
Identified problems
Services should correctly serve identically named services in different namespaces on different external IP addresses
/go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/test/e2e/service.go:401
Expected error:
<*errors.errorString | 0xc208952040>: {
s: "service s0 in namespace e2e-ns-2015-05-04t115826-0 doesn't have a public IP after 240.00 seconds",
}
service s0 in namespace e2e-ns-2015-05-04t115826-0 doesn't have a public IP after 240.00 seconds
not to have occurred
Services should be able to create a functioning external load balancer
/go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/test/e2e/service.go:352
Expected error:
<*errors.errorString | 0xc208630030>: {
s: "service external-lb-test in namespace e2e-ns-2015-05-04t114906-0 doesn't have a public IP after 240.00 seconds",
}
service external-lb-test in namespace e2e-ns-2015-05-04t114906-0 doesn't have a public IP after 240.00 seconds
not to have occurred

I have thus far utterly failed to reproduce this on a GCE test cluster.

PS: We saw this problem intermittently in #7306 , but now it's occurring 100% of the time in our CI environment.

The GCE project jenkins is running in has hit its quota for target pools, so all external load balancer related tests have been failing in all our e2e varieties.
I've deleted the old target pools (except for a half dozen I'm keeping around in case they may be useful for debugging), so the tests should go back to normal soon. The question we have to answer now is what caused all the old target pools to leak...

Closing this in favor of a bug explicitly about the target pool leak, now that the bleeding should be stopping.

Thanks Alex!

Still failing with the same errors:
May 4, 2015 8:10 PM:
Identified problems
Services should correctly serve identically named services in different namespaces on different external IP addresses
/go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/test/e2e/service.go:401
Expected error:
<*errors.errorString | 0xc2089f4080>: {
s: "service s0 in namespace e2e-ns-2015-05-04t202630-0 doesn't have a public IP after 240.00 seconds",
}
service s0 in namespace e2e-ns-2015-05-04t202630-0 doesn't have a public IP after 240.00 seconds
not to have occurred
Services should be able to create a functioning external load balancer
/go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/test/e2e/service.go:352
Expected error:
<*errors.errorString | 0xc2089f4070>: {
s: "service external-lb-test in namespace e2e-ns-2015-05-04t202230-0 doesn't have a public IP after 240.00 seconds",
}
service external-lb-test in namespace e2e-ns-2015-05-04t202230-0 doesn't have a public IP after 240.00 seconds
not to have occurred

We'll have to continue debugging in the morning.  Provisionally assigning to @a-robinson

cc @wojtek-t in case you or one of the Polish crew can take a look at this before we wake up.

Interestingly the test started to pass again consistently on both of our CI jobs tonight (5/4) at around 20:00.  No PR's were merged around that time. Need to dig through logs for the root cause, but for now at least the problem appears to be resolved.

I assume that it took a few hours for the quota to be replenished in GCE, but I don't have logs to confirm this.  Closing this bug as the tests continue to pass in our CI again.  We can re-open if we run into it again.

I'd believe that - I noticed yesterday evening that we hadn't leaked any more target pools yet ~1 hour after I deleted the old ones. I don't know whether we can see logs of target pool creation attempts though, since they unfortunately don't show up in the list of Operations.


Update wasm tools to 1.0.20

On the latest versions of wit-bindgen, wasm-tools  version of 1.0.20 is used.
Can wasmtime-py be updated to that version as well?
This mis-versions breaks our setup, where we use wasm components for our js and python part of stack.

https://github.com/bytecodealliance/wasm-tools/releases v1.0.27?

Sorry for late reply, it all works great now.


Chore/refactor away unstated to fix SSR

First of all, apologies for the monstrous PR and thanks in advance for your review(s)!
This PR refactors away any third-party state management and context management (the incumbent was unstated). The fundamental reasoning behind the the change was that unstated changed to an asynchronous model during one of their releases which broke server-side rendering (see https://github.com/springload/react-accessible-accordion/issues/123 for example) and also forced us to do some pretty hacky stuff in our testing suite to make time-based assertions. In earlier releases unstated showed real promise, but (on top of the async issues) the maintainer refuses to enable issues or document releases/changes anywhere so it was a risky dependency to continue to maintain, long term.
The following were givens:

We still need 'context' because an AccordionItem needs to know which Accordion it belongs to, and in order for 'true' accordions to work (only one item may be open at one time).
We want to continue to support React 15 for a little longer, so we can't use the new shiny React 16.3+Context API. I plan to deprecate support for R15, but I would still like to maintain 16.0-16.2 support for a little while longer anyway.

So, I went with the legacy context API, which according to documentation will be supported for the remainder of React 16 releases. I used a little workaround to bypass prop-types support, because we use Flow in the internals anyway, and because I wanted to keep the library's dependency footprint small.
I imagine that it will be very difficult to review the unit tests by viewing the diffs, as the changes are so significant that the negative diffs are unlikely to give any helpful context (mostly because they're so unstated-specific).
Don't hesitate to get in touch if you have any more questions about this PR :)

Gidday @madarauchicha, basically it's just awaiting review from one of my colleagues, who has indicated that they will check it out sometime this week. I would welcome more reviews from anyone though, so if you've got a bit of time then any feedback would be appreciated 🙂


SharePoint Online

When using the command Get-PnPRecycleBinItem the property FileLeafName don't exist. It works if you use LeafName instead.
Get-PnPRecycleBinItem | ? LeafName -like "*.docx" | Clear-PnpRecycleBinItem

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

ID: 2d8ffc74-6836-0a88-f1e2-2962b487ca4e
Version Independent ID: 89967280-3b45-01d3-99c5-e9854da371fa
Content: Clear-PnPRecycleBinItem (sharepoint-pnp)
Content Source: sharepoint/sharepoint-ps/sharepoint-pnp/Clear-PnpRecycleBinItem.md
GitHub Login: @techwriter40
Microsoft Alias: kirks

@officedocsbot assign @yogkumgit

Hello @DRamalho92 Thanks for your feedback.
As the article indicates in Outputs section, this cmdlet returns a Microsoft.SharePoint.Client.RecycleBinItem object. Please see here the properties that it exposes https://docs.microsoft.com/en-us/previous-versions/office/sharepoint-server/ee536442(v%3Doffice.15)

@get-itips  Thank you very much for the contribution and sharing this explanation. @DRamalho92
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

@officedocsbot close


Consider poetry for dependency and package management

See if we want to use poetry for dependency management, package deployment to package repositories and project scaffolding.
Detailed Description
"Poetry is a tool for dependency management and packaging in Python. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you." (https://python-poetry.org/docs/)
We could use poetry to recreate the atlite project scaffolding and/or manage the dependencies for the different package repositories like pypi  and conda-forge and use poetry for deploying new atlite versions to these repositories.
Poetry consolidates most information which is currently redundantly specified and spread across files into a pyproject.toml  file.
Context
Issues as in #143 caused by inconsistencies in maintaining the dependency files for different package repositories will arguably continue to arise as long as we have dependencies manually duplicated for different installation methods.
Possible Implementation
/

definitively agree!

Poetry does not support combining multiple projects in a manner similar to pip install -e .. at the same time as far as i am aware (ie. https://github.com/python-poetry/poetry/issues/34). Ie. you could not use a development version of atlite with a development version of pypsa-eur easily (or at least i don't know how to). Maybe the PR https://github.com/python-poetry/poetry-core/pull/182 solves that, but i have not investigated that.


Tooltip shifts 1px

Hello,
I'm seeing an issue where tooltips shift 1px horizontally at the end of their fade in animation.
Here's a plunkr: http://plnkr.co/edit/nv8iDI6dyGxvByomZaNj?p=preview
Using Chrome or Safari, hover over each of the buttons a few times. As you move between them, you'll see the problem on the left and rightmost buttons.
Here's a gif showing it. In this gif, I log the offsetWidth of the button in the positionElements function, because I think it's related. It returns different values for the same button.
Here's another example, where the tooltip never stopped moving.
I think there's some kind of Webkit/Blink bug happening. The problem doesn't affect Firefox. I searched a little, but didn't find much about it. The closest thing was this Stack Overflow post about a similar offsetWidth problem.
This problem is only in ui.bootstrap 0.13.0. It is a regression from 0.12.1.
I'm using Angular 1.4.2 and Bootstrap 3.3.5 CSS. Testing with Chrome 43 and Safari 8 on a retina screen.

I can prevent the shift from happening by removing this $watch on line 249:
tooltipLinkedScope.$watch(function () {
  $timeout(positionTooltip, 0, false);
});

but I'm sure it's there for a good reason.

Thanks for this clear investigation - if I had to guess, this looks like a potential Webkit/Blink bug. I am not able to reproduce this on Firefox or on IE11.
The watch is there to reposition in the event something changed in the UI - a bit of a hack, but I'd be hesitant to touch it.

Thanks @wesleycho. I took a shot at fixing this in the above PR. It avoids the shift by being more deliberate about when to update the position.


Update docker.md

library/powershell does not exist
seems right command will be: docker run -it lalyos/powershell

Hi @stasburn, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

Worth noting that laylos/powershell is built from a fork, not this repo. It would be useful to setup an official build under the Microsoft namespace as a trusted build from this repository.

The instructions have been updated to explicitly call out the build step to create the Docker container. Thanks for the contribution!


Build on Windows should compile additional security flags

This is related to similar errors using trace_processor_shell.exe under constrained security environment #635
Similar compiler flags are recommended to be used.
So we were looking to use trace_processor_shell.exe at Microsoft but the binary failed a set of security checks from binskim. These compile flags would be needed to use the binary.

Optional to fix (warning)
##[warning]1. BinSkim Warning BA2024 - File: file:///D:/a/_work/_temp/Microsoft.Performance.Toolkit.Plugins.PerfettoPlugin-1.5.5.ptix/plugin/trace_processor_shell.exe.
Signature: bb153f488d6c6f10d936daa45314e203f796b8a444582e5b04226f08aec44667
Tool: BinSkim: Rule: BA2024 (EnableSpectreMitigations). https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations
'trace_processor_shell.exe' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.
The following modules were compiled with a toolset that supports /Qspectre but the switch was not enabled on the command-line:
libcmt.lib,cxx,19.36.32533.0 (argv_mode.obj,commit_mode.obj,default_local_stdio_options.obj,delete_array.obj,delete_scalar.obj,delete_scalar_size.obj,denormal_control.obj,env_mode.obj,exe_main.obj,file_mode.obj,fltused.obj,gshandler.obj,gshandlereh.obj,gshandlereh4.obj,gshandlerseh.obj,initializers.obj,initsect.obj,invalid_parameter_handler.obj,matherr.obj,new_array.obj,new_mode.obj,new_scalar.obj,new_scalar_nothrow.obj,std_nothrow.obj,std_type_info_static.obj,thread_locale.obj,thread_safe_statics.obj,throw_bad_alloc.obj,tlsdyn.obj,tlssup.obj,tncleanup.obj,utility.obj,utility_desktop.obj)
libcmt.lib,c,19.36.32533.0 (cpu_disp.obj,dyn_tls_dtor.obj,dyn_tls_init.obj,gs_cookie.obj,gs_report.obj,gs_support.obj,guard_support.obj,loadcfg.obj,matherr_detection.obj,pesect.obj,ucrt_detection.obj)
libcpmt.lib,cxx,19.36.32533.0 (_tolower.obj,_toupper.obj,asan_noop.obj,cerr.obj,cond.obj,cthread.obj,iomanip.obj,ios.obj,iosptrs.obj,locale.obj,locale0.obj,mutex.obj,raisehan.obj,StlCompareStringA.obj,StlCompareStringW.obj,StlLCMapStringA.obj,StlLCMapStringW.obj,syserror.obj,syserror_import_lib.obj,thread0.obj,vector_algorithms.obj,winapisupp.obj,wlocale.obj,xdateord.obj,xgetwctype.obj,xlocale.obj,xlock.obj,xmbtowc.obj,xmtx.obj,xnotify.obj,xonce2.obj,xstol.obj,xstoll.obj,xstoul.obj,xstoull.obj,xstrcoll.obj,xstrxfrm.obj,xthrow.obj,xtime.obj,xtowlower.obj,xtowupper.obj,xwcscoll.obj,xwcsxfrm.obj,xwctomb.obj)
libvcruntime.lib,cxx,19.36.32533.0 (chandler_noexcept.obj,ehhelpers.obj,ehstate.obj,frame.obj,initialization.obj,locks.obj,per_thread_data.obj,purevirt.obj,purevirt_data.obj,riscchandler.obj,risctrnsctrl.obj,softmemtag.obj,std_exception.obj,std_type_info.obj,throw.obj,undname.obj,winapi_downlevel.obj)
libvcruntime.lib,c,19.36.32533.0 (jbcxrval.obj,jmpuwind.obj,strchr.obj,strrchr.obj,strstr.obj,wcschr.obj,wcsrchr.obj)

Optional to fix (warning)
BinSkim Note BA2025 - File: file:///D:/a/_work/_temp/Microsoft.Performance.Toolkit.Plugins.PerfettoPlugin-1.5.5.ptix/plugin/trace_processor_shell.exe.
Signature: 8984a9935d3a4a9192e6f2ebeec7d34a11009823593c8341a1c53d20cc46eb9d
Tool: BinSkim: Rule: BA2025 (EnableShadowStack). https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack
'trace_processor_shell.exe' does not enable the Control-flow Enforcement Technology (CET) Shadow Stack mitigation. To resolve this issue, pass /CETCOMPAT on the linker command lines.

##[error]
3. Should fix
BinSkim Error BA2008 - File: file:///D:/a/_work/_temp/Microsoft.Performance.Toolkit.Plugins.PerfettoPlugin-1.5.6.ptix/plugin/trace_processor_shell.exe.
Signature: 1f235194c05841f2e4c479175283e6a8cfa2d94cda552a735cd9a19bf4cb9cd3
Tool: BinSkim: Rule: BA2008 (EnableControlFlowGuard). https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard
'trace_processor_shell.exe' does not enable the control flow guard (CFG) mitigation. To resolve this issue, pass /guard:cf on both the compiler and linker command lines. Binaries also require the /DYNAMICBASE linker option in order to enable CFG.

Please hold - this may be outdated. I forgot the full history here including some manual steps, and I think this is from the v38 version. #635 was fixed AFTER v38. Testing if v45 resolves the errors

Ok - indeed Perfetto v45 fixes the error. I am leaving the new scan howto and warnings here in case someone wants to fix (optional).
Using https://github.com/google/perfetto/releases/download/v45.0/windows-amd64.zip unzipped to say Downloads\windows-amd64\windows-amd64
cd microsoft.codeanalysis.binskim.1.9.5\tools\netcoreapp3.1\win-x64

BinSkim.exe analyze --config default --recurse --verbose --sarif-output-version OneZeroZero --sympath windows-amd64\windows-amd64 windows-amd64\windows-amd64\trace_processor_shell.exe

trace_processor_shell.exe: warning BA2004: 'trace_processor_shell.exe' is a native binary that links one or more static libraries that include object files which were hashed using an insecure checksum algorithm (MD5). MD5 is subject to collision attacks and its use can compromise supply chain integrity. Pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing. The following modules are out of policy:
Microsoft (R) Macro Assembler : masm : 14.15.26706.0 : libcmt.lib (amdsecgs.obj,chkstk.obj,guard_dispatch.obj)
Microsoft (R) Macro Assembler : masm : 14.15.26706.0 : libvcruntime.lib (handlers.obj,memchr.obj,memcmp.obj,memcpy.obj,memset.obj,notify.obj)
Microsoft (R) Optimizing Compiler : c : 19.15.26706.0 : libcmt.lib (cpu_disp.obj,dyn_tls_dtor.obj,dyn_tls_init.obj,gs_cookie.obj,gs_report.obj,gs_support.obj,guard_support.obj,loadcfg.obj,matherr_detection.obj,pesect.obj,ucrt_detection.obj)
Microsoft (R) Optimizing Compiler : c : 19.15.26706.0 : libcpmt.lib (_tolower.obj,_toupper.obj,cthread.obj,xgetwctype.obj,xmbtowc.obj,xmtx.obj,xnotify.obj,xstol.obj,xstoll.obj,xstoul.obj,xstoull.obj,xstrcoll.obj,xstrxfrm.obj,xtime.obj,xtowlower.obj,xtowupper.obj,xwcscoll.obj,xwcsxfrm.obj,xwctomb.obj)
Microsoft (R) Optimizing Compiler : c : 19.15.26706.0 : libvcruntime.lib (jbcxrval.obj,jmpuwind.obj,strchr.obj,strrchr.obj,strstr.obj,wcschr.obj,wcsrchr.obj)
Microsoft (R) Optimizing Compiler : cxx : 19.15.26706.0 : libcmt.lib (argv_mode.obj,commit_mode.obj,default_local_stdio_options.obj,delete_array.obj,delete_array_size.obj,delete_scalar.obj,delete_scalar_size.obj,denormal_control.obj,ehvecctr.obj,ehvecdtr.obj,env_mode.obj,exe_main.obj,file_mode.obj,gshandler.obj,gshandlereh.obj,gshandlerseh.obj,initializers.obj,initsect.obj,invalid_parameter_handler.obj,matherr.obj,new_array.obj,new_mode.obj,new_scalar.obj,new_scalar_nothrow.obj,std_nothrow.obj,std_type_info_static.obj,thread_locale.obj,thread_safe_statics.obj,throw_bad_alloc.obj,tlssup.obj,tncleanup.obj,utility.obj,utility_desktop.obj)
Microsoft (R) Optimizing Compiler : cxx : 19.15.26706.0 : libconcrt.lib (CacheLocalScheduleGroup.obj,Chores.obj,Context.obj,ContextBase.obj,event.obj,Exceptions.obj,ExecutionResource.obj,ExternalContextBase.obj,FairScheduleGroup.obj,FreeThreadProxy.obj,FreeVirtualProcessorRoot.obj,HillClimbing.obj,InternalContextBase.obj,location.obj,Platform.obj,RealizedChore.obj,ResourceManager.obj,rtlocks.obj,ScheduleGroupBase.obj,SchedulerBase.obj,SchedulerPolicyBase.obj,SchedulerProxy.obj,SchedulingNode.obj,SchedulingRing.obj,SearchAlgorithms.obj,staticinits.obj,SubAllocator.obj,TaskCollection.obj,TaskCollectionBase.obj,ThreadProxy.obj,ThreadProxyFactoryManager.obj,ThreadScheduler.obj,ThreadVirtualProcessor.obj,Trace.obj,Transmogrificator.obj,TransmogrifiedPrimary.obj,UMSBackgroundPoller.obj,UMSFreeThreadProxy.obj,UMSFreeVirtualProcessorRoot.obj,UMSSchedulerProxy.obj,UMSSchedulingContext.obj,UMSThreadInternalContext.obj,UMSThreadProxy.obj,UMSThreadScheduler.obj,UMSThreadVirtualProcessor.obj,UMSWrapper.obj,utils.obj,VirtualProcessor.obj,VirtualProcessorRoot.obj,WinRTWrapper.obj,WorkQueue.obj)
Microsoft (R) Optimizing Compiler : cxx : 19.15.26706.0 : libcpmt.lib (cerr.obj,cond.obj,excptptr.obj,iomanip.obj,ios.obj,iosptrs.obj,locale.obj,locale0.obj,mutex.obj,ppltasks.obj,raisehan.obj,StlCompareStringA.obj,StlCompareStringW.obj,StlLCMapStringA.obj,StlLCMapStringW.obj,syserror.obj,thread0.obj,vector_algorithms.obj,winapinls.obj,winapisupp.obj,wlocale.obj,xdateord.obj,xlocale.obj,xlock.obj,xonce.obj,xthrow.obj)
Microsoft (R) Optimizing Compiler : cxx : 19.15.26706.0 : libvcruntime.lib (ehhelpers.obj,ehstate.obj,frame.obj,initialization.obj,locks.obj,per_thread_data.obj,purevirt.obj,purevirt_data.obj,riscchandler.obj,risctrnsctrl.obj,rtti.obj,std_exception.obj,std_type_info.obj,throw.obj,uncaught_exception.obj,undname.obj,winapi_downlevel.obj)

trace_processor_shell.exe: warning BA2024: 'trace_processor_shell.exe' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.
The following modules were compiled with a toolset that supports /Qspectre but the switch was not enabled on the command-line:
libcmt.lib,cxx,19.15.26706.0 (argv_mode.obj,commit_mode.obj,default_local_stdio_options.obj,delete_array.obj,delete_array_size.obj,delete_scalar.obj,delete_scalar_size.obj,denormal_control.obj,ehvecctr.obj,ehvecdtr.obj,env_mode.obj,exe_main.obj,file_mode.obj,fltused.obj,gshandler.obj,gshandlereh.obj,gshandlerseh.obj,initializers.obj,initsect.obj,invalid_parameter_handler.obj,matherr.obj,new_array.obj,new_mode.obj,new_scalar.obj,new_scalar_nothrow.obj,std_nothrow.obj,std_type_info_static.obj,thread_locale.obj,thread_safe_statics.obj,throw_bad_alloc.obj,tlssup.obj,tncleanup.obj,utility.obj,utility_desktop.obj)
libcmt.lib,c,19.15.26706.0 (cpu_disp.obj,dyn_tls_dtor.obj,dyn_tls_init.obj,gs_cookie.obj,gs_report.obj,gs_support.obj,guard_support.obj,loadcfg.obj,matherr_detection.obj,pesect.obj,ucrt_detection.obj)
libcpmt.lib,cxx,19.15.26706.0 (cerr.obj,cond.obj,excptptr.obj,iomanip.obj,ios.obj,iosptrs.obj,locale.obj,locale0.obj,mutex.obj,ppltasks.obj,raisehan.obj,StlCompareStringA.obj,StlCompareStringW.obj,StlLCMapStringA.obj,StlLCMapStringW.obj,syserror.obj,thread0.obj,vector_algorithms.obj,winapinls.obj,winapisupp.obj,wlocale.obj,xdateord.obj,xlocale.obj,xlock.obj,xonce.obj,xthrow.obj)
libcpmt.lib,c,19.15.26706.0 (_tolower.obj,_toupper.obj,cthread.obj,xgetwctype.obj,xmbtowc.obj,xmtx.obj,xnotify.obj,xstol.obj,xstoll.obj,xstoul.obj,xstoull.obj,xstrcoll.obj,xstrxfrm.obj,xtime.obj,xtowlower.obj,xtowupper.obj,xwcscoll.obj,xwcsxfrm.obj,xwctomb.obj)
libconcrt.lib,cxx,19.15.26706.0 (CacheLocalScheduleGroup.obj,Chores.obj,Context.obj,ContextBase.obj,event.obj,Exceptions.obj,ExecutionResource.obj,ExternalContextBase.obj,FairScheduleGroup.obj,FreeThreadProxy.obj,FreeVirtualProcessorRoot.obj,HillClimbing.obj,InternalContextBase.obj,location.obj,Platform.obj,RealizedChore.obj,ResourceManager.obj,rtlocks.obj,ScheduleGroupBase.obj,SchedulerBase.obj,SchedulerPolicyBase.obj,SchedulerProxy.obj,SchedulingNode.obj,SchedulingRing.obj,SearchAlgorithms.obj,staticinits.obj,SubAllocator.obj,TaskCollection.obj,TaskCollectionBase.obj,ThreadProxy.obj,ThreadProxyFactoryManager.obj,ThreadScheduler.obj,ThreadVirtualProcessor.obj,Trace.obj,Transmogrificator.obj,TransmogrifiedPrimary.obj,UMSBackgroundPoller.obj,UMSFreeThreadProxy.obj,UMSFreeVirtualProcessorRoot.obj,UMSSchedulerProxy.obj,UMSSchedulingContext.obj,UMSThreadInternalContext.obj,UMSThreadProxy.obj,UMSThreadScheduler.obj,UMSThreadVirtualProcessor.obj,UMSWrapper.obj,utils.obj,VirtualProcessor.obj,VirtualProcessorRoot.obj,WinRTWrapper.obj,WorkQueue.obj)
libvcruntime.lib,cxx,19.15.26706.0 (ehhelpers.obj,ehstate.obj,frame.obj,initialization.obj,locks.obj,per_thread_data.obj,purevirt.obj,purevirt_data.obj,riscchandler.obj,risctrnsctrl.obj,rtti.obj,std_exception.obj,std_type_info.obj,throw.obj,uncaught_exception.obj,undname.obj,winapi_downlevel.obj)
libvcruntime.lib,c,19.15.26706.0 (jbcxrval.obj,jmpuwind.obj,strchr.obj,strrchr.obj,strstr.obj,wcschr.obj,wcsrchr.obj)

trace_processor_shell.exe: warning BA2025: 'trace_processor_shell.exe' does not enable the Control-flow Enforcement Technology (CET) Shadow Stack mitigation. To resolve this issue, pass /CETCOMPAT on the linker command lines.

Thanks for filing, 2 and 3 make sense but I'm a bit confused by 1: wasn't this implemented already in https://github.com/google/perfetto/commit/2a4f01d2fc828bfb7a80926586c22d8b004aa1e9?

I agree. I am confused by (1) as well since https://github.com/google/perfetto/commit/2a4f01d2fc828bfb7a80926586c22d8b004aa1e9 code looks like it does add "/ZH:SHA_256". My best guess is some sub-lib compiled into the .exe didn't have that on or something like that??

That would be very strange, we build all our deps from source and I'm pretty sure that the command lines you see there are used for all of our deps as well (unless there's some special dep I'm not thinking about).


Issue 8: Implement Post-event Attendee Feedback Sharing

I've added the Feedback button as per your instruction

there are some conflicts so pull the code and then resolve the part which is causing conflict and then commit the changes.

@abhideepkumar I've resolved the conflicts please check now


Memory leak in /usr/bin/envoy

Bug Description
We are using an istio-proxy side car with a second pod containing a golang mqtt client. When the mqtt client subscribes to the broker and receives messages the size of the istio-proxy pod grows at ~72 MB / hour until it reaches its 1GB limit and the pod restarts. The input data rate is 3 to 4 json messages / second totalling < 500 KB per hour. The behaviour is consistent across many runs.  We have other pods in the same cluster which all have istio sidecars, exchange messages at the same rate via gPRC but don't show memory growth.

Here is the script used to collect memory stats:
while true
do
	date
	kubectl -n adapdix top pod $POD --containers
	kubectl -n adapdix exec -it $POD -c istio-proxy -- ps aux
	kubectl -n adapdix exec $POD -n adapdix -c istio-proxy -- pilot-agent request GET stats | grep 'memory'
	echo ------------------------------------------------------------------
	sleep 10
done

The cleaned up output is here:
istio-proxy memory leak.ods
Debug Info
Followed this to generate heap profile:
To generate this:
heap.tar.gz
Used pprof to generate:
profile001.pdf
Version
$ ./istio/istio-1.16.1/bin/istioctl version
client version: 1.16.1
control plane version: 1.16.1
data plane version: 1.16.1 (37 proxies)
$ sudo kubectl version --short
Client Version: v1.25.4+k3s1
Kustomize Version: v4.5.7
Server Version: v1.25.4+k3s1
$ helm version --short
v3.8.2+g6e3701e

Additional Information
No response

More useful  output from pprof
$ PPROF_BINARY_PATH=./lib  ~/go/bin/pprof -text envoy.prof.0001.heap
Some binary filenames not available. Symbolization may be incomplete.
Try setting PPROF_BINARY_PATH to the search path for local binaries.

We have learned that the increase in memory is bounded. If the side car is given more memory then the memory eventually levels off.

Sure, I'll have a go. I also spoke too soon:

I collected these stats istio.stats.tar.gz  every minute for 24 hours using this:
while true
do
        date
        kubectl top pod $POD --containers
	kubectl  exec $POD  -c istio-proxy -- pilot-agent --log_as_json request GET stats | sed 's/;/\n/g' | grep -v '^\.'
        echo ------------------------------------------------------------------
        sleep 60
done

We are hitting similar issues, @chubbard-adapdix were you able to solve this issue on your side?

Sorry, this fell off my radar, let me take another look.

I looked at the stats, but didn't notice anything strange. Can you enable all Envoy stats for the workload temporarily via a pod annotation:
  metadata:
    annotations:
      proxy.istio.io/config: |-
        proxyStatsMatcher:
          inclusionRegexps:
          - ".*"

I'm a bit confused - why is MQTT showing up as HTTP2 buffers? Can you share more about the specific protocol use? I'd like to look deeper into the backend implementation.
It's very unlikely there's a leak across streams, so if the streams are interrupted more often by the client or the server, I suspect the leak would go away.


avoid needless call to memcpy with an empty entries_ array

Based on #300 , we should avoid calling memcpy() when entries_ is empty to keep -fsanitize=undefiend happy. The sanitizer (reasonably) detected a copy of 0 bytes from nullptr. And while that should be completely harmless in this case, it's cleaner to avoid entirely.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.347%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2196

Relevant Lines:
2378

💛  - Coveralls

fixes #300


Swift 4.1 Support

It seems TinyCrayon doesn't support swift 4.1. I got the following error:
Module compiled with Swift 4.0.3 cannot be imported in Swift 4.1: ../TinyCrayon/TCMask.framework/Modules/TCMask.swiftmodule/arm64.swiftmodule

Same issue that was reported 11 days ago; “Incompatible Library Version”.
Adding comment here Incase a reply is made here and not on the other thread.

Thanks for reminding, it's rebuilt with Swift 4.1 now

Thank you!
Any plans to update the UI so it resizes to device orientation changes?  If not, is this something I could help with?
Regards,
From: Xin Zeng<EMAIL_ADDRESS>Reply-To: TinyCrayon/TinyCrayon-iOS-SDK<EMAIL_ADDRESS>Date: Monday, April 23, 2018 at 11:24 PM
To: TinyCrayon/TinyCrayon-iOS-SDK<EMAIL_ADDRESS>Cc: RadionAtl<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [TinyCrayon/TinyCrayon-iOS-SDK] Swift 4.1 Support (#25)
Thanks for reminding, it's rebuilt with Swift 4.1 now
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FTinyCrayon%2FTinyCrayon-iOS-SDK%2Fissues%2F25%23issuecomment-383791469&data=02|01||e74d2a8c981847e27f6b08d5a992f240|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636601370944305952&sdata=g19qjFieFyjYWwcxSN5tEmJRgUsQkdOR%2FKigkS3DrDo%3D&reserved=0, or mute the threadhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANjOlruX5LblESCgSy87uIbgOIfdgrZFks5trpsEgaJpZM4Tgp6X&data=02|01||e74d2a8c981847e27f6b08d5a992f240|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636601370944305952&sdata=%2BnPzVZrrhYQjOs2WVN8jFmtQCHPt3NB2aM6UbGQcWi4%3D&reserved=0.


getSubject returns missing subject

Example Subject:
Fully Approved - Credit Limit Decision - Your reference: Credit Limit Buyer: 2222222 Buyer Name: XXXXXXX Policy Number: 111111
getSubject returns only "fully approved - credit limit decision - your reference: credit"
and sometimes "fully approved - credit limit decision - your reference: credit limit"
mail contains an attachment but getAttachments - hasAttachments returns null and 0
Expected behavior
return full subject
Desktop / Server (please complete the following information):

OS: macOS
PHP: 7.4.2
Version 2.0.2

Additional context
outlook.office365.com

Hi @aradhell ,
thanks for your report.
I cant replicate the behavior. Please dump the message header like this:
dd($message->getHeader());

and look for the attribute raw; please provide an anonymized copy of that. This will enable me to accurately reproduce the header and possibly  verify the bug.
Best regards,

hi @Webklex thanks! I sent it to<EMAIL_ADDRESS>I can also provide full mail by exporting it as .msg if it is needed.

It turned out that the subject was broken up into two lines. Each terminated with "\r\n". However the second line did not start as expected with a "\t" but with a " " and contained a ":" which lead to it being interpreted as a separat header entry.
Possible solution: support multiple "continuous indicators" such as " " and "\t".

Hi @aradhell ,
a patch has been released. Please update your webklex/php-imap dependency to at least v2.1.11.
Best regards,


LDAP for API Umbrella Users

Hi,
I have successfully configured admin log ins through various OmniAuth authentications such as Google and GitHub - https://github.com/NREL/api-umbrella/wiki/Authentication-Strategies
However, these are for admin accounts. My use case requires accounts for users (not the admins) through these other diverse means.

Can I get keys auto-generated from the LDAP integrated?
Is it possible to get the authentications for API users through the other options too, instead of just admin accounts?

I could not find documentation pointing to how these can be done. All I found was the manual sign up for API keys.

There's not a direct integration between LDAP and users/api keys. One potential idea would be to use the administrative API to programmatically create API keys for any LDAP users, though (see the section under "user" of the docs for how to create API keys). I'm not entirely sure if that approach would meet your needs, though.

The page you have pointed "administrative API" (https://api-umbrella.readthedocs.io/en/latest/admin/api.html) as well as "API users" https://api-umbrella.readthedocs.io/en/latest/admin/api-users/index.html are empty in the ReadTheDocs. Am I looking at a wrong place?


Fix ndarray index out of bound

Description
Fixes #12389
Add index out of bound check before make key tuple in _get_index_nd used by _get_nd_advanced_indexing
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes
Comments

@mxnet-label-bot add [NDArray, Python, pr-awaiting-review]


Routing to any astro component, not only those within "pages" directory.

Hi there, I'm testing Astro with HTMX, an unopinionated js library with gives you a easy ajax functionality.
A simple example, by doing
Click here
, I can make an ajax request to '/my-endpoint' in server and it returns you essentially a html response.
In Astro, any .astro files return html but for routing, it only works for astro component within "pages".
In order to get html, is there a way to make an ajax request to any astro component from any directory in src since each endpoint is related to a file inside pages directory ?
Something like this:
Fill contact form
 and '/contact-form' returns me html content from an astro component inside for instance src/components/ContactForm.astro !

Hi, thank you for your reply. I will check the discord. I will also check
the blog you mentioned.
Sincerely
Le jeu. 22 juin 2023 à 15:32, Sarah Rainsberger @.***>
a écrit :

Hi there @believelody https://github.com/believelody! Sorry that it's
taken me a while to catch up with Issue triage here! 😅
Just wanted to let you know that these issues are for issues specifically
with our documentation, not for issues you encounter when building with
Astro. We're also not in a position to provide support here, and we
recommend our Discord for that: https://astro.build/chat We'd be happy
for you to ask your questions about HTMX there, and I know some of our
community members are discusssing it.
I did a quick search, and someone has even posted an article they wrote
about HTMX and Astro, so maybe something in their blog post would help you?
https://bgolebiowski.com/blog/htmx-progressive-enhancement
If not, then please do come into Discord and make a post in our support
channel! That's where we have people who will be looking to answer your
questions! So I'll close this issue as it's not a documentation error or
problem, and hope to see you in Discord. 🚀
—
Reply to this email directly, view it on GitHub
https://github.com/withastro/docs/issues/3454#issuecomment-1602647672,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD6GCOAJ62CR4T6LDQNESCTXMRCQLANCNFSM6AAAAAAY7HJZBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


fix #48

Thanks to @jorisvandenbossche who brought the solution in geopandas/geopandas#1146.

@lamourj : Many Thanks for your contribution. As @jorisvandenbossche mentioned, please change the gdf_new = gpd.GeoDataFrame(gdf_new) to a pd.DataFrame and then I will merge the request directly ;).
Best,
Patrik

@lamourj : Many Thanks for your contribution. As @jorisvandenbossche mentioned, please change the gdf_new = gpd.GeoDataFrame(gdf_new) to a pd.DataFrame and then I will merge the request directly ;).
Best,
Patrik

Done :)

HI @lamourj ,
already merged your branch. Thanks for contributing ;).
Is there anything you are missing in Pandas-Bokeh or what you would improve?
Best, Patrik

Thanks!
I don't have enough experience with Pandas-Bokeh for now to give you innovative ideas, but I've been quite satisfied with it so far, thanks!


Add: a protocol page

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 96.19565% with 14 lines in your changes missing coverage. Please review.

Project coverage is 88.46%. Comparing base (907317a) to head (d987394).
Report is 8 commits behind head on main.

Files with missing lines
Patch %
Lines

project/docs/templatetags/image_element.py
60.00%
4 Missing :warning:

project/docs/templatetags/text_element.py
60.00%
4 Missing :warning:

project/docs/views.py
95.45%
3 Missing :warning:

project/tests/docs/test_template.py
92.30%
2 Missing :warning:

project/docs/models.py
97.56%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #95      +/-   ##
==========================================
+ Coverage   87.69%   88.46%   +0.76%
==========================================
  Files         107      115       +8
  Lines        3861     4221     +360
==========================================
+ Hits         3386     3734     +348
- Misses        475      487      +12

Flag
Coverage Δ

unittests
88.46% <96.19%> (+0.76%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Moved test/bootstrap.php —> test/loop-auto-start.php

Cleaned up some dev autoloading by moving things to composer.json

Coverage increased (+0.05%) to 100.0% when pulling 676f303fed8198e49af6dfdb234ebdbdfc9dbcb4 on davidwdan:bootstrap into 9756162d74086967385bd9e47f64fa7e1a7fa497 on ReactiveX:2.x.


feat: add skipEsbuild option on a per function level

Use case:
I've got multiple projects where I'm using serverless-esbuild and it's working great. But I'm building my own custom plugin for these projects where I'm adding a function and defining my own artifact zip file. Turns out though, serverless-esbuild will try to run esbuild even if an artifact is already defined. I'm sure this use case wasn't something that was thought of in the beginning, but I feel like it's something this should account for.
This has also been brought up in #376
Solution:
I tried going a variety of different routes, but the best solution I have so far is to make it so you can set a property when you define the function called skipEsbuild and if it's true, then it'll just skip over it. I'm leveraging the Serverless schema configuration helpers so that some default validation takes place.
I'm still pretty new to TypeScript and all, so if I did something incorrect here, let me know!

@all-contributors please add @koryhutchison for new code and idea


Sanitizer in Text Editor keeps converting nbsp back and forth

Description:
The sanitizing text / html editor module in the administration keeps "sanitizing" non-breaking spaces to UTF8 characters in the HTML mode, then back to entities when you switch editor mode, then back to UTF8 characters the next time the sanitizer runs on the content.
Steps to reproduce:

Create / open a text editor CMS module in the administration.
Switch to HTML editing mode
Insert a nbsp directly as an UTF8 character (e.g. via Option + Space on a Mac keyboard)
Click next to the editor to actually save the change (since the bug from NEXT-33239 is still not fixed)
switch to text editing mode (via Inspect Element, you can see a   entity where you inserted the nbsp character)
make a change in the editor, e.g. add a letter somewhere
switch back to HTML editing mode
make another change in the editor, e.g. adding a letter, and again click next to the editor to trigger the sanitizer
the sanitizer now converts the entity back to a UTF8 character

Expected result:
The nbsp should either remain a character or an entity, it shouldn't be visibly converted back and forth while editing. If it has to be converted, it shouldn't be this visible and distracting to the user, instead it should happen immediately when the editing mode is switched.
Actual result:
That's sadly not the case, the user sees the entities switching back and forth once other changes are made.

[public] Automated response: This issue is linked to the internal issue https://shopware.atlassian.net/browse/NEXT-34383.
[created from NEXT-34383, comment 485894]

[public] Hello,
Within our company roadmap and work capacity, we try to address each bug or improvement request but admit that not each one will be resolved. To continue our culture of honesty and openness, we are closing this issue to focus on our roadmap on behalf of all Shopware users.
If you feel like this issue is still impacting you, please create a new issue and let us know. Thank you again for your valuable feedback.
[created from NEXT-34383, comment 501218]

Appears to be fixed in SW<IP_ADDRESS>.


remove_repetition

When I run remove_repetition(4)
I sometimes get an error:
remove_repetition
self.remove_word(all_words[j], False, verbose=False)
line 1545, in remove_word
raise ValueError('word not in result')
ValueError: word not in result

What is remove_repetition? This does not look related to the wtpsplit code to me? Please reopen if I am missing something.

So sorry, I posted the issue to the wrong repo.


feat: vuln-fix of stdlib bump ubuntu to 23.10 [CR-22892]

Checklist:

[ ] Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
[ ] The title of the PR states what changed and the related issues number (used for the release note).
[ ] The title of the PR conforms to the Toolchain Guide
[ ] I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
[ ] I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
[ ] Does this PR require documentation updates?
[ ] I've updated documentation as required by this PR.
[ ] I have signed off all my commits as required by DCO
[ ] I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
[ ] My build is green (troubleshooting builds).
[ ] My new feature complies with the feature status guidelines.
[ ] I have added a brief description of why this PR is necessary and/or what this PR solves.
[ ] Optional. My organization is added to USERS.md.
[ ] Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

@oleksandr-codefresh should be it also delivered to OSS ?

@pasha-codefresh I guess yes


add Kconfig option to control logging

Summary
Logs have a great impact on image size, so whether to print logs is modified as a compilation option and controlled by Kconfig
Impact
Testing
sim:matter

[Experimental Bot, please feedback here]
This PR summary is missing crucial information. Here's a breakdown of what's lacking and how to improve it:
Summary - Missing Information

Why is this change necessary?

Is this a performance optimization?
Are there specific use cases where large log sizes are problematic?
Clearly state the problem this PR solves.

What functional part of the code is being changed?

Be specific! Which logging framework is being modified?
Are you changing the NuttX kernel, a specific driver, or a general logging utility?

How does the change work?

Explain the Kconfig option:

What is its name?
What are the possible values?
What is the default behavior?

How can developers enable/disable logging at compile time using this option?

Impact - Incomplete
You need to address all the points in the impact section. Even if the answer is "NO", state it explicitly. For example:

Is new feature added? YES (Kconfig option for logging control)
Impact on user: YES (Users can now control logging verbosity at compile time, potentially reducing image size).
Impact on build: YES (The build system now needs to respect the new Kconfig option).
Impact on hardware:  NO
Impact on documentation: YES (The documentation must be updated to explain the new Kconfig option and its usage).
Impact on security:  Potentially YES. Disabling logs can have security implications if debugging information is no longer available. You need to analyze and explain this.
Impact on compatibility:  Possibly, depending on how the logging changes are implemented. Analyze and explain.

Testing - Insufficient

Build Host(s):  Provide more details about your development environment. This helps reviewers reproduce your results.

OS:  (e.g., Linux Mint 21)
CPU: (e.g., Intel i7-12700K)
Compiler: (e.g., GCC 12.2.0)

Target(s):

"sim:matter" is not descriptive enough.
Which simulator are you using? (e.g., QEMU)
What is the "matter" configuration?

Testing Logs:

You must provide actual logs demonstrating:

The system's behavior with logging enabled.
The system's behavior with logging disabled.
Ideally, show the difference in image size between the two scenarios.

Revised Summary Example
## Summary

This PR addresses the issue of large log files impacting image size in NuttX. It introduces a new Kconfig option, `CONFIG_DEBUG_LOGGING`, which allows developers to enable or disable logging at compile time. This change modifies the core logging framework within the NuttX kernel ([mention specific files or modules]).

By default, `CONFIG_DEBUG_LOGGING` is set to `y` (enabled). Developers can disable logging by setting this option to `n` in their board or application configuration files.

This change provides a flexible mechanism to control logging verbosity, enabling optimization of image size for resource-constrained devices or deployments where extensive logging is not required.

## Impact

* **Is new feature added?** YES (Kconfig option for logging control - `CONFIG_DEBUG_LOGGING`)
* **Impact on user:** YES (Users can now control logging verbosity at compile time using the `CONFIG_DEBUG_LOGGING` option, potentially reducing image size).
* **Impact on build:** YES (The build system now respects the `CONFIG_DEBUG_LOGGING` option)
* **Impact on hardware:**  NO
* **Impact on documentation:** YES (The documentation must be updated to explain the new `CONFIG_DEBUG_LOGGING`  Kconfig option and its usage).
* **Impact on security:**  YES (Disabling logging could make it more difficult to debug security issues in the field. Developers should carefully consider the security implications of disabling logs).
* **Impact on compatibility:**  NO (This change does not introduce any known compatibility issues.)

## Testing

**Build Host:**
* OS: Linux Mint 21
* CPU: Intel i7-12700K
* Compiler: GCC 12.2.0

**Target:**
* QEMU simulator
* matter: [Provide a clear description of the "matter" configuration]

**Testing Logs (Before Change - Logging Enabled):**

[logs showing system behavior with logging enabled]

**Testing Logs (After Change - Logging Disabled):**

[logs showing system behavior with logging disabled - should be minimal or no output]

**Image Size Comparison:**

* Image size with logging enabled: [size]
* Image size with logging disabled: [size]


add unsupervised calculation on gains for root locus plot.

Add gains up to a tolerance is achived.
@slivingston I wait for reviews. I have a file with some examples that are an exersice taken from Franklyn book. Let me know if you need it to test the algorithm. Do I have to put in a particular place? Where? Thanks in advance.

Coverage increased (+0.4%) to 77.778% when pulling 8b829ccfcc051483c277c899af39e748a362a260 on gonmolina:unsup_rlocus_gain_selection into 6ada795f081e619b250077f848c588bcea7d34e2 on python-control:master.

Coverage increased (+0.4%) to 77.778% when pulling 6d55d573d3618ed3ba25030beaf042bb1bc41b68 on gonmolina:unsup_rlocus_gain_selection into 6ada795f081e619b250077f848c588bcea7d34e2 on python-control:master.

Coverage decreased (-0.4%) to 76.955% when pulling ebd39047108c35712cfc67fe819f3186e85c256c on gonmolina:unsup_rlocus_gain_selection into 6ada795f081e619b250077f848c588bcea7d34e2 on python-control:master.

Coverage decreased (-0.5%) to 76.822% when pulling 5438746ba1b7ce69bf9b9f26d727c5fe79c7b893 on gonmolina:unsup_rlocus_gain_selection into 6ada795f081e619b250077f848c588bcea7d34e2 on python-control:master.

@gonmolina can you add a citation in the docstring to the book that you used?

I am sorry for my delay; I lost track of my GitHub notifications feed. I anticipate finishing reviewing this within 2 days.

Coverage decreased (-0.6%) to 76.68% when pulling 6c813ce107cc121ee96e9cafa9c280c8e5b9cc38 on gonmolina:unsup_rlocus_gain_selection into 6ada795f081e619b250077f848c588bcea7d34e2 on python-control:master.

Coverage decreased (-0.9%) to 76.428% when pulling 6e4d14f105c75dbbb0a4c1d121c4f82bb5492d5e on gonmolina:unsup_rlocus_gain_selection into 6ada795f081e619b250077f848c588bcea7d34e2 on python-control:master.

I added a book as a reference.
I added possibility to draw a grid on s-plane similar to matlab (argument grid = True).
I have tested a lot this function and works fine.
I have wrote a script with several tests with a lot of cases and root locus figures seem to be fine. If you think this script can help you to test the algorithm I can add it to the repository (please tell me where is the right place to add it).
I have added support of 0 degrees root locus (positive feedback or  k<0) in the algorithm. This works fine in all cases that I have tested, but I couldn't solve when the num.order=den.order. To solve this problem a complete new solution have to be written, mainly when lines are plotted and when roots are sorted. I raise an error when a root locus of this kind is demanded.
@slivingston I wait for your review.
Thanks in advance.
Gonzalo

@gonmolina thanks working on it now.

@gonmolina thanks. The changes are good.

Actually considering the failures on CI testing, there may have been a regression. I am trying to reproduce locally.

Is there any way to do the test locally in my machine without doing a push?
I think I can fix it....

There are several new changes outside the scope of the previous review, so I will review these when you tell me that they are ready.
Several of the commit messages mention fixing of bugs. If these existed before this PR, can you add regression tests for them, i.e., tests that demonstrate the bugs?

I made 2 changes:

I added line 268 to ensure kmax> 0 when all the singular points are in 0. Problems getting kvect when deal with systems of the form 1/s^n. I do not think this is the problem while building.
I greatly increased the gain after the kmax in line 209 so that the lines of the  roots locus reach the zeros (in the figure) for all cases. I think this can be the problem since several groups of equal roots turn out to be about the same for too large gains. Solution: fewer points after kmax, smaller maximum gain, and separate them logarithmically. This problem was clear when I was trying to solve 0 degrees root locus with for systems with equal number of zeros and poles.

A regression test for the first problem is:
import control as ctrl
sys1=ctrl.tf([1],[1,0,0])
r,k = ctrl.rlocus(sys1, grid=True)

Coverage decreased (-0.6%) to 76.741% when pulling 4eedde4bf8844a28f9a583d83fee4b3a450d5f1c on gonmolina:unsup_rlocus_gain_selection into 6ada795f081e619b250077f848c588bcea7d34e2 on python-control:master.

@gonmolina it looks like you are permitting me to push changes to the branch associated with this pull request. Can I do so, to add the regression test that you suggest above?

yes, you can do it.

@slivingston I'm trying to clean up some of the PRs over the holiday break.  Let me know if you are still working on this one.


Quicklisp

Hello!
I wonder what is the status of Quicklisp on Corman Lisp? I've been trying to load an existing QL installation, but I'm getting this error:
?(load #P"C:\Users\user\quicklisp\setup.lisp")
;;; Warning: the following function(s) are called from forms
;;; in file "#P"C:\Users\user\quicklisp\asdf.lisp"" but were not defined:
;;;     TRANSLATE-PATHNAME
;;;     SOFTWARE-TYPE
; Loading system definition from
; #P"C:\Users\user\quicklisp\quicklisp\quicklisp.asd" into
; #<PACKAGE "ASDF0">
; Registering #<SYSTEM "quicklisp">
;;; Warning: the following function(s) are called from forms
;;; in file "#P"C:\Users\user\quicklisp\quicklisp\impl.lisp"" but were not defined:
;;;     METHOD-OPTION
;;; Warning: Invalid type specifier in HANDLER-BIND clause: COMPILER-NOTE
;;; Warning: Invalid type specifier in HANDLER-BIND clause: COMPILER-NOTE
;;; Warning: Unused variable G20678 in function SLOT-UNBOUND, File C:\Users\user\quicklisp\quicklisp\dist.lisp, line 482
;;; Warning: Unused variable G20677 in function SLOT-UNBOUND, File C:\Users\user\quicklisp\quicklisp\dist.lisp, line 482
;;; Warning: Unused variable G20703 in function SLOT-UNBOUND, File C:\Users\user\quicklisp\quicklisp\dist.lisp, line 489
;;; Warning: Unused variable G20702 in function SLOT-UNBOUND, File C:\Users\user\quicklisp\quicklisp\dist.lisp, line 489
;;; An error of type SIMPLE-ERROR was detected in function MACROEXPAND:
;;; Error: There is no SETF expansion method defined for (DIST RELEASE)
;;; Entering Corman Lisp debug loop.
;;; Use :C followed by an option to exit. Type :HELP for help.
;;; Restart options:
;;; 1   Retry compiling #<ASDF:CL-SOURCE-FILE "quicklisp" "dist">.
;;; 2   Continue, treating
        compiling #<ASDF:CL-SOURCE-FILE "quicklisp" "dist"> as having
        been successful.
;;; 3   Abort to top level.

https://www.quicklisp.org/beta/ does not list Coman as a supported implementation. I think the proper place to make this issue would be at https://github.com/quicklisp/quicklisp-client and to have someone implement CorCL support for it.

Oh, I see. Thanks for clarification!

If there's any concrete issue that prevents the Quicklisp client from supporting Corman, please feel free to open an issue with the concrete problem. I'll allow myself to close this ticket for now.

Well, I have not had much free time recently to work on Corman Lisp, unfortunately. I wish I could dedicate more time to the projects like this one.
There is a lot of work to do before Corman Lisp would be compatible with Quicklisp.
Most importantly, modern versions of ASDF do not support Corman Lisp. This problem has to be addressed first before working on supporting Corman Lisp in Quicklisp.
I hope this clarifies the things a bit.


ARROW-2300: [C++/Python] Integration test for HDFS

Don't merge yet, the tests are running, but test case fails with a segfault:
...
[       OK ] TestHadoopFileSystem/1.AppendToFile (102 ms)
[ RUN      ] TestHadoopFileSystem/1.ListDirectory
2018-04-13 10:42:07.815260, p4732, th139976980866944, WARNING the number of nodes in pipeline is 1 [6a75d180502e(<IP_ADDRESS>)], is less than the expected number of replica 3 for block [block pool ID: BP-565321869-<IP_ADDRESS>-1481502352273 b
lock ID<PHONE_NUMBER>_1099] file /tmp/arrow-hdfs/scratch-1325/test-file-1
2018-04-13 10:42:07.832038, p4732, th139976980866944, WARNING the number of nodes in pipeline is 1 [6a75d180502e(<IP_ADDRESS>)], is less than the expected number of replica 3 for block [block pool ID: BP-565321869-<IP_ADDRESS>-1481502352273 b
lock ID<PHONE_NUMBER>_1100] file /tmp/arrow-hdfs/scratch-1325/test-file-2
arrow/dev/hdfs_integration/hdfs_integration.sh: line 76:  4732 Segmentation fault      arrow/cpp/build/debug/io-hdfs-test

Core dump
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f6c79048cec in length (__s=<optimized out>)
    at /home/msarahan/miniconda2/conda-bld/compilers_linux-64_1507259624353/work/.build/x86_64-conda_cos6-linux-gnu/build/build-cc-gcc-final/x86_64-conda_cos6-linux-gnu/libstdc++-v3/include/bits/char_traits.h:269
269     /home/msarahan/miniconda2/conda-bld/compilers_linux-64_1507259624353/work/.build/x86_64-conda_cos6-linux-gnu/build/build-cc-gcc-final/x86_64-conda_cos6-linux-gnu/libstdc++-v3/include/bits/char_traits.h: No such file or directory.
(gdb) bt
#0  0x00007f6c79048cec in length (__s=<optimized out>)
    at /home/msarahan/miniconda2/conda-bld/compilers_linux-64_1507259624353/work/.build/x86_64-conda_cos6-linux-gnu/build/build-cc-gcc-final/x86_64-conda_cos6-linux-gnu/libstdc++-v3/include/bits/char_traits.h:269
#1  std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7ffc82ee5260, __s=0x46 <error: Cannot access memory at address 0x46>, __a=...)
    at /home/msarahan/miniconda2/conda-bld/compilers_linux-64_1507259624353/work/.build/x86_64-conda_cos6-linux-gnu/build/build-cc-gcc-final/x86_64-conda_cos6-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:664
#2  0x0000000000657b46 in arrow::io::SetPathInfo (input=0x18c7dd0, out=0x18c77c0) at /apache-arrow/arrow/cpp/src/arrow/io/hdfs.cc:300
#3  0x000000000065aa16 in arrow::io::HadoopFileSystem::HadoopFileSystemImpl::ListDirectory (this=0x18af890, path=..., listing=0x7ffc82ee5610) at /apache-arrow/arrow/cpp/src/arrow/io/hdfs.cc:444
#4  0x000000000065820b in arrow::io::HadoopFileSystem::ListDirectory (this=0x189ed80, path=..., listing=0x7ffc82ee5610) at /apache-arrow/arrow/cpp/src/arrow/io/hdfs.cc:582
#5  0x00000000005cc5cc in arrow::io::TestHadoopFileSystem_ListDirectory_Test<arrow::io::PivotalDriver>::TestBody (this=0x18a2990) at /apache-arrow/arrow/cpp/src/arrow/io/io-hdfs-test.cc:295
#6  0x000000000068ab70 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (object=0x18a2990, method=&virtual testing::Test::TestBody(), location=0x6a1833 "the test body")
    at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:2402
#7  0x0000000000684c2e in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x18a2990, method=&virtual testing::Test::TestBody(), location=0x6a1833 "the test body")
    at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:2438
#8  0x000000000066b0a5 in testing::Test::Run (this=0x18a2990) at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:2475
#9  0x000000000066b94c in testing::TestInfo::Run (this=0x18a0ee0) at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:2656
#10 0x000000000066c010 in testing::TestCase::Run (this=0x189f6f0) at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:2774
#11 0x00000000006729e0 in testing::internal::UnitTestImpl::RunAllTests (this=0x189ef90) at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:4649
#12 0x000000000068be92 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x189ef90,
    method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x672748 <testing::internal::UnitTestImpl::RunAllTests()>, location=0x6a20b8 "auxiliary test code (environments or event listeners)")
    at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:2402
#13 0x0000000000685960 in testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x189ef90,
    method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x672748 <testing::internal::UnitTestImpl::RunAllTests()>, location=0x6a20b8 "auxiliary test code (environments or event listeners)")
    at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:2438
#14 0x0000000000671606 in testing::UnitTest::Run (this=0x9171c0 <testing::UnitTest::GetInstance()::instance>) at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest.cc:4260
#15 0x0000000000696dbd in RUN_ALL_TESTS () at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/include/gtest/gtest.h:2233
#16 0x0000000000696d4d in main (argc=1, argv=0x7ffc82ee5aa8) at /apache-arrow/arrow/cpp/build/googletest_ep-prefix/src/googletest_ep/googletest/src/gtest_main.cc:37

I've tried with different compiler versions, but without any luck. Suggestions how should I fix it?

Codecov Report

Merging #1889 into master will decrease coverage by 0.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1889      +/-   ##
==========================================
- Coverage    84.2%   84.08%   -0.12%
==========================================
  Files         288      288
  Lines       43749    43749
==========================================
- Hits        36837    36785      -52
- Misses       6883     6933      +50
- Partials       29       31       +2

Impacted Files
Coverage Δ

go/arrow/math/float64_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/uint64_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/memory/memory_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/int64_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/int64_amd64.go
33.33% <0%> (-33.34%)
:arrow_down:

go/arrow/math/uint64_amd64.go
33.33% <0%> (-33.34%)
:arrow_down:

go/arrow/math/float64_amd64.go
33.33% <0%> (-33.34%)
:arrow_down:

go/arrow/math/math_amd64.go
31.57% <0%> (-31.58%)
:arrow_down:

go/arrow/memory/memory_amd64.go
28.57% <0%> (-28.58%)
:arrow_down:

cpp/src/arrow/util/thread-pool-test.cc
99.45% <0%> (+0.54%)
: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 782c5a5...4d3a4dc. Read the comment docs.

@wesm I could use some hints:
With libhdfs3 it still segfaults when setting HdfsPathInfo string members.
In the ListDirectory test case the first iteration goes well, but afterwards char* pointers have bogus addresses. For a single file, the test case passes.
There must be something obvious I can't find. Maybe this bad_alloc handling causes it?

Oof, sorry that you've run into this. libhdfs3 2.3.x. on conda-forge introduced an ABI incompatibility, see
https://issues.apache.org/jira/browse/ARROW-1465
In the meantime, you can pin to version 2.2.31 to make the problem go away

The discussion of the underlying problem is in https://issues.apache.org/jira/browse/ARROW-1445

Hmm, sooo these are the symptoms of ABI incompatibility. Pinning it, thanks!

Another error happens, but it seems fixable. I'll investigate it tomorrow.

libhdfs3 works now. Currently I'm adding libhdfs too.

Thank you @kszucs. I will take this for a spin locally and then merge

Checked this out and got this error:
~/code/arrow/python/testing  (ARROW-2300)$ ./test_hdfs.sh
+ docker build -t arrow-hdfs-test -f hdfs/Dockerfile .
Sending build context to Docker daemon  36.86kB
Step 1/6 : FROM cpcloud86/impala:metastore
manifest for cpcloud86/impala:metastore not found

Something must went wrong during checkout, because this no longer uses the Impala image.

Ok, let me nuke my branch and start over

If I recall correctly a couple of tests are failing, but the setup works correctly.

[  FAILED  ] 2 tests, listed below:
[  FAILED  ] TestHadoopFileSystem/0.MultipleClients, where TypeParam = arrow::io::JNIDriver
[  FAILED  ] TestHadoopFileSystem/0.MakeDirectory, where TypeParam = arrow::io::JNIDriver

I've fixed the python errors, but the previously pastedlibhdfs tests fail with errno: 2.
AFAIK errno isn't handled precisely in libhdfs, I'm using hadoop 2.6.0

@wesm errno == 2 here, however the library exists - only occurs with libhdfs
Should We wrap hdfsListDirectory with a closure or store the driver/adapter type in LibHdfsShim with the following condition?
if (result == nullptr && errno == 2 && this->hdfsExists(fs, path)) {
    // if libhdfs reports errno 2: no such file or directory
    // however the path exists, we set errno to zero
    errno = 0;
}

It's a super hacky solution, I don't like it, but can't think of an alternative. Perhaps We should pin a minimal libhdfs version - assuming it has been fixed.

Let me have a closer look today -- I thought I had run this with Hadoop 2.6 before and didn't hit these issues so

@kszucs do you see this?
https://github.com/kszucs/arrow/blob/ARROW-2300/python/testing/hdfs/Dockerfile#L19
The scope of the GitHub issue was to fix python/testing/test_hdfs.sh, so we should either fix that or remove it. Can you add instructions how to run the HDFS tests?

Ohh sorry @wesm !
I've ported the hdfs integration tests from arrow/python/testing to arrow/dev/ next to spark_integration because it fits more naturally with the docker-compose setup. It also has a broader scope because it runs cpp tests too.
I've planned to port dask integration as well and remove arrow/python/testing eventually (the best place would be arrow/integration though)
Please use the following command: arrow/dev/run_docker_compose.sh hdfs_integration

Sweet thanks =)

After We have all of the integration tests under the same roof (dask, spark, hdfs) We can simply just submit them as crossbow tasks (similarly like the build tasks, but defined in a separate tests.yml).
Nightly integration tests would run in the same fashion like the nightly builds.

@kszucs I applied your workaround for the errno 2 thing. I fiddled with this a little bit (including setting errno = 0 before the hdfsListDirectory call (which made one of the errors go away, I guess errno was in a bad state from elsewhere) but couldn't get it completely working without the workaround.
+1. I will merge this once the build completes to make sure I didn't mess up the lint

thanks @kszucs!


Navbar of the BIT page modified

Navbar Modified.
@Vaishnavi-Patil2211 ,please check and merge .
Closes #1150

[ x] I have linked the PR to the correct issue.
[ x] I have read the Contribution Guidelines
[ x] I have built and tested the changes, and they do not break or show any errors.

@Vaishnavi-Patil2211 ,please merge the PR


Transparent Background

In the screenshots of it in action, there is an example of the OBS image behind the text. I have not been able to get it to successfully have no/transparent background using the css -fx-background-color:transparent;.

Set the color in the .css-file to this:
-fx-background-color: #111111;

Then add a Color key filter in OBS to the stage display source with settings.
Key Color Type: Custom
Key Color: #111111 (#ff111111)
Similarity: 1


fix: Color labeled as unknown #58

Color labelled as unknown #58

Hey thanks Michael! @iamoghenerukevwe
Good debugging here, could you explain why the hsl changes fix it?
I think it's better, but I still get an unknown if you regenerate a couple of times:

This is for hex #ea7a96. I need to take a closer look. But perhaps you'll know the bug right away?

nice @prichter — thanks for chiming in. Really well explained. Excellent. Do you know the ultimate fix? Feel free to push it up

Great teamwork here.

Thanks @prichter for so coherently putting it, I discovered that boundary conditions in the if statements were causing the error of "Unknown" and to resolve the issue  would simply be to make sure that there are no gaps, in the values used for the if statements. I'll just hold until @prichter is done, then I can add in more color names.

This also seems messed up (this is on main). I'd expect Yellow vs Green for #f1f30d.

Same with red vs pink for #f30d55
I wish we could use tinycolor.toName() from https://github.com/bgrins/TinyColor but it seems that returns false for hex values. I bring up the above bugs in case the algo as a whole needs to be fixed, instead of just patching it

@alexdanilowicz certainly.  I'll work on this next...

Closing this in favor of https://github.com/Mirrorful/mirrorful/pull/182
Nice work, @prichter !


UseProtoNames=false doesn't seem to use "lowerCamelCase name in JSON field names."

What version of protobuf and what language are you using?
protoc-gen-go v1.28.1
protoc        v3.21.9
What did you do?
I'm marshaling a protobuf message using protojson
The message User has an EmployeeNumber field:
// (optional) employee number
EmployeeNumber *string `protobuf:"bytes,2,opt,name=EmployeeNumber,proto3,oneof" json:"EmployeeNumber,omitempty"`

I'm using the following go code to create such a User and marshal it:
        number := "number"
	user := User{
		EmployeeNumber: &number,
	}
	options := protojson.MarshalOptions{
		EmitUnpopulated: true,
		UseProtoNames:   false,
		UseEnumNumbers:  true,
	}
	json_bytes, err := options.Marshal(&user)
	println(string(json_bytes))

What did you expect to see?
Some json containing "employeeNumber":"number". That is, using lowerCamelCase, given I opted for UseProtoNames: false
The description is (from https://pkg.go.dev/google.golang.org/protobuf/encoding/protojson#MarshalOptions):
// UseProtoNames uses proto field name instead of lowerCamelCase name in JSON
// field names.
UseProtoNames [bool]

since I'm using false I expect lowerCamelCase.
What did you see instead?
Some json containing "EmployeeNumber":"number". That is, not using lowerCamelCase because I used false for UseProtoNames and the description for that field (as I understand it) indicates lowerCamelCase name in JSON field names will be used.

Unfortunately, it seems you’ve hit upon an interesting corner-case condition. This apparent misbehavior results from not matching up with the style guide in the naming of fields. It is expected that field names will always be snake_case, and as such, there is no need to waste cycles lowercasing the first character, which should already always be lowercased. The algorithm then capitalize each letter after seeing and skiping an '_'.
So, in the case of CamelCase field names, this means that the entire field name ends up being returned as is. This behavior is also consistent with the C++ and Java implementation.

thanks for the quick and detailed response.
Would it make sense to at least update the text around UseProtoNames to mention this?

Since this is behavior consistent across all protobuf implementations, it might be worth bringing up to the wider protobuf project. If you propose a Gerrit change, then this project would considered it as appropriate to the project.
Unfortunately, there are a lot of known issues that come up when not following the style guide. It’s a bit of a weird situation where protos written outside of the style guide are really only supported at best-effort level. It’s not treated like a standards violation, but it’s definitely not a supported path.
An important thing to remember is that protobuf is an inter-language standard, and the style guide is there to help code be more consistent with best practices in many different languages. Converting the snake_case to the local-language preferred camelCase, CamelCase or even keeping the snake_case is one part of that. And that’s why sometimes these sorts of “you’re not following the style guide” can end up outside of support.


Login command in cli lacking username

Describe the bug
A clear and concise description of what the bug is.
Currently, after deploying epinio, the suggested command to log in from cli lacks the username:
epinio login -u  https://epinio.<IP_ADDRESS>.sslip.io

Hint: Make sure to search through the existing issues, as they often contain important information on recent changes.
To Reproduce

Install Epinio
Observe how the command is
epinio login -u  https://epinio.<IP_ADDRESS>.sslip.io

Expected behavior
The commnad should include the username in order not to throw an error
Cluster (please complete the following information):

Provider: [K3D]

Desktop/CLI (please complete the following information):

OS: [Linux]
Epinio Version: v0.9.0-0.0.3
Epinio Install Options: [e.g. loadbalancer, type of system domain]

This looks to be an issue with the NOTES.txt from the epinio chart.

work@tagetarl:~/SUSE/dev/epinio/helm-charts> cat chart/epinio/templates/NOTES.txt
To interract with your Epinio installation download the latest epinio binary from https://github.com/epinio/epinio/releases/latest.
Login to the cluster with:
epinio login -u {{.Values.api.username}} https://epinio.{{ .Values.global.domain }}
or go to the dashboard at: https://epinio.{{ .Values.global.domain }}
If you didn't specify a password the default one is password.
For more information about Epinio, feel free to checkout https://epinio.io/ and https://docs.epinio.io/.

Note that there is a user name referenced. This variable is likely empty, or does not exist.

Right. The issue is that .Values.api.username got removed recently. It was replaced with the .Values.api.users list which contains two standard users, admin and epinio, in this order.

Chart PR https://github.com/epinio/helm-charts/pull/222
Main PR  https://github.com/epinio/epinio/pull/1549

Validated in the latest release: :heavy_check_mark:
NOTES:
To interact with your Epinio installation download the latest epinio binary from https://github.com/epinio/epinio/releases/latest.

Login to the cluster with any of

    `epinio login -u 'admin' 'https://epinio.<my-domain>'`
    `epinio login -u 'epinio' 'https://epinio.<my-domain>''`