add a pic

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
38
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
730
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
712
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
30
The patch does not generate ASF License warnings.

1598

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux f6c7465e47aa 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 7f1b76c

Max. process+thread count
447 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/1/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
79
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
825
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
863
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
28
The patch does not generate ASF License warnings.

1888

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux ecf52ccd67b0 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / c7c7a88

Max. process+thread count
306 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/2/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
42
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
713
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
718
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
25
The patch does not generate ASF License warnings.

1586

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux c77172c3ae4b 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / e872ceb

Max. process+thread count
412 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/3/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
42
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
781
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
1
The patch has no whitespace issues.

+1
shadedclient
771
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
27
The patch does not generate ASF License warnings.

1712

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux be2282582457 4.4.0-157-generic #185-Ubuntu SMP Tue Jul 23 09:17:01 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 00b5a27

Max. process+thread count
411 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/4/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
46
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
696
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
713
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
25
The patch does not generate ASF License warnings.

1563

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux 8f4b74d2314e 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / e356e4f

Max. process+thread count
411 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/5/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
87
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
844
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
867
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
32
The patch does not generate ASF License warnings.

1930

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux 6afa82e6aaac 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 094d736

Max. process+thread count
305 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/6/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
96
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
825
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
788
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
27
The patch does not generate ASF License warnings.

1834

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux b80d97034a78 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 69ddb36

Max. process+thread count
316 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/7/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
41
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ trunk Compile Tests _

+1
shadedclient
748
branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
785
patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1
asflicense
31
The patch does not generate ASF License warnings.

1702

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-372/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/372

Optional Tests
dupname asflicense

uname
Linux 1bc92aa5e82f 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 3329257

Max. process+thread count
435 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/8/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
10
https://github.com/apache/hadoop/pull/372 does not apply to trunk. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute for help.

Subsystem
Report/Notes

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-372/9/console

versions
git=2.17.1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.


ENH - Do not use pwd in aa_test

The test log is currently written in pwd, i.e. the current directory. This is ill-defined, as it is possible to start running aa_test from any directory.
What is the expected location for the aa_log file? Then make sure it is put there.

Since aa_test log is created before any parameter file is read, its not possible to put it in the acq_details main folder.
Also, if multiple tests are run, they all write to this same log file.
And, for CI, this would actually be a file that you DO want in the artifacts, to be able to look at the contents, so it should be at a well defined location.
Thus, although it is not that nice to put new files within the main directory structure, in this case it would be most logical to put it either in the main aa folder, or in the ./developer folder next to aa_test.m

I implemented logging thinking it was a useful addition because the tests would run unattended.
If its not workable with CI (or the group feels it is not useful) I would be open to removing it.

I'd rather keep the logfile and use it as the main artifact extended with the aa_jpeg_crawler.m.

Yes, my idea was just that in the two times that there is fullfile(pwd,'aa_test.log'), the pwd should be replaced with either aa.Path [but that is only available later, so needs some code shuffling], or fileparts(mfilename('full path')) [directly available, and if there is logging during aaClass it will be included].
[Actually, the filename should be created only once and put in a variable, not constructed-on-the-fly twice]


Exception/Errors seen in service logs resulting in clientApiError.

Rancher Version:v1.2.0-pre3-rc1
There are many automated test cases that report failure because of clientApiError encountered when waiting for service activation to be completed.

Docker-compose.yml
healthcheckfail:
log_driver: ''
labels:
io.rancher.container.pull_image: always
tty: true
log_opt: {}
image: nginx
stdin_open: true
rancher-compose.yml
.catalog:
name: "Health check"
version: "1.0.0"
description: "Services"
uuid: health-check-0
minimum_rancher_version: v0.46.0
healthcheckfail:
scale: 1
health_check:
port: 80
interval: 2000
recreate_on_quorum_strategy_config:
quorum: 1
initializing_timeout: 60000
unhealthy_threshold: 3
strategy: recreateOnQuorum
request_line: 'GET "/404" "HTTP/1.1\r\nHost: blah.com"'
healthy_threshold: 2
response_timeout: 2000
reinitializing_timeout: 50000

Following are all the "ClientApiError:" exceptions seen when running automation tests:
ClientApiError: Timeout: container starting [container:1i24]
ClientApiError: Failed to acquire lock [SERVICE.80]
ClientApiError: Canceling upgrade
ClientApiError: Failed to do service reconcile for service [414]

Version - master 9/10
checked my healthcheck service and it is not throwing error in today's master build.

Validation test on master builds did not report any of the ClientApiErrors tracked in this issue.
2 issues seen in validation runs are now tracked in https://github.com/rancher/rancher/issues/5944 and https://github.com/rancher/rancher/issues/5941.


if u have some error with passing, try mine

i use old labtop like 7 year old one to run bot(may have problem with screen resolution), idk why the screen detects mana and all other smoothly but doesnt clicks "pass" button well, so i made as clicking "spacebar" to pass. i may edit clicking x and y axis but its better to just press spacebar.
original code : https://github.com/ziminl/LoR-Bot/blob/master/Bot.py#L135
edited one : https://github.com/ziminl/LoR-Bot/blob/master/Bot.py#L152

Yeah passing of turns is not implemented intentionally. This is because it is hard to tell when to actually pass. If you implemented passing, what will happen is, for example, bot will cast a burst speed spell and it will think his turn is over and pass. There are also other such cases, where it could play more cards but will pass instead.
The solution is to enable auto passing in game.


Add api.neuvector.com api group resources to role creation

Summary
Fixes #11174

This adds the resources for the api.neuvector.com api group to the Global, Cluster, and Project/Namespace role editing pages.
Occurred changes and/or fixed issues

The resources for the apiGroups is a hardcoded list for each role type, this adds the resources for the neuvector group.
Technical notes summary

Since NeuVector resources contain both Cluster Scoped and Namespaced resources, the roles had to be modified within the RoleDetailEdit component to include unique labels.
Areas or cases that should be tested

Creating a Global, Cluster, and Project/Namespace role with any of the neuvector resources.

From the Users & Authentication page, navigate to Role Templates
Create both a Global Role and Cluster Role
For each role, ensure you can select both "Cluster Scoped" and "Namespaced" NeuVector resources and the apiGroup that is selected is api.neuvector.com
Create a Project/Namespaces Role
Ensure you can only select "Namespaced" resources

Global role with Cluster Scoped resource

Project/Namespace role with namespaced resource

Areas which could experience regressions

Screenshot/Video

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

I needed to create unique labels for both the cluster scoped and namespaced roles, in the RoleDetailEdit component I added a condition to check for the neuvectorApi group and apply unique labels based on the scope.
Also updated the manual testing steps.


Create MoM-2024-01-30.md

What type of PR is this?

documentation

What this PR does / why we need it:
Agenda for next meeting. to be updated with minutes

@bigludo7 Please review the meeting minutes. If you need some clarification as you were not in this one, let me know. Thanks

@jlurien for #141 not sure why waiting for Commonalities outputs. The guidelines stated: For this specific event, the data must feature terminationReason attribute.
There is not specification of the value enumeration and with the diversity of the APIs not sure it makes sense . For me I'm afraid that going to Commonalities will take unnecessary delay for a very short point - WDYT?

The question is about whether we should agree on the value for terminationReason across APIs, as I think that this case will happen for all APIs with subscriptions.
In QoD there is PR proposal that is somehow similar, to add a new reason for termination, even if  in QoD there are no explicit subscriptions and notifications are implicit to the QoS session, and there the reason value for this case is
    * `DELETE_REQUESTED`- User requested the deletion of the session before the requested duration expired

They also have NETWORK_TERMINATED as another reason.
For Geofencing I see SUBSCRIPTION_DELETED acceptable as well, but other APIs with subscriptions may decide on another value if it is not documented in Commonalities.


Update controller-tools to v2 beta5

/kind feature
Describe the solution you'd like
Update controller-tools to v2 beta5. See https://github.com/kubernetes-sigs/cluster-api/pull/1224 as an example.

/assign
/lifecycle active


Drag sprite with a mouse/trackpad with grid turned on

Resolves

Resolves #473

Proposed Changes
listen touch and mouse event when grid is on.
Reason for Changes
When grid on, stage could not listen to mouse/touch event, so bridge the event to stage.
Test Coverage

[x] macOS Catalina (10.15.6) with mouse
[x] iPad mini 2 (iOS 12.5.2)
[x] Amazon Fire HD 8 (2017) (Android 5.0)

SJR-164


Sample notebook move into language folders, but guide document is not update, so can not find file when following learning guide

here is folder sample notebooks move to

here is guide link

Thanks for letting us know! The docs have been fixed :)


Added Support for Django 1.11 and python 3.6

LEARNER-1182
This commit will add the support for django 1.11 and python 3.6

Coverage remained the same at 73.066% when pulling b84b1bb62fb7abd48d70b0db264764249d5646cb on ahsan/LEARNER-1182-add-support-for-django-1.11 into ee649fe87014c3948d3eec25e9580f7e6c9330c8 on master.

Coverage remained the same at 73.066% when pulling 92afa26d9b95c66d12497e829094f2dd1f71a0da on ahsan/LEARNER-1182-add-support-for-django-1.11 into ee649fe87014c3948d3eec25e9580f7e6c9330c8 on master.

Coverage remained the same at 73.066% when pulling 1d4349bc911b3988ce75b996b2330b26b34a1dce on ahsan/LEARNER-1182-add-support-for-django-1.11 into ee649fe87014c3948d3eec25e9580f7e6c9330c8 on master.

Coverage remained the same at 73.066% when pulling 1d4349bc911b3988ce75b996b2330b26b34a1dce on ahsan/LEARNER-1182-add-support-for-django-1.11 into ee649fe87014c3948d3eec25e9580f7e6c9330c8 on master.

Coverage remained the same at 73.066% when pulling 1d4349bc911b3988ce75b996b2330b26b34a1dce on ahsan/LEARNER-1182-add-support-for-django-1.11 into ee649fe87014c3948d3eec25e9580f7e6c9330c8 on master.


[Bug Report]: BatchProduceAsync seems to produce items out or order

Prerequisites

[X] I have searched issues to ensure it has not already been reported

Description
It looks like BatchProduceAsync can produce message out-of-order messages.
It happens from time to time, so the order doesn't seem to be deterministic.
Most of the time it does seem to produce messages in the right order, but not always.
Steps to reproduce
I was using this code to reproduce:
private sealed record Batch(Guid Id, List<ISpecificRecord> Messages);

private static Batch CreateBatch()
{
    var id = Guid.NewGuid();
    var messages = new List<ISpecificRecord>
    {
        new UserJoined { id = id, order = 1 },
        new UserDeactivated { id = id, order = 2 },
        new UserActivated { id = id, order = 3 }
    };

    return new(id, messages);
}

[Fact]
public async Task Should_preserve_order_of_messages()
{
    var batchesToSend = Enumerable.Range(0, 10).Select(_ => CreateBatch()).ToList();

    foreach (var batch in batchesToSend)
    {
        var toProduce =
            batch.Messages
                .Select(x => new BatchProduceItem(
                    fixture.TopicName,
                    batch.Id.ToString(),
                    x,
                    new MessageHeaders()))
                .ToList();

        await fixture.Producer.BatchProduceAsync(toProduce);
    }

    // assertion is omitted for brevity
}

I then look at the topic itself and see that some batches come out of order.
Expected behavior
I expect that the messages order is guaranteed by the batch producer all the time.
Actual behavior
Most often messages are coming in the right order: 1, 2, 3 but sometimes they are written in the wrong order.
KafkaFlow version
v3.0.10

Is it possible that the problem can be in the middleware?
I see that BatchProduceAsync executes Produce synchronously for each message, separately.
But it internally it does _middlewareExecutor.Execute which returns Task. This Task is dropped on the floor.
This could mean that multiple Tasks are just running in parallel and by chance can finish out-of-order.
If I am right, then this execution model is unsound.

That is exactly why is not guaranteeing in order producing. For it to guarantee in order producing, the code would need to wait until InternalProduce is called (this method pushed the message to the driver buffer).
It should ne very easy to reproduce this issue by adding a producing middleware with a descending timeout and see an inverse order of producing.
Let's say 3 messages with descending timeouts of 1s, 500ms, 0s.


Can't downscale to the original cluster size

Hi all,
First of all, thanks guys cloudbreak is really a cool stuff!
We have cluster of 8 nodes created using cloudbreak. We have a group_slave_1 (our data nodes) and group_slave_2 (worker nodes with only Node manager and ambari metric inside). Our HDFS replication factor is 2 and we have 2 data nodes and 1 worker node.
We scale the worker node based on application pending alert. It's working, depending to our load, cloudbreak add worker nodes in group_slave_2. After load we was expecting going back to 1 worker nodes based on our downscale policy (-1 node). But it not the case, at 3 worker nodes we have an exception in log saying that the replication factor is 2 so the cluster can't downscale. So we have now 2 data nodes and 3 working nodes and not 2 data nodes and 1 working nodes (our original cluster configuration)
What are we doing wrong?
Regards

Hey,
Cloudbreak does not allow you to scale down your cluster below replication factor + 1 node, so in your case below 3. It's a safety feature as it can happen that there is not enough space to move the data. This behavior might change in the future.

Hi,
Thanks for your reply but let me explain again. For hdfs stuff we have a
dedicated group with 2 nodes inside. What we scale is another group for
worker with only node manager component in side. The initial size of the
cluster was 8 nodes  (2 data nodes fors hdfs and one workernode) after
scale we have know a cluster oh 11 nodes  (2 data nodes fors hdfs and 3
workernode). Why in the replication factor cloudbreak don't count the
original 2 data nodes ?
Regards
Le ven. 26 févr. 2016 08:33, Krisztian Horvath<EMAIL_ADDRESS>a
écrit :

Hey,
Cloudbreak does not allow you to scale down your cluster below replication
factor + 1 node, so in your case below 3. It's a safety feature as it can
happen that there is not enough space to move the data. This behavior might
change in the future.
—
Reply to this email directly or view it on GitHub
https://github.com/sequenceiq/cloudbreak/issues/1357#issuecomment-189147179
.

I see. It looks like it's a bug in cloudbreak and ignores the fact that the host group you're trying to downscale does not have datanode in it so basically it doesn't allow any host group to scale below 3 in your case. Here's the relevant code for this behavior: decommission. Also if the RM's web port is open in the security group we check for the running applications and if those nodes have ApplicationMasters we exclude them from the decommission and can happen the same.
I'll create a JIRA for it and get it fixed. Thanks. Any feedback is welcome.

You got it!
Looking at the code the problem in decommisionning is getting the global replication factor: dfs.replication.
I also try setting dfs.replication at host group level but it's not working too :
{
            "name": "host_group_slave_2",
            "configurations" : [
        {
          "hdfs-site" : {
            "dfs.replication" : "0"
          }
        }
      ],
            "components": [
                {
                    "name": "NODEMANAGER"
                },
                {
                    "name": "METRICS_MONITOR"
                }
            ],
            "cardinality": "1"
        },

here the exception stack :
cbreak_cloudbreak_1 | 2016-02-26 09:47:05,666 [http-nio-8080-exec-7] clusterHostgroupAdjusmentChange:200 INFO  c.s.c.c.ClusterController - [owner:41c11a7e-46f5-4420-b830-94e0c795bebf] [type:STACK] [id:13] [name:testscale] Cluster host adjustment request received. Stack id: 13 /cbreak_cloudbreak_1 | 2016-02-26 09:47:14,675 [http-nio-8080-exec-7] verifyNodeCount:532 INFO  c.s.c.s.c.AmbariClusterService - [owner:41c11a7e-46f5-4420-b830-94e0c795bebf] [type:STACK] [id:13] [name:testscale] Cannot downscale: replication: 2, adjustment: -1, filtered host size: 2 /cbreak_cloudbreak_1 | 2016-02-26 09:47:14,677 [http-nio-8080-exec-7] badRequest:46 ERROR c.s.c.c.ExceptionControllerAdvice - [owner:cloudbreak] [type:cloudbreakLog] [id:undefined] [name:cb] There is not enough node to downscale. Check the replication factor and the ApplicationMaster occupation. /cbreak_cloudbreak_1 | com.sequenceiq.cloudbreak.controller.BadRequestException: There is not enough node to downscale. Check the replication factor and the ApplicationMaster occupation. /cbreak_cloudbreak_1 |  at com.sequenceiq.cloudbreak.service.cluster.AmbariClusterService.verifyNodeCount(AmbariClusterService.java:533) ~[cloudbreak.jar!/:na] /cbreak_cloudbreak_1 |  at com.sequenceiq.cloudbreak.service.cluster.AmbariClusterService.collectDownscaleCandidates(AmbariClusterService.java:454) ~[cloudbreak.jar!/:na] /cbreak_cloudbreak_1 |  at com.sequenceiq.cloudbreak.service.cluster.AmbariClusterService.updateHosts(AmbariClusterService.java:229) ~[cloudbreak.jar!/:na] /cbreak_cloudbreak_1 |  at com.sequenceiq.cloudbreak.controller.ClusterController.clusterHostgroupAdjusmentChange(ClusterController.java:208) ~[cloudbreak.jar!/:na] /cbreak_cloudbreak_1 |  at com.sequenceiq.cloudbreak.controller.ClusterController.updateCluster(ClusterController.java:186) ~[cloudbreak.jar!/:na] /cbreak_cloudbreak_1 |  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_79] /cbreak_cloudbreak_1 |  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_79] /cbreak_cloudbreak_1 |  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_79] /cbreak_cloudbreak_1 |  at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_79] /cbreak_cloudbreak_1 |  at org.springframework.web.method.support.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:215) ~[spring-web-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:132) ~[spring-web-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104) ~[spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:749) ~[spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:689) ~[spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:83) ~[spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:938) ~[spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:870) ~[spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:961) [spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.FrameworkServlet.doPut(FrameworkServlet.java:874) [spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) [javaee-api-7.0.jar!/:na] /cbreak_cloudbreak_1 |  at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:837) [spring-webmvc-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [javaee-api-7.0.jar!/:na] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat-embed-websocket-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:110) [spring-boot-actuator-1.1.8.RELEASE.jar!/:1.1.8.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.springframework.boot.actuate.autoconfigure.EndpointWebMvcAutoConfiguration$ApplicationContextHeaderFilter.doFilterInternal(EndpointWebMvcAutoConfiguration.java:280) [spring-boot-actuator-1.1.8.RELEASE.jar!/:1.1.8.RELEASE] /cbreak_cloudbreak_1 |  at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.0.7.RELEASE.jar!/:4.0.7.RELEASE] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbreak_cloudbreak_1 |  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-embed-core-7.0.55.jar!/:7.0.55] /cbr

Yep, thanks for checking, we'll fix this.

This issue has been fixed and will be part of the next release https://github.com/sequenceiq/cloudbreak/commit/6823e693d646a57c589492b9104e0c4b94e38e8b


Missing symbols error

100s of missing symbol errors
I submitted my workspace to have a look at it, and I've asked stuff but haven't got a response. Have you found any errors and how to fix them? Thanks

I did not have access to your google drive. Give me a download link I can use if you want me to test your workspace.

I did not have access to your google drive. Give me a download link I can use if you want me to test your workspace.

Can you access?

Yes and your errors have nothing to do with the plugin. Tons of unrelated minecraft classes are causing missing symbol errors too. Therefore, I do not have any reason to help you with this issue here as this page is only for issues relating to the plugin.

Oh, when I put it on the main MCreator errors they said it was to do with the plugin.. idk what they were on about
Thank you, and sorry for wasting your time

Yes and your errors have nothing to do with the plugin. Tons of unrelated minecraft classes are causing missing symbol errors too. Therefore, I do not have any reason to help you with this issue here as this page is only for issues relating to the plugin.

Ok, so when I asked MCreator support, they said:
"Some plugins is overriding some important generator files. This is a plugin problem."

I have no other plugins installed btw

"error: package software.bernie.geckolib3 does not exist
This error can't be caused by MCreator as MCreator does not provide anything geckolib related to be able to emit this error.
Please consult with plugin author. This tracker is for core software bugs"

I suggest you head over to your workspace's folder and delete the .mcreator and .gradle folders

thanks but still same error...

I suggest you head over to your workspace's folder and delete the .mcreator and .gradle folders

i've tried this multiple times and it never fixes it

that didnt do anything but thanks for suggesting

go for it if you want but from what I see this has nothing to do with my plugin.

go for it if you want but from what I see this has nothing to do with my plugin.

I have looked through the logs, heres what I found: https://gist.github.com/jhe675/ac66c2df4b1d4d4974fc7bbc168fdc50
If you look at it, you can see the missing symbols errors only show next to the animation code, and it only shows to geckolib entites. So I am 99% confident it is a plugin error

And from what I see here I am 99.9% confident that this error is completely on your end and would not happen if you were to install MCreator 2023.2 along with the latest version of my plugin and make a workspace. Please stop asking for help on something I told you many times is not an issue with the plugin's code.


How to transfer BTC from a wallet.db back into my (private) wallet ?

Hi,
during my first attempt with chainpoint gateway I loaded my ~/.chainpoint/gateway/.lnd/data/chain/bitcoin/mainnet$ wallet.db with some 0.0... BTC - but I screwed up this machine and I started (successfully) with a 2nd machine.
But now I have this wallet.db in a non working environment containing "some" BTC ...
What can I do to transfer these BTC from this wallet.db back into my main wallet ?
Thanks for any hint :-).
Best wishes,
Jo ...

I'd probably try this:
You can move the old wallet.db to the new machine. You can then create the requisite docker secrets that you should have saved from the old machine:
  `printf ${walletPassword} | docker secret create HOT_WALLET_PASS -`,
  `printf '${cipherSeed}' | docker secret create HOT_WALLET_SEED -`,
  `printf ${address} | docker secret create HOT_WALLET_ADDRESS -`

The wallet should unlock.
If this doesn't work, I'd say you should take the init script from gateway and modify it to accept your existing password and seed instead of generating a new one in this method: https://github.com/chainpoint/chainpoint-gateway/blob/master/init/index.js#L115

Thanks for your quick reply Jacob !
Will give this a try :-).


change the use of environment variables

@dantownsend What do you think about the approach of using environment variables in this PR. Another option is to not use the .env file but pass the env vars to docker run like this
docker run -d -e DB_NAME='some_db_name' \
 -e DB_PASSWORD='some_db_password' \
 -e DB_USER='some_db_user' \
 -e DB_HOST='some_db_host' \
 -e DB_PORT='some_db_port' \
 -e USERNAME='piccolo' \
 -e PASSWORD='piccolo123' \
 -e<EMAIL_ADDRESS>\
 --network=host --name admin_container piccolo_admin

I'm not a Docker expert, but I don't find it convenient to use ENV vars in Dockerfile. In docs is also a warning "Note that, because the environment variables you set persist in containers, using them can lead to unintended side-effects for the application's runtime."

@sinisaos I think we need to allow the users to pass in environment variables. Even though it's a pain to pass them in via the command line, most users with have something like Docker Compose, or Kubernetes, where the config is a YAML file, which makes it really easy to specify environment variables.
There will reach a point though where environment variables alone becomes unmanageable. Piccolo Admin has so many potential config options, that we will need to allow some kind of config file (YAML or something). We could let the user add the config file to the container, or have some kind of UI which guides the user through the options, and generates the config. Or maybe even stores the config within the SQLite database.
I have this repo from a few years ago where I experimented with this a bit:
https://github.com/piccolo-orm/piccolo_admin_docker
The repo is a mess though. I started playing around with a config UI:
https://github.com/piccolo-orm/piccolo_admin_docker/tree/main/config_tool
But didn't get very far. I was using a library which generated UI from a JSON schema. I thought it would save time, but honestly it is kind of a pain. So if we built a config tool, we may as well just build the UI ourselves from scratch.

@dantownsend I agree some sort of UI would be great. Unfortunately the links you post are returning a 404. I find using an .env file to be most convenient, because the user just needs to fill in that .env file and run cp .env.example .env && rm .env.example and they ready to go. Docker compose would be almost the same with something like this
services:
  web:
    build: .
    command: python app/main.py
    volumes:
      - .:/app
    env_file:
      - .env

Docker run also has an interactive mode flag (-it) with which we can ask for user input similar to piccolo asgi new. I'm experimenting with it a bit so I wanted to hear your thoughts. Thanks for the answer.

@dantownsend sorry to interrupt, but what do you think about the latest changes. Is this a good direction to use Piccolo Admin config options (using a yaml file)?

@sinisaos I think having a YAML config file makes sense - having everything as an environment variable would be unmanageable.
The closest comparable thing I have worked with is self hosted GitLab, which all runs in a Docker container. They use a mix of environment variables and a Ruby config file which is mounted inside.

The closest comparable thing I have worked with is self hosted GitLab, which all runs in a Docker container. They use a mix of environment variables and a Ruby config file which is mounted inside.

@dantownsend I think we have a similar thing here. Secrets (sensitive information) are stored in an .env file which I think is a good practice. User configuration (how user wants to display columns and other things) is stored in yaml file which is added to container. How the user should format the yaml file is shown in the readme as an example. The user must read the Piccolo Admin docs to see how it works, but basically with these changes we can use Piccolo Admin with an existing (legacy) database if Piccolo Admin supports database columns. I will also add rich_text_columns (user needs to read docs to see only Text column is supported to get WYSIWYG editor) and link_column (again user needs to read docs to see that if link_column is enabled, primary_key column should be disabled (not used)).

@dantownsend I will merge this PR. Everything from this PR works on localhost (I don't have the ability to test with online database, but I think it should work if network_mode: "host" from docker-compose.yml is removed), but feel free to make changes as you think is best.


Fix default fingerprinting when using synthetic traces

I think I've found a bug w/ fingerprinting and synthetic traces.
When using synthetic traces via the globalOption stracktrace: true,  there is an attempt to maintain the legacy grouping behavior and fingerprint on msg, not stack trace.
Looks like when this was implemented, there was a few oversights. Here is the breaking code

The default fingerprint is dropped and never gets to sentry
The fingerprint value is of the wrong type

First, there is an attempt to create a default fingerprint from the msg param passed to captureMessage. The fingerprint property is added to the options variable but the values from options are not merged back to data after the fingerprint property is set. The end-result is that fingerprint ends up getting dropped and it never makes it to sentry.
The other issue w/ the existing code is that fingerprint is set to a string value. Sentry does not like raw strings and it will ignore the fingerprint unless its an array of strings. I've modified the fingerprint value to be an array of strings.
Here is my setup and some of the JSON payloads to make things a little clearer.
Sentry 8.22.0
Raven 3.23.1
Config: {stacktrace: true}
before the fixes: (notice the ["{{ default }}"] fingerprint)

after including the fingerprint as a string: (note the fingerprint and the errors)

after including the fingerprint as an array:

👍

Thanks for contributing to our lovely codebase! :)
Took your changes, made some stylistic changes and unified some code, made sure it works and merged manually to master (still as yours commit of course) - https://github.com/getsentry/raven-js/commit/8f8a62487c7ef245e55561e94c319a23ff7625e4
Will release it next week.
Cheers! :)


chore: create develop branch to development

create develop branch and assigning it as default for changes, is a best practice and helps to protect main branch which would only be used for prod.

hey @0xneves please assign this to me!

Hey @luislucena16
We discussed finishing the current incentives round before a release, which would then split into the development branch. Active issues on top of the main branch will soon cease. Let's leave this chore on standby from now. We scheduled this release for January.

@0xneves
why not use develop for development in general?

Active issues on top of the main branch will soon cease.
We discussed finishing the current incentives round before the release of the development branch.
I agree that mature projects should not use the main much. Our project is still a baby, it's not an issue.

right! understood! :)

Hey @luislucena16, now it's time to rise from the ashes and submit the develop branch as you proposed.

okay, I'm going to do it!

done here: https://github.com/blockful-io/swaplace-contracts/pull/192
I created only a comment to push develop branch

I upload a PR and leave it for you to configure the policies?

There is no need for policies, just submit a copy of the main branch named develop. We will move forward on the develop but will keep the main as the default.

yes @0xneves, but remember that I have a fork and I have my develop branch there, I don't have permissions to do it from here

It's okey, I will create the branch them!

Issues will be directed to the develop branch now.

@0xneves nice!!


File name not as expected

In document Pino-roll said:

dateFormat?: the format for appending the current date/time to the file name. When specified, appends the date/time in the provided format to the log file name. Supports date formats from date-fns (see: date-fns format documentation). For example: Daily: 'yyyy-MM-dd' → error.2024-09-24.log Hourly: 'yyyy-MM-dd-hh' → error.2024-09-24-05.log

But with the below config file name output not as expected
const transport = pino.transport({
	targets: [
		{
			target: 'pino-pretty',
			options: {
				colorize: true,
				translateTime: true,
			},
		},
		{
			target: 'pino-roll',
			options: {
				file: join('logs', 'http'),
				extension: 'log',
				dateFormat: 'yyyy-MM-dd',
				frequency: 'daily',
				mkdir: true,
			},
		},
	],
});

Output file name:

My expected is file name should be  http.2024-12-31.log

Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.

Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.

@mcollina I will give it a try, happy new year by the way.


docs: fix several mistakes

This fixes several errors in the doc-reference with the actual
implementation, and clarifies locations and filenames.

/cc @squeed if you don't mind having a look if you are passing by. Otherwise I will self-merge tomorrow.


[RND-403] - Anonymized Request Body Logging

Wasn't sure if we wanted the standard writeRequestToLog call in this code, so included it for now, can remove if unneeded

This PR looks great to me but I haven't been able to run it yet locally, so not marking as approved.


Annotate implicit fallthroughs

Now that we've got -Wimplicit-fallthrough turned on in the Core repo, we'll see this output during builds including minisketch (I've put together a branch using the new build system changes, to test https://github.com/bitcoin/bitcoin/pull/21859, here: https://github.com/fanquake/bitcoin/tree/minisketch_integration).
We turned this warning on in https://github.com/bitcoin/bitcoin/pull/21430, and for at least leveldb, made use of it's FALLTHROUGH_INTENDED macro. See details here: https://github.com/bitcoin-core/leveldb/blob/f8ae182c1e5176d12e816fb2217ae33a5472fdd7/util/hash.cc#L11.
  CXX      minisketch/src/libminisketch_a-minisketch.o
minisketch/src/minisketch.cpp:104:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            case 2:
            ^
minisketch/src/minisketch.cpp:104:13: note: insert '[[fallthrough]];' to silence this warning
            case 2:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:104:13: note: insert 'break;' to avoid fall-through
            case 2:
            ^
            break;
minisketch/src/minisketch.cpp:107:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            case 3:
            ^
minisketch/src/minisketch.cpp:107:13: note: insert '[[fallthrough]];' to silence this warning
            case 3:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:107:13: note: insert 'break;' to avoid fall-through
            case 3:
            ^
            break;
minisketch/src/minisketch.cpp:110:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            case 4:
            ^
minisketch/src/minisketch.cpp:110:13: note: insert '[[fallthrough]];' to silence this warning
            case 4:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:110:13: note: insert 'break;' to avoid fall-through
            case 4:
            ^
            break;
minisketch/src/minisketch.cpp:113:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            case 5:
            ^
minisketch/src/minisketch.cpp:113:13: note: insert '[[fallthrough]];' to silence this warning
            case 5:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:113:13: note: insert 'break;' to avoid fall-through
            case 5:
            ^
            break;
minisketch/src/minisketch.cpp:116:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            case 6:
            ^
minisketch/src/minisketch.cpp:116:13: note: insert '[[fallthrough]];' to silence this warning
            case 6:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:116:13: note: insert 'break;' to avoid fall-through
            case 6:
            ^
            break;
minisketch/src/minisketch.cpp:119:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            case 7:
            ^
minisketch/src/minisketch.cpp:119:13: note: insert '[[fallthrough]];' to silence this warning
            case 7:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:119:13: note: insert 'break;' to avoid fall-through
            case 7:
            ^
            break;
minisketch/src/minisketch.cpp:122:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            case 8:
            ^
minisketch/src/minisketch.cpp:122:13: note: insert '[[fallthrough]];' to silence this warning
            case 8:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:122:13: note: insert 'break;' to avoid fall-through
            case 8:
            ^
            break;
minisketch/src/minisketch.cpp:125:13: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
            default:
            ^
minisketch/src/minisketch.cpp:125:13: note: insert '[[fallthrough]];' to silence this warning
            default:
            ^
            [[fallthrough]];
minisketch/src/minisketch.cpp:125:13: note: insert 'break;' to avoid fall-through
            default:
            ^
            break;
8 warnings generated.

The code is also actually wrong; there should be breaks here.

Haha, I had the same two reactions :)
Agree about adding breaks vs fallthroughs. Fallthroughs would imply that other impls should be tried if the requested one fails. This was actually my assumption and I was puzzled as to why generic wasn't the default fallback in case of absent clmul instructions, but I see now that fallbacks aren't intended.
It seems wonky in a few other ways too, though. How about breaking up the cases entirely like this: https://github.com/theuni/minisketch/commits/fixup-field-switch ?

@theuni LGTM

This has been fixed by #47.


Update rules regarding date_format can be globally set

see: https://github.com/baianat/vee-validate/releases/tag/2.0.0-rc.7

Hey, much appreciated. Do you mind also updating the docs src, so future builds doesn't overwrite your work.
You can find it here:
https://github.com/baianat/vee-validate/blob/master/docs/src/templates/markdown/rules/validations.md


Add forests info to the package

Add extra info to the package

No need to do or implement.

forsts


Select base branch from github actions

@ChaituVR it would be better to design things so these frequent hotfixes aren't needed. Like moving the networks to an endpoint instead

@samuveth Yep for sure. But I think, irrespective of that we may still need this :)

@mktcode please review this when you have time


Add YOLO object detection model

What does this PR do?
This PR adds the YOLO object detection model. The implementation is based on the YOLOv3 and YOLOv4 Darknet implementations, although it doesn't include all the features of YOLOv4. Detection seems to work with weights that have been trained using the Darknet implementation, so the network architecture should be more or less identical. The network architecture is read from a configuration file in the same format as in the Darknet implementation. It supports loading weights from a Darknet model file too, if you don't want to start training from a randomly initialized model.
Fixes #22
Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes?
[x] Did you write any new necessary tests? [not needed for typos/docs]
[x] Did you verify new and existing tests pass locally with your changes?
[x] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review

[x] Is this pull request ready for review? (if not, please submit in draft mode)

Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

Hello @senarvi! Thanks for opening this PR.

In the file pl_bolts/models/detection/yolo/yolo_config.py:

Line 94:16: E713 test for membership should be 'not in'

In the file pl_bolts/models/detection/yolo/yolo_layers.py:

Line 438:23: E741 ambiguous variable name 'l'

In the file pl_bolts/models/detection/yolo/yolo_module.py:

Line 42:5: E125 continuation line with same indent as next logical line

Do see the Hitchhiker's guide to code style

this is awesome. @Borda @kaushikb11 let's get this merged? and can we add as backbones available in Flash?

The PR is great 🎉 Nice implementation of YOLO v4. It's hard to do in PyTorch since it's model is originally written in DarkNet. 😅 Great work
A few comments, the reason is this pr on torchvision. Hence I think it could be safer to use torchvision.ops ?

Thanks! Indeed it's somewhat problematic how this project overlaps with torchvision. I definitely agree that I would rather use torchvision functions than copy them here, for the exact reason that you pointed out. We could use box_iou(images, target).diagonal() if we think it's worth the performance hit.

@senarvi The tests failing here are not related to these PR changes. It will be fixed in #580

overall it looks good to me, mind check minor comments from @akihironitta

I think the comments from @akihironitta have been resolved. Let me know if there's still something.

I changed still one detail. The boxes are directly predicted in coordinates to the input image, not in the [0, 1] range. There are three reasons:

a bit fewer scaling operations,
consistency with torchvision models, and
better resolution for representing coordinates with half-precision floats.

One more small improvement: image size from the configuration file was passed to DetectionLayer constructor, and any images fed to the network had to have the same size. Now the image size from the input batch is passed to its forward() method, so one can use a different size during inference, or - at least in theory - train with different image sizes.

Hi there! This looks like an amazing PR. What is the timeline for merging?

The PR is good to go! But there are failing tests.
@akihironitta Could you please assist @senarvi with the failing tests, so we could go ahead with merging?

@kaushikb11 Sure, I'll look into this within 24 hours :)

Great, thanks @kaushikb11 @senarvi @akihironitta !

A test was failing because / was used on integer tensors, which is deprecated. I fixed it, but now I don't get a proper error message anymore, why the tests are stuck. Maybe just try rerunning them? The tests were already passing earlier, so there shouldn't be anything major anymore.

@senarvi I approved and reran the tests. https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks was blocking you from running tests in CI.

Still one check fails to run. @akihironitta could you check what's wrong?

All of these tests are failing due to the unavailability of MNIST datasets (http://yann.lecun.com/exdb/mnist/index.html is 503 at this moment), so I believe the errors are related to none of the changes in this PR. Let me fix the issue in another PR.

@Borda what was the solution in the end for this mnist dataset issue ?

I created an issue for the MNIST problem. #632

Looks like #633 was merged. I still see a few failures. Anything I can do to help?

@senarvi Could you merge master?

@akihironitta I merged master and I can see that the MNIST fix is in my source branch, but the tests still fail with HTTP Error 503.

Merged master again, but now test_data_monitor.py::test_base_log_interval_* tests seem to be failing.

Can there be an example of using the COCO dataset instead of the Pascal VOC dataset in the data module?

Currently there's no COCO data module. Adding a COCO data module is trivial, but one of the principles of this project is to keep pull requests simple and not to include several things in one pull request. So I don't know. Should I include a COCO data module in this pull request?

Can there be an example of using the COCO dataset instead of the Pascal VOC dataset in the data module?

Currently there's no COCO data module. Adding a COCO data module is trivial, but one of the principles of this project is to keep pull requests simple and not to include several things in one pull request. So I don't know. Should I include a COCO data module in this pull request?

It might be beneficial to remove the data module part - since it is so tied to VOC, and have another PR or set of PRs that implement the different types of datamodules.
I tried to use the VOC one as a template for COCO, and I just couldn't get where I needed to. That's why I was asking.

Can there be an example of using the COCO dataset instead of the Pascal VOC dataset in the data module?

Currently there's no COCO data module. Adding a COCO data module is trivial, but one of the principles of this project is to keep pull requests simple and not to include several things in one pull request. So I don't know. Should I include a COCO data module in this pull request?

It might be beneficial to remove the data module part - since it is so tied to VOC, and have another PR or set of PRs that implement the different types of datamodules.
I tried to use the VOC one as a template for COCO, and I just couldn't get where I needed to. That's why I was asking.

What exactly do you suggest removing? There's a small change to the existing VOC data module that allows passing transforms for both images and target boxes, for example, resizing both the image and its target boxes. This lets us see that training on VOC data works. The dummy CLI is similar to that of the currently only object detection model, FasterRCNN, and is meant more like sample code rather than a useful tool. I agree that a pull request for COCO data module would be useful, and could also update the CLIs so that they support COCO data.
Implementing a data module for COCO should be quite easy using the VOC data module as a template. Just remember to convert the coordinates from (x1, y1, width, height) to (x1, y1, x2, y2).

@senarvi could you check the failing tests? and mind allow edit for the maintainers... :rabbit:

@senarvi could you check the failing tests? and mind allow edit for the maintainers... 🐰

@Borda the test was failing because I was introduced a bug in the MSE loss, when I fixed the IoU loss. Both should work now. How do I allow edit for the maintainers?

@senarvi could you check the failing tests? and mind allow edit for the maintainers... 🐰

@Borda the test was failing because I introduced a bug in the MSE loss, when I fixed a problem in the IoU loss. Both should work now. How do I allow edit for the maintainers?

It seems that "Allow edits from maintainers" is not possible when the source repository is under an organization.

@Borda I noticed also the formatting issues and fixed them by running the new formatting tools.

VOCDetectionDataModule was updated to better conform to the new data module interface. The constructor takes batch size and the transforms take image and target. We can now pass the data module to Trainer, instead of the dataloaders. train_dataloader() and val_dataloader() still support image-only transforms, but I don't see any need for using them.

The test suite found still one problem with integer division with an older PyTorch version. @Borda could you restart the CI? I don't see the error when running the tests with my PyTorch installation.

@senarvi Hi, thanks again for all your work and patience! Just restarted CI again. I'll try to be active on this PR for the next few days until we get this PR merged :]

@akihironitta correct me if I'm wrong, but the remaining error was something about CIFAR dataset and not related to this pull request.

@akihironitta ok, done.


snapshot of docs

Signed-off-by: Aditya Chatterjee<EMAIL_ADDRESS>Description
This PR fixes #
Notes for Reviewers
Signed commits

[ ] Yes, I signed my commits.

🚀 Preview for commit 11c03bffa3273df95773284927fe75e8d5f7ad75 at: https://63122a0f0f3d5525ef29bf9c--meshery-docs-preview.netlify.app

🚀 Preview for commit 5216ecaa6d0d61327f9eef0cf205ae50f4ab43da at: https://63122d6e70ced900614649ce--meshery-docs-preview.netlify.app


Allow different response classes via klass param

Allow any subclass of http.HttpResponseBase
Default to http.HttpResponse
Do a quick issubclass() check on the argument

Not sure exactly what's up with the failed checks - something about Error fetching remote repo 'origin'.

This kind of change requires an accepted ticket.

Closing per ticket.


fix: secret saved indicator on ui for datasource forms

Description
Secret saved indicator on ui exists if the datasource field has a valueExistPath and server sends back the boolean value for the specific field in secretExists key.
The UI would appear as follows :
When the password is saved and there exists a key valueExistPath for Password field and the value in secretExists is true then

When password field is not focused. An overlay indicating the password shows up.

When the password field is focused. The overlay goes away.

TL;DR
Fixes #14783
Media
Loom Video of 4 sec
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Manual

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=a53f527

/perf-test

/perf-test

/ok-to-test sha=e34091f


Define a minimum header hight

Hi, love this plugin well written.
I'm trying to make a header with several animated objects in it that fade out but some will stay. So far i have not figured out where the final offset is calculated to keep some of the header without closing it compleately

Hi @kiwina can you share some code or a screenshot?

Same here: How is it possible to set a minimum height of the remaining collapsible header so that there can be shown an ActionBar? It should look similar to that:

Same here: How is it possible to set a minimum height of the remaining collapsible header so that there can be shown an ActionBar? It should look similar to that:

Hi @PentamapRainer you can render the toolbar above the CollapsibleTabView and pass the same Animated.Value to both ()
I have a setup like this where I'm using a react-navigation header and animating the title when the user is scrolling.

Hi @PentamapRainer you can render the toolbar above the CollapsibleTabView and pass the same Animated.Value to both ()
I have a setup like this where I'm using a react-navigation header and animating the title when the user is scrolling.

When I try to render the toolbar above the CollapsibleTabView with following code, then the CollapsibleTabView is not shown any more. Just the Text element is shown.
<View>
    <Text>HERE COMES THE NAVIGATIONBAR</Text>
    <CollapsibleTabView<Route>
        navigationState={{ index, routes }}
        renderScene={renderScene}
        onIndexChange={handleIndexChange}
        renderHeader={renderHeader}
        headerHeight={HEADER_HEIGHT}
        tabBarHeight={150}
        {...props}
    />
</View>

So where do I have to render the NavigationBar above the  CollapsibleTabView?

When I try to render the toolbar above the CollapsibleTabView with following code, then the CollapsibleTabView is not shown any more. Just the Text element is shown.
<View>
    <Text>HERE COMES THE NAVIGATIONBAR</Text>
    <CollapsibleTabView<Route>
        navigationState={{ index, routes }}
        renderScene={renderScene}
        onIndexChange={handleIndexChange}
        renderHeader={renderHeader}
        headerHeight={HEADER_HEIGHT}
        tabBarHeight={150}
        {...props}
    />
</View>

So where do I have to render the NavigationBar above the  CollapsibleTabView?

Did you try flex: 1?

Did you try flex: 1?

Did you try flex: 1?

Thanks a lot! That worked:
<View style={{flex:1}}>
    <Text>HERE COMES THE NAVIGATIONBAR</Text>
    <CollapsibleTabView<Route>
        navigationState={{ index, routes }}
        renderScene={renderScene}
        onIndexChange={handleIndexChange}
        renderHeader={renderHeader}
        headerHeight={HEADER_HEIGHT}
        tabBarHeight={150}
        {...props}
    />
</View>

Did you try flex: 1?

Thanks a lot! That worked:
<View style={{flex:1}}>
    <Text>HERE COMES THE NAVIGATIONBAR</Text>
    <CollapsibleTabView<Route>
        navigationState={{ index, routes }}
        renderScene={renderScene}
        onIndexChange={handleIndexChange}
        renderHeader={renderHeader}
        headerHeight={HEADER_HEIGHT}
        tabBarHeight={150}
        {...props}
    />
</View>

One more question to this issue: Is it possible to make the collapsible header behind the (transparent) NavigationBar, so that the header image is visible behind the NavigtionBar when scrolling to the top.
This is how it looks now:

This is how it should look like:

One more question to this issue: Is it possible to make the collapsible header behind the (transparent) NavigationBar, so that the header image is visible behind the NavigtionBar when scrolling to the top.
This is how it looks now:

This is how it should look like:

@PentamapRainer If I got your question right, you can interpolate the opacity of the "bar", to do so, you can use the animated value coming from the CollapsibleTabView and interpolate it between 0 and the header height to get the opacity, something like
  const backgroundOpacity = scrollYPosition.interpolate({     inputRange: [0, scrollSize],     outputRange: [0, 1],     extrapolate: 'clamp',   });

@PentamapRainer If I got your question right, you can interpolate the opacity of the "bar", to do so, you can use the animated value coming from the CollapsibleTabView and interpolate it between 0 and the header height to get the opacity, something like
  const backgroundOpacity = scrollYPosition.interpolate({     inputRange: [0, scrollSize],     outputRange: [0, 1],     extrapolate: 'clamp',   });

@PedroBern Is it possible to configure a minimum header height with the v3 version? While the approach of placing the component outside the Collapsible tab view component is an easy and simple approach, if you need to place the content with an absolute position on the header(something similar to the previous image on the comments), it becomes really hard to come with a solution since the absolute position removes the component from the screen flow and its size is not taken into consideration.
This is more of a discussion other than an "issue" for me, wasn't just sure how to reach you to discuss it, thanks in advance.

@PedroBern Is it possible to configure a minimum header height with the v3 version? While the approach of placing the component outside the Collapsible tab view component is an easy and simple approach, if you need to place the content with an absolute position on the header(something similar to the previous image on the comments), it becomes really hard to come with a solution since the absolute position removes the component from the screen flow and its size is not taken into consideration.
This is more of a discussion other than an "issue" for me, wasn't just sure how to reach you to discuss it, thanks in advance.

@tcorreiaubi no, it's still no possible in v3, I know, this desired configuration is probably hard to get with the current implementation, but it's open for PR.
The next milestones are adding a default tab bar (WIP), then integrate v3 with react-navigation.
Also, I'm planning to add something like visibleHeaderOffset into the context to get the visible delta and easily interpolate, for example, the backgroundColor/opacity of the header.

@tcorreiaubi no, it's still no possible in v3, I know, this desired configuration is probably hard to get with the current implementation, but it's open for PR.
The next milestones are adding a default tab bar (WIP), then integrate v3 with react-navigation.
Also, I'm planning to add something like visibleHeaderOffset into the context to get the visible delta and easily interpolate, for example, the backgroundColor/opacity of the header.


Fix 1045

I assume you meant that this fixes #1405 not #1045, right?

We are in the middle of a release so I will merge this once that finishes, thanks


update(userspace/engine): make rule_matching strategy stateless

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind release

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area engine

/area tests

/area proposals

/area CI

What this PR does / why we need it:
Since process_event could be called by multiple threads, passing the rule_matching strategy to the engine at each call rather than storing state inside it is better for thread safety.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: loresuso
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

We already bumped the engine version for this feature. I don't think we need another bump this time

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jasondellaluce, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 35a61788728cee01996ce767bd9dfecdd5dbdfd6

/milestone 0.36.0

/unhold

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, jasondellaluce, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


hdfs - replace import-time cluster actions

INFINITY-2275: hdfs - replace import-time cluster actions

You're right, but I'm avoiding touching any more than I have to in these refactors. I don't want to introduce any new bugs, and I don't own the tests themselves so hesitate to do any deeper refactoring. Maybe if all these get done I can go back and streamline? (If that's a high priority.)

If we introduce a local variable called: FOLDERED_SERVICE_NAME, then the diff will be significantly smaller. A follow-up PR can then be used to rename this (e.g. change the case).
That is to say, the simplest change to achieve what this PR does is to move the global variables to function-local variables (with no renaming), and then proceed from there. (this holds for the other related PRs #1540 #1542 #1543 #1544 as well.

A smaller diff perhaps, but I'd argue not a simpler change. It's hard to get simpler than search/replace and updating some indention. It also matches the pattern used in cassandra (#1466).
Are you saying the issue is worth blocking these tickets?

Ok. I'll do that work next.


Switching explorer configuration from testnet to mainnet does not work

I posted this announcement to the test explorer on 037cf5d083b58ad971d7943ecfa8bee797ee68ee and it failed to switch the oracle configuration over

and this is what I see on the testnet explorer logs which makes sense since i've posted it there once already

I put another commit on proxy-server-002 that should address this behavior.

fixed in #10


Update gems

This PR updates Ohana API's dependencies using bummr. One update that bummr ended up dropping was the update from protected_attributes 1.1.3 (July 2015) to 1.1.4 (May 2017). I didn't dig into that failure, so I'm not sure what that's all about.
There are a couple of major version upgrades here, specifically ancestry 2.2.2 to 3.0.0 and haml-rails 0.9.0 to 1.0.0. Looking at the changelog for ancestry, it looks like the major version bump was motivated by dropping support for older versions of Rails. I don't see any breaking changes mentioned that are relevant to Ohana. For haml-rails, it looks like they just decided it was time to call it "1.0"; I don't think any breaking changes were involved.
Included in these updates (specifically in bef6d7ca) is an update for nokogiri, which resolves an open alert on Gemnasium. The alert is related to libxslt, however, so I don't think it has any actual relevance for Ohana API (see https://github.com/sparklemotion/nokogiri/issues/1634).

Coverage remained the same at 99.368% when pulling 2a72d410d4ccc7fff5b73e768a5bf460f5cff609 on appropriate:update-gems into 802ad1e11adb85aecbabaa9c2b16b4a366791963 on codeforamerica:master.

Thanks!


How does selector memoization work?

The RFC proposes that both the context and the selector are memoized.
However, it seems like this library works differently. E.g.:
  const count1 = useContextSelector(context, v => v[0].count1);

From my understanding of the RFC, this should defeat the memorization and make useContextSelector ineffective as a performance optimization.
Obviously, the above snippet works for this library, so could you please explain how? Is the selector memoized, and if so, how?
To cite a more complex example, let's look at this snippet:
function Foo({ id }) {
  const value: number = useContextSelector(Context, c => c.values[id])
  return <>{id} = {value}</>
}

How will this behave if both Context and id may change? (If props are too constant, then id may also be state.)

As far as I understand, the RFC says if the selector is memoized like
  const count1 = useContextSelector(context, useCallback(v => v[0].count1, []));

It skips re-evaluation. But, if not
  const count1 = useContextSelector(context, v => v[0].count1);

It will re-evaluate.
So, it's just about optimization of re-evaluation of the selector function.
This library doesn't include such optimization, assuming the selector function is fairly lightweight.

How will this behave if both Context and id may change?

It will use the latest values, so it behaves correctly.
Is it clear? I'm afraid I don't get the point of your question.

Thank you for your explanation.
In that case, I think there is a bug in the useContextSelector implementation of this library. This dependency array should also include selector.
Right now, the selector captured by the reducer function can become stale. This happens with the following steps:

Let the context be the number 1, and the selector be () => 1.
Change the selector to be c => c (yield the whole context).
This will cause the selector in useReducer to be become stale because the deps array is still [value, selected] = [1, 1]
Change the context to 2.
The stale selector will still return 1.

I think those steps will produce incorrect results.

Sorry for code readability, but that's not a dependency array. It's an initial value for useReducer. selector will never be stale.

I see. Thank you for the clarification.


Use a component to identify cesium camera

This PR gives the possibility to distinguish the camera used by cesium with a specific component.
It allows to have one camera to let cesium compute the frustum and the tiles to load. It will not render anything.
The rendering will be done by another camera. It is useful for a platform like the hololens to separate the actual rendering that is always done by the main camera from the tiles retrieval.
All of this is optional and if no camera use the CesiumCamera component Cesium will use the main camera

Thanks for the PR @raggnic! Can I please bug you to sign our Contributor License Agreement so that we can review this?
https://github.com/CesiumGS/cesium/blob/main/CONTRIBUTING.md#contributor-license-agreement-cla

I'm waiting for approval  of my managers before signing it

@kring , @raggnic  Are there still plans to merge this in at some point? Currently, I'm building my own version of Cesium with these changes made, and would love to move to the official releases!

@Reag we can't take these changes without a signed CLA, and we recommend that you don't use them, either. @raggnic if the CLA has been signed at this point and I missed it, please let me know.

Sorry for the delay. I've signed the CLA

Thanks @raggnic! We'll review this soon.

Thanks for the PR @raggnic, and sorry for the delay in reviewing it! This looks really good for supporting an alternate camera. I think it would be straightforward - and worthwhile! - to extend it to support multiple cameras as well. I think it would just be a matter of making the static field on CesiumCamera a list. And then add the camera attached to the current object to the list in OnEnable, and remove it in OnDisable. What do you think?
In any case, I'm going to move this PR out of tomorrow's release. I definitely want to get it into the August release, though!

No problem about the delay,  I'm not in position to complain :-)
I'm little concerned about having several active cesium cameras, but I'm going to try where it goes

I've extended the static field to support multiple cameras, but in cameramanager I only consider the first camera of the list
I think it will require much more work  to have multiple active cameras in cesium, with each defining different frustrums

Hi @raggnic, can you elaborate on where you're running into trouble? Multiple cameras with multiple frustums are already supported on the cesium-native side. I think it should just be a matter of calling this line multiple times, once for each camera:
 result.emplace_back(
        unityCameraToViewState(pCoordinateSystem, unityWorldToTileset, camera));

Still needs a bit more work, so I'm moving this out of today's release.

Hi Kevin. FYI I've taken your suggestion into account

Thanks for all your work on this @raggnic!
As I was reviewing this, I realized the collection of cameras should probably be a component rather than a global list, so that we can use different cameras in different scenes. So now there's a CesiumCameraManager that usually lives on the same game object as the CesiumGeoreference.
And then the question became, how do we know which CesiumCameraManager a given CesiumCamera should associate itself with? We can't necessarily require cameras to be nested inside the CesiumGeoreference (this would be inconvenient in some uses-cases). And what if we want to use a single camera with multiple camera managers?
I resolved this by getting rid of the CesiumCamera "marker" component to designate cameras for use with Cesium. Instead, there's an explicit list of cameras on the camera manager:

The checkboxes allow you to disable the automatic use of the MainCamera and the Editor scene view camera.
As a bonus, I also fixed an unrelated bug where a Cesium3DTileset that is not nested inside a CesiumGeoreference would throw a NullReferenceException when attempting to load.
@raggnic can you take a look and see if you're equally happy with this solution?
And now that I've made substantial changes to this PR myself, can I bug @azrogers to give it a review and merge?
BTW, the code in this branch is also in the autonomous-cesium-camera branch in the main repo.

For our need in mixed reality the key point is to be able to separate the mainCamera from the one used to select tiles, so I approve this solution.
I think that's a much better implementation of this feature, mine was more a quick workaround.

Will we be able to edit this component in real time? That is, must it be constant at the unity bootstrap, or can we add or remove cameras depending on user logic? Right now, we are using a variant of Raggnic's code to handle this, as our main server cant actually load cesium. For that server, we have a special asmdef that disables Cesium in its entirety. The clients however have Cesium active, and they inject the appropriate camera after loading a particular scene, to avoid having null references in our servers logs.

I suggest you try it out with a build from this branch if you have any doubts @Reag. But I think it shouldn't be a problem. The way it works is that the Cesium3DTileset finds the CesiumCameraManager when it's first enabled, but then it asks the camera manager for the set of cameras every frame. So you can programmatically add and remove cameras at will, and the change should take effect on the next frame.

Thanks for taking a look @raggnic!

I've addressed all your comments, so this should be ready for another look. Your nitpicks are always valuable suggestions by the way, not nitpicks at all!

Thanks @kring ! Merging now :smile:


h2c opensource or not ?

restful http/https, h2/h2c (compatible with grpc, will be open sourced).

RT

related code is under development and is expected to be completed by the end of May or June


Design Discharge

This PR adds a new module for Design Discharge that leverages the "DOT" precip frequency data available in the SNAP Data API.
The Design Discharge is computed via what is known as "The Rational Method, Q = CIA where:

Q = Peak rate of runoff in cubic feet per second
C = Runoff coefficient, an empirical coefficient representing a relationship between rainfall and runoff.
I = Average intensity of rainfall in inches per hour for the time of concentration (Tc) for a selected frequency of occurrence or return period (this values comes from the API).
A = The watershed area in acres

To test this PR please review the functions and perhaps try a few different lat-lons in the initial API request. You should be able to generate the dataframe of results, and observe it respond to change in the inputs.
This requires an API endpoint that is not in the production API yet, so I suggest running this locally adjacent to the current main branch of the API that is running locally as well. Really any Python env should work to run this module, you just need pandas, Jupyter Notebook, and ipywidgets.

Thanks Josh! I'll ticket the unit idea 👍 📏


change botocore back to <1.29.81

Issue #, if available:
Fixes #327
Description of changes:
Dependabot changed botocore to <*.82 instead of keeping it <*.81 as suggested by the changelog
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I dont think its going to fix https://github.com/aws/aws-elastic-beanstalk-cli/issues/327
the error its that requirements.txt is missing
if you download archive from https://pypi.org/project/awsebcli/#files
the file is missing

I dont think its going to fix #327
the error its that requirements.txt is missing
if you download archive from https://pypi.org/project/awsebcli/#files the file is missing

Thank you for verifying that. I downloaded it from GH and it was there so I assumed it wasn't the issue. Closing the PR.


ChatOps params from the installer UI are not being escaped

An example: if your Hubot password has & in it, it'll break the init script.

Good catch.
P.S. If those tickets are created from chat, it would also be a good idea to include the name of the person who created / reported the ticket somewhere.

Created a PR in Installer, so I'm going to close this issue. st2 is a wrong repo for this anyway. :)


Docs: consider adding ngx-bootstrap as a JavaScript framework

In the 'Usage with JavaScript frameworks' section: https://getbootstrap.com/docs/5.3/getting-started/javascript/#usage-with-javascript-frameworks it lists ng-bootstrap as a solution for Angular.
I think it might be worth considering adding ngx-bootstrap too. It has 5500 Stars and works great with Bootstrap 5. I'm not affiliated with the project but I have been using it.

Personally, I don't mind adding it. I used it in a project for Orange back in the day with Bootstrap 4, and it worked great. Feel free to create a PR for it, @coliff, or I can take care of it if you're short on time. Let's see what the rest of the core team thinks once the PR is up.


force:source:push and force:source:deploy --tracksource error out with "The "path" argument must be of type string. Received undefined" when files inside StaticResource application/zip folder are forceignored

Summary
StaticResource application/zip folders with forceignored files result in this same unhelpful cryptic error:
% sfdx force:source:push -f
*** Pushing v52.0 metadata with SOAP API v54.0 connection ***
DEPLOY PROGRESS | ████████████████████████████████████████ | 1/1 Components
ERROR running force:source:push:  The "path" argument must be of type string. Received undefined
Updating source tracking... done

% sfdx force:source:deploy -p src/path/to/staticresources/someStaticResource -t -f
*** Deploying v52.0 metadata with SOAP API v54.0 connection ***
Deploy ID: 0AfJ000002AFWHQKA5
DEPLOY PROGRESS | ████████████████████████████████████████ | 1/1 Components
ERROR running force:source:deploy:  The "path" argument must be of type string. Received undefined
Updating source tracking... done

Steps To Reproduce:
Repository/branch to reproduce: my dreamhouse-lwc

Create a decomposed StaticResource application/zip folder and resource-meta.xml as shown in the linked branch above with one file inside the folder with a file type that is safe to forceignore.
Add the file or even more generally the file type to forceignore.
Run sfdx force:source:push or sfdx force:source:deploy -p path/to/staticresource -t
Get the error ERROR running force:source:push(or deploy):  The "path" argument must be of type string. Received undefined

Expected result
Similar to when the folder is empty, I would expect an error that points out that a specific StaticResource zip folder is empty.  Ideally, it would be nice if the solution to this problem more specifically points out that the StaticResource zip folder would be empty because the file inside is being forceignored.
Actual result
This very unhelpful error that required me to step through each top level folder to determine which file was the culprit.  Ideally, nobody else should suffer through this again.  Running --loglevel debug on the commands did not produce any more useful log errors.  Even though it says updating source tracking.  Source tracking does not actually update since all the files still try to push on the next run.
ERROR running force:source:push(or deploy):  The "path" argument must be of type string. Received undefined
System Information
{
"cliVersion": "sfdx-cli/7.150.0",
"architecture": "darwin-x64",
"nodeVersion": "node-v14.19.2",
"pluginVersions": [
"@oclif/plugin-autocomplete 0.3.0 (core)",
"@oclif/plugin-commands 1.3.0 (core)",
"@oclif/plugin-help 3.3.1 (core)",
"@oclif/plugin-not-found 1.2.6 (core)",
"@oclif/plugin-plugins 1.10.11 (core)",
"@oclif/plugin-update 1.5.0 (core)",
"@oclif/plugin-warn-if-update-available 1.7.3 (core)",
"@oclif/plugin-which 1.0.4 (core)",
"@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
"alias 2.0.0 (core)",
"apex 0.11.0 (core)",
"auth 2.0.2 (core)",
"community 1.1.4 (core)",
"config 1.4.6 (core)",
"custom-metadata 1.1.0 (core)",
"data 0.6.15 (core)",
"generator 2.0.0 (core)",
"info 2.0.0 (core)",
"limits 2.0.0 (core)",
"org 1.12.1 (core)",
"salesforce-alm 54.3.0 (core)",
"schema 2.1.0 (core)",
"sfdx-cli 7.150.0 (core)",
"signups 1.0.0 (core)",
"source 1.9.7 (core)",
"telemetry 1.4.0 (core)",
"templates 54.6.0 (core)",
"trust 1.1.0 (core)",
"user 1.7.1 (core)"
],
"osVersion": "Darwin 20.6.0"
}
Additional information
This issue seems specific to the new source tracking.  Legacy push did not encounter the issue and deploy only encounters the issue with the --tracksource option.

yeah, that is annoying.  Thanks for the repro/explanation.


LE Audio: HAS invalid bsim tests

Is your enhancement proposal related to a problem? Please describe.
The current babblesim tests for HAS mainly focuses on the case where everything goes right, and do not test much invalid behavior or error handling.
Describe the solution you'd like
All APIs should be tested with invalid values to verify that they will return an error.
To the extent possible, the APIs should also be used in cases where the the remote device should perform some error handling.
Finally the APIs should be tested with disconnects.
Describe alternatives you've considered
To test against a non-conforming device, some verification and checks in the stack needs to be disabled. TBD if this is a good idea to test somehow.
Additional context
N/A

This is still valid


AWS Lambda fails to run when deepgram-sdk is imported

What is the current behavior?
An error is encountered when running deepgram-sdk inside of a Python Lambda function. When I remove the deepgram-sdk import from the lambda, the lambda works.

What's happening that seems wrong?

START RequestId: c1d0ca1d-4f05-4a3b-89b3-77eeb359288c Version: $LATEST
{"timestamp": "2024-01-20T13:47:13Z", "log_level": "ERROR", "errorMessage": "Syntax error in module 'app': invalid syntax (base_events.py, line 296)", "errorType": "Runtime.UserCodeSyntaxError", "requestId": "2e0ec8e3-31a0-44a5-b6eb-5f86ba78496f", "stackTrace": ["  File \"/var/task/asyncio/base_events.py\" Line 296\n            future = tasks.async(future, loop=self)\n"]}
END RequestId: 2e0ec8e3-31a0-44a5-b6eb-5f86ba78496f
REPORT RequestId: 2e0ec8e3-31a0-44a5-b6eb-5f86ba78496f	Init Duration: 0.90 ms	Duration: 4625.05 ms	Billed Duration: 4626 ms	Memory Size: 128 MB	Max Memory Used: 128 MB
{"errorMessage": "Syntax error in module 'app': invalid syntax (base_events.py, line 296)", "errorType": "Runtime.UserCodeSyntaxError", "requestId": "2e0ec8e3-31a0-44a5-b6eb-5f86ba78496f", "stackTrace": ["  File \"/var/task/asyncio/base_events.py\" Line 296\n            future = tasks.async(future, loop=self)\n"]}

Steps to reproduce
I have created a hello_world lambda repository and the behaviour can be reproduced locally. You will notice deepgram-sdk in requirements.txt and that we are importing deepgram in app.py

git clone git@github.com:KentonParton/deepgram_sam_app.git
Start Docker
sam build && sam local invoke HelloWorldFunction --event events/event.json

To make it faster to diagnose the root problem. Tell us how can we reproduce the bug.
Start by cloning git@github.com:KentonParton/deepgram_sam_app.git, if you don't have AWS SAM cli, you will need to install it:
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html

Start docker
Once SAM CLI is installed and docker is running, run:
sam build && sam local invoke HelloWorldFunction --event events/event.json
You should see the error mentioned above
Expected behavior
I expect the lambda to run return the hello world message.

What would you expect to happen when following the steps above?

Please tell us about your environment

We want to make sure the problem isn't specific to your operating system or programming language.

Operating System/Version: MacOS M1
Language: Python 3.10
Browser: Chrome

Other information

Anything else we should know? (e.g. detailed explanation, stack-traces, related issues, suggestions how to fix, links for us to have context, eg. stack overflow, codepen, etc)
https://stackoverflow.com/questions/76625455/store-value-of-a-callback-in-python-using-asyncio

Hi @KentonParton
The SDK definitely works in Lambda. Another user has implemented using it here:
https://discord.com/channels/1108042150941294664/1192050843705425930
Something to note:

has a default 5 second timeout in which can be increased

I would suggest trying to debug your issue a little more. My guess is it has something to do with that SAM CLI environment.
We use asyncio library (/var/task/asyncio/base_events.py), but don't own the code for it. Try importing just that and see if you get the same result.

@dvonthenen I have tried running the above code on Lambda but encountered the same error as running on SAM locally. Looking here: https://github.com/deepgram/deepgram-python-sdk/blob/9cb034e2c6ef44d95b2f824d1f31ae9bba3c6b1a/requirements.txt#L12
I see that asyncio is being installed even though it is part of the standard library. From what I have read, installing asyncio causes the error I am experiencing. Here are some links:
https://forum.serverless.com/t/cant-import-asyncio/15014
https://stackoverflow.com/questions/59546682/aws-lambda-not-importing-asyncio
https://www.reddit.com/r/aws/comments/ej1nqm/cant_import_modules_into_lambda/
Is it necessary to include asyncio when the minimum version of python supported is 3.10 when asyncio is included in the standard library?

It's definitely that SAM environment not liking asyncio as I suspected. I can look into what dependencies are needed from asyncio and look into it.

PR merged. Will be available in the next release.


syncedCrud: LegendState will attempt to sync when waitFor is back to falsey

@jmeistrich - apologies for the issue spam I am creating - but I am battle-testing the syncedCrud plugin and came across another unexpected behavior. Consider this scenario:

waitFor resolves to false initially -> sync doesn't happen, no attempt to connect to my CRUD endpoints occurs and everything works offline (as expected).
waitFor now resolves to true -> sync starts to happen (as expected).
waitFor resolves back to false -> sync still tries to happen and CRUD endpoints are hit (not expected)

Is point 3 the expected behavior? 🤔
https://github.com/user-attachments/assets/54ffdcf4-27b3-40dc-9371-1dfa27733dfe

No it's great! Keep the issues coming! You're finding scenarios I hadn't thought of. I've just been really busy (gave a talk last night and doing a workshop next week) so I haven't had a chance to dive into them yet.
#3 is by design because I hadn't considered a scenario where it would revert back to false. I use that mainly for waiting for authentication or for dependent tables to load first. Can you tell me more about a scenario where waitFor would get set back to false and what would you expect to happen?

@jmeistrich - basically the app starts in an offline mode (unauthenticated).

You could add another check within the functions that checks for the pro plan eligibility. That's what I do, since those functions are async anyways.

@zoltlabs - that's what I currently do - if it's not eligible, I throw and return 403 forbidden - but it would be nice not to see a bunch of errors on the browser console with the sync plugin hitting my sync endpoints endlessly 😬


the incremental compiler does not work when adding new methods in the jdk

In scala-native and in Scala.js we need to reimplement the jdk.
I'm currently working on java.util.regex.{Pattern, Matcher}.
I need to add a private constructor to Matcher.
steps
When I change something in Patten
problem
it complains about the non-existing private constructor. (Pattern depends on Matcher).
expectation
a clean compile works. I can touch the Matcher then touch the Pattern compile and it works

\cc @sjrd @Duhemm @densh

I'm not surprised, and I don't think this can be fixed. In Scala.js we simply disable the incremental compiler wholesale for the javalib and scalalib.

This is how they do it: https://github.com/scala-js/scala-js/blob/v0.6.15/project/ExternalCompile.scala#L19-L104

Yes, I think this is expected.

@MasseGuillaume @sjrd I've been able to get incremental compilation to work in javalib in Scala Native so far using https://github.com/Duhemm/scala-native/commit/6fa9fbace4911a47a2ee8b211383336b20578357.

@Duhemm Smart.


RuboCop --auto-correct replaces $$ with a possible nil

RuboCop's auto-correct replaces $$ with $PROCESS_ID, which may be undefined (nil).

Expected behavior
RuboCop fixed the violation, but reminded the user to require the english library (require 'english'). Or it would not fix the violation at all.
Actual behavior
Fixes the violation, but might leave the program in a non-working state, if the user didn't require the english library.
Steps to reproduce the problem

Create a script and reference $$, without requiring the english library
Run RuboCop against that script, using the --auto-correct flag
Your program no longer works because $PROCESS_ID is nil. $PROCESS_ID is a global variable, therefore you won't even have any kind of warnings.

RuboCop version
$ rubocop -V
0.50.0 (using Parser <IP_ADDRESS>, running on ruby 2.2.3 x86_64-darwin14)

Just noticed that this has already been done.