issue resolved ...Improved color contrast in night mode for better readability

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #1680
Description
[Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.]

Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes. Make sure to attach before & after screenshots in your PR.]
Checklist:

[x] I have made this change from my own.
[x] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

@PriyaGhosal pls check it ...i resolved the conflict of the issue #1680 ...if any changes required kindly suggest ...possibly kindly merge it  ...under labels

@PriyaGhosal kindly check it ..solved conflict

Sorry, This issue has already been addressed  Find another issue or feature to contribute to. Thank you!


[HIPIFY][feature] Support for fp8 data types

Problem Description
Such as when I hipify a cu file  having fp8 datatype in it, after the hipify-clang command, the fp8 datatype doesn't turned into HIP fp8 type.
For example:
__nv_fp8_e4m3

doesn't change and the hipify-clang will report error:
 error: unknown type name '__nv_fp8_e4m3'

Why? Doesn't hipify support FP8?
Operating System
Ubuntu 20.04.6 LTS (Focal Fossa)
CPU
AMD EPYC 7643 48-Core Processor
ROCm Version
ROCm 6.0.0
ROCm Component
HIPIFY
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response

Hello @foreverlms,
Currently, HIP supports some of the fp8 data types and APIs. Whereas, HIPIFY tools don't. Thank you for pointing it out.
Marking the ticket as a feature to Implement.

Thanks for replying. Hope to see the fp8 support available.

Finally implemented.

Thanks for replying. Hope to see the fp8 support available.

Hi @foreverlms,
It is available now. Going to revise fp16 soon.

Thanks for replying. Hope to see the fp8 support available.

Hi @foreverlms,
It is available now. Going to revise fp16 soon.

Thanks, this could be very helpful for mix300 series.


Bring back react-a11y

https://github.com/rackt/react-a11y found new maintainers and is updated to support React 0.13+.

Will be released soon.


Task :dependencyUpdates FAILED with Gradle 7.0

Checklist

[x] I tried to reproduce the bug in my fork of the Kotlin Libraries Playground, or in one of the samples in this repository
[x] I have run with $ ./gradlew --scan refreshVersions to provide a Build Scan URL

Describe the bug
Some problems were found with the configuration of task ':dependencyUpdates' (type 'DependencyUpdatesTask').
  - Type 'DependencyUpdatesTask' property 'checkForGradleUpdate' has redundant getters: 'getCheckForGradleUpdate()' and 'isCheckForGradleUpdate()'.

    Reason: Boolean property 'checkForGradleUpdate' has both an `is` and a `get` getter.

    Possible solutions:
      1. Remove one of the getters.
      2. Annotate one of the getters with @Internal.

    Please refer to https://docs.gradle.org/7.0/userguide/validation_problems.html#redundant_getters for more details about this problem.
  - Type 'DependencyUpdatesTask' property 'outputFormatter' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.0/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - Type 'DependencyUpdatesTask' property 'resolutionStrategy' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.0/userguide/validation_problems.html#missing_annotation for more details about this problem.

To Reproduce
Build scan URL: https://scans.gradle.com/s/n5hbowfp33fsw
Update to gradle 7.0 and run ./gradlew buildSrcVersions
Note: it works with your playground project. My setup is different, I use Version.kt instead of versions.properties, I prefer.
Expected behavior
Not throwing
Additional context
With gradle 6.8.3 it works.

Hello, the checkboxes were lying, because you haven't run the refreshVersions, you've run the buildSrcVersions task.
I've seen in the Gradle scan that you're using buildSrcVersions, which hasn't been updated in a while.
That said, we plan to have it come back as buildSrcLibs, next to refreshVersions soon that will bring the features of buildSrcVersions into refreshVersions.
We'll see how to help adapt to any changes that might be needed for the migration of users of buildSrcVersions.

Hello,

Hello, the checkboxes were lying, because you haven't run the refreshVersions, you've run the buildSrcVersions task.

That's not true and you can see it by the name of the generated report (in red, "refreshVersions
14 de abr de 2021 14:54:01 WEST"). Also. here's the same output as proof (which is the same as buildSrcVersions, that's probably why you were led to think that I've used buildSrcVersions):
$  ./gradlew --scan refreshVersions
Configuration on demand is an incubating feature.

> Configure project :app
WARNING: The option setting 'android.enableResourceOptimizations=true' is experimental.
The current default is 'false'.

> Configure project :module-common
Cannot apply AAPT2 OPTIMIZE without resource shrinker being enabled.

> Configure project :module-core
Cannot apply AAPT2 OPTIMIZE without resource shrinker being enabled.

> Configure project :module-network
Cannot apply AAPT2 OPTIMIZE without resource shrinker being enabled.
Cannot apply AAPT2 OPTIMIZE without resource shrinker being enabled.
Cannot apply AAPT2 OPTIMIZE without resource shrinker being enabled.

> Task :dependencyUpdates FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Some problems were found with the configuration of task ':dependencyUpdates' (type 'DependencyUpdatesTask').
  - Type 'DependencyUpdatesTask' property 'checkForGradleUpdate' has redundant getters: 'getCheckForGradleUpdate()' and 'isCheckForGradleUpdate()'.

    Reason: Boolean property 'checkForGradleUpdate' has both an `is` and a `get` getter.

    Possible solutions:
      1. Remove one of the getters.
      2. Annotate one of the getters with @Internal.

    Please refer to https://docs.gradle.org/7.0/userguide/validation_problems.html#redundant_getters for more details about this problem.
  - Type 'DependencyUpdatesTask' property 'outputFormatter' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.0/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - Type 'DependencyUpdatesTask' property 'resolutionStrategy' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.0/userguide/validation_problems.html#missing_annotation for more details about this problem.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/7.0/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 24s
1 actionable task: 1 executed

Publishing a build scan to scans.gradle.com requires accepting the Gradle Terms of Service defined at https://gradle.com/terms-of-service. Do you accept these terms? [yes, no] yes

Gradle Terms of Service accepted.
...

I've seen in the Gradle scan that you're using buildSrcVersions, which hasn't been updated in a while.
That said, we plan to have it come back as buildSrcLibs, next to refreshVersions soon that will bring the features of buildSrcVersions into refreshVersions.
We'll see how to help adapt to any changes that might be needed for the migration of users of buildSrcVersions.

Ok thanks 👍

@jmfayard Maybe we can provide an update as well instead of just close the issue?
The current version of refreshVersions has the ability to get buildSrcVersions-like behavior through enabling of "buildSrcLibs".
You can use the search feature on the website to locate the corresponding section in the docs.

Thanks @LouisCAD , for reference: link


chore: remove hardcoded namespace from manifests

As mentioned by @alexmt in discussion of ArgoCD PR #8148 - bundling ApplicationSet with ArgoCD, removing default argocd namespace for ApplicationSet resources.
@jgwest PTAL.

FYI. I think  https://github.com/argoproj/applicationset/pull/433 and https://github.com/argoproj/applicationset/pull/403 can be closed once this PR is merged.


How to change HttpClient to OkHttp in Zuul, and use OkHttp async?

Spring Cloud version: Edgware.SR6
I tried to override OkHttpLoadBalancingClient.java
` @Override
public OkHttpRibbonResponse execute(OkHttpRibbonRequest ribbonRequest,
final IClientConfig configOverride) throws Exception {
boolean secure = isSecure(configOverride);
if (secure) {
final URI secureUri = UriComponentsBuilder.fromUri(ribbonRequest.getUri())
.scheme("https").build().toUri();
ribbonRequest = ribbonRequest.withNewUri(secureUri);
}
    OkHttpClient httpClient = getOkHttpClient(configOverride, secure);
    final Request request = ribbonRequest.toRequest();
    final Response[] responses = {null};

    Call call =  httpClient.newCall(request);
    call.enqueue(new Callback() {
        @Override
        public void onFailure(Call call, IOException e) {
        }

        @Override
        public void onResponse(Call call, Response response) throws IOException {
            responses[0] = response;
        }
    });

    return new OkHttpRibbonResponse(responses[0], ribbonRequest.getUri());
}`

So, How does it work?

Please learn how to format code on GitHub.
https://cloud.spring.io/spring-cloud-static/Greenwich.SR1/single/spring-cloud.html#_zuul_http_client

I find key words form the doc you provide：
 If you would like to customize the Apache HTTP client or the OK HTTP client, provide a bean of type ClosableHttpClient or OkHttpClient
but, how can I define a new OkHttpClient and add it to Spring life cycle?

Create a bean that returns the type OKHttpClient.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


Release artifacts for release v0.0.12

Description of changes:

Release artifacts for release v0.0.12
Increase wait time after creating CAs in e2e tests

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

/lgtm


WIP: docs(toh-6-aot): add aot to toh-6

WIP. Do not merge

This is still pending https://github.com/angular/in-memory-web-api/pull/36, but here is my first stab at supporting both AoT and JiT in the same code base. We can improve on this, but this is at least a starting point.
AoT
I have added a new project with no source code under toh-6-aot. I went in this direction to allow both compilation modes to be active at the same time (with unit tests).
There is no source code in the new project, but there is a new index.html file pointing to the generated bundle. The bundle is generated from the source in the original toh-6 folder. Trigger a build by running build:toh-aot from the toh-6-aot/ts
JiT
The JiT code still lives in its original location, but I have added two sets of main.ts and tsconfigs over there. Trigger a JiT build from toh-6/ts by running build:toh-jit.
@wardbell @johnpapa @brandonroberts @Foxandxss @filipesilva

I made a few tweaks based on discussions with @wardbell
Instead of adding a new tsconfig.json I have made a few tweaks to the shared config
This also includes an upgrade of in-mem-web-api
The remaining part for this cookbook is to add a section to the prose.

@thelgevold I've reviewed your files and have a few questions:

you mentioned that after talking with Ward, you had opted to tweaking the shared tsconfg instead of adding a new one. In this PR I still see 3 tsconfig total, can you elaborate?
can this approach handle lazy loaded modules?

I'm also thinking of generalizing this approach to run AoT over all of our examples in a separate e2e CI instance.

@filipesilva The third tsconfig is obsolete now, so I have deleted it.
Currently this does not address lazy loading of modules. I was thinking we could address that in a subsequent revision.

Addressing lazy loading separately is fine by me, just wanted to confirm.

@wardbell I have updated the prose and removed the WIP part of the title.
This PR is ready for review.

I am rebasing and reviewing and will force push so beware

I reviewed it and cleaned up some prose. There are outstanding issues:

[ ] Doesn't compile anymore since the Protractor PR changed our setup. Mostly duplicate typing errors
[ ] No obvious way for readers to get the samples.
[ ]  I don't think Rollup works in Windows when its configuration file is named rollup.js; as I recall it should be named something else like rollup.config.js.

@thelgevold there were a few setup changes in https://github.com/angular/angular.io/pull/2233, which went in yesterday.
When rebasing pay special attention to public/docs/_examples/_boilerplate/tsconfig.json, which is the new master tsconfig for example. It contains the "types": [] property that forces tsc/ngc to ignore any @types present in node_modules.
Since you create new tsconfigs for your examples, you must add this property, otherwise you will get a lot of duplicate identifier errors.

The only item I am not clear on is the No obvious way for readers to get the samples part.
Have to think about improvements here.

I have fixed the typings issue and renamed the rollup.js file to rollup-config.js

should it be rollup.config.js. or rollup-config.js ? which works in @wardbell 's case?

I think either will work. My impression is that on windows it can't be named the same as the binary (rollup)

I switched to using the AppRouterModule and there were no issues with AoT

We should make sure the cookbook prose and code samples are updated too.

I've extended the gulpfile's e2e facility so it can run the same e2e.specs against the AoT build of an app when ~/aot/index.html is defined.
It's primitive and rigid but it works as seen in the toh-6 in his  PR. That means no need for a separate aot project folder (toh-6-aot is gone).
The "trick" is that the AoT version of the index.html is in the /aot folder and to run it you serve from within /aot!
Still don't have a good way to demonstrate this to our readers. The instructions in the prose describe what to do if you've cloned the repo.


Refine https://github.com/NASA-IMPACT/veda-jupyterhub/issues/56

This has been refined into two epics

https://github.com/2i2c-org/infrastructure/issues/5002
https://github.com/2i2c-org/infrastructure/issues/5004


Multiple wallet accounts

Adds infinite wallet account creation, an account info view and ability to rename accounts.
Relies on: https://github.com/kyokan/bob-extension/pull/17

This PR has a lot of code style changes (lint/prettier).
If there's an agreement on a new style to use, it would be better to have a PR just to apply the new style. Otherwise, it's hard to review the real changes in this PR.

Agreed.. Most of the lint styling is inherited from the cold storage PR. Already discussed with Jacky as an oops. Too much to go back and sift out. The new prettier rules are included in the PR.

Closing as this was included in a separate branch.


FIX (partial) for #3181 where non-submit buttons are being activated on "enter" key press.

This issue (and fix for  #3181) relates to CMS issue at https://github.com/silverstripe/silverstripe-cms/issues/1288 and associated pull request: https://github.com/silverstripe/silverstripe-cms/pull/1290
PLEASE NOTE: This is a combined fix across both repositories and ensures that all non-submit buttons are defined explicitly as type button to ensure browsers will not automatically register the first occurrence after someone presses the enter key.

CMS:

Issue: https://github.com/silverstripe/silverstripe-cms/issues/1288
PR: https://github.com/silverstripe/silverstripe-cms/pull/1290

Framework:

Issue: https://github.com/silverstripe/silverstripe-framework/issues/3181
PR: https://github.com/silverstripe/silverstripe-framework/pull/4651 (you are here)

This is a good fix, but we would prefer to merge this into the 3 rather than 3.1 branch. 3.1 branch should not be receiving anything other than fixes to critical issues. Any non-critical (e.g. quality of life improvements) should be either 3.2 or 3 branches. Similarly to 3.1, 3.2 is nearing stable release, and we don't want to introduce any bugfixes there that aren't strictly necessary.

Sure.

Ok -- new PR here: https://github.com/silverstripe/silverstripe-framework/pull/4662
Trying to keep organized in this tangled mess of PR's :) Links and etc are updated.


Allow switching between different song scenes

This should be configurable, e.g. a fixed cycle of X seconds.
On section change base? -> Would need a fallback solution for lazy charters

I hope I get what you wanna have with this ticket! :)
To switch between whitelisted scenes in OBS, I am using the Advanced Scene Switcher plugin:

With this macros, I can control, how and how fast the Whitelist scenes should be switched. And on is not in the list. This is my guitar cam scene for solos. What could be triggered by channel points or with my foot switch. And also now the Scene switcher switching to this cam in case enterSolo happens, and switch back to the first song scene if leaveSolo.

This is what you want? Because I think, the plugin is better! Because it is really separated from SB and for example, I am switching randomly between 0.3 and 10 seconds. It is way more faster and stable than with SB I think.
Or you mean something else?
--> "Would need a fallback solution for lazy charters". Cam1 if enterChorus? Cam2 if enterRiff? Or maybe this?

The advanced scene switcher is probably more versatile, but this feature was requested as part of the plugin, so let's integrate it.
It's already assigned to me, so no worries. I'll implement a basic functionality for switching, but you can leave it off and use other means if prefered.

There is some problem with this. The conversion into int will drop an Exception if the value could not found in config of the Mock or in SB.

The commits you've added are merged to develop already


Update Samsung's user.md to add android 13 info

https://github.com/urbandroid-team/dont-kill-my-app/issues/689

Big thanks for contributing this!


[NONT]: Delete expanded name and update root node title

The expanded name has become obsolete for object type NONT is therefore deleted from the AFF interface.
The title for the field root_node_flag is changed from "Root Node Flag" to "Root Node" in response to feedback from a UX review.

This second improvement is visible in the form-based editor for object type NONT in ABAP Development Tools.
Renaming also the field root_node_flag in the NONT AFF-interface is planned, but will probably be realized in the second AFF version accompanied by appropriate compatibility handling.

This second improvement is visible in the form-based editor for object type NONT in ABAP Development Tools.
Renaming also the field root_node_flag in the NONT AFF-interface is planned, but will probably be realized in the second AFF version accompanied by appropriate compatibility handling.

I think we can still change this object type incompatible as it is not used in repositories (such as abapGit), yet.

I talked to @Ehret-Thomas . He will open a new pull request as soon as he decided to rename the field root_node_flag in the NONT AFF-interface.
I will merge this pull request


DEV: do.py build. On setup checks if intro-buildoptions.json exists instead of build dir.

In case there was a failure on previous setup execution,
there will be a build dir but no buildoptions file.
By checking the file instead of the dir, it ensures the meson setup command will be executed when required.

In case there was a failure on previous setup execution,
there will be a build dir but no buildoptions file.

FWIW, internally Meson itself uses the file meson-private/coredata.dat, see e.g. mesonbuild.msetup -> validate_dirs() and the code comments before env.dump_coredata(), essentially, that is the file which determines whether the build system is considered to be configured and you need to use reconfigure/wipe.

@eli-schwartz thanks for the info.
I picked intro-buildoptions.json because this file is directly used by SciPy build script.
So for sure it is required to exist in SciPy case.
I guess in practice it is the same as checking for coredata.dat, but I really dont have knowledge of Meson.
It would be easy to check for coredata.dat as well. I can prepare a patch if you guys decide this is necessary.

It's probably not super important, just thought I'd mention it.
In general, the introspection json file is still written out after the buildsystem has been fully evaluated, checked, etc. -- which is the main opportunity for it to fail in ways that this PR was intended to solve.
It's still possible for e.g. something bizarre to happen and cause Meson to crash while generating the actual build.ninja, in which case the json files will exist but the coredata will not.
For the sake of thoroughness I'd say it cannot hurt to check the coredata file too, even if it's not especially likely.

but I really dont have knowledge of Meson.

I do have a special advantage there :) and am always happy to offer suggestions that aren't obvious to (most) people who lack a thorough understanding of Meson internals.


Create Generic Pages “en-ce-moment”

Automatically generated by Netlify CMS

👷 Deploy Preview for shiny-babka-998c7e processing.

Name
Link

🔨 Latest commit
bc123a2eb33f7886df6398325d101dfa8fb72442

🔍 Latest deploy log
https://app.netlify.com/sites/shiny-babka-998c7e/deploys/659c0b1f4e86f80008f1bade


Version not printed

renee --version does not print version number on the head node, but tries to load singularity. I understand that renee run etc do require singularity. But renee --version should spit out version without the need to load singularity.
On head node:

On interactive node:

xavier does something similar but does print version at the bottom line

The modules should only be loaded if they're not already in the path and the platform is either biowulf or FRCE.
The version command works when you call the main driver script /renee directly. The problem is in bin/redirect (symlinked to bin/renee), which contain the logic for loading modules and conda envs. I tend to think we should get rid of these bin/ files for both xavier and renee (except for maybe the last line to just call the CLI), and instead handle module stuff within run/dryrun subprocesses in the main driver script. Our nextflow template has a simpler design where there's only one subprocess.run call that prepends the command with module load if needed -- much easier to maintain since there's only one place where nextflow gets called (see https://github.com/CCBR/CCBR_NextflowTemplate/blob/da155de02067db79c0c74013840992739b05de90/src/util.py#L193-L208).

Work in progress on branch iss-107

Idea: what if we handle loading modules and the py311 conda env in the ccbrpipeliner module? This way we don't have to write repetitive and biowulf/frce-specific code for each pipeline, when they all require most of the same modules anyway (either snakemake or nextflow plus singularity). Most software typically requires users to figure out how to install dependencies with their preferred method anyway.


Use CupertinoIcons instead of material ones

A Cupertino widget should also use the cupertino icons

Thank you, Simon!


Upload library with module dependencies

Hi there.
I'm trying to upload an updated version of my library MaterialList, and I've successfully uploaded versions 2.0.2 and 2.0.3 (by now only 2.0.2 is available, within a few hours v2.0.3 should be also).
The problem comes when, between 2.0.1 and 2.0.2 a massive refactor was done, and now the library is divided into two modules, let's call them "core" and "implementation".
Before there was only a module, 'materialList'.
Now there are two: 'materialList', which contains the core, and 'sampleCards', which contains the implementation.
The implementation module depends on the core, and this is the module I want to upload (the implementation one).
It contains the line
compile project(':materialList')

So I thought that it would compile it, and be uploaded together. But when I try to use it via mvn, it throws the following error:
Error:A problem occurred configuring project ':app'.
> Could not resolve all dependencies for configuration ':app:_debugCompile'.
   > Could not resolve com.github.dexafree:materialList:2.0.2.
     Required by:
         com.github.dexafree:app:2.0.3 > com.github.dexafree:materiallist:2.0.2
      > inconsistent module metadata found. Descriptor: com.github.dexafree:materiallist:2.0.2 Errors: bad module name: expected='materialList' found='materiallist'

I don't know if the expected='materialList' found='materiallist' case problem is the main problem here, or if it's just uploading the implementation module and not the core one.
Thank you in advance

I include dependent classes by
task androidJavadocs(type: Javadoc) {
    failOnError false
    source = android.sourceSets.main.java.srcDirs
    classpath += project.files(android.getBootClasspath()) + project.files(configurations.compileJavadoc)
}

and then
compileJavadoc 'io.reactivex:rxjava:1.0.8'

in my gradle file.

I ended up publishing the whole project, sorry :worried:

@dexafree @amadib It will work with https://github.com/Vorlonsoft/GradleMavenPush. Please read README.md before use it.


feat(backend): add project lock to prevent concurrent actions

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#455
#454  👈
#453
#452
#451
#450
#449
#448
#446
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @NathanFlurry and the rest of your teammates on  Graphite


Fingerprint sensor

The fingerprint sensor on my laptop doesn't seem to be recognized. Is this a bug or is the driver just not implemented yet?

I think we're still waiting on the firmware update to be pushed from framework?

If you enable lvfs-testing the fingerprint reader seems to work on my 13th Gen Intel.
fwupdmgr enable-remote lvfs-testing
just update-firmware or
fwupdmgr refresh --force
fwupdmgr get-updates
fwupdmgr update

Hi,
I have Framework Laptop with 12 Gen Intel CPU. My fingerprint reader is recognized by fprintd, but not used by gnome. With stock Fedora Workstation 39 I didn't hat any problem.

I use ublue:silverblue-framework
Thanks for the awesome work
Keywan

Hey,
i could fix it with
sudo authselect enable-feature with-fingerprint

After I run this command, I could add fingerprints via gnome-setting and us it with sudo, pkexec or gnome-settings.
Will this change be reverted by a future rpm-ostree update? Can we enable "with-fingerprint" by default?
I'm happy to test settings or prepare a MR, but need some hints, if I'm on the right track.


Update performance test results for Ballerina v1.0.x

Purpose
This PR updates the performance test results for Ballerina v1.0.1x
Check List

[x] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #19464 into ballerina-1.0.x will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           ballerina-1.0.x   #19464   +/-   ##
================================================
  Coverage            15.73%   15.73%
================================================
  Files                   47       47
  Lines                 1265     1265
  Branches               197      197
================================================
  Hits                   199      199
  Misses                1053     1053
  Partials                13       13

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 69bc949...4a2c7d3. Read the comment docs.

Latest results: https://github.com/ballerina-platform/ballerina-lang/pull/19515


[Test] Unified 'boundedArbitraryExprB' and 'boundedArbitraryExprF'

This

unifies 'boundedArbitraryExprB' and 'boundedArbitraryExprF'
inlines some top-level functions that are only used once in an instance definition
adds a nested lets test case

As per discussion in slack, the unified generator still allows us to dispatch on the resulting type and do something different for distinct types (e.g. we generate special-cased comparisons when the resulting type is Bool), so we're not bound by parametricity.
I'll check that generated values are of a similar shape to the ones that we've been generating so far.

Running the testGen script I get:
Generated 1000 ASTs
Requested size = 1000

Minimum depth = 1              | 1
Maximum depth = 23             | 18
Mean depth    = 11             | 9

Minimum number of nodes = 1    | 1
Maximum number of nodes = 859  | 776
Mean number of nodes    = 251  | 181

where numbers after | are the ones that we were getting previously.
And for testGen 1000 10000 we get
Generated 1000 ASTs
Requested size = 10000

Minimum depth = 1               | 1
Maximum depth = 29              | 26
Mean depth    = 14              | 12

Minimum number of nodes = 1     | 1
Maximum number of nodes = 4195  | 4144
Mean number of nodes    = 1250  | 897

So we generate more nodes in average and the maximum number of nodes is greater as well. Seems fine.

Running the testGen 1000 1000 script I get:

...

So we generate more nodes in average and the maximum number of nodes is greater as well. Seems fine.

I had a closer look at the distribution of the sizes of the trees produced by the generators and I think we might even want to turn up the relative frequency of non-atomic nodes (ie, not variables or values).  I'll have another look using this branch: I'll send you details later.

There's a comment about hiding variables when we generate a new local with the same name.  It looks as if we are allowing references to shadowed variables now, so that comment should be removed.  We should probably still say something about how we're dealing (or not) with shadowing though, since that's an issue where it's not at all clear what should happen.

I basically understand it, but I might have some trouble if I had to make major additions to it.

I'll always be happy to help, of course.

I had a closer look at the distribution of the sizes of the trees produced by the generators and I think we might even want to turn up the relative frequency of non-atomic nodes (ie, not variables or values). I'll have another look using this branch: I'll send you details later.

Let's do that separately?

There's a comment about hiding variables when we generate a new local with the same name. It looks as if we are allowing references to shadowed variables now, so that comment should be removed. We should probably still say something about how we're dealing (or not) with shadowing though, since that's an issue where it's not at all clear what should happen.

I think that generating ASTs that we can't get by parsing is a feature, not a bug. We might also get such ASTs by compiling from some high-level language and we're going to do that at some point. The print-and-then-parse tests are now weaker indeed, but we can fix that by implementing alpha-equality of terms (also it is kind of weird to change uniques of free variables and so we probably want a newtype wrapper around Expr with that very specific Eq instance). Let's do that in a dedicated PR.
I don't think we should ban repeated names. It's fine to have them and we might get them after compiling from a high-level language, so it's good to test this scenario.

Comments addressed.

Ok, merging and let's solve the problems that we talked about here in follow-ups.


reactNativeRouterFlux.Actions.SignUp is not a function

I'm using react-router-flux module and getting an error like
reactNativeRouterFlux.Actions.SignUp is not a function,
reactNativeRouterFlux.Actions.SignUp is undefined

Sorry, it is question not issue and must be posted at stackoverflow. This error usually means that actions are not generated yet but you are using them already


Module 0 environment build -- auto enable services

I have tested building this stack from a new account and auto enabling of services.
GuardDuty fails on Auto Enable even with new accounts never accessing the account.
SH and Config also fail on the same process.
I found that going to SH on a fresh new account still shows it as enabled by default.
Config and GuardDuty do not however the CFT enable feature is generating an error so still created the Config rules manually and set Config auto enable to No in order to build this stack successful.

GuardDutyTesterTemplate | CREATE_FAILED | Embedded stack arn:aws:cloudformation:us-east-1:xxxyyyyzzzzzzz:stack/aws-meetup-sh-workshop-stack-GuardDutyTesterTemplate-111WU0YPHKMWQ/21b4f530-d277-11ea-9da4-0e3038696552 was not successfully created: The following resource(s) failed to create: [RedTeam].

I got the exact same error as noneil277 above when:

Config & Security HUB are not pre-enabled and I select ‘YES” to be enabled by the template
GuardDuty pre-enabled and I select “NO” to be enabled by the template

and when all three are pre-enabled by default.
It didn't work for me when disabling all three either, and selecting ‘YES” for all of them to be enabled by the template.
In all cases, I tried with a brand new AWS account.

@noneil277 @monicaalcalde Thank you for your feedback.  Sorry that you are running into some issues with deploying the workshop.
I would like to clarify the current issues that you are receiving.  The failure that is being reported from the GuardDutyTesterTemplate, where the RedTeam resource failed to create, is related to an EC2 resource which the template creates to help with generation of GuardDuty findings.   What I would like to know is if both of you are only seeing the the failure to create the RedTeam resource or if you are seeing other failures related to the steps for actually enabling the GuardDuty, Security Hub, and Config services.
Would it be possible to post the errors you are receiving related to CloudFormation trying to enable the GuardDuty, Security Hub, and Config resources?

closing this issue after no further feedback.    Most likely cause for this is running the template in a brand new account before the account could be baselined to allow launching of EC2 instances.


Update Cython to 3.0.0b2

Codecov Report

Merging #19 (f941c7f) into main (7a8ef49) will increase coverage by 94.18%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##           main      #19       +/-   ##
=========================================
+ Coverage      0   94.18%   +94.18%
=========================================
  Files         0        3        +3
  Lines         0      172      +172
=========================================
+ Hits          0      162      +162
- Misses        0       10       +10

see 3 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add GetCommissionerNodeId command supports for yaml tests, chip-tool and darwin-framework-tool

Problem
https://github.com/project-chip/connectedhomeip/pull/24197 has introduced a variable named commissionedNodeId for yaml that is directly exposed by the Test Harness. That diverge from the other YAML steps that normally use pseudo-clusters commands in order to do things.
commissionerNodeId is used in various tests now, so this PR replace the inner variable mechanism by exposing a new pseudo-cluster command (CommissionerCommands::GetCommissionerNodeId) where the value retrieved is saved and reused in the steps that needs it.
This PR requires a ZAP update but it can be reviewed before the ZAP update lands (for the record, the necessary ZAP change is in https://github.com/project-chip/zap/pull/910)

The first commit of this PR contains the codegen changes introduced by https://github.com/project-chip/connectedhomeip/pull/24757
This is in order to check that everything runs fine. In theory only the ZAP CI task should fails until #24757 lands.


Update required Node.js version

AArch64 builds message claims that 11.0.0 is required:
WARN engine<EMAIL_ADDRESS>wanted:
{"node":">=10.0.0"} (current: {"node":"8.10.0","npm":"3.5.2"})
WARN engine<EMAIL_ADDRESS>wanted:
{"node":"^8.16.0 || ^10.6.0 || >=11.0.0"} (current: {"node":"8.10.0","npm":"3.5.2"})

https://travis-ci.com/MIPT-ILab/mipt-mips/jobs/262643680


store_metadata_in_osv3: ensure we don't store null as value for image-id

LGTM. Just to be sure we do the same trick for other objects

It looks to me like all the other keys are protected.

LGTM. We should consider creating a generic utility for this.

Coverage remained the same at 87.226% when pulling 8eb7b6ff9cd7da5034390de41fd9528fba38d52c on metadata-no-null into 59599359b8eda3cb05e12ee96e062686ab4e7dca on master.


[core] Add Perlin ground profile generators.

I am proposing to add a unidirection Perlin ground HeightmapFunction, 2D Perlin ground HeightmapFunction and a quantization methods to quantize any ground to certain z-values.

[x] Unidirectional Perlin Ground:

[x] 2D Perlin Ground

[x] Pass the Perlin process by copy to the builder function

[ ] Ground quantization method to quantized the ground to only certain level

[ ] Unit tests

[ ] Fix sample_state in gym-jiminy to account for the ground profile ?

It would be nice to add a quantization options to quantized the ground to only certain level.

What do you mean ?

It would be nice to add a quantization options to quantized the ground to only certain level.

What do you mean ?
To be able to get this type of terrain:
 (ref: https://fse.studenttheses.ub.rug.nl/30171/1/thesis.pdf)

Are you planning to work on it ? If not, then I suggest closing this issue because I'm not planning to work on it either.

Yes, I did a bit more work on it but didn’t push anything yet. I’m planning to work on/finish it in a couple of weeks.

Ok perfect ! Let's keep it open then :)

Apparently you made good progress ! What is your future plan ? You want to add quantisation ? Can you add a unit test checking if the gradient is right ?

leads to floating point exception (core dumped)

The problem is not that it asserts to false because asserts are disabled for release build type. The issue is rather the contrary, we should systematically check this condition and raise an exception if not satisfying this condition causes segfault.

Apparently you made good progress ! Nice :)
What is your future plan ? You want to add quantisation ? Can you add a unit test checking if the gradient is right ?

Yes, I still need to do :

some update of the code (following your comments as well),
add quantisation on any ground,
since I'm already into Perlin noise, I'm thinking of adding 2d perlin noise/ground
Yes, add unit test for the gradient. I was thinking of comparing the gradient with the numerical gradient, were you thinking of any other tests?

I was thinking of comparing the gradient with the numerical gradient, were you thinking of any other tests?

Nope it is fine :)

Maybe update sample_state in gym-jiminy to account for the HeightMap.

I'm afraid doing this is not straightforward. It has been a long-lasting issue as you know. Once everything else is working, I could help you on this part to improve the current heuristic that has not sufficient in many cases.

To many code duplication. There should be no need to implement anything specific for the 2D scenario.

I'm going to help you on this, so that we can close this long-lasting PR.

I'm going to help you on this, so that we can close this long-lasting PR.

If you have time for it, I'm pretty happy to get your help. I didn't have much time to work on it the last few weeks, but hoping to finish it this week.

Ok I skimmed through the code. Now I remember. Since those processes at not used for anything inside core itself, I'm going to refactor them a bit. In particular to replace operator() by evaluate and add evaluate_gradient which will return both the value and its gradient. Then, I will rather template them with the dimensionality of the process, with only 1 and 2 being supported at the moment. I hope this will make everything more simple and clear, while avoid redundancy.

Since you're taking over for the PerlinNoise part, I started creating some unit tests (using the current methods' name) and fixed a typo in the 1D gradient computation. There is also a bug in the 2D gradient computation.

Ok nice, so far I have been working on adding the gradient feature on all the other random processes so as to provide a unified API for all of them, without slowing down computations. I have also fixed stuff like negative time, and fixed bugs on non-perlin processes.

I will commit something this morning.

OK I'm going to rebase your branch on mine and push the whole stack on this PR.

For the record, it is taking a bit more time than expected because I'm going for the N-dimensional implementation.

Just for you to now, I'm still on it. It is almost done. It was a bit more tricky than expected, but now it works in N-d without gradient.

I'm done with the gradient. Adding terrain generation.

Ready to merge. Missing stuff if any could be added later.

Can you try creating a periodic_perlin_ground on your side ? I am having a bit of trouble doing so:
In [15]: periodic_perlin_ground?
Docstring: periodic_perlin_ground( (float)wavelength, (float)period, (int)num_octaves, (int)seed) -> HeightmapFunction
Type:      function

In [16]: periodic_perlin_ground(1.0,2.0,6,0)
---------------------------------------------------------------------------
LogicError                                Traceback (most recent call last)
Cell In[16], line 1
----> 1 periodic_perlin_ground(1.0,2.0,6,0)

LogicError: jiminy::PeriodicPerlinNoiseOctave<2>::PeriodicPerlinNoiseOctave(/Users/mathiasw/Code/jiminy/core/include/jiminy/core/utilities/random.hxx:457):
'period' must be larger than 'wavelength'.

Also, I had started working on sample_state and added:

        # Compute the height of the freeflyer in neutral configuration
        # TODO: Take into account the ground profile.
        q_init, _ = self._sample_state()

        ground_profile = self.simulator.get_options()["world"]["groundProfile"]
        self._height_neutral = q_init[2] - ground_profile(q_init[:2])[0]

        # Get ground profile
       ground_profile = self.simulator.get_options()["world"]["groundProfile"]

       # Lowest contact point from ground
       contact_frames_xy_positions = np.stack([self.robot.pinocchio_model.frames[frame_index].placement.translation[:2]
                                   for frame_index in self.robot.contact_frame_indices])
       contact_frames_z_positions = np.stack([self.robot.pinocchio_model.frames[frame_index].placement.translation[2]
                                   for frame_index in self.robot.contact_frame_indices])
       ground_height_contact_frames = np.zeros((len(self.robot.contact_frame_indices),))
       query_heightmap(ground_profile, contact_frames_xy_positions, ground_height_contact_frames)
       delta_height_from_ground = contact_frames_z_positions - ground_height_contact_frames

       if (delta_height_from_ground >= 0.0).all():
           # Lowest=Closest contact points needs to be into contact
           # with the ground:
           q[2] -= min(delta_height_from_ground)
       else:
           # From the points below ground, deepest one needs to be in contact
           # with the ground
           delta_height = delta_height_from_ground[delta_height_from_ground < 0.0]
           q[2] = q[2] - delta_height.min()

Either there is a bug in this code or there is something that I've been missing because it's not working as expected.

Either there is a bug in this code or there is something that I've been missing because it's not working as expected.

No need to make two branches based on the sign of delta_height_from_ground. This should be fine:
        # Get ground profile
       ground_profile = self.simulator.get_options()["world"]["groundProfile"]

       # Lowest contact point from ground
       contact_frames_xy_positions = np.stack([self.robot.pinocchio_model.frames[frame_index].placement.translation[:2]
                                   for frame_index in self.robot.contact_frame_indices])
       contact_frames_z_positions = np.stack([self.robot.pinocchio_model.frames[frame_index].placement.translation[2]
                                   for frame_index in self.robot.contact_frame_indices])
       ground_height_contact_frames = np.zeros((len(self.robot.contact_frame_indices),))
       query_heightmap(ground_profile, contact_frames_xy_positions, ground_height_contact_frames)
       delta_height_from_ground = contact_frames_z_positions - ground_height_contact_frames

       # Make sure that there is exactly one point in contact with the ground, all the others being above the ground
       q[2] -= min(delta_height_from_ground)

The issue is that it is flying when I test it on Perlin ground...
Also the API changed on query_heighmap so it needs to be:
        contact_frames_xy_positions = np.stack([self.robot.pinocchio_model.frames[frame_index].placement.translation[:2]
                                    for frame_index in self.robot.contact_frame_indices], -1)

Can you try creating a periodic_perlin_ground on your side ? I am having a bit of trouble doing so:

It is expected, but the error message is misleading. I will fix it. In fact, each octave has a larger wavelength than the "previous" one, so if you add too many octaves, at some point it can exceed the period.

Can you try creating a periodic_perlin_ground on your side ? I am having a bit of trouble doing so:

It is expected, but the error message is misleading. I will fix it. In fact, each octave has a larger wavelength than the "previous" one, so if you add too many octaves, at some point it can exceed the period.

Is it standard implementation or some implementation use the other convention (each octave has a higher frequency) ?

The issue is that it is flying when I test it on Perlin ground...

Did you updated the forward kinematic by calling update_quantities or framesForwardKinematics ?
# Set robot in neutral configuration
q = self._neutral()
pin.framesForwardKinematics(self.robot.pinocchio_model, self.robot.pinocchio_data, q)

Is it standard implementation or some implementation use the other convention (each octave has a higher frequency) ?

It is standard, look for Perlin Noise "persistence" and "lacunarity".

The issue is that it is flying when I test it on Perlin ground...

Did you updated the forward kinematic by calling update_quantities or framesForwardKinematics ?
# Set robot in neutral configuration
q = self._neutral()
pin.framesForwardKinematics(self.robot.pinocchio_model, self.robot.pinocchio_data, q)

It should be called since it is what comes after in reset:
        # Sample the initial state and reset the low-level engine
        q_init, v_init = self._sample_state()
        if not jiminy.is_position_valid(self.robot.pinocchio_model, q_init):
            raise RuntimeError(
                "The initial state provided by `_sample_state` is "
                "inconsistent with the dimension or types of joints of the "
                "model.")

        # Set robot in initial configuration
        pin.framesForwardKinematics(
            self.robot.pinocchio_model, self.robot.pinocchio_data, q_init)

Also the API changed on query_heighmap so it needs to be:

Yes, it changes for leveraging vectorisation more efficiently and hence improvement performance.

It shouldn't be needed since it is already called after sample_state in reset:

Indeed. If you called refresh afterward then there is something very strange happening.

Here is the code snipper I use:
import numpy as np

from gym_jiminy.envs.anymal import ANYmalPDControlJiminyEnv
from jiminy_py import tree
from jiminy_py.core import periodic_perlin_ground, random_perlin_ground

if __name__ == '__main__':
    env = ANYmalPDControlJiminyEnv()
    engine_options = env.simulator.get_options()
    orientation = 0.0
    wavelength= 1.0
    num_octaves = 8
    seed = 42
    engine_options["world"]["groundProfile"] =  random_perlin_ground(wavelength, num_octaves, seed)
    env.simulator.set_options(engine_options)
    for i in range(5):
        obs, _ = env.reset(seed = i)
        terminated, truncated = False, False
        while not (terminated or truncated):
            assert not any(np.isnan(e).any() for e in tree.flatten(obs)), "Nan in observation"

            obs, _, terminated, truncated, _ = env.step(0.0*env.action_space.sample())
            breakpoint()
            if terminated or truncated:
                print(f"terminated: {terminated}, truncated: {truncated}")
        env.replay(backed="panda3d")
        env.stop()

Here is your issue:
            contact_positions = np.stack([
                self.robot.pinocchio_data.oMf[frame_index].translation
                for frame_index in self.robot.contact_frame_indices], -1)

I can confirm it is working with:
            engine_options = self.simulator.get_options()
            ground_fun = engine_options['world']['groundProfile']

            # Lowest contact point from ground
            contact_positions = np.stack([
                self.robot.pinocchio_data.oMf[frame_index].translation
                for frame_index in self.robot.contact_frame_indices], -1)
            contact_heights = np.zeros((contact_positions.shape[-1],))
            jiminy.query_heightmap(
                ground_fun, contact_positions[:2], contact_heights)
            delta_height_from_ground = contact_positions[2] - contact_heights

            # Make sure that there is exactly one point in contact with the
            # ground, all the others being above the ground.
            q[2] -= delta_height_from_ground.min()

Oh yes, that's a nice catch. It is still floating in the air on my end..

It is fine on my side ! (I mean with "your" patch to make the robot touch the ground, it is not merged for now as it is not generic enough, it should also consider collision bodies, even if they are not properly supported at the time being that are used in ant environment for instance)

I need to profile this code, because I'm not happy at all with the performance:
positions = np.random.rand(3, 100)
%timeit jiminy.query_heightmap(ground_fun, positions[:2], positions[2])
76.1 µs ± 680 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

I consider this as extremely bad. I would expect something like 5us at max. There is a lot of redundant computations everywhere: the gradient is computed independently from the height, and the gradient at knots is never cached even if the query point is only shifted by 1mm.

Damn... most of the time is spend it computing cos, sin, and pow... sounds tricky to optimise...


About and Splash Widgets need a clear format button

Many users rely on copying and pasting text from websites - however this sometimes carries over unwanted HTML. You should consider adding a clear format button on these widgets like in the Public Information Map and other templates. @driskull

@pjdohertygis ...these widgets are not included in this repository.


Solace Direct Messaging capability

Solace Direct Messaging Capability.

Enabled client.type property to check for client type direct or persistent
Implemented seperate class for Direct messaging client
Renamed few properties that are common to direct and persistent messaging client
Added tests to validate direct messaging capability

@ozangunalp Review comments are addressed in this commit - https://github.com/SolaceLabs/solace-quarkus/pull/76#:~:text=and Documentation update-,b6aa984,-Merge state

@SravanThotakura05 Looks good to me. Maybe we can squash the commits.

@ozangunalp removed unused config and squashed commits


Add support for Ranger buffs

Relevant data:

Skill Name
Skill ID
Effect Name
Effect ID
Validated in Ragna4th?

Placeholder
12345
PLACEHOLDER
54321
no

Relevant skills:

No Limits
Fear Breeze
Full Throttle

Source: https://irowiki.org/wiki/Ranger


SVG rendering issue

Tested versions
4.2.2.rc2
System information
Godot v4.2.2.rc2 - Pop!_OS 22.04 LTS - X11 - GLES3 (Compatibility) - Mesa Intel(R) Graphics (ADL GT2) () - 12th Gen Intel(R) Core(TM) i5-1235U (12 Threads)
Issue description
There is an SVG rendering bug that causes every second stroke closing joint to close incorrectly.
Only one of our icons is affected.

It's also fixed in latest ThorVG version. I've not checked if it's fixed in our master branch though.
Steps to reproduce
Check out this icon in the visual shaders editor, or make your own SVG that has the issue, for example <svg width="64" height="64" viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg"><path d="M5 3.5l-2 4.5 5.5-2zM8.5 9.5l.5 3.5 3.5-2.5z" fill="none" stroke="#def" stroke-linejoin="round"/></svg>
Minimal reproduction project (MRP)
N/A

Can you confirm that cherrypicking https://github.com/godotengine/godot/pull/89591 will close this?

Can you confirm that cherrypicking #89591 will close this?

I don't think so, but I confirmed that #90243 fixes it.


Subsequent, identical requests always fail

I'm having a strange issue where I try to hit either the same server or different servers twice, and the second one always gets a name-resolution failure. This does not happen when I use urllib3. This is specific to Requests, which is queer as Requests uses urllib3.

This only happens on my build systems. It works as expected locally. Both local and remote are on Requests 2.9.1 .
It happens in both Python 2.7 and Python 3.
It happens even when I request SSL from these servers and then get a SSL failure (because these servers aren't configured for it). Even though there is an SSL-related protocol breakdown, the first request fails properly, and the second fails due to no connection.
Specifically, it's the socket.getaddrinfo call. I tested it directly.. after I due a requests.get(), I do a socket.getaddrinfo() and it fails.
I've tried with and without using Requests' sessions functionality.
I've tried requests with and without a "Connection: close" header.

The results are always identical.
_LOGGER.info("SENDING REQUEST 1")

try:
    r = requests.get(url)
    r.raise_for_status()
except:
    _LOGGER.exception("There was a problem.")
else:
    raw_response = r.text

    _LOGGER.info("Response:\n=====\n{}\n=====".format(raw_response))

_LOGGER.info("SENDING REQUEST 2")

try:
    r = requests.get(url)
    r.raise_for_status()
except:
    _LOGGER.exception("There was a problem.")
else:
    raw_response = r.text

    _LOGGER.info("Response:\n=====\n{}\n=====".format(raw_response))

Output:
04:00:58 INFO:__main__:SENDING REQUEST 1
04:00:58 INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): sanitized.url
04:00:58 DEBUG:requests.packages.urllib3.connectionpool:"GET /CiTriggerService/Notify HTTP/1.1" 405 1741
04:00:58 ERROR:__main__:There was a problem.
04:00:58 Traceback (most recent call last):
04:00:58   File "/tmp/jenkins7232109961798303504.sh", line 36, in <module>
04:00:58     r.raise_for_status()
04:00:58   File "/usr/lib/python3/dist-packages/requests/models.py", line 840, in raise_for_status
04:00:58     raise HTTPError(http_error_msg, response=self)
04:00:58 requests.exceptions.HTTPError: 405 Client Error: Method Not Allowed for url: http://sanitized.url:9091/CiTriggerService/Notify

04:00:58 INFO:__main__:SENDING REQUEST 2
04:00:58 INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): sanitized.url
04:00:58 ERROR:__main__:There was a problem.
04:00:58 Traceback (most recent call last):
04:00:58   File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 137, in _new_conn
04:00:58     (self.host, self.port), self.timeout, **extra_kw)
04:00:58   File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 67, in create_connection
04:00:58     for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM):
04:00:58   File "/usr/lib/python3.5/socket.py", line 732, in getaddrinfo
04:00:58     for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
04:00:58 socket.gaierror: [Errno -2] Name or service not known

Yet, urllib3 works fine:
import urllib3
http = urllib3.PoolManager()

print('')
print("Request 1:")
print('')

r = http.request('GET', 'http://sanitized.url:9091/CiTriggerService/Notify')
print(r.status)
print(r.data)

http = urllib3.PoolManager()

print('')
print("Request 2:")
print('')

r = http.request('GET', 'http://sanitized.url:9091/CiTriggerService/Notify')
print(r.status)
print(r.data)

Output:
04:12:52
04:12:52 Request 1:
04:12:52
04:12:52 405
04:12:52 b'\xef\xbb\xbf<?xml version="1.0" encoding="utf-8"?>\r\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
...
04:12:52
04:12:52 Request 2:
04:12:52
04:12:52 405
04:12:52 b'\xef\xbb\xbf<?xml version="1.0" encoding="utf-8"?>\r\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
...

I realize that the version that we're running on is quite a bit behind, but, given that it works perfectly fine on my local system at the same version, I doubt that an update would not make a difference and I can't blindly move forward on tweaking our provisioning process without a reason.

Closing this. Since there's no way to publicly debug this and the parameters and issue, in general are irrational and nonsensical, I'm not expecting anyone to be able to [effectively] help.


Import wiz 2.6

related issue: https://github.com/stolostron/backlog/issues/24557

/retest

/retest-required

/retest-required

/retest


Add v2 of the dashboard_list_item API

Adds the v2 version of the dashboard list item API - https://docs.datadoghq.com/api/?lang=python#get-items-of-a-dashboard-list
Makes new methods for each CRUD operation (same names as the V1 version but appended with V2)
Only the individual items API has a V2, so this doesn't duplicate the V1 dashboard_list API. Mostly the same, but the Item struct ID field is now all capitalized, and returns a string instead of an integer.

@jbenais Thanks for the review. Added a set of tests (its pretty much identical to the tests for v1, but updated to use the new structs/methods) Let me know what you think.
I also don't have a strong preference but found myself referring to these as DashboardListV2Items vs having the V2 after the word items. Let me know if you think one is preferential to the other. (The API methods are consistent)

LGTM, merging 👍 Thanks for doing this!


Remove south migrations

Closes #20

I appreciate you want to simplify this, but I'd like to suggest a somewhat smoother migration path, i.e. continue to offer South migrations for Django 1.6 users, and create new migrations using Django >=1.7 native migrations.
great app btw :+1: thanks!

Hi @miraculixx,
Thank you for the feedback.
You kinda reminded me of this but i am not sure i will want to keep django 1.6 support given that the django project decided to drop support for it.

not sure i will want to keep django 1.6 support given that the django project decided to drop support for it

some still use 1.6 because migration to 1.7 has a few implications, and not all apps that people depend on have migrated to 1.7 yet... if you drop 1.6 support, may I suggest to please add a release that still has 1.6 support so people can decide by themselves?


Merge parameter ignore hidden parameter

version: 2.9.2
bug fix

The parameter merger is missing the hidden field.
https://github.com/springfox/springfox/blame/master/springfox-core/src/main/java/springfox/documentation/builders/ParameterMerger.java#L88

I created the pull request, but I based from the 2.9.2 tag. There is conflict with the latest code from master branch


Release Notes link broken

Hello Damien,
I just have a look on your online documentation available at https://damienharper.github.io/auditor-docs/docs/auditor/index.html, and realized that the Release notes link on Getting Started section is broken.
Gave a 404 error with : https://damienharper.github.io/auditor-docshttps://github.com/DamienHarper/auditor/releases
I don't know Couscous CMS, so I can't help you but source definition is at https://github.com/DamienHarper/auditor-docs/blob/master/couscous.yml#L38

Same issue with auditor-bundle docs and Release notes link defined at https://github.com/DamienHarper/auditor-docs/blob/master/couscous.yml#L67

@llaville Thanks for the report, I already noticed it but hadn't time to fix it yet. It seems related to the way Couscous handles links (it might not support full absolute links :/ I need to investigate)

After having a look on your source code, I've noticed that menu is generated by twig macro https://github.com/DamienHarper/auditor-docs/blob/master/template/helper.twig#L12
You need to update it and check if protocol is set before to prepend baseUrl

Good catch, thanks @llaville

Fixed!


Getting Started with Snowflake - Zero to Snowflake - Section 10

In the above, under step 2, the database should be `soVID19_EPIDEMIOLOGICAL_DATA` instead of `COVID19_BY_STARSCHEMA_DM`

@sfc-gh-ybrenman can you please take a look? thanks.


OBDragDropManager EXC_BAD_ACCESS crash

Hi
Thanks for the great library
I keep getting this error EXC_BAD_ACCESS on this function:
-(BOOL) ovumRecognizerShouldHandleTouch:(UIGestureRecognizer *)recognizer {
if (recognizer.state == UIGestureRecognizerStateBegan) {
id ovumSource = recognizer.ovumSource;
    if ([ovumSource respondsToSelector:@selector(shouldCreateOvumFromView:)] && //On this line
        ![ovumSource shouldCreateOvumFromView:recognizer.view])
    {
        // Workaround to cancel the gesture recognizer
        recognizer.enabled = NO;
        recognizer.enabled = YES;
        return NO;
    }
    return YES;
}

return recognizer.ovum != nil;

}
I am using the gesture recognizer on UITableViewCells.
When the application goes to the background and comes back to the foreground, if I touch one of the cells (most of the time) it will crash the app.
The ovumSource in the gesture recognizer is held with an assign attribute, so they are naturally not strongly holding the object.
My OvumSource object is strongly held by my TableViewController.
Any ideas?
Thanks

Hi there,
Sorry for the belated response. I added a UITableView source in the test project, but wasn't able to reproduce the error you saw.
There's a subtlety with using the drag drop framework on UITableViewCells in case you're not aware, whereby one should take care not to add more than one instance of the drag drop gesture recognizer.
Here's a snippet:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
  UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:kCellIdentifier forIndexPath:indexPath];

  ...

  // Drag drop with long press gesture
  //
  // Be careful with attaching gesture recognizers inside tableView:cellForRowAtIndexPath: as cells
  // get reused. Add a check to prevent multiple gesture recognizers from being added to the same cell.
  // The below check is crude but works; you may need something more specific or elegant.
  if (cell.gestureRecognizers.count == 0) {
    OBDragDropManager *dragDropManager = [OBDragDropManager sharedManager];
    UIGestureRecognizer *recognizer = [dragDropManager createLongPressDragDropGestureRecognizerWithSource:self];
    [cell addGestureRecognizer:recognizer];
  }
}

Let me know if that helps.

Hi there,
sorry for my late reply too.
I have made sure that i don't add extra gesture recognisers, but the issue was still occurring.
I made a little modification on
@property (nonatomic, assign) id ovumSource;
and made the property weak instead.
That seems to stop the crashing and work OK.
Not sure if that's the correct way of fixing the problem though.

Hey there,
Are you referring to the protocol definition of OBDragDropGestureRecognizer? I do see that we're using retain/assign instead of strong/weak ... the change makes sense since the weak reference would prevent the crashes you're seeing.
I can change it from my end, or if you'd like submit a pull request and I'll merge it.


Resolve build warnings

Description
Changes proposed in this pull request:

Pass GENERATE_SOURCEMAP=false to resolve missing react-tippy source map warning. It looks like a bug in CRA.

We can't have a fix for DEP_WEBPACK_DEV_SERVER_ON_AFTER_SETUP_MIDDLEWARE - onAfterSetupMiddleware function is used by CRA again (here).

I noticed that core is complaining about big size of lib/vs (the minified Monaco). It's not used actually by core, but by react-shared - core just copies it so shared can access it lazily. We could remove some warnings (with help of https://www.npmjs.com/package/webpack-exclude-assets-plugin), but I don't consider it that valuable.

/test pre-busola-integration-test-k3s

/test pre-busola-integration-test-k3s

/test pre-busola-integration-test-k3s

/test pre-busola-integration-test-k3s

/test pre-busola-integration-test-k3s


NullreferenceException in a public getter seems to throw the editor in a corrupted state

Summary
Code from pathfindax:

If a nullreference exception is thrown in the getter here (CreatePathfinder can do that in this case) the editor seems to go into a corrupted state leading to all kinds of strange things like ghost components that live outside of any scene.
TODO: simplify and isolate the problem
How to reproduce

Cause nullreference exception in a getter
TODO

There are no editor guards in place in order to prevent an exception from inside user code getters or setters to propagate into the editor - however, I think it should be possible to add try / catch clauses like that in spots where these kinds of errors are most likely to occur.
Is there a callstack we can work with? From where exactly is that getter called when the problem occurs?

So I tried the following things:
-Make the property invisible in the UI.
-Change the property to a method.
Neither of those changes seem to solve the problem.
The code is used in a DualityApp.Mouse.ButtonDown event. Iam still in the process of isolating this completely so sorry for the current lack of info.

Ah seems I have forgotten to unsubscribe the DualityApp.Mouse.ButtonDown event. This in addition to the fact that new GameObjects/Components are created when you enter/leave sandbox mode means you will be calling methods on objects that are supposed to be out of scope. So this was really a bug caused by myself.
Aside from that fact though it would be nice if the editor actually told you forgot to unsubscribe some event.

Let's refocus this issue towards guarding against forgotten public event subscriptions then 👍
Can you rename / edit the issue to reflect this? Don't remove the old description and repro sample though, doesn't hurt to have them still around, maybe just "quote" them at the bottom as original text.

So a solution to this would be the following structure:
`
var list = new List();
for (int i = 0; i < 10; i++)
{
try
{
SomeShutdownMethod();
}
catch (Exception e)
{
list.Add(e);
}
}
        if (list.Count > 0)
        {
            throw new AggregateException(list);
        }

`
However this has a downside since the debugger will no longer automatically break at the original exception/exceptions. This can be solved with the [DebuggerStepThrough] attribute though.

Moved the Editor doesnt tell you you forgot to unsubcribe a event issue to a separate issue #666

Great idea from a design perspective, but not sure what it would do to performance, as passing-by-delegate potentially produces garbage and cannot be optimized as thoroughly as a regular function call - I'd generally try to avoid this in spots like this. If having specialized methods instead has a big impact design / maintenance wise though, we should probably consider it anyway. It's a tradeoff.

A delegate invocation does not produce garbage if it does not capture a local variable. Aside from that a delegate invocation is pretty just as fast as a interface call. I doubt this will lead to noticable performance issues or that the difference is even measurable in duality.

Performance considerations mostly, as a try-catch block isn't free if I recall correctly, especially when optimizations (or lack thereof) come into play. Would still be willing to consider making the change, as you're right that there's somewhat severe editor / dev bug potential when left entirely unchecked.

In the happy path I don't think there is any noticable difference with a try catch block. Only when actual exceptions are thrown there will be a difference.
But like always with performance only by measuring it you will know it for sure.

A delegate invocation does not produce garbage if it does not capture a local variable.

Delegate invocation might not, but delegate creation does. Unless you cache the implicitly created delegate when passing some method to the delegate parameter, you'll create a new one on every call.

Aside from that a delegate invocation is pretty just as fast as a interface call. I doubt this will lead to noticable performance issues or that the difference is even measurable in duality.

Even if the invocation was free, it's still less compiler / JIT optimizable than having a specific method called.
You're probably right on this for init and shutdown though, just let's not expand this to update and render calls, or expect one generalized method to cover them all via delegate.

In the happy path I don't think there is any noticable difference with a try catch block. Only when actual exceptions are thrown there will be a difference. So I don't think we should be afraid of putting try catch blocks where its needed.

try..catch will block some compiler optimizations, so I wouldn't just put them wherever.
My point in both cases is just that we're in territory where we should spend some thought on how a design change might impact performance and compiler optimizations. Handling components - that's a big part of what the update cycle does all the time. Compiler friendly code can pay off when dealing with 10k objects potentially every frame. It's probably worth the tradeoff for init and shutdown, just a general "beware" sign here 🙂

Potentially related: Issue #381

I think it might be worth benchmarking the code to see what really happens.
My current understanding is that delegate's (statically typed and without closures) do not have any GC overhead. This might be proved wrong though. On top of that I believe their invocation to be equally fast as a interface/virtual call.
Try catch will increase the size of the method body I believe so it could potentially affect performance. I suspect this difference to be on the single nanosecond scale or maybe less though.
Will report back when I got the results.


extend .gitignore for .vscode & /dev

How to categorize this PR?

/area dev-productivity
/kind cleanup
/priority normal
What this PR does / why we need it:
Extend the existing .gitignore file to ignore any repository specific VC code settings and a dev folder.
Both items seem to be ignored in most of the other Gardener repositories, so it would help harmonize things across these.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

/invite @schrodit

publish step only failed because of docker rate limits


Tutorial issues

Hi,
Firstly, thanks for writing this, looks really useful.
I'd like to make a couple of suggestions for the tutorial page.

from livescrape import ScrapedPage, Css, CssMulti
(beginner friendlify it)

class project_page = GithubProjectPage(ScrapedPage):
^^ your version didn't capitalise Page in GithubProjectPage

project_page = GithubProjectPage("ondergetekende", "livesscrape")
( double s in livesscrape)

print (project_page.contents) returns empty dicts. It would improve the tutorial if something came back here.

I appreciate this isn't as interesting as editing code - I'm happy to send over an error-free tutorial page (or figure out git) if it's easier.
Thanks again,
Mat

You're completely right; documentation's importance isn't quite matched by its "interestingness". I'll address these issues after my day job...

from livescrape import ScrapedPage, Css, CssMulti
(beginner friendlify it)

How would you suggest to friendlify this?
(the other points will be addressed later today)

Hi Koert,
You hadn't imported anything - I think if you include the necessary imports
it'll be easier for people to get started (aka more friendly).
I'll check back when you've had a change to update it.
Thanks,
Mat
On 9 February 2016 at 09:21, Koert van der Veer<EMAIL_ADDRESS>wrote:

You're completely right; documentation's importance isn't quite matched by
its "interestingness". I'll address these issues after my day job...
from livescrape import ScrapedPage, Css, CssMulti
(beginner friendlify it)
How would you suggest to friendlify this?
(the other points will be addressed later today)
—
Reply to this email directly or view it on GitHub
https://github.com/ondergetekende/livesscrape/issues/2#issuecomment-181774839
.

I feel that I've addressed all of the issues you mentioned, but your proofreading abilities obviously exceed mine, so could you have a look again?
Thanks for helping me out here - it's much appreciated.

I just tried running it - you need to add CssLink to your imports.
The class definition also fails - I'm not sure why.
Traceback (most recent call last):
File "", line 1, in
File "", line 6, in GithubProjectPage
TypeError: init() takes exactly 3 arguments (2 given)
Can't do more now, will check back later.
Ta,
Mat
On 9 February 2016 at 13:05, Koert van der Veer<EMAIL_ADDRESS>wrote:

I feel that I've addressed all of the issues you mentioned, but your
proofreading abilities obviously exceed mine, so could you have a look
again?
Thanks for helping me out here - it's much appreciated.
—
Reply to this email directly or view it on GitHub
https://github.com/ondergetekende/livescrape/issues/2#issuecomment-181855632
.

Beautiful. To achieve perfection, loose the blank like before you define description so it can cut&paste into a console better.
Now for a look at the tutorial.
Thanks again
Mat


Add feedback form

TODO:

[ ] Where to store the data
[ ] Review form copy
[ ] Add modal trigger
[ ] Define subject options

For subject options, thinking:

Report a technical issue
Let us know what you think
Get in touch with OAM team
Everything else

@ricardomestre @cgiovando

Where to store the data

@danielfdsilva to look into it more.

Add modal trigger

@DylanMoriarty @ricardomestre where you do think we should put the trigger? We talked about maybe putting it on the map or in the About dropdown?

First version of the modal up on feature/feedback.
Data is being stored in a google doc for now.
For the trigger I used the "Contact" button on the dropdown. This needs to be reviewed.

Tucking it into the "About" dropdown seems fine to me. That dropdown is the current home to the 'contact us' and is the closet thing we have to a sub menu for the site. If we need more sub elements like that for the site, it might be worth revisiting that button and maybe doing something more menu-y.
A Feedback form is tangential enough to information about this site that I think it would do fine living in there.

@danielfdsilva 👍
@DylanMoriarty Yeah. One follow up question is around reporting map issues. Think putting it in the About dropdown limit the ability to report a issue with the map (like thumbnail broken, or TMS doesn't work)? Or do we just add an extra link within the map area that says something like Report an issue with the map.

We could have dedicated buttons in strategic places that would pre-fill the
subject.
On Jun 14, 2016 6:34 PM, "Nate Smith"<EMAIL_ADDRESS>wrote:

@danielfdsilva https://github.com/danielfdsilva 👍
@DylanMoriarty https://github.com/DylanMoriarty Yeah. One follow up
question is around reporting map issues. Think putting it in the About
dropdown limit the ability to report a issue with the map (like thumbnail
broken, or TMS doesn't work)? Or do we just add an extra link within the
map area that says something like Report an issue with the map.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hotosm/oam-browser/issues/140#issuecomment-225956586,
or mute the thread
https://github.com/notifications/unsubscribe/ABCkLtm3m3IdBfEU32lbCyCDYMGKSWW_ks5qLuYcgaJpZM4Ia-f9
.

For issues directly associated with the map area, we could add 'Report an issue with the map' to the annotation. (the line that reads © Mapbox © OpenStreetMap Improve this map could instead say © Mapbox © OpenStreetMap | Report an bug with the map. ).
'Improve the map' goes to a feedback form for MB that just let's someone point out if something is wrong with the OSM layer of the map. I can see that being useful here if someone spots something off, but think it might be confusing if we have both 'Report an issue with the map' & 'Improve map' in the same line, particularly because both would be going to feedback forms.

@DylanMoriarty Agreed on the point about having two report links, we should just have one.


(BOLT-53) Global transport

Adds a --transport command line option for specifying the default transport to use if one is not specified. The default transport is ssh. This is handy for Windows as you don't need to repeat winrm in each node URI:
bolt command run whoami -n win1,win2,win3,win4 --transport winrm

CLA signed by all contributors.


SAPUI5 Freestyle app vs Fiori elements app recording

hello ,
After generating wdi5 code using UI5 Journey Recorder, we noticed the code generated for a very small SAPUI5 Freestyle app was missing details for the navigation path and had small mistakes related to syntax.

The code generated for Fiori elements worked as expected.  Is the UI5 Journey Recorder intended to work only with Fiori elements?
The dependencies are:
"@babel/eslint-parser": "7.14.7",
"@sap-ux/ui5-middleware-fe-mockserver": "2",
"@sap/eslint-plugin-ui5-jsdocs": "2.0.5",
"@sap/ui5-builder-webide-extension": "^1.1.8",
"@sap/ux-ui5-tooling": "1",
"@sapui5/ts-types": "~1.108.0",
"@ui5/cli": "^3.0.0",
"@wdio/cli": "^7.31.1",
"@wdio/local-runner": "^7.31.1",
"@wdio/mocha-framework": "^7.30.2",
"@wdio/spec-reporter": "^7.31.1",
"chromedriver": "^112.0.1",
"eslint": "7.32.0",
"eslint-plugin-fiori-custom": "2.2.1",
"mbt": "^1.2.18",
"ui5-task-zipper": "^0.5.0",
"wdio-chromedriver-service": "^7.3.2",
"wdio-ui5-service": "^1.3.3"
UI5 Journey Recorder 0.2.1
Thank You,
Joe Valliparampil.

Hi,
thanks for the small syntax issues, i will adress them as soon as possible.
For the wrong path: What's the correct one?
Or better can you send an export of the Step/Journey? Another possible way is the url for the page, because we determine the path from this url.
As for your question: No the UI5-Journey-Recorder is not only for Fiori-Elements it should work for all types of UI5-Applications. Sometimes it's hard to determine some correct code-generations. As well as the test-setups differ.
Maybe you can describe which code-fragments fit not for your tests?
Best regards
Adrian Marten


Convert simple byte handlers in lexer to branchless code

Why the lexer is slower than it needs to be
Many of the simpler byte handlers in the lexer perform multiple branches.
e.g. The handler for = which needs to figure out "is the whole token =, ==, ===, or =>?"
https://github.com/oxc-project/oxc/blob/b9d69ad665ab386233f940e9f1a9b3095a2238dc/crates/oxc_parser/src/lexer/byte_handlers.rs#L389-L403
Typical JS code will contain a random mix of assignments x = 1, equality checks x === 1, and arrow functions =>.
Because of the random distribution, the branch predictor won't be able to predict what the token is going to be, and so which way these branches are going to go. It will likely get it wrong at least 50% of the time. Branch mis-predication is fairly expensive (I think I read about 20 CPU cycles each time), and these functions are on a hot path because =, ===, and => are all common in JS code.
Make it branchless!
We could convert these matchers to branchless code with something like this:
// Set the discriminants for `Kind` to always follow the pattern
// that `discriminant % 4` is number of bytes this token takes
const EQ_BASE: u8 = 64; // or whatever multiple of 4

#[derive(PartialEq, Clone, Copy)]
#[repr(u8)]
pub enum Kind {
    /// `=`
    Eq = EQ_BASE + 1,
    /// `==`
    Eq2 = EQ_BASE + 2,
    /// `===`
    Eq3 = EQ_BASE + 3,
    /// `=>`
    Arrow = EQ_BASE + 4 + 2,

    // ...all the other token kinds
}

ascii_byte_handler!(EQL(lexer) {
    const fn num_bytes(kind: Kind) -> usize { kind as usize % 4 }

    // Check the invariant about discrimants mentioned above at compile time
    const_assert!(num_bytes(Kind::Eq) == "=".len());
    const_assert!(num_bytes(Kind::Eq2) == "==".len());
    const_assert!(num_bytes(Kind::Eq3) == "===".len());
    const_assert!(num_bytes(Kind::Arrow) == "=>".len());

    // NB: For simplicity, not handling case where close to EOF
    // and there are not 2 more bytes remaining in source to read.
    // Would need to handle that case separately, in a `#[cold]` branch.

    let next2: [u8; 2] = unsafe { lexer.source.position().add(1).read2() };
    let kind = if next2 == [b'=', b'='] {
        Kind::Eq3
    } else {
        match next2[0] {
            b'=' => Kind::Eq2,
            b'>' => Kind::Arrow,
            _ => Kind::Eq,
        }
    };

    unsafe { lexer.source.advance(num_bytes(kind)); }

    kind
});

The trick is to make Kind play two roles. It's the token kind, but it also encodes how many bytes the token is. This is what allows to compiler to use cmovne instructions rather than branches.
Godbolt shows this compiles down to branchless code: https://godbolt.org/z/5W7qjfqMq
Note on benchmarking
We need to alter the benchmarking setup before we do this. CodSpeed have advised that the way their benchmarking works, it doesn't take into account branch mis-prediction.
So, even if this change makes a solid difference in real world (which I think it could), it won't show up on our CodSpeed benchmarks.
We need some way to check that this is improving performance in the way that we think it is.

Is this done? (Sorry I lost track).

No, this one is not done yet.
As mentioned under "Note on benchmarking" header above, I actually think ideally we'd get some form of wallclock benchmarking set up before we do this, as currently I doubt CodSpeed benchmarks would say it was a benefit, even if it was in reality (because CodSpeed doesn't take into account branch prediction, and this change is all about reducing branch mis-predictions).
Shall we move it back to backlog for now?

I haven't finished this yet, but I had started coding something locally so I pushed my WIP branch to https://github.com/oxc-project/oxc/pull/4597. CodSpeed indeed does not report much change.

@lucab OK great. Didn't know you were working on it.
I was surprised to find that your version in #4597 does result in branchless code, despite not using the trick I proposed above of encoding the length in Kind's bottom 3 bits.
Inspired by your version, I've come up with a new one which results in same compact assembly as my original version but without having to do anything special with Kind's discriminants. It's a couple of instructions shorter than your version, lucab:
https://godbolt.org/z/zY1qv5boa
#[repr(u8)] // <- Add this so you can treat `Kind` as a number (`u8`)
#[derive(Clone, Copy)]
enum Kind { /* same as now */ }

// `!`
ascii_byte_handler!(EXL(lexer) {
    lexer.consume_char();
    let kind_and_len = match lexer.peek_2_bytes() {
        Some([b'=', b'=']) => KindAndLen::new(Kind::Neq2, 2),
        Some([b'=', _]) => KindAndLen::new(Kind::Neq, 1),
        _ => KindAndLen::new(Kind::Bang, 0),
    };
    let (kind, len) = kind_and_len.unpack();
    // SAFETY: We peeked at least `len` of ASCII chars above
    unsafe { lexer.advance_bytes(len) };
    kind
});

mod kind_and_len {
    use super::Kind;

    /// Wrapper for `Kind` and `len` stored as a single `u16`.
    /// Hidden in a module to ensure only way to construct is via `KindAndLen::new`.
    #[derive(Clone, Copy)]
    pub struct KindAndLen(u16);

    impl KindAndLen {
        #[inline]
        pub const fn new(kind: Kind, len: u8) -> Self {
            Self(kind as u16 + len as u16 * 256)
        }

        #[inline]
        pub const fn unpack(self) -> (Kind, usize) {
            let len = (self.0 / 256) as usize;
            let kind_id = self.0 as u8;
            // SAFETY: A `KindAndLen` can only be constructed from a valid `Kind`
            // so guaranteed bottom 8 bits represent a valid `Kind`
            let kind: Kind = unsafe { std::mem::transmute(kind_id) };
            (kind, len)
        }
    }
}
use kind_and_len::KindAndLen;

Although, regardless of the implementation, the full version also needs to handle the edge case where last 2 bytes of file are !=:
ascii_byte_handler!(EXL(lexer) {
    lexer.consume_char();
    if let Some(next2) = lexer.peek_2_bytes() {
        let kind_and_len = match next2 {
           Some([b'=', b'=']) => KindAndLen::new(Kind::Neq2, 2),
           Some([b'=', _]) => KindAndLen::new(Kind::Neq, 1),
            _ => KindAndLen::new(Kind::Bang, 0),
        };
        let (kind, len) = kind_and_len.unpack();
        // SAFETY: We peeked at least `len` of ASCII chars above
        unsafe { lexer.advance_bytes(len) };
        kind
    } else {
        // This branch will never be taken unless there's only a single byte left before EOF.
        // So it is a branch, but almost 100% predictable.
        // Use `cold_branch` to further hint that this branch is unlikely to be taken.
        cold_branch(|| {
            if lexer.peek_byte() == Some(b'=') {
                lexer.consume_char();
                Kind::Neq
            } else {
                Kind::Bang
            }
        })
    }
});

Posting cpu instruction counts from local /usr/bin/time/ measurement can be a good start point for these kind of optimizations. CPUs are way too fast these days to see any wall clock differences.

I wasn't aware you could get instruction counts from time. Thought you had to use perf.
But in this case, we're not hoping to reduce instruction count, but to reduce branching. In fact instruction count might go up, but we hope it'll still be faster because straight-line code doesn't result in branch mis-predictions, and the perf hit they incur.
Here can see instruction count for cheapest paths is shorter than the branchless version: https://godbolt.org/z/1Kr87cs73
I don't know if there's a tool which can give stats on branch prediction hits/misses? (CodSpeed apparently doesn't take that into account)

I've unassigned myself here. I couldn't get to the bottom of it, and I don't think I'll have time in the near future to look deeper into it. Also I tried to look at benchmarks locally but I see a lot of noisy variance (up to 25% differences without any change), so I'll probably have to properly tune my workstation to get stable results first.

Totally fair enough.
25% variance on benchmarks! That's completely impossible to work with. That's the thing CodSpeed is really good at - because it's measuring instruction count rather than wallclock time, it's much more stable. But the problem in this case is that CodSpeed has a blind spot on the exact thing we're trying to improve here.


SC layer: Tessellation evaluation shader input interface mismatch errors

This reports errors similar to those reported in issue #106.
A tess control shader with output defined as
layout(vertices=4) out;
layout(location = 0) out vec3 ctrlPosition[];
patch out float ctrlTess;

matched with a tess eval shader with input defined as
layout(location = 0) in vec3 ctrlPosition[];
patch in float ctrlTess;
layout(quads, equal_spacing, ccw) in;

produces the following errors:

[SC] Code 2: Type mismatch on location 0.0: 'ptr to output arr[4] of vec3 of float32' vs 'ptr to input arr[32] of vec3 of float32'

(repeats for each of location 0.0, 1.0, 2.0, 3.0)
followed by

[SC] Code 4: tessellation evaluation shader consumes input location 4.0 which is not written by tessellation control shader

(repeats for each location 4.0 - 31.0)
The tess eval shader explicitly consumes only indices [0]-[3] of ctrlPosition.  It seems like there should ideally be some awareness of the tess control shader's layout(vertices=N) out; setting when validating the interfaces between these stages.

I see what's going wrong here. We discard the outermost array dimension when matching a single vertex interface to an arrayed interface (->TCS, ->GS) but we should also be doing so on /both/ sides of the TCS->TES interface for non-patch variables. The spec describes this -- the layer was just taking a now-invalid shortcut.
Thanks for the bug report, will fix this shortly.

Fix in #206 was merged.


IRGen: Nuke isSILOnly usage

It queried for [transparent] [serialized] definitions and only had an effect
when the module was compiled with -Onone because we remove [serialized]
as part of the optimizer pipeline.
It was causing bad effects when the module we imported from was compiled
with -Onone:
The definition would be marked internal in said module.
and the importing module is compile with -O:
The definition would be marked as available_externally.
because neither would guaranteed the presence of a definition of the
imported symbol available to the importer.
rdar://35100697

@swift-ci Please test

Awesome, thanks!

Thanks for fixing this!


Revert "Use Jetty v9.4.7"

Reverts vespa-engine/vespa#3467
Negative performance impact that needs investigation.
@bjorncs or @baldersheim

Please review after the fact.

👍


[Package Request]: Browser Tamer

Package Requested

[X] I would like someone else to build the manifest.
[ ] I would like help so I can submit the manifest.
[X] I have performed a search and couldn't find this package.
[X] I have checked that the installer for this package is not a standalone or portable executable or a .zip file
[ ] I think there is a new version available and I have provided the URL.

Please provide the following information
Publisher: aloneguid
Publisher Url: https://www.aloneguid.uk/projects/bt/
Package Name: Browser Tamer
Description: Browser Tamer acts as a browser proxy on your machine that catches links you click and redirects them to a browser or browser profile of your choice.
Package Version: 2.5.4
Installer URL: https://www.aloneguid.uk/projects/bt/bin/bt-installer-2.5.4.exe
Current Package Identifier (for new versions):

Nice tool 😉, but there are some issues with the installer:

While the software is installed into C:\Program Files (x86)\BT\, which is in system scope, the Add Remove Program information is written to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Browser Tamer, which is in user scope. It is suggested to keep them aligned by

Change the directory of ARP to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Browser Tamer, or
Change the directory of files to C:\Users\<Username>\AppData\Local\Programs

You can add DisplayVersion to ARP to help WinGet recognize installed version.
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\Browser Tamer" DisplayVersion "2.5.4"
WriteRegStr HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\Browser Tamer" Publisher "aloneguid"

https://nsis.sourceforge.io/Reference/$PROGRAMFILES

Thanks @SpecterShell :) I was going to update the installer but looks like it's already merged in (thanks for spotting it by the way).  I guess the next version then needs to uninstall from system scope and install in user scope.


Tests failed

test_jacobian fails with pytorch=1.6.0=py3.7_cuda9.2.148_cudnn7.6.3_0
======================================================================
FAIL: test_jacobian (main.ConditioningTest)
Traceback (most recent call last):
File "conditioning.py", line 92, in test_jacobian
self.assertTrue(torch.allclose(logdet, logdet_num, atol=0.1, rtol=0.1))
AssertionError: False is not true
======================================================================
FAIL: test_jacobian (main.IResNetTest)
Traceback (most recent call last):
File "invertible_resnet.py", line 149, in test_jacobian
self.assertTrue(torch.allclose(logdet, logdet_num, atol=1.5, rtol=0.1))
AssertionError: False is not true
Any ideas here?

Should be fixed by e76808ca3a65036c00fd3e1ff0a3161e59e8a2af


Map not showing up

Hi, Thanks for the great package. Was just trying to integrate into one of my new project.
Everything configured, but seems the map is not showing up.

You have to enable Google Maps SDK for iOS on your google developer console

Thank you so much @indesignlatam.