Add provider auto-registration

we'll need to remember to tweak the pending Monitor PR (manager) with this as well. Maybe apply directly to the PR, so we don't forget later?

@martinsawicki Also the document db. I'll block this thread until we merge those 2.

about MOnitor, i don't know if we're going to merge that for the next release. The reason we kept it from 1.0.0 (even as Beta) was because we had issues with the REST API exposing a nameless way of creating children (so our defineFoo() would have no params). We started a discussion about that with the service team.
Even if we identify a subset of Monitor we could merge, we do not currently have anyone to work on it. So not sure about that one...
OK to wait for DocDB at least.

Addressed. Thanks!

@anuchandy Hey Anu, are you able to sign off at this point?

@jianghaolu DocDB mgmt was already merged - does anything have to be done to it as per the top remark?

DocDB already updated. Merging.


[Monitor Opentelemetry Exporter] Update Statsbeat Attach Type Naming

Packages impacted by this PR
@azure/monitor-opentelemetry-exporter
Describe the problem that is addressed by this PR
Updates Statsbeat Attach type names to follow new spec.
Checklists

[x] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[x] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


Max retries on podcast episodes

Hey everyone,
I got the issue with librespot which spammed my Folder var/logs with 22GB and made my Pi run out of diskspace.
The problem was that it tried to play a podcast episode which is not supported.
A log message is created for that.
But the problem here is that the log message keeps repeating as librespot retries to play all the episodes again.
So my /var/log/messages/ looked like this:
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:5psVgZsd1FKmqynemaGMzf" at position [1] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:61sI2sfZCDy1CVorNegftU" at position [2] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:4yPmY02A3TSzmrnIrLCDYe" at position [3] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:1ktT0FmYGUcVyIh2Rcs1M5" at position [4] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:1y5lbX4aitZDLcKXJ2wO3Y" at position [5] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:1GilsaJvjks37eHBHiEPn3" at position [6] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:5Gm9arSLMtjHBN8ltBKeYK" at position [7] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:3Semc5af0HOBbQNnL1mZwu" at position [8] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:0pgiQxgrNfiOB0cuRgWYPm" at position [9] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:6Drce4px7W5grjyXCP0GdF" at position [10] of 12
Sep 16 08:31:40 raspberrypi librespot[24622]: [2019-09-16T06:31:40Z WARN  librespot_connect::spirc] Skipping track "spotify:episode:0B0sqwQMmEpsZog4bH5siE" at position [11] of 12

This was repeating over 6GB (also in /var/log/syslog and /var/log/user.log) only with different timestamps.
It would be nice to have a fix for that and directly stop after x retrys if podcasts are not supported anyway.

Fixed with #381


_command_handler needs to be extensible

In CLI 2.0 we expose the no_wait parameter in the _command_handler method of the create_command method in CLICommandsLoader.  This method is not customizable, so I had to copy and modify the entire implementation from the base class.

It's tricky finding a balance between making everything extensible and suggesting to subclass. In this case, I'd subclasses would be required anyway so you could subclass and provide your own implementation of create_command and then _command_handler.
In Azure CLI case, even if _command_handler was extensible, you'd still have to override create_command for this.
This is related to https://github.com/Microsoft/knack/issues/12 but in that case, it was a single line you wanted to change to use a different class. Here, modifying _command_handler basically changes all of create_command anyway.
link to code in question: https://github.com/Microsoft/knack/blob/master/knack/commands.py#L106


"main" property in bower.json incorrect.

The main property in the bower.json is incorrect. So tools like wiredep do not work correctly with it.
It needs to be "main": "dist/impetus.js".
You can work around this with bower overrides.
This is a great utility I really like it.

+1


How can I make it work with vue router?

Hi I have an app that im manually SSR it using vue-server-renderer, Aparrently seems that this plugin doesnt work for any of the components that I have inside VueRouter ... take this as an example:
<template>

    <div class="main">

        <LazyHydrate> <!-- works --->
            <MenuBar/>
        </LazyHydrate>

        <RouterView/>

        <LazyHydrate> <!-- works --->
            <Footer/>
        </LazyHydrate>

    </div>

</template>

<template>

    <Page class="page-a">

        <template #body>

            <LazyHydrate> <!-- doesnt work --->
                <SomeComponent/>
            </LazyHydrate>

        </template>

    </Page>

</template>

Do you know what might be happening here? should it work normally with RouterView ?

never mind this was a mistake on my side.. it does works as expected


Fail to add a new repeatable or scheduled job.

class QueueMixin(object):
def get_form(self, request, obj=None, **kwargs):
    queue_field = obj._meta.get_field('queue')
    queue_field.choices = QUEUES
    return super(QueueMixin, self).get_form(request, obj, **kwargs)

Looks like the get_form method will fail if obj is None. And the queue_field is not use anyway. Should those two lines be removed?
I'm using django-rq-scheduler 1.1.0 (with Django 1.9.6, rq 0.6.0 and django-rq 0.9.1). When trying to add a new repeatable or scheduled job from /admin, the /admin/scheduler/repeatablejob/add/ endpoint gave me an error of:
AttributeError at /admin/scheduler/repeatablejob/add/
'NoneType' object has no attribute '_meta'
Request Method: 	GET
Request URL: 	http://localhost:9000/admin/scheduler/repeatablejob/add/
Django Version: 	1.9.6
Exception Type: 	AttributeError
Exception Value:
'NoneType' object has no attribute '_meta'
Exception Location: 	/home/**/virtualenv/p34/lib/python3.4/site-packages/scheduler/admin.py in get_form, line 16

Never mind. chassing has fixed this in his pull request.

Never mind. chassing has fixed this in his pull request.


[Bug] [API] Task parameter check error

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
When I start the dolphinscheduler-api, dolphinscheduler-master, dolphinscheduler-worker. And create a task, I get an error.

This is caused by we remove the task plugin dependencies in dolphinscheduler-api module, but we rely the task plugin module to do the parameter check.
What you expected to happen
xx
How to reproduce
Create a task in cluster mode.
Anything else
No response
Version
dev
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Maybe we need to change the dependency
https://github.com/apache/dolphinscheduler/blob/6134e0a628edc9890adc6f7677a5d122dd5c1a93/dolphinscheduler-api/pom.xml#L54-L57
to
<dependency>
        <groupId>org.apache.dolphinscheduler</groupId>
        <artifactId>dolphinscheduler-task-all</artifactId>
</dependency>

This will increase the size of api module. cc @kezhenxu94

Maybe we need to change the dependency
https://github.com/apache/dolphinscheduler/blob/6134e0a628edc9890adc6f7677a5d122dd5c1a93/dolphinscheduler-api/pom.xml#L54-L57
to

<dependency>

        <groupId>org.apache.dolphinscheduler</groupId>

        <artifactId>dolphinscheduler-task-all</artifactId>

</dependency>

This will increase the size of api module. cc @kezhenxu94

Thanks for the information. I can help to verify when you open a pull request.


Add support for sub queries

Summary
This PR introduces sub queries
For data ingestion, sub queries are handled the same as normal queries. The only difference is that sub queries will also be executed when running report for the main query.
Invoice generation will group reports for sub-facts (i.e. facts generated by a sub-query) as sub-items for query line items. That means if we have a query foo with a sub-query sub-foo and sub-foo2 and a query bar. When generating an invoice we will get the line items
items:
- description: foo
  quantity: 4
  ....
  total: 1337
  subItems:
  - description: sub-foo
    quantity: 1
    ....
  - description: sub-foo2
    quantity: 3
    ....
- description: bar
  quantity: 7
  ....
  total: 42

Sub items will not show up in the total of the main item.
Checklist

[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog
[x] Update tests.

I fixed two things:

Return the query unit for a line item instead of the product unit
Reproduced and fixed a bug I introduced that dropped line items if there are multiple discounts for one query in a single month.

As discussed I will refactor the tests in a separate PR


Dependabot remainder - dockerfile image ref

Base image for epinio-unpacker is bumped in its Dockerfile.
Should bump the unpacker version, and then update the user (epinio helm chart) to match.
With regard to that, users of the dockerfile are:

.github/workflows/unpacker-image.yml - Explicit tagging with version 1.0.
.goreleaser.yml - How is the version number determined ?

Codecov Report
Base: 61.26% // Head: 8.26% // Decreases project coverage by -52.99% :warning:

Coverage data is based on head (9793210) compared to base (a9b168a).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #1933       +/-   ##
==========================================
- Coverage   61.26%   8.26%   -53.00%
==========================================
  Files         179      93       -86
  Lines       14523   10111     -4412
==========================================
- Hits         8897     836     -8061
- Misses       4516    9220     +4704
+ Partials     1110      55     -1055

Flag
Coverage Δ

acceptance-api
?

acceptance-cli
?

unittests
8.26% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

That was a bit unexpected. Something to add to the release flow document probably.
Basically we have a manual release that is releasing the unpacker image with a fixed tag (the unpacker-image.yml GH action), and also it's automatically updated during the normal release with Goreleaser: https://github.com/epinio/epinio/blob/main/.goreleaser.yml#L55
https://github.com/epinio/epinio/pkgs/container/epinio-unpacker/versions
The tag is the one used during the release, so we already have the v1.5.1-amd64.

Ok. Note however that the helm chart still uses the 1.0, see
  bash:
    registry: ghcr.io/
    repository: epinio/epinio-unpacker
    tag: "1.0"

in the values.yaml. Without an architecture suffix too. How would that be resolved ?

Yes, I mean that we are releasing an image that we are not using because we are still using the 1.0 with no platform (the one released manually).
I think that we should try to use at least the same tooling and have a single way to release (goreleaser?), then we could think about release the two images at the same time, or maybe having a different tag/workflow with a separate .goreleaser.yml file.
If nothing is changed I think that the layers will be the same, and so the tag is just going to be an "alias", right?

If nothing is changed I think that the layers will be the same, and so the tag is just going to be an "alias", right?

I guess so.
I just noticed the section about docker manifests in goreleaser.
It apparently pulls the platform specific docker images (templates) together into a single thing which is just tagged with the tag, and no architecture.
That is missing for unpacker. I will look into adding such a section now.

For the epinio-server the chart leaves the tag empty, and then defaults to the appVersion.
I suspect that we can do that for epinio-unpacker as well, in the future.

Pushed 882e45aee958b54b2be9db35eaa6602343187c58 with that change


responsive?

Hi,
Is this package responsive? When decreasing the width of the page, the number of items shown in the carousel should also decrease. Any way for this? Thanks

How about the pagination, does it support numbered pagination?


⚠ Bofrost.es has degraded performance

In 05c1a82, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1387 ms

Resolved: Bofrost.es performance has improved in c1dde91 after 6 minutes.


Use variable spot price module

What is this PR trying to achieve?
Use the variable spot price version of the terraform module.
Depends: https://github.com/wellcometrust/terraform-modules/pull/68
NOTE: This will need to be updated with the correct ref after the module is released.
Who is this change for?
🔬

@alexwlchan should be updated now.


Can't get multiple services

It seems that ServiceType shouldn't be included when trying to get all services.
Dropping this option triggers an error.
I tried to removed all entries of such element in  the relevant wdsi file but no avail.

Figured it out, need to pass None :)
I was trying 'NONE', 'None'

Glad I could help! :)


Power checks

Now with Cargo Console. Fix for: #706

Fixes #706 in the description so GitHub auto-closes the issue.


Rename unifi-poller to unpoller

Description of changes
Rename unifi-poller to unpoller to match upstream change.
Follow-up to #202563, in which @lukegb highlighted that the package name should be updated.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

NixOS tests executed:
$ nix-build ./prometheus-exporters.nix
...snip...
(finished: waiting for the VM to power off, in 1.13 seconds)
(finished: run the VM test script, in 10.15 seconds)
test script finished in 10.15s
cleanup
(finished: cleanup, in 0.00 seconds)
kill vlan (pid 7)
/nix/store/g180g9as5p9vblwm8x5a93dqabsn5d4l-vm-test-run-prometheus-unpoller-exporter

Note: Seem to be other unrelated broken tests in prometheus-exporters.nix... I disabled all other exporters in exporterTests to get this clean test run, otherwise I would have failures like:
nix-build ./prometheus-exporters.nix
error:
       Failed assertions:
       - Database dc=example has `olcDbDirectory` (/var/db/openldap) that is not a subdirectory of
       `/var/lib/openldap/`.
(use '--show-trace' to show detailed location information)

Note: This has a breaking change in the rename of the NixOS exporter module; eg. services.prometheus.exporters.unifi-poller has become services.prometheus.exporters.unpoller.  I wasn't sure how to resolve this breaking change given the abstraction in exporters.nix; I added it into the 23.05 release notes though.

#202710 is the same PR at the same time.  Closing.


Parse unsafe async / const unsafe fns properly

Also adds tests that unsafe async fn as well as const unsafe fn parse properly and that these keywords in the reversed order cause parse errors.
Playground link to verify that this is the correct order.
Closes #1086.

bors r+
Thanks!

Thanks!


THT holes with corresponding pads in upper left corner

I am using your tool and am mostly satisfied with the result. Only one issue occured to me.
As visible in attached picture, all through holes with their corresponding pads are collected in the upper left corner instead of being in their designated places.
I have tried the same pcb file in kidiff alone, their the holes with pads stay in the correct place.
If any more information is required, I will gladly attach it.

The KiCAD version used to create and edit the inspected project is KiCAD 5.1.6

Interesting, thanks for sharing this issue.
Which version of the Kiri are you using?
By the way, could you share the project so I can check if I can reproduce your results here?
Alternatively, the latest version of Kicad 5 is 5.1.12 of 2021-11-05, could you check if the newest version will give you the same results?

I am using the latest available Kiri Version, downloaded just a few days ago.
I can not share the project in the picture but an alternative project with similar issues. I also attach a second project, where the issue does not occur but no rememberable differences where made while creating the two projects, so same libs, same kicad version, same layer count etc.
In total, I now have eight projects where this issue occurs using kicad 5.1.6 and one project, in which it does not occur.
Unfortunately, I will not try version 5.1.12 for now as there is also a project which does not show this issue on kicad 5.1.6.
If I can provide any further information for solving this issue, please just tell me.
In following project, the issue does NOT occur:
20220826_KiCAD_Testprojekt.zip
In following project, the issue DOES occur:
a.Box.2.print_2pSwitch_w_SOM.zip

I can not share the project in the picture but an alternative project with similar issues.

This is enough for me to start investigating this. Thanks for helping me, hoever I cannot run Kiri directly on them, since these are not git repos. Could you share the repo instead of the export?
Meanwhile, let me know if you tried cleaning the generated files once on those projects that fail to place vias. This is done with the flag -r. Inside the project directory, you can run it again using the command kriri -r.
Now, a word about versions. You should definitely use the latest Kicad of that version. Since you are using the old Kicad 5, then you should upgrade to Kicad 5.1.12 at least since it brings bug fixes for 5.1.6 issues. This is different than upgrading to the latest Kicad 6. It is like using an old and comfortable shoe that has the sole rubber loose. If you glue it, making it work and look better, it is still the same old and comfortable shoe but now it gives better quality walks and allows you to walk farther.

Right now, at this machine, I have the latest Kicad 6 installed. So I am going to test quickly check if I have the same issues with my current version of Kicad.
Kiri uses the plot_kicad_pcb command to plot the boards, so I dont have to use Kiri.
=====================
This is one of the layers of the project you said DOES have the issue, right?
plot_kicad_pcb a.Box.2.print_2pSwitch_w_SOM.kicad_pcb
This is F.Cu layers, it looks good to me. Could you confirm?

=====================
To compare, I am doing the same with the prokect that does NOT have the issue.
The same layer, F.Cu, and this also seems not to have the issue, as you said.

=====================
I need some time to prepare a way to test with the old Kicad 5. But it looks like this is a Kicad issue. I remeber that I made a script to workaround that in some way. I just have create a way to reproduce your issue to understand how to proceed.
But I feel that if you upgrade the Kicad to 5.1.12 your problems will be solved. (You could also help me try the same on a virtual machine, I use Virtualbox for these tests)

(Off-topic), I like the traces of your designs, they are nice and well organized. Thanks for sharing.


Autosave

The Autosave checkbox state is not saved and is always turned on after loading.

#17 I did a PR for that.

#17 I did a PR for that.

Thank you! I hope to see it soon.


TranslatedField issues

I think that on row 138 of file forms.py the last parameter is meant to be **attrs[f_name].kwargs instead of **translated_fields[f_name].kwargs.
Besides that, I'm having issues getting the field rendered: I'd like to use a CKEditor widget, and that does not seem to work, but even if I remove the custom widget setting the label is rendered as %(contents)s: instead of simply contents.
edit: the label thing was totally a (stupid) error on my side, but I still can't get the custom widget to work.
Is there any way I could fix this?
edit: well disregard all of that, I am a tool.
Thanks

Issued a pull request to fix the wrong variable name;
I'd suggest merging it (or anyway fixing the small typo) as soon as possible, since it throws an exception immediately when building forms with custom widgets.

I've merged #68 - can you confirm this is now correct? And if you can, please provide a unit test for this feature.


ClientException exception thrown on shock serve with no internet connection

Static Shock allows users to serve and update the content dynamically during development using the shock serve CLI command. However, it only works when there is an internet connection. This makes it inconvenient to continue development on a flight or other occasions when internet connectivity is unavailable.
Reproduction steps:

Generate a new Static Shock project.
Disconnect from the internet.
Run shock serve.

Expected result:
The server runs locally and serves the site content at http://localhost:4000/.
Actual result:
An unhandled ClientException is thrown.
The following is the full error message and stack trace:
Unhandled exception:
ClientException with SocketException: Failed host lookup: 'pub.dev' (OS Error: nodename nor servname provided, or not known, errno = 8), uri=https://pub.dev/api/packages/static_shock_cli
#0      IOClient.send (package:http/src/io_client.dart:154:7) <asynchronous suspension>
#1      BaseClient._sendUnstreamed (package:http/src/base_client.dart:93:32) <asynchronous suspension>
#2      _withClient (package:http/http.dart:167:12) <asynchronous suspension>
#3      PubUpdater._getPackageInfo (package:pub_updater/src/pub_updater.dart:87:22) <asynchronous suspension>
#4      PubUpdater.getLatestVersion (package:pub_updater/src/pub_updater.dart:57:25) <asynchronous suspension>
#5      StaticShockCliVersion.isAtLeastUpToDateWithPub (package:static_shock_cli/src/version_check.dart:42:27) <asynchronous suspension>
#6      PubVersionCheck.run (package:static_shock_cli/src/version_check.dart:23:24) <asynchronous suspension>
#7      ServeCommand.run (package:static_shock_cli/src/commands/serve_command.dart:45:5) <asynchronous suspension>
#8      CommandRunner.runCommand (package:args/command_runner.dart:212:13) <asynchronous suspension>
#9      main (file:///Users/suragch/.pub-cache/hosted/pub.dev/static_shock_cli-0.0.7/bin/static_shock_cli.dart:26:5) <asynchronous suspension>

Resolving ambiguities
It is unclear at this point if the issue is related to SS itself or Dart. If something about running the Dart server requires contacting pub.dev, then the expected result would be to gracefully handle the exception and inform the user that shock serve only works with an internet connection.
shock build does not throw an exception when there is no internet connection.

@matthew-carroll Updated this issue in accordance with the following:

How to write a bug ticket
How to write an issue ticket


[Bug]: [Describe the issue]

What happened?
The service worked at first (links queueing songs) but randomly stopped? I am not sure. twitch username is "myhf"
What part of the service is not working for you?
No response

I'm not sure what you mean? I don't think I ever onboarded you.

Spotify will not accept requests for accounts that I don't manually allow access to, since their Terms of Service won't allow me to open up my project to a broader user base. I think you meant to make an onboarding request? I'll add you now and it should work.

Added you. I also turned on additional logging for my service in case I'm missing something obvious.

strange, i could've sworn that i tested it the other day and it worked for me. it 100% works now, thank you!


[BUG] msg.channel_mentions can and will be None

Describe the bug
Discord will only populate the channel_mentions key of a message if textual channels that are visible to everyone in a lurkable guild are in the message. Obviously this isnt ideal and causes confusion as channels are clearly mentioned, but not available in the message object.
Also the default value of message.channel_mentions is None, it should be []
Categorised as a bug as this is not user-expected behaviour, however it could be argued that its api-expected behaviour
To Reproduce
If you have acceess to the test guild, look here: https://canary.discord.com/channels/701347683591389185/945763271384891424/945936910793199666
Otherwise, send a message mentioning a channel not everyone can see.
Expected behaviour
All channels mentioned and known by the bot are in this list

Theoretically, you could do this with a simple regex. It wouldn't be 1:1 with the API, but it would be more expected behavior.


Added Functional Step Progress Project

It solves issue #1422
Its working video,
https://user-images.githubusercontent.com/75881393/118352803-0721db00-b581-11eb-83fa-f5829ebde807.mp4

Please @ridsuteri @991rajat @urvashi-code1255 review this PR.


ja: Make /docs/tasks/access-application-cluster/connecting-frontend-backend/ follow v1.17 of the original text

Close #21393

/assign @inductor
Thank you for good first issue.
I updated docs, please check my commit.

/approve


[PROPOSAL] Horizontal scalability/Sharding

Though this topic is very vaguely touched in the whitepaper under 'Partial Evaluation of Blockchain State', eos should be designed to shard.
Here is the current progress on sharding within ethereum:
Ethereum has been writing some utils here: https://github.com/ethereum/sharding and there's documentation here: https://github.com/ethereum/wiki/wiki/Sharding-FAQ
Here's a proposal of how to shard ethereum: https://github.com/ethereum/EIPs/issues/53
We should start researching and writing documentation on possible sharding approaches for EOS.

Thanks for the proposal.


WhisperFeatureExtractor

Hi,
I was wondering how to extract input features with whisper in Unity3d. Could you give a hint?
Thanks

I'm not sure what you mean by "input features". It looks like original whisper.cpp has a function to get logits of tokens before sampling. There is no binding for this function in Unity yet, but it should be easy to add.
https://github.com/ggerganov/whisper.cpp/blob/13c22321d1ac758ce68a429c23104e234b440769/whisper.h#L406-L411
If you need output from audio encoder, this is not exposed. But maybe this help:
https://github.com/ggerganov/whisper.cpp/discussions/1489


[* Number] Support for unconventional scientific notation

Non-conventional notations like "1.3x10^6" should ideally be supported as they are common in the wild.

working on this


Design & document HTTP API

This is a work-in-progress implementation of #413. I was considering creating an issue to discuss the design of the HTTP API, but I figure a pull request and some documentation might be the most productive medium for doing this.
The text of the documentation is incomplete and might be partial sentences. Mainly looking here for feedback on the API, then we can complete all the sentences.
I think it is mostly there, but a few design questions:

Do we like our request and response objects?
Do we like our status names? (Maybe failure instead of failed? Is there some prior art here we can build upon instead of inventing something new?)
#428
Is this compatible with #437 and #443?
File handling is a work in progress and I will create a separate piece of documentation about that.
Is this compatible with a potential future async version?
Do we want to version it? #94

@sirupsen @zeke Sorry I should have been clearer in the PR body: I'm mainly looking for feedback here on the actual API. The text of this documentation is incomplete (but thank you for the suggestions!).
@zeke I see answers to the questions are incoming. 😄

For clarity for future reviewers: this is really for feedback on the API, not for feedback on the documentation. I have only half written the documentation. I'm particularly interested in the questions in the original post.
I opened this pull request instead of making a spec for the API because I figured it would be easier to comment on a PR than a GitHub issue.
This is also related to #443 where there are some ideas about how bi-directional HTTP might work. (Not necessarily for now, but could influence future design.)

I wonder how an async API would work. It could be along the lines of:
POST /predictions?async=1
{
  "id": "332f6f8f39f1",
  "status": "processing",
}

GET /predictions/332f6f8f39f1
{
  "id": "332f6f8f39f1",
  "status": "success",
  "output": ...
}

@bfirsh yeah I think something along those lines.
There's probably ~4 distinct cases to think through:

HTTP Version
URL
Result

HTTP/1.1
/predictions
HTTP Uni-directional SSE Stream

HTTP/1.1
/predictions?async=false
HTTP 201

HTTP/{2,3}
/predictions
HTTP Bi-directional stream

HTTP/{2,3}
/predictions?async=false
HTTP 201

Do we like our request and response objects?

For reference, here's an example of what those objects look like today:
{
  "Request": {
    "title": "Request",
    "type": "object",
    "properties": {
      "input": {
        "$ref": "#/components/schemas/Input"
      },
      "output_file_prefix": {
        "title": "Output File Prefix",
        "type": "string"
      }
    }
  },
  "Response": {
    "title": "Response",
    "required": ["status"],
    "type": "object",
    "properties": {
      "status": {
        "$ref": "#/components/schemas/Status"
      },
      "output": {
        "$ref": "#/components/schemas/Output"
      },
      "error": {
        "title": "Error",
        "type": "string"
      }
    },
    "description": "The status of a prediction."
  }
}

Two things stand out to me:

title is redundant. Let's get rid of it. https://github.com/replicate/cog/issues/457
description is inconsistent. Here's a PR to fix that: https://github.com/replicate/cog/pull/498

Do we like our status names? (Maybe failure instead of failed? Is there some prior art here we can build upon instead of inventing something new?)

I've had a look, but can't find any sort of open standard here.
GitHub Actions use success, failure and cancelled, which works, but isn't exactly consistent. I think I'd prefer succeeded, failed and cancelled for consistency.
This random Microsoft status enum is very self-consistent: https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.jobstate?view=powershellsdk-7.0.0. I like the distinction between …ed statuses for a thing that's over and …ing statuses for something in progress. (One small nit: I'd probably prefer something like Waiting rather than NotStarted.
I think adopting …ing and …ed endings would make it easier to add consistent new statuses in the future. If we start with success and failure then we either end up inconsistent like GitHub Actions or we add a status like cancellation which feels super weird.
With …ing and …ed, if we want to add statuses for jobs that haven't started or are in progress, it's easy to find verbs: queuing, waiting, running.

Thanks for all your feedback here! I'm going to merge this as-is because it's a lot better than nothing, then turn the suggestions about the API into new tickets.

👆 here are the tickets I made


[ALLUXIO-2396] Warn users of unecessary URI information

https://alluxio.atlassian.net/browse/ALLUXIO-2396
@aaudiber

I still need to make a few more changes to perform the checks within each method.

Merged build finished. Test FAILed.

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

Merged build finished. Test PASSed.

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

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

Merged build finished. Test PASSed.


Fix body-prose empty paragraph bug

Why do you use backticks again for the message? Let's use double-quotes (like other tests), and this way you don't need to escape the backticks inside.

Why do you use backticks again for the message? Let's use double-quotes (like other tests), and this way you don't need to escape the backticks inside.

Ah sorry, the initial commit message is too long, I forgot to replace the backtick with double quotes at the end.


Error: Cannot find module 'express' in product environment

I need a express server in my app.
I move the express dependence from devDependencies to dependencies,
After execute:
npm run package
I still got an Error: Cannot find module 'express' in product environment

I deleted my node_modules folder,and run "npm install" again,problem was solved

Closing because you apparently resolved this issue


[BugFix] Renewed Pulsar routine load task timeout

Why I'm doing:
What I'm doing:
This PR fixes the renewed pulsar routine load task timeout as the old task.
Fixes #issue
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

@mergifyio rebase


RoasterFormModelSourceGeneratorTest & related changes

Unit test for RoasterFormModelSourceGenerator class, small refactoring and a fix of situation where empty dataHolders set is passed to the generator and two constructors are generated.

The build seems to be failing due to reasons unrelated to the change I made (it fails also with the previous version). It might be due to the previous commit (Fixes after IP BOM 7.0.0.CR4 upgrade (#31)) or changes made somewhere else in the product. @paulovmr could you please look at the LiveSparkEntryPointTest - why it fails?

@jsoltes Hi, LiveSparkEntryPointTest was broke by this line removal: https://github.com/droolsjbpm/livespark/commit/c4c29a92ee66cd34e13e1b8c464d55fde09dacf8#diff-058918d9f053df0c3ad85a13037dae30L99
I'll send a PR to fix the test.

@jsoltes Here is the PR: https://github.com/droolsjbpm/livespark/pull/33

jenkins retest this.

As in PR #33, the failing test is caused by: https://issues.jboss.org/browse/UF-335

+1, thanks for the test @jsoltes.


Rename annotated_gene_feature_per_publications

Add "pombase_" to match the other PomBase views.
Also maybe feature_id and pub_id would be more useful columns.
@markmcdowall

We are on 58 now, 59 pending.  Is this needed urgently? If not I'll remove the "next" label (unless its quick or it breaks things)

The renaming it done but the extra columns aren't there.  It's not urgent at all so I removed "next".

@kimrutherford , is this still relevant?

@kimrutherford , is this still relevant?

adding low priority, remove if not

Done!


Overriding :object in #permitted_to? should change skip_attribute_test

Consider the following
    role :employee do
      has_permission_on :foo do
        if_attribute :has_special_permission? => is{true}
      end
    end

    class User < ActiveRecord::Base
      def has_special_permission?
         #fancy permission logic
      end
    end

    class FooController
      filter_access_to :index, attribute_check: true
    end

    <% if permitted_to?(:show, :foo, object: current_user) %>
      <!-- this link is scattered throughout the app -->
      <%= link_to "Foo", foo_path %>
    <% end %>

The intent here is that we have a non-resourceful controller and we want to check that a particular user has permission for this controller based on non-trivial logic buried in the User model.
The problem is in: https://github.com/stffn/declarative_authorization/blob/master/lib/declarative_authorization/in_controller.rb#L195
where :skip_attribute_test is determined based on the object variable which has not yet been overridden by the merge of the options passed in. So if object is present in the override hash, :skip_attribute_test does not seem to reflect the intended behavior, which is: if object is present, don't skip the attribute test.
Is this a bug or is there a different way I should be accomplishing this?
Thanks!

Just realized this can be worked around by explicitly passing in :skip_attribute_test like so:
<% if permitted_to?(:show, :foo, object: current_user, skip_attribute_test: false) %>


Disconnect/Close connection

Hello,
I could not find any mentions here: https://docs.min.io/docs/golang-client-api-reference.html
As to how i can disconnect the client, any suggestions ?
Thanks

There is no such thing, its an HTTP client what are you trying to achieve?

I have a function which open a minio connection on demand, at the moment that function creates a client and gets an object.
Should the minio.New part be moved to a global space and just be reused ?
If so is there any connection error/close handing that needs to be done ?

I have a function which open a minio connection on demand, at the moment that function creates a client and gets an object.
Should the minio.New part be moved to a global space and just be reused ?
If so is there any connection error/close handing that needs to be done ?

First I think you need to get a hang of writing code using net/http https://golang.org/pkg/net/http/
minio.New is a single persistent object for the life time of a program
connection error/close handling is automatically done in the code.
you only need to Close() the Reader() that is sent to you for consumption such as GetObject()

Also please ask these questions in our https://slack.min.io - we would like to limit GitHub issues for issue management alone.


TreeTable, during node collapse rowSelectionChange event gives incorrect rowIndices

OpenUI5 version:
1.52.10
Browser/version (+device/version):
Chrome 65
Any other tested browsers/devices(OK/FAIL):
None other tested
URL (minimal example if possible):
https://jsbin.com/yisaxexizi/edit?js,console,output
User/password (if required and possible - do not post any confidential information here):
N/A
Steps to reproduce the problem:

Load the provided JSBin page
Select all the children nodes in the TreeTable. Note the row indices printed on selection
Collapse the parent node. Note the row indices printed.

What is the expected result?
The sample should print that row indices 1,2,3,4 have selection changed during parent node collapse.
What happens instead?
The sample prints that row indices 2,3,4,5 have been changed.
Any other information? (attach screenshot if possible)
The problem seems to stem from TreeBindingAdapter when it collects the affected row indices. Starting iNodeCounter at -1 seems to produce the correct rowIndices event parameter.

Hi @nickroth,
Thanks a lot for reporting this! We are working on a fix. It will be available in one of the upcoming releases of 1.52 and all higher releases.

Reopening until downports are merged

Tracking internally as<PHONE_NUMBER>

The fix has been merged into codelines 1.52, 1.54 and the current master. It will be part of one of the upcoming releases of 1.52 and 1.54 (apparently not 1.54.4). Thanks again for reporting this issue!


Openscenario parser extensions

Description

Fixes #
Where has this been tested?

Platform(s): ...
Python version(s): ...
Unreal Engine version(s): ...
CARLA version: ...

Possible Drawbacks

This change is

Hi,
there are only some minor comments. Please also update the changelog.md and run the code_check_and_formatting.sh script :)


[EmbedUtils] Add An Option To Edit Embed Messages

Feature Request
If someone needed to edit an embed that has role reactions attached to the message, being able to edit the embed without needing to resend the embed and having to redo all of the said role reactions would make it a lot more convenient and it makes more logical sense.
Something like [p]embed edit <message_id> <fromfile/frommsg/fromdata/etc.>

I believe you can edit webhook embeds as well so maybe do the same thing for webhook embeds?

I don't like bumping issues but here I am..

Closing this as [p]embed edit has been added.


[BUG] [Monitoring] Readiness/Liveness probe failed

Rancher Server Setup

Rancher version: 2.7.9
Installation option: Helm chart

Kubernetes Cluster and version: v1.26.10+k3s1

Proxy/Cert Details: Certmanager

Information about the Cluster

Kubernetes version: v1.26.10+k3s1
Clusters:

Rancher: 2 nodes (Ubuntu on Raspberry Pi 4B)
Production: 8 nodes (Ubuntu  on Raspberry Pi 4B)

User Information

What is the role of the user logged in: Admin

Describe the bug
I keep getting events from rancher-monitoring on my production cluster:
rancher-monitoring-prometheus-adapter-7494f789f6-gtqq2: Readiness probe failed: Get "https://<IP_ADDRESS>:6443/healthz": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
rancher-monitoring-prometheus-adapter-7494f789f6-gtqq2: Liveness probe failed: Get  "https://<IP_ADDRESS>:6443/healthz": net/http: request canceled while  waiting for connection (Client.Timeout exceeded while awaiting headers)

When I look at Grafana, I don't see any issues (see screenshots). Also, the pod doesn't have any restarts. The Prometheus pod doesn't show any logs.
I couldn't find a way to make these probes more lenient through the helm chart. It would be nice if you could configure the probes through the values.yaml file.
To Reproduce
Deploy rancher-monitoring
Result
Event saying Readiness/Liveness probe failed
Expected Result
No event
Screenshots
Events:

Grafana:

Pod:

I found this documentation (found on this page) that might be relevant.
It seems that it allows you to patch the prometheus container through creating another Prometheus resource. I'll see if I can get it to work.
If it does, It would be nice if the values.yaml could include a field that would add the Prometheus automatically.
I'll keep you updated.


Fix typo in README.md

:rocket:
This description was created by Ellipsis for commit c9a031adaf7daa5d17de77c6f691df59b343fa51

Summary:
Fixed a typo in README.md by correcting the URL for the installation guide in the Quickstart section.
Key points:

Fixed a typo in README.md.
Corrected the URL for the installation guide in the Quickstart section.

Generated with :heart: by ellipsis.dev

Looks great, @gaoyifan! Thanks for fixing that!


add github action for go-vuln-check

This PR solves https://github.com/apache/skywalking/discussions/10483#discussioncomment-5460399. Now onwards all PRs in golang repositories will be scanned for vulnerabilities.

Shouldn't this be enabled through a .lift/config.toml? @kezhenxu94 @rabajaj0509 I'm confused.

Shouldn't this be enabled through a .lift/config.toml? @kezhenxu94 @rabajaj0509 I'm confused.

I'm confused too, I have asked here https://github.com/apache/skywalking/discussions/10483#discussioncomment-5460399 about what's their outcome

Let's hold this pr for a bit.

Closing as sonatype has adopted the check as native pr bot.


CI Logs filled overly verbose

@troydai
With recent changes to the CI build, the log is filling up with useless entries.  About 6000 lines of things like:
copying azure/cli/core/parser.py -> build/lib/azure/cli/core
This actively prevents finding out what failed the build because TravisCI truncates the log at 10,000 lines and gives the following:
This log is too long to be displayed. Please reduce the verbosity of your build or download the raw log.
So... as the CI requests... please reduce the verbosity of the log 😆

Fixed in https://github.com/Azure/azure-cli/issues/4452.


Update configuration typings to allow for oracle db connectionstring

I am working on a typescript project with an oracle database using SID and we currently have it configured with a custom connectString. We were hoping to move to knex and ran into a typescript issue. Here is the resolution we used to get it working.

Thanks!

Released in 0.19.1

Thanks very much! :)


Enhancement: Change the scroll to top button to a icon

Describe the feature
To maintain the simplicity of the website, change the scroll to top button to an icon
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Hey @anuragverma108 please assign this issue to me under GSSOC'24

This issue already exists. Please check the existing issues before raising a new one. Find another issue or feature to contribute to. Thank you!


ResourceNotFoundError

Describe the bug
Trying to get the identity from the application gateway, just return the error "ResourceNotFoundError"
Related command
az network application-gateway identity show -g ""  --gateway-name ""
Errors
az network application-gateway identity show -g ""  --gateway-name ""
Issue script & Debug output
ResourceNotFoundError
Expected behavior
{
"principalId": null,
"tenantId": null,
"type": "userAssigned",
"userAssignedIdentities": {
"/subscriptions/XXXXXXXXX-80b8-4447-b2a6-XXXXXXXXXX/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id1": {
"clientId": "DDDDDDDDD-eb2e-4836-898a-DDDDDDDDD",
"principalId": "UUUUUUUUUU-b7c8-43d2-80a2-UUUUUUUUUU"
}
}
}
Environment Summary
{
"azure-cli": "2.50.0",
"azure-cli-core": "2.50.0",
"azure-cli-telemetry": "1.0.8",
"extensions": {
"aks-preview": "0.5.137",
"confcom": "0.2.15"
}
}
Additional context
No response

Thank you for opening this issue, we will look into it.


Problems supplying port to script

Hi, this seems like a really promising project!
I'm having some issues connecting to my database running on a non-standard port (27019).
When I add the details in the config:
$ mongobar config

┌───────────┬────────────────────────────┐
│ root      │ /var/lib/mongodbhc/backups │
│ log_level │ INFO                       │
└───────────┴────────────────────────────┘

Connections:

┌ [default] ┬──────────────────┐
│ host      │ localhost        │
│ port      │ 27019            │
│ username  │ admin            │
│ password  │ **************** │
│ authdb    │ admin            │
└───────────┴──────────────────┘

I get the following error:
[CRITICAL] Command failed: Command '['mongodump', '-h', 'localhost', '-p', '27019', '-u', 'admin', '-p', '*****************', '--authenticationDatabase', 'admin', '--db', 'scoutTest', '--out', '/var/lib/mongodbhc/backups/localhost:27019/goad-linseed', '--quiet', '--gzip']' returned non-zero exit status 1.

I notice that the -p option is showing up twice both for port and password which I assume is giving the error.
So I tried giving the port on the mongobar command line:
$ mongobar backup --port 27019 -d scoutTest
Traceback (most recent call last):
  File "/home/hiseq.clinical/miniconda/envs/prod170926/bin/mongobar", line 1255, in <module>
    MongobarScript().run()
  File "/home/hiseq.clinical/miniconda/envs/prod170926/bin/mongobar", line 121, in run
    getattr(self, self.args.action.replace("-", "_"))()
  File "/home/hiseq.clinical/miniconda/envs/prod170926/bin/mongobar", line 859, in backup
    metadata = self.mb.generate_metadata()
  File "/home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages/mongobar/mongobar.py", line 77, in generate_metadata
    client = self.create_pymongo_client()
  File "/home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages/mongobar/mongobar.py", line 64, in create_pymongo_client
    client = pymongo.MongoClient(**options)
  File "/home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages/pymongo/mongo_client.py", line 413, in __init__
    raise TypeError("port must be an instance of int")
TypeError: port must be an instance of int

Probably just some small bugs - I will try to play around with the code a little and I can open a PR unless you fix it quicker than I 😉

Hmm, the config port problem only seems to be an issue with the latest pip release
However giving the port on the command line does raise the above exception from PyMongo

sorry for the delay, I'll get into this asap. You're correct, there are a few small bugs kicking around, thanks for bringing this to my attention

This issue should be fixed in version 0.0.12 available here in the master branch and on pip.
@robinandeer Please let me know at your convenience if this solves the problem so I can close the issue. Thanks!

I was able to duplicate and fix the issue. Thanks for the input 👍


Example has wrong paramaters

"azdata bdc spark batch create" section has a wrong parameter/example --code.
It should be --file

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

ID: 6600107a-20b8-6ee3-1616-4c6ca1c06159
Version Independent ID: 46981b99-72b9-16d4-bfe3-cc383708f26d
Content: azdata bdc spark batch reference - SQL Server
Content Source: docs/big-data-cluster/reference-azdata-bdc-spark-batch.md
Product: sql
Technology: big-data-cluster
GitHub Login: @MikeRayMSFT
Microsoft Alias: mikeray

@tiagobalabuch -- Tiago, thank you for catching that.  I am looking into this article.

@MikeRayMSFT -- Mike, please review private PR 14609.


Fix broken build.gradle release tag from #14814

This fixes a missing comma discovered while building 2.31.0 RC1. Error before:
  build file '/tmp/build_release_candidate/beam/runners/google-cloud-dataflow-java/build.gradle': 49: expecting ']', found 'dataflow.fnapi_container_version' @ line 49, column 5.
         'dataflow.fnapi_container_version' : '2.31.0'
         ^

  1 error

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @emilymye

Ping @emilymye
cc: @ihji


10/5/2020 Update

Updated triage

Your merge request is backward. You probably want to merge from my repo to yours. Instead, this request attempts to merge your content into my repo.


List all accounts in the service

Develop a RESTful service using Test Driven Development for LIST RESTful API endpoint to return all accounts.

Steps to complete:

Develop test cases for the LIST RESTful Flask service.
Develop RESTful API endpoints for LIST action.
Perform unit testing with nose and coverage.


Add survey message to calculator page. Add icon to b117 alert

Fixes #622

I'm gonna merge this since it's so minor.

I'm gonna merge this since it's so minor.


[Chore] Restore radio patch

Restore the radio patch for kodi Internet Radio metadata.
The change apparently is not on the ppa

Available in 2022-12-181. It's a wrong release anyway, I had to revert


What is your input type (image or skeleton joints) for your st-gcn network?

Code version (Git Hash) and PyTorch version
Dataset used
Expected behavior
Actual behavior
Steps to reproduce the behavior
Other comments
What is your input dimension and sample input-data channels for your st-gcn network?

You can find these numbers in the paper. Or you can just run the codebase to get the sense.


passing screenProps prevents inner navigation

I have the following structure:
DrawerNavigator
    --> StackNavigator1
    --> StackNavigator2
    ...

My navigator is defined like this:
DrawerNavigator({
  Stack1: {
    screen: StackNavigator1
  },
  Stack2: {
    screen: StackNavigator2
  }
})

I could call this.props.navigation.navigate('DrawerOpen') to open the outer Drawer.
But I need to pass screenProps to inner scenes, so I refactored this to:
DrawerNavigator({
 Stack1: {
    screen: ({ navigation }) => <StackNavigator1 screenProps={{ rootNavigation: navigation }} />
  },
 Stack2: {
    screen: ({ navigation }) => <StackNavigator2 screenProps={{ rootNavigation: navigation }} />
  }
})

But this.props.navigation.navigate('DrawerOpen') no longer works inside those Stack navigators.
What am I doing wrong?

You need to pass the navigation prop to StackNavigator1 and StackNavigator2

DrawerNavigator({
 Stack1: {
    screen: ({ navigation }) => <StackNavigator1 navigation={navigation} screenProps={{ rootNavigation: navigation }} />
  },
 Stack2: {
    screen: ({ navigation }) => <StackNavigator2 navigation={navigation} screenProps={{ rootNavigation: navigation }} />
  }
})

Gives me an error:
Warning: Failed prop type: The prop `navigation.state.index` is marked as required in `CardStack`, but its value is `undefined`.
    in CardStack
    in Unknown (created by Navigator)
    in Navigator (created by NavigationContainer)
    in NavigationContainer (created by screen)
    in screen (created by SceneView)
    in SceneView (created by DrawerScreen)
    in DrawerScreen (created by withCachedChildNavigation(DrawerScreen))
    in withCachedChildNavigation(DrawerScreen) (created by Unknown)
    in Unknown (created by Navigator)
    in Navigator (created by DrawerView)
    in RCTView (created by View)
    in View (created by AnimatedComponent)
    in AnimatedComponent (created by DrawerLayout)
    in RCTView (created by View)
    in View (created by DrawerLayout)
    in DrawerLayout (created by DrawerView)
    in DrawerView (created by Unknown)
    in Unknown (created by Navigator)
    in Navigator (created by NavigationContainer)
    in NavigationContainer (created by App)
    in Provider (created by App)
    in App
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer

Oops, you cannot use a navigator as a component like that, because the router is not set. This should work:
const Stack1 = ({ navigation }) => <StackNavigator1 navigation={navigation} screenProps={{ rootNavigation: navigation }} />;
Stack1.router = StackNavigator1.router;

const App = DrawerNavigator({
 Stack1: {
    screen: Stack1,
  },
  ...
})

But I think you shouldn't need to do that. Perhaps the DrawerOpen behavior is a bug.


Where are the sources for bigdl-core-cpp?

I am looking to build ipex-llm from sources and I found that bigdl-core-cpp is used in setup.py for cpp library support. I can however find sources for these filers or the build scripts on how these are built. Please guide me to relevant repo.

I am looking to build ollama 0.2.0 for reference

bigdl-core-cpp is closed source.


Exception: (while loading libncurses.so) /lib/x86_64-linux-gnu/libncurses.so: file too short

No matter how I compile the library (no option, NCURSES_VERSION=5, or NCURSES_VERSION=6),
I systematically get this error when I try to run one of the examples.
I can't remember whether we ever found a way to make it work or whether I ended up
always using my personal laptop rather than my work one when experimenting with this?
Anyway, I have a little project in mind so I'd welcome any hint as to how to get this going.

Remind me what OS you’re using (at work, where you hit the error) and if you recall having installed anything related to ncurses by hand or just what the system shipped with and I’ll try to reproduce so I can offer actual help.
I’ve only got a Mac available, but I can attempt to repro your system via Docker or a vm.

I'm running Ubuntu jammy. This is what I have installed:
$$ dpkg -l '*ncurses*' | grep ^ii
ii  libncurses-dev:amd64  6.3-2        amd64        developer's libraries for ncurses
ii  libncurses5:amd64     6.3-2        amd64        shared libraries for terminal handling (legacy version)
ii  libncurses5-dev:amd64 6.3-2        amd64        transitional package for libncurses-dev
ii  libncurses6:amd64     6.3-2        amd64        shared libraries for terminal handling
ii  libncursesw6:amd64    6.3-2        amd64        shared libraries for terminal handling (wide character support)
ii  ncurses-base          6.3-2        all          basic terminal type definitions
ii  ncurses-bin           6.3-2        amd64        terminal-related programs and man pages

and what's in /lib/x86_64-linux-gnu:
$$ ls -lh | grep libncur
lrwxrwxrwx  1 root root    12 Jan 17  2022 libcurses.a -> libncurses.a
lrwxrwxrwx  1 root root    13 Jan 17  2022 libcurses.so -> libncurses.so
-rw-r--r--  1 root root  159K Jan 17  2022 libncurses++.a
-rw-r--r--  1 root root  310K Jan 17  2022 libncurses.a
-rw-r--r--  1 root root    31 Jan 17  2022 libncurses.so
lrwxrwxrwx  1 root root    17 Jan 17  2022 libncurses.so.5 -> libncurses.so.5.9
-rw-r--r--  1 root root  147K Jan 17  2022 libncurses.so.5.9
lrwxrwxrwx  1 root root    17 Jan 17  2022 libncurses.so.6 -> libncurses.so.6.3
-rw-r--r--  1 root root  155K Jan 17  2022 libncurses.so.6.3
-rw-r--r--  1 root root  159K Jan 17  2022 libncurses++w.a
-rw-r--r--  1 root root  430K Jan 17  2022 libncursesw.a
-rw-r--r--  1 root root    32 Jan 17  2022 libncursesw.so
lrwxrwxrwx  1 root root    18 Jan 17  2022 libncursesw.so.6 -> libncursesw.so.6.3
-rw-r--r--  1 root root  235K Jan 17  2022 libncursesw.so.6.3

libncurses.so is indeed really small:
$$ cat libncurses.so
INPUT(libncurses.so.6 -ltinfo)

I've just tried on  my personal laptop and I have the same problem.
Debian bullseye. Similar packages installed:
$$ dpkg -l '*ncurses*' | grep ^ii
ii  libncurses-dev:amd64  6.2+20201114-2 amd64        developer's libraries for ncurses
ii  libncurses5-dev:amd64 6.2+20201114-2 amd64        transitional package for libncurses-dev
ii  libncurses6:amd64     6.2+20201114-2 amd64        shared libraries for terminal handling
ii  libncursesw6:amd64    6.2+20201114-2 amd64        shared libraries for terminal handling (wide character support)
ii  ncurses-base          6.2+20201114-2 all          basic terminal type definitions
ii  ncurses-bin           6.2+20201114-2 amd64        terminal-related programs and man pages
ii  ncurses-term          6.2+20201114-2 all          additional terminal type definitions

I haven’t had time to look into this yet today, but if your original comment meant you literally see an error about libncurses.so being too small no matter how you set the version then I think there may be something broken with my build scripts because setting the version should result in the runtime trying to load libncurses5.so (for example) when a version is set.

Yep the message does not change no matter what NCURSES_VERSION option I pass.

Ok, there was definitely a problem with the Makefile's replacement of libncurses with libncurses x for some version x.
I fixed that problem and also made the Makefiles for the examples work without having installed idris-indexed or ncurses-idris (they are built into the local depends folder and ncurse's C lib is also copied into the example depends folder.
The fix is in PR here: https://github.com/mattpolzin/ncurses-idris/pull/27
If you have the time to check that branch out and see if it works, I'd love to know I am on the right track. Otherwise, I'll probably merge it sometime tomorrow regardless.
In my testing in Docker on my mac, I actually hit an even scarier error after fixing the problem you encountered here. I'll be curious to hear if you hit the new error as well or if that's just because I was working in such a poor approximation of your full work setup. The error I hit was Exception: invalid memory reference.  Some debugging context lost.

The new exception I got fits the shape of at least one known issue for Idris 2 (https://github.com/idris-lang/Idris2/issues/1974) but interestingly it is not an issue on my mac. I only hit the error in my Ubunutu docker environment.


GC concurrent issue potential fix

Fixes from @pratikpatel39 according to this issue

Thank you @tosbaha, do you mind to put the original WebKit patch directly? It would be better to appreciate original author's work.
It seems your branch has the permissions for me to edit directly. If you don't mind, I could edit on your branch and then merge your PR.

Hi @Kudo , I got the combined patches from the linked thread. Which actually links to https://trac.webkit.org/changeset/251307/webkit Since the patches were pointing to the different directories, @pratikpatel39  fixed the patches and unified the patch. I don't know how can I put the original WebKit patch directly. I checked the patches in this repository there were no authors etc. Please edit the PR as you please.

Sorry to make you confuse. I was talking about including the CHANGELOG.
Will modify your PR and merge directly. Thank you very much.

I've modified your PR and merged back to jsc_2_26_1 branch.
Will follow up to merge this patch to my develop branch and hopefully to publish new version soon.
Thank you.


Getting "RuntimeError: CUDA error: invalid configuration argument" trying to train MVX-Net

I am getting this trying to train MVX-Net
python tools/train.py configs/mvxnet/dv_mvx-fpn_second_secfpn_adamw_2x8_80e_kitti-3d-3class.py
Traceback (most recent call last):
  File "tools/train.py", line 166, in <module>
    main()
  File "tools/train.py", line 162, in main
    meta=meta)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmdet/apis/train.py", line 150, in train_detector
    runner.run(data_loaders, cfg.workflow, cfg.total_epochs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 125, in run
    epoch_runner(data_loaders[i], **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 50, in train
    self.run_iter(data_batch, train_mode=True)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 30, in run_iter
    **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/parallel/data_parallel.py", line 67, in train_step
    return self.module.train_step(*inputs[0], **kwargs[0])
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmdet/models/detectors/base.py", line 247, in train_step
    losses = self(**data)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 84, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/base.py", line 59, in forward
    return self.forward_train(**kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 274, in forward_train
    points, img=img, img_metas=img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 208, in extract_feat
    pts_feats = self.extract_pts_feat(points, img_feats, img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_faster_rcnn.py", line 54, in extract_pts_feat
    voxels, coors, points, img_feats, img_metas)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 164, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/voxel_encoders/voxel_encoder.py", line 274, in forward
    voxel_feats, voxel_coors = self.vfe_scatter(point_feats, coors)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 113, in forward
    points[inds], coors[inds][:, 1:])
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 92, in forward_single
    self.point_cloud_range)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 38, in forward
    coors_range)
RuntimeError: CUDA error: invalid configuration argument

the environment:
sys.platform: linux
Python: 3.6.9 (default, Oct  8 2020, 12:12:24) [GCC 8.4.0]
CUDA available: True
GPU 0,1: TITAN X (Pascal)
CUDA_HOME: /home/kirilly/cuda10.1
NVCC: Cuda compilation tools, release 10.1, V10.1.105
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.5.0+cu101
PyTorch compiling details: PyTorch built with:
  - GCC 7.3
  - C++ Version: 201402
  - Intel(R) Math Kernel Library Version 2019.0.5 Product Build 20190808 for Intel(R) 64 architecture applications
  - Intel(R) MKL-DNN v0.21.1 (Git Hash 7d2fd500bc78936d1d648ca713b901012f470dbc)
  - OpenMP 201511 (a.k.a. OpenMP 4.5)
  - NNPACK is enabled
  - CPU capability usage: AVX2
  - CUDA Runtime 10.1
  - NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_37,code=compute_37
  - CuDNN 7.6.3
  - Magma 2.5.2
  - Build settings: BLAS=MKL, BUILD_TYPE=Release, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -fopenmp -DNDEBUG -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DUSE_INTERNAL_THREADPOOL_IMPL -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, USE_CUDA=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON, USE_STATIC_DISPATCH=OFF,

TorchVision: 0.6.0+cu101
OpenCV: 4.5.1
MMCV: 1.2.6
MMCV Compiler: GCC 7.5
MMCV CUDA Compiler: 10.1
MMDetection: 2.9.0
MMDetection3D: 0.10.0+ac9a3e8

Did anyone encounter this? What could be the steps for solution?
Thank you a lot in advance for help!

Could you try dist_train.sh and see whether it could succeed?

@ZwwWayne
running:
tools/dist_train.sh configs/mvxnet/dv_mvx-fpn_second_secfpn_adamw_2x8_80e_kitti-3d-3class.py 1
or
tools/dist_train.sh configs/mvxnet/dv_mvx-fpn_second_secfpn_adamw_2x8_80e_kitti-3d-3class.py 2 (I've got 2 GPUs)
gives the same result:
2021-02-17 13:41:39,778 - mmdet - INFO - workflow: [('train', 1)], max: 40 epochs
Traceback (most recent call last):
  File "tools/train.py", line 166, in <module>
    main()
  File "tools/train.py", line 162, in main
    meta=meta)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmdet/apis/train.py", line 150, in train_detector
    runner.run(data_loaders, cfg.workflow, cfg.total_epochs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 125, in run
    epoch_runner(data_loaders[i], **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 50, in train
    self.run_iter(data_batch, train_mode=True)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 30, in run_iter
    **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/parallel/distributed.py", line 46, in train_step
    output = self.module.train_step(*inputs[0], **kwargs[0])
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmdet/models/detectors/base.py", line 247, in train_step
    losses = self(**data)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 84, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/base.py", line 59, in forward
    return self.forward_train(**kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 274, in forward_train
    points, img=img, img_metas=img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 208, in extract_feat
    pts_feats = self.extract_pts_feat(points, img_feats, img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_faster_rcnn.py", line 54, in extract_pts_feat
    voxels, coors, points, img_feats, img_metas)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 164, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/voxel_encoders/voxel_encoder.py", line 274, in forward
    voxel_feats, voxel_coors = self.vfe_scatter(point_feats, coors)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 113, in forward
    points[inds], coors[inds][:, 1:])
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 92, in forward_single
    self.point_cloud_range)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 38, in forward
    coors_range)
RuntimeError: CUDA error: invalid configuration argument
Traceback (most recent call last):
  File "tools/train.py", line 166, in <module>
    main()
  File "tools/train.py", line 162, in main
    meta=meta)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmdet/apis/train.py", line 150, in train_detector
    runner.run(data_loaders, cfg.workflow, cfg.total_epochs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 125, in run
    epoch_runner(data_loaders[i], **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 50, in train
    self.run_iter(data_batch, train_mode=True)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 30, in run_iter
    **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/parallel/distributed.py", line 46, in train_step
    output = self.module.train_step(*inputs[0], **kwargs[0])
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmdet/models/detectors/base.py", line 247, in train_step
    losses = self(**data)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 84, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/base.py", line 59, in forward
    return self.forward_train(**kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 274, in forward_train
    points, img=img, img_metas=img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 208, in extract_feat
    pts_feats = self.extract_pts_feat(points, img_feats, img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_faster_rcnn.py", line 54, in extract_pts_feat
    voxels, coors, points, img_feats, img_metas)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 164, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/voxel_encoders/voxel_encoder.py", line 274, in forward
    voxel_feats, voxel_coors = self.vfe_scatter(point_feats, coors)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 113, in forward
    points[inds], coors[inds][:, 1:])
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 92, in forward_single
    self.point_cloud_range)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/scatter_points.py", line 38, in forward
    coors_range)
RuntimeError: CUDA error: invalid configuration argument
Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/distributed/launch.py", line 263, in <module>
    main()
  File "/home/kirilly/mmdetection_env/lib/python3.6/site-packages/torch/distributed/launch.py", line 259, in main
    cmd=cmd)
subprocess.CalledProcessError: Command '['/home/kirilly/mmdetection_env/bin/python', '-u', 'tools/train.py', '--local_rank=1', 'configs/mvxnet/dv_mvx-fpn_second_secfpn_adamw_2x8_80e_kitti-3d-3class.py', '--launcher', 'pytorch']' returned non-zero exit status 1.

@ZwwWayne maybe you can direct me, what is better to change to make it work? python version? torch version? CUDA version? I can try different configurations

Hi @manonthegithub ,
This is a little bit weird. We will first try to reproduce your bug first and give you feedback.

@ZwwWayne thank you! Looking forward to your reply :)

Hi, @manonthegithub
It seems that we encountered the same problem 'CUDA configuration error' two weeks ago. The runtime error was raised when calling a custom PyTorch extensiondynamic_point_to_voxel_forward. There was a bug in the extension's CUDA part that would lead to runtime error when your points feature being scattered has more than 16 channels.
PR #318  addressing this issue has been merged and this issue should go away with the next release I guess.
If you want more information----------
CUDA configuration error is a kind of kernel launch failure, which is most probably caused by wrongly configured threads number within a CUDA thread block, namely, 'block dim', or wrongly configured blocks number in total, namely 'grid dim'. These numbers are limited by hardware. Especially the block dim, which is limited to 1024 for almost all CUDA GPUs. The upper mentioned extension CUDA code launches (64 * N_feat_channels) threads per block and this is obviously erroneous when N_feat_channels > 16.
Pls check this URL for details https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#compute-capabilities

@zhanggefan yes looks like the pr may fix the issue, I have changed the num threads in scatter_points_cuda.cu on line 17 (int const threadsPerBlock = sizeof(unsigned long long) * 8;)
to 8 instead of 64, and it worked. Putting 16 did not work in my case though.
@ZwwWayne do you think I made it in a right way? can it somehow affect the results of training?

@zhanggefan yes looks like the pr may fix the issue, I have changed the num threads in scatter_points_cuda.cu on line 17 (int const threadsPerBlock = sizeof(unsigned long long) * 8;)
to 8 instead of 64, and it worked. Putting 16 did not work in my case though.
@ZwwWayne do you think I made it in a right way? can it somehow affect the results of training?

This is indeed a simple and effective workaround!
Looks like your feature channel count was in the range [64, 128), am I right?
From my point of view, making threadsPerBlock smaller will not affect the training result but it may affect the training speed. This 'scatter points' op has several other kernels and when they are launched with fewer threads per block, which means more blocks to run, the running time would be longer. But the actual performance still depends on the input point cloud size and sometimes the performance decrease may also be neglectable.

@zhanggefan thanks for the reply, not sure about the number of features, probably it was as you say

@zhanggefan I have checked the latest changes related to #382. Thank you a lot for fixing! The code now fails not in scatter_points.py, but in voxelize.py. As we already know the problem is in the empty input when points.shape is [0, 4]. In the voxelization_cuda.cu, the num_points at the line 193 is 0. Can you please fix that too?
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/voxelize.py", line 113, in forward
    self.max_num_points, max_voxels)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/voxelize.py", line 43, in forward
    dynamic_voxelize(points, coors, voxel_size, coors_range, 3)
    ```

I am now rechecking it again just to be sure.

@manonthegithub I am not familiar with that part (really lots of cuda code there). But I believe Dr.Zhang will help us with it if he has time! ;-) @ZwwWayne

@ZwwWayne @zhanggefan
yep the problem is in the empty input.
I have added  print("points shape: " + str(points.shape) + "  coors: " + str(coors.shape) + "  voxel size: " + str(voxel_size) + " coors_range: " + str(coors_range)) on the line 43 in voxelize.py right before dynamic_voxelize(points, coors, voxel_size, coors_range, 3)
And getting the following output:
points shape: torch.Size([8504, 4])  coors: torch.Size([8504, 3])  voxel size: [0.05, 0.05, 0.1] coors_range: [0, -40, -3, 70.4, 40, 1]
[>>>>>>>>>>>                 ] 768/1806, 10.9 task/s, elapsed: 70s, ETA:    95spoints shape: torch.Size([1182, 4])  coors: torch.Size([1182, 3])  voxel size: [0.05, 0.05, 0.1] coors_range: [0, -40, -3, 70.4, 40, 1]
[>>>>>>>>>>>                 ] 769/1806, 10.9 task/s, elapsed: 70s, ETA:    95spoints shape: torch.Size([7767, 4])  coors: torch.Size([7767, 3])  voxel size: [0.05, 0.05, 0.1] coors_range: [0, -40, -3, 70.4, 40, 1]
[>>>>>>>>>>>                 ] 770/1806, 10.9 task/s, elapsed: 70s, ETA:    95spoints shape: torch.Size([0, 4])  coors: torch.Size([0, 3])  voxel size: [0.05, 0.05, 0.1] coors_range: [0, -40, -3, 70.4, 40, 1]
Traceback (most recent call last):
  File "tools/train.py", line 212, in <module>
    main()
  File "tools/train.py", line 208, in main
    meta=meta)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmdet/apis/train.py", line 150, in train_detector
    runner.run(data_loaders, cfg.workflow, cfg.total_epochs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 125, in run
    epoch_runner(data_loaders[i], **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/epoch_based_runner.py", line 54, in train
    self.call_hook('after_train_epoch')
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/base_runner.py", line 307, in call_hook
    getattr(hook, fn_name)(self)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmdet/core/evaluation/eval_hooks.py", line 144, in after_train_epoch
    results = single_gpu_test(runner.model, self.dataloader, show=False)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmdet/apis/test.py", line 27, in single_gpu_test
    result = model(return_loss=False, rescale=True, **data)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/parallel/data_parallel.py", line 42, in forward
    return super().forward(*inputs, **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/parallel/data_parallel.py", line 153, in forward
    return self.module(*inputs[0], **kwargs[0])
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 84, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/base.py", line 60, in forward
    return self.forward_test(**kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/base.py", line 41, in forward_test
    return self.simple_test(points[0], img_metas[0], img[0], **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 404, in simple_test
    points, img=img, img_metas=img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_two_stage.py", line 207, in extract_feat
    pts_feats = self.extract_pts_feat(points, img_feats, img_metas)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_faster_rcnn.py", line 52, in extract_pts_feat
    voxels, coors = self.voxelize(points)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/autograd/grad_mode.py", line 15, in decorate_context
    return func(*args, **kwargs)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/mmcv/runner/fp16_utils.py", line 164, in new_func
    return old_func(*args, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/models/detectors/mvx_faster_rcnn.py", line 38, in voxelize
    res_coors = self.pts_voxel_layer(res)
  File "/home/kirilly/v2pearl5p36/lib/python3.6/site-packages/torch/nn/modules/module.py", line 550, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/voxelize.py", line 114, in forward
    self.max_num_points, max_voxels)
  File "/home/kirilly/git_repos/mmdetection3d/mmdet3d/ops/voxel/voxelize.py", line 44, in forward
    dynamic_voxelize(points, coors, voxel_size, coors_range, 3)
RuntimeError: CUDA error: invalid configuration argument

@manonthegithub  I also met this error. How can I solve it? I used the data created myself. Looking forward to your reply. Thanks a lot!

@clytze0216 so for me the problem was following:

when you run create_data.py it generates many things, and one of them is reduced velodyne data (in the folder <kitti_dataset>/training/velodyne_reduced and for testing too as I remember)
in my case some of those velodyne_reduced files were empty (no points in the range), you can just see which files are of 0 bytes size
the model was failing with the empty input for lidar
to solve this I just removed those samples from the list of samples for training as well as validation and test (you can find the corresponding files in <kitti_dataset>/ImageSets/), and regenerated the infos (create_data.py)

Hope that helps! Good luck!

@manonthegithub
This fix doesn't work, i don't have any empty sample in the velodyn_reduced.
I am running the demo with the model second on a pointcloud of my own like this:
python demo/pcd_demo.py /home/acatalan/Desktop/bin_dir/bin_dir_0/7447458364380.bin configs/second/hv_second_secfpn_6x8_80e_kitti-3d-car.py checkpoints/hv_second_secfpn_6x8_80e_kitti-3d-car_20200620_230238-393f000c.pth --show
and I get this error:
File "demo/pcd_demo.py", line 44, in
main()
File "demo/pcd_demo.py", line 31, in main
result, data = inference_detector(model, args.pcd)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/apis/inference.py", line 116, in inference_detector
result = model(return_loss=False, rescale=True, **data)
File "/home/acatalan/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/nn/modules/module.py", line 889, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/acatalan/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/fp16_utils.py", line 98, in new_func
return old_func(*args, **kwargs)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/models/detectors/base.py", line 61, in forward
return self.forward_test(**kwargs)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/models/detectors/base.py", line 42, in forward_test
return self.simple_test(points[0], img_metas[0], img[0], **kwargs)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/models/detectors/voxelnet.py", line 100, in simple_test
x = self.extract_feat(points, img_metas)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/models/detectors/voxelnet.py", line 42, in extract_feat
voxels, num_points, coors = self.voxelize(points)
File "/home/acatalan/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/home/acatalan/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/fp16_utils.py", line 186, in new_func
return old_func(*args, **kwargs)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/models/detectors/voxelnet.py", line 57, in voxelize
res_voxels, res_coors, res_num_points = self.voxel_layer(res)
File "/home/acatalan/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/nn/modules/module.py", line 889, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/ops/voxel/voxelize.py", line 138, in forward
self.deterministic)
File "/home/acatalan/Ensemble/mmdetection3d/mmdet3d/ops/voxel/voxelize.py", line 65, in forward
deterministic)
RuntimeError: CUDA error: invalid configuration argument
Out of 29 poinclouds I have, 10 of them run with no problem and 19 of them encounter this exception.
What can I do?

Hi, @aldakata
Sorry for the late reply.
More information is needed for further troubleshooting.
Could you please try set deterministic=False here, and re-run your experiment one more time?
https://github.com/open-mmlab/mmdetection3d/blob/c06c0189a5fe343722722659c9e72230b8283f07/mmdet3d/ops/voxel/voxelize.py#L13-L19
Please let me know if the errors are gone or anything weird happens.


⚠ AZ-Launcher has degraded performance

In 559948e, AZ-Launcher (https://az-launcher.nz/) experienced degraded performance:

HTTP code: 200
Response time: 2222 ms

Resolved: AZ-Launcher performance has improved in 013cc9e after 16 minutes.


[BEAM-7699] Propagate null check/comparison to deepEquals

This is trivial improvement of deepEqualsForMap.
Looking at https://github.com/apache/beam/pull/6845 and https://github.com/apache/beam/pull/8368, equality check can be simpler as checking null values will be done in next recursion.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Hi! what's the status for this change?

@TheNeuralBit is this a change your interested in taking over and finishing?

Yeah I could do that.
Based on the last comment it looks like the only action is to revert the actual change and make the PR only add tests?

Yeah I could do that.
Based on the last comment it looks like the only action is to revert the actual change and make the PR only add tests?

To my knowledge yes.


yotta modules allow case sensitivity

Forcing yotta modules to use lowercase letters is a PITA. This means that all class names would need to be lowercase to match the module name and namespace name or it it unintuitive to guess at the camelcase assuming we use the same coding guidelines from mbed v2. Maybe we've changed the coding guidelines but if not this will be a problem.

yotta modules are lowercase-only to prevent confusingly similar names: this isn't going to change!
That doesn't mean you have to use lowercase class or variable names. Because you know that there aren't case-only variants of your name, you're free to use any case you wish for your naming. yotta does not care about your case conventions. I don't have a link to the mbed OS coding conventions, but the yotta module tutorial includes some as an example: http://yottadocs.mbed.com/tutorial/tutorial.html


revamp api

Hi
some constructive feedback:
if you want MASS adaption of you wallet, then get rid of the cardano types.
Make the api as simple as possible: when sending a value send it as 12345.6789 ADA and not as a Value object.
When you send an address, send it as a bech32 address. Accept values in that format and transform your self.
Heck, you could have a raw api (with cardano types) and a default API with simple types.
One of the things that makes metamask and web3 so wonderful, is how easy it is to work with it. If you give this simplicity to web developers, you will be the standard wallet. Try to design APIs with your end user in mind, not the system you are interfacing with.
You can get in touch with me on discord if you want to discuss Anixai#4159.
PS:  for the rest I am sending you a lot of LOVE for creating nami wallet. Thanks for all your efforts! If you want help / contributers, let me know.
Jeroen

(and maybe have a small npm lib that can be used in the backend for instance as well, to verify signed data etc)

Yes I totally understand that, but it is intended to be this way right now. There is a standard I follow:
https://github.com/cardano-foundation/CIPs/pull/88
The types are part of the ledger specs, which makes the API very flexible. A top level API simply solves this problem and yes that's the plan, which makes this pretty much like web3 then. But at the moment I don't have the time to build it.

Without Alonzo and smart contracts, there is no reason to focus on a top level API at this stage.

@xocdr as @alessandrokonrad  mentioned it is following the standard as specified in CIP-30. The CIP is still a draft so if you have any comments about that they are best left there instead of in an individual wallet's repo. It is much better to have a single standard for communication with dApps instead of having a bunch of different wallets having different APIs, effectively either a) locking dApps to specific wallets (bad for users) or b) multiplying the work for dApp devs if they have to implement against multiple different APIs. (bad for devs)
Also keep in mind that as of the Mary hardfork with NFTs you can't just use a single number/string/whatever as you must support multiassets too, which can contain multiple in the same output. One issue with accepting this is that you would then have an inconsistency between parameters and return values since return values would have to always return the proper full cbor<value> type (or some other type capable of expressing multiassets). Concerning the bech32 addresses instead of cbor-encoded, there is already a comment in that CIP's PR about that asking if it should be changed to bech32 instead of cbor. It was cbor for consistency with the rest of the API. A type-choice between the two e.g. cbor<address> | string or cbor<value> | string could be possible, but you should post those suggestions in that CIP's PR to get the community's feedback.  However, as cbor is the standard across the cardano ecosystem and the fact that in order to use the other endpoints that require things like cbor<transaction> you likely would have access to the ability to easily (de)serialize simpler types like value or address in order to create those other types anyway.
If you want simple development that doesn't take into account multiassets or anything else like that then it's possible to write a wrapper library used from within the dApp that wraps these calls and then calls the corresponding API calls against the wallet's injected code, but it should only be the wallet's responsibility to provide a common standard that all dApps can interface with. Such a library could also provide additional utility functionality but this should not be a part of the wallet as long as the wallet provides access to the data required to implement that functionality. For example, web3 provides a tonne of extra functionality but requires a provider that has access to a full node (e.g. infura or self hosted node) to do so. This isn't really something that the wallet should need to be involved in (you must think about light wallets too) and can easily be a library that is part of the dApp instead.