pnpm-lock.yaml not parseable (Dependabot::DependencyFileNotParseable)

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
pnpm
Package manager version
8.6.9
Language version
Node v20.4.0
Manifest location and content before the Dependabot update
I use the dependabot-script with local update version ("dependabot-omnibus", "~> 0.221.0")
I try to run with theses env var :
GITHUB_ACCESS_TOKEN=<TOKEN>
GITLAB_ACCESS_TOKEN=<TOKEN>
PACKAGE_MANAGER=npm_and_yarn
PROJECT_PATH=titouan-joseph/overbookd

Link of project here
Link of the forked dependabot-script here in branch v0.221.0
dependabot.yml content
No response
Updated dependency
No response
What you expected to see, versus what you actually saw
Error
Fetching npm_and_yarn dependency files for titouan-joseph/overbookd
Parsing dependencies information
/home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:23:in `rescue in block in parsed': /pnpm-lock.yaml not parseable (Dependabot::DependencyFileNotParseable)
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:15:in `block in parsed'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `block in in_a_temporary_directory'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `chdir'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `in_a_temporary_directory'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:14:in `parsed'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:55:in `details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:39:in `block in lockfile_details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:38:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:38:in `lockfile_details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:93:in `build_dependency'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:71:in `block (3 levels) in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:67:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:67:in `block (2 levels) in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:65:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:65:in `block in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:59:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:59:in `manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:37:in `parse'
        from ./generic-update-script.rb:178:in `<main>'
/home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:138:in `rescue in run_helper_subprocess': Dependabot::SharedHelpers::HelperSubprocessFailed
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:84:in `run_helper_subprocess'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:17:in `block in parsed'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `block in in_a_temporary_directory'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `chdir'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `in_a_temporary_directory'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:14:in `parsed'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:55:in `details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:39:in `block in lockfile_details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:38:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:38:in `lockfile_details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:93:in `build_dependency'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:71:in `block (3 levels) in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:67:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:67:in `block (2 levels) in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:65:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:65:in `block in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:59:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:59:in `manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:37:in `parse'
        from ./generic-update-script.rb:178:in `<main>'
/usr/local/lib/ruby/3.1.0/json/common.rb:216:in `parse': 859: unexpected token at '' (JSON::ParserError)
        from /usr/local/lib/ruby/3.1.0/json/common.rb:216:in `parse'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:128:in `run_helper_subprocess'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:17:in `block in parsed'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `block in in_a_temporary_directory'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `chdir'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-common-0.221.0/lib/dependabot/shared_helpers.rb:55:in `in_a_temporary_directory'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:14:in `parsed'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/pnpm_lock.rb:55:in `details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:39:in `block in lockfile_details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:38:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser/lockfile_parser.rb:38:in `lockfile_details'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:93:in `build_dependency'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:71:in `block (3 levels) in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:67:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:67:in `block (2 levels) in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:65:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:65:in `block in manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:59:in `each'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:59:in `manifest_dependencies'
        from /home/dependabot/dependabot-script/vendor/ruby/3.1.0/gems/dependabot-npm_and_yarn-0.221.0/lib/dependabot/npm_and_yarn/file_parser.rb:37:in `parse'
        from ./generic-update-script.rb:178:in `<main>'

Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

This is likely because the helpers for required for pnpm are missing. The docker image (ghcr.io/dependabot/dependabot-updater-npm) contains them. It looks like you are using the scripts (https://github.com/dependabot/dependabot-script) repo but it still hasn't been upgraded to use an image per ecosystem.

Ok thanks !


Add openapi-generator v6.5.0 and v6.6.0 containers

New versions of the openapi-generator containers.

@mharding-hpe Process of adding images to this repo was completely revamped by @mitchty , so I'd delegate PR review to him... As far as I can see, the files in this PR were generated the old way (by running create_buildfiles.sh) and they are supposed to be ran by running make add now.

Ok, I've recreated them using the "make add" procedure.

Interesting. In this version of the PR, the jobs are failing. Let me investigate...

I think running the make under Ubuntu was not working. Tried it under SLES and it went more smoothly.

Now they are failing on Snyk failures. I'm wondering if it's okay for us to allow these anyway, since we don't actually ship these containers as part of CSM -- they're just used by us at build time to generate API framework files. So we don't need to worry about malicious actors making use of them.

Talked to @mitchty . He said to go ahead and manually edit the jobs for these guys to not fail on Snyk failures. I have done so.


VSCode-Extension: download lldb built for ubuntu 20.04

This should allow users to use the vscode extension on ubuntu 20.04.
After https://github.com/bytecodealliance/wasm-micro-runtime/pull/2132 , our lldb binary for 20.04 works on ubuntu 22.04 as well.
On the other hand, lldb for 22.04 has no chance to work on ubuntu 20.04. (because of glibc version requirement.)

does anyone know a good way to test this kind of changes w/o actually making a release?


extract drainToAsync ?

this would be nice

Done

wow,Thanks.I will upgrade to 2.1.1 later,you know what?the new async interface with scala's future implicit conversion and akka actor works very fine.thanks very much.

the new async interface with scala's future implicit conversion and akka actor works very fine.thanks very much.

Oh, knowledge of this it's a ray of sunshine for me. Thanks for using. You could tell me you project name and i'll add it to Projects using Redisson section if you want, of course.

@mrniko I want but it was a part of a mobile game server,the project name is "super heros".we are currently using the redis as a message queue and for the player's ranking lists with redisson.
really thanks for you work.I am sure we will find many other intersting part with this project.
:100:


Add documentation on Triple .NET Team Guidelines

Adds a few documents on .NET team standards.

@Nuss9 Can you either resolve or close the comments in this PR so I can merge it?


fix NPE when replying to un-decrypted message

Fixes #3266.
This makes it possible to reply to encrypted emails, when you don't have openKeyChain installed, or probably if you didn't bother to decrypt a message/decryption failed.
One thing that's still happening is that the subject of the reply is empty. It should populate the normal reply subject which is either available in unencrypted form or it should reply to the placeholder subject. (This is how thunderbird behaves as well.)
But hey, at least we don't crash anymore. :-)

Thanks for attempting to fix this issue. Unfortunately this PR is mostly fighting symptoms. I tried to come up with a fix that doesn't require all MessageViewInfo consumers to handle a special case. See #4419.

@cketti Thanks for doing a proper fix! :tada:


How to set intial value for query, so it's value won't be undeifned before query complete?

I can't find doc for this question, can anyone help me?

Just set the value in the data object.
i.e.
export default {
  data: () => ({ field: 'Initial Data' }),
  apollo: {
    field: GET_FIELD
  }
}

Would be great if this could be documented in the docs somewhere.


Some users are creating recurring contributions with Bank Transfer (manual)

Discovered while investigating https://github.com/opencollective/opencollective/issues/6934
Describe the bug
See the history for https://opencollective.com/letztegenerationat/contributions/611915:
Initially created with interval=month but no payment method (manual bank transfer) - this indeed doesn't make sense, we're not supposed to allow it.
Then updated to PayPal a few months later, payments apparently been running smoothly since then.
  select *
  from "Orders" o
  INNER JOIN "Collectives" fc ON fc.id = o."FromCollectiveId"
  where o."PaymentMethodId" IS NULL
    AND o."interval" IS NOT NULL
    AND o."deletedAt" IS NULL
    AND o.status != 'PLEDGED'
    AND fc.type = 'USER'
  ORDER BY o.id DESC

To Reproduce
Steps to reproduce are still unclear.
Expected behavior
We do not support recurring for manual payments. It shouldn't be offered in the frontend, and should be blocked by the API.

https://github.com/opencollective/opencollective/issues/6873


Add another point of randomness (the initial choice had been missed)

Make the tests cross-platform. Hopefully

Thanks greg, Hope it works also this is more random then before

Done thanks
Le dim. 7 oct. 2018 à 04:40, Greg Landrum<EMAIL_ADDRESS>a
écrit :

Make the tests cross-platform. Hopefully
You can view, comment on, or merge this pull request online at:
https://github.com/thegodone/rdkit/pull/7
Commit Summary

Add another point of randomness (the initial choice had been missed)

File Changes

M Code/GraphMol/Canon.cpp
https://github.com/thegodone/rdkit/pull/7/files#diff-0 (136)
M Code/GraphMol/SmilesParse/test.cpp
https://github.com/thegodone/rdkit/pull/7/files#diff-1 (89)

Patch Links:

https://github.com/thegodone/rdkit/pull/7.patch
https://github.com/thegodone/rdkit/pull/7.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/thegodone/rdkit/pull/7, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABIbYjdwmfGxigt3VgOAkpqAozEKU-W5ks5uiWm7gaJpZM4XLpaq
.


The way to view resource provider details has been updated in the portal

Please reach out to me on the Azure portal team and I can provide details on an easier way to view RP details.

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

ID: 4e0f4357-f70d-c3b7-5107-5dd4c1430efc
Version Independent ID: 84c23960-2831-bc9f-7bbe-33e751a19ad2
Content: Resource providers and resource types - Azure Resource Manager
Content Source: articles/azure-resource-manager/management/resource-providers-and-types.md
Service: azure-resource-manager
Sub-service: management
GitHub Login: @mumian
Microsoft Alias: tomfitz

@gurua
Thanks for your feedback! We will investigate and update as appropriate.

Tracking the issue internally with https://dev.azure.com/msft-skilling/Content/_workitems/edit/265560.
#please-close


segment_v2: Support bitmap index build

This PR implements the build part of bitmap index support. It follows most of the design described in #1684 , but with the following differences and enhancements

Bitmap indexes are now written in the segment file for simplicity. Separate index file would be helpful when we're going to support alter table add bitmap index in the future though.
We switch to a generalized index page format for all data types rather than specialize for each one. Code simplicity and reusability is preferred here than optimal compression rate.
We introduce a new abstraction called IndexedColumn to unify the processing of the dictionary section and bitmap section of bitmap index. IndexedColumn is a column with an optional ordinal index and an optional value index. Ordinal index enables us to seek to a particular rowid within the column. Value index requires IndexedColumn to store ordered values and enables us to seek to a particular value. Therefore, the dictionary section can be represented by an IndexedColumn with value index and the bitmap section can be represented by an IndexedColumn with ordinal index.

the failed tests are unrelated, reopen to re-run the CI

LGTM


Firefox error "SyntaxError: missing = in const declaration"

When trying to use this library in Firefox I am getting the "SyntaxError: missing = in const declaration"
it appears that Firefox < version 51 has a bug in its implementation of "for(const"  ....
Below is the Mozilla bug tracking this :
https://bugzilla.mozilla.org/show_bug.cgi?id=1101653
Just letting you all know that FF 52+ should resolve this ...
p.s. the bug was being hit when the util.ts -> makeString method was being called .. That has a for loop using a const

Closing this because of old age. If the issue persists, please let me know.


Add force_show_panics flag for proc-macro bridge

https://github.com/rust-lang/rust/pull/75082 and https://github.com/rust-lang/rust/pull/76292 added a new flag in proc_macro::Bridge such that the ABI was changed. These ABI changing are the reason of some weird panics which caused #6880 and maybe related to the panic mentioned in #6820.
These changes are landed on rust stable 1.48 so I think it is okay to apply it now.
fixes #6880
r @jonas-schievink

I no longer get any crashes with this PR.

Looks good!
bors r+


Fix - Wrong drag width on cloned elements

Related to the PR #194
Width persistent was applied to the wrong element.

LGTM


Test scikitlearn imports

Hi @madhursharma ,
Thanks for your PR. However, the diff is huge, and I can't find what changed. Could you please give more details?

Please ignore . Merge was done accidentally
On Sat, Oct 5, 2019, 1:15 AM Aurélien Geron<EMAIL_ADDRESS>wrote:

Hi @madhursharma https://github.com/madhursharma ,
Thanks for your PR. However, the diff is huge, and I can't find what
changed. Could you please give more details?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ageron/handson-ml/pull/494?email_source=notifications&email_token=AASE77FH7HDXQ3OGZO2L43DQNAPIZA5CNFSM4I5KKUBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEANKNXI#issuecomment-538617565,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASE77FAQGD6YRFW4NMVANTQNAPIZANCNFSM4I5KKUBA
.

Got it, thanks for your feedback @madhursharma .


AIP-6522 IAM role per workflow

In order to support IAM roles for individual profiles we also need to support IAM roles per workflow from the workflow SDK. This change pulls in an environment variable set in the host notebook pod and launches the underlying Argo workflow with the configured role from the user.

@cloudw how does this look? Is it good for approval?

@cloudw how does this look? Is it good for approval?

How was the code tested? Was it a manual test?

yep, manually downloaded to my notebook in sandbox and tested.

Already approved but I'd prefer a unit test here if it doesn't take too much time. There is one existing unit test that checks for yaml output: https://github.com/zillow/metaflow/blob/feature/kfp/metaflow/plugins/kfp/tests/run_integration_tests.py#L301

showing the test passed
run_integration_tests.py::test_kubernetes_service_account_compile_only Metaflow zg.post1.2-33+git27c3bef executing TolerationAndAffinityFlow for
Creating local datastore in current directory (/home/zservice/metaflow/metaflow/plugins/kfp/tests/.metaflow)
Validating your flow...
    The graph looks good!
Running pylint...
    Pylint is happy!
Uploaded package to: /home/zservice/metaflow/metaflow/plugins/kfp/tests/.metaflow/TolerationAndAffinityFlow/data/60/602f68cf78[349]
Done converting TolerationAndAffinityFlow to /tmp/tmpdyxk0nii/kubernetes_service_account.yaml
[gw0] PASSED run_integration_tests.py::test_kubernetes_service_account_compile_only /opt/zillow/.venv/lib/python3.9/site-packages/coverage/control.py:794: CoverageWarning: No data was collected. (no-data-collected)


[language][events] include type info in emitted events

Summary
This includes type info in emitted in emitted events so that one will be able to know it when querying.
Test Plan
cargo test

:umbrella: The latest upstream changes (presumably 8744e33e5c29da95938c9268017a12c4392b61ba) made this pull request unmergeable. Please resolve the merge conflicts.

Note: does not work yet. Need to figure out how to handle type parameters. (emit_event<T> calls write_to_event_storage<T> and everyone else needs to call emit_event<some concrete type>.)

Note: does not work yet. Need to figure out how to handle type parameters. (emit_event<T> calls write_to_event_storage<T> and everyone else calls emit_event<some concrete type>.)

Had a quick discussion with @vgao1996 this morning. It seems to us that we would probably need to implement a substitution map at runtime. There can be two implementation possibilities here:

We can implement a type stack where type arguments being pushed onto the stack whenever there is a call. Substitution should only happen when the write_to_event_storage <T> is called. By that time we will materialize T into a TypeTag. This approach won't have too much overhead, but we do need to handle the substitution carefully to avoid exponential work.
We can do an eager substitution where at each function call, we push the substituted types onto the stack.

IMHO the former approach sounds a bit more reasonable as we only need to do such substitution for the write_to_event_storage, but we probably need a bit more discussion there.
Also, we had some similar substitution strategy in type_context.rs. Maybe  we should revisit that piece of code to unify the logic a bit. The main issue here is that we use types for two separate purpose: to get the struct layout of an object, and to get the type identifier name for event. We might want to store those two struct together so that we don't need to duplicate the code at a cost of bigger memory consumption.

I would imagine that for future work, we will have another table entry in the storage to map from EventKey to the type identifier, so that we don't need to store it multiple times. I would cc @msmouse for the potential future work here.

@runtian-zhou Yes, the currently implementation is more of a temporary fix to unblock other folks. I'm expecting the Vec<TypeTag> in frames to be replaced by some cached structure when we rework the loaded module.

:umbrella: The latest upstream changes (presumably 1deeabc700a1375817c746eccdb2eecba75c639b) made this pull request unmergeable. Please resolve the merge conflicts.

@dariorussi I've updated the PR. Note for the sake of this task I'm simply adding a Vec<libra_types::language_storage::TypeTag> to each frame. Type substitution is done in an eager fashion and there's no caching, which can lead to bad performance in some rare cases. In other words, this is a temporary solution that will unblock folks who depend on events.
As we talked previously, we need to formerly introduce the concept of nominal types into the VM and rename the existing vm_runtime_values::loaded_data::types::Type to sth like TypeLayout. We'll fix the performance issue as we implement these as part of the greater module cache redesign. Sounds good to you?

@dariorussi I've updated the PR. Note for the sake of this task I'm simply adding a Vec<libra_types::language_storage::TypeTag> to each frame. Type substitution is done in an eager fashion and there's no caching, which can lead to bad performance in some rare cases. In other words, this is a temporary solution that will unblock folks who depend on events.
As we talked previously, we need to formerly introduce the concept of nominal types into the VM and rename the existing vm_runtime_values::loaded_data::types::Type to sth like TypeLayout. We'll fix the performance issue as we implement these as part of the greater module cache redesign. Sounds good to you?

I'll do the code review tomorrow if someone has not done it earlier. Just wanted to comment that your approach is sound to me and I love it! :)
thanks!

@bors-libra r=dariorussi

:pushpin: Commit 16bac50 has been approved by dariorussi

:hourglass: Testing commit 16bac5081bf28168230609dbd3809882afe0aec2 with merge eca2d91c6ceb6551243d830520cade5580e93995...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra r=dariorussi

:pushpin: Commit 38cfaed has been approved by dariorussi

:hourglass: Testing commit 38cfaed71fca81c6f562969e7d675dd972a09106 with merge d18d4604e0dee4ea8abf867205d432e6c314bcd0...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: dariorussi
Pushing d18d4604e0dee4ea8abf867205d432e6c314bcd0 to master...


Saved case list search working on old devices

This feature was not working in old devices, this PR fixes that.

Looks good! Will merge after my comment is addressed

Should be good to go now.


Fix issue that signal based exceptions in lldb were not working.

This isbecause a hack in miengine that adds frame info to the results class
wasn't accounting for signal-received events resulting in engine assuming
this is a module load event. Note that this hack (assuming any event
without a frame is a mod-load) seems wrong but removing it would be a bit
risky. It may be better to account for mod loads by directly checking for
them. Also, the existing hack no longer works as results.add returns a new
results class. Fixed that as well.

@gregg-miskelly @chuckries @paulmaybee

:+1:

:+1:


allow more templating in .packit.yml

Description
Ohai!
In @theforeman we use packit to build RPMs from PRs so people can test out the changes without having a full development setup (the way our app works requires a few steps and many extra dependencies to build JS/CSS assets, and we avoid the need of having all that by using packit builds).
One of the "problems" we stumbled upon is that due to the fact that we have additional_repos defined (for the before mentioned dependencies) and multiple stable branches in parallel (which might need different versions of those dependencies), we have to "manually" (sed exists, but still) edit .packit.yml in our stable branches to point at the stable branches of our packaging dependencies.
Examples:

current develop packit yaml
current 3.7 packit yaml

The only difference is the URL http://koji.katello.org/releases/yum/foreman-3.7/el8/x86_64/ vs http://koji.katello.org/releases/yum/foreman-nightly/el8/x86_64/
If we could somehow template that (via an action that sets additional_repos, or one that does pre-processing of the whole .packit.yml or just plain old variable replacement as you allow in other places), we could save an additional step during branching :)
End-of-RFE ;-)
Benefit

saving time
having more stable builds as noone can forget the additional step :)
I can also sign this RFE with my @katello hat on

Importance
not blocking
Workaround

[X] There is an existing workaround that can be used until this feature is implemented.

Participation

[ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)

Oh, and it would be cool if the same templating could be applied to the post-upstream-clone action, so we can download the .spec file from the right branch too.

Hello @evgeni !
Thanks for the issue. This makes a lot of sense even though I am not sure how this can be easily implemented. I would say this should be implemented in a generic way to support all (or most of) the config options. The key problem here is that actions are required to be run in the sandbox environment (e.g. Sandcastle for release syncing and Copr for builds) and we don't have this available all the time when going through the workflow. E.g. when setting the first GitHub statuses, we parse the config but don't run the actions for improved speed.
Just for reference, we've already got a similar request here: https://github.com/packit/packit/issues/1925 , but the use case is a bit different.
Let's discuss the possibilities at our architecture meeting. (@evgeni  I'll send an invite if you want to attend. Anyone interested can join as well, just let me know).

I've created a research card to take a look into this: https://github.com/packit/research/issues/201

Another point where it may be useful is building for multiple versions.
The use case is a Foreman plugin which supports Foreman 3,8 & nightly. You want to build RPMs for all those versions, but also get the RPM spec for the exact version. I imagine you could set variables per job and use those again in actions like post-upstream-clone.
Or more concrete, taking from foreman_ansible's packit.yaml and imagine you could have 2 jobs there, each of which can set $PACKAGING_BRANCH. So you could have a config like:
actions:
  post-upstream-clone:
    - "wget https://raw.githubusercontent.com/theforeman/foreman-packaging/$PACKAGING_BRANCH/packages/plugins/rubygem-foreman_ansible/rubygem-foreman_ansible.spec -O rubygem-foreman_ansible.spec"
  get-current-version:
    - ruby -rrubygems -e 'puts Gem::Specification::load(Dir.glob("*.gemspec").first).version'
  create-archive:
    - gem build foreman_ansible.gemspec
    - bash -c "ls -1t ./foreman_ansible-*.gem | head -n 1"

jobs:
  - job: copr_build
    trigger: pull_request
    targets:
      centos-stream-8:
        additional_modules: "foreman:el8,nodejs:12"
        additional_repos:
          - http://koji.katello.org/releases/yum/foreman-nightly/el8/x86_64/
          - http://yum.theforeman.org/plugins/nightly/el8/x86_64/
    module_hotfixes: true
    variables:
      PACKAGING_BRANCH: rpm/develop
  - job: copr_build
    trigger: pull_request
    targets:
      centos-stream-8:
        additional_modules: "foreman:el8,nodejs:12"
        additional_repos:
          - http://koji.katello.org/releases/yum/foreman-3.8/el8/x86_64/
          - http://yum.theforeman.org/plugins/3.8/el8/x86_64/
    module_hotfixes: true
    variables:
      PACKAGING_BRANCH: rpm/3.8


Add support for Vector Tiles

A tremendous improvement to osmdroid would be to add support for online vector tiles.
Some explanations here: https://mapzen.com/projects/vector-tiles
Key advantages compared with bitmap tiles:

smaller tiles,
huge flexibility for custom rendering, e.g. night mode
in the future: support for continuous zoom levels with perfect display.

In the same time, online tiles service do not have the drawbacks of MapsForge: manual download, huge file, and limited region.
And osmdroid caching features will allow to store portions for offline use (using for instance OSMBonusPack Cache management tools).
So, the best of all worlds.
Now, which tiles format to choose? MapBox Vector Tiles format (https://github.com/mapbox/vector-tile-spec) is probably a safe choice for performance and size aspects.
There are at least 2 services providing worldwide OSM maps as online vector tiles: MapZen and MapBox. Both are supporting MapBox Vector Tiles format (https://www.mapbox.com/developers/vector-tiles).
Implementation aspects:
The osmdroid tile caching mechanism can be fully reused.
The big task will be to implement vector tiles drawing. MapsForge experience (and code?) should help a lot.
MapZen currently has no Android SDK for using its service: they could be interested to participate to this enhancement of osmdroid, thus addressing the whole osmdroid community.
Note that MapBox deprecated its Android SDK based on an osmdroid fork (https://github.com/mapbox/mapbox-android-sdk-legacy), and now puts its efforts on an Android SDK based on Vector Tiles and OpenGL (https://github.com/mapbox/mapbox-gl-native/).
@spyhunter99 what do you think about this new challenge?

@MKergall ugh I have enough projects lol.
Have you see seen geopackage? It's a sqlite database with vector and/or raster images. I've done some work to get the existing components made by NGA to work with osmdroid (raster only), but it may be possible to adapt their vector code.
I also have a need to support shape files, which are basically vector graphics.
Back on topic. Both mapbox and mapzen require developer keys which lets me to believe they are not exactly free services. Mapzen serves up the code using geojson. Don't you have support for that already with OBP?

Obtaining a key at Mapzen for free without particular limit seems easy.
Obtaining a key at Mapbox for free is easy, but leads to usage limits.
Mapzen serves the tiles in 3 formats. One of them is the Mapbox Vector Tiles (.mvt).
I think that geojson is not a good choice in our context: too verbose, and too long to parse, compared with a binary format designed with these contraints in mind.
What is OBP?
There is an Android lib at OpenScienceMap for Vector Tiles: https://github.com/opensciencemap/vtm
Display is based on OpenGL. Code is under GPL.
They picked some code from both osmdroid and OSMBonusPack.

OBP = osm bonus pack.

OpenScienceMap looks interesting (at least the browser based solution). it may be possible to do an on the fly conversion of the vector format to the mapforge data structures for rendering. I wonder if the maps forge folks have an adapter

having this functionality on device along with #245 mapsforge would bring a number of new options for supporting alternate rendering for #133 night mode

Hi,
GeoJSON is a standard (will be an IETF standard), so even if it could be verbose (a technical motivation), for the actual GIS market (a functional requirement) is a must to implement it.
regards
Paolo

@paolo-rendano GeoJson is supported by osmbonuspack. This thread is really about vector tiles

then, how we can use mapsforge for display online mapbox vector tiles?

@darkwizzard good question. osmdroid has an adapter to use mapsforge as a tile source. See the example app for it. The full stack should be available, but sorry we don't have an example of using mapbox vector with forge

Mapzen offers vector tiles (https://mapzen.com/projects/vector-tiles/)
The Mapzen vector tile server uses the familiar slippy tile zoom/x/y URL format:
http://vector.mapzen.com/osm/{layers}/{z}/{x}/{y}.{format}?api_key={api_key}
This could help us?
https://github.com/mapzen/map-burrito
How @MKergall tells we can use;

vtm (https://github.com/opensciencemap/vtm) or
vector-tile-spec (https://github.com/mapbox/vector-tile-spec).

The last is part of awesome-vector-tiles (https://github.com/mapbox/awesome-vector-tiles).
Mapnik is using mapbox vector tile spec here;
https://github.com/mapbox/mapnik-vector-tile/

@darkwizzard thanks for the link. VTM, open science map and thus the burrito project (which has no docs) all fall under GPLv3. This effectively means that if you use their libraries, you are required to make their stuff and all your stuff that depends on it open source. I'm not a lawyer, but that would be a deal breaker in many cases. Now we "could" have a support library that adopts the VTM stuff to osmdroid. It could then be included with the demo app. This support library would also have to carry the GPLv3 license, which is fine.

oh good news, mapsforge already has an adapter for VTT

@devemux86 i found the integration guide for the vtt library, but it basically just helps you setup the dependencies. I'd like to do something similar to https://github.com/osmdroid/osmdroid/blob/master/osmdroid-mapsforge/src/main/java/org/osmdroid/mapsforge/MapsForgeTileSource.java#L199 but for the vtt library and frankly, I'm not sure how to go about. Let's just assume we have an input stream for vector tile, how can i use vtt to produce a bitmap?

This might be what we need... https://github.com/mapsforge/vtm/blob/master/vtm/src/org/oscim/renderer/BucketRenderer.java
Since we don't use GL I'm not sure how well this will work out, if at all

VTM is licensed under LGPL and development continues at Mapsforge repository.
It's an OpenGL vector map library, compatible with Mapsforge map files, not producing bitmaps but renders vector (or raster) data in real time on GL surface.
Can see it in action via vtm-android-example.

@spyhunter99 @MKergall  I am not getting if it is supported now or not? (2)

it is not


Landing page [beta]

Added a basic landing page to showcase all the projects.
NOTE: Liable to change and recieve updates.
commits:

[part] added index page layout
improved index page layout
added index layout and card layout
added bottom panel to projects card

addresses #1


net/freeradius: Allow : in user and password

Fixes #3975
FreeRADIUS allows a : character in the username and password. This update is especially useful for MAC-based authentication where you might want to copy-paste a MAC address for the username and password.
# opnsense-patch -a chelming -c plugins 1207358
Fetched 1207358 via https://github.com/chelming/plugins
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 120735808a1bdcdfec7a85897a252d0e9b8dcfa4 Mon Sep 17 00:00:00 2001
|From: Chris Helming<EMAIL_ADDRESS>|Date: Mon, 13 May 2024 10:21:33 -0400
|Subject: [PATCH] allow : in FreeRADIUS user and password
|
|---
| .../OPNsense/Freeradius/forms/dialogEditFreeRADIUSUser.xml    | 4 ++--
| .../src/opnsense/mvc/app/models/OPNsense/Freeradius/User.xml  | 4 ++--
| 2 files changed, 4 insertions(+), 4 deletions(-)
|
|diff --git a/net/freeradius/src/opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/dialogEditFreeRADIUSUser.xml b/net/freeradius/src/opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/dialogEditFreeRADIUSUser.xml
|index e6fc8d7484..e025a865a5 100644
|--- a/net/freeradius/src/opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/dialogEditFreeRADIUSUser.xml
|+++ b/net/freeradius/src/opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/dialogEditFreeRADIUSUser.xml
--------------------------
Patching file opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/dialogEditFreeRADIUSUser.xml using Plan A...
Hunk #1 succeeded at 9 with fuzz 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/net/freeradius/src/opnsense/mvc/app/models/OPNsense/Freeradius/User.xml b/net/freeradius/src/opnsense/mvc/app/models/OPNsense/Freeradius/User.xml
|index 506ab2d3f9..589798ce4a 100644
|--- a/net/freeradius/src/opnsense/mvc/app/models/OPNsense/Freeradius/User.xml
|+++ b/net/freeradius/src/opnsense/mvc/app/models/OPNsense/Freeradius/User.xml
--------------------------
Patching file opnsense/mvc/app/models/OPNsense/Freeradius/User.xml using Plan A...
Hunk #1 succeeded at 11 with fuzz 2.
done
All patches have been applied successfully.  Have a nice day.

# radtest 11:22:33:44:55:66 11:22:33:44:55:66 <IP_ADDRESS> 1812 abcd
Sent Access-Request Id 59 from <IP_ADDRESS>:8d5b to <IP_ADDRESS>:1812 length 103
        User-Name = "11:22:33:44:55:66"
        User-Password = "11:22:33:44:55:66"
        NAS-IP-Address = <IP_ADDRESS>
        NAS-Port = 1812
        Message-Authenticator = 0x00
        Cleartext-Password = "11:22:33:44:55:66"
Received Access-Accept Id 59 from <IP_ADDRESS>:714 to <IP_ADDRESS>:36187 length 42
        Tunnel-Type:0 = VLAN
        Tunnel-Medium-Type:0 = IEEE-802
        Tunnel-Private-Group-Id:0 = "20"
        Framed-Protocol = PPP

I'm not having any trouble with the shown config and a Catalyst 3750 🤷. Unifi can ship the : notation and it's easier to copy-paste right from there or DHCP leases and not have to remove all the colons.

Is there anything I can do to help get this merged? Any logs, demo recordings, documentation, etc?

Interested in a follow up regarding this PR since this issue prevents using MAC addresses to assign devices to VLANs.

Interested in a follow up regarding this PR since this issue prevents using MAC addresses to assign devices to VLANs.

you can use MAC addresses to assign, just not with colons. for example, in the unifi network manager you'd select the format to send as "aabbccddeeff" and remove the colons when creating a user on the freeradius users table.

you can use MAC addresses to assign, just not with colons. for example, in the unifi network manager you'd select the format to send as "aabbccddeeff" and remove the colons when creating a user on the freeradius users table.
I don't think I can control the MAC addresses format from the hardware I have at home.

Hi there, any ETA on this being merged ?
Is there anything needed to help advancing on this PR ?

I ended up modifying the files using single user mode. Works like a charm.

Merged, thanks!


Expand column!()

r? @edwin0cheng

Can we also have file!()?

Can we also have file!()?

I think that deserves a separate PR.

We also can't really have file!() at the moment, as rust-analyzer
(purposefully) lacks the knowledge about absolute file paths. I think, for
starters, we should expand file to just "".
On Fri, 22 Nov 2019 at 16:57, Jeremy Kolb<EMAIL_ADDRESS>wrote:

Can we also have file!()?
I think that deserves a separate PR.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rust-analyzer/rust-analyzer/pull/2355?email_source=notifications&email_token=AANB3M2Q5W77PMEQW6J6G6DQU7QMHA5CNFSM4JQQ5UQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE5WPVI#issuecomment-557541333,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANB3M5IV74NSF5M7FBPX4LQU7QMHANCNFSM4JQQ5UQA
.

I'll rebase this ones #2357 merges.

bors r+


Monix vNext — future plans

Series 3.0.0 is now stable and for its duration we can no longer break binary compatibility — at least not on top of Scala 2.12+ — and I predict more features being built on top of what we have.
But we should also talk about a wish list for future versions, that can happen both soon (without breaking binary compatibility) or in a far future major version that can break binary compatibility.
This list is a work in progress, items may be added or removed, suggestions welcome.
Safe (non-binary breaking) changes

Provide bi-functor Task and Coeval implementations, possibly in their own sub-project?

Not sure if we should, this needs to be discussed — I don't believe in the approach, but there are some people that do
As an alternative, maybe a nicer EitherT would be better (e.g. one that is covariant, maybe with better performance as the one in Cats is not representative of what can be done)

Make Iterant covariant, for improving type inference (e.g. Iterant[+F[_], +A])
Better stack traces, preferably opt-in, possible solutions need to be investigated
...

Binary breaking changes
Note that these aren't necessarily plans that will happen in less than a year, or even more — we are talking about a long time frame:

Rebuild Observable to use the Reactive Streams protocol internally, instead of the Future-based protocol that we have — but keep the Future-based one for consumption of streams and for ease of use — this might yield better performance in some cases, even if it's more challenging, but we can take inspiration from RxJava, while coming up with our own innovations and trying hard to keep source compatibility

right now we piggyback the Reactive Streams on top of our Future-based one, but maybe it should be the other way around
what I like about Reactive Streams is that the protocol for cancelation is clearer, whereas with Future you can end up with leaks due to not being able to unregister an "onComplete"
one thing I really want, that RxJava doesn't do, is a stack safe flatMap implementation ... I'm not sure right now if this is a limitation of the underlying protocol or not

if we can make a stack safe flatMap, we can also implement Sync[Observable] and Async[Observable] at the very least 😉
we might be able to implement that stack safe flatMap even sooner, without breaking binary compatibility, but I remember trying it and being very challenging

this needs experimentation before deciding whether it's a good idea or not

Refactor Iterant to not have so many operators that depend so much on Sync — e.g. operators should depend on Monad, MonadError, Defer, etc, as Sync should only be needed when we're suspending actual side effects

I'm not sure if we can remove some of that dependence on Sync right now, without breaking binary compatibility
whatever we can do sooner, we'll do sooner
given the long time frame we are talking about, we might be talking about refactoring Iterant to use the future Cats-Effect 3.0 type class hierarchy

Remove all @deprecated symbols
...

My wishes are modest and could target 3.x.x line. I'm not in rush for 4.0.0 considering how long it took us to get to 3.0.0. And Cats-Effect 3.0 will most likely drain our resources.

stack traces (already mentioned)
Polymorphic Thread.interrupt support ( #983 )
Overhaul https://monix.io/ Documentation - I feel like it is harder to navigate and looks worse than github sites or whatever is Akka doing. For instance, everything about Task is on one page  and it's pretty "narrow" so there's a lot of scrolling. Might be nice to read on a phone but as our docs grow I think we should be able to split it into different sections without requiring a lot of clicks to get there. Font in code snippets could probably be better too. I'm not really knowledgeable about design but that's my subjective feelings. :D

Better stack traces, preferably opt-in, possible solutions need to be investigated

I'd say it should be opt-out. If there is a performance impact, most people won't notice it but the feature will be useful for everyone. but that's something we can discuss when we have anything

Provide bi-functor Task and Coeval implementations, possibly in their own sub-project?
Not sure if we should, this needs to be discussed — I don't believe in the approach, but there are some people that do

I've grown to really like it. Well, I didn't actually use it in a project yet but I usually follow a standard pattern of F[Either[E, A]] where E is an error which is recoverable and F.raiseError is either not recoverable or when I handle all errors the same way. To me, Bifunctor is just taking this common pattern and embedding it. I don't buy performance argument but ergonomics are better (it's covariant and there is no need to wrap to EitherT to get shorcircuiting on E) and it allows cool stuff like returning UIO in an attempt.
ZIO is providing type aliases, something like Task[A] = ZIO[Any, Throwable, A] and IO[E, A] = ZIO[Any, E, A] to not require dealing with an error all the time. I don't know how well it does in practice, I assume it often infers to ZIO anyway. Different type aliases and return types in methods are extra complexity and something you need to learn even if you just want monofunctor.
I wonder how could we provide it without making it the default and still be compatible with "normal" Task.

As an alternative, maybe a nicer EitherT would be better (e.g. one that is covariant, maybe with better performance as the one in Cats is not representative of what can be done)

Covariant EitherT would be cool as well. Not sure if it's good enough in comparison to Bifunctor but it should be useful even if we have both. I'm attending ZIO Hackaton next week. Maybe there will be someone interested in contributing to Monix as well so I could guide this someone to create a prototype. It should be relatively simple if we disregard performance for now.

I'm not in a hurry for a binary breaking 4.0.0 either, this is the far future we're talking about.
However we might prepare at least some stuff for it, on a separate branch maybe, because opportunities present themselves — for example if Cats or Cats-Effect break binary compatibility, then we can do so too. I don't predict that will happen soon though and it is my wish for Monix to be fairly stable going forward.
Good points on the monix.io documentation and integrating with Java's Thread.interrupt.
We'll open separate issues for these and for bifunctors and discuss implementation ideas there.

I will jump in only as a user but bifunctor and stacktraces are two game changers I would like to have. And similar to @Avasil, in my usecases performance is the last concern.

Hey there! Great to see this discussion has started.
I'd like to say that performance is an important quality of Monix and it's quite important for me! I believe some of the items in this list are great (better stack traces are important), but I would love to see more PRs to make Monix even more performant than it is today.
I use Monix heavily in Bloop for fast scheduling of various tasks on machines with lots of cores. For example, we're heavy user of observer/observables to model many of the performance-sensitive build server internals. I haven't seen obvious performance bottlenecks with the current implementation --I haven't really profiled it either-- but the faster scheduling, context management and task creation is the faster we will build Scala code. Building code fast is pretty much all Bloop needs to do and we rely heavily on Monix to not get in the way of that (and we're really satisfied with it so far!).
I'm planning to run some benchmarks when we upgrade to 3.0.0 to see if the latest merged optimizations have an effect in our particular use of Monix APIs. That should shed more light on whether 3.0.0 is fast enough and we would/would not benefit from further performance work. Not sure if it'll be an apple-to-apples comparison but will offer us some insights.
Until I run those experiments though, performance work always gets a :+1: from me -- I love it that the use of powerful Monix abstractions doesn't come with a runtime cost. It allows people to use Monix in areas where it has traditionally not been able to model programs with such a level of abstraction (e.g. developer tools/compilers/who knows what else).
Thanks for all of the work you guys put into this library and hope that whatever you end up doing you keep pushing the limits of what Monix currently enables Scala developers to do and how they do it.

Thanks @jvican, performance is always a priority.
And in case you see any regressions after an upgrade, it's a mistake that can be rectified.

Personal priority (in order) for our use case at work is

Stack traces that work with Task/Coeval
Bifunctor (not EitherT, using that is quite painful)

@mdedetrich 👍


The use of regularization

Thank you for the awesome code!
I observe serious overfitting on my own data using this code.
Does deeplab-v3-plus any regularization at all?

This is a good point. Yes, they use l2 regularization with weight_decay=0.00004, they also use batch_norm_decay=0.9997, which is different from keras default value of 0.99.
I dont have this in my implementation, but you can add it and make pull request

@bonlime Probably also dropout is different. have you checked?

@bhack  #4 it looks like everything is correct with dropout

Oh ok was already fixed.

@ChristianEschen
This model is made mainly for fine-tuning, and because of that don't use regularization as in the original paper. You can notice, that all models in Keras.applications also don't have regularization for the same reason. You can add regularization by iterating over all layers in defined model. Don't forget to compile the model after it.
for layer in model.layers: layer.W_regularizer = l2(...)


Added ECS ProxyConfiguration, DependsOn,  StartTimeout and StopTimeout parameters

Also added other new parameters such as: ProxyConfiguration for TaskDefinition and  DependsOn, StartTimeout and StopTimeout for ContainerDefinition.

@markpeek hey, could you please merge this pull request? Anything else I need to do? Thanks, Yoni.

I don't see that these changes are in the documentation or released to CloudFormation yet. Holding pending release.

lol! I see I opened issue #1378 to track adding these changes. While the spec files tend to lag, I'm surprised the documentation isn't reflecting these additions.

That's so strange I can see what you are saying but I swear I've seen this in the release notes about a week ago and obviously I read the documentation in order to code this. Will investigate tomorrow. Thanks.


Fixed #33917: Move app_config initialization inside if block

Optimize ModelBase.__new__ by moving variable app_config inside the if block where it is used. app_config is not used outside this if block.

Closing per ticket.


Auto save files before running

Hi Spyder team,
In Spyder 4, the Python files are automatically saved when I clicked "run".  This is gone in Spyder 5.
Is there a way to bring back this feature?  (Or has this become configurable somewhere?  I don't seem to be able to find it.)
Thanks!

Hi @jsh9,
Indeed we removed that behavior in Spyder 5, @ccordoba12 there's an option for this?

This is working fine for me on Linux. A couple of questions for you @jsh9:

Are you running untitled files? I mean, files that you haven't saved to disk yet? In that case, we can run those files without asking the user to save them (that was a very requested feature).
What operating system are you using?

@steff456, I don't understand how you were able to reproduce this. Could you post an animated gif of the process you followed?

Hi @ccordoba12 , I was not running untitled files.  Instead, I ran saved .py files: I opened them from the hard drive, made changes, and clicked "run", and they were not saved.
I was using macOS Catalina.

Then I think this is a problem in Mac only because I can't reproduce it on Linux.

@ccordoba12 what I understood @jsh9 is that he wants to go back to saving the file if he presses run. I'm not sure if we completely removed that behavior or if there is a way to set that option in preferences.

Oh, I see what you mean. Well, that option is here:

@jsh9, is it activated for you and still Spyder is not saving files before running them?

Yes, I'm seeing this option now (I didn't know where to find this option before).  I guess the default was changed from "yes" (in Spyder 4) to "no" (in Spyder 5).

I'm closing this issue because it isn't actually a bug.


Integration error in webpack

Hi Team,
I have install this package yarn add phaser-plugin-virtual-gamepad and in my game state i used    game.vjoy = game.plugins.add(Phaser.Plugin.VJoy); i am getting error as
phaser-split.js:9569 Uncaught TypeError: Cannot set property 'game' of undefined     at webpackJsonp.236.Phaser.PluginManager.add (phaser-split.js:9569)     at _class.create (Game.js:128)     at webpackJsonp.236.Phaser.StateManager.loadComplete (phaser-split.js:8142)     at webpackJsonp.236.Phaser.StateManager.preUpdate (phaser-split.js:7905)     at Game.updateLogic (phaser-split.js:15011)     at Game.update (phaser-split.js:14884)     at webpackJsonp.236.Phaser.RequestAnimationFrame.updateRAF (phaser-split.js:43063)     at _onLoop (phaser-split.js:43046)
Please guide me

Hi deepackgd. This is probably an error with how scripts are being loaded in your webpack process and not a code functional issue related to the plugin.

Furthermore, you may follow this tutorial perhaps the author is not using webpack it might be useful for you: https://ourcodeworld.com/articles/read/311/implementing-a-free-touch-joystick-for-your-game-in-phaser-js
Let us know how it goes, cheers!


Flytekit v0.7.0 release

TL;DR
New release v0.7.0
Type

[ ] Bug Fix
[x] Feature
[ ] Plugin

Are all requirements met?

[x] Code completed
[x] Smoke tested
[x] Unit tests added
[x] Code documentation added
[x] Any pending items have an associated Issue

Complete description
NA
Tracking Issue
https://github.com/lyft/flyte/issues/301
Follow-up issue
NA

Codecov Report

Merging #105 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #105   +/-   ##
=======================================
  Coverage   82.24%   82.24%
=======================================
  Files         208      208
  Lines       13266    13266
  Branches     1106     1106
=======================================
  Hits        10911    10911
  Misses       2092     2092
  Partials      263      263

Impacted Files
Coverage Δ

flytekit/__init__.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Qualified name for FenwickTree: FT vs FW

Which one is preferable?
Although the initials are FT, the unit test writes fw.

Use FT.


Ensure every tool has the same argparse arguments for the same things.

https://github.com/googlefonts/fontbakery/blame/9518c59f85031f4904d5b0552730c59e711ac399/BRIEF.md#L24 says that all fontbakery tools will work in a similar/uniform way.
Concretely this means that every tool must have the same argparse arguments for the same things.
That is currently not the case.
For example, currently these 2 have font and ttf_font, and one has a help text and the other does not.
https://github.com/googlefonts/fontbakery/blob/972da4505839332ff083843bc4e5556fc050109c/fontbakery-fix-ascii-fontmetadata.py#L52
https://github.com/googlefonts/fontbakery/blob/26bf4709c1714025e7c04c2fbb19f868081b5e32/fontbakery-fix-familymetadata.py#L9
In addition to font files as the main required input, the other common optional args will be autofix and verbose, which (per https://github.com/googlefonts/fontbakery/blame/9518c59f85031f4904d5b0552730c59e711ac399/BRIEF.md#L48) should be required to show the "OK" confirmations.
To implement this and make sure it stays implemented I suggest that a Test Driven Development approach is required:

[x] write a test that ensures that each executable tool has the args in an 'expected' list (font, verbose) and there are not any args that are not in an 'optional' list (autofix)
[x] ensure this test runs via travis on all PRs
[x] fix the tools until the test passes

I only miss the ability to pass -o,--output (or maybe --prefix) to define the prefix of the markdown and JSON output files

Why is shell redirection insufficient for this?

Alright! There we go!
https://github.com/googlefonts/fontbakery/commit/514d17de5de19f37eff2777e0066199b71bc8a0f
is an attempt at building the foundations of a command line arguments validator for fontbakery.
I have refactored most scripts so that they adere to a consistent coding style, but I haven't yet modified the set of arguments that each use.
There's also a test_args.py script that we'll likely use on Travis soon.
Next task here is to really consolidate which is the minimal set of mandatory arguments that we want to have accross the whole set of scripts and then adjust that in the checker script.
The checker script has 2 lists:

mantatory_args
optional_args

There's a few more info in comments in the patch itself.

I reviewed that commit, looks fine; I think the tests should be added to travis and run via some typical python test runner like nose or whatever

The tests are already running on Travis, but not with nose or any testing framework. The test_args.py script is simply invoked via .travis.yaml setup.

Regarding testing, maybe fontbakery as a whole could benefit from a testing framework at some point, but that's not a top priority at the moment.

@davelab6 do you want to change the set of command line attributes used in each of the tools? Or are you already familiar with the way the commands work thus preferring to keeping them with the current command "signature" ?


Added two config options: shouldSortItems and renderSelectedChoices

Hey @maximmig,
The shouldSortItems option is working as expected however the renderSelectedChoices option appears to hide all choices in the dropdown - is this intentional? To replicate, change the default value to false.
Thanks

OMG, definitely not 😞 I pushed a fix for this and two tests as well, thanks!

Thanks!

You're welcome, Josh, more to come! 😄


Feature description
I want to use date time picker as i have requirement in many peojects.If you add this component it will be so helpful.
Affected component/components
No response
Additional Context
Additional details here...
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues and PRs

Seconded.
And / Or standalone time input selector

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

Let's try:
https://shadcn-datetime-picker-xi.vercel.app
https://github.com/huybuidac/shadcn-datetime-picker

Thanks it is very useful.
On Fri, Oct 18, 2024, 10:57 PM Bui Dac Huy @.***> wrote:

Let's try:
https://shadcn-datetime-picker-xi.vercel.app
https://github.com/huybuidac/shadcn-datetime-picker
—
Reply to this email directly, view it on GitHub
https://github.com/shadcn-ui/ui/issues/3551#issuecomment-2422929133, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A2FWTRHB5WSSWIW5K7YGECTZ4FAJHAVCNFSM6AAAAABGQOXSO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRSHEZDSMJTGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

I have created a Date Time Picker component too. Feel Free to have a look
https://codesandbox.io/p/live/74ecfdc5-a613-4fcf-bfbf-ff601e5a7a54


Don't assume URI can parse everything.

https://github.com/orientation/orientation/issues/200

Thanks for this @brupm :-)


Update ru_ru.json for 1.20.1/multi

Migrated ru_ru.json from 1.19 branch
Added missing lines
Improved some consistency

Wow that was fast, appreciate your time!


How to change default_events for IRC service?

How do I make the IRC service respond to the issues events as well?
class Service::IRC < Service
  default_events :push, :pull_request
end

Opening this as an issue vs. stack overflow question because I couldn't find documentation on how to do this. I can contribute docs if I can figure out how to do it.

Forgive me for being dense... how would one use the info provided in the linked documentation to update the settings for the IRC service hook of a given repository? Seems like that documentation is specific to Web hooks and not service hooks.

curl -X PATCH -d '{"add_events": ["issues","issue_comment"]}' https://api.github.com/repos/:owner/:repo/hooks/:id would work. That, for example, would add the issues and issue_comment events to your hook. You'd need to replace :owner, :repo, and :id with the correct values. :grinning: Feel free to contact<EMAIL_ADDRESS>if you have specific questions. We're happy to help.

Thanks! That made it perfectly clear :)


System crashes after deleting a Class slot

I had created a Class slot, saved it, and then realised that I didn't need it. I double clicked the text, and erased it. I then clicked the check mark. Gt reported SubscriptOutOfBounds: 1.
crash.dmp.log
PharoDebug.log
I clicked on the debug lightning icon. The system displayed the beach ball, and required a forced restart. The Image had become 1.2GB

This problem happens when the text of the Slot is edited and cleared. Deleting the slot by single clicking to select it, and then pressing delete, works successfully.


chore: improve the snippets menu for the pre-request script

Please review this PR (https://github.com/Kong/insomnia/pull/7172) firstly as current one is based on it
Changes:

[x] added more menus
[x] categorized snippets into different menus
[x] enable basic auto code complete - copied from this nice PR (https://github.com/Kong/insomnia/pull/7104)

How to test
Try to play with snippet menus and see if there is any weird thing.

Please clean up the commits in this PR.


Type hinting enums

I don't think it's a good idea to type hint enums in the function signatures as strings. That gives insight to the fact that we are setting the enum variables to be strings, whereas they could just as easily be ints or anything else.
Not sure how we should do this.

We could define a new type (enum package)

Actual type hinting has been removed. In order to keep classes in separate files and not get circular dependency issues, some imports have to be moved to the bottom of the file. However this means that we can't statically type hint. Instead, input / output types are specified in the function docstring.


initial task : Notebok using MDF analysis

While working with MDF models based on conditions, I encountered an error with image generation. The code runs properly, but terminates with the error message 'FileNotFoundError: [Errno 2] No such file or directory: 'condition_based.png'' and does not display the desired output. However, upon checking the folder, I found that the 'png' folder was created. It seems that the image was not properly saved, but the folder creation suggests that the code attempted to do so. Further investigation may be needed to determine the root cause of this error.

@thesakshidiggikar Thanks for your PR. I would resolve the issue if you are still having it of generating graphs on your system with graphviz. I would try running python abcd.py -graph in the examples/MDF folder and check the graphviz docs for windows, before using this in a jupyter notebook.
Also, for your recommender example, I would try running the example using EvaluableGraph before trying to generate the graph. If there is any problem with the setup of the graph it will be found at run time, rather than at the graph generation time when it might be harder to debug. At first glance in your example you are trying to output a list of strings and then use this in a mathematica expression which will fail.

Also, can you merge in the latest code from the development branch and change this PR to aim at the development branch in the main mdf repo.

Closing all previous Outreachy application period pull requests. Thanks again for your interest in this project.


chore(gulp): avoid watching tmp files

@Foxandxss : very minor change is ready for review and merge.

What is that globbing going to filter?

Temporary files generated by Emacs during editing.

Actually, I don't think that we should be watching any dot files, but in particular not autosave files. Maybe that line can be changed simply to **/.?*. Let me know what you prefer.

FYI, I changed it to **/.?*.

Actually, this still isn't solving my original problem (of getting browser page refreshes when Emacs does an auto-file backup). So I'll close this for now.


[CT-1477] Ensure that all logbook special entries are included in the relevant logging events

The legacy logger included a number of special additions to logging, implemented by logbook.Processor classes, such as UniqueID, TimingProcessor, DbtStatusMessage, etc.  These are generally magically added to log lines by using "with", like "with UniqueID".
Go through all of these magical data additions and ensure that the matching logging events contain the same information. In particular, we want to make sure that we have unique_ids where necessary.
This is part of the structured logging initiative, such as we see in #6136.

Events from a sample dbt run command that included "unique_id" by the logbook Processor UniqueID class: NodeStart, LogStartLine, NewConnection, NodeCompiling, CompilingNode, WritingInjectedSQLForNode, TimingInfoCollected, NodeExecuting, MacroEventDebug (bad name... how about JinjaDebug?), ConnectionUsed, SQLQuery, NewConnectionOpening, SQLQueryStatus, SQLCommit, ConnectonClosed2 (lets rename or combine and get rid of the 2), LogModelResult, NodeFinished.
I haven't looked at every one yet, but the ones that are executed via the context 'log' method are the most problematic. I don't see that the method has access to the model, so I'm not sure how we would handle that. We could pass the unique_id in on the log call, we could write our own context manager to contain some of that information (if we want current node_info we'd have to update it whenever it changes), we could revamp how we internally log in the jinja code. Every context log call uses the same logging event, so it's not particularly "structured".
In addition, other logging events with logbook Processor data: TimingInfoCollected, NodeFinished, EndResultSummary, ConcurrencyLine, NodeStart, LogHookStartLine, LogHookEndLine.

It looks like using contextvars will be a good way to solve this issue, and is a mechanism used by other logging frameworks.


test: accelerator="auto" [RFC]

What does this PR do?
maximize testing, so in env with GPU always run all tests with GPU
otherwise running tests only on CPU is wasting resources...
Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[ ] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[ ] Did you list all the breaking changes introduced by this pull request?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃
cc @borda @akihironitta

If the Trainers are not set to fit/validate/tune.... we should not set this flag.

yes, agree, this would need some more cleaning, but wanted to iterate the main idea

@carmocca manually went throw all cases when we fall fit in our tests and if an appropriate added auto option...
-> mind check now again :rabbit:

A problem with this change is that CI will not tell you whether these are passing under a GPU job since we don't have a job that would test them after #13651. You should completely run the test suite in our cluster manually to verify. Otherwise users will see failures when they are run locally with a GPU machine.

A problem with this change is that CI will not tell you whether these are passing under a GPU job since we don't have a job that would test them after #13651. You should completely run the test suite in our cluster manually to verify. Otherwise users will see failures when they are run locally with a GPU machine.

We can rethink CI in following uodate, but at least running locally on GPU you will get wider/genelized testing...

I don't understand yet what the goal is.

At this moment, when you run all tests most are running on CPU and ignoring GPU, which is a very marginal use of PL users, they want to use GPU, so why we are testing mostly CPU configuration and then just believe that all would work also with GPU?
And even if you want to test on GPU you can't without this rewrite, in the other hand with setting GPU visibility you can very simply force run all on CPU even if you use a GPU machine (but not vice versa)...

Recently @carmocca made it so that only tests annotated with RunIf(gpus>0) would run on the GPU CI. So adding auto to any of the tests here would not make a difference. These seem to be two conflicting directions.

yes, they won't run on CI, which can be changed later...

Also, in general we would have to go through each test and check what its intentions are. For example, in configuration tests where we assert fixed values, e.g. explicitly the device, the test could fail if we just blindly added "auto" and it ran on e.g. GPU, TPU or IPU etc.

yes, that probably would need to be checked but it will be covered with them running all tests on GPU

Just some thoughts!

I understand we need to test everything on each device to ensure it won't break, but we never did that, and recently GPU CI time was reduced significantly, but now we are adding more tests to make it even higher (maybe?).
Did we see any issues related to these tests where it worked on CPU but failed on GPU/TPU?
Many of them are related to the model checkpointing, progress bar updates, callbacks (some of them), loops, etc., which I don't think will have any effect based on the device used.

I suggest we close this because of the limitations described in the comments above and because this will get implicitly tested the day we start defaulting to auto in the Trainer. Happy to continue the discussion if you feel differently.


Feature/fxls8974 driver

Added drivers for the fxls8974 accelerometer, tested over I2C on the mimxrt1040_evk board.

While fixing bugs I found TODO comment in samples/sensor/sensor_shell/sample.yml which should've been deleted since the https://github.com/zephyrproject-rtos/zephyr/issues/63414 is resolved.

doc: updated copyrights

@CZKikin please check https://docs.zephyrproject.org/latest/contribute/guidelines.html#contribution-workflow, the workflow in Zephyr is that you need to interactively rebase commits to fix review issues. Please make sure you are following the process


PPL SHOW with no argument -> runtime error

Reported by ansley b manke on 20 Jun 2017 23:44 UTC
User Marco van Hulten ran into this:
ppl show
 **ERROR Symbol not found
  show
At line 103 of file cmderr.F
Fortran runtime error: Expected P edit descriptor in format
(A1,000X,'^')
       ^

this is in cmderr, which writes a nice error message, such as
yes? ppl show nosymbol
 **ERROR Symbol not found
  show nosymbol
       ^

The empty argument is causing an incorrect FORMAT statement to be created.
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/2543

Comment by ansley.b.manke on 21 Jun 2017 19:32 UTC
Fixed in ppl/symlib/cmderr.F

Comment by ansley.b.manke on 23 Jun 2017 23:27 UTC
Changing things to send these errors through Ferret's ERRMSG routine. Somehow the PPLUS routine CMDERR was doing something funny and writing a fort.41 file, even though the unit number is correct.
Do the same for the routine ppl/plot/spwn.F which is used to report completely incorrect PPLUS commands, e.g.
yes? PPL nonsense
or
yes? plot/set myvar
yes? ppl nocommand
These were handled correctly, but for future error handling, good to have messages follow the same path through the code.  There are no doubt more places where PPL error handling needs improvement.


Use deviceType/deviceVersion from the endpoint table instead of hardc…

…oding it in helper-endpointconfig.js
Problem
Currently deviceVersion and deviceType are hardcoded into helper-endpointconfig.js
This results into the descriptor cluster device-list to always returns:
[1638443328854] [24733:51031451] CHIP: [ZCL] ReadAttributesResponse:
[1638443328854] [24733:51031451] CHIP: [ZCL]   ClusterId: 0x0000_001D
[1638443328854] [24733:51031451] CHIP: [ZCL]   attributeId: 0x0000_0000
[1638443328854] [24733:51031451] CHIP: [ZCL]   status: Success                (0x0000)
[1638443328854] [24733:51031451] CHIP: [ZCL]   attribute TLV Type: 0x16
[1638443328854] [24733:51031451] CHIP: [TOO] OnDescriptorDeviceListListAttributeResponse: 1 entries
[1638443328854] [24733:51031451] CHIP: [TOO]   [1]: {
[1638443328854] [24733:51031451] CHIP: [TOO]     Type: 0
[1638443328854] [24733:51031451] CHIP: [TOO]     Revision: 1
[1638443328854] [24733:51031451] CHIP: [TOO]   }

This fixes https://github.com/project-chip/zap/issues/332

I think this fixes #279 too, at least for my purposes.


Add spanish translation for-richard-bondi-bitcoin-cli-regtest

this file is in the root folder as opposed to the austin-bitcoin-developers directory.

@BlueeeMoon, thanks for the contribution!
This file is in the root folder and should be moved to the austin-bitcoin-developers directory before merge.

Thank you!!, I have changed it.


How can I stop to receive messages?

Hi @ViLsonCake !
This is a really nice project, I really liked it! I tried using your bot and it works very nice. But I would like to stop receiving messages from it now and there is no command to stop it yet.

Thanks @JeanExtreme002 for the feedback!
I'll now look into solving this issue.


Spike with a deep cut of smart agent code deleted

This is a spike - running it via CI to see what tests pass, and it will get cut out into smaller PRs as needed.

I have removed in separate PRs the elements identified in this PR, except for filters. We will need to remove translatesfx first.


Create Varchar column has wrong default syntax when  in UI

System information:

Operating system (distribution) and version Win10
DBeaver version 7.3.5 EA

Connection specification:

Database name and version MySQL

Describe the problem you're observing:
Steps to reproduce, if exist:

Open Columns tab in a table properties
Create a column of varchar type without adding anything to default settings.

Expected: SQL statement with full varchar definition appears and the new column is created
Actual result:

the column cannot be created,
the error about wrong SQL syntax appears.
Varchar definition is missed in the SQL statement:

ALTER TABLE test_review.test_copy ADD column1 varchar NULL; (has to be varchar (some_numbers) NULL)

This problem applies to all columns from the list (mariaDB also). Example - varbinary type has to be also with parameters

Doesn't work since at least version 7.3.0

Fixed in 21.0.0
Now the default type when creating a new column is varchar. Actual for Oracle also.

verified


Attempted to redefine property 'error'.  no stack

🐛 Bug Report
App compiles on Android emulator, but stuck on:

I'm not sure where to even start solving this problem.
To Reproduce
Not sure if relevant, but I fixed an Error: Unable to resolve module './index.android' by adding back index.android.js. I copied the contents of my index.js file into index.android.js.
I start an emulator emulator @Pixel_2_API_28 -netdelay none -netspeed full.
Then start React Native Debugger.app.
Then react-native run-android.
The following is is the output from ./gradlew installDebug --warning-mode=all:
> Configure project :app

Installing unimodules:
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/@unimodules/core
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/@unimodules/react-native-adapter
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/expo-barcode-scanner
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/expo-camera
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/expo-constants
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/expo-file-system
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/expo-image-manipulator
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/expo-location
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/expo-permissions
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-barcode-scanner-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-camera-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-constants-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-face-detector-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-file-system-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-font-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-image-loader-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-permissions-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-sensors-interface
<EMAIL_ADDRESS>from /Users/howardwkim/mementum/client/node_modules/unimodules-task-manager-interface
The TaskInternal.executer property has been deprecated and is scheduled to be removed in Gradle 5.0. There are better ways to re-use task logic, see https://docs.gradle.org/4.7/userguide/custom_tasks.html#sec:reusing_task_logic.
        at sentry_2vgic3h3auwbds8l3avzca8to$_run_closure1$_closure6.doCall(/Users/howardwkim/mementum/client/node_modules/react-native-sentry/sentry.gradle:19)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)
w<EMAIL_ADDRESS>(78, 55): Parameter 'context' is never used
w<EMAIL_ADDRESS>(82, 55): Parameter 'context' is never used
w<EMAIL_ADDRESS>(86, 55): Parameter 'context' is never used
w<EMAIL_ADDRESS>(90, 53): Parameter 'context' is never used
w<EMAIL_ADDRESS>(94, 30): Parameter 'context' is never used

> Task :unimodules-core:compileDebugJavaWithJavac
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :expo-barcode-scanner:compileDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Users/howardwkim/mementum/client/node_modules/expo-barcode-scanner/android/src/main/java/expo/modules/barcodescanner/scanners/ZxingBarCodeScanner.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :expo-camera:compileDebugJavaWithJavac
Note: /Users/howardwkim/mementum/client/node_modules/expo-camera/android/src/main/java/expo/modules/camera/CameraViewHelper.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

> Task :expo-file-system:compileDebugJavaWithJavac
Note: /Users/howardwkim/mementum/client/node_modules/expo-file-system/android/src/main/java/expo/modules/filesystem/FileSystemModule.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :expo-location:compileDebugJavaWithJavac
Note: /Users/howardwkim/mementum/client/node_modules/expo-location/android/src/main/java/expo/modules/location/taskConsumers/GeofencingTaskConsumer.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :react-native-camera:compileDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Users/howardwkim/mementum/client/node_modules/react-native-camera/android/src/main/java/com/google/android/cameraview/Camera2.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :react-native-fs:compileDebugJavaWithJavac
Note: /Users/howardwkim/mementum/client/node_modules/react-native-fs/android/src/main/java/com/rnfs/RNFSManager.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

> Task :react-native-sentry:compileDebugJavaWithJavac
Note: /Users/howardwkim/mementum/client/node_modules/react-native-sentry/android/src/main/java/io/sentry/RNSentryModule.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :app:installDebug
08:04:38 V/ddms: execute: running am get-config
08:04:38 V/ddms: execute 'am get-config' on 'emulator-5554' : EOF hit. Read: -1
08:04:38 V/ddms: execute: returning
Installing APK 'app-debug.apk' on 'Pixel_2_API_28(AVD) - 9' for app:debug
08:04:38 D/app-debug.apk: Uploading app-debug.apk onto device 'emulator-5554'
08:04:38 D/Device: Uploading file onto device 'emulator-5554'
08:04:38 D/ddms: Reading file permision of /Users/howardwkim/mementum/client/android/app/build/outputs/apk/debug/app-debug.apk as: rw-r--r--
08:04:39 V/ddms: execute: running pm install -r -t "/data/local/tmp/app-debug.apk"
08:04:39 V/ddms: execute 'pm install -r -t "/data/local/tmp/app-debug.apk"' on 'emulator-5554' : EOF hit. Read: -1
08:04:39 V/ddms: execute: returning
08:04:39 V/ddms: execute: running rm "/data/local/tmp/app-debug.apk"
08:04:39 V/ddms: execute 'rm "/data/local/tmp/app-debug.apk"' on 'emulator-5554' : EOF hit. Read: -1
08:04:39 V/ddms: execute: returning
Installed on 1 device.

BUILD SUCCESSFUL in 19s
471 actionable tasks: 250 executed, 221 up-to-date

From Metro Bundler:
Loading dependency graph, done.

 DELTA  [android, dev] ../../index.android.js ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100.0% (1/1), done.

::ffff:<IP_ADDRESS> - - [15/Mar/2019:14:26:16 +0000] "GET /index.delta?platform=android&dev=true&minify=false HTTP/1.1" 200 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36"

Expected Behavior
Expect app to start.
Code Example
Environment
  React Native Environment Info:
    System:
      OS: macOS 10.14.2
      CPU: (8) x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
      Memory: 80.39 MB / 16.00 GB
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 11.9.0 - ~/.nvm/versions/node/v11.9.0/bin/node
      Yarn: 1.13.0 - /usr/local/bin/yarn
      npm: 6.9.0 - ~/.nvm/versions/node/v11.9.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        API Levels: 23, 24, 25, 26, 27, 28
        Build Tools: 23.0.1, 24.0.2, 25.0.0, 25.0.2, 26.0.1, 26.0.3, 27.0.3, 28.0.2, 28.0.3
        System Images: android-28 | Google Play Intel x86 Atom
    IDEs:
      Android Studio: 3.3 AI-182.5<IP_ADDRESS>14842
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.6.3 => 16.6.3
      react-native: 0.58.6 => 0.58.6

Updating to 0.59 resolves this issue.


Add out-of-range/invalid events to BXNumberInput

Based on the work in: https://github.com/carbon-design-system/carbon-custom-elements/pull/374

Going to assign myself for now ... going to try and take a look at it this week


Set zone from EndpointSlice for xDS Endpoint

Description:

xDS Endpoint's zone will be needed as first step when user wants to apply priority levels or zone aware routing for cluster's load balancing to reduce cost.

[optional Relevant Links:]

https://github.com/envoyproxy/gateway/issues/1909#issuecomment-2126782250

hey @aoledk thanks for driving this work,
before we implement this, we as a community need to align on what the feature is, is it

Auto Zone Aware Routing where a user sets a global field to enable this, and envoy proxy prioritizes endpoints in the same zone based on its zone ?
Open Questions:

is this granular enough ? there are only 2 levels here - local or not local

Priorites for BackendRefs - Prioritizes one backendRef over another backendRef within the same HTTP Rule


Update Composer dependencies (2021-06-08-00-08)

Visual regression test passed!
View the visual regression test report


Returning list of elements as NodeList

In my opinion in waff-query could be useful returning list of elements as nodelist.

Nope! Nope nope nope nope

Why not @artur9010 ? Actually I was wondering about it as an optional argument.

Included in new version as:
var divs = qq('body', {
  array: true // always output as Array. true by default.
});
var divs = qq('body', {
  array: false // output as HTMLCollection or NodeList or Array.
});


can't parse kubeconfig correctly with lithops 2.2.13

I have a simple code which run on  lithops 2.2.9 + runtime ibmfunctions/lithops-ce-3.8.5-2.2.9:1.0.0 successfully.
code is
import lithops

iterdata = ['Gil', 'Dana', 'John', 'Scott']

def add_value(name):
    return 'Hello ' + name

if __name__ == '__main__':
    lt = lithops.FunctionExecutor(mode="serverless",
            backend='code_engine',
            log_level='DEBUG')
    lt.map(add_value,  iterdata)
    print (lt.get_result())

lithops_config file is
lithops:
    storage: ibm_cos
    storage_bucket: lithops-batch

    mode: serverless
    workers: 1000

serverless:
    backend: code_engine
    runtime_memory: 256
    runtime : ibmfunctions/lithops-codeengine-v38:2213

code_engine:
    kubectl_config: ~/.kube/config
    docker_user: my-name
    runtime_cpu: 200m

ibm_cos:
    endpoint    : https://s3.us-south.cloud-object-storage.appdomain.cloud
    private_endpoint: https://s3.private.us-south.cloud-object-storage.appdomain.cloud
    api_key     : xx

Executed successfully.

Now I update lithops to 2.2.12 via pip3 install -U lithops==2.2.13
Using lithops 2.2.13 + runtime ibmfunctions/lithops-codeengine-v38:2213
code and lithops config file NOT change and run again, but my execution fail with error

2020-12-10 15:51:08,306 [INFO] lithops.config -- Lithops v2.2.13
2020-12-10 15:51:08,306 [DEBUG] lithops.config -- Loading configuration
2020-12-10 15:51:08,306 [DEBUG] lithops.config -- Getting configuration from /Users/shiyan/work/coligo/lithops/.lithops_config
2020-12-10 15:51:08,327 [DEBUG] lithops.config -- Loading Serverless backend module: code_engine
2020-12-10 15:51:08,707 [DEBUG] lithops.config -- Loading Storage backend module: ibm_cos
2020-12-10 15:51:08,764 [DEBUG] lithops.storage.backends.ibm_cos.ibm_cos -- Creating IBM COS client
2020-12-10 15:51:08,764 [DEBUG] lithops.storage.backends.ibm_cos.ibm_cos -- Set IBM COS Endpoint to https://s3.us-south.cloud-object-storage.appdomain.cloud
2020-12-10 15:51:08,765 [DEBUG] lithops.util.ibm_token_manager -- Using IBM COS API Key - Reusing Token from local cache
2020-12-10 15:51:08,768 [DEBUG] lithops.util.ibm_token_manager -- Token expiry time: 2020-12-10 16:50:56.863872+08:00 - Minutes left: 59
2020-12-10 15:51:08,816 [INFO] lithops.storage.backends.ibm_cos.ibm_cos -- Created IBM COS Storage client - Region: us-south
2020-12-10 15:51:08,816 [DEBUG] lithops.serverless.backends.code_engine.code_engine -- Creating IBM Code Engine client
2020-12-10 15:51:08,852 [ERROR] lithops.serverless.serverless -- There was an error trying to create the code_engine serverless backend
Traceback (most recent call last):
  File "first-test.py", line 9, in <module>
    lt = lithops.FunctionExecutor(mode="serverless",
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/lithops/executors.py", line 127, in __init__
    self.compute_handler = ServerlessHandler(serverless_config,
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/lithops/serverless/serverless.py", line 44, in __init__
    raise e
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/lithops/serverless/serverless.py", line 39, in __init__
    self.backend = ServerlessBackend(self.config[self.backend_name], storage_config)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/lithops/serverless/backends/code_engine/code_engine.py", line 65, in __init__
    self.region = self.cluster.split('//')[1].split('.')[1]
IndexError: list index out of range

Anything change on this part?
my kubernetst version is 1.18 (both server and client)

@JosepSampe @kpavel  it fails on reading some value from kube config file. Do you know what is wrong? For me it working, for some not...perhaps this value not always present?

Fix added in #490

@shiyan0109 just out of curiosity, what is the value of the cluster var you obtain in your kubeconfig file?

@JosepSampe please do not expect any particular format for the value of cluster. This highly depends on the component creating the Kubeconfig.
When we are working on Code Engine clusters as developers, the format is <cluster name>/<cluster id>. When we are using KinD clusters, it's <cluster name>.