[Bug] Chainsaw tries to create namespace which is already present

chainsaw version Version
v0.2.8
Description
When we start tests with the parameter --namespace chainsaw-tests, we get the error that the namespace already exist. This is correct, the namespace does already exist, but it should just run inside this namespace.
We have this behaviour when the tests are started in the official container, not when launched from a client where chainsaw is installed through brew.
Also; the pod doesn't exit with a error code; so Kubernetes says the pod is completed instead of failed (normally, when a test fails, the pod fails).
Steps to reproduce

Put the test files in the container (for example with a Dockerfile)

FROM ghcr.io/kyverno/chainsaw:v0.2.8
`COPY chainsaw-tests/ /chainsaw-tests/`

Create manually a namespace chainsaw-tests
Launch the container/pod with the following commands:

    - args:
        - test
        - '--test-dir=/chainsaw-tests'
        - '--namespace=chainsaw-tests'
      command:
        - chainsaw

When trying with <=v.0.2.7, it does work. Also tried with 0.2.9 and x.10, doesn't solve it.
Expected behavior
Chainsaw tests would run in the provided namespace.
Screenshots
No response
Logs
Version: 0.2.8
Loading default configuration...
- Using test file: chainsaw-test
- TestDirs [/chainsaw-tests]
- SkipDelete false
- FailFast false
- Namespace 'chainsaw-tests'
- FullName false
- IncludeTestRegex ''
- ExcludeTestRegex ''
- ApplyTimeout 5s
- AssertTimeout 30s
- CleanupTimeout 30s
- DeleteTimeout 15s
- ErrorTimeout 30s
- ExecTimeout 5s
- DeletionPropagationPolicy Background
- Template true
- NoCluster false
- PauseOnFailure false
Loading tests...
- e2etest-argo-instance-and-apps (/chainsaw-tests/deploy-argo)
Loading values...
Running tests...
=== RUN   chainsaw
=== PAUSE chainsaw
=== CONT  chainsaw    l.go:52:| 12:10:16 | chainsaw | @chainsaw | CREATE    | ERROR | v1/Namespace @ chainsaw-tests
=== ERROR
 namespaces "chainsaw-tests" already exists
l.go:52:| 12:10:16 | chainsaw | @chainsaw | INTERNAL  | ERROR |
=== ERROR
namespaces "chainsaw-tests" already exists
--- FAIL: chainsaw (0.05s)
FAIL
Tests Summary...
- Passed  tests 0
- Failed  tests 0
- Skipped tests 0
Done.

Slack discussion
No response
Troubleshooting

[X] I have searched other issues in this repository and mine is not recorded.

Thanks for reporting, i will fix it asap!

@sandert-k8s I couldn't reproduce the issue with v0.2.10.
I created the chainsaw-tests namespace in my cluster and ran:
docker run \
	-v ./testdata/e2e/:/chainsaw/ \
	-v ${HOME}/.kube/:/etc/kubeconfig/ \
	-e KUBECONFIG=/etc/kubeconfig/config \
	--network=host \
	--user $(id -u):$(id -g) \
	--name chainsaw \
	--rm \
	ghcr.io/kyverno/chainsaw:v0.2.10 test /chainsaw/examples/quick-start --namespace chainsaw-tests

It seems to work fine:
Version: 0.2.10
Loading default configuration...
- Using test file: chainsaw-test
- TestDirs [/chainsaw/examples/quick-start]
- SkipDelete false
- FailFast false
- Namespace 'chainsaw-tests'
- FullName false
- IncludeTestRegex ''
- ExcludeTestRegex ''
- ApplyTimeout 5s
- AssertTimeout 30s
- CleanupTimeout 30s
- DeleteTimeout 15s
- ErrorTimeout 30s
- ExecTimeout 5s
- DeletionPropagationPolicy Background
- Template true
- NoCluster false
- PauseOnFailure false
Loading tests...
- quick-start (/chainsaw/examples/quick-start)
Loading values...
Running tests...
=== RUN   chainsaw
=== PAUSE chainsaw
=== CONT  chainsaw
=== RUN   chainsaw/quick-start
=== PAUSE chainsaw/quick-start
=== CONT  chainsaw/quick-start
    | 09:22:09 | quick-start | step-1    | TRY       | BEGIN |
    | 09:22:09 | quick-start | step-1    | APPLY     | RUN   | v1/ConfigMap @ chainsaw-tests/chainsaw-quick-start
    | 09:22:09 | quick-start | step-1    | CREATE    | OK    | v1/ConfigMap @ chainsaw-tests/chainsaw-quick-start
    | 09:22:09 | quick-start | step-1    | APPLY     | DONE  | v1/ConfigMap @ chainsaw-tests/chainsaw-quick-start
    | 09:22:09 | quick-start | step-1    | ASSERT    | RUN   | v1/ConfigMap @ chainsaw-tests/chainsaw-quick-start
    | 09:22:09 | quick-start | step-1    | ASSERT    | DONE  | v1/ConfigMap @ chainsaw-tests/chainsaw-quick-start
    | 09:22:09 | quick-start | step-1    | TRY       | END   |
    | 09:22:09 | quick-start | step-1    | CLEANUP   | BEGIN |
    | 09:22:09 | quick-start | step-1    | DELETE    | OK    | v1/ConfigMap @ chainsaw-tests/chainsaw-quick-start
    | 09:22:09 | quick-start | step-1    | CLEANUP   | END   |
--- PASS: chainsaw (0.01s)
    --- PASS: chainsaw/quick-start (0.12s)
PASS
Tests Summary...
- Passed  tests 1
- Failed  tests 0
- Skipped tests 0
Done.

Can you provide more details on how to reproduce it ?

Sorry for my late reply.
I think this issue can be closed, I did some more debugging. It looks like since 0.2.8 it's needed to have get permission on the namespace where the chainsaw test will be executed, and my service account only had list. This was never a issue, until 0.2.8.
I just added the get permission. Thanks!


Please create a release with changes

unknown field 'TokenPrefix' in struct literal of type lock.Options

The latest master is released as https://github.com/bsm/redis-lock/releases/tag/v8.0.1, please use godep or go mod


Open interactive python window error

[Window Title]
devenv.exe
[Main Instruction]
An unexpected error occurred
[Content]
An error occurred opening this interactive window.
Please press Ctrl+C to copy the contents of this dialog and report this error to our issue tracker.
[V] Show details  [Close]
[Expanded Information]
Build: 3.0.17114.1

System.TypeLoadException: Could not load type 'Microsoft.VisualStudio.InteractiveWindow.Shell.IVsInteractiveWindowFactory2' from assembly 'Microsoft.VisualStudio.VsInteractiveWindow, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
   at Microsoft.PythonTools.Repl.InteractiveWindowProvider.CreateInteractiveWindowInternal(IInteractiveEvaluator evaluator, IContentType contentType, Boolean alwaysCreate, Int32 id, String title, Guid languageServiceGuid, String replId)
   at Microsoft.PythonTools.Repl.InteractiveWindowProvider.Create(String replId, Int32 curId)
   at Microsoft.PythonTools.Repl.InteractiveWindowProvider.OpenOrCreate(String replId)
   at Microsoft.PythonTools.InterpreterList.InterpreterListToolWindow.OpenInteractiveWindow_Executed(Object sender, ExecutedRoutedEventArgs e)

I have the same issue on my home PC with only VS2017 installed. This is with Python 3.6 (64 bit) environment. Also, pip installation (e.g. bitarray) fails with a complaint about requiring VC++ 14.0 in case that's related/relevant. At work things work just fine (there I have VS2013, VS2015 and VS2017 installed). Both running the latest Win10 (not the preview stuff).

We've been seeing this a few times, and right now we suspect (but have not yet confirmed) that it's an upgrade issue from a previous version.
Can you try uninstalling and reinstalling VS? If you've only installed the Python workload, you should only need to remove/replace that workload, which may save you some time (and shouldn't lose your settings).
If that works, could you then use the tool at https://aka.ms/vscollect to collect your setup logs into %TEMP%\vslogs.zip and email them to<EMAIL_ADDRESS>Those should provide enough information to help us track down exactly why this is happening.

Have either of you had VS 2017 Preview installed at all? There may be a potential versioning issue between VS and the preview of the updates that might be at fault.

I did have the preview installed.
From: Steve<EMAIL_ADDRESS>Sent: torstai 15. kesäkuuta 2017 19.05
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [Microsoft/PTVS] Open interactive python window error (#2641)
Have either of you had VS 2017 Preview installed at all? There may be a potential versioning issue between VS and the preview of the updates that might be at fault.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/PTVS/issues/2641#issuecomment-308786140, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQmh2YWlqVeKiy217_nMcE4YyVtYylNuks5sEVYngaJpZM4NvdGw.

@zooba I'm sorry but it seems that reinstalling will not work for me. In fact I've installed python workload when using preview, but later on removed it when 2017 came to public officially. Recently I add it in again, and this error occurs; I mean, it should be a 'fresh' install now on my PC. Could you please help?

We'll just keep one of these open: https://github.com/Microsoft/PTVS/issues/2534


how to run

Can you please tell me what steps you are following after cloning repo

https://www.youtube.com/watch?v=ZoWems8EqL4


fix(connector): [Bluesnap] disable 3ds flow

Type of Change

[X] Bugfix
[ ] New feature
[ ] Enhancement
[ ] Refactoring
[ ] Dependency updates
[ ] Documentation
[ ] CI/CD

Description

Disabling 3DS flow for Bluesnap as the current implementation needs to be refactored and might cause bugs on production.
Additional Changes

[ ] This PR modifies the API contract
[ ] This PR modifies the database schema
[ ] This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

Checklist

[X] I formatted the code cargo +nightly fmt --all
[X] I addressed lints thrown by cargo clippy
[X] I reviewed the submitted code
[X] I added unit tests for my changes where possible
[ ] I added a CHANGELOG entry if applicable

This PR is no longer required

This PR is no longer required


travis config file

Devtools could help in distributing and maintaining travis config files. WDYT? /cc @dkubb @mbj @snusnu

I removed travis from all my gems as its to slow compared to Circle. Also I reduced the matrix significantly to one or 2 ruby implementations. Reducing the scope to what I use by mself is in-line with my meanwhile changed OSS policy that states: I only make myself and the projects I work on happy.


Framework Laptop support

It'd be greatly appreciated if framework users such as myself could have an option for a secureblue_framework image with the framework-specific presets, and TLP, in the ublue framework image.

available now :partying_face:


Improve mapping of operative SMV data to pay elements

Update schema to latest version with string timesheet id
Fix issue where percentage wasn't calculated correctly
Don't award SMVs for work orders that were closed with 'No Access'
Don't insert pay element for work orders that were cancelled

Given the dependence on the models, I'm wondering whether this should be in the API repo


Quality gate

create ci/cd pipeline

@rultor hello

@rultor hello

@l3r8yj Hi there! I understand a few simple commands: "merge", "deploy", etc. This page explains them briefly. Any questions or bug reports are welcome. Have fun :)


No instructions on how to add icons

I'm submitting a ...  (check one with "x")
[x] missing documentation

Current behavior

When not including <link href="https://file.myfontastic.com/Jnf54BZCm7mSjGCxNRbfp3/icons.css" rel="stylesheet"> the icons for sorting are missing.
But this is no where mentioned AFAIK.
Expected behavior

It should probably be noted here: https://swimlane.gitbooks.io/angular2-data-table/content/introduction/installing.html
Maby even bundle the icons with the table.
What is the motivation / use case for changing the behavior?

I spend time figuring out why my icons were missing,

Good call. I think in most cases people use their own set from material/fontawesome/bootstrap/etc. I'll add some docs tho

For people who want to use font-awesome with datatable
here is the setup I used.

You can manually pass the icon names now so this shouldn't be needed.

Ah ha ! I see. Thx

#amcdnl  where is the table html generate in module , basically i didnot found previous and next button in ngx datatable

@amcdnl Can you give me a hint how to pass the icons manually... Thanks


KAFKA-14735: Improve KRaft metadata image change performance at high …

…topic counts
Performance of KRaft metadata image changes is currently O(<# of topics in cluster>). This means the amount of time it takes to create just a single topic scales linearly with the number of topics in the entire cluster. This impact both controllers and brokers because both use the metadata image to represent the KRaft metadata log. The performance of these changes should scale with the number of topics being changed – creating a single topic should perform similarly regardless of the number of topics in the cluster.
This patch leverages persistent data structures to avoid copying the entire TopicsImage upon every change.  It initially introduced a dependency on the Paguro library for immutable/persistent collection support in Java.  This library could have been a good fit because it is relatively small and well-integrated with the existing Java Collections class hierarchy (the latter property especially helps to minimize the changes required to introduce the library into the existing code base).  Unfortunately the Paguro library does not support Java 8, so we moved to Vavr, which does support Java 8.  Vavr is also greatly inspired by Scala, so it is a good cultural fit with this project.  The patch minimized the changes needed by introducing a couple of wrapper classes, Vavr{Set,Map}AsJava.  Note that Vavr has an open issue to add better integration with the standard Java interfaces, so at some point we would likely be able to use that instead.  Finally, a third iteration of this patch leverages PCollections because it was clearly the best fit for https://github.com/apache/kafka/pull/13437 due to the O(N) performance of Paguro and Vavr when invoking tailSet() on a sorted set, whereas it is O(log N) in PCollections.  This function is not needed here, so this issue in those two libraries would have gone unnoticed without that other PR.
This patch also adds the following JMH benchmarks demonstrating the resulting performance changes.  Note that the Vavr implementation is shown to perform comparably to the Paguro one.  The PCollections implementation benchmarks at about half the speed as those two libraries, and the reason for the slower performance is described here.

TopicsImageSingleRecordChangeBenchmark tracks how long it takes to create a new topic.  This is the benchmark that clearly identifies the O(N) behavior in the existing code and that most dramatically illustrates a performance improvement.

As shown below, the existing code takes several orders of magnitude longer to make a single change than the new code.  The existing code, with 12,500 topics, took 1.4 milliseconds on my laptop and grows more or less linearly as the number of topics grows.  The new code took a constant amount of time (~250 nanoseconds for Paguro and Vavr, ~500 nanoseconds for PCollections) regardless of the number of topics in the cluster.
The reason for the improvement is because it is inexpensive to add, update, or delete an entry in an immutable, persistent map to create a new persistent map.  The new map shares the vast amount of the old map; only the root node and any nodes along the path to the node that must change are swapped out, and when the reference to the old map is released the swapped-out nodes can be garbage-collected. (There are typically 5 times as many nodes to swap out in a PCollections data structure, which is why it performs slower.)
Current Code, TopicsImageSingleRecordChangeBenchmark

Total Topic Count
nanoseconds/op
error

12,500
1,410,901
153,461

25,000
3,570,451
221,992

50,000
14,143,125
1,123,616

100,000
31,126,930
4,243,625

Updated Code, TopicsImageSingleRecordChangeBenchmark

Total Topic Count
nanoseconds/op (Paguro)
error
nanoseconds/op (Vavr)
error
nanoseconds/op (PColl)
error

12,500
258
13
274
9
473
3

25,000
265
8
291
4
489
8

50,000
273
5
293
5
486
3

100,000
222
4
254
3
509
11

TopicsImageZonalOutageBenchmark simulates a zonal outage where each broker in the zone will lose its session – in this benchmark we assume the controller deals with them one by one rather than demoting 1/3 of the cluster all at once.  Since the number of topics per broker does not change very much, we expect O(N) behavior with the current code but not with the updated code, so we should see a performance improvement here as well -- and in fact we do.

The existing code scales with the number of topics in the cluster, thus the time always doubles as the cluster size doubles, increasing from 5ms to 47ms (a factor of 9) as the cluster scales by a factor of 8.  The updated code should scale with the number of affected topics, which in this case, based on the (debatable) values chosen of 10000 replicas per broker and 10 partitions per topic, means a factor of 1.6 (from 4167 topics affected to 6667 topics affected) as the cluster scaled by a factor of 8.  In fact we see the time spent increasing by a factor of 2.6 (from 4.4 ms to 11.6 ms) when the cluster scaled by that factor of 8.  This a bit higher than expected, but it is still sub-linear (and there is some +/- error in these numbers, so the sub-linear behavior is the real point as opposed to the specific number).
Current Code, TopicsImageZonalOutageBenchmark

Total Topic Count
ms/op
error
(Brokers Impacted)
(Topics Impacted)

12,500
5.2
0.4
1/36
4,167

25,000
10.6
0.1
1/75
5,000

50,000
21.7
0.4
1/150
6,667

100,000
47.7
5.2
1/300
6,667

Updated Code, TopicsImageZonalOutageBenchmark

Total Topic Count
ms/op (Paguro)
error
ms/op (Vavr)
error
ms/op (PColl)
error
(Brokers Impacted)
(Topics Impacted)

12,500
4.4
0.2
3.8
0.3
7.7
1.8
1/36
4,167

25,000
6.9
0.2
6.0
0.3
11.2
0.3
1/75
5,000

50,000
10.2
2.5
11.6
1.1
17.5
0.2
1/150
6,667

100,000
11.6
2.8
10.6
0.8
19.6
0.1
1/300
6,667

TopicsImageSnapshotLoadBenchmark simulates the loading of a snapshot when the broker starts – i.e. load up 100,000 topics/1M partitions from scratch and commit them all at once.  We would expect to see some performance degradation here in the updated code, and the question really was by how much.

This is the benchmark that simulates the case where every topic is affected – e.g when we load the initial snapshot during startup.  We expect the persistent data structures to perform worse here because every perturbation to create a new tree implies replacing some path in the old tree and sharing the remainder.  That’s a lot of replacing and a lot of garbage collecting.  It turns out to be a 20%-40% penalty (and a 100% penalty for PCollections).   This happens far less frequently than the scenarios described above – people create topics and ISRs change more frequently than the brokers roll – so the performance degradation here seems like a reasonable penalty to accept.
Current Code, TopicsImageSnapshotLoadBenchmark

Total Topic Count
ms/op
error

12,500
9.2
0.2

25,000
20.7
1.9

50,000
41.6
2.9

100,000
110.8
12.4

Updated Code, TopicsImageSnapshotLoadBenchmark

Total Topic Count
ms/op (Paguro)
error
ms/op (Vavr)
error
ms/op (PColl)
error

12,500
13.7
1.3
10.9
0.4
20.2
2.7

25,000
28.9
1.4
27.2
1.6
44.4
3.5

50,000
67.6
1.6
54.6
0.6
91.6
8.1

100,000
126.0
12.9
131.8
2.7
219.7
14.1

KRaftMetadataRequestBenchmark is a version of an existing set of benchmarks that we have for ZooKeeper-based brokers.  It demonstrates a potential slowdown in read performance with the new code of between 5% and 10% when requesting metadata for all topics -- but the evidence is not particularly strong as some cases actually perform better.  Overall there doesn't seem to be anything here that strongly cautions against this change.

KRaftMetadataRequestBenchmark.testMetadataRequestForAllTopics
Current Code, unpatched
(partitionCount)  (topicCount)  Mode  Cnt     Score      Error  Units
              10           500  avgt   15   1,372,555 ±  15168  ns/op
              10          1000  avgt   15   2,726,199 ±   31911 ns/op
              10          5000  avgt   15  41,553,723 ± 1394093 ns/op
              20           500  avgt   15   2,373,810 ±   28321 ns/op
              20          1000  avgt   15   5,077,006 ±  344757 ns/op
              20          5000  avgt   15  50,903,119 ±  842825 ns/op
              50           500  avgt   15   5,592,480 ±   38801 ns/op
              50          1000  avgt   15  11,278,004 ±  140578 ns/op
              50          5000  avgt   15  97,650,988 ± 2605903 ns/op

KRaftMetadataRequestBenchmark.testMetadataRequestForAllTopics
Updated Code
(partitionCount)  (topicCount)  Mode  Cnt  Score (Paguro) Error  Units  Score (Vavr)  Error  Units  Score (PColl)  Error  Units
              10           500  avgt   15   1,437,036 ±   10188  ns/op   1,442,117 ±  8,559  ns/op  1,436,177 ±  11021  ns/op
              10          1000  avgt   15   2,957,573 ±   39260  ns/op   2,954,884 ±  12060  ns/op  2,987,309 ± 159598  ns/op
              10          5000  avgt   15  40,949,310 ±  354110  ns/op  41,635,894 ± 213369  ns/op  42,404,435 ± 483119 ns/op
              20           500  avgt   15   2,493,095 ±   18131  ns/op   2,408,136 ±   6702  ns/op  2,501,674 ±  11742  ns/op
              20          1000  avgt   15   5,224,700 ±  198612  ns/op   5,179,505 ± 147137  ns/op  5,031,919 ±  37816  ns/op
              20          5000  avgt   15  55,643,648 ±  935801  ns/op  54,693,354 ± 663260  ns/op  52,388,351 ± 446151 ns/op
              50           500  avgt   15   5,731,311 ±  289600  ns/op   5,659,881 ±  37952  ns/op  5,704,824 ±  33033  ns/op
              50          1000  avgt   15  11,708,292 ±   63063  ns/op  12,157,078 ± 568409  ns/op  11,983,888 ± 260229 ns/op
              50          5000  avgt   15  94,717,769 ± 1248511  ns/op  92,230,586 ± 881284  ns/op  103,499,261 ± 544445 ns/op

There are 2 other benchmarks in the set that seem to perform comparably with and without the patch.
KRaftMetadataRequestBenchmark.testRequestToJson
Current Code, unpatched
(partitionCount)  (topicCount)  Mode  Cnt         Score         Error  Units
              10           500  avgt   15       674.874 ±      19.315  ns/op
              10          1000  avgt   15       643.048 ±       4.638  ns/op
              10          5000  avgt   15       696.829 ±      23.999  ns/op
              20           500  avgt   15       672.617 ±       4.812  ns/op
              20          1000  avgt   15       674.492 ±       6.206  ns/op
              20          5000  avgt   15       677.546 ±       2.301  ns/op
              50           500  avgt   15       682.702 ±       3.841  ns/op
              50          1000  avgt   15       634.786 ±       6.009  ns/op
              50          5000  avgt   15       678.107 ±       8.479  ns/op

KRaftMetadataRequestBenchmark.testRequestToJson
Updated Code
(partitionCount)  (topicCount)  Mode  Cnt  Score (Paguro) Error  Units  Score (Vavr)  Error  Units  Score (PColl)  Error  Units
              10           500  avgt   15       679 ±       3    ns/op    680 ±         5    ns/op       635 ±       5    ns/op
              10          1000  avgt   15       659 ±       3    ns/op    671 ±         3    ns/op       676 ±      10    ns/op
              10          5000  avgt   15       679 ±       6    ns/op    672 ±         2    ns/op       624 ±       3    ns/op
              20           500  avgt   15       666 ±       2    ns/op    671 ±         3    ns/op       671 ±       4    ns/op
              20          1000  avgt   15       671 ±       3    ns/op    633 ±         2    ns/op       674 ±       1    ns/op
              20          5000  avgt   15       671 ±       2    ns/op    670 ±         4    ns/op       632 ±       2    ns/op
              50           500  avgt   15       672 ±       7    ns/op    674 ±         4    ns/op       668 ±       7    ns/op
              50          1000  avgt   15       665 ±       2    ns/op    697 ±        11    ns/op       685 ±       4    ns/op
              50          5000  avgt   15       669 ±      27    ns/op    646 ±        12    ns/op       680 ±      13    ns/op

KRaftMetadataRequestBenchmark.testTopicIdInfo
Current Code, unpatched
(partitionCount)  (topicCount)  Mode  Cnt         Score         Error  Units
              10           500  avgt   15        10.760 ±       0.078  ns/op
              10          1000  avgt   15        11.118 ±       0.281  ns/op
              10          5000  avgt   15        10.882 ±       0.192  ns/op
              20           500  avgt   15        10.822 ±       0.121  ns/op
              20          1000  avgt   15        10.966 ±       0.569  ns/op
              20          5000  avgt   15        10.764 ±       0.120  ns/op
              50           500  avgt   15        10.823 ±       0.081  ns/op
              50          1000  avgt   15        10.755 ±       0.154  ns/op
              50          5000  avgt   15        10.694 ±       0.068  ns/op

KRaftMetadataRequestBenchmark.testTopicIdInfo
Updated Code
(partitionCount)  (topicCount)  Mode  Cnt  Score (Paguro)       Error  Units  Score (Vavr)  Error  Units  Score (PColl) Error  Units
              10           500  avgt   15        10.493 ±       0.056  ns/op  7.488 ±       0.055  ns/op  10.548 ±      0.032  ns/op
              10          1000  avgt   15        10.507 ±       0.059  ns/op  7.505 ±       0.227  ns/op  10.545 ±      0.063  ns/op
              10          5000  avgt   15        10.455 ±       0.055  ns/op  7.453 ±       0.037  ns/op  10.545 ±      0.035  ns/op
              20           500  avgt   15        10.424 ±       0.035  ns/op  7.486 ±       0.194  ns/op  10.587 ±      0.041  ns/op
              20          1000  avgt   15        10.476 ±       0.139  ns/op  7.509 ±       0.075  ns/op  10.531 ±      0.047  ns/op
              20          5000  avgt   15        10.454 ±       0.079  ns/op  7.530 ±       0.027  ns/op  10.618 ±      0.159  ns/op
              50           500  avgt   15        10.891 ±       0.152  ns/op  7.551 ±       0.216  ns/op  10.515 ±      0.033  ns/op
              50          1000  avgt   15        10.509 ±       0.073  ns/op  7.616 ±       0.139  ns/op  10.763 ±      0.304  ns/op
              50          5000  avgt   15        10.479 ±       0.059  ns/op  7.454 ±       0.038  ns/op  10.605 ±      0.041  ns/op

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@rondagostino , also, it looks like this library doesn't support JDK 8?

@showuon Thanks for the review.  Yes, I noticed the lack of Java 8 support as well.  I tried compiling the latest version of Paguro with Java 8 and it did not work (e.g. [ERROR]   reason: '<>' with anonymous inner classes is not supported in -source 8).
I will change the PRs to use the Java-8 compatible Paguro 3.1.2 version instead of Paguro 3.10.3 for the moment while doing research for a replacement library that supports Java 8 and that extends the standard java.util interfaces.

I removed Paguro in favor of Vavr.  The PR size would have been much larger without the addition of the Vavr{Set,Map}AsJava classes that wrap the Vavr maps and sets as their unmodifiable java.util equivalents.  I've updated the PR description to show the Vavr benchmark numbers alongside the Paguro ones.  They are comparable, though the topicIdInfo benchmark shows the several extra nanoseconds it takes to instantiate the wrapper class for the var implementation.

The topicIdInfo benchmark now performs equivalently.  I eliminated the TranslatedValueMapView class in favor of adding a value mapper to the VavrMapAsJava class.

Thanks @rondagostino for the PR. I am also evaluating different persistent libraries for the removal of the R/W lock from StandardAuthorizer. I checked three libraries - pcollections, Paguro and Vavr.
For the StandardAuthorizer, it looks like pcollections shows read-time performance similar to the existing code and 3-4x of AclAuthorizer. But the Vavr and Paguro are performing very badly at the time of read - around 5000x of current code performance. Even though the write time performance of Paguro was the best and pcollections was around 20x of Paguro.
Because of read performance, pcollections looks like a clear choice for the Authorizer use case. For the Kraft metadata image change use case, should we evaluate the performance with pcollections as well?

The persistent collection library space remain unsettled (frustrating that it would remain this way even after so many years). I therefore added wrapper classes and import controls so that we don't end up sprinkling library-specific code all over the place.  This will help insulate us from changes in this space over time.
Given that the PColllections benchmarks are a massive improvement over the existing code, we can just go with PCollections here since that is what is needed in https://github.com/apache/kafka/pull/13437.

Thanks for working on this, @rondagostino and @showuon ! I think this will be a really cool improvement.
A note about namespace names:
Rather than having an abbreviated namespace like org.apache.kafka.pcoll , how about org.apache.kafka.server.persistent ? This emphasizes that the code is in server-common and is more consistent with our other namespace names, which mostly don't use abbreviations.
I don't have any objection to wrapping pcollections so that you can swap in a different library in the future. However, I don't like the wrappers here for two main reasons:

They don't implement standard collection interfaces (java.util.Map, java.util.Set)
They involve an additional "wrapper object" for every operation (every addition, etc.)

The first issue is easy to fix. If you look at TimelineHashMap.java and TimelineHashSet.java, you can see that I implemented the standard Map and Set operations without too much fuss. It is a lot better than just implementing Iterable and some getters or having awkward "convert this to a real java collection" methods.
The second issue is harder to fix because of the nature of Java's type system. However, I suspect that you might be able to do it by having something like a PCollectionFactory that implemented PersistentCollectionFactory. Then you could have methods like:
class PersistentCollectionFactory<K, V> {
Map<K, V> emptyMap<K, V>()
Map<K, V> singletonMap<K, V>(K k, V v)
Map<K, V> afterAdding<K, V>(Map<K, V> map, K k, V v)
Map<K, V> afterRemoving<K, V>(Map<K, V> map, K k, V v)
Map<K, V> afterRemoving<K, V>(Map<K, V> map, K k)
...
}

This would basically let you not have to cart around a wrapper object for each new map you created. However you could avoid dealing with pcollections types entirely in the calling code, and just refer to java.util.Map, etc. Since the pcollections type do implement the standard java types, this would work well here.

It is true that the wrapper implementation in the PR as it stands right now always creates a new object when creating a new persistent collection (either by creating an empty/singleton or by adding/removing from an existing one). The overhead is low -- object creation isn't onerous in time or space when object initialization is cheap (which it is here), and the work created by having the additional object will be a very low percentage of the work that the underlying persistent collection has to do anyway. So it doesn't concern me very much in that regard, but I do agree we should avoid it if we decide it is unnecessary and any tradeoff ends up being worth it.

The performance issues are debatable, I'll definitely grant you that. And I feel kind of bad mentioning them considering what a big performance improvement this will be in general. Probably the bigger issue is the extra complexity of implementing our own Set / Map / TreeMap / etc. It's all doable (and perhaps we'll end up doing it for Vavr) but it feels kind of bad when the library has already done that work.

So I think we have a situation where the current PR introduces a small amount of overhead that is not expected to be significant but that we would prefer to eliminate of possible. But the cost of eliminating it is a lack of type safety -- the compiler would not be able to know if a collection is a persistent one or not.

I agree that the solution I proprosed lacks type safety. It would be possible for someone to pass a non-persistent map to one of the PersistentCollectionFactory methods. Or, of course, to pass a different kind of persistent collection than what is expected.
If type safety is a requirement, it would be possible to add a third generic parameter which is the type of the Map. But this gets back to your original objection to exposing these types, which is that people could then invoke methods directly on the pcollections map type. The users would also need to pull in the pcollections imports and so on. I feel that there is no advantage to going down this path versus just using pcollections directly, since the effort to switch to something else later would not be lessened.
Another option is to actually handle the different types in an appropriate fashion. For example, if someone gives you a non-pcollections java.util.HashMap, you can implement afterAdding by copying it with the requested addition. Hmm... now that I think about this more, it actually sounds like a pretty good option. I suppose in that case we could just have a bunch of static methods in org.apache.kafka.server.persistent.PersistentCollection like PersistentCollection. afterAdding(K k, V v) and implement them appropriately for all persistent collection types we support...

Probably the bigger issue is the extra complexity of implementing our own Set / Map / TreeMap / etc. It's all doable (and perhaps we'll end up doing it for Vavr) but it feels kind of bad when the library has already done that work.

i think you are referring to having to implement that if we don't go with the current PR implementation and instead go with something like what you proposed -- since the current PR wrapper implementations don't implement the Set/Map interfaces.  Is that correct?  In other words, I think you are arguing against your proposal -- I just want to be sure.

handle the different types in an appropriate fashion
java.util.HashMap... implement afterAdding by copying it with the requested addition

I think it is important for people to be able to easily understand what performance they are going to get from a function.  If that's not clear, and we end up giving O(1) performance if the downcast to a persistent collection can occur vs. O(N) performance if it cannot -- I think that would make it more likely for O(N) performance to occur inadvertently.  Especially since people won't necessarily be able to know what type they have just by reading the immediate code -- if all they know is that have a java.util.Map then they might have to trace back to figure out where they actually got that, what the actual type is, and therefore what O() behavior they are going to get if they try to add something to it.

have a bunch of static methods in org.apache.kafka.server.persistent.PersistentCollection like PersistentCollection. afterAdding(K k, V v) and implement them appropriately for all persistent collection types we support.

I'm not following this suggestion.  I don't think this would give us type safety.  It feels like it is just the wrapper class I've implemented here.  I'm perhaps missing something.
Overall, I'm feeling like type safety is not worth giving up for the very small benefit of eliminating the wrapper class.

i think you are referring to having to implement that if we don't go with the current PR implementation and instead go with something like what you proposed -- since the current PR wrapper implementations don't implement the Set/Map interfaces. Is that correct? In other words, I think you are arguing against your proposal -- I just want to be sure.

So firstly, as per the earlier discussion in the PR, I think we have to implement Set, Map, and TreeMap. Using custom types just hurts programmer productivity and ability to understand the code too much. Obviously there are going to be some differences with the java.util versions, but hopefully those can be minimal, so people's intuitions about what is O(1), O(N), O(log N) can be correct, as well as people's understanding of what the code does.
So the contest here is between

implementing your own Set, Map, TreeMap wrappers above the library code, or
implementing a helper class like I suggested above
just using pcollections directly, and adding a wrapper class only for the libraries that need it, like Vavr

My main argument is that 1 is a lot of tricky code that we don't really need, and likely worse performance (it's hard to argue about it without benchmarks, of course).
3 will make it slightly harder to try different collections libraries. Although in theory we could ask people to use our own helper functions rather than PCollections-specific methods, to minimize the delta needed. Perhaps this is an avenue worth exploring.

I think it is important for people to be able to easily understand what performance they are going to get from a function. If that's not clear, and we end up giving O(1) performance if the downcast to a persistent collection can occur vs. O(N) performance if it cannot -- I think that would make it more likely for O(N) performance to occur inadvertently. Especially since people won't necessarily be able to know what type they have just by reading the immediate code -- if all they know is that have a java.util.Map then they might have to trace back to figure out where they actually got that, what the actual type is, and therefore what O() behavior they are going to get if they try to add something to it.

There is a tension between what you are trying to do here (abstract over multiple libraries) and the idea that "people [need] to be able to easily understand what performance they are going to get from a function." If a new library we add later is somewhat better at get() and worse at put(), does that means that people using your wrappers can't "easily understand what performance they are going to get"? Arguably yes. So should we ditch the wrappers and use the libraries directly?
Ultimately the test of performance is our JMH benchmarks, as well as the profiles we take in production. I believe we should rely on those, rather than assuming we can deduce everything about performance ahead of time...

I think we have to implement Set, Map, and TreeMap.  Using custom types just hurts programmer productivity and ability to understand the code too much... [it] is a lot of tricky code that we don't really need,

I don't think we have to if we go with a wrapper class -- it is trivial to invoke asJava() if the programmer wants something that implements the standard interface.  If we did want it, it is trivial to delegate all those invocations when the underlying library classes already implement those interfaces -- which is the case with PCollections.  But yes, it would be annoyng to have to write it for something like Vavr.  This is why I felt that the asJava() method is a good solution.

There is a tension... should we ditch the wrappers and use the libraries directly?
Agreed, there's no perfect solution.  We either sprinkle the PCollections code all over the place and have to migrate all of that or we abstract it away somehow.  I think we should abstract it away but don't get too crazy about it.  I think not implementing the standard interfaces, supporting .asJava(), and providing type safety so people at least know they have a persistent collection is a good balance.

We can implement the java.util interfaces in the wrapper classes.  It is trivial to do so via delegation when the underlying library classes already implement those interfaces -- which is the case with PCollections.
It will be more difficult for libraries like Vavr that do not support those interfaces directly.  See, for example, the VavrMapAsJava class I implemented in the Vavr commit, https://github.com/apache/kafka/pull/13280/commits/f195c2055bad96da2a189ff35ea0dd9263da5d6e.  But it was not onerous.

Also, as you yourself argued, converting back to java.util.Map loses type safety, since now we don't know if we have a persistent map or not. It is quite useful to know that your map is immutable, even if I doubt that confusion between regular types and persistent ones will be as common as you suggest.

Yeah, I was including .asJava() really only as a way to not have to change our existing type return values.  If something returns a java.util.Map<> and now we are implementing the logic with persistent data structures, do we want to change that signature to indicate that the returned map is persistent?  When we weren't considering the use of a wrapper class it was very intrusive to change the signature to say we are now returning a Vavr map -- the ripple effects went everywhere.
But I guess this does argue for implementing the standard interfaces in the wrapper.  It would allow us to change the signature but downstream code is unaffected.  That code might declare Map<Class1, Class2> x = someObject.someMethod() and that will still compile when we declare someMethod() to return a wrapper class when that wrapper class implements java.util.Map.  That insulates us from ripple-effect changes while simultaneously giving callers the option to actually know that the map is a persistent one.
I think this is the argument that convinces me to implement the standard interfaces in the wrapper classes.  I'll add it now.

Type safety is a tricky thing. There's no hard and fast rule about where to stop :)
I do genuinely think encoding "this is persistent and therefore immutable" in the type system is a good thing... maybe it's my history as a C++ programmer (heh)
Anyway sounds good

My suggestion is to introduce a new interface like ImmutableMap (PMap or PersistentMap are also possible, but they can be confused with a map that persists the data) and introduce new methods to that interface. Our code should only interact with ImmutableMap, java.util.Map, etc.
For code that doesn't need the new methods exposed via ImmutableMap, we can choose to use java.util.Map if we like.

Thanks for the review @ijuma.  I think you have suggested 2 name changes: one to rename the wrapper  interfaces and one to Rena e the methods on those interfaces.
Current interface names:
PHash{Map,Set}Wrapper
Proposed interface names:
Immutable{Map,Set}
Persistent{Map,Set}
P{Map,Set}
I don't have a strong a strong preference, so I'll go with Immutable{Map,Set} given your comment about the potential dual meaning of persistent.
Regarding the method names.
Current method names:
newSet = origSet.afterAdding(e);
NewMap = origMap.afterRemoving(k);
These read pretty well for me.
Proposed names:
newSet = origSet.updated(e);
newMap = origMap.removed(k);
I'm fine with this style, though maybe "origSet.added(e);" would be better?

Yes, updated would only make sense on the map interface. For the Set interface, added seems reasonable.

@ijuma @rondagostino : I feel like "persistent" should appear somewhere in the class names here. Perhaps you're right that it doesn't need to be in the short class name, but can we put the classes in a namespace that includes that word? So something like org.apache.kafka.server.persistent? Then we'd have org.apache.kafka.server.persistent.ImmutableMap, etc.

Yes, updated would only make sense on the map interface. For the Set interface, added seems reasonable.

Sorry to bikeshed this again but I kinda like withAdded, withRemoval, etc. Curious how you feel about those.

I don't see strong motivation for having that in the name. Most of the examples you have simply documented it which we can as well.

documented it which we can as well.

Yes, the Javadoc uses the term persistent.
I'm fine with the package/class/method names as they exist right now.

I'm fine with the package/class/method names as they exist right now.

+1

I don't see strong motivation for having that in the name. Most of the examples you have simply documented it which we can as well.

Yeah, correct. Scala doesn't include it in the name though it is persistent.
I am also fine to follow the current naming which conforms to Scala.

@rondagostino BTW I still would like to understand what is wrong with calling values() on the map (if anything) but let's take that discussion offline and not block on it


(FACT-2128) Fix mountpoints fact

https://tickets.puppetlabs.com/browse/FACT-2128

Can one of the admins verify this patch?

Hi @valia0906, thanks for your contribution!
Looks like we were reading f_bfree while df uses f_bavail to report the available space, which takes into account the root-reserved space (see https://stackoverflow.com/a/51107001).
However, the tests are failing because the free field of the mountpoint struct is not mocked.
I would suggest the following:

add a reserved parameter to the add_mountpoint function here https://github.com/puppetlabs/facter/blob/master/lib/tests/facts/resolvers/filesystem_resolver.cc#L17
set mp.free to available + reserved
add the new parameter to the function call here https://github.com/puppetlabs/facter/blob/master/lib/tests/facts/resolvers/filesystem_resolver.cc#L78 (call it with 0 for the tests to pass)

Would you be able to work on this?

Ive alrady add t opass tests but they failed. Maybe Ive done something wrong. Can you see?

All tests were successful, thank you for your help.

CLA signed by all contributors.

Looks good! Can you please squash your work into a single commit? Also, please include the ticket number in the commit message (i.e.: (FACT-2128) Fix mountpoints fact). We have some automated checks that rely on this format.

I`ve created new pull request with squashed commits.

Continued in https://github.com/puppetlabs/facter/pull/1857


Why is it's still in README?

I am shocked that it's still in README.
I am sure that if somebody would add "Free Palestine From Hamas" or "Stand With Israel", Even "Arabs and Jews Refuse to be enemies" it was long removed by one of the maintainers.
And to @acao I would hope to have just a fraction of a white man's confidence when talking about things that happen thousands of miles away from where I live.

The GraphQL technical steering committee is working on a policy to guide the use of political speech from the voice of a GraphQL project. The original author chose to revert the original change via #1879 until we complete that policy. This should resolve this issue, so I am closing it.
As a reminder, all discussion within GraphQL projects must adhere to our Code of Conduct.


Product functors are (braided/symmetric) monoidal

... if they go between (braided/symmetric) monoidal categories.

Yep it should be ready. I checked using make test locally, so I expect Travis to be happy too.
Yes, it's all boilerplate. It would be nice to avoid doing these things by hand. There seems to be a lot of boilerplate stuff for monoidal categories in general...

My guess is that this is true of many "lifting" operations, where properties in the base case lift across a nice operation. The same probably will happen from some unary functors too.


Little bug with AnimatedList - Axis.horizontal

When I want to animate my AnimatedList with removeItem method in horizontal direction, is not working the animation of the list. When I use vertical direction is working perfect with removeItem but the problem is only with horizontal direction, more specifically to use removeItem method because the list is not animated, only the animation works when I add an item.

I have solved! you have to specify axis: Axis.horizontal in your SizeTransition (on removeItem)


rails_helper

Hello,
actually I do not know, is it a bug or a feature, and I did not found better way, than write here.
There is no any mention of spec_helper in rails_helper, and if use config as usual, including only rails-helper in specs, you will never achieve simplecov.
I understand, that there may me any reason to move in other file webmocks, but why expect syntax and simplecov are moved also?
I will be very pleased, if you will say me the core of the idea of this feature, or give some data about it.
Thank you!

There is no any mention of spec_helper in rails_helper [...] you will never achieve simplecov.

As https://github.com/thoughtbot/suspenders/issues/631 shows, suspenders apps generate a .rspec file which includes spec_helper, and thus we get coverage.

why expect syntax and simplecov are moved also?

I don't understand this question. Can you please explain more?

I will close this issue as it's not a bug in suspenders, but I'm happy to continue this thread. Thanks!


adjusting azure-core reference tag for agrifood-farming:pom

Addressing the POM version scanner failure due to reference to non-existing unreleased tag

Overriding check-enforce. The pom file version scanner will fail until this is checked in. We ran java - template (the internal) against this refs/merge to verify this change fixes it.

/check-enforcer override


Cross-Origin Request Blocked

Hi,
I'm running the LinuxForHealth server as a docker image as mentioned in the readme. The thing is that when I use curl or postman to send requests and receive responses, it is working perfectly fine.
But when I try to do the same from a browser, I'm getting the following error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ‘https://localhost:9443/fhir-server/api/v4/Device’. (Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’).
Can anyone help me with this? I know this is caused due to the browser trying to prevent CSRF attacks. But other than that, I don't know much.
Thanks,
Sundaresan

Issue solved guys (for now). I just changed value attributed to the credentials in my source code to omit. This fixes the problem for now. But I don't know how secure it is (I omitted something, so that means there was something there to be omitted which could very well be a security patch or fix). So if you have any comments, please let me know. Thanks.


[$500] Request Money - The currency search field fails to auto-focus

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open a chat.
Navigate to the "Request Money" section.
Click on the currency option
Observe that the search field does not auto-focus.

Expected Result:
The currency search field should automatically focus upon clicking, ready for user input
Actual Result:
The currency search field does not auto-focus upon clicking, resulting in the need for click on search field
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1,3,66,3
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/9dcbd8e8-942f-4fe3-8bcd-d8c1fba7f690
https://github.com/Expensify/App/assets/93399543/df7c50ac-5f5e-4fde-90cb-2b6e172542ab
Expensify/Expensify Issue URL:
Issue reported by: @ayazhussain79
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1691438190303789
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01885f56507c4e1e91
Upwork Job ID:<PHONE_NUMBER>323342336
Last Price Increase: 2023-09-10

Proposal
Please re-state the problem that we are trying to solve in this issue.
The currency search field fails to autofocus.
What is the root cause of that problem?
The selection list gains focus after the text input is initially focused which causes
What changes do you think we should make in order to solve the problem?
Add shouldDelayFocus prop to the OptionsSelector in IOUCurrencySelection.
What alternative solutions did you explore? (Optional)
None.

Dupe of https://github.com/Expensify/App/issues/27030

Closing as it appears to be a dupe of the below.  Thanks @ishpaul777 for the 👀 and comment

#27030


generate python documentation for our sdk(nginx)

Type of issue
Missing information
Description
missing python documentation, we are wondering if we can get auto generated documentation like
https://azuresdkdocs.blob.core.windows.net/$web/python/azure-appconfiguration/1.6.0/index.html
our sdk page: https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/nginx/azure-mgmt-nginx#examples
[Enter feedback here]
Page URL
https://learn.microsoft.com/en-us/python/api/overview/azure/mgmt-nginx-readme?view=azure-python
Content source URL
https://github.com/MicrosoftDocs/azure-docs-sdk-python/blob/main/docs-ref-services/latest/mgmt-nginx-readme.md
Document Version Independent Id
7a4f91d0-229e-82b0-d9a2-7b48b1ac118b
Article author
@azure-sdk
Metadata

ID: ceea63dc-9530-e33a-ba1b-d9576c1d9995
Service: nginx

@danieljurek
Hi is there any update on this? Thank you

Chatted with @jamesfan1 -- The linked README.md file is where updated content should go https://github.com/MicrosoftDocs/azure-docs-sdk-python/blob/main/docs-ref-services/latest/mgmt-nginx-readme.md ... this is owned by the team which authors the SDK.


SandDance Explorer snapshot sharing

How to make my SandDance Explorer snapshots shareable?
In the SandDance Explorer example https://sanddance.js.org/app it is possible to share your snapshot with the 'share' button;

I can't find any information about this share/export option in the docs, the only 2 things I could find;
A function called SnapshotExport - https://github.com/microsoft/SandDance/blob/b0725a2eb975b248d6e6a61a2471d0fa97f41669/packages/sanddance-app/src/snapshots.tsx#L269
And a button that changes the url which makes it shareable - https://github.com/microsoft/SandDance/blob/b0725a2eb975b248d6e6a61a2471d0fa97f41669/packages/sanddance-app/src/snapshots.tsx#L301-L316
^These look like the function and button that I'm looking for but I don't know how to implement this in my code
Example of my explorerProps:
return {
  //logoClickUrl: '/',
  mounted: explorer => {
    const service = this.getServices(process.env.webserver);
    const url = myUrl
    const dataFile = {
      displayName: 'Mangrove',
      dataUrl: url,
      type: fileType
    }
    explorer.load(dataFile);
  },
  compactUI: { compactUI },
  dataExportHandler: true
}

I was expecting that there would be an option like; 'snapshotSharing: boolean'.

DataExport:
In my code example above you can see that I've set the 'dataExportHandler' on true, but whenever I try to export my rows like this:

It displays the following error in my console; Uncaught TypeError: this.props.dataExportHandler is not a function
Just like the snapshot sharing I cannot find anything regarding this function in the docs.

For snapshot sharing, see snapshotProps, an object with a getActions property, which returns an array of your own `SnapShotActions](https://github.com/microsoft/SandDance/blob/master/packages/sanddance-explorer/src/interfaces.ts#L33). Here you can provide your own React elements for the snapshot actions.
The dataExportHandler prop should be a function, please see this example

For snapshot sharing, see snapshotProps, an object with a getActions property, which returns an array of your own `SnapShotActions](https://github.com/microsoft/SandDance/blob/master/packages/sanddance-explorer/src/interfaces.ts#L33). Here you can provide your own React elements for the snapshot actions.
The dataExportHandler prop should be a function, please see this example

Closing this for now, if you have any feedback, please feel free to re-open.


 I mean it seems kind of obvious now that I am reading the error message, but is there any fix?
I just cannot use multiple layers for now, I could try splitting it up into files


Openshift password should be given/pulled from summon

The script asks few times for OpenShift password. In order to make it run automatically from start to end it needs to pull the password from summon or receive  it as a parameter

Hi @tzheleznyak. It should already do this if you're using summon, see https://github.com/cyberark/kubernetes-conjur-deploy/blob/master/secrets.yml#L13. Alternatively you could export the environment variable OPENSHIFT_PASSWORD before running the script.
It's possible that I'm misunderstanding when exactly this happens. If so, please provide details for how we can replicate the issue you're facing.

Do i need to launch the ./script using summon. It not happens in the script?

@tzheleznyak Yes you'll have to run the script using summon.


⚠ Bofrost.es has degraded performance

In 256d184, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 2037 ms

Resolved: Bofrost.es performance has improved in 8ebb857 after 10 minutes.


Implement transfers to sequencer

Changes:

On commit update inner account.

Fetch deposits and decide which have delay already passed and should be included.

Add committer.ml file where proving and storing of commits happen.

Changed recomitting logic. We are now not storing the commit command, but instead witness needed to prove and recreate the command. This is because the unprocessed transfers action extension will change with users submitting deposits, so it needs to be reproven.

Add api for proving transfers (async for now).

I would change it to async-less api in future PR and merge this so it can be tested.

Add tests.

Add also archive to the testing ledger, to test fetching of actions.

PR description and unrelated commits seem to be included

What is the design of the API?


Add statistics for idr0127

Generated using https://github.com/IDR/idr-utils/pull/49.
The last two commits unify the format of the table to comply with the new proposed number of columns

OK, so I see the extra Sample Type column and it's filled in for idr0127.
So it needs filling in for the other studies in a followup PR?

I just tried running https://github.com/IDR/idr-utils/pull/49 on idr-next server.
$ python idr-utils/scripts/stats.py --disable-fsusage
...
Created session for public@localhost:4064. Idle timeout: 10 min. Current group: Public
Traceback (most recent call last):
  File "idr-utils/scripts/stats.py", line 466, in <module>
    main()
  File "idr-utils/scripts/stats.py", line 459, in main
    append_totals=(ns.format != 'tsv'))
  File "idr-utils/scripts/stats.py", line 303, in stat_top_level
    for study, containers in sorted(studies(study_list).items()):
  File "idr-utils/scripts/stats.py", line 138, in studies
    for line in f:
  File "/usr/lib64/python3.6/fileinput.py", line 250, in __next__
    line = self._readline()
  File "/usr/lib64/python3.6/fileinput.py", line 360, in _readline
    self._file = self._openhook(self._filename, self._mode)
  File "/usr/lib64/python3.6/fileinput.py", line 400, in hook_compressed
    return open(filename, mode)
FileNotFoundError: [Errno 2] No such file or directory: 'idr0087-paci-nuclearimport/experimentA/idr0087-experimentA-filePaths.tsv'

Interesting, indeed, there was a mismatch between the type of file and its name for this study. Pushed https://github.com/IDR/idr0087-paci-nuclearimport/commit/a0f5ccff4d3fb64d2b64a31154c7e16d89a5cc66 and pulled the change on prod105

$ python idr-utils/scripts/stats.py --release prod105 idr0123-mota-mifish
idr0123-mota-mifish	experimentA	prod105	2251	9	0			0	208	93662	0.196082560248<PHONE_NUMBER>48	1673<PHONE_NUMBER>3950985	1024 x 1024 x 66 x 7 x 1	cell

Added idr0123 in https://github.com/will-moore/idr.openmicroscopy.org/commit/f59e67e2389c32ca1bf3fa97d274886d8f04b9da


Starter Template is broken

The starter template is broken due to dependency fetch:
index.js:504 Uncaught TypeError: Class extends value undefined is not a constructor or null
    at node_modules/nofilter/lib/index.js (index.js:504:11)
    at __require2 (chunk-FKZU6AN4.js?v=74759e5a:47:50)
    at node_modules/cbor/lib/utils.js (utils.js:4:18)
    at __require2 (chunk-FKZU6AN4.js?v=74759e5a:47:50)
    at node_modules/cbor/lib/commented.js (commented.js:4:15)
    at __require2 (chunk-FKZU6AN4.js?v=74759e5a:47:50)
    at node_modules/cbor/lib/cbor.js (cbor.js:3:21)
    at __require2 (chunk-FKZU6AN4.js?v=74759e5a:47:50)
    at esm_shims.js:2:32

This also broke the cloud version  https://vite-typescript-starter.thirdweb-example.com/

hey @SebasG22, thanks for the report. We're actively working on a fix for this in: https://github.com/thirdweb-dev/typescript-sdk/pull/459 and will update this template when that is resolved later today!

hey @SebasG22, thanks for the report. We're actively working on a fix for this in: thirdweb-dev/typescript-sdk#459 and will update this template when that is resolved later today!
@jnsdls
I confirm this fix solves the blocker issue. Now the button to connect to Metamask is on the screen. The only issue that I saw is an error for Buffer.


Flake lang migration rust

I think this is superseded by https://github.com/mlabs-haskell/lambda-buffers/pull/184


SCRUM-1850 integration tests

The changes to all the validators are the same - a fault in the logic for validation of obsolete terms/entities where null objects were not accounted for.  I guess I could pull all of that out into its own PR but it might as well go in with this stuff as it was doing the ExperimentalCondition integration tests that identified the bug.  Do we really need to create extra work?

The changes to all the validators are the same - a fault in the logic for validation of obsolete terms/entities where null objects were not accounted for. I guess I could pull all of that out into its own PR but it might as well go in with this stuff as it was doing the ExperimentalCondition integration tests that identified the bug. Do we really need to create extra work?

Separation of concerns makes for easier review and testing. If you want to be able to trace these additional changes and test them on alpha independently, then yes, I'd recommend to make a separate PR for merging those changes to alpha instead, and only merge the relevant new experimental condition integration tests in this branch (I can cherry-pick them from the commit mentioned earlier).
If these changes don't require any further testing or approval, then fair enough, you can leave them in this PR.


add maximum duration in docs

What happened?
beta 28 introduced maximum duration feature. We need to make sure we include that in the docs.
How to reproduce
install beta 28 or up.
Relevant log output
No response
Which version are you running?
beta 28
Diagnostics file

[X] I have attached a diagnostics file

Additional information
No response

@gatonero this is for you :)


"ocicl install package-name" always downloads

This is a feature request.  "ocicl install XX" always downloads the XX package files, even if they already exist.  "ocicl install" only downloads packages that aren't locally available.   I'd like the first to act like the second.  You could even add a flag like "ocicl install --if-needed" to preserve the existing behaviour.
  I'd like to be able to run it on each build.  I could just invoke "ocicl install" if the systems.csv exists, but that exceeds my meager ability to write windows bat scripts.

Ok, try the latest version.  See what I changed in the README.  The --force option forces a download.


Update version to 0.5.0

I wonder if these shouldn't move to the 'workspace' model for Cargo.toml too so every settings doesn't need to be repeated 4 times.


I am not able to use the npm run dist: win accompanies this error

I have the same issue too.

I went to package.json and in scripts I changed what was at start to "start": "react-scripts start", and so at least npm start is back up and running

Like this?
Because I'm still getting the same error.

uses npm start

Thanks for reporting @MatheusMoreira0101 @gvasilakiss, I have fixed the issue with npm run dist:win on windows machines in the latest update. Feel free to test it out and let me know if the issue still persists.

Hey there, now when I run the program I get this

Hey @gvasilakiss, I have tested this on a windows machine. Couldn't reproduce it. Can you let me know the commands you have used to start the application?
Ideally the following command should work on windows.
npm run electron-dev

If you get an error saying 'BROWSER' is not recognized, just remove BROWSER=none from the electron-dev run script in package.json

To start the application I do:
npm run dist:win
Is this the correct format?

I have pushed a hot-fix to change a few things in the run scripts. Please pull the changes and try again.

npm run dist:win is used to create production builds of the app. To run the app in development mode npm run electron-dev is used.

This is the message I get now:

I tried the cross-env but I didn't work.

cross-env is a development dependency, you might need to run npm install

Okay now its working form the electro-dev

When I'm trying to log in I get this now:
:3000/#/:1 Form submission cancelled because the form is not connected

Try, pulling the latest changes :smile: I have encountered this and sent a fix.

I pulled the latest one, but still the same issue

Cross-platform development is a pain :face_with_head_bandage: . I'll take a close look. into this one Do check if the problem exists on production builds.:)

Okay, will wait for your reply.

When I login it returns to the terminal
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false".  It will change to be "true" in Electron 9.  For more information please check https://github.com/electron/electron/issues/18397

alhamdulillah, but I can't save 24 hours 😄 ,

@mukmin-rockman Option will be available in the upcoming release 👍🏼

Thank you very much (Jazakallahu khairan) Mr. @haxzie 👍

alhamdulillah, but I can't save 24 hours 😄 ,

How you managed to get it working?
Can you send the steps you followed, I did what was said in the readme file, but no luck.

When I login it returns to the terminal
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false". It will change to be "true" in Electron 9. For more information please check electron/electron#18397

Even I had the same issue. The latest update has helped me fix it. Please do check it. kudos @haxzie

 the video was automatically saved, I'm waiting for the next update

chat me via Whatapps +62<PHONE_NUMBER>2

can i live with others in obs ?

@monillosagasta As of now, nope.


move-package: add name resolution hook

Description
Adds a custom_resolve_pkg_name hook in order to allow for the dependency graph to discriminate between packages based on a dynamically resolved symbol (returned by the hook) rather than just package name. When the hook isn't defined it returns the package manifest name when so this doesn't affect Sui package resolution currently. This will make it possible to consolidate source and on-chain packages (which don't have a name) within a single graph.
This is part of the work to enable compiling against on-chain dependencies https://github.com/MystenLabs/sui/pull/14178.
Test Plan
Added unit tests.

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)

[ ] protocol change
[ ] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes

@amnn @rvantonder I'm debating whether the custom_resolve_pkg_name (and corresponding variables) should be renamed to custom_resolve_pkg_identifier because "pkg_name" variables in dependency graph conflating between package name as defined in manifest and resolved name gets super confusing with later changes.

conflating between package name as defined in manifest and resolved name gets super confusing with later changes.

A better name sounds good to me! Thoughts on custom_resolve_pkg_manifest_name or custom_resolve_pkg_name_from_manifest? I think more verbosity here will help, identifier comes across as something more general than the "real" description that causes confusion :-)

(kicking off CI)

Well the problem is really with referring to the thing as "package name" since with the resolution hook it's not necessarily a name anymore. E.g. with Sui on-chain resolution hooks it will be its original id.
So the first point of confusion is that dependency graph code uses types such as PM::PackageName in maps as package keys and the other is that variable names such as pkg_name are used when with the resolution hook it's not necessarilly a package name. This becomes especially tricky around places where the resolution hook gets called and propagated because all variable names become confusing when reading the code.
I was thinking we need something more generic than package name.

Got it! If this is a case of just renaming, I'm generally in favor (indicating identifer is good, with appropriate comments to explain this could refer to a source package name, versus an on-chain ID).
@kklas is your sense that there's a direction that this is more than renaming, i.e., we may want types to represent these?
Either way, I think we're good to follow up with a renaming / refactor PR to be hygienic about this, and don't need to bundle it with this PR. @amnn to weigh in when he's back from PTO later this week, but I don't see this as needing to block this PR. I'll take a deeper look soon!

I think it would just be a renaming in dependency_graph and resolution_graph files. PM::PackageName is a type alias to Symbol so we can just introduce a new alias like PackageIdentifier. There's a lot of pkg_name variables in these files though (~130).

I will change name to identifier at the end because otherwise there will be a lot of merge conflicts with commits that are ready from before.

(kicking off CI)

@rvantonder what's the status?


Relationship Responders

This was the most intricate of the conversions. The interplay between RelationshipController, RelationshipControl and their delegate/responders required a lot of Swift value type wrapping and code refactoring. RelationshiopController is now held by BaseElloViewController due to BlockModalViewController's need for it to be in the responder chain.
Future work may include renaming the RelationshipPriority and RelationshipRequestStatus wrappers for more clarity.

(sorry about the merge conflict!)

All changes made. Running specs now. You'll be happy to know that I merged sd/feature/disable-logged-out-interaction rather than rebasing @colinta. It was hard not to type r-e-b-a-s-e, but I did it! Also, thanks for the thorough review on this pr. Very helpful!

Executed 2623 tests, with 0 failures (0 unexpected) in 334.869 (337.185) seconds

Ok, if everything is good to go @colinta please approve it and we can merge this into sd/feature/disable-logged-out-interaction.


Feature/upd build

link to javadoc on gh-pages
add copying of the final jar ./dcm4ceph-dist via antrun plugin

along with some cleanup changes mentioned in chat

Basically re-tested java8 compile + java 17 run and vice-versa. All works fine now.


Add app_launcher_visible to Access Application

Description
Adds the app_launcher_visible field to Access applications. This optional field will allow the ability to show/hide applications in App Launcher.
Related PR: https://github.com/cloudflare/terraform-provider-cloudflare/pull/1303
Has your change been tested?
Here is a cURL request with the new field:
curl --request PUT \
  --url https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/access/apps/<APP_ID> \
  --header 'authorization: Bearer <TOKEN>' \
  --header 'content-type: application/json' \
  --header 'x-auth-email: <EMAIL>' \
  --header 'x-auth-key: <KEY>' \
  --data '{
        "aud": REDACTED,
        "domain": "asdf.fans",
        "id": REDACTED,
        "name": "asdf-fans",
        "policies": [],
        "allowed_idps": [],
        "session_duration": "24h",
        "uid": REDACTED,
        "auto_redirect_to_identity": false,
        "app_launcher_visible": true
}'
{
  "result": {
    "aud": REDACTED,
    "created_at": "2020-09-03T20:27:02Z",
    "domain": "asdf.fans",
    "id": REDACTED,
    "name": "asdf-fans",
    "policies": [],
    "allowed_idps": [],
    "auto_redirect_to_identity": false,
    "session_duration": "24h",
    "uid": REDACTED,
    "updated_at": "2021-11-08T14:33:13Z",
     "app_launcher_visible": true
  },
  "success": true,
  "errors": [],
  "messages": []
}

Types of changes
What sort of change does your code introduce/modify?

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] This change is using publicly documented (api.cloudflare.com or developers.cloudflare.com) and stable APIs.

thank you @AkemiDavisson 👏


MWPW-154013 PEP prompt redirection is broken in stage after the PEP dismissal PR merge

Fixed redirect issue introduced by #2392

Resolves: MWPW-154013
Test URLs:

Before: https://main--milo--adobecom.hlx.page/drafts/raghavs/pep-prompt?martech=off&skipPepEntitlements=true
After: https://dismiss-pep--milo--adobecom.hlx.page/drafts/raghavs/pep-prompt?martech=off&skipPepEntitlements=true
QA url: https://stage--cc--adobecom.hlx.live/products/photoshop/ai?milolibs=dismiss-pep&skipPepEntitlements=true

Validation done on the below url :
https://main--cc--adobecom.hlx.page/creativecloud/animation/testdoc/pepphsp1?milolibs=dismiss-pep&skipPepEntitlements=true

https://main--cc--adobecom.hlx.page/jp/creativecloud/animation/testdoc/pepphsp1?milolibs=dismiss-pep&skipPepEntitlements=true


chore: upgrade yarn

I converted this to a draft PR, there are some issues with asdf and yarn I will need to look into in the app Dockerfile.


Add support for Next.js app router exports

Ref: https://github.com/markdoc/markdoc/issues/416
@mfix-stripe, I'm not sure if you had a different implementation in mind, but thought I'd get the ball rolling on this one.
This PR adds support for specifying Next.js app router exports under the nextjs frontmatter key:
---
nextjs:
  dynamic: auto
  dynamicParams: true
  fetchCache: auto
  maxDuration: 5
  metadata:
    title: Lorem ipsum
    description: Lorem ipsum dolor sit amet
  preferredRegion: auto
  revalidate: false
  runtime: nodejs
---

Makes sense! I've updated the PR to include all exports that I could find under a nextjs key.
Export names come from:

https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config
https://nextjs.org/docs/app/building-your-application/optimizing/metadata

Let me know if you have any additional feedback! 🤙


bot.game.dimension returns the dimension the bot logged on instead of the current one

Hello, today i asked around the Discord if someone knew a fix for this problem but nothing pooped up, so i decided to open this Issue Page.
Every time i try to print bot.game.dimension, it always print out the dimension the bot logged in, even if i'm in another dimension at the moment. i'm trying to print it with the following command:
console.log(The bot has been killed at ${bot_current_position} by ${bot_nearest_player.username} on dimension ${bot.game.dimension})
Another user was also having this problem, he mentioned that the problem happend for him before the "Karangs world refactor".

this should be in mineflayer

I'll move it to Mineflayer then, thx


Change CSS classes of the homepage search line

Fixes #1048
There were two issues here:

The wrong CSS class was used - col-dm instead of col-md.
col-lg-6 only applies to larger screens, so I changed it to md.

To be perfectly honest, I do not have any Bootstrap experience, so this is kind of a lucky guess. Maybe it's not the "correct" way of doing it.

Thats why it did not work :/ Thank you!!


Create corresponding Alembic Migrations for Flyway 12/13

Describe the task
Create corresponding alembic migrations for the flyway 12/13 migrations.
Acceptance Criteria

[ ] 2 new alembic migrations are created for 12/13

Additional context

This is important as if they don't exist, we risk overwriting the flyway if we generate a new one from alembic

The Pull request #331 addresses adding logic to the script that generates the flyway migrations from the alembic migrations to prevent a clober or duplicate flyway migration for the condition where a flyway migration is generated without a corresponding alembic migration.


Data lineage between different database services is not showing

We have openmetadata setup on AKS clsuter using helm chart. we have connected databricks and azure sql database services. when we create table on databricks using a table from azure sql, the data lineage should be azure_sql_table --> databricks_table, but this lineage is not coming, we can see lineage between tables on databricks, like databricls_table1 --> databricks_table2. we tried creating tables with openmetadata-spark-agent as well as openmetadata-spark-agent-1.0-beta, nothing is giving expected result.

Hi team, Any update on this issue?

Is lineage btwn 2 different tables in the single database is possible?

@Madhur-Jatiya yes that is possible


[ISSUE #4706] fix console printed log format is incorrect

Make sure set the target branch to develop
What is the purpose of the change
Fix #4706
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.2%) to 48.829% when pulling e446c6421d4908a58fb3e90c7f454dc232c77b7a on mxsm:rocketmq-4706 into 96fb142569b3e3a5560ec57c84e351363841cf94 on apache:develop.


Add docker-compose config file

A new way to start it up:
docker-compose up -d

Maybe not a good idea, :)


Add regression tests for #987

@asroy Can we add a test case to the CI?

+1. I am not going to delay merging this PR and cherry-picking it, however. But if this PR will not contain a regression test, then I'll open a high priority ticket for this.
Originally posted by @atamazov in https://github.com/ROCmSoftwarePlatform/MIOpen/issues/987#issuecomment-864409294

vkia #997


[DO NOT REVIEW - 1.8 - #576 - Scanning AWS] Authenticate scanner

Do not review - this builds off of the add-system branch
Closes #576
Code Changes

[ ] list your code changes here

Steps to Confirm

[ ] list any manual steps taken to confirm the changes

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation Updated:

[ ] documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
[ ] documentation issue created (tag docs-team to complete issue separately)

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md

Description Of Changes
Write some things here about the changes and any potential caveats

@ssangervasi your work nullifies this work, right? or is your AWS work separate from this?


Got runtime error on flutter 2.8.1

Hi,
I tried using this plugin, but when I run the example code using flutter 2.8.1, i got runtime error :
E/flutter (27100): [ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: Concurrent modification during iteration: Instance(length:2) of '_GrowableList'.
E/flutter (27100): #0      ListIterator.moveNext (dart:_internal/iterable.dart:336)
E/flutter (27100): #1      SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1081)
E/flutter (27100): #2      SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:996)
E/flutter (27100): #3      _rootRun (dart:async/zone.dart:1428)
E/flutter (27100): #4      _CustomZone.run (dart:async/zone.dart:1328)
E/flutter (27100): #5      _CustomZone.runGuarded (dart:async/zone.dart:1236)
E/flutter (27100): #6      _invoke (dart:ui/hooks.dart:150)
E/flutter (27100): #7      PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:270)
E/flutter (27100): #8      _drawFrame (dart:ui/hooks.dart:114)
E/flutter (27100):
E/flutter (27100): [ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: Null check operator used on a null value
E/flutter (27100): #0      RenderRepaintBoundary.toImage (package:flutter/src/rendering/proxy_box.dart:3157)
E/flutter (27100): #1      _MarkerGeneratorState._convertToMarker (package:widget_marker_google_map/src/components/marker_generator.dart:28)
E/flutter (27100): #2      _MarkerGeneratorState.onBuildCompleted. (package:widget_marker_google_map/src/components/marker_generator.dart:52)
E/flutter (27100): #3      MappedListIterable.elementAt (dart:_internal/iterable.dart:413)
E/flutter (27100): #4      ListIterator.moveNext (dart:_internal/iterable.dart:342)
E/flutter (27100): #5      Future.wait (dart:async/future.dart:471)
E/flutter (27100): #6      _MarkerGeneratorState.onBuildCompleted (package:widget_marker_google_map/src/components/marker_generator.dart:52)
E/flutter (27100): #7      _MarkerGeneratorState.initState. (package:widget_marker_google_map/src/components/marker_generator.dart:43)
E/flutter (27100): #8      SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1145)
E/flutter (27100): #9      SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1082)
E/flutter (27100): #10     SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:996)
E/flutter (27100): #11     _rootRun (dart:async/zone.dart:1428)
E/flutter (27100): #12     _CustomZone.run (dart:async/zone.dart:1328)
E/flutter (27100): #13     _CustomZone.runGuarded (dart:async/zone.dart:1236)
E/flutter (27100): #14     _invoke (dart:ui/hooks.dart:150)
E/flutter (27100): #15     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:270)
E/flutter (27100): #16     _drawFrame (dart:ui/hooks.dart:114)
E/flutter (27100):
Is there any way to fix it?
Thank you.

Hello sir,
I have the same issue, Did you solve it?

@SaudElabdullah
Does it also happen on version 0.0.2? If so, I will fix this problem.
Thank you.

@santa112358
Yes, It happen in version 0.0.2.
Thank you.

+1 same here.
I spent a long time thinking that this was caused by my own code...
Please fix asap


chore: test:compat to botbuilder-lg

#minor

Pull Request Test Coverage Report for Build 994780514

70 of 75 (93.33%)  changed or added relevant lines in 7 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.02%) to 84.327%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

libraries/botbuilder-lg/src/expander.ts
17
18
94.44%

libraries/botbuilder-lg/src/extractor.ts
0
4
0.0%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build 994516144:
0.02%

Covered Lines:
19633

Relevant Lines:
22087

💛  - Coveralls


NuScenesSSL dataset preparation

Thanks for your excellent work!
However, an error occurs when I run the instructions for preparing the NuScenesSSL dataset. Upon investigation, I found that this might be due to the 'pipeline' parameter being passed as 'None' during the initialization of NuScenesSSL. How can I resolve this issue?
Traceback (most recent call last):
File "tools/create_data.py", line 306, in
nuscenes_data_prep(
File "tools/create_data.py", line 81, in nuscenes_data_prep
create_groundtruth_database(dataset_name, root_path, info_prefix,
File "/home/ps/project/GeoMAE/tools/data_converter/create_gt_database.py", line 238, in create_groundtruth_database
example = dataset.pipeline(input_dict)
File "/home/ps/anaconda3/envs/GeoMAE/lib/python3.8/site-packages/torch/utils/data/dataset.py", line 83, in getattr
raise AttributeError
AttributeError

@ChenGY-THU did you manage to solve the issue?


EvangelistRanker.php

Please apply the concept of Dependency Injection to the rankEvangelist function too.
               throw new NullUserException();
           }```

should not be in the try and catch block because you actually want to throw the error to the developer

DI has been applied


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative-sandbox/channel-wg-leads
/assign knative-sandbox/channel-wg-leads
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/eventing ca9e469...e7445c5:
  > e7445c5 Enable OPTIONS and CloudEvent Webhook headers (# 5542)

/lgtm
/approve


Replace in-tree AppArmor kernel patches

This patch removes the in-tree AppArmor kernel patches for linux 3.2
and 3.4, instead using patches from the apparmor-kernel-patches package.
I have confirmed that the checksums are in fact the same, and
I am able to do map (x: readFile x.patch) linux_3_{2,4}.kernelPatches
and have the patch contents read back to me, which indicates to me that
the builds should work as before.
A possible refinement is to provide a convenience wrapper for accessing
AppArmor kernel patches (in { name = ...; patch = ...; } format), but that
is beyond the scope of what I wanted to do here.
cc @thoughtpolice

Okay, so there's seems to be some breakage after all, but it's not clear to me exactly what's wrong ...

Having looked closer at the travis log, I'm not sure the failure is related to this PR.
I'm seeing
building gitweb.cgi

GEN gitweb.cgi

building decorate.o

CC date.o

tar: Unexpected EOF in archive

tar: Unexpected EOF in archive

building diffcore-break.o

CC decorate.o

building diffcore-delta.o

CC diffcore-break.o

building diffcore-order.o

CC diffcore-delta.o

gcc: internal compiler error: Killed (program cc1)

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

make: *** [archive-tar.o] Error 4

make: *** Waiting for unfinished jobs....

gcc: internal compiler error: Killed (program cc1)

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

make: *** [convert.o] Error 4

gcc: internal compiler error: Killed (program cc1)

and then
tar: Error is not recoverable: exiting now

do not know how to unpack source archive /nix/store/78zlc85xafhy7wndkwk94dznh81506b9-linux-3.2.68.tar.xz

/nix/store/3sqnsignf07mwz12fmi9r4g4vigxg3al-stdenv/setup: line 484: 6462 Killed xz -d < "$fn"

6463 Done | tar xf -

do not know how to unpack source archive /nix/store/78zlc85xafhy7wndkwk94dznh81506b9-linux-3.2.68.tar.xz

builder for ‘/nix/store/qk8dc7acfqyzr1pcyywl6vw98frz20v6-linux-config-3.2.68.drv’ failed with exit code 1

builder for ‘/nix/store/fhwcnml888irzvz2fvl3p5q6gfxf3m0b-linux-headers-3.2.68.drv’ failed with exit code 1

killing process 4998

killing process 7879

error: build of ‘/nix/store/fhwcnml888irzvz2fvl3p5q6gfxf3m0b-linux-headers-3.2.68.drv’ failed

Linux 3.2 at least builds for me, but building all that stuff locally is not feasible for me, so I'm not quite sure how to proceed in debugging this.

Meh nox is really best effort, and half of time produces bad results. I think if checksums are the same, it's should be safe to merge.

Hrm, this looks OK to me, but I wonder if we should even continue supporting 3.2 and 3.4 kernels? I mean, yes, sure, they're LTS, but A) it's unlikely many people use them, B) they can be added back if we delete them before 15.05, and C) in the best case, it just lets us get rid of all this. Kernel 3.5+ has full AppArmor patch support.

Also, our Hydra/kernel configuration doesn't exactly build the slimmest little vmlinux, so I'm sure Hydra would appreciate not having to build the 3.2 and 3.4 kernel a ton of times.

I don't care about older kernels at all (I only want the latest version supported by grsecurity). That said, removing old kernels seems orthogonal to this issue; I intended this to be a functional no-op.
I'm not sure there's too much left to be removed as far as AppArmor patching is concerned, this patch makes it quite cheap and it could easily be made cheaper still.
I'm not sure if its significant, but AppArmor distributes patches for kernels 2.6.36 through 3.12 and for kernels 3.4+ there's a patch for network rule support. If those patches are in there for a reason, I'm not sure its fair to say that 3.5+ has full AppArmor support (I don't use old kernels, though, so I don't know what is actually supported).

I have implemented a first draft of the AppArmor patch convenience wrapper I had in mind here: https://github.com/joachifm/nixpkgs/tree/apparmor-kernel-patches-convenience. With this changeset, you can apply AppArmor patches to any kernel almost for-free (passing them via kernelPatches from the pkgs toplevel). Linux 3.2 and 3.4 exprs are now both more than halved in size. If you like this, I can bake it into this PR.

FWIW, in place of this, I'm simply dropping all older kernels in #7220 and promoting AppAmor 2.9 to stable. I think this is the proper way to go.
Sorry for not responding sooner.

Okay.


Adding video texture.

Awesome project -- just wondering if i'm able to use a video as a texture. Some insight on how to approach this would be great.  Thanks!

React-three-renderer doesn't directly support VideoTexture at the moment.
But you can, as always with missing react-three-renderer features, use plain javascript to achieve what you need.
In this case, you can create your video material in a react event like componentDidMount, then set it to your existing react-three-renderer mesh (a  I guess).
Here is an example (/!\ There are missing parts, like camera, but it's working when complete): http://pastebin.com/z4yqwSkV

The difficult part is that you need to use a canvas (where you store you video image) as your material texture, then update this canvas image on each frame with next video image.
Note: I didn't know you can use video  as texture, thanks for this funny coding session :D

Thanks for the demo - i ended up doing something similar - doing it all with plain JS. However I noticed that three has a VideoTexture method, and didn't need to update.  Basically following this example: https://threejs.org/examples/webgl_video_panorama_equirectangular.html adding a reference to the react element and watching for movement on mobile devices :)


cost-mgmt -> koku-metrics

Codecov Report

Merging #38 (5c3d3a7) into master (aeffde1) will not change coverage.
The diff coverage is 93.18%.

@@           Coverage Diff           @@
##           master      #38   +/-   ##
=======================================
  Coverage   81.26%   81.26%
=======================================
  Files           8        8
  Lines        1078     1078
=======================================
  Hits          876      876
  Misses        142      142
  Partials       60       60

Flag
Coverage Δ

unittests
81.26% <93.18%> (ø)

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

Impacted Files
Coverage Δ

collector/report.go
81.39% <ø> (ø)

controllers/kokumetrics_controller.go
57.19% <85.71%> (ø)

collector/collector.go
87.83% <100.00%> (ø)

collector/prometheus.go
89.71% <100.00%> (ø)

packaging/packaging.go
81.62% <100.00%> (ø)

sources/handler.go
96.49% <100.00%> (ø)

Continue to review full report at Codecov.

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


New version: PDQ.PDQInventory version 19.3.626.0

Created by 🥟 Dumplings.
Microsoft Reviewers: Open in CodeFlow

@wingetbot run


Tested with PCA9548A; No issue found.

Hi @RobTillaart ,
Recently checked out this library with PCA9548A  and working satisfactory.
No major issue detected.
if (!MP.isConnected())
{
MP.reset();
    if (MP.begin() == false)
    {
      Serial.println("MUX  COULD NOT CONNECT");
      return;
    }
  }
  MP.selectChannel(mux_scan_arr[ch].mux_channel);

Thanks for this positive feedback!
What do you mean by the code snippet?
Is there a question?

Is there a question?

No!
It's part of my code; in which I've tested function of library.
Added as reference for any one who might in need.

OK, as there is no problem I'll close the issue.
Thanks again for the positive feedback


Next funding event estimate in taker UI is incorrect in Adelaide

It is calculated based on the heuristics that we are always doing it on the next full hour. The calculation seems to happen in local time, so in Adelaide (+10.30UTC) it is advertising 30min after/before funding event!

Oh my, why would anybody allow timezones with half an hour shift 😅


using package name breaks production loading

instead of
<html>
	<body>
		<script src="/node_modules/steal/steal.production.js"
               main="index.stache!done-autorender"></script>
	</body>
</html>

I had
<html>
	<body>
		<script src="/node_modules/steal/steal.production.js"
               main="bitballs/index.stache!done-autorender"></script>
	</body>
</html>

I think this is fixed in steal-tools 0.11.0-pre.8.  Previously steal-tools was producing bad bundle names when the main is an npm name.
Note that the main in the script tag here should match what is used in pkg.system.main. So if you're using directories.lib both should include the package name.

I will verify.

I'm going to close this because it's how all of our apps are written now.  This is the commit that fixed the issue: https://github.com/stealjs/steal-tools/commit/80f4190240e8b232554f8d26d74e71483d2cac43


How to show uploaded text file content?

I have upload the code here:
           file.upload.then(function (response) {
                $timeout(function () {
                    file.result = response.data;

                    var reader = new FileReader();
                    reader.onload = function(e) {
                       $scope.content = reader.result;
                    }
                    reader.readAsText(file);
                });
            }, function (response) {
                if (response.status > 0)
                    $scope.errorMsg = response.status + ': ' + response.data;
            }, function (evt) {
                file.progress = Math.min(100, parseInt(100.0 *
                                         evt.loaded / evt.total));
            });

but failed to get the file content. What is wrong?

You are using f not file


GoalTracker

I added a goal tracker to the word count. It places a green bar behind the word count to show progress. It is configurable through two settings (a word goal setting, and a color setting).

Thank you for the contribution! I really appreciate it, that folks pick up the tasks and features they want to see in wordcount! That said, I'd love to merge this, but please remove this one newline.
As a addition I'd like to propose a different look of the goaltracker. I this it should be a bit more subtle, like having a extra bat in the wordcount widget, a 90/10 split e.g. I attached a sketch to better transport my idea :pencil2:

I agree that subtly would be nice. Given the size of the panel (at least on my gutter), I worry, however, that by making it 10% of the height, it will not be visible. There's little room between the bottom of the letters and panel, and it would look weird overlapping the bottom part of the letter.
I'll play with it and see what I can do.

Awesome! Looking forward to what you will come up with! We could also make
the font 100% and the bar and userbg-color 90/10 but I assume that might be
a bit complex implementing.
On Sun, Aug 16, 2015 at 10:44 PM, davidfig<EMAIL_ADDRESS>wrote:

I agree that subtly would be nice. Given the size of the panel (at least
on my gutter), I worry, however, that by making it 10% of the height, it
will not be visible. There's little room between the bottom of the letters
and panel, and it would look weird overlapping the bottom part of the
letter.
I'll play with it and see what I can do.
—
Reply to this email directly or view it on GitHub
https://github.com/nesQuick/atom-wordcount/pull/38#issuecomment-131619261
.

More work than I expected, but the height of the line is now configurable. I decided against the color gradient in your drawing since it's hard to know what percentage to assign to each of the colors, and making it user configurable likely would be confusing.

Yeah! I like it very much! Last though: I think making it configurable just adds more complexity then needed to the config, I like the 20, why not just setting it to 20? :)

I agree on the added complexity, but I actually like it at 100%, which is why I decided to make it configurable so we'd both be happy :)

Alright, I see your point then. Let's see how many more options will pop up and when it become too cluttered this might change. Let;s get this in and bump a version. Thanks for helping out here!

just published 2.3.0
λ  atom-wordcount git:(master) apm publish minor
Preparing and tagging a new version ✓
Pushing v2.3.0 tag ✓
Publishing<EMAIL_ADDRESS>✓

:tada:


Update to Smithy 1.27.0

Describe the feature
The Smithy team recently released 1.27.0 which includes breaking changes.  We are currently locked on 1.26.4.
Update the app as needed so that Smithy 1.27.0+ can be integrated.
Use Case
To support latest Smithy features
Proposed Solution
No response
Other Information
No response
Acknowledgements

[ ] I may be able to implement this feature request
[ ] This feature might incur a breaking change

This kind of issues go to oncall.