Problem reading the access token returned by SimpleIdConnect

Problem
I authenticate with pkce using the the following settings:
const oidcSettings: UserManagerSettings = {
    authority: "https://localhost:56954/",
    client_id: "simpleIdServerWebsite",
    client_secret: "simpleIdServerWebsiteSecret",
    automaticSilentRenew: true,
    scope: "openid profile",
    response_type: "code",
    prompt: "coucou",
    loadUserInfo: true,
    redirect_uri: "https://localhost:44416",
}

Everything seems to be going fine except that the library doesn't seem to detect a succesfull authentication.
The following is not this interesting except for this conclusion
First Investigation
When looking at network activity, it appears that everything goes fine as the accessToken is requested back and returned accurately.
I activated logs in the library and see that the last news I get from it is ResponseValidator:code processed
So it seems that something wrong happens here:
https://github.com/authts/oidc-client-ts/blob/54fda0f58c65d12bf3f25d652eb38fea81d5063f/src/ResponseValidator.ts#L65-L67
Debugging
Debugging your api confirms that the method ResponseValidator.validateSigninResponse receives a very good response with the right information (I checked with jwt.io).
So far so good 👍
💥 The debug fails and ends at the check if the requested authentication is openId by accessing the value of isOpenId
https://github.com/authts/oidc-client-ts/blob/54fda0f58c65d12bf3f25d652eb38fea81d5063f/src/ResponseValidator.ts#L65
Behind the scenes, in this situation, isOpenId is not an attribute but the following property:
https://github.com/authts/oidc-client-ts/blob/54fda0f58c65d12bf3f25d652eb38fea81d5063f/src/SigninResponse.ts#L74-L76
The problem is this one:
the this.scope is not empty, so the split on it is called. But... it is already is an array!

🔍 Let's investigate further...
As everything is strongly typed in this project, of course typescript would not transpile if you assigned an array into a string. Then, the issue must come from the Object.assign (as this method doesn't make any type check behind-the-scenes) on this line of _processCode:
https://github.com/authts/oidc-client-ts/blob/54fda0f58c65d12bf3f25d652eb38fea81d5063f/src/ResponseValidator.ts#L228
When debugging _processCode:
https://github.com/authts/oidc-client-ts/blob/54fda0f58c65d12bf3f25d652eb38fea81d5063f/src/ResponseValidator.ts#L216-L232
By setting a breakpoint before this line:
https://github.com/authts/oidc-client-ts/blob/54fda0f58c65d12bf3f25d652eb38fea81d5063f/src/ResponseValidator.ts#L228
The following reveals:

No further process is done when getting the response to obtain the token:
https://github.com/authts/oidc-client-ts/blob/54fda0f58c65d12bf3f25d652eb38fea81d5063f/src/TokenClient.ts#L103
Conclusion
(FYI, I wrote this ticket at the same time I was investigating, this is why maybe only what follows will be usefull to you 🤣 )
It appears that the authentication server I use (https://github.com/simpleidserver/SimpleIdServer) actually returns an array:

Question
Is it a bug at you side that you don't take in consideration the fact that the authentication server may return the scope by gicing an array?
Or shall I submit an an issue to the author of SimpleIdServer for not following the standard about this response?
(I submitted the issue to SimpleIdServer as well :))
https://github.com/simpleidserver/SimpleIdServer/issues/271

Thanks for the detailed write up!
The array in the response is not typical, though I can't seem to find any wording in rfc6749 that forbids it in the response—the documentation for scope in the response is identical to scope in the authorize request. It's valid to pass multiple scope parameters in the request (e.g. authorize?scope=openid&scope=profile), so it doesn't seem unreasonable that a multivalued scope in the response could be allowed. It seems like the OAuth extensions rfc7662 and rfc8693 do explicitly define that the value in the request's JWT payload is a JSON string, although this shouldn't have much bearing over the access token response format.
Given the ambiguity in the spec, I'd be supportive of a PR here for handling the array response!

The guys of SimpleIdServer agreed that it is a bug (https://github.com/simpleidserver/SimpleIdServer/issues/271) on their side. They are going to fix that, so no need to do something in this library....

The guys of SimpleIdServer agreed that it is a bug (simpleidserver/SimpleIdServer#271) on their side. They are going to fix that, so no need to do something in this library....

Indeed, I saw. For now, I'll integrate a copy of your library in my app with the fix @kherock mentionned till the new version of SimpleIdServer is on nuget.


Error messages from the parser are inconsistent

Rewriting the rule functions should fix this.

Fixed by a133561.


Add support for system keyboard in string/number prompts

Fixes https://github.com/microsoft/pxt-arcade/issues/4845
Adds an optional "use system keyboard" parameter for the "ask for string" and "ask for number" APIs that allows you to type using your actual keyboard and not the in-game one. There will be a corresponding PR in pxt-arcade-sim that has the simulator side of this.
This will require an upgrade rule. Or, if we want, we can deprecate this block and make a new one that always pops the system keyboard.

OMG!  Amazing!!!  Thank you Richard.  This has been a big pain point for teachers getting through the "User Input" curriculum unit.  Much appreciated.


Dribbble's API v2

Are there plans to update it for version 2 of the API?

I didn't notice the v1 wasn't even working anymore! I have to check out the v2 documentation when I have some time but, I was under the impression it required an authentication, which would presumably break this entire project's goal. Do you know more about it?

Hmm. Unless I'm misunderstanding the authentication process, I think it's a showstopper. The very idea of this project was to allow designers with no technical knowledge to set up their sites super easily. I'm gonna have a closer look at it when I can but, I'm not really confident tbh.

Yeah, I figured.
I tried to get the access_token and is not non-coders friendly.

Pity! It was a good run 😛


Triton performance regresses on mixed dtype matrix vector multiplication.

Benchmark: http://ix.io/4G0k
Tip<PHONE_NUMBER>9d964671ebb98f6b94e8efaa0f5636): 88.7 us
old commit (1465b573e8d8e4c707d579092001bcff0f1523ed): 45.9 us
New TTGIR<PHONE_NUMBER>9d964671ebb98f6b94e8efaa0f5636): http://ix.io/4G0h
Old TTGIR (1465b573e8d8e4c707d579092001bcff0f1523ed): http://ix.io/4G09
From talking with @ThomasRaoux , seems like the main causes are 1. convert_layout is now happening later on with a fp32 dtype instead of an int8 one. 2. A broadcast is needlessly happening before a convert_layout

I have just discovered that probably the root cause of https://github.com/openai/triton/issues/2301 is identical to this issue's.
broadcast divisibility 1 causing add_ptr divisibility to drop to 2
Visited: tt.broadcast. Got AxisInfo.divisibility:
divisibility: 1,1,
Operand divisibility: divisibility: 1,1,
getDivisibility[0]: 1
getDivisibility[1]: 1
Joining(0): LHS: 1, RHS: 1
GCD: 1
Joining(1): LHS: 1, RHS: 1
GCD: 1
Visited: tt.addptr. Got AxisInfo.divisibility:
divisibility: 2,2,
Operand divisibility: divisibility: 16,16,
Operand divisibility: divisibility: 1,1,

convert layout divisibility 1 causing add_ptr divisibility to drop to 2
Visited: triton_gpu.convert_layout. Got AxisInfo.divisibility:
divisibility: 1,1,
Operand divisibility: divisibility: 1,1,
getDivisibility[0]: 1
getDivisibility[1]: 1
Joining(0): LHS: 1, RHS: 1
GCD: 1
Joining(1): LHS: 1, RHS: 1
GCD: 1
Visited: tt.addptr. Got AxisInfo.divisibility:
divisibility: 2,2,
Operand divisibility: divisibility: 16,16,
Operand divisibility: divisibility: 1,1,

Reproduction script available in https://github.com/openai/triton/issues/2301


use v5 is treated as a package, not a version number

use v5.14 and use 5.014 both highlight as a version. use warnings highlights as a package.
But use v5 is erroneously interpreted as a package name, not a version.

I have created a branch containing some currently-failing tests to demonstrate the issue
https://github.com/tree-sitter-perl/tree-sitter-perl/tree/gh38


chore(dependencies): allow @nestjs/common 8

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/Nikaple/nest-typed-config/blob/main/CONTRIBUTING.md
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[x] Other... Please describe: Relaxing dependency constraints on @nestjs/common to allow usage with NestJS v8

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information
NestJS v8 release info - https://trilon.io/blog/announcing-nestjs-8-whats-new

@Nikaple - Can you get this merged?


[Minor] Improve English, use better names and data, simplify SQL

What changes were proposed in this pull request?
In general, it is better to use more realistic data and don't use generic names ending in numbers. The SQL also needs to match the amount of data we have in the playground.
Why are the changes needed?
To provide a slightly more realistic example and make SQL easier to understand.
Fix: # N/A
Does this PR introduce any user-facing change?
N/A
How was this patch tested?
Ran commands locally to test.

@qqqttt123 can you please help to review, thanks.


Kernel.warn when using Forwardable delegators with a null object

Subject of the issue
When using Forwardable delegators, if the destination object is a spy, a kernel warning will be emitted of the form:

warning: [Class]#[method name] at [file]:[line] forwarding to private method RSpec::Mocks::InstanceVerifyingDouble#[method name]

Your environment

Ruby version:
rspec-mocks version:

Steps to reproduce
require 'forwardable'
require 'rspec/core'
require 'rspec/mocks'

class ForwardableTest
  extend Forwardable
  def_delegator :@dest, :bar
  def initialize(dest)
    @dest = dest
  end

  def foo
    bar
  end
end

class Injected
  def bar; true; end
end

RSpec.describe 'fowardable behavior' do
  subject { ForwardableTest.new(thing).bar }

  context 'with an object instance' do
    let(:thing) { Injected.new }

    specify { expect { subject }.not_to output.to_stderr }
  end

  context 'with a null object (spy)' do
    let(:thing) { instance_spy('Injected') }

    specify { expect { subject }.not_to output.to_stderr }
  end
end

Expected behavior
Both examples will pass.
Actual behavior
fowardable behavior with a null object (spy) is expected not to output to stderr fails.

Adding an expected result solves this, such as:
instance_spy('Injected', bar: true)

So I think this is an artefact from the forward, as  instance doubles only verify methods which are stubbed, where as the spy mode calls as_null_object where everything returns self, so is more like a method missing call, I think forward is complaining about that

By looking at the implementation, it doesn't look like Forwardable's warning is fair ([1], [2]). I'm not certain if it's Forwardable or instance_spy to blame.
I guess that spy is accepting and records every method call with method_missing. But does it define respond_to_missing? to declare that it does so? Is this sufficient for Forwardable to work and skip this warning?
Are you interested in getting to the bottom of this?
I'd start with an attempt to reproduce the warning with a class defining dynamic methods used as a delegator target.

Our doubles respond_to? true for this case, it seems Forwardable checks theres an actual method with this warning, we don't define that unless you specifically mock out the method, I don't think we want to change that behaviour, and given there is an easy alternative, I'm inclined to close this as a "not something we can fix"


"User" definition in domain model is unnecessary

Minor change in the "Add a domain model" step, where a "User" definition is added, seemingly unnecessarily.
Apologies if this seems pedantic, it's just that it raised questions with several colleagues at my company currently going through this training.

Line of code: https://github.com/sap-tutorials/btp-dev-guidance/blob/aa1e44d6eb7628de1b1f6cb2f31d0b53eb6acdbe/tutorials/build-cap-app/build-cap-app.md?plain=1#L86C3-L86C79

Hi @goncalvesp,
Thanks for your feedback!
I'll take this for discussion with my dev colleagues and get back to you ASAP.
Best regards,
Sveto


New UI missing Sales Settings

Step 1 says to "In the site map, select Sales Settings, and then under Standard settings, select Connect SharePoint"
In my environments, there is no Sales Settings link. I am using v9.1.0000.3842

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

ID: efa7e2da-da89-2fb6-ea96-83eaff6880bc
Version Independent ID: 0cfff3a6-8018-9cef-5aba-a97b62abc5c9
Content: Configure Dynamics 365 for Sales Professional to integrate with SharePoint
Content Source: ce/sales-professional/connect-with-sharepoint.md
Service: dynamics-365-sales
GitHub Login: @shubhadaj
Microsoft Alias: shujoshi

@mhammons : You may not be using the latest Sales Professional app version. Please try installing the latest version and get back to us if you are still unable to see the setting.

@mhammons : Thank you for your feedback. You may not be using the latest Sales Professional app version. Please try installing the latest version and get back to us if you are still unable to see the setting.

Hell9o @shubhadaj - I am currently on v9.1.0000.4046 for CE and it is Sales Professional. The Sales App is v9.0.1903.4006 I believe these are the latest and greatest versions.

@mhammons , can you confirm that you have the system administrator role assigned to you? Meanwhile, I will also check with my team about what could be the possible reason.

@shubhadaj  confirmed, I have Administrator role.

@mhammons: Can you please confirm you are using Sales Professional? Do you have solution 'msdyn_SalesPro' (Dynamics 365 for Sales Professional' installed? If so, what is the solution version?
The version you mention  in earlier comments 9.0.1903.4006 is the latest version of the Sales Hub app (Dynamics 365 for Sales Application), which is different from Sales Professional. This settings feature is available only in Sales Professional, not in Sales Hub.

@bharavar that was the issue....I was using Sales Hub....after installing Sales Professional msdynd_SalesPro I now see the link for Settings.

@mhammons , I am closing this issue as you can see the link for settings now.


Xcode 13 compat improvements

This PR improves #433 by reporting nil values and aborting DFU process.

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


Update to parent pom version 6

Update to version 6 and use new variables for references to covered plugins (clean, install, deploy)

CI build passed:


[LS] Improve record field completions

Purpose
$subject
Fixes #40477
Approach
When there are multiple fields with the same name and same type, show a single completion item for the particular field having a detail of Type1.field1 | Type2.field1.
Samples

Check List

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

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

[x] Increased Test Coverage
[ ] Added necessary documentation

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

type INT int;

type Foo record {|
    int i;
|};

type Bar record {|
    INT i;
|};

public function main() {
    Foo|Bar fb = {}
}

For above case we are getting two suggestions, is that expected?

type INT int;

type Foo record {|
    int i;
|};

type Bar record {|
    INT i;
|};

public function main() {
    Foo|Bar fb = {}
}

For above case we are getting two suggestions, is that expected?

Yes that's expected! We are showing a single completion item for multiple fields only when the type of the fields is exactly the same.


Deploy move2kube workflows and associated resources

Deploy move2kube workflows and associated resources
The broker URL has to be static in the workflow https://github.com/parodos-dev/serverless-workflows/blob/main/move2kube/m2k.sw.yml#L30
The charts for the workflow were taken from https://github.com/parodos-dev/serverless-workflows action output and updated with placeholders, this should be later addressed in the repo https://github.com/parodos-dev/serverless-workflows directly to avoid any manual action

lgtm


Issue with running Tensorflow with OpenCL - Ubuntu 14.04.3 (Trusty) - AMD R5 Radeon M335 GPU

System information
Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):14.04.3-->Trusty
TensorFlow installed from (source or binary):Source
TensorFlow version (use command below):1.0 (Steps-> Downloaded tensorflow from https://github.com/benoitsteiner/tensorflow-opencl, ./configure - to configure project)
Bazel version (if compiling from source):0.4.5
CUDA/cuDNN version:NA
OPENCL Version:
Number of platforms:	1
Platform Profile:	FULL_PROFILE
Platform Version:	OpenCL 2.0 AMD-APP (1800.11)
Platform Name:	AMD Accelerated Parallel Processing
Platform Vendor:	Advanced Micro Devices, Inc.
Platform Extensions:	cl_khr_icd cl_amd_event_callback cl_amd_offline_devices
GPU model and memory:
Platform Name:	AMD Accelerated Parallel Processing
Number of devices:	2
Device Type:	CL_DEVICE_TYPE_GPU
Board name:	AMD Radeon (TM) R5 M335
Memory:	4096M
Exact command to reproduce:
run the python script -- ipython keras_code.py
** G++/GCC version**:
g++-4.9 (Ubuntu 4.9.4-2ubuntu1~14.04.1) 4.9.4
I have compiled CPP programs, they work fine.
More details: Output of Computecpp_info:
ComputeCpp Info (CE 0.1.4)
Toolchain information:
GLIBCXX: 20150426
This version of libstdc++ is supported.
Device Info:
Discovered 2 devices matching:
platform :
device type :
Device 0:
Device is supported : UNTESTED - Device not tested on this OS
CL_DEVICE_NAME : Hainan
CL_DEVICE_VENDOR : Advanced Micro Devices, Inc.
CL_DRIVER_VERSION : 1800.11 (VM)
CL_DEVICE_TYPE : CL_DEVICE_TYPE_GPU
Device 1:
Device is supported : UNTESTED - Device running untested driver
CL_DEVICE_NAME : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
CL_DEVICE_VENDOR : GenuineIntel
CL_DRIVER_VERSION : 1800.11 (sse2,avx)
CL_DEVICE_TYPE : CL_DEVICE_TYPE_CPU
If you encounter problems when using any of these OpenCL devices, please consult
this website for known issues:
https://computecpp.codeplay.com/releases/v0.1.4/platform-support-notes
-- ** Python**: I am using Anaconda distribution Python for 2.7.2. (Anaconda - 2.4.3)
Describe the problem
I have compiled tensorflow, and deployed the same -> No issues here. when I try to run the code I run into the following error:
Segmentation fault (core dumped)
I downloaded the latest code and compiled it from https://github.com/lukeiwanski/tensorflow-opencl. This one gives coredump.
I downloaded the latest code and compiled it from https://github.com/benoitsteiner/tensorflow-opencl. This one gives coredump.
There are challenges installing from tensorflow's main git repo as there seems to be issues on compiling protobuf. I cannot do source compile after cloning from main site.
What I try to do is build a simple LSTM for word embedding.
Read data from files,
Pass it through a NN
I am using Keras as the Functional programming API on top of Tensorflow.
tensorflow-code-throwing-error.txt
Please let me know if there are any fixes or if I can do something to get round this issue.
Thanks and regards
Sayantan

Can you update to the latest version of the ComputeCpp ( 0.2.0 ) ?
As well is there cl_khr_spir in your clinfo?

I have upgraded to ComputeCpp 0.2.0. I also confirm that clinfo does show cl_khr_spir (Extensions).
I am getting the following error while compiling. Any suggestions how can I fix this first?
ERROR: /home/sayantan/Downloads/tensorflow-master/tensorflow/tools/pip_package/BUILD:131:1 undeclared inclusion(s) in rule '@protobuf//:python/google/protobuf/pyext/_message.so':
this rule is missing dependency declarations for the following files included by 'external/protobuf/python/google/protobuf/pyext/descriptor_containers.cc':
'/home/sayantan/anaconda2/include/python2.7/Python.h'
'/home/sayantan/anaconda2/include/python2.7/patchlevel.h'
'/home/sayantan/anaconda2/include/python2.7/pyconfig.h'
'/home/sayantan/anaconda2/include/python2.7/pymacconfig.h'
'/home/sayantan/anaconda2/include/python2.7/pyport.h'
'/home/sayantan/anaconda2/include/python2.7/pymath.h'
....

is that your default python installation location? if so, you should make sure that ./config reflects that
Please specify the location of python. [Default is /usr/bin/python]:

It is my default. Even .configure picks that up.
Please specify the location of python. [Default is /home/sayantan/anaconda2/bin/python]:
Thanks and Regards Sayantan

the files also exist in that location, not sure why compile does not find it. I even upgraded Bazel to latest .5.1 version, still I face the same issue.

Since that happens as well without --config=sycl ( https://github.com/tensorflow/tensorflow/issues/22#issuecomment-306561891 ) it's mostl likely set up issue. Perhaps TF or bazel gets confused about python include paths. Removing one of them should fix the issue.

I will give it a try. Surprising part is when I download from this link https://github.com/benoitsteiner/tensorflow-opencl compilation happens without problem, only I get a segmentation fault :(

https://github.com/benoitsteiner/tensorflow-opencl is quite out-dated ( 4k comments behind )

Ok, I will try to figure out the differences, his build files are quite different from yours, and they simply do not have the same issues with the compile. I am trying to figure out the differences, but the dependencies are quite long. To start with his models.build is not 0 bytes. I understand there might be changes made, but the recent changes in tensorflow build process (happens even with the tensorflow/tensorflow) are hurting my compile. I will see if I can figure that out.

Is there any update on this?

@rahasayantan you might want to try with latest ComputeCpp. Otherwise closing due to lack of activity.


i18n(zh-cn): Update why-astro.mdx

Description (required)

Update why-astro.mdx
Replace the html tag syntax with markdown syntax when using bold

Related issues & labels (optional)

#9240
Suggested label: i18n

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File
Note

zh-cn/concepts/why-astro.mdx
Localization changed, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


[BUG] Flyte console "Status" filter is not working as expected

Describe the bug
When I used the status filter, the behavior is erroneous. If you check the "Failed" box, the console only brings up some of the older failed executions. For example, in our hive.ExampleQueryWorkflow, there have been 2 failed execution on 10/12. If I check the Failed box, the console only brings up the failed executions older than 9/27.
Also, after unchecking the box, the console will not be able to bring back the entire up-to-date list of executions. It doesn't show the latest batch of executions; the latest ones it shows were some of the older executions that started 12 hours ago.
Not sure if this bug only affects the status filter or if all the other filters experience the same bug.
Expected behavior
Using the filter should bring up a correct and up-to-date list of recent executions that satisfy the filter value. Unchecking the filters should bring up the correct and up-to-date list of all recent executions.
Flyte component

[ ] Overall
[ ] Flyte Setup and Installation scripts
[ ] Flyte Documentation
[ ] Flyte communication (slack/email etc)
[ ] FlytePropeller
[ ] FlyteIDL (Flyte specification language)
[ ] Flytekit (Python SDK)
[ ] FlyteAdmin (Control Plane service)
[ ] FlytePlugins
[ ] DataCatalog
[ ] FlyteStdlib (common libraries)
[x] FlyteConsole (UI)
[ ] Other

To Reproduce
Steps to reproduce the behavior:

...
...

Screenshots
Right after entering the workflow view (i.e., the "correct" outcome):

After checking the "Failed" filter box. You can see that the latest failed execution is not shown

After unchecking the filter. You can see that the list doesn't match the correct outcome shown above.

Environment
Flyte component

[ ] Sandbox (local or on one machine)
[ ] Cloud hosted

[x] AWS
[ ] GCP
[ ] Azure

[ ] Baremetal
[ ] Other

Additional context
Add any other context about the problem here.

@bnsblue could this be a dupe of https://github.com/lyft/flyte/issues/539 ?

Looks like Console isn't clearing the token when changing filters, which results in fetching further and further back in the history every time you change a filter.

Fixed by lyft/flyteconsole#105
Available in flyteconsole v0.13.2


[TT-9144] Test jira pr title

TT-9144

 A JIRA Issue ID is missing from your branch name, PR title and PR description! 🦄
Your branch: test-jira-pr-title
Your PR title: Test jira pr title
Your PR description: null
If this is your first time contributing to this repository - welcome!

Please refer to jira-lint to get started.
Without the JIRA Issue ID in your branch name you would lose out on automatic updates to JIRA via SCM; some GitHub status checks might fail.
Valid sample branch names:
‣ feature/shiny-new-feature--mojo-10'
‣ 'chore/changelogUpdate_mojo-123'
‣ 'bugfix/fix-some-strange-bug_GAL-2345'

 A JIRA Issue ID is missing from your branch name, PR title and PR description! 🦄
Your branch: test-jira-pr-title
Your PR title: Test jira pr title
Your PR description: null
If this is your first time contributing to this repository - welcome!

Please refer to jira-lint to get started.
Without the JIRA Issue ID in your branch name you would lose out on automatic updates to JIRA via SCM; some GitHub status checks might fail.
Valid sample branch names:
‣ feature/shiny-new-feature--mojo-10'
‣ 'chore/changelogUpdate_mojo-123'
‣ 'bugfix/fix-some-strange-bug_GAL-2345'

 A JIRA Issue ID is missing from your branch name, PR title and PR description! 🦄
Your branch: test-jira-pr-title
Your PR title: Test jira pr title
Your PR description: null
If this is your first time contributing to this repository - welcome!

Please refer to jira-lint to get started.
Without the JIRA Issue ID in your branch name you would lose out on automatic updates to JIRA via SCM; some GitHub status checks might fail.
Valid sample branch names:
‣ feature/shiny-new-feature--mojo-10'
‣ 'chore/changelogUpdate_mojo-123'
‣ 'bugfix/fix-some-strange-bug_GAL-2345'

 A JIRA Issue ID is missing from your branch name, PR title and PR description! 🦄
Your branch: test-jira-pr-title
Your PR title: Test jira pr title
Your PR description: null
If this is your first time contributing to this repository - welcome!

Please refer to jira-lint to get started.
Without the JIRA Issue ID in your branch name you would lose out on automatic updates to JIRA via SCM; some GitHub status checks might fail.
Valid sample branch names:
‣ feature/shiny-new-feature--mojo-10'
‣ 'chore/changelogUpdate_mojo-123'
‣ 'bugfix/fix-some-strange-bug_GAL-2345'

 A JIRA Issue ID is missing from your branch name, PR title and PR description! 🦄
Your branch: test-jira-pr-title
Your PR title: Test jira pr title
Your PR description: null
If this is your first time contributing to this repository - welcome!

Please refer to jira-lint to get started.
Without the JIRA Issue ID in your branch name you would lose out on automatic updates to JIRA via SCM; some GitHub status checks might fail.
Valid sample branch names:
‣ feature/shiny-new-feature--mojo-10'
‣ 'chore/changelogUpdate_mojo-123'
‣ 'bugfix/fix-some-strange-bug_GAL-2345'

 A JIRA Issue ID is missing from your branch name, PR title and PR description! 🦄
Your branch: test-jira-pr-title
Your PR title: Test jira pr title
Your PR description: null
If this is your first time contributing to this repository - welcome!

Please refer to jira-lint to get started.
Without the JIRA Issue ID in your branch name you would lose out on automatic updates to JIRA via SCM; some GitHub status checks might fail.
Valid sample branch names:
‣ feature/shiny-new-feature--mojo-10'
‣ 'chore/changelogUpdate_mojo-123'
‣ 'bugfix/fix-some-strange-bug_GAL-2345'

    Knock Knock! 🔍

    Just thought I'd let you know that your PR title and story title look quite different. PR titles
    that closely resemble the story title make it easier for reviewers to understand the context of the PR.

    An easy-to-understand PR title a day makes the reviewer review away! 😛⚡

Story Title
Add JIRA check GH action

PR Title
[TT-9144] Test jira pr title

    Check out this guide to learn more about PR best-practices.


Phosphor 2.0

Hello,
Could you please, upgrade package to support Phosphor 2.0.
Thanks

Hey @phaiderh ,
Kindly update the package to ^2.0, to get the benefits of the new icon set.
Thanks to @NikarashiHatsu & @thaqebon for the PRs to get us updated.


Pagination doesn't work with javascript disabled

If you use the pagination component, added in PR #95, and you have javascript enabled, the url will update if you navigate to a page, change the number of results, etc.
If javascript is disabled, and the page is rendered on the server, you always arrive at the first page with the default options.
Ideally, using the same URL should yield the same result with or without javascript support

If javascript is disabled pagination component renders page properly but it doesn't allow to change page.
We wouldn’t start creating our own wrapper around the bootstrap pagination for now, so I've opened an issue on ng-bootstrap to find a way to solve the issue.

ng-bootstrap has closed my issue, they won't do our request.
So if we want fix the problem we should consider other ways.

@atarix83 and @artlowel : The ng-bootstrap team responded to my question on their ticket. We need to provide them with more info on how to reproduce this behavior in a minimal fashion. Then they may reopen the ticket, if they can reproduce.

@artlowel  @tdonohue :
I've tried to provide them more explanations on the ticket.


API Documentation

PR-Codex overview
This PR enhances payment processing features by adding timeout options, error handling, and RPC request/response classes.
Detailed summary

Added TimeoutType enum for specifying operation timeouts.
Created ITimeoutOptions interface for defining timeout options.
Updated IPFSUploadResult struct for IPFS upload details.
Implemented RPC classes for requests, responses, and errors.
Introduced methods for buying with fiat and cryptocurrency.
Included classes for fiat currencies, quotes, and purchase statuses.
Enhanced the ThirdwebClient class for API interactions.

The following files were skipped due to too many changes: Thirdweb/Thirdweb.Pay/ThirdwebPay.GetBuyHistory.cs, Thirdweb/Thirdweb.RPC/ThirdwebRPCTimer.cs, Thirdweb/Thirdweb.Client/TimeoutOptions.cs, Thirdweb/Thirdweb.Pay/Types.GetBuyHistory.cs, Thirdweb/Thirdweb.RPC/ThirdwebRPC.cs, Thirdweb/Thirdweb.Http/ThirdwebHttpResponseMessage.cs, Thirdweb/Thirdweb.Storage/ThirdwebStorage.cs, Thirdweb/Thirdweb.Wallets/InAppWallet/InAppWalletBrowser.cs, Thirdweb/Thirdweb.Http/ThirdwebHttpContent.cs, Thirdweb/Thirdweb.Transactions/ThirdwebTransactionReceipt.cs, Thirdweb/Thirdweb.Wallets/InAppWallet/IThirdwebBrowser.cs, Thirdweb/Thirdweb.Http/IThirdwebHttpClient.cs, Thirdweb/Thirdweb.Transactions/ThirdwebTransactionInput.cs, Thirdweb/Thirdweb.Pay/Types.Shared.cs, Thirdweb/Thirdweb.Http/ThirdwebHttpClient.cs, Thirdweb/Thirdweb.Pay/Types.GetBuyWithFiatStatus.cs, Thirdweb/Thirdweb.Contracts/ThirdwebContract.cs, Thirdweb/Thirdweb.Pay/Types.GetBuyWithFiatQuote.cs, Thirdweb/Thirdweb.Pay/Types.GetBuyWithCryptoStatus.cs, Thirdweb/Thirdweb.Wallets/InAppWallet/InAppWallet.cs, Thirdweb/Thirdweb.Wallets/IThirdwebWallet.cs, Thirdweb/Thirdweb.Wallets/PrivateKeyWallet/PrivateKeyWallet.cs, Thirdweb/Thirdweb.Utils/Utils.cs, Thirdweb/Thirdweb.Pay/Types.GetBuyWithCryptoQuote.cs, Thirdweb/Thirdweb.Wallets/EIP712.cs, Thirdweb/Thirdweb.Transactions/ThirdwebTransaction.cs, Thirdweb/Thirdweb.Extensions/ExtensionTypes.cs, Thirdweb/Thirdweb.Extensions/ThirdwebExtensions.cs

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Codecov Report
Attention: Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.

Project coverage is 90.59%. Comparing base (bb9f506) to head (a0e8305).

Files
Patch %
Lines

...rdweb/Thirdweb.Transactions/ThirdwebTransaction.cs
50.00%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #40      +/-   ##
==========================================
- Coverage   90.66%   90.59%   -0.07%
==========================================
  Files          24       24
  Lines        2903     2903
  Branches      380      380
==========================================
- Hits         2632     2630       -2
- Misses        198      200       +2
  Partials       73       73

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


etnerscan.io

see https://github.com/409H/EtherAddressLookup/commit/475315391418d3721da69f5fdf5066aaff889a4c

Interesting one. One comment: we should probably use only one subcategory.
(The script won't recognize an icon with this subcategory). For a
description we can use the 'description' property.
On a side note, I probably think that Etherscan will fit best as a
subcategory and there's no icon yet for that.
Op 2 sep. 2017 16:54 schreef "H"<EMAIL_ADDRESS>
@409H https://github.com/409h requested your review on:
MrLuit/EtherScamDB#38 https://github.com/MrLuit/EtherScamDB/pull/38
etnerscan.io.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MrLuit/EtherScamDB/pull/38#event-1232355545, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALeroDmspwou-uwB_YoK37OXMZrUWeE6ks5seWwagaJpZM4PK66L
.


New onnxconverter.py issue on MacBook Pro (M1 Pro)

I get an error when building the sam model docker container. Error code 137
When running:
docker build . -t sam:latest

I get this output:
[+] Building 10.3s (13/13) FINISHED                                                                  docker:desktop-linux
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 198B                                                                                0.0s
 => [internal] load build definition from Dockerfile                                                                 0.0s
 => => transferring dockerfile: 826B                                                                                0.0s
 => [internal] load metadata for docker.io/library/python:3.8-slim                                                   0.8s
 => [1/9] FROM docker.io/library/python:3.8-slim@sha256:9187d27fd8f222a181292f24f8e7d6b22419d46bd9cc4506adbdf2dcfae  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 638B                                                                                0.0s
 => CACHED [2/9] WORKDIR /app                                                                                0.0s
 => CACHED [3/9] RUN apt-get update -q     && apt-get install -qy --no-install-recommends wget git libopencv-dev py  0.0s
 => CACHED [4/9] COPY download_models.sh .                                                                           0.0s
 => CACHED [5/9] RUN bash /app/download_models.sh                                                                    0.0s
 => CACHED [6/9] COPY requirements.txt .                                                                             0.0s
 => CACHED [7/9] RUN pip install --no-cache-dir -r requirements.txt                                                  0.0s
 => CACHED [8/9] COPY . ./                                                                                0.0s
 => ERROR [9/9] RUN python3 onnxconverter.py                                                                         9.5s
------
 > [9/9] RUN python3 onnxconverter.py:
9.289 Killed
------
Dockerfile:29
--------------------
  27 |
  28 |     # Add ONNX model
  29 | >>> RUN python3 onnxconverter.py
  30 |
  31 |     EXPOSE 9090
--------------------
ERROR: failed to solve: process "/bin/sh -c python3 onnxconverter.py" did not complete successfully: exit code: 137

Issue fixed. Increased Docker's available memory from 4GB to 8GB.


Start count when click in timer type?

I was use the Pomodoro-Timer and it has a good feature: When click in the timer type, it starts the count.  I think that this helps the use.
Do you like this funcionality?

I think is cool!
This change really accelerate productivity :)
You want to send a PR ? or I can do here =D

@afonsopacifer I never developed using React, but I can try ;)

Do you view my other issue? #12

I did it, hope you guys don't mind

I think this issue can be closed.
cc @afonsopacifer


Allow overlapping catch-all and param segment

Earlier this year, the RFC: Route Overlapping was introduced to enhance the routing flexibility of the router by allowing overlapping of wildcard segments with static segments. The current rules, as outlined in the RFC, are as follows:
Rules

Prioritize the more specific route:

If a catch-all or named route overlaps with a static route segment, the static segment should be prioritized.

Allow only one named or catch-all route to overlap with a static route segment.
Overlapping named parameters and catch-all parameters in the same segment is not allowed.
Each HTTP method has its own tree, so overlapping routes with different methods are allowed.

For example, the following route configurations are allowed:
/*{filepath}
/static

/content/{id}
/content/articles/{id}
/content/news/{id}
/content/events/{id}

Proposition
While supporting overlapping named parameters, such as /users/{id}/book and /users/{name}, presents challenges, this new RFC aims to introduce the capability to overlap catch-all and named parameter segments (overlapping named parameters within the same segment remains prohibited at this stage).
As a result, the following route configurations would be allowed:
/*{filepath}
/{chain}/track

/users/uuid:{id}
/users/uuid:*{any}

New Rules

Static segments are always evaluated first.
A named parameter can only overlap with a catch-all parameter or static segments.
A catch-all parameter can only overlap with a named parameter or static segments.
When a named parameter overlaps with a catch-all parameter, the named parameter is evaluated first.
Each HTTP method has its own tree, so overlapping routes with different methods are allowed.

Priority example
Pattern /users/123/email

Route
Matching order

/users/{id}/email
1

/users/{id}/{action}
2

/users/*{any}
3

Pattern /users/123/revoke

Route
Matching order

/users/{id}/email
no match

/users/{id}/{action}
1

/users/*{any}
2

Pattern /users/123/orders/5

Route
Matching order

/users/{id}/email
no match

/users/{id}/{action}
no match

/users/*{any}
1

Performance comparaison
goos: linux
goarch: amd64
pkg: github.com/tigerwill90/fox
cpu: Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
                    │   old.txt    │               new.txt                │
                    │    sec/op    │    sec/op      vs base               │
StaticAll-16          11.01µ ±  2%    11.13µ ±  0%  +1.08% (p=0.019 n=10)
GithubParamsAll-16    86.16n ±  3%    92.61n ±  2%  +7.49% (p=0.000 n=10)
OverlappingRoute-16   98.58n ±  0%   103.15n ±  1%  +4.64% (p=0.000 n=10)
StaticParallel-16     10.04n ±  8%    10.48n ± 12%  +4.46% (p=0.015 n=10)
CatchAll-16           32.15n ±  1%    32.63n ±  2%       ~ (p=0.086 n=10)
CatchAllParallel-16   5.927n ± 20%    6.111n ± 14%       ~ (p=0.190 n=10)
MultiWriter-16        106.8n ±  1%    103.5n ±  2%  -3.14% (p=0.000 n=10)
geomean               346.1n          350.7n        +1.33%

The impact on performance is expected to be null for static route and minimal for wildcard route.

@tigerwill90 sorry, I didn't take time to review this one 🙈


Early cache invalidation in multistage Docker build

Hello - I'm not sure if this counts more as a question or an issue, as I am not sure if this is intentional or not.
So essentially, when running docker compose to build this project, if there is a change in any of the workspace files, an early build step is rerun, and the cache for all subsequent docker commands is also invalidated for some reason.
For example (from a fresh install):

Run docker compose -f docker-compose.nextjs-app.yml build runner
The cache has not yet been built, so this takes around 180 seconds to build on my machine
Run docker compose -f docker-compose.nextjs-app.yml build runner again
The cache has been built and no files have changed, so the build takes basically no time to finish (as it should)
In apps\nextjs-app\src\pages_app.tsx, add a single character to the comment on line 45 ( * Generally don't enable getInitialProp if you don't need to, ->  * Generally, don't enable getInitialProp if you don't need to.)
Run docker compose -f docker-compose.nextjs-app.yml build runner again
In the first build stage (deps [7/7]), the yarn install --immutable --inline-builds command runs again, and takes 60 seconds to finish (specifically, jumping straight to the yarn 'link step'), and all subsequent commands in all following stages (builder and runner) are no longer cached.

This also occurs when the deps or builder stages are built only (ex. docker compose -f docker-compose.nextjs-app.yml build deps)
This is especially an issue in situations where one would want to create multiple builders/runners for different applications within the same dockerfile, as the 'deps' stage and all further stages would have to be rebuilt after every single change made throughout any of the packages/apps (even though none of the dependencies actually change).
This issue is currently affecting the most recent commit (3952f1603b1bc87eab0c5e1e92b5640cdddacab7) but also affects all of the previous versions I have tested up until now.

I haven't updated the dockerfile since a while and use a different one in prod. I'll see what I can I do next week. I'm open to ideas as well cause I reprends trying a lot of things
Thanks for reporting

I completely forgot.  Have you tried with DOCKER_BUILDKIT=1 ?

Thank you for your response. The example given above was done running with when running the above example on Docker version 20.10.17, build 100c701, with buildkit enabled. I can confirm this happens when running docker on Ubuntu 20.04.4 LTS x86_64, as well as on Docker Desktop for Windows using the WSL2 backend. When I manually disable buildkit, I get the following error:
1 error occurred:
        * Status: the --mount option requires BuildKit. Refer to https://docs.docker.com/go/buildkit/ to learn how to build images with BuildKit enabled, Code: 1

Closing as docker example was reworked recently. Thx


Update OTel packages to GA releases

The OpenTelemetry .NET core packages used in this wrapper are all pre-release packages. A nuget package cannot be published as GA if it contains pre-release dependencies.
The 1.1.0 core packages have been released.
The 1.0.0 instrumentation packages are currently at rc7
We should upgrade to the latest 1.1.0 core packages and 1.0.0-rc7 packages.

A nuget package cannot be published as GA if it contains pre-release dependencies.

Argh, that could complicate things. I could see the upstream instrumentation libraries staying in preview longer. We'll want to chat with 'em about this when we're in our GA push.

For us to do this, we'll need to change our TFMs. Instrumentation for ASP.NET Core is not longer .NET Standard 2.0.
For us to continue supporting .NET Framework, we'll likely need to rip out .NET Standard and just multitarget the .NET versions.

Separating the instrumentation packages into a new project will allow us to create a GA version of our distro.


How to map eventData properties to data explorer using "Ingest data from Event Hub"?

I don't know how to get the properties of the eventData in data ingestion settings.
I used "$.” to get the whole message of the event, but the properties are not in the message.
or is it not supported? if so, will it be supportted in the future? thanks

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

ID: d5808ed2-5d09-4c56-dc0b-4e3650f8fc16
Version Independent ID: 10ebaf9d-0cc0-b59b-ae95-63bc7b1be4b5
Content: Ingest data from Event Hub into Azure Data Explorer
Content Source: articles/data-explorer/ingest-data-event-hub.md
Service: data-explorer
GitHub Login: @orspod
Microsoft Alias: orspodek

@smartczh Thank you for the feedback. We are actively investigating and will get back to you soon.

@smartczh Could you please elaborate your issue.
WHen you say Data Ingestion settings, is this the screen that you are referring to?

Thanks a lot!
Yes, it is. I have been told that this function is not supported currently, but still i will show you the details.
I want to ingest the data which is in the properties field of the EventData class, as shown below:
(refer to https://docs.azure.cn/zh-cn/dotnet/api/microsoft.azure.eventhubs.eventdata?view=azure-dotnet)
We have some valuable info in that.
It is easy to get data in the body field, but I can’t find a way to get the data in the properties field using this Kusto build-in support (ingest from Event Hubs)
(refer to https://docs.microsoft.com/zh-cn/azure/data-explorer/ingest-data-event-hub)
Even I write the column mapping as $. (which means get all data in the json data) To a certain column, like
(.create table TestTable ingestion json mapping 'TestMapping' '[{"column":"Root","path":"$.","datatype":"string"}]')
the data in this column still don’t have the properties data of the EventData class I want.
So how can I get the data in the properties field of the EventData class using this build-in support? Or you have other better ways to do the job?
Thanks a lot !
At 2019-08-06 18:01:34, "Kalyan Chanumolu"<EMAIL_ADDRESS>wrote:
@smartczh Could you please elaborate your issue.
WHen you say Data Ingestion settings, is this the screen that you are referring to?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@smartczh Thank you very much for providing more details.
As you rightly pointed out, this feature is not currently available but already in the request pipeline.
Please upvote for this feature here
The product teams prioritize the features based on the number of votes.
We will proceed to close this issue now.
If there are further questions regarding this matter, please comment and we will gladly continue the discussion.

I am also facing same issue,
we have configured ADX data connection with EH. Some of the header info required to fetch from EvenData.Properties.
But i can read data from message body and system properties but no provision to read properties. I tried in spark streaming and it is working but i want to read from ADX.
Any ideas or suggestions,

+1 I am also looking for getting the properties set on eventData into ADX.
The feature link in @KalyanChanumolu-MSFT's comment is broken. Found the following related feature requests:
https://feedback.azure.com/d365community/idea/5869633b-ec24-ec11-b6e6-000d3a4f0da0
https://feedback.azure.com/d365community/idea/3d789564-0daa-ec11-a81c-6045bd7d1bee
https://feedback.azure.com/d365community/idea/b7ba74c8-2c7b-ed11-a81b-000d3adb7ffd

Please refer to:
https://learn.microsoft.com/en-us/azure/data-explorer/ingest-data-event-hub-overview#event-hubs-properties

Thanks @YaelSchuster, I have seen this before. It is mentioned in the first note on that link that custom properties are not supported. You need to include the values in the body for them to be accessible. I can confirm that it does not work with uncompressed and gzip compressed data.

Ingesting Event Hubs custom properties, used to associate metadata with events, isn't supported. If you need to ingest custom properties, send them in the body of the event data. For more information, see Ingest custom properties.


Add a Graphql implementation of the repo StargazersStream

This PR is adding a Graphql implementation of the repo StargazersStream and solving #120
This also integrated backward pagination and early exit by faking a "since" parameter.
Open questions:

should we replace the existing stream completely? (I lean towards yes, but not sure if it is strictly backward compatible). If we go with yes, then we don't need #121 and can close it.
the graphql endpoint is missing gravatar_id for the user object, is it even worth mentioning? (I lean towards no)

Bonus - I made a few tweaks that seem to improve requests-caching

@edgarrmondragon any thoughts on questions 1 and 2 above?

@edgarrmondragon any thoughts on questions 1 and 2 above?

@ericboucher the schema and replication keys look the same, so the rest and graphql versions only differ in the pagination order?

The replication keys are different owner, repo -> repo_id @edgarrmondragon

@ericboucher I see the primary key will change with the new graphql stream. What do you think of the following plan:

Change the name of the new stream to something like stargazers_graphql
Add a deprecation warning, in the readme and maybe in the code too for the REST version of the stream
Deselect the new version by default (TBD how we handle that)
Release new version with both streams

In a future release we remove the REST version and consider renaming the graphql one.
cc @aaronsteers

@edgarrmondragon not sure I'm a fan since the next release would be yet another breaking change by renaming thisstargazers_graphql to stargazers for consistency.
To be honest, since the previous stream was working so poorly I think it's reasonable to introduce this one and override the previous one directly. Maybe we can add a warning in the code on this streams initialization? Is there a way to force the target to drop existing tables / update indexes?

@edgarrmondragon @aaronsteers I followed your suggestion and used the same partition keys so that we can "safely" override the REST stream completely. Which I did in the end.
The breaking id changes should happen in https://github.com/MeltanoLabs/tap-github/issues/122
Please have a final look and let me know what you think.
cc @laurentS for final thoughts as well

To be honest, since the previous stream was working so poorly I think it's reasonable to introduce this one and override the previous one directly. Maybe we can add a warning in the code on this streams initialization? Is there a way to force the target to drop existing tables / update indexes?

I don't think there's any defined behaviour on the target side, each target can do pretty much anything with the data, at least from the singer spec perspective, which just defines the interface between tap and target.
But I'd agree with the view that the current stream is behaving poorly. Also, taking into account the number of stars on this repo (5, of which 2 are commenting on this PR and 1 is with Meltano), I'd think it's fair to assume the number of users is very low (and those actually using this stream even lower).
Considering the sort of problems an unstable PKey can bring (see #110 and #112), I'd be in favour of simply replacing the old stream with the new one (and stable keys), with a big fat warning in the logs on init. As an option, rename the old stream stargazers_rest and keep it with a deprecation warning for a bit longer, so that on the off chance that someone is actually using the stream, they have an easy fix.

Is it easy to use a stream with another name? Eg. use stargazers_rest but still write to a stargazers table? Is this something meltano-cli provides @edgarrmondragon ?

Is it easy to use a stream with another name? Eg. use stargazers_rest but still write to a stargazers table? Is this something meltano-cli provides @edgarrmondragon ?

@ericboucher the SDK comes with stream renaming out of the box: https://sdk.meltano.com/en/latest/stream_maps.html#aliasing-a-stream-using-alias


update conus404 dataset names in intake catalog for conus404 explore …

…notebooks

I know these notebooks will probably be getting replaced, but trying to keep them functional in the meantime


findSDRPlay should not stop stream

When the device is streaming and findSDRPlay is called (which might be due to various reasons, esp. when running under SoapyRemote), the stream is stopped.
Here, I propose to instead just ignore the call and return no devices:
https://github.com/SDRplay/SoapySDRPlay/blob/master/Registration.cpp#L76
Patch (feel free to change, if accepted):
diff --git a/Registration.cpp b/Registration.cpp
index db02814..71c6a33 100644
--- a/Registration.cpp
+++ b/Registration.cpp
@@ -73,8 +73,8 @@ static std::vector<SoapySDR::Kwargs> findSDRPlay(const SoapySDR::Kwargs &args)

    if (activeStream)
    {
-      SoapySDR_log(SOAPY_SDR_WARNING, "findSDRPlay() called while the device is streaming. Deactivating stream.");
-      activeSoapySDRPlay->deactivateStream(activeStream, 0, 0LL);
+      SoapySDR_log(SOAPY_SDR_WARNING, "findSDRPlay() called while the device is streaming. Ignoring request.");
+      return {};
    }

    if (deviceSelected)

@fmoessbauer - Thanks Felix for reporting this issue. I just fixed it as you suggested.
Please give it a try and let me know.
Franco

Hi @fventuri , just tested the latest master and my use-case now works. Thanks!


Fix var names per new TC

This PR fixes the names of the taxcalc class variables in get_micro_data.py to correspond with changes in the Tax-Calculator.

This PR ensures OG-USA compatibility with TC after PR #1303.


Keep existing compats fixed

Added the ability to keep any current compats in place. Solves #5.
Because I feel this behaviour should be the default, and have as such made the keyword argument keep=true by default, this is a breaking change and merits updating to version 0.3.0.

Do you think this is ready to be merged?

Do you think this is ready to be merged?

I do, but do you think this is (all) a good idea?

Looks good to me. I will merge and test it before making a new release...


Incorporate sc-std in this package

[x] Migrate massa-sc-std to this repo.
[ ] Add an issue on massa-sc-std to update the readme to reference this new project
[x] Add an issue on massa-sc-std to delete the repo after some time: https://github.com/massalabs/massa-sc-std/issues/44

Only one sub-task remaining, and maybe we should transfer open issues of std into this sdk


Added support for some of the missing joint parameters

Related to jrouwe/JoltPhysics#555.
This PR aims to add support for some of the missing joint parameters, like springs and soft limits, using the currently work-in-progress feature/stiffness_and_damping branch in Jolt:
Here's a complete list of the parameters/flags that are currently missing, as well as what their current status is:
Legend

✅ Supported in this PR
⏳ Not yet supported in this PR
⚖ Might be supported in this PR
🚫 Won't be supported in this PR
🩹 ... using JPH::SixDOFConstraint
❓ Unknown/uncertain

PinJoint3D

⚖🩹 PIN_JOINT_BIAS
⚖🩹 PIN_JOINT_DAMPING
⚖🩹 PIN_JOINT_IMPULSE_CLAMP

HingeJoint3D

🚫 HINGE_JOINT_BIAS
⏳ HINGE_JOINT_LIMIT_BIAS
⏳ HINGE_JOINT_LIMIT_SOFTNESS
⏳ HINGE_JOINT_LIMIT_RELAXATION

SliderJoint3D

⏳ SLIDER_JOINT_LINEAR_LIMIT_SOFTNESS
⏳ SLIDER_JOINT_LINEAR_LIMIT_RESTITUTION
⏳ SLIDER_JOINT_LINEAR_LIMIT_DAMPING
⏳ SLIDER_JOINT_LINEAR_MOTION_SOFTNESS
⏳ SLIDER_JOINT_LINEAR_MOTION_RESTITUTION
⏳ SLIDER_JOINT_LINEAR_MOTION_DAMPING
⚖🩹 SLIDER_JOINT_LINEAR_ORTHOGONAL_SOFTNESS
⚖🩹 SLIDER_JOINT_LINEAR_ORTHOGONAL_RESTITUTION
⚖🩹 SLIDER_JOINT_LINEAR_ORTHOGONAL_DAMPING
⚖🩹 SLIDER_JOINT_ANGULAR_LIMIT_UPPER
⚖🩹 SLIDER_JOINT_ANGULAR_LIMIT_LOWER
⚖🩹 SLIDER_JOINT_ANGULAR_LIMIT_SOFTNESS
⚖🩹 SLIDER_JOINT_ANGULAR_LIMIT_RESTITUTION
⚖🩹 SLIDER_JOINT_ANGULAR_LIMIT_DAMPING
⚖🩹 SLIDER_JOINT_ANGULAR_MOTION_SOFTNESS
⚖🩹 SLIDER_JOINT_ANGULAR_MOTION_RESTITUTION
⚖🩹 SLIDER_JOINT_ANGULAR_MOTION_DAMPING
⚖🩹 SLIDER_JOINT_ANGULAR_ORTHOGONAL_SOFTNESS
⚖🩹 SLIDER_JOINT_ANGULAR_ORTHOGONAL_RESTITUTION
⚖🩹 SLIDER_JOINT_ANGULAR_ORTHOGONAL_DAMPING

ConeTwistJoint3D

⚖🩹 CONE_TWIST_JOINT_BIAS
⚖🩹 CONE_TWIST_JOINT_SOFTNESS
⚖🩹 CONE_TWIST_JOINT_RELAXATION

Generic6DOFJoint

✅ G6DOF_JOINT_FLAG_ENABLE_ANGULAR_SPRING
✅ G6DOF_JOINT_FLAG_ENABLE_LINEAR_SPRING
⏳ G6DOF_JOINT_LINEAR_LIMIT_SOFTNESS
⏳ G6DOF_JOINT_LINEAR_RESTITUTION
⏳ G6DOF_JOINT_LINEAR_DAMPING
✅ G6DOF_JOINT_LINEAR_SPRING_STIFFNESS
✅ G6DOF_JOINT_LINEAR_SPRING_DAMPING
⏳ G6DOF_JOINT_LINEAR_SPRING_EQUILIBRIUM_POINT
⏳ G6DOF_JOINT_ANGULAR_LIMIT_SOFTNESS
⏳ G6DOF_JOINT_ANGULAR_DAMPING
⏳ G6DOF_JOINT_ANGULAR_RESTITUTION
❓ G6DOF_JOINT_ANGULAR_FORCE_LIMIT
⏳ G6DOF_JOINT_ANGULAR_ERP
✅ G6DOF_JOINT_ANGULAR_SPRING_STIFFNESS
✅ G6DOF_JOINT_ANGULAR_SPRING_DAMPING
⏳ G6DOF_JOINT_ANGULAR_SPRING_EQUILIBRIUM_POINT

CC: @jrouwe

I'm not sure if you'd prefer to keep the conversation in the issue on your end, @jrouwe, or if it's alright to do it here as well, but when going through the list of parameters I was unsure what the deal was with HINGE_JOINT_LIMIT_BIAS and G6DOF_JOINT_ANGULAR_FORCE_LIMIT.
You mentioned that the hinge should probably be implemented using the "softness * relaxation and softness * damping" method, but there's no damping there as far as I can tell, unless HINGE_JOINT_LIMIT_BIAS is the damping somehow.
I don't think we touched on G6DOF_JOINT_ANGULAR_FORCE_LIMIT. It's described as "The maximum amount of force that can occur, when rotating around the axes." in Godot's documentation.
(Also, forgive this one-off force push, I'll try to keep the commit history somewhat sane to allow for easier incremental reviews.)

Hello,
As far as I can see HINGE_JOINT_LIMIT_BIAS = stiffness and HINGE_JOINT_LIMIT_RELAXATION = damping (in the current godot version that ignores softness, if you want to do it correctly I think you need to multiply both with the softness)
I will look into G6DOF_JOINT_ANGULAR_FORCE_LIMIT and your changes tomorrow.

I pulled out some of the refactoring that had no business being in this PR to begin with, which necessitated another force-push. Hopefully that should make the changes a lot easier to grok.
I'll be adding the changes to HingeJoint3D later today.

Regarding G6DOF_JOINT_ANGULAR_FORCE_LIMIT and G6DOF_JOINT_ANGULAR_MOTOR_FORCE_LIMIT:
What the code does is to first detect if the motor is outside of the angular imits and use that to calculate the actual angular impulse
So basically:

If G6DOF_JOINT_ANGULAR_MOTOR_TARGET_VELOCITY is set then G6DOF_JOINT_ANGULAR_MOTOR_FORCE_LIMIT is used as the motor force limit.
If, however, the limits are violated, the motor is turned off and instead a spring to enforce the limits is activated. G6DOF_JOINT_ANGULAR_FORCE_LIMIT is the max force that it will apply in that case.

Jolt doesn't really work that way as it will keep the motor active and enforce the limits at the same time (meaning the motor will push until the limit force is big enough to counteract the motor). I personally think that that is more consistent as turning the motor off will give a discontinuity: the motor will push the constraint past the limits, instantly turn off, spring returns the constraint within the limits again, motor instantly turns on, pushes constraints past limits etc.
What goes where:

G6DOF_JOINT_ANGULAR_MOTOR_FORCE_LIMIT - this goes into the motor settings for the velocity motor. You've already implemented this in the right way.
G6DOF_JOINT_ANGULAR_FORCE_LIMIT - Jolt doesn't support a min/max force for limit springs yet. It's not hard but I feel it's quite a fringe case where you would want to use this.

Great, thank you for taking a closer look at it. I agree that the inconsistency there seems a bit jarring. It sounds like G6DOF_JOINT_ANGULAR_FORCE_LIMIT is staying unsupported then.

I've been treading water with this for a bit now, as the soft limits for HingeJoint3D are proving difficult for me to translate.
For reference, here are the ranges (enforced in the editor) and default values (which I sadly can't change) of these properties:

HINGE_JOINT_LIMIT_BIAS

Min: 0.01
Max: 0.99
Step: 0.01
Default: 0.3

HINGE_JOINT_LIMIT_RELAXATION

Min: 0.01
Max: 16.0
Step: 0.01
Default: 1.0

HINGE_JOINT_LIMIT_SOFTNESS

Min: 0.01
Max: 16.0
Step: 0.01
Default: 0.9

So HINGE_JOINT_LIMIT_BIAS is a factor in both Godot 3 and Godot 4, and I'm not entirely sure how I can map this to Jolt's stiffness. Multiplying it by some arbitrary value, which after some experimentation seems to be in the millions, and then passing it on as mStiffness, makes it behave close-ish to what I can see in Bullet, as this factor doesn't seem immune to changes in mass there either. Once you start messing with the damping this "calibration" sort of goes out the window though.
HINGE_JOINT_LIMIT_RELAXATION is apparently described in Godot's documentation as "The lower this value, the more rotation gets slowed down", which to me sounds like the inverse of how damping behaves, and seems to reflect how it behaves at runtime in Bullet. This confuses me quite a bit, considering the name and value range of this property, so I'm again not sure how to map this to Jolt's damping.
Could I be missing something here, or is this just an unfortunate discrepancy between these two worlds?
It wouldn't be the end of the world to leave these as unsupported and instead implement them for the eventual custom nodes later instead.

Unfortunately, I don't have much to contribute to this question. However, I wanted to express that, from my perspective, I would definitely utilize the "custom Jolt nodes" if they were available. It would be wonderful to be able to use frequency and damping directly and to have nodes that map more directly to the Jolt joint constraints.

I see I didn't look closely enough:
real_t amplitude = ((angVelB - angVelA).dot(axisA) * m_relaxationFactor + m_correction * (real_t(1.) / p_step) * m_biasFactor) * m_limitSign;

real_t impulseMag = amplitude * m_kHinge;

or
torque_impulse = -m_kHinge * m_biasFactor / p_step * x - m_kHinge * m_relaxationFactor * v

so
torque = -m_kHinge * m_biasFactor / p_step^2 * x - m_kHinge * m_relaxationFactor / p_step * v

so
jolt_stiffness = m_kHinge * m_biasFactor / p_step^2
jolt_damping = m_kHinge * m_relaxationFactor / p_step

m_kHinge is calculated like this during setup:
Vector3 axisA = A->get_transform().basis.xform(m_rbAFrame.basis.get_column(2));
m_kHinge = 1.0f / (A->compute_angular_impulse_denominator(axisA) + B->compute_angular_impulse_denominator(axisA));

So a function of the hinge axis and the inertias of both bodies.
These formulas are actually very close to what Jolt uses for the frequency and damping and I think:
(2 * pi * frequency)^2 = m_biasFactor / p_step^2
4 * pi * frequency * damping = m_relaxationFactor / p_step

So I think you can also keep the spring in freq/damping mode and calculate the frequency and damping using these formulas.
(and I probably made a math mistake somewhere here)

Hello,
I've been going over the math again and I cannot spot my mistake. If the godot version doesn't behave well then I can understand that Jolt also doesn't if it uses the same math.
I looked at the Bullet source code and that implementation seems to be completely different (I find it hard to follow though). It looks like the formula goes like:
torque_impulse = -m_kHinge * m_biasFactor * max(0.2 / p_step * x,  m_relaxationFactor * v) - m_kHinge * 1.0 * v

(I've simplified this a bit by omitting some details when hitting the lower vs the upper limit)
The relaxation factor is only used when the velocity v is bigger than the position error x (multiplied by some constants). The purpose of the relaxation factor seems to be to make the hinge bounce against the limits (equivalent of the restitution). The damping factor is hardcoded to 1 (m_damping is not set in the block of code you mentioned and when debugging I saw it defaults to 1) and the 0.2 is the global ERP factor which is also not overridden by godot.
I think we have to leave out relaxation as Jolt doesn't support that max operation, that leaves us with:
jolt_stiffness = m_kHinge * m_biasFactor * 0.2 / p_step^2
jolt_damping = m_kHinge / p_step

And in frequency damping terms:
(2 * pi * frequency)^2 = m_biasFactor * 0.2 / p_step^2
4 * pi * frequency * damping = 1 / p_step

or:
frequency = sqrt(m_biasFactor) / (2 * pi * sqrt(5) * p_step)
damping = 1 / (4 * pi * frequency * p_step)

I have no idea how accurate this is going to be....

Thinking about it some more, I think we could also approximate max(a, b) with a + b to get:
jolt_damping = m_kHinge * (1 + m_relaxationFactor) / p_step

or:
damping = (1 + m_relaxationFactor) / (4 * pi * frequency * p_step)

Formula 2
frequency = sqrt(m_biasFactor) / (2 * pi * sqrt(5) * p_step)
damping = 1 / (4 * pi * frequency * p_step)

This one is actually kinda scary how close it is to Bullet. I had to double-check to make sure I hadn't mixed up the files at first. So I would say you nailed the accuracy in terms of matching Bullet at least.
There looks to be a bit more bounce at the limits in the Bullet one, which I guess might be explained by the missing relaxation component in this particular formula, but honestly this would be Good Enough™ in my book. I had no illusions about perfect parity, and this is better than I could have imagined.
Bias
https://github.com/godot-jolt/godot-jolt/assets/4884246/d84beeef-1484-4f3f-90ee-5e67e76590f6
Relaxation
(No video showing relaxation since that isn't incorporated.)
Formula 3
frequency = sqrt(m_biasFactor) / (2 * pi * sqrt(5) * p_step)
damping = (1 + m_relaxationFactor) / (4 * pi * frequency * p_step)

The relaxation here seemingly ends up inverted again, where a higher relaxation erroneously results in more damping, which ends up affecting both tests by the looks of it.
Bias
https://github.com/godot-jolt/godot-jolt/assets/4884246/e173728f-3691-4160-882b-0ce45c45430f
Relaxation
https://github.com/godot-jolt/godot-jolt/assets/4884246/b138a2aa-019b-43b8-a46a-38c4101bad6d
Formula 4
frequency = sqrt(m_biasFactor) / (2 * pi * sqrt(5) * p_step)
magic = 1 - (m_relaxationFactor / 16)
damping = magic / (4 * pi * frequency * p_step)

This is a caveman attempt on my part, with no real basis in reality, but I was curious to see what it would look like if the dividend somehow ended up being an inverse factor of the relaxation.
I think the result are somewhat interesting. The bias test stays close to the results of formula 2, while still ending up with a relaxation that achieves something resembling an inverse damping, even if it doesn't really look anything like what Bullet produces.
I have no idea how you'd achieve this "correctly" though.
Bias
https://github.com/godot-jolt/godot-jolt/assets/4884246/68439c48-2f66-4549-8a3f-53ea5dbec89b
Relaxation
https://github.com/godot-jolt/godot-jolt/assets/4884246/ccdee8aa-84ca-4402-9cdb-73a32b24b777
Summary
All-in-all, I'd be perfectly fine with settling for formula 2 and just leaving relaxation unsupported, unless you have more ideas.

I think you should go for formula 2 indeed. I think the fact that the relaxation isn't working is because I oversimplified the formula: The relaxation is only applied when the body is moving towards the limit and not away, this is not something you can replicate with the current Jolt implementation.
I cannot find any documentation (neither in godot, bullet or anywhere else on the internet) what the physical meaning of 'bias' and 'relaxation' is, so to me these are just confusing numbers.
I also looked at PhysX's PxRevoluteJoint limit settings and they use stiffness and damping just like Jolt but have an extra 'restitution' property to make limits bouncy. Maybe I'll add that too one day (and maybe it can be related to relaxation somehow).

Apologies for letting this PR sit inactive for so long. With summer rolling around I've had to slow things down a bit, which has made more time-consuming tasks like this one tricky to fit into my short bursts of work.
With that said, I've also felt very conflicted about how to proceed with these changes.
To start with, it turned out that formula 2 for the hinge joint soft limits didn't actually work as well as I thought it did. By some stroke of luck it turned out that Jolt (with formula 2) and Bullet just happened to align in behavior at the particular timestep (240 hz) that I was using in the test project. Once I changed that to something like 60 hz they deviated from eachother quite a bit. This was however seemingly fixable by simply hardcoding the timestep into the formula, so that it became something more like to this:
frequency = sqrt(m_biasFactor) / (2 * pi * sqrt(5) * (1 / 240))
damping = 1 / (4 * pi * frequency * (1 / 240))

After some further tweaking to this (now magic) constant, to better match Bullet, I ended up with something closer to (1 / 300). Obviously this change didn't feel very sensible though.
On top of this I've spent a little bit of time in the last few weeks trying to make sense of the (linear) soft limits for the slider and 6DOF joints, using a similar test project as what I used for the hinge limits, and I can safely say at this point that I don't understand them even a little bit. Out of the three parameters (softness, restitution and damping) the only one that doesn't seem to explode the joint at anything but the default value is softness. This applies to both Bullet and Godot Physics, weirdly enough.
With all that in mind, as well the whole thing about these parameters not seeming to have any real physical meaning, I'm feeling much less inclined to actually add support for the default joints' soft limits. I'm also worried that they might do more harm than good, since there's no way of actually disabling the soft limits with the parameter ranges that Godot uses. So all hinges, sliders and 6DOF joints would effectively be using soft limits at all times, which I feel demands that they are sensible and reliable. Those are not words I would use to describe their current state in either of the two reference implementations.
Once Godot 4.1 is released in the coming days that will (hopefully) unlock some things that I've been waiting for in order to implement the custom Jolt joints properly, so I will likely be doing a focused effort in the coming few weeks to add all that stuff, as well as figuring out some solution for the C# part of it. These will obviously use the more sensible frequency/damping interface for springs and soft limits, as well as add other useful features, like breakable joints and the ability to override the solver iterations on a per-joint basis.
I've gone ahead and pulled out the 6DOF springs from this PR (#478) and instead replaced it with the code for the hinge joint stuff, in case anyone is curious what that looked like. I also added support for spring equilibrium (target position/rotation) as part of #478, which seemed to work well enough. I'm not entirely sure if that rotation order thing is anything to worry about, but seeing as how Godot Physics doesn't implement this at all right now there's technically no compatibility to worry about anyway.
Anyway, please let me know if you have any objections to abandoning the soft limits for the default Godot joints, @jrouwe. Clearly this aspect of the Jolt integration has proven to be beyond my capabilities anyway, so I'm at the mercy of whatever support you can offer either way.

Thanks for the update! I will take another look at it. I know the creator of Bullet, so I may just send him an e-mail to ask what these numbers are supposed to mean.

I've been looking at this again, and I think you're right that we should just leave these parameters for now and have Jolt use hard limits for the default constraints. The parameters seem to be inconsistently implemented between Godot 3, 4 and Bullet and across the different constraint types, so it is going to be very difficult to implement this.

Thank you for taking yet another look at it. I really appreciate it.
It seems like 4.1 is right around the corner, so I might take a crack at the custom nodes this week even. Once I get going I would imagine they'll be implemented in fairly quick succession.
I'll go ahead and close this PR. Thanks again!


typo in environment creation

Great looking tutorial. Just a small typo in the environment setup of README.md.
conda create env ...  should be condo env create ...

Fixed! Thanks a lot 👍

Great. Also in the README.md file here:
https://github.com/leriomaggio/deep-learning-keras-euroscipy2016#recreate-the-conda-environment


Improvement for k8s.io/docs/reference/setup-tools/kubeadm/kubeadm/

No instructions or link on how to install Kubeadm for newbies

Thanks for the suggestion @adic26
/kind feature
/language en

PRs welcome to link from that page to: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
thanks
/sig cluster-lifecycle


gh my prs fails if a repo does not have status checks

bsh ❯ gh my prs -a
template: :9:31: executing "" at <.statusCheckRollup.state>: nil pointer evaluating interface {}.state

This is because of https://github.com/quotidian-ennui/jubilant-octo-journey/pull/2 since that repo does not have an status checks or workflows associated with it.

It actually illuminated a bad copy-pasta error which would have meant things didn't work anyway.
https://github.com/quotidian-ennui/gh-my/blob/c5330aa9c8d4e387efb11fa3f80cbf56c1742581/includes/query_prs#L22-L32
is basicaly wrong, because it should really be .reviewDecision where it has .statusCheckRollup.state


[Feature request] Support for touch screen device

Nowadays most of the people browse the web on touch screen device.
So, it would be nice if you add this feature.

Any updates on this feature request? If added, it will be a nice feature all will love.


feat(tauri) webview user_data added to AppBuilder api

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] Feature
[ ] New Binding Issue #___
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes. Issue #___
[x] No

The PR fulfills these requirements:

[x] It's submitted to the dev branch and not the master branch

This feature allows the application (user) to pass in a user_data value through to the webview where it can be later accessed via the webview.get_user_data() apis

Said argument replacement is partially happening with the new bindings. We can talk about details on Discord.

Closing it since we're going to implement it differently with the new bindings.


Small refactoring

Thanks! I did some additional changes, as those Exceptions should be thrown, so the image loading could fail if wrong color format is provided.


rootless: Fix rangeUID parsing

rangeUID should be parsed as ids[2] rather than ids[1]
Fixes: #2173
Signed-off-by: Li Yuxuan<EMAIL_ADDRESS>

related to https://github.com/kata-containers/runtime/issues/2132
cc @jodh-intel

/test


Gender should be optional

When working with #558 I noticed that we ask for gender from the get-go, and we offer three options (Male, Female & Diverse). Now that I'm working on #576 I see that we show it in Profile, and it makes me wonder as to the reason for the requirement.
I'm hoping that choosing Gender shouldn't affect the UX of a new sign-up, and if that's the case, I propose we remove it as a required field and instead we offer it as just another field they can feel IF they want to. Based on #220 it seems like we don't display it on the third option, but that comes as bad UX if that's the case for 2.0.
And one less thing to ask during Sign Up would lower the chances of a user thinking filling a long form is too much hassle.
Hope I make sense.

When working with #558 I noticed that we ask for gender from the get-go, and we offer three options (Male, Female & Diverse). Now that I'm working on #576 I see that we show it in Profile, and it makes me wonder as to the reason for the requirement.

My main reason: I want to address males as Mr. X and females with Mrs. X in an email. But because we live in 2019 we have to have the third option too. For inclusion and because it is the right thing to do.
Maybe it doesn't make a difference in the WebGUI. But we need the information.

I'm hoping that choosing Gender shouldn't affect the UX of a new sign-up, and if that's the case, I propose we remove it as a required field and instead we offer it as just another field they can feel IF they want to.

We need to ask for it in the sign up to have the right greeting in the first email. It's one of the things I want to make better than the other players.

And one less thing to ask during Sign Up would lower the chances of a user thinking filling a long form is too much hassle.

I know what you mean. I had the same idea and thought that we could make it a radio button with male or female as the default. By that we have a 50% chance that the user doesn't have to enter more data.

I'm all in for the third option, as someone that has friends that would pick the third one. Kudos for that. However, I'm more focused on the need to ask the user to pick before they reach a screen where other personal information is asked. As gender should not be a big deal.
I just created an account, and noticed that we're not using Mr. or Mrs. X - and I think that the absence of it is not a big deal, especially since I have not provided you with information that could change that, such as a PhD. What about, let's say, Doctors ? Wouldn't they be Dr. for both in English? In spanish we have distinction between genders, but in English they don't.
If it's about formality, we could show the full name in the email instead of prefixing my name with "Mr.".
My suggestion is to move the gender selection one screen, right after the user clicks the confirmation email. That way those that don't agree with the three options can ommit to fill it and all is good. And if they choose to pick diverse show it instead of hiding it. If they gave us that piece of information, they want it to be seen at that point.
I see more positives than negatives at that point to remove Gender as a required field for Sign Up.

I just created an account, and noticed that we're not using Mr. or Mrs. X

Not in English. But in German. Here's an email I received today:

So it's language dependent. In some languages it is ok to address somebody with the first name and others are more complicated.

If it's about formality, we could show the full name in the email instead of prefixing my name with "Mr.".

It's about doing it right and sending a signal that we care.
I see your workflow point but this one is important for me. In German it makes a big difference if I address somebody correctly or not. I want the very first email to be as good as possible.
By the way: The signature changes depending on the weekday too. Wishing users a great weekend when it makes sense.

I see more positives than negatives at that point to remove Gender as a required field for Sign Up.

I see your point and we might loose people over this but this one is dear to my heart.
In case people don't want their gender to be stored: It hasn't happened yet. At least I didn't get any feedback about this. And I did get feedback that it was unfair to have "male" as the default in the drop down select field. That's the reason that field doesn't have a default in v1.1. But I'm open to an improvement - that people can deactivate it - in version 2.1 for this.


Second call to message disposition in ModeSecond hangs

Calling AcceptMessage() on the same message twice in a row hangs on the second call.

Fixed in upcoming v0.17.0 release.


Change defaults of the open LDAP properties

Change defaults of the open LDAP Group Member User Attribute & Group DN Field
https://github.com/rancher/rancher/issues/6435

All test failures unrelated- caused by failed to download/schedule instances
@alena1108 can you review the pr

LGTM


Add an option to open NERDTree in current window

In a multi-window workflow, it's often desirable to make NERDTree to
work in the current window instead of its side window. See issue #244
for brief discussion.
Currently it's possible to use :e <dir> to achieve this for
:NERDTree command; but there are no workarounds for other functions
like opening bookmark, toggling nerdtree, finding current file, etc.
This commit adds an option to render NERDTree in current window instead
of side window, and modifies all relevant commands to respect the
option.

This is not a pull request I want to merge.
We're trying not to add any more global options.  So, I suggest that you add this functionality by extending the NERDTree with a plugin for your own private use.  This PR adds a lot of code, which is no good for an already bloated project.
I don't mean to be harsh, but this is not the direction in which I want the NERDTree to go.  Feel free to submit PRs in the future.  Bug-fixes are especially welcome at this time.


Feature Request: display current value when command starts with :set

Using :set <partialsearch>  gives setting names as completion options.
Would it be possible to also add the current value as a 'preview', basically whatever :set name? would tell you.

I think it's already can...? (In my environment, :set virtualedit=| will only show the completion item that virtualedit=all.

Once you get to the other side of the = it will autocomplete non-boolean values, but I was thinking something more like this screenshot (from the tridactyl vim-like browser):

Where, after you type set it starts to show you the list of settings that match the text typed so far, but also shows the current value for that setting (it also shows possible setting values or their js type and a help string). I found it helpful to add context to the settings when you're not quite sure what you are looking for, similar to when a file shows a preview.


fix: array coverity hits

Description
Addresses 2 array hits in coverity.

PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.
You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).
Checklist to comply with before moving PR from draft:
PR completeness and readability

[ ] I have reviewed my changes thoroughly before submitting this pull request.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have updated the documentation to reflect the changes or created a separate PR with update and provided its number in the description, if necessary.
[ ] Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
[ ] I have added a respective label(s) to PR if I have a permission for that.
[ ] I have resolved any merge conflicts that might occur with the base branch.

Testing

[ ] I have run it locally and tested the changes extensively.
[ ] All CI jobs are green or I have provided justification why they aren't.
[ ] I have extended testing suite if new functionality was introduced in this PR.

/intelci: run

CI fails unrelated, to be fixed in https://github.com/intel/scikit-learn-intelex/pull/2190

Error from the public CI job reads as follows:
Info from 'helper_mpi_tests.py'
sys.argv: ['/home/vsts/work/1/s/sklearnex/tests/helper_mpi_tests.py', 'pytest', '-k', 'spmd', '--with-mpi', '--verbose', '--pyargs', 'sklearnex']
ERROR: usage: helper_mpi_tests.py [options] [file_or_dir] [file_or_dir] [...]
helper_mpi_tests.py: error: unrecognized arguments: --with-mpi
  inifile: /home/vsts/work/1/s/sklearnex/pyproject.toml
  rootdir: /home/vsts/work/1/s/sklearnex

It means the job doesn't have pytest-mpi installed, which is required for running the SPMD tests.

/intelci: run

/intelci: run


When DataGrid is not set to a height, dynamically adding rows will not widen the height

Describe the bug
When I was using DataGrid, I did not set the height, and the set for initializing the binding was empty. By clicking the button to add rows, there was data in the set, but it did not expand the height of the DataGrid, which led me to think that there was a problem with the binding at one point.

To Reproduce

Create a DataGrid normally
Add a button
Add a click event to the button and add data to the ObservableCollection object bound to the DataGrid through the Add method

Expected behavior
When dynamically adding data, if the height of the DataGrid is not set, it should automatically expand to display the latest data
Avalonia version
11.0.10
OS
Windows, macOS
Additional context
No response

https://github.com/AvaloniaUI/Avalonia/assets/33543763/069cfaca-e806-4a07-99b6-d2c2e43929f6
I added this code: ScrollViewer.VerticalScrollBarVisibility="Disabled", only adding the first piece of data can automatically display the data, and the rest cannot be extended unless scrolling the mouse over the table

Maybe there's a problem with your theme. With the fluent theme it seems to work.
eg: TAGrid.zip

DataGrid needs fixed height to work as inteneded. StackPanel doesn't provide it. Either set height on your own or use a Grid or DockPanel.


Lint should process metadata structs (maybe entity fragments?), not raw XML strings

Fixed in 21aadbc480ef14a1e02f7f807193c7a868c27d93 Lint remains undocumented, but new functions have been added to Metadata and Entity


Improve Discoverable and BinarySensor classes

Description
The main changes in this PR are:

A sensor can be associated to a device by populating its device field
Add type parameter to the Discoverable class so that each subclass manages a specific type of sensor
Use pydantic to validate input settings and provide default values.
Use pytest to run Python tests. Write some tests for Discoverable and BinarySensor classes (some of the tests require a local MQTT broker running).
Update README.md with new instructions for creating a sensor and associating it to a device.
Add docker-compose.yml to ease in local development and testing.

According to the Home Assistant MQTT discovery protocol, a sensor is linked to a device when it provides the device field in its configuration. I suggest we associate a sensor to a device in a similar manner. The current solution of using a Device object with its add_metric does not allow to re-use the existing BinarySensor class, or any additional sensor classes that will be added in the future.
This change brings the following advantages:

If a sensor instance is linked to a device, a user can update the sensor by directly invoking its methods, without having to call every time add_metric() and publish() on the Device object
When a device contains multiple sensors, avoid iterating over all the sensors and publishing each state when a single sensor changes.

If the information about a device change (e.g. the software version), the user needs only to update a single instance of DeviceInfo and publish a state change on any of the linked sensors.

Fixes #13 (the Device class is no longer needed, since each Sensor now can be associated to a device)
If a Device class might be needed for convenience, it could be built simply as a wrapper around a list of sensor instances, each of them pointing to the same DeviceInfo object.
License Acceptance

[x] This repository is Apache version 2.0 licensed (some scripts may have alternate licensing inline in their code) and by making this PR, I am contributing my changes to the repository under the terms of the Apache 2 license.

Type of changes

[ ] Add/update a helper script
[ ] Add/update link to an external resource like a blog post or video
[ ] Bug fix
[x] New feature
[x] Test updates
[x] Text cleanups/updates

Checklist

[ ] I have read the CONTRIBUTING document.
[x] All new and existing tests pass.
[ ] Any scripts added use #!/usr/bin/env interpreter instead of potentially platform-specific direct paths (#!/bin/sh is an allowed exception)
[ ] Scripts added/updated in this PR are all marked executable.
[ ] Scripts added/updated in this PR do not have a language file extension unless they are meant to be sourced and not run standalone. No one should have to know if a script was written in bash, python, ruby or whatever. Not including file extensions makes it easier to rewrite the script in another language later without having to change every reference to the previous version.
[x] I have confirmed that any links added or updated in my PR are valid.

Thank you for the initial groundwork! :wink:
I have some doubts on how to integrate the CLI with these changes: have you considered an helper library for more easily defining and documenting the input parameters? I know argparse works, but it seems a bit cumbersome to define all the options inside the parser.
In the past I used the wonderful Click to write a simple CLI utility, but now I have been thinking about using Typer, since it provides a more beautiful interface with less boilerplate annotations.

Bump the version to 0.5.0 when you're ready to merge.
The command line tooling is currently charitably described as awkward. I mainly had it for testing, my initial thought had been to make this library as something people would pull into their own programs, but after using the cli scripts already in here, I realized that for a lot of users, something they can run from a shell prompt would make this far more usable. Let's discuss it more on https://github.com/unixorn/ha-mqtt-discovery/issues/18, I don't want to block merging your work on this PR
We can also address changing the argument handling in #18 . I'm not opposed to it, I used argparse to minimize the number of modules used that aren't included in the standard library. That said, they already have to pull in pyaml, paho-mqtt and others, so adding another one shouldn't be a deterrent if that makes argument handling easier for us.

One tiny thing - please run make format to get poetry to run black on all the .py files. You can ignore the SPELL error in the megalint report, I just configured it to treat spell errors as warnings in https://github.com/unixorn/ha-mqtt-discovery/pull/16 to get it to stop complaining about mosquitto :-)

One tiny thing - please run make format to get poetry to run black on all the .py files. You can ignore the SPELL error in the megalint report, I just configured it to treat spell errors as warnings in #16 to get it to stop complaining about mosquitto :-)

Yeah sorry I didn't quite know the workflow you followed in this repo. Tried to make sense of the Makefile but didn't know what targets were required before a commit.

I added documentation for enabling the git hooks in https://github.com/unixorn/ha-mqtt-discovery/pull/19, but it boils down to running hooks/autohook.sh install from the top level of the repo. It'll automagically format during commit.
I'll document the Makefile better in another PR, sorry about that

I'm going to defer working on #10 and #11 until after this PR lands. I don't want to make merge conflicts for you and the code change would need to be changed to work with this PR anyway

This is a huge improvement, thank you very much for the contribution.

Happy to help! :+1:


Group imports into blocks based on a heuristic

It might be nice, perhaps as an option, to separate packages and local
modules in the import block. What I mean by this is instead of having
one import block that is all sorted alphabetically, import-js would
manage multiple import blocks that are individually sorted alphabetically.
The first would include any package dependencies, and the second would
include any local dependencies.
Example:
import _ from 'underscore';
import React from 'react';

import MyComponent from './MyComponent';
import SomeOtherThing from '../../SomeOtherThing';

// rest of file would go here

In files that have a lot of dependencies, this should help keep things a
bit more organized and readable.
We considered making each group configurable, but ran into issues with
being able to map import statements back to actual paths
deterministically, so we decided to use a heuristic based on the style
of the imports and the paths. In most situations this will produce 2
groups (one for packages and one for non-packages), but in theory there
could be up to 12 groups.
We discussed making this configurable, but I wanted to get feedback
about my current implementation before doing that work.
Fixes #138

Thanks for all the work on this! I'm going to do some manual testing and check with the team before getting back to you about merging.

I've tried this out on the Brigade codebase, and it looks pretty decent! What's your opinion on making it configurable? I could go both ways, though I could see this being irritating if you don't want it and can't turn it off. Maybe group_imports, where the default is true?

Awesome! I think we should only add the config if it is actually needed. If
you need it at Brigade or if someone else needs it then let's add it.
Otherwise let's keep it slim.
On Sun, Feb 28, 2016, 1:56 PM Henric Trotzig<EMAIL_ADDRESS>wrote:

I've tried this out on the Brigade codebase, and it looks pretty decent!
What's your opinion on making it configurable? I could go both ways, though
I could see this being irritating if you don't want it and can't turn it
off. Maybe group_imports, where the default is true?
—
Reply to this email directly or view it on GitHub
https://github.com/trotzig/import-js/pull/200#issuecomment-189952184.

@lencioni FYI - I pushed a bugfix for an issue I found when running the CLI tool.

I have a preliminary +1 from the team to group imports. I'll follow up in the coming days when I have a few extra cycles. I'll probably merge this followed by releasing 0.5.0. It's probably a good idea to update your .importjs.json at that time with a minimum_version to force everyone to upgrade.

I ended up pushing another bugfix that I found when rewriting the Brigade codebase. Not introduced in this branch though, but we might as well put it here.


Differenciate various types of properties in the Documentation

Differenciate various types of properties, such as ObjectProperties, DatatypeProperties, AnnotationProperties, and RDF Properties in general, in the Documentation Tab

On documentation tab, when the user clicks „properties“ checkbox, a dropmenu will appear to show all of different properties types to be selected by the user


text gets cut off in Evaluate

I used this dataset for text classification: https://www.kaggle.com/teejmahal20/airline-passenger-satisfaction?select=train.csv
Here are the Labels:

Here is what it looks like in Try your model:

Verify this issue on latest main build: <IP_ADDRESS>7701
I’m not sure if there will be such a long title, but I did name a very long one to verify the problem, find that there is not enough space to show the long title on Evaluate page. Could you help to take a look again?

@zewditu Can you take a look here, and if it's a quick fix add the tooltip?

@beccamc @zewditu
Is there any update on this issue?

@beccamc @zewditu any update?

@vzhuqin I will look into it.

Not repro this issue on latest main: <IP_ADDRESS>6904


An empty partition can block data ingestion from Kafka/Kinesis

Affected Version
All version since 0.10
Description
When the supervisor is restarted or reset, it first finds the valid offsets to continue reading from metadata storage. If there's no offsets in metadata storage, then it fetches the latest/earliest offset from Kafka/Kinesis per partition. It's implemented here.
  private ImmutableMap<PartitionIdType, OrderedSequenceNumber<SequenceOffsetType>> generateStartingSequencesForPartitionGroup(
      int groupId
  )
  {
    ImmutableMap.Builder<PartitionIdType, OrderedSequenceNumber<SequenceOffsetType>> builder = ImmutableMap.builder();
    for (Entry<PartitionIdType, SequenceOffsetType> entry : partitionGroups.get(groupId).entrySet()) {
      PartitionIdType partition = entry.getKey();
      SequenceOffsetType sequence = entry.getValue();

      if (!getNotSetMarker().equals(sequence)) {
        // if we are given a startingOffset (set by a previous task group which is pending completion) then use it
        if (!isEndOfShard(sequence)) {
          builder.put(partition, makeSequenceNumber(sequence, useExclusiveStartSequenceNumberForNonFirstSequence()));
        }
      } else {
        // if we don't have a startingOffset (first run or we had some previous failures and reset the sequences) then
        // get the sequence from metadata storage (if available) or Kafka/Kinesis (otherwise)
        OrderedSequenceNumber<SequenceOffsetType> offsetFromStorage = getOffsetFromStorageForPartition(partition);

        if (offsetFromStorage != null) {
          builder.put(partition, offsetFromStorage);
        }
      }
    }
    return builder.build();
  }

If the supervisor sees an exception while fetching the offset from Kafka/Kinesis for some reason (e.g., timeout because of an empty partition), then this method would return immediately and handling the runNotice would fail because of the exception. This may block the entire data ingestion until any data is ingested to all partitions.
I think the supervisor should be able to skip some partitions if it sees some error while getting the offset and continue ingestion for other partitions.

Hey @jihoonson, thanks for opening this issue! I've put up a PR to address this issue: https://github.com/apache/incubator-druid/pull/7648 - let me know if this is what you had in mind.