Vulkan Validation Error in a default, empty app w/ window.

Bevy version
0.8-dev (main)
Relevant system information
AdapterInfo {
  name: "NVIDIA GeForce RTX 3090",
  vendor: 4318,
  device: 8708,
  device_type: DiscreteGpu,
  backend: Vulkan
}

What you did
Any project started with DefaultPlugins and a window on a vulkan backend.
What went wrong
Vulkan device creation is being provided with a non-compliant VkPhysicalDeviceVulkan12Features / device create info struct.
The expectation is that default vulkan init would be free of validation errors.
2022-07-21T14:59:03.219031Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkDeviceCreateInfo-pNext-02830 (0x211e533b)]
        Validation Error: [ VUID-VkDeviceCreateInfo-pNext-02830 ] Object 0: handle = 0x2307368ded0, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x211e533b | If the pNext chain includes a VkPhysicalDeviceVulkan12Features structure, then it must not include a VkPhysicalDevice8BitStorageFeatures, VkPhysicalDeviceShaderAtomicInt64Features, VkPhysicalDeviceShaderFloat16Int8Features, VkPhysicalDeviceDescriptorIndexingFeatures, VkPhysicalDeviceScalarBlockLayoutFeatures, VkPhysicalDeviceImagelessFramebufferFeatures, VkPhysicalDeviceUniformBufferStandardLayoutFeatures, VkPhysicalDeviceShaderSubgroupExtendedTypesFeatures, VkPhysicalDeviceSeparateDepthStencilLayoutsFeatures, VkPhysicalDeviceHostQueryResetFeatures, VkPhysicalDeviceTimelineSemaphoreFeatures, VkPhysicalDeviceBufferDeviceAddressFeatures, or VkPhysicalDeviceVulkanMemoryModelFeatures structure The Vulkan spec states: If the pNext chain includes a VkPhysicalDeviceVulkan12Features structure, then it must not include a VkPhysicalDevice8BitStorageFeatures, VkPhysicalDeviceShaderAtomicInt64Features, VkPhysicalDeviceShaderFloat16Int8Features, VkPhysicalDeviceDescriptorIndexingFeatures, VkPhysicalDeviceScalarBlockLayoutFeatures, VkPhysicalDeviceImagelessFramebufferFeatures, VkPhysicalDeviceUniformBufferStandardLayoutFeatures, VkPhysicalDeviceShaderSubgroupExtendedTypesFeatures, VkPhysicalDeviceSeparateDepthStencilLayoutsFeatures, VkPhysicalDeviceHostQueryResetFeatures, VkPhysicalDeviceTimelineSemaphoreFeatures, VkPhysicalDeviceBufferDeviceAddressFeatures, or VkPhysicalDeviceVulkanMemoryModelFeatures structure (https://vulkan.lunarg.com/doc/view/<IP_ADDRESS>/windows/1.3-extensions/vkspec.html#VUID-VkDeviceCreateInfo-pNext-02830)
2022-07-21T14:59:03.219780Z ERROR wgpu_hal::vulkan::instance:   objects: (type: INSTANCE, hndl: 0x2307368ded0, name: ?)

This is probably a bug in wgpu, the rendering crate used by Bevy. Try running wgpu's examples and/or tests. If you still get this error in those, close this issue and create a new one in wgpu's repository.

i'm getting the same issue on a rtx 2070. arch linux. wgpu examples seem to run fine.

I have the same issue on RTX 2080 (Win10) when I upgraded to 0.8.0. WGPU examples run fine.

wgpu issue: https://github.com/gfx-rs/wgpu/issues/2925

getting the same thing on arch, RX 6800M

I've been experiencing the same on an AMD RX 6700xt on Windows 10, so I don't believe it's hardware/OS related. Looks like this issue has been logged on the wgpu repo here.
Apparently it's harmless, though. I'm guessing it will take some time before the fix is applied and back-ported.

TL;DR: I'm still going to blame wgpu.
This error is affecting multiple GPUs from both Nvidia and AMD, so we can rule out driver/GPU problems. It's also happening on both Windows and Linux, so it's likely not the OS, either. The culprit is likely either bevy_render or wgpu. However, bevy_render doesn't interact with Vulkan directly – that's wgpu_hal's job.
The error that you got is saying that the list of features was invalid. The only optional feature that Bevy enables by default is TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES, which, according to the wgpu docs, is required for read/write storage access. wgpu, in turn, converts the features it receives into a list of features to be passed to Vulkan. wgpu essentially included redundant information: The VkPhysicalDeviceVulkan12Features structure has several boolean fields, which can be toggled to enable/disable many of Vulkan's features. However, in older versions of Vulkan, instead of using a single structure for most features, you would instead pass a linked list of many structures. (You still have to use a linked list if you're using features that aren't in VkPhysicalDeviceVulkan12Features, by the way.) wgpu, for some reason, decides to declare features through both techniques at the same time (probably for backwards compatibility). Vulkan's spec doesn't allow this, since it creates two different sources of truth, which can make things confusing for the driver. The output from LogPlugin suggests that the error comes from wgpu's built-in validation layer, which detected the problem and threw an error.
The solution would be for wgpu to use only VkPhysicalDeviceVulkan12Features when running on Vulkan 1.2 or newer, and use a good ol' linked list for older versions.

Marking this as blocked upstream based on current conversation, let me know if that is not correct.

The linked wgpu bug is now closed and the fix is in their 0.14.0 release.
fix: https://github.com/gfx-rs/wgpu/commit/c519901d575bd6d61711e5cf9c3c1b047e7d3cf7
issue: https://github.com/gfx-rs/wgpu/issues/2925

Is there a recommended workaround to suppress this warning when working on a new project? Ignoring it doesn't seem like a viable option when it spams the console.

@lstanden It looks like the fix for this one was merged to wgpu almost a year ago here: https://github.com/gfx-rs/wgpu/commit/c519901d575bd6d61711e5cf9c3c1b047e7d3cf7  Are you sure you are still getting the same validation error or is it a different one? It looks like this issue should have been closed.

As far as I can see, wgpu 0.16 is the one being used by bevy, and that fix in is 0.17.1

If you search their changelog it was included in 0.14 https://github.com/gfx-rs/wgpu/blob/2664da88b0c7e5090a4f6d40dea834ae79005560/CHANGELOG.md#vulkan-14
The comment right above your first one also said it would be in the 0.14 release. Note that the comments on this issue before yours are from 2022 and there have been multiple releases of bevy and wgpu since then.
I'm just suggesting that you should compare your validation error more closely to the one in this issue and let us know if it's actually the same or not (if not please create a new issue). Does your's have this part in it?

if the pNext chain includes a VkPhysicalDeviceVulkan12Features structure, then it must not include a VkPhysicalDevice8BitStorageFeatures, VkPhysicalDeviceShaderAtomicInt64Features, VkPhysicalDeviceShaderFloat16Int8Features, VkPhysicalDeviceDescriptorIndexingFeatures, VkPhysicalDeviceScalarBlockLayoutFeatures, VkPhysicalDeviceImagelessFramebufferFeatures, VkPhysicalDeviceUniformBufferStandardLayoutFeatures, VkPhysicalDeviceShaderSubgroupExtendedTypesFeatures, VkPhysicalDeviceSeparateDepthStencilLayoutsFeatures, VkPhysicalDeviceHostQueryResetFeatures, VkPhysicalDeviceTimelineSemaphoreFeatures, VkPhysicalDeviceBufferDeviceAddressFeatures,

Maybe this is a separate issue then, although it looks like it started all the same

Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-04627 ] Object 0: handle = 0x628d6100000000f7, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x45125641 | vkCmdBeginRenderPass(): Image view #0 created from an image with usage set as 0x11 but using VkImageViewUsageCreateInfo the inherite
d usage is the subset 0x10 and the image info #0 used to create the framebuffer had usage set as 0x11 The Vulkan spec states: If framebuffer was created with a VkFramebufferCreateInfo::flags value that included VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of the pAttachments member of a VkRenderPassAtt
achmentBeginInfo structure included in the pNext chain must be a VkImageView with an inherited usage equal to the usage member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer (https://vulkan.lunarg.com/doc/view/<IP_ADDRESS>/windows/1.2-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-framebuffer-04627)

Ok, after suggesting it might be different, I just found this comment in another related issue: https://github.com/bevyengine/bevy/issues/3640#issuecomment-1113793791
The solution is exactly what's suggested in that doc: uninstall the Vulkan SDK from your computer. Ugh.

They actually say it was fixed in newer versions of the Vulkan SDK. So maybe try installing an up to date version of the Vulkan SDK?

Already installed the latest version when I ran into this and realized it was Vulkan related. Appreciate the suggestion though!

@lstanden that issue is https://github.com/gfx-rs/wgpu/issues/3855 and was due to an issue in OBS (who fixed the issue in their vulkan layer, and afaik the fix will be in OBS 30 when that releases).
There's a workaround applied in wgpu 0.17, but we only just merged that into main (it'll be part of bevy 0.12 when that releases soon).
It's also possible to disable the OBS layer(s) for your bevy games in the vulkan configurator which is included in the sdk (but that might break capturing gameplay with OBS of that program, and iirc you need to manually add every bevy/wgpu app where it's bothering you)

I was having this from OBS, there's also a DISABLE_VULKAN_OBS_CAPTURE environment variable you can set to 1 that will prevent the messages.


Failing test on master & develop

MassTransit.Tests.Timeouts.When_scheduling_a_timeout_for_a_new_id.The_timeout_should_be_added_to_the_storage
Expected: True
But was:  False
This keeps me from building it out of the box.

Not failing anymore


Master 1.9 notes (Prior to release)

We’ve been flying master for the last month or two and logged a lot of hours on this so I thought I’d write up some notes prior to release.
Just for clarity:

We used 3 different airframe types.
Flew in no wind up to 12 m/s+
Conducted countless automissions from landing to takeoff and tested a lot of the new additions.
Only tested fixed wing.

A few thoughts:

Early landing (FW_LND_EARLYCFG)

We tested this a lot. It is great but it should not be enabled as default. A few reasons, if you have a plane that can create significant drag with insufficient thrust, you run a definite increased risk of crashing.

We saw this happen on all three different airframe types during our tests. No crashes to be clear occurred, but in some situations it put the planes past any comfort zone and borderline needed intervention. Of importance, each plane used wasn’t truly ideal as they all had oversized motors.
- Secondly, wind. If there is excessive wind and you are loitering in a higher drag setup, this it is not good. We actually clipped a tree top with a foam plane while being blown down a bit since there was so much lest authority, luckily it was just a wing nick and it kept going and landed fine (autonomously) but this feature coupled with adequate wind plus a not too powerful setup (or even normal power setup) can put you in a difficult spot and if you are a newer pilot this could cause problems, ie crash.
- Lastly is that while you tend to have increased airspeed while descending from the previous waypoint, the issues becomes that while actually conducting the loiter, that speed is bled off quickly and you end up back at point 1, potentially in a scenario where you have increased drag, maybe insufficient thrust and less authority.

I want to make sure I don’t want to take away from the hard work that went into this, when it works it is great and really does assist with the flap deployment altitude bump but over the last 1+ months of testing, the one clear thing is that there were multiple times where we would definitely not want this enabled (and did disable it) and having this as standard on the next release will give people sense that it should be ok in any scenario. It is not. I strongly recommend disabling this as standard and having something in the docs about when to use it, its concerns, things to think about in wind, you specific power setup, etc. Prudence would dictate disabling this as standard.

Runway tracking because of ground speed scaling of outputs. The ground speed scaling diminishes nose wheel control which is only evident if there are very long takeoffs (rollout). Generally, we ran three planes off the runway which is something we’ve never seen. This should be noted, explored, etc. I also think the reason why the takeoffs were so long should be assessed (brings me to the next point).
Negative pitch setpoint - If you have a negative pitch setpoint to use during level flight, you are essentially wanting the plane to nose down (or up) to not change altitude while in the air. The issue is that during takeoff if you look at pitch setpoint you will see that it is actually the specified pitch minus the setpoint (we have takeoff pitch set to 12º but are getting 7º of pitch up on takeoff because we have a negative set point of 5 degrees (FW_PSP_OFF). What we are seeing is a real “airframe” pitch of 7 degrees instead of 12 (because of the offset and it thinks it is 12º) and the elevator up is sort of giving 12º up but not really since when level on the ground the elevator is technically giving 5º pitch down.

Quick solution is probably to simply let runway takeoff pitch setpoint (RWTO_PSP) able to be a positive number. It is currently not allowed to be.

Wind - this is an older issue but still present. In higher winds - 10-15 m/s+ the TAS test ratio is constantly >1. @Dagar suggests increasing the TAS Gate size (EKF2_TAS_GATE) but I think there should be some talk of this prior.

Landing itself needs a lot of work to get inline with a true and robust plane style landing.
Also, and this is just an observation, the ability to have control over the throttle time constant is good (FW_LND_THRTC_SC).
Just wanted to share some thoughts.

@dagar We've taken care of all but these.

PR to disable FW_LND_EARLYCFG by default. https://github.com/PX4/Firmware/pull/11843

Runway tracking because of ground speed scaling of outputs. The ground speed scaling diminishes nose wheel control which is only evident if there are very long takeoffs (rollout). Generally, we ran three planes off the runway which is something we’ve never seen.

Is this a regression? Could you share any new logs that show the problem? Even more helpful would be if you have older logs where it wasn't an issue.

PR to handle the FW pitch setpoint offset properly in all scenarios. https://github.com/PX4/Firmware/pull/11845

Runway tracking because of ground speed scaling of outputs. The ground speed scaling diminishes nose wheel control which is only evident if there are very long takeoffs (rollout). Generally, we ran three planes off the runway which is something we’ve never seen.

https://github.com/PX4/Firmware/blob/d36b06f779d49d8dc7387bf2b4fa3aade999ada3/src/modules/fw_att_control/FixedwingAttitudeControl.cpp#L647-L650
The current groundspeed scaling logic only applies once your groundspeed exceeds 60% of your min airspeed. I don't know the history of this magic number.

@priseborough Could you please chime in here?

Here is some data and notes. They are grouped into tests and test days. Some brief notes are present but theres some flights to look at if need be for data. More if needed.
Test Plane   2
Flying fine but pre-loiter fix - take off is fast (no ground steering issues). No psp-offset:
https://review.px4.io/plot_app?log=6338f82c-163a-4250-bd03-9a3618d2fd22
https://review.px4.io/plot_app?log=d430c100-0dee-486b-857c-32670cbccfd8
https://review.px4.io/plot_app?log=05f3060a-7222-4423-bf19-05f02fef815b
https://review.px4.io/plot_app?log=e421d610-1f31-4f15-9321-8656a4d1ce8d
https://review.px4.io/plot_app?log=cbae2d66-5c98-4fd8-b6a6-b556d0591f0a
https://review.px4.io/plot_app?log=b3f64035-ab96-47c5-8c55-29df9ee412b9
Flying fine post-loiter fix - take off is fast (no ground steering issues). No psp-offset
https://review.px4.io/plot_app?log=72823f80-5c7c-4410-92c0-60c08fc66e70
https://review.px4.io/plot_app?log=5d6a9598-d08b-43a1-aa2d-3376618247e0
https://review.px4.io/plot_app?log=7407282f-7a21-4c55-aa5b-6b97c1d00f78
https://review.px4.io/plot_app?log=ea1cd724-576a-4bab-8ae4-dc37fc5a7e75
Flying fine - ~7 m/s wind creates TAS checkbit fail - take off is fast (no ground steering issues). No psp-offset
https://review.px4.io/plot_app?log=32c5651f-76a1-43bf-9e2b-86786b673142
https://review.px4.io/plot_app?log=500d30df-83ce-4298-8859-1dc0c80cc912
https://review.px4.io/plot_app?log=325f67ed-b7b5-40ac-9468-5cdeeae687da
https://review.px4.io/plot_app?log=0b2a1298-bb69-4895-98e8-517a823f26c0
https://review.px4.io/plot_app?log=82bd73cf-09f4-4a96-9954-13c849de8712
Flying fine -Testing FW_LND_THRTC_SC and altering landing settings (flare/Take-off is fast (no ground steering issues). No psp-offset
Lots of TAS flags for no real reason.
https://review.px4.io/plot_app?log=e98c02d4-2bdd-4ee4-9d83-000f71c6f829
https://review.px4.io/plot_app?log=c150c0b6-c1b7-4b7a-8ef5-9cb7c221424d
https://review.px4.io/plot_app?log=ca05c861-63da-4999-b20c-d7c486510757
https://review.px4.io/plot_app?log=a70dfbed-defb-4151-bee7-78833d2b7d32
https://review.px4.io/plot_app?log=b57515e2-db1b-4aa2-885d-54143f09b3e4
https://review.px4.io/plot_app?log=2398c72f-da49-49bf-bdfb-28f9fba7c297
https://review.px4.io/plot_app?log=e7b0753d-e7db-4312-a676-68b1c394cd9a
https://review.px4.io/plot_app?log=349097d9-e4d0-4a1b-b1a1-fe3ceb6e300b
https://review.px4.io/plot_app?log=1a017f5a-3958-4ff8-a2cf-d289a8963c60
https://review.px4.io/plot_app?log=99152b04-b769-4f64-aa23-db466b113c48
Test plane 3
CRASH - LOG missing (will need to locate). Due to ground steering, shallow takeoff and then pilot error   switching modes.
12-14 m/s wind.   Flying fine but TAS checkbit error.
https://review.px4.io/plot_app?log=1c6d0251-272d-4434-b898-d109b0b13ab2 Ground Steering failure (high head wind and 60% issue most likely)
https://review.px4.io/plot_app?log=b2f50bec-a9d3-41ae-a1b1-3bdd701ec2c9 Ground Steering failure (high head wind and 60% issue most likely)
https://review.px4.io/plot_app?log=222b48b8-54bc-49af-97af-39eaadc93bae Ground Steering failure (high head wind and 60% issue most likely) Increased FW_PR_P leads to oscillations on FFT graph - flying sufficiently though.
Testing flare to alt WITHOUT early landing on.
https://review.px4.io/plot_app?log=51293785-52c3-4901-a88f-327aa675459c Less wind (5-7 m/s) lots of checkbits hitting.
https://review.px4.io/plot_app?log=21ed6aaa-4bcd-4542-befe-0f407e7c35f8 Lands very long (too long)
Lower wind, testing decreased FW_PR_P
https://review.px4.io/plot_app?log=14e3a6cf-7688-4c77-a5bc-44c4099c1782 High vibration - motor change needed but not done for consistency
Poor take off and landing
https://review.px4.io/plot_app?log=bd117170-1dca-42a8-a309-58b537296419 Steering error and shallow takeoff so position mode entered into and then back to mission. Mag checkbits may be the issue here.
https://review.px4.io/plot_app?log=3198efbc-5eff-4d7a-8371-31aa64c563b6 Long landing, put into position mode to cut motor right when about to land.
https://review.px4.io/plot_app?log=08ff0f58-b264-49b0-a694-58eab9b76ffd Super long landing, ended  landing while just about to land as was going to hit tree line, avoided crash by turning right.
https://review.px4.io/plot_app?log=998a6802-6a13-41d2-95ba-15d5213d0e03 Ground steering so bad that turns left to circle back to hit takeoff waypoint. Mag checkbits?? Wind 7-9 m/s
Very good flights and landings. 12 m/s wind. Takeoff and ground steering good.
https://review.px4.io/plot_app?log=652d869f-713b-424a-8402-8d3a233a42ab Really good flight and landing - mode change was due to new ground-station improperly calibrated for mode change switch.
https://review.px4.io/plot_app?log=b16d8104-d0e3-4e84-8ed4-656989e639fa Really good flight and landing - mode change was due to new ground station improperly calibrated for mode change switch.
Lastly is a snapshot from one of our daily flight assessments post flight. Done to see impact on flare at touchdown. Any questions and let me know.

I think the 60% scaling issue is an issue for two reasons, one if there is high head wind on takeoff, where on one hand would lead to shorter takeoffs and not pose an apparent issue but the issue is still there just not realized all the time and secondly (and more importantly), when you are at 60% of min speed and not at whatever percentage you have set for pitch up to start (we are at 85% of min speed) that 25% can be super fast but if it takes some time, (seconds, meters, however you want to measure it), it poses an issue or window for there to be an error present.
Obviously the concept makes sense, as speed is increased we dont want a hard right on the nose wheel so we dont flip over but there is probably something that needs to be done.
Also, we saw on many occasions, when hitting the mission start the nose wheel would immediately go full left or right for a split second. On the smaller planes this would cause a flip over and the mission would need to be aborted (likely not in the above logs as those are all flights), but in some instances it would still recover quickly and be okay (no flipping, etc). On the larger planes it occurred but would recover very fast all but a few times. This probably is reflected in the above. Why, i'm not sure but we ended up limiting the max and min pwm the nose servo could output via qgc, not the servo programmer. Food for thought. There will be examples of both in the above.

Wind - this is an older issue but still present. In higher winds - 10-15 m/s+ the TAS test ratio is constantly >1. @dagar suggests increasing the TAS Gate size (EKF2_TAS_GATE) but I think there should be some talk of this prior.

I've been through the https://review.px4.io/plot_app?log=1c6d0251-272d-4434-b898-d109b0b13ab2 log with the following observations:

Sideslip innovations are small, but airspeed innovations are large which normally indicates an issue with airspeed sensor calibration:

This is confirmed by over-plotting GPS ground speed and true airspeed which for a close circuit flown should show TAS sitting halfway between min and max ground speed:

The continued high TAS innovation test ratio looks to be a true indicator of a large pitot-static calibration error.

Thanks for looking and good to know. It does raise questions though as every one of these flights are done on the sensirion sdp33 units all with measured tubes, etc and calibrated prior to each flight (or groupings of flights).
That raises questions as to what to do then.

The other high wind logs show similar characteristics, so this flight vehicle definitely needs to have the differential pressure scale factor adjusted.

A calibrated probe/pressure sensor by itself is insufficient - the airflow around the aircraft induces a change in static pressure at the static holes and therefore the differential pressure seen by the sensor. This varies from installation to installation and measuring and correcting for it should be part of the commissioning procedure.
I have never commissioned PX4 for a FW platform so am not familiar with the parameters used to calibrate the airspeed sensor, however looking in the code for the SPD3X driver I do not see where the user can calibrate for this error. I will investigate further.

Thanks for the insight on this. The pitots are in the nose of the aircraft protruding out their full length, ie not on the wings or sides of the fuselage. This has always been in an attempt to have a clean access to airflow.
This does raise an interesting point of how to measure and correct for this in any installation. I do have some high wind logs of this occurring with a different airspeed sensor and if keeping the pitot out the nose away from everything isn’t ideal than figuring out what is or how we correct for that would probably be pretty helpful for all.
Thanks for looking into this further. I’m quite intrigued.

A calibrated probe/pressure sensor by itself is insufficient - the airflow around the aircraft induces a change in static pressure at the static holes and therefore the differential pressure seen by the sensor. This varies from installation to installation and measuring and correcting for it should be part of the commissioning procedure.

@ryanjAA @priseborough Just saw this in passing and thought I might give some heads-up from my own experience with this sensor -- we use it exclusively because it's great at low speeds, but Paul is correct that the given parameters do not account for other flow around the aircraft. We've dealt with this so far by simply using one of the parameters (specifically the diameter) to adjust (fudge) this after checking the performance in flight. This is quite simple to do by just flying a constant altitude loiter for a few times in a row, and then adjusting the param until the true airspeed sits directly in the center of the ground speed oscillations -- I've actually written a script that will automatically do this using the wind triangle equations and a constant wind assumption to back calculate out the diameter that fits the physics using nonlinear least squares (only a few lines of matlab code -- but I'm sure could also easily be done in python). It's a little hacky, as of course a more proper solution would be to introduce a new parameter for airflow interference effects .. but until then, adjusting the diameter is pretty easy/effective.
Anyway - just thought it may be helpful!

@ryanjAA Air in front of the nose has been partially slowed which increases static pressure (Bernoullis law applies) and reduces differential pressure/airspeed measured. Air above the wing or around the side/topof the fuselage tends to be accelerated and therefore has lower than atmospheric pressure which causes the airspeed to read high. Probes on full size aircraft are carefully placed in a region where the air is close to free-stream velocity and static pressure close to atmospheric.
Flying in a circular loiter and adjusting the scale factor until the average airspeed innovation is zero or the TAS is in the middle of the ground speed is one way to do it. Also be aware of TAS vs EAS/IAS differences as test altitude and temperature increases.

Interesting, although that does raise some other questions given i've seen this on several airframe types, not the same vehicle or even vehicle shape which means there needs to be a way to manage this other than putting something at risk in the air. Granted, i've never seen a crash because of this but if the front of the fuse is going to give slower than actual readings and placement around the wing area gives faster than actual then the safe bet is still the nose. I can pull out all the CFD work and modeling done etc but that's not helpful to other users of other airframe types which is the real aim here to solve. Surely I can't be the only person seeing this. Maybe only very few are reporting it or know to even report it? @tstastny definitely has seen it given your comments so I'm not alone here but the sdp3x units are only on our test vehicles and I have some logs of this happening on the older ms4525 airspeed as well. A fix with those would be I assume altering the SENS_DPRES_OFF for non sdp33 units?
We ran some bench tests (indoors) with a set known windspeed device and an anemometer as well as the sdp33 units in the plane prior to the first real tests as a sanity check but I believe we only ran them to 10-12 MPH so much slower and not in a real-world scenario (as there was no reason to doubt their use).
@tstastny is your work private or available somewhere? I'm wondering if this can be incorporated in during flight (well instead of fudging the tube mm, adjust the scale factor) but there must be a methodical way to approach this rather than a fly and test and fly and test given it's one of the critical things to know and from the sounds of, people are possible having this issue and not even knowing it.
The fact that TAS vs IAS will change at altitude and temp (is a known understandable thing) but the fact that it further convolutes the issue means this all probably really needs some attention.

sdp3x sensors are "flow-through" style sensors and can be tricky to calibrate.  Amazing performance for their size, but very sensitive to pressure drop in the tubing and pitot-static tube upstream of the sensor.  Also can't test for leaks very easily since a flow-through system can't hold pressure.  We continue to use the old cheap ms4525 series even though they have relatively terrible performance.


[Duet] Write tests.

Duet needs tests that are benchmarked against the original matlab implementation.

Tests are written and are in "test" folder


Shows the radius in the home page

#9 shows the radius in the home page (index.html)

Why was this PR closed? Shouldn't it have been merged instead?


Ghost admin displays emails analytics despite being disabled

Issue Summary
Reporting based on suggestion by @naz in https://github.com/TryGhost/Ghost/issues/12496#issuecomment-764906785
Ghost admin displays emails received and opened under member details although newsletter open-rate analytics is disabled under Labs > Members.
Reference screenshot:

Issue Details
I have exactly the same issue as others reported in #12496 - ghost crashes with an error message that seems to be related to email analytics. I turned off email analytics as soon as I discovered that ghost was crashing, shortly after the feature was originally released.
My expectation was that the INFO Worker for job "email-analytics-fetch-latest" exited with code 0 error in issue #12496  would go away since there would be no email analytics to fetch to begin with. However, seeing the email open and click rates in member details makes me think that the ghost is ignoring the settings in the admin panel.
I'm on a digital ocean droplet built from the ghost image, using mailgun integration for emails without any issues.
Technical details:

Ghost Version: 3.40.5
Node Version: v12.20.1
Browser/OS: Safari Version 14.0.2 on macOS Big Sur
Database: mysql  Ver 14.14 Distrib 5.7.32

Hi @onurozer,
As explained in the referenced issue, the "newsletter open-rate analytics" checkbox only changes a flag that is set on outgoing emails sent via Mailgun's API, it does not turn on or off anything to do with workers or jobs. It also will not hide the UI. It is preventing stats being generated going forward, not historically.
As also explained in the same issue there are two config options you can use to control this behaviour, one of which will hide the UI if you don't want it.
This is all as expected at the moment, not a bug.


Basic Implementation of  User Authentication

Basic Authentication (Login/Signup)
Password recovery
Discussion open about the library to use like passportjs, discuss with the team about the solution to be used.

hello any update on this ?

Ok guys, about solution. I noticed you installed next-session already since we won't be doing cross-site requests. I guess the simpler path to take is next-session to store the user information and will be access in the browser context as props.
So what i will need to work on now are (Thats creating methods since api design comes later);

[ ] Login Flow
[ ] SignUp FLow
[ ] Password Recovery


Push notifications are not getting displayed in IOS and Android randomly

Describe the bug
I have used kreait/laravel-firebase package in Laravel framework. I'm trying to send bulk push notification, But some users are not getting the notification. It randomly occurs to some users. Can't find the exact solution for this problem.
Following the custom error logs from firebase:
Requested entity was not found.
Internal error encountered
Installed packages
kreait
/
laravel-firebase

PHP version and extensions
8.0.26

Steps to reproduce the issue.
$message = CloudMessage::new();
$androidConfig = AndroidConfig::fromArray([
'ttl' => '3600s',
'priority' => 'normal',
'notification' => [
'title' => $notificationBody['title'],
'body' => $notificationBody['body'],
'color' => '#16BFFF',
],
]);
                 $data = [
                        'click_action' => 'FLUTTER_NOTIFICATION_CLICK',
                        'sound' => 'default',
                        'default_sound' => true,
                        'id' => $id,
                        'notification_id' => $notificationData['id'],
                        'type' => $notificationData['type'],
                        'object' => isset($this->param)
                            ? json_encode($this->param)
                            : null,
                        'invite_by' => isset($this->inviteBy)
                            ? json_encode($this->inviteBy)
                            : null,
                    ];

                    $message = $message->withAndroidConfig($androidConfig);
                    $message = $message->withData($data);

                    $report = $messaging->sendMulticast(
                        $message,
                        $androidDeviceTokens
                    ); // Sent bulk push notification to user device using fcm

Error message/Stack trace
{"0":{"report":{}},"1":{"error_message":"Requested entity was not found.\n"},"2":{"error_code":0}}
{"0":{"report":{}},"1":{"error_message":"Internal error encountered.\n"},"2":{"error_code":0},"6":{"report":{}},"7":{"error_message":"Internal error encountered.\n"},"8":{"error_code":0},}

Additional information
No response

Please see https://firebase-php.readthedocs.io/en/stable/cloud-messaging.html#error-handling for the different errors.
There's nothing this library can do about server errors, this is on the Firebase Service's side and sometimes happens.
Unknown registration tokens (the docs explain how this can happen) are not recoverable, I'd recommend removing them from your system (you can't do anything with them), but, of course, that's up to you 😅


Rework pool construction

Arguments would be a sequence of dice, or convertible-to-dices. If truncation is available, we would produce the efficient class as the current Pool, otherwise, we would produce a less-efficient class that treats each die separately. The current PoolRoll would just be a collection of single-outcome dice.

[x] Debug descending direction.
[x] Re-implement direction selection.
[ ] Re-optimize popping.
[x] Finalize a class name.
[ ] Try to merge the two directions of code.

I considered making pool objects hidden, but this doesn't play well with count_dice.

Substantially done. May revisit the remaining items later.


fs-extra should be a regular dependency

Since it's used other than during the build process, the fs-extra package is actually not a dev dependency.

Oops!Thanks for PR.


core temp 0?

When reviewing temps in zcfan and psensor, it appears that zcfan temp shown is nvme sensor 1.  The cpu sensor ID is lmsensor coretemp-isa-0000 Core 0, and the nvme ID sensor is PCI adapter-nvme-pci-0400: sensor-1.
Observing both the zcfan temps compared to psensor temps and Sensors Monitor (Sensors@claudiux) applet, the temperatures that agree with zcfan temps is the nvme pci 400: sensor - 1.
I reviewed the readme in  the usr/share/doc/zcfan as well as changelog.debian, etc.  It is my understanding that the temps shown in terminal after entering sudo zcfan, are generated from hwmon.  Unfortunately due to the number of hwmon number titled folders, I was unable to narrow down to the exact folder that zcfan utilizes.  I do have a couple of suggestions to perhaps assist those of us that experience this issue with the differences in sensor readings in lmsensors and hwmon settings, with a script showing the address of the hwmon that is utilized to assist in any changes that are necessary concerning which sensors the hwmon should be pointing in the readme, and another addition to readme would be the steps necessary to redirect to the hwmon that corresponds to the lmsensors if needed.
Perhaps I should not be going down the rabbit hole on this, but it is somewhat disconcerting that the cpu temps shown in terminal do not correspond to the lmsensors temp readings.  Also, thank you and all involved for providing zcfan for Lenovo Thinkpads.  It is very cool - pun intended.

Hi! I'm not entirely clear what the problem is here (other than the bugged sensor). zcfan uses the highest temperature recorded by any sensor, so a single sensor reporting 0 shouldn't cause a problem. Is there a problem?

HI, all is good, I know have a clear understanding that the CPU temps are not the specific trigger for CZFAN, but the rather,  based upon the sensor with the highest temp.  This is an awesome fan controller.  Please feel free to close this issue.
I wish there was a Linux fan controller for intel MacBook Pros that was as easy and efficient as the solution provided by CZFAN.
Thank again!


Slide Deck Introduction page (sort of an orphan)

Note quite sure where this page came from: http://community.openspending.org/about/community-site/slide-deck-introduction/
I think this is a bit of an orphan and we want to delete and put slide deck on the front page or just delete and put slide deck on a page called "Presentations" or similar.
/cc @danfowler for your input as czar of the migration

OK, I cleaned this up a bit :ru:

Thanks though I'm still not sure a dedicated page is that useful - who would visit it?
Either we embed in front page (that's useful if we think deck is useful) or, if we do not think that is warranted, we probably want this in a page called "presentations" or similar where we collect not only this but other decks over time (what section this would come under is not clear but about seems reasonable).

I'm not sure a slide deck is how I want to introduced to a website/community :smile:.  /about/presentations/ is a list of presentations. Perhaps it can be moved from a dedicated page to an entry in the "Presentations" collection, and still be listed in /about/presentations/

OK. I would say a video or slidedeck (for those without videos) are standard intro practice on many websites i've been to - not perfect but better than a few words and allows people to get a sense of what we are doing - right now if i arrive I'm not sure i'd find out that quickly and people are notoriously poor at clicking.
As an initial move let's just get the standard presentations page and have this as one item (i did think the old site had a list of presentations somewhere too but i may be mistaken).


JuliaSim: Machine Learning Accelerated Modeling and Simulation | Chris Rackauckas | JuliaCon2021

Video link: https://www.youtube.com/watch?v=lNbU5jNp67s
00:07 Introduction
00:42 Industrial application of Julia
02:44 Fast Differential Equation Solvers
05:07 Speedup of symbolic computation
05:52 Integration with neural networks
06:45 Engineering a Community
09:48 SciML coverage
10:58 Missing pieces in SciML
15:29 JuliaSim introduction
17:32 Next generation of algorithms
18:27 Acceleration via surrogates
21:57 Composed surrogates
23:42 Training surrogates with JuliaHub
24:13 Pretrained models
25:39 GUI
26:30 Examples of JuliaSim integration
27:27 JuliaSim Roadmap
28:26 Try JuliaSim

Added, thank you!


Fixes to dropdown menu

Description
Please include a summary of the change and a link to which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # DropdownMenu Styling

Username on dropdown fixed by using UserHeader component
Dropdown issues fixed with applying line-height
Issue with CSS reset was causing vertical align to mess up the caret

Type of change
Please delete options that are not relevant.

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

Change status

[x] Complete, tested, ready to review and merge
[ ] Complete, but not tested (may need new tests)
[ ] Incomplete/work-in-progress, PR is for discussion/feedback

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

[ ] Test A
[ ] Test B

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] There are no merge conflicts

There are merge conflict issues that need to be resolved.


[ALLUXIO-1727] Added Portuguese language option to site.

Added Portuguese language option to support future translation of docs to Portuguese.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Tachyon-Pull-Request-Builder/8611/
Test PASSed.

LGTM, thanks for adding our third language!


Work around a diagnostic using CommandLine.arguments on older toolchains.

…hains. (#2622)
CommandLine.arguments is declared read/write in older toolchains and this causes an error diagnostic when it's used in Swift 6 mode. This PR uses CommandLine.argc and CommandLine.unsafeArgv directly instead so the diagnostic does not occur.
Cherry-picked from main (#2622, 6c459f2728572a64c4b29ce3140daa90c3c6e7d1) because certain combinations of toolchains and swift-syntax versions are now incompatible. Until that issue is resolved and those toolchains have aged out, the workaround is needed, but we can presumably revert it in a few weeks if it's bothersome.

Explanation: Certain combinations of toolchains and swift-syntax versions are now incompatible. A build error occurs when using swift-syntax-600 with those toolchains.
Scope: Implementation only.
Issue: #2622
Original PR: #2622
Risk: No obvious risk. The implementation of CommandLine.arguments is equivalent to the code added in this PR.
Testing: Tested at desk with the change locally and pulling from the main branch after it was merged there. The diagnostic is gone.
Reviewer: @bnbarham @ahoppen


WIP -- Testing  CI

I am testing if CI failure in https://github.com/apache/arrow-rs/pull/5525 is related to the change in that PR

Fix merged


Godot engine is actively fighting against making more secure enviroments without using C++

Godot version
4.0.3 [5222a99f5]
System information
-OS: Android
-Godot Version:4.0.3 [5222a99f5]
Issue description
Every single time, you are trying to limit functionality to scripts, the engine is actively trying to fight you on it, it really does not want to cooperate, it always just fails. c
My goal objective was to limit FileAccess and OS singletons, that way i can enable object serialization and also allow mods to be loaded in safely. Unlike other scripting languages (for example Lua) where it's as straight forward as literally wiping it from the global enviroment, you cannot do this in GDScript.
register_singleton() will not propagate singleton changes to GDScript, which means you cannot do anything.
(FileAccess as Object).set_script(load("res://test.gd")) will also not work, since FileAccess's real base (GDScriptNativeClass) is unreachable and hidden, making anything fail.
Setting script would be quite nice, as you can limit the programmers from running set_script(null) by overriding the function, and then you can override open() to make a whitelist of what files can be accessed and when.
All i want to do is add security, and it always fails. Private variables were never implemented. The least thing you can do is to create a function to get the stack trace to a string instead of just making it print. That would allow developers to atleast check what function is calling and from where, and would allow them to implement it.
Steps to reproduce
Attempt to access GDScriptNative from the global scope will result in an error.
Minimal reproduction project
project.zip
(created with tar -cf)

FileAccess isn't derived from GDNativeClass, you're using the name of the class, which is handled by this, FileAccess is RefCounted

GDScript is currently not suitable for implementing secure mods. Artificial restrictions like the one you suggested or #61831 does NOT provide security, these restrictions are very easy to bypass (if you know Godot). Source code validation can be tricky to bypass, but it's a fairly complex and unreliable approach.
A possible solution could be to implement your own simple language or command interpreter, if you don't need complex features and high performance. But you must understand exactly what you are doing in order to prevent security breaches.
There is also a third-party Godot LuaAPI module. It's in early development and I haven't tried it, so don't take it as a recommendation, just let you know if you're interested.
See also godotengine/godot-proposals#5010.

GDScript is currently not suitable for implementing secure mods. Artificial restrictions like the one you suggested or #61831 does NOT provide security, these restrictions are very easy to bypass (if you know Godot). Source code validation can be tricky to bypass, but it's a fairly complex and unreliable approach.
A possible solution could be to implement your own simple language or command interpreter, if you don't need complex features and high performance. But you must understand exactly what you are doing in order to prevent security breaches.
There is also a third-party Godot LuaAPI module. It's in early development and I haven't tried it, so don't take it as a recommendation, just let you know if you're interested.
See also godotengine/godot-proposals#5010.

This is exactly what i was looking for, thank you.


Suggestion: Add DisableCoInstallers to Windows post-install guide

Hi, thank you for producing this guide.
Recently when debugging a system plagued with I/O issues, I had gone to lengths to try disable Windows from auto-installing third-party software using the registry methods already outlined in the guide.
I found in several cases, particularly Razer and Alienware hardware were installing their own bloatware even with these registry edits applied. In this case of Alienware - simply plugging in their monitor would auto-install the Alienware Command Center without any permission/asking. Razer would bring up an installer setup - even when declined would go ahead and install various Razer DLL files, for simply plugging in a mouse.
It has since been discovered that some of these coinstallers (Razer in particular) are abusing sys admin privileges to bypass UAC and user consent. In addition, several security vulnerabilities have been highlighted from this, which are not addressed by MS as of time of writing.
To prevent this, I had to do the following:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer
Add DWORD-32 value named DisableCoInstallers and set it to 1
This registry edit appears to prevent driver coinstaller bloatware from auto-running when a device is plugged in.

Under System properties (sysdm. cp) -> Hardware -> Device Installation Settings -> Set to No
Note: This setting was off for me and Razer/Alienware would still install, so this setting is not reliable on it's own.
Sources:
https://www.bleepingcomputer.com/news/microsoft/how-to-block-windows-plug-and-play-auto-installing-insecure-apps/
https://twitter.com/wdormann/status/1432703702079508480
I think it would be beneficial to add this to the guide for others, as this is becoming an increasing problem.

Thanks for the suggestion, there are downsides to making this change as other types of drivers use co-installers, audio, printing and perhaps some others. I believe the razer co-installer is only an issue if you allow automatic driver downloads, I have recommendations for disabling automatic driver installs in the post install process.
I would probably add this as optional with some reasoning why/why not.

For me I had the Razer software installing, even with the driver install tweaks applied + rebooted.
Others seem to experience this also - it seems Razer are pulling some voodoo to get around everything. Setting DisableCoInstallers was the only thing that stopped this for me. Hence why I suggested it could be added to the section about preventing driver installs, for anyone else with this issue.
Thanks!

Thanks I'll try to recreate it, I have some razer gear I can test with.

Is it possible you've built a custom iso that has already added the drivers?
I'm unable to replicate the behavior so far with a default windows 10/11 iso, the most critical part of my process is to not connect to the internet during the install process, apply the registry keys then restart the computer and at that point you can connect to the internet.
If you're doing a windows 11 install and not using a local account setup this is probably reason since you otherwise need to establish internet to install it using your microsoft account.
You can initiate local only account setup using this process.

Disconnect your ethernet before starting
After the initial disk and install process completes, press shift + F10 to open a command prompt
Go to the directory C:\Windows\System32\oobe\ then run BypassNRO.cmd
The windows 11 process will restart and continue as you would like a Window 10 install, do not reconnect the network card.

Added in recent commit to the Post Installation steps.


Cannot call write after a stream was destroyed

node: 18.16.0
os: Mac
pnpm: v8
mini reproduction: https://github.com/JiangWeixian/react-streaming/tree/test/destory
steps:

pnpm i
pnpm tsx ./server.tsx
pnpm tsx ./request.ts and CTRL+C.

Will throw this error:
Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
    at __node_internal_captureLargerStackTrace (node:internal/errors:490:5)
    at new NodeError (node:internal/errors:399:5)
    at write_ (node:_http_outgoing:880:11)
    at ServerResponse.write (node:_http_outgoing:831:15)
}

Maybe a fix for this:
convert this
writableFromUser.write(chunk, encoding, callback)

into this
if (!writableFromUser.destroyed) {
  writableFromUser.write(chunk, encoding, callback)
}

If this is a bug, I like to open PR for this issue

👍 PR welcome.


upgrade in our workflow

https://user-images.githubusercontent.com/1469198/178315406-e70d95e2-97cb-4016-8cf1-7c447ad3e921.mp4

ok, i think it works


How to add predefined tags from Mailchimp

How to I use tags from Mailchimp and where do I find the correct tag/group ID?
I've tried setting the tag-name as a state and adding the value to a hidden field:
state = {
  tags: "Community",
};

addToMailchimp(this.state.email, {
  TAGS: this.state.tags,
})

<input
  id="tags"
  name="tags"
  type="text"
  defaultValue={this.state.tags}
  readOnly
  hidden
/>

This does not work. Any suggestions on how to send in or connect to the correct tag?

Found out how to add new signups to a Mailchimp group.
In Mailchimp go to Audience -> All Contacts -> Manage contacts -> Groups. Create your group category and add group names.
After creating your group, go to Signup forms -> Embedded forms -> Find your your new group inputs and copy the names. They look something like this: name="group[13080][0]".
Then in your Gatsby app, you can paste your group names into the addToMailchimp object:
addToMailchimp(this.state.email, {
  "group[13080][1]": "1",
  "group[13080][2]": "2",
})


Roll engine f34bc65bee49..f3ce90e9387b (20 commits)

https://github.com/flutter/engine/compare/f34bc65bee49...f3ce90e9387b
git log f34bc65bee49..f3ce90e9387b --first-parent --oneline
2020-02-06<EMAIL_ADDRESS>Reset width/height before deallocation for Safari allocation bug. (flutter/engine#16469)
2020-02-06<EMAIL_ADDRESS>Roll src/third_party/skia 116b33e8ab21..7f36405ea3ec (3 commits) (flutter/engine#16471)
2020-02-06<EMAIL_ADDRESS>Roll src/third_party/skia cc21d0c1f2ce..116b33e8ab21 (3 commits) (flutter/engine#16466)
2020-02-06<EMAIL_ADDRESS>Roll src/third_party/skia f6e3eaf05150..cc21d0c1f2ce (1 commits) (flutter/engine#16463)
2020-02-06<EMAIL_ADDRESS>Roll src/third_party/skia 4721e067812f..f6e3eaf05150 (1 commits) (flutter/engine#16461)
2020-02-06<EMAIL_ADDRESS>Roll src/third_party/skia cbf79b95c2d4..4721e067812f (1 commits) (flutter/engine#16459)
2020-02-06<EMAIL_ADDRESS>Roll fuchsia/sdk/core/linux-amd64 from VJv0H... to A9STP... (flutter/engine#16457)
2020-02-06<EMAIL_ADDRESS>Include  in hb_wrapper.h because unique_ptr is used. (flutter/engine#16442)
2020-02-06<EMAIL_ADDRESS>Roll rapidjson (flutter/engine#16347)
2020-02-06<EMAIL_ADDRESS>Wrap strdup to use compliant name on Windows (flutter/engine#16372)
2020-02-06<EMAIL_ADDRESS>Add explicit casts to printing of function pointers (flutter/engine#16370)
2020-02-06<EMAIL_ADDRESS>Roll buildroot (flutter/engine#16419)
2020-02-06<EMAIL_ADDRESS>Roll src/third_party/skia ebc00f97fab1..cbf79b95c2d4 (4 commits) (flutter/engine#16456)
2020-02-06<EMAIL_ADDRESS>Roll fuchsia/sdk/core/mac-amd64 from ubThi... to fvWgE... (flutter/engine#16454)
2020-02-06<EMAIL_ADDRESS>Suppress some deprecation warnings on Windows (flutter/engine#16416)
2020-02-06<EMAIL_ADDRESS>[fuchsia] change kMaxFramesInFlight to 3 (flutter/engine#16425)
2020-02-06<EMAIL_ADDRESS>Reland #16206: "[web] Correct getPositionForOffset for multi-line paragraphs" (flutter/engine#16365)
2020-02-06<EMAIL_ADDRESS>fix bad reference to maxDiffRatePercent (flutter/engine#16440)
2020-02-06<EMAIL_ADDRESS>Added a plugin method that gets called when the engine is about to be deleted (flutter/engine#16336)
2020-02-06<EMAIL_ADDRESS>Roll src/third_party/skia bc3307c395e2..ebc00f97fab1 (21 commits) (flutter/engine#16429)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

The tree is grene, flutter status is wrong, merging this manually to get the roller moving.

/cc @keyonghan  - is your recent change to cocoon in yet?

Yes. I have already deployed it in appEngine.


Error on sched report  policy

Policy Template Name
Scheduled Report
Issue Type
Bug
Policy Template version (Bug Only)
1.1
Error Messages (Bug Only)
Summary:
failed to retrieve datasource data
Detail:
unexpected response status
POST https://optima.rightscale.com/bill-analysis/orgs/6698/costs/aggregated
got "400 Bad Request", expected a status in the 200 range
response body:
{"id":"mxgWKvhV","code":"bad_request","status":400,"detail":"startAt "2019-02-04" must be before endAt "2019-02-04""}
Location:
datasource "ds_report"
script "js_report"
argument "current_week_costs"
datasource "current_week_costs"

The policy ran again on its own and ran fine. Not sure under what conditions that error occurs.

@ryanoleary Happens on Mondays. Working on a fix.


Add Athom Smart Plug AU

Device information

https://www.athom.tech/blank-1/esphome-au-plug
Home Assistant Device information

Smart_Plug_V2
by Athom_Technology
Firmware: 2023.11.6 (Dec 6 2023, 13:08:47)
Hardware: 2.0
Checklist

[x] I have created a single PR per device. When you have multiple submissions please create separate PR's.
[x] For lights - I have only included the gzipped files (*.gz), not the raw CSV files.
[x] For lights - I have provided a CSV file per supported color mode. Look that up in Developer Tools -> States

Additional info

Refs #1952 - pictures of power measurements.

You can add alias in model.json that will make the plug auto discovered when starting HA.
Also needs entry in aliases.py. https://github.com/bramstroker/homeassistant-powercalc/blob/master/custom_components/powercalc/aliases.py
For Athom_Technology -> athom.
See the other examples in aliases.py.

@hadleyrich Are you still able to do the requested change for the manufacturer alias?
Then we can merge.

@hadleyrich Are you still able to do the requested change for the manufacturer alias? Then we can merge.

My apologies I was on Summer holiday break. Thank you for the tip I didn't see that, I will get this done soon.

My eu plugs get detected as au, I do not know if there is any internal difference, but I do not like this behaviour, I think it would be better to either make a common one or exclude other models from detection.

@cewbdex thanks for reporting. That's probably because we have added Smart_Plug_V2 as an alias, which is the same for the EU plugs. There is no way to differentiate, so I would suggest we remove the alias, so this plug can only be setup with manual flow.
Do you have any possibilities to measure your EU plug?

I don't have any certified meter, but when I try to measure the plug with another plug, I get with relay on:
[11:11:54][D][sensor:093]: 'voltage': Sending state 240.82330 V with 1 decimals of accuracy
[11:11:54][D][sensor:093]: 'current': Sending state 0.00277 A with 2 decimals of accuracy
[11:11:54][D][sensor:093]: 'power': Sending state 0.08769 W with 1 decimals of accuracy
[11:11:54][D][sensor:093]: 'energy': Sending state 478.09766 kWh with 3 decimals of accuracy

up to like
[11:13:14][D][sensor:093]: 'voltage': Sending state 240.78621 V with 1 decimals of accuracy
[11:13:14][D][sensor:093]: 'current': Sending state 0.00474 A with 2 decimals of accuracy
[11:13:14][D][sensor:093]: 'power': Sending state 0.10445 W with 1 decimals of accuracy
[11:13:14][D][sensor:093]: 'energy': Sending state 478.09766 kWh with 3 decimals of accuracy

I do not know if there is any difference or their accuracy with low values is low.


Scene import unit tests

Changes to URL handling or scene importing like https://github.com/tangrams/tangram-es/pull/1659 are currently hard to evaluate for correctness because there are many possible configurations of scene loading and importing that must be checked.
Making improvements to these parts of the engine will be easier if we add unit tests for a range of configurations. We'll want test cases covering permutations along several dimensions:

base scene type (YAML file, ZIP archive)
import type (YAML file, ZIP archive)
import URL (relative, absolute)

This exists now! https://github.com/tangrams/tangram-es/blob/master/tests/unit/sceneImportTests.cpp


Add report titles

After #450, the report lost too much context by only using the short names from the tsv files. There was no way to tell which plot was train/loss vs test/loss:

It looked fine in other DVC plots because they include the path:

This PR adds titles to help separate plots with shortened names:

I wasn't sure how adding a title property would work with Studio live metrics, but it doesn't seem to have an impact (which is fine since they already have the file paths in the title, and more importantly it doesn't break anything):

wasn't sure how adding a title property would work with Studio live metrics,

The changes in this P.R. don't affect it as you are only modifying report.py and

wasn't sure how adding a title property would work with Studio live metrics,

The changes in this P.R. don't affect it as you are only modifying report.py

I was confused because I saw you made changes to report.py in #450. Prior to that, the report would have looked like:

Anyway, the title looks like a nice improvement to the UI and more closely matches the DVC plots output, so let's go with this.

I was confused because I saw you made changes to report.py in #450. Prior to that, the report would have looked like:

Yeah sorry, those changes were not strictly related to fixing the studio updates and I thought that the titles were being inferred in dvc-render.
The changes in report.py were meant to ensure consistency in the data points with dvc plots show (https://github.com/iterative/dvclive/pull/450#discussion_r1095790377)


Diagram correction fails for certain frequencies

ωs = [1,0,0,2.0, -2.0]
    contraction_coeff(2,0,ωs) #+ contraction_coeff(0,2,ωs)
    diagrams = get_diagrams(DiagramNode((2,0)))
    ω_test= split_freqs_into_bubbles(ωs, diagrams[2])
    corr = diagram_correction(ω_test)
    corr.poly

Looking deeper into the error, there are two problems here.
First, the number of frequencies has to match the number of modes in the diagram. This is now fixed, and split_freqs_into_bubbles would return an error if they do not match.
Second, the problem seems to be when the second frequency is zero.
ωs = [1, 0]
diagrams = get_diagrams(DiagramNode((2, 0)))
ω_test = split_freqs_into_bubbles(ωs, diagrams[2])
corr = diagram_correction(ω_test)
@show corr.poly

In which case the correction is 0, and the polynomial correction coefficients are NaN.

The problem was in extend_correction, which mistakenly normalized by the first element of the polynomial rather than the first non-zero element. After correcting this, the function seems to work and produce the right corrections for the cases considered here.


internal/netutil: staticcheck

Closing this, see my comment here:

https://github.com/perkeep/perkeep/pull/1405#issuecomment-894727096


Disable player knockback on respawn

Hi, I already tried to set the player's velocity to 0, but that doesn't work. How can I do it?

Cancel EntityKnockbackEvent?

How can i check if it was the last knockback? i cant seem to get 0 health from the event
20.0
15.5
10.333333
6.833333
2.833333
3.1666665

this is the health output of killing a player

That should not usually happen, maybe send me the code on discord so I can try to help. This is not really the right place for troubleshooting

fixed on discord


WGPU error: There was no valid format for the surface at all

➜  brush git:(main) ✗ RUST_BACKTRACE=full cargo run --release
Compiling brush-desktop v0.1.0 (/mnt/data01/MachineLearning/PointCloudCompression/3dgs/brush/crates/brush-desktop)
Finished release profile [optimized] target(s) in 5.06s
Running target/release/brush_bin
[2024-11-15T02:35:20Z ERROR eframe::native::run] Exiting because of error: WGPU error: There was no valid format for the surface at all.
thread 'main' panicked at crates/brush-desktop/src/main.rs:44:10:
called Result::unwrap() on an Err value: Wgpu(NoSurfaceFormatsAvailable)
stack backtrace:
0:     0x560d4abba12a - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h304520fd6a30aa07
1:     0x560d4abe722b - core::fmt::write::hf5713710ce10ff22
2:     0x560d4abb5993 - std::io::Write::write_fmt::hda708db57927dacf
3:     0x560d4abbb632 - std::panicking::default_hook::{{closure}}::he1ad87607d0c11c5
4:     0x560d4abbb29e - std::panicking::default_hook::h81c8cd2e7c59ee33
5:     0x560d4abbbebf - std::panicking::rust_panic_with_hook::had2118629c312a4a
6:     0x560d4abbbba7 - std::panicking::begin_panic_handler::{{closure}}::h7fa5985d111bafa2
7:     0x560d4abba609 - std::sys::backtrace::__rust_end_short_backtrace::h704d151dbefa09c5
8:     0x560d4abbb834 - rust_begin_unwind
9:     0x560d497a2163 - core::panicking::panic_fmt::h3eea515d05f7a35e
10:     0x560d497a2636 - core::result::unwrap_failed::h7c8d8bbbcf45dc13
11:     0x560d497ca458 - brush_bin::main::h3c5a32ecca309821
12:     0x560d497bb863 - std::sys::backtrace::__rust_begin_short_backtrace::h6a773ef73b90bcd7
13:     0x560d497c791d - std::rt::lang_start::{{closure}}::h93dd68dd970df060
14:     0x560d4abad030 - std::rt::lang_start_internal::h4d90db0530245041
15:     0x560d497ca595 - main
16:     0x7ffa88c30083 - __libc_start_main
at /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
17:     0x560d497a2a3e - _start
18:                0x0 -

Hmm this happens when the chosen GPU can’t render UI. Do you have a dedicated and integrated GPu? Is this on Linux? Any way to force dedicated GPU?
Should add some printouts before creating the GUI of the chosen adapter.

#44 might fix this, if you have a chance to try it let me know!

Assuming this is fixed after #44


iOS 9.3.3 breaks hot reloding

Changes are no longer reflected, most buttons are now missing from dev menu.

This issue may be related to https://github.com/facebook/react-native/issues/8419

What is being assigned to jsCodeLocation in AppDelagate.m?

jsCodeLocation = [[RCTBundleURLProvider sharedSettings]<EMAIL_ADDRESS>fallbackResource:nil];

Change it to: #ifdef DEBUG     jsCodeLocation = [NSURL URLWithString:@"http://PUT_YOUR_IP_HERE.2:8081/index.ios.bundle?platform=ios&dev=true"];   #else     jsCodeLocation = [[RCTBundleURLProvider sharedSettings]<EMAIL_ADDRESS>fallbackResource:nil];   #endif
Redploy and all will be well

Unfortunately that didn't work, but I tried modifying the original line adding .bundle?platform=... and that did the trick. I noticed when it was loading it had some xib or something in the url, which probably caused the normal ip address to not work.
Regardless it works with all the extra suffixes :) Thanks.
I still think this is a bug though. React Native no longer works out of the box with an iphone that has 9.3.3 installed.


feat: Create new Fleets for all variants #1090

add arch and balena device type to hardware definitions.

** Create new Fleets for all variants #1090 **

Link: https://github.com/NebraLtd/hm-dashboard/issues/1090
Summary: adding balena device type to variant to have single source of info.

How

Screenshots

References

Checklist

[ ] Tests added
[ ] Cleaned up commit history (rebase!)
[ ] Documentation added
[ ] Thought about variable and method names

Also relates to #98

@marvinmarnold what do you think about just removing hardware that we have no current plans to manufacture?
For example tinkerboard ones etc
Unless we want to support them DIY, which we currently aren't planning either, perhaps we should remove them and can just add them back in later if anything changes

fixed review comments.

@pritamghanghas Coul you also add nebra-light3 and nebra-outdoor2 so my changes on helium-miner-software would not fail.
For nebra-outdoor2, just copy the nebra-indoor2. For the nebra-light3, you can either copy nebra-light2 and let me fix it later with another PR, or get the information from the hardware-designs repo or directly from me.

@pritamghanghas Please see https://github.com/NebraLtd/hm-pyhelper/tree/murat/add-nebra-light-2-and-3
I'm leaving merging to you. Feel free to delete it after merging it here.

@shawaj I have updated them as per discussions.

@pritamghanghas Please see https://github.com/NebraLtd/hm-pyhelper/tree/murat/add-nebra-light-2-and-3
I'm leaving merging to you. Feel free to delete it after merging it here.

I have added those. Let me know if there is any mistake.

@pritamghanghas Coul you also add nebra-light3 and nebra-outdoor2 so my changes on helium-miner-software would not fail.
For nebra-outdoor2, just copy the nebra-indoor2. For the nebra-light3, you can either copy nebra-light2 and let me fix it later with another PR, or get the information from the hardware-designs repo or directly from me.

@pritamghanghas Please see https://github.com/NebraLtd/hm-pyhelper/tree/murat/add-nebra-light-2-and-3
I'm leaving merging to you. Feel free to delete it after merging it here.

done


Update README: DataFunctionArgs is being deprecated

Hi, according to this PR from Remix, DataFunctionArgs is being deprecated, so where the README says: "Make sure your loader and action use the new declaration format:", the example should look like:
// Old ways
export const loader: LoaderFunction = async ({request}) => {}
export const action: ActionFunction = async ({request}) => {}
export const loader = async ({request}: DataFunctionArgs) => {}
export const action = async ({request}: DataFunctionArgs) => {}

// New way
export const loader = async ({request}: LoaderFunctionArgs) => {}
export const action = async ({request}: ActionFunctionArgs) => {}

Although I don't know if there's also code to be touched before editing the documentation.

Thanks for the heads up!


Android build error: 2 files found with path 'lib/arm64-v8a/libreactnative.so' from inputs:

Hey there,
I'm encounting a build error for Android. This build does pass on iOS.
What went wrong
Execution failed for task ':app:mergeDebugNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.MergeNativeLibsTask$MergeNativeLibsTaskWorkAction
   > 2 files found with path 'lib/arm64-v8a/libreactnative.so' from inputs:
-<EMAIL_ADDRESS>      - /home/expo/.gradle/caches/8.10.2/transforms/672b395bf72c7a6fb6406ced23d66ff2/transformed/react-android-0.76.5-debug/jni/arm64-v8a/libreactnative.so
     If you are using jniLibs and CMake IMPORTED targets, see
     https://developer.android.com/r/tools/jniLibs-vs-imported-targets

This, interestingly, is a VERY similar error that we saw on another library we use: RN Vision Camera
Perhaps there is some insight to be gleamed from their error and fix?
Of note, we are using Expo.
RNMIP Version
2.1.0
Dependencies
"dependencies": {
    "@baronha/react-native-multiple-image-picker": "^2.1.0",
    "@expo/react-native-action-sheet": "^3.13.0",
    "@expo/vector-icons": "^14.0.0",
    "@react-native-async-storage/async-storage": "1.23.1",
    "@react-native-community/datetimepicker": "8.2.0",
    "@react-native-community/netinfo": "11.4.1",
    "@react-native-masked-view/masked-view": "0.3.2",
    "@react-native-picker/picker": "2.9.0",
    "@react-navigation/bottom-tabs": "^6.1.0",
    "@react-navigation/native": "^6.0.7",
    "@react-navigation/native-stack": "^6.5.0",
    "@sentry/react-native": "~6.3.0",
    "@shopify/flash-list": "1.7.1",
    "@wwimmo/react-native-sketch-canvas": "^0.8.5",
    "expo": "~52.0.20",
    "expo-application": "~6.0.1",
    "expo-asset": "~11.0.1",
    "expo-av": "~15.0.1",
    "expo-blur": "~14.0.1",
    "expo-camera": "~16.0.10",
    "expo-constants": "~17.0.3",
    "expo-dev-client": "~5.0.6",
    "expo-device": "~7.0.1",
    "expo-file-system": "~18.0.6",
    "expo-font": "~13.0.1",
    "expo-haptics": "~14.0.0",
    "expo-image": "~2.0.3",
    "expo-image-picker": "~16.0.3",
    "expo-linear-gradient": "~14.0.1",
    "expo-linking": "~7.0.3",
    "expo-localization": "~16.0.0",
    "expo-media-library": "~17.0.4",
    "expo-network": "~7.0.4",
    "expo-notifications": "~0.29.11",
    "expo-secure-store": "~14.0.0",
    "expo-sharing": "~13.0.0",
    "expo-splash-screen": "~0.29.18",
    "expo-sqlite": "~15.0.3",
    "expo-status-bar": "~2.0.0",
    "expo-store-review": "~8.0.0",
    "expo-updates": "~0.26.10",
    "expo-video-thumbnails": "~9.0.2",
    "expo-web-browser": "~14.0.1",
    "i18n-js": "^4.1.1",
    "metro-react-native-babel-transformer": "^0.77.0",
    "mime": "^3.0.0",
    "moti": "^0.24.2",
    "pack-spheres": "^1.0.4",
    "package": "^1.0.1",
    "patch-package": "^8.0.0",
    "postinstall-postinstall": "^2.1.0",
    "react": "18.3.1",
    "react-dom": "18.3.1",
    "react-native": "0.76.5",
    "react-native-dialog": "^9.2.1",
    "react-native-draggable-flatlist": "^4.0.1",
    "react-native-gesture-handler": "~2.20.2",
    "react-native-keyboard-aware-scroll-view": "^0.9.5",
    "react-native-nitro-modules": "^0.18.2",
    "react-native-popup-menu": "^0.15.12",
    "react-native-purchases": "^7.1.0",
    "react-native-reanimated": "~3.16.1",
    "react-native-safe-area-context": "4.12.0",
    "react-native-screens": "~4.1.0",
    "react-native-static-safe-area-insets": "^2.2.0",
    "react-native-svg": "15.8.0",
    "react-native-swipeable-item": "^2.0.9",
    "react-native-switch": "^1.5.1",
    "react-native-vision-camera": "^4.6.1",
    "react-native-web": "~0.19.13",
    "react-native-webview": "13.12.5",
    "reflect-metadata": "^0.1.13",
    "svg-path-properties": "^1.1.0",
    "typeorm": "^0.3.7"
  },

Debug notes
Things I have tried that have not worked:

Dropping to RNMIP version 2.0.0
using Nitro 0.19.0+

Happy to provide more details if this helps.
Thanks!

Try Nitro 0.18.2

Hi @baronha!
I'm currently using "react-native-nitro-modules": "^0.18.2"

Just became a sponsor to support your work @baronha -- thanks!

Just became a sponsor to support your work @baronha -- thanks!

Thank you for your support. I will see suggestions from Vision Camera so I can fix it as soon as possible.
Thank you very much

And using:
npx expo install @baronha/react-native-multiple-image-picker
npx expo install<EMAIL_ADDRESS>-- --dev
npx expo prebuild

Thanks @baronha, android builds now -- really appreciate your work!

Thanks @baronha, android builds now -- really appreciate your work!

I will try to upgrade to Nitro 20 today. Thank you for trusting this library
https://github.com/baronha/react-native-multiple-image-picker/pull/210


FIX: Maxwell icepak example

Description
Changes to fix maxwell icepak example.
@maxcapodi78 @Samuelopez-ansys  Feel free to close this PR if you have something working. I need to drop now.

@SMoraisAnsys I think this is duplicated with PR #5595


Fix checkpoint loading behaviour

I've forced the use of base_estimator and the random_state from the saved checkpoint. This should fix the issues #949 and #997, possibly also related to #959 and #960.

Hello @ISipi! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file examples/interruptible-optimization.py:

Line 101:73: W291 trailing whitespace
Line 108:80: E501 line too long (89 > 79 characters)
Line 111:80: E501 line too long (81 > 79 characters)
Line 112:80: E501 line too long (88 > 79 characters)
Line 113:80: E501 line too long (88 > 79 characters)
Line 114:80: E501 line too long (87 > 79 characters)
Line 115:41: W291 trailing whitespace


feat(speech): generate speech v2

Fixes #10168
Note that moving speech v1 is not a prerequisite for making this change. The types will not conflict, and we know where we want to put speech v2.
I tried to come up with a general glob solution. It deserves scrutiny.

This change is

I see no changes the main.dox which would include the samples for this new client. I think you will need to make some changes to the ci/generate-markdown scripts and maybe add new placeholders in main.dox.

Fixed by #10241 + regeneration


Online Meeting

Hi @frheault,
As you know, every other week, we have a DIPY online meeting.
I propose you to lead the next one to talk about the tractography file format.
The next one is December 2nd, noon EST / 6pm CET.
Let me know what you think and if you are interested then I will update the calendar and start to promote this online discussion to have as many diffusion actors as we can.

Hello, I would be happy to present the current 'results' of my attempt at creating a file format that please everyone and lead a discussion on what I would need to improve.
However it is important to mention that at the moment I am not sure if there is strong opinion for or against anything I have done.
So it would be important to clearly state that this is ongoing work that we want to fast-track and not that I want to impose this 'draft version' or even myself.
But yeah, I would be happy to initiate the discussion about 'how to go forward' from this initial attempt.

ok, great and I completely agree. Can you give me a simple title? I think you will have the right word for that.
Something like: "Summary of Tractography file format discussion and future direction proposition". Does not sound good but you get the idea. When you have a title, We will start to tweet, send to mailing list, etc... more people to discuss, better

What about ''TRX, a community file format: Where do you come and where do you go?''

@skoudoro so is it the date decided? Should I start planing it on my end?

Yes, Let me update DIPY online meeting: December 2nd, noon EST / 6pm CET

Are you ok if we communicate it on Neurostart and nueroimaging mailing list?
I let you add it on the Nibabel issue

I will try to frame the meeting so it doesn't turn into an incoherent free for all of suggestions, demands and weird questions but yeah you can invite people using the normal ways.
But I will orient the meeting toward power users and developers only. Just so it stay on topic.

ok, make sense. Sounds like a plan! I will start to promote to devs


Ultimatum on Nancy Experimentation

The lack of cooperation of the different actors in the centralized experimentation in Nancy is blocking the experimentation.
Then we decide to deprioritize it if nothing is achieved for january 1st.
Dod:

the beta tester community in Nancy is aware of this limit.

Hey team! Please add your planning poker estimate with Zenhub @ad2ien @JDixmier


Allow default tags to be set using a variable

In our organisation, we require a set of tags to be set on all resources. It currently isn't possible to do that on AFT created resources, and this PR allows that.
#466 (which superseeds #23) suggests merging customer defined tags with the default managed_by tag currently set on all providers. This is less than ideal for our use case, as we don't want to have that tag. We actually require a MANAGED_BY tag (all-caps).
Ideally we would be able to define the providers ourselves, but that would be a breaking change. If you are interested, I would be happy to implement that. This would allow us to have different sets of tags on each provider, which we would like, in order to have a different ACCOUNT_ID tag

I have performed a plan of this change against our deployed infrastructure, and the changes are as I expect.


TypeScript error "Cannot assign an abstract constructor type to a non-abstract constructor type" when using abstract model class

I having so much troubles to make things work in objection + typescript, and that's the one where I have no idea how to solve it by myself...
In my project i have a models hierarchy, including abstract models classes. For example, this:
class NamedQueryBuilder<
	M extends Base, R = M[]
> extends QueryBuilder<M, R> {
	searchByName(name: string): this { /* Some query building logic */ }
}

abstract class Named extends Model {
	QueryBuilderType!: NamedQueryBuilder<this, this[]>;
	declare name: string;
}

So i tried to use this abstract class as an argument type of a function:
function search(Model: typeof Named) {
	return Model.query()
		.searchByName(name)
		/* ... */
}

But getting following error:
error TS2684: The 'this' context of type 'typeof Named' is not assignable to method's 'this' of type 'Constructor<Named>'.
  Cannot assign an abstract constructor type to a non-abstract constructor type.

I think this is because of constructions like this i have seen in objection's typings:
export interface Constructor<T> {
  new (): T;
}
/* ... */
static query<M extends Model>(
  this: Constructor<M>,
  trxOrKnex?: TransactionOrKnex
): QueryBuilderType<M>;

I know that typescript thinks something like Abstract classes cannot be invoked with "new", so "this" not implements "Constructor" here. Seems logically. But it means that I can't use abstract model class as a type!
Is there any way to get around it and make it possible to use abstract models as a types somehow?

 Just a newbie in typescript. I found solution.
The problem is not with objection, but with typescript. I'm getting error because usage of static fields and methods on abstract classes is allowed in typescript. So function search from example can get abstract class Named directly and boom! Attempt to create instance of an abstract class is here.
Solution is simple: use a constructor type with an abstract class to let typescript know that we are accepting only something that we can instantiate, i.e. non-abstract. Like these:
function search(Model: typeof Named & (new () => Named)) {}


[Feature] Need automatic parser from protobuf file

Need parse from proto-file logic

fixed in #17


Stabilize unreachable.

Tracking issue: https://github.com/rust-lang/rust/issues/61119

The wasm job is failing, but that appears unrelated.


add --cleanup-aws option to remove ANY AWS allocated resource

in particular:

cloudwatch logs
SQS queues

Aggreed 👍

@cwaltken-edrans Are you already working on a fix? I would like to start contributing to the project and this issue seems interesting.

No, I'm not working on this one right now. Feel free to send a PR.
I'm pretty sure we can get it merged.
On Thu, Oct 5, 2017 at 9:48 PM, Nope<EMAIL_ADDRESS>wrote:

@cwaltken-edrans https://github.com/cwaltken-edrans Are you already
working on a fix? I would like to start contributing to the project and
this issue seems interesting.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/goadapp/goad/issues/157#issuecomment-334630534, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AaaDsUIaJP-13Xlq5S83antCsz3SeXzsks5spXjjgaJpZM4OrB0D
.

Thank you. Could you please give me some pointers, since I am new to the project? What other resources should the "--cleanup-aws" option delete?

Please take a look at: https://github.com/cwaltken-edrans/goad/blob/master/infrastructure/aws/aws.go
The code in this file is solely responsible for creating aws resources.
Resources to delete if present that come right to my mind would be:

SQS-Queue
Role for lambda function
Lambda aliases
Lambda functions
CloudWatch logs associated to the lambda function

Ideally the cleanup code would also apply to the Docker infrastructure though to run goad on docker is still considered to be an experimental feature.
You could take a look at the cleanup code for each infrastructure and improve on that and reuse the code.


Auto Update All (From Publisher) grayed out and has check mark

Testing #223091
Auto Update All (From Publisher) is grayed out and has a check mark although the extension has Auto Update disabled:

Later:

I think the check mark for Auto Update All (From Publisher) should only be shown when indeed all extensions of that publisher have auto update enabled. Not sure what the current logic is.

I think the check should indicate "all" have it enabled. The missing check should indicate "not all" (but not necessarily none) have it enabled.
Enablement (grayed out) of the menu item changes in a way I don't understand. :)

I will go through all scenarios and improve the experience for this action.


Change Edge style rounded to support sharp, rounded, and orthogonal_loop

Currently I have the EdgeStyle parameters only supporting rounded = 0 or 1. This is actually a miss as in Draw.io you have a three menu dropdown for Sharp (no rounded style at all), Rounded (rounded=1), or Curved (rounded=0,orthogonalLoop=1).

Misunderstood: Draw.io has a dropdown with sharp, rounded, and curved. But curved can also be set in the waypoints field so Drawpyo gets curved by setting waypoints to curved. This feels more intuitive.


How to send unique incident_key to PagerDuty for each alert rule

Missing some documentation
How to send unique incident_key to PagerDuty for each alert?

This is done automatically for you, there's no configuration required.
We use a unique hash per alert group.

Is every alert rule in prometheus automatically a group in alert manager?
ALERT service_down
IF consul_health_service_status == 0
FOR 6m
LABELS {severity="critical"}
ANNOTATIONS {description="{{$labels.node}} of job {{$labels.job}} has been down for more than 6 minutes.", summary="Service {{$labels.node}} down"}
I have multiple services in consul, when there are multiple services down in consul, alert manager is sending the same incident key to PagerDuty. Is there a solution for this scenario?

The group_by Alertmanager configuration allows you to group by labels other than the alertname.

group_by label fixed it for me, thanks!!

@brian-brazil Hi Brian, is there a way to exclude incident_key from the payload completely? I have one integration where I want to send repeat alerts even when the payload is exactly same, but the integration deduplicates events by default if the incident_key is same. If there is a way to exclude incident_key for certain alerts, this will solve a problem for us without requesting any changes to the integration.


thread '' panicked at 'assertion failed: (left == right)

When running tests with Vitest, I have the following error:
[...snip...]
 ❯ src/authorization/authorization.endpoints.integration-test.ts (3)
   ❯ Authorization API endpoints (3)
     ⠸ [ beforeAll ]
     · GET /v1/authorization/training (3)
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: failed to delete napi ref', query-engine/query-engine-node-api/src/engine.rs:131:1
stack backtrace:
   0:        0x11cf0eea8 - _napi_register_module_v1
   1:        0x11c8dab4c - <unknown>
   2:        0x11ceed3c8 - _napi_register_module_v1
   3:        0x11cf122f4 - _napi_register_module_v1
   4:        0x11cf11f54 - _napi_register_module_v1
   5:        0x11cf12e2c - _napi_register_module_v1
   6:        0x11cf129b8 - _napi_register_module_v1
   7:        0x11cf12928 - _napi_register_module_v1
   8:        0x11cf12904 - _napi_register_module_v1
   9:        0x11d192618 - _napi_register_module_v1
  10:        0x11d1927fc - _napi_register_module_v1
  11:        0x11d199f20 - _napi_register_module_v1
  12:        0x11c844450 - <unknown>
fatal runtime error: failed to initiate panic, error 5
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Can you help us with some more inforamtion how we could reproduce this?
Does this happen all the times or just sometimes?
What database are you using? What version of Prisma?

I'm having the same problem. I'm running prima and @prisma/client 4.11.0 (which is the latest at the time of this post).
This is on a MySQL 5.7 database.
It happens from a single query like
prisma.user.count({ where : { id : 'xxx'}})

I'm seeing the same issue causing intermittent test failures during deployment.
There I'm running against pg14.

Mine turned out to be that I was missing an await somewhere

@rizen how did you track that down?
I've just reverted our tests back to jest because our CI builds were failing almost every time without multiple manual retries of the test run.

Unfortunately it was painful to find it. I created a copy of my app, and kept ripping out parts until I had the smallest part possible and the error was still happening. Even when I got down to less than 50 lines of code, it was still not easily apparent to me. I even showed several other devs and nobody saw it.
I even tried rewriting the app to not use inheritance, as I was thinking maybe mixins were the problem.
I eventually created a repo to submit a bug report to prisma and still didn't see it at that point. But then after sleeping on it for a weekend, I took another look and sure enough I forgot an await on a super() call. You can see it on line 24 here: https://github.com/rizen/prisma-inheritance-seg-fault/blob/main/inheritance.test.ts

What version of Prisma were you on? Could you retry with the latest Prisma? The error looks similar to an issue that should be fixed as of Prisma 4.13.0 and later.

@rizen the problem in your repro looks a bit different than the error you were initially getting, and a segfault happening because of a missing await on your side is still a bug on our side that must be fixed. I can reproduce this with the latest Prisma and your repo. I'll open a separate issue for that.

Hi there,
As part of our effort to clean up our GitHub repo, we’re closing this issue to help focus on features and improvements that align with our focus areas and those of our community. We recommend using this workaround by our colleague @aqrln.

If this is issue is still important to you, feel free to reopen the issue and get like-minded users to upvote as we will prioritize fixing issues based on community interest. If you do reopen the issue, please ensure that there’s a clear method for us to reproduce it.
For more insight into our priorities and how we’re thinking about the future of the Prisma ORM, please see our recent blog post: https://www.prisma.io/blog/prisma-orm-manifesto.
Thank you for your understanding and support!

fwiw vitest now uses child processes rather than worker threads by default so this issue is unlikely to affect many people even if the bug still exists (not to mention that it might already be fixed even for worker threads given that napi-rs has been updated multiple times)


[FR] Integrate nDPI with IPFW (probably as a plugin)?

Hi,
I stumbled upon this one ...
https://github.com/ntop/nDPI/issues/300
... where a BSD user was able to filter with nDPI applications like facebook.
After a quick research there was a similiar issue open: #1397
I'm not really a BSD pro, nor really into OPN where it does PF or IPFW, or mix it up, but I could imagine to to build something which works besides the basic firewall rules. And if it's implemented as a plugin there should not be much impact with main development, perhaps we could build a base for further development?
I saw a npdi package in the ports on github, but nothing related to ipfw-classifyd. Is this outdated or a replacement for it around?
What do you think?

Sadly, this is not about ipfw, it is about ipfw-classifyd, a very ancient application filtering daemon with poor performance and no maintenance for years. It was removed from OPNsense in 2015, removed from pfSense in 2016.

So there's no hook around for integrating it to ipfw?

there is, it can be done like relayd or squid, but essentially you need to write a daemon with ndpi, add rules configuration, etc. And then the tricky part is to be able to do something useful with the application classification, namely blocking and shaping.

Seems there's a guy around with a similar idea:
https://redmine.openinfosecfoundation.org/issues/511
I'll close this one for now but keep tracking :)
Thanks!

Suricata is nice, but it can't shape. Ideally, writing this isn't the issue. But nobody is doing it OpenSource because everybody wants to make money off of it.
See Slide 4 of this grumpy guy from 2014 http://operatingsystems.io/slides/userland_networking.pdf

@fichtner Snort with OpenAppID? I know, also not working with the shaper, but a good choice for blocking access to specific sites or micro apps.
I read the #1649 but are you all against snort?

With snort on FreeBSD we have the problem of not having a real inline mode, only lazy IP blocking destinations. AppID in Snort has the same problem, shaping is not applicable here. :/

https://github.com/pmacct/pmacct/blob/master/QUICKSTART#L776
It's only classification, but a quite good start to visualize.
Do you streamline this version to the ports or will we have to wait for FreeBSD?
P.S. very low prio :)


manually registered subscribers not called from transactional

Describe the bug
When i register the subscriber manually using em.getEventManager().registerSubscriber(this) the event handlers are not called when events are happening in a transactional callback.
To Reproduce
Steps to reproduce the behavior:

Make the following NestJS service:

import type { EventSubscriber } from '@mikro-orm/core';
import { EntityManager } from '@mikro-orm/postgresql';
import { Injectable } from '@nestjs/common';
import User from '../entities/User';

@Injectable()
export default class MyService implements EventSubscriber<User> {
    public constructor(private em: EntityManager) {
        em.getEventManager().registerSubscriber(this);
        console.log('subscribed');
        this.test();
    }

    public onFlush() {
        console.log('onFlush');
    }

    public async test() {
        await this.em.transactional(async (em) => {
            const user = this.em.getRepository(User).create({});
            em.persist(user);
        });
    }
}

Instantiate the service (either manually or by NestJS)
"subscribed" is logged, but "onFlush" is not.

Expected behavior
Event handlers should be called and onFlush
Additional context
I figured out that in EntityManager.ts, there is this code:
   // in transactional:
    const fork = em.fork({
      clear: false, // state will be merged once resolves
      flushMode: options.flushMode,
      freshEventManager: true,
    });

    //in fork:
    const eventManager = options.freshEventManager ? new EventManager(em.config.get('subscribers')) : em.eventManager;

which means that the fresh event manager uses subscribers from config, but ignores subscribers registered via registerSubscriber()
Versions

Dependency
Version

node
16.13.2

typescript
4.6.2

mikro-orm
5.4.2

your-driver
postgresql

For the record: it was fixed in commit: https://github.com/mikro-orm/mikro-orm/commit/0e523b3fa59a7e26faad9393465c6b2b609f9643
And will be released in v5.6.1


rand/randfile.c: permit non-regular files in RAND_load_file.

Apparently applications rely on RAND_load_file's ability to work with
non-regular files, customarily with /dev/urandom, so that the ban was
not exactly appropriate.

[x] documentation is added or updated
[ ] tests are added or updated

Three competing pull requests. How exciting! :-)

With @levitte 's documentation change included please.

Commentary updated. Since it wasn't a code change I reckon that approvals stand unless somebody else claims otherwise.


[mac] "bad seed size" if trying to add an existing account using account number

Bug Description
"bad seed size" if trying to add an existing account using account number
Steps to Reproduce
Steps to reproduce the behavior:

Install the TNB v30
Launch the app
Click on "My Accounts" (+ sign) on the left side menu
Select "Add Existing Account"
Enter any account number
Click "Add" button

Expected behavior
Seems we should provide a clear error under the "Signing Key" field about invalid signing key.
Actual behavior
"bad seed size" if trying to add an existing account using account number
Screenshots/Recordings
https://prnt.sc/voaayp
OS and Browser

OS: [Mac]
Browser [Chrome]

Account Number
a9a4823b71318bf481cf58f97fd3e8090c7221a84ae8ad25d8deff8922acfa8a

@dstekanov can you see if this issue persists with the latest changes? I tried replicating this using the account number you provided, but I did not encounter any issues

@dstekanov can you see if this issue persists with the latest changes? I tried replicating this using the account number you provided, but I did not encounter any issues

closing issue for now

closing issue for now

Hi @angle943, I tried it with v(1.0.0-alpha.39) and cannot reproduce it anymore.

Hi @angle943, I tried it with v(1.0.0-alpha.39) and cannot reproduce it anymore.


[new page] document size on disk guidelines

Originally: https://github.com/influxdb/influxdb.com/issues/205
Will need to get numbers from perf testing, but for now just summarize https://github.com/influxdb/influxdb/issues/3554 and talk a bit about https://github.com/influxdb/influxdb/pull/3544

Fixed by https://github.com/influxdata/docs.influxdata.com/pull/92


Callable Timestep

This changes the API for producing time steps. get_step(timestep) is replaced by timestep() and get_step(sim) by timestep(sim). This allows to get rid of the awkward _oed and _oed! helper functions.
Closes #56

Merge only after merging #65!


Improve Logic Design of signIn method and allow explicit options

Feature request
It should be possible to disable automatic magic links.
Actually I think the signIn method has a bad architectural design, prove me wrong.
Logic should be split by concerns, but the signIn allows magic link, phone login, password login etc. all by "guessing". This is meant to lead to failure. Instead I'd either expect different methods such as signInByPhone etc. or at least a config flag enforcing the requirements.
Currently what happens is that when I do signIn({email}) it will trigger sending a magic link - even if I want it to be login per password.
Problem description below 👇
Problem Description
Now you guys probably thought of "This is a cool feature and is pretty convenient". In most cases it is. But Architecture Design is all about requirements both technically as well as considering your Personas etc.
Now let me sketch a use-case (I have MANY more if needed):
Use-case 1:
I have a target group that doesn't have immediate access to their E-Mail so-to-speak hence the Magic Link is becoming inconvenient due to the amount of actions needed.
You would probably argue: Then don't use it and use signIn({email, password}) . Well, fair point, however no code is perfect and good Architecture lives by "Design for Failure" so I'm having somewhere a code fail where instead of {email: 'mail...', password: 'pass...'} only the email prop is provided but the password prop is missing/undefined. Rest assured this can happen on library level. Now what? The magic link is sent, the function acts "succesfully" and the code is confused expecting a valid session and so is the user. Especially more confusing since that user isn't expecting a magic link.

So kinda I criticize what's been improved already. So I guess we can close this. Probably didn't notice it because it's not yet deployed in my latest package as it's still RC

But one question remains open: Wouldn't that still leave the problem open of still technically being able to do OTP? I'd like to be able to disable those (but I guess then this would be a supabase ticket, not a gotrue one?)

https://supabase.com/docs/reference/javascript/next/auth-signinwithotp
I think this should be extended to fit your needs:
signInWithOtp({..., shouldCreateUser: true, onCreateUserData: {your_meta_data}})

Hey @activenode, this is now possible in the rc branch for signInWithOtp. Please take a look at https://github.com/supabase/gotrue-js/blob/rc/src/lib/types.ts#L313-L320 - we'll file a separate PR to update the docs on the site to reflect this change.

Not sure if this is the best place to comment, but are there plans to extend this functionality out to SignInWithOAuthCredentials / signInWithOAuth? I'd like to be able to offer users the ability to OAuth once they've been invited to the App but without allowing them to create an account automatically. I believe this used to be supported under v1.0.


Delete promotion

As a admin
I need to delete specific promotion
So that we can get rid of promotion that is invalid (entered by mistake)
Details and Assumptions

promotion is inserted by mistake
promotion is not just outdated (status will change in this case)

Acceptance Criteria
promotion is deleted from the database
Given a promotion that is invalid
When delete that promotion
Then the promotion is deleted from the database

Note, a promotion that expires will have status changed rather than being deleted