Merge

Codecov Report
Attention: Patch coverage is 74.90196% with 64 lines in your changes are missing coverage. Please review.

Project coverage is 77.32%. Comparing base (360048b) to head (6f3de9f).
Report is 31 commits behind head on master.

Files
Patch %
Lines

...u/address/storage/JsonSerializableAddressBook.java
5.88%
16 Missing :warning:

...classcommands/AddStudentToClassByIndexCommand.java
52.00%
11 Missing and 1 partial :warning:

...eedu/address/storage/JsonAdaptedTutorialClass.java
52.17%
10 Missing and 1 partial :warning:

...s/logic/parser/AddStudentToClassCommandParser.java
66.66%
4 Missing and 4 partials :warning:

.../java/seedu/address/storage/JsonAdaptedModule.java
50.00%
4 Missing and 1 partial :warning:

src/main/java/seedu/address/model/AddressBook.java
85.71%
2 Missing and 2 partials :warning:

...java/seedu/address/model/module/TutorialClass.java
66.66%
2 Missing :warning:

...a/seedu/address/logic/messages/ModuleMessages.java
0.00%
1 Missing :warning:

...a/seedu/address/logic/messages/PersonMessages.java
0.00%
1 Missing :warning:

.../address/logic/messages/TutorialClassMessages.java
0.00%
1 Missing :warning:

... and 3 more

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master      #15      +/-   ##
============================================
- Coverage     77.89%   77.32%   -0.57%
- Complexity      585      637      +52
============================================
  Files            94      101       +7
  Lines          1764     1958     +194
  Branches        171      198      +27
============================================
+ Hits           1374     1514     +140
- Misses          348      393      +45
- Partials         42       51       +9

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


Center the Calendar to the Current Week

The HG calendar doesn't move to the current week, which can be a bit inconvenient or confusing.
We should explore it's it's possible to automatically center / jump the calendar to the current date / week? Maybe with https://fullcalendar.io/docs/Calendar-gotoDate

Perhaps the solution to auto-center / jump to the current day and week while in the dayGridMonth view is more like this solution
https://stackoverflow.com/a/48100619

@all-contributors please add @MhdGhaithAlhelwany for code

@all-contributors please add @MhdGhaithAlhelwany for code

Reopening as Bogdan found in #261 that the Next and Previous buttons stopped working.

@allella should we close this now?

Was something re-implemented?  Having it center on the current week would still be nice.

@allella I can take this on if you want. Do you just want it scrolled into view on page load?

It just seems like centering / focusing on the current week would be a nice improvement.  Though, it's not a critical feature if it's going to be hard.
We had a PR that did the job, but it wouldn't uncenter when next or previous arrows were clicked, so we rolled that PR back.

So is the summary of the desired behavior...

Scroll to current on page load
Reset to top on next/previous
Only do this on the month view

If so, that doesn't sound like it'll be too hard.
I saw your note on a function Fullcalendar may have built in. If that doesn't work out, I know roughly how to do this vanilla.

@JSn1nj4 yes that sounds good.


adding hybridization change filter

This PR adds a filter for hybridization_changes of atoms, disallowing them.

[ ] general hybridization changes
[ ] ring hybridization changes.

Hello @RiesBen! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file src/kartograf/filters/element_change.py:

Line 57:80: E501 line too long (80 > 79 characters)
Line 68:28: W292 no newline at end of file

In the file src/kartograf/tests/test_element_filters.py:

Line 42:1: E302 expected 2 blank lines, found 1

@richardjgowers yes that is a very important change even. but we would need to check the all ring atoms, I think. Therefore this would be a ring -change filter.


Add support for notes in TypeScript files

@fgrehm please take a look

Thank you! Pushed newest version to rubygems.


[DROOLS-1055] Fix ClassCastException when running with Fuse 6.2.1 (bl…

…ueprint-core 1.4.4)

@psiroky mind that I'm only fixing particular bug in Fuse, I don't know the big picture of drools/jbpm/brms

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.

ok to test

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.

ok to test

+1 to merge. There is no test, but as uncovered by @grgrzybek all the current tests are disabled (yikes), because they are failing (likely test setup issue). I will first need to fix those. Then we can take a look at adding specific test case for this case.
I will merge this shortly.


Update code in README.md

Hi again! The merged README code is still linked to my fork when it really should be linked to yours.

Thank you!

You might also want to update the description on the main page :P


Bugfix introduced into bb08fe8113e37a6a44dc3ab4ca64fcf8a3ec200e

This is work on Pull Request #803 and help of @johanhammar and @fewieden

Great, then maybe we can close/decline #803?
I would really like to add a test for this but am finding it hard to mock moment.js.

Sometimes It's really hard work with dates in Javascript ;)
I think the good approach will be create a new pull request with test for that. I'll can help you with that.
For other hand, there are a stranger behavior I mentioned in review https://github.com/MichMich/MagicMirror/pull/803#pullrequestreview-30370685

Hi @johanhammar
There something weird for this case if we use moment-timezone in the test suite. You can see more information about this in

https://forum.magicmirror.builders/post/19276
https://forum.magicmirror.builders/post/19279

If you are interested to push on something on this will be great

I'll take a look at this later this week

Hi @roramirez
There seems to be a problem with the moment module  which doesn't seem to load correctly. I don't know the details of how modules are loaded (especially when running tests).
I've attached a screenshot showing moment not beeing loaded when running the test.

Hi @johanhammar
Are you setting nodeIntegration ?
For me this  is the stranger case, if I set nodeIntegration give me the same error like you show in the picture before.


Get remaining GNU test cases from ERROR to at least FAIL

From https://github.com/uutils/coreutils-tracking/blob/main/gnu-full-result.json, here are the remaining GNU test cases that are marked as ERROR (as opposed to FAIL, PASS, or SKIP):

[x] tests/cp/cp-parents.sh - see #3332, #3894, #4071
[x] tests/cp/preserve-slink-time.sh - see #3364, #3531
[x] tests/cp/sparse-extents.sh - see #3362
[x] tests/cp/sparse.sh - see #3362
[x] tests/dd/no-allocate.sh - see #3321
[x] tests/ls/nameless-uid.sh - see #3380
[ ] tests/misc/csplit-io-err.sh - see #2925
[x] tests/misc/shuf.sh - see #3329
[x] tests/misc/usage_vs_getopt.sh
[x] tests/split/filter.sh - see #3281
[ ] tests/tail-2/inotify-rotate-resources.sh - implemented in pull request #2695 but errors due to https://github.com/uutils/coreutils/blob/702a0b7a34b60a81e3fc1cf5423e9902e5cb3c13/src/uu/tail/README.md?plain=1#L35-L38

It would nice to get them from ERROR to at least FAIL.

Great idea! thanks

I updated the tests/tail-2/inotify-rotate-resources.sh item with comments from a recent pull request that implemented the missing behavior.

I marked some more items as completed. There are now five remaining tests in the ERROR state.

tests/cp/cp-parents.sh is now no longer in the ERROR state due to #4071.

and tests/split/filter.sh is also no longer in the ERROR state due to #3281

tests/dd/no-allocate.sh is no longer ERROR (now in FAIL state) due to #4164

Wow we're getting close on this one! Nice work!

Closing this ticket as the two remaining test cases in the list above are no longer marked ERROR: csplit-io-err.sh is SKIP and inotify-rotate-resources.sh is FAIL.

Fantastic! Thanks all


Fix the test data reference set checksum

This is computed as MD5("90977a37195d3fd247e4916b5b4cbae8") per the documentation.

Sorry, I intended to fork my own repo, forgot I had branch creation rights here. I'll fix that later tonight unless this gets merged before then.

Closing in favor of #80.


Add Dual Function Keys Package

Project description
A plug-in for interception tools. Helps configure things like utilizing capslock as both escape on release and control when held. Helpful for Wayland users in particular.
Metadata

homepage URL: https://gitlab.com/interception/linux/plugins/dual-function-keys
source URL: https://gitlab.com/interception/linux/plugins/dual-function-keys
license: mit.
platforms: Linux

It's already there, was added in https://github.com/NixOS/nixpkgs/pull/94097 :)

Okay, weird. I thought that all packages would show up on https://search.nixos.org/, but a search for "dual-function-keys" yields "no packages found". Moreover, nix-env won't resolve "nix-env -iA nixpkgs.dual-function-keys", but it will resolve "nix-env -iA nixpkgs.interception-tools-plugins.dual-function-keys". The only way I was able to figure out how to install the package was by looking at https://raw.githubusercontent.com/NixOS/nixpkgs/master/pkgs/top-level/all-packages.nix . So I guess I should open an issue at https://github.com/NixOS/nixos-search/issues ?

Ah no, the problem is that in all-packages.nix the definition of interception-tools-plugins needs a recurseIntoAttrs to expose nested packages:
-  interception-tools-plugins = {
+. interception-tools-plugins = recurseIntoAttrs {
    caps2esc = callPackage ../tools/inputmethods/interception-tools/caps2esc.nix { };
    dual-function-keys = callPackage ../tools/inputmethods/interception-tools/dual-function-keys.nix { };
  };

Ah, Okay. Can you commit the change to https://raw.githubusercontent.com/NixOS/nixpkgs/master/pkgs/top-level/all-packages.nix ?

I'm a bit short on time, I'd appreciate it if you could make a PR for that, I can review and merge it if you ping me :)


Limit check to virtualMachines and virtualMachineScaleSets

Currently the check will trigger a false positive if a variable or parameter is named 'storageProfile'.  Add a check to filter the results from Find-JsonContent to only include nodes where the parent object is a VM or VMSS.  Testing done: Tested script locally with vm and vmss templates manually modified to include "-preview" in the version field.  This might introduce a limitation of not finding cases where a variable named 'storageProfile' is defined and actually contains an 'imageReference', which is later used as the value for the 'storageProfile' field of a VM or VMSS.  This should also address https://github.com/Azure/arm-ttk/issues/122 which I'm guessing is happening because the prereq template for the HDI cluster includes a storageProfile property (https://github.com/Azure/azure-quickstart-templates/blob/master/101-machine-learning-compute-attach-hdi/prereqs/prereq.azuredeploy.json#L197) as will any other template that deploys HDInsight.

#122 - thanks Rick... also added a test case for this ;)


Unable to use Heldion 2.0 built-in health-check

Im trying to get the build-in health checks to work in my microprofile projectby including the following in my build.gradle file :
implementation platform("io.helidon:helidon-dependencies:${project['io.helidon.version']}")
implementation 'io.helidon.microprofile.bundles:helidon-microprofile-core'
implementation 'io.helidon.microprofile.tracing:helidon-microprofile-tracing'
implementation 'io.helidon.health:helidon-health-checks'
implementation 'io.helidon.tracing:helidon-tracing-jaeger'

Note - (io.helidon.version = 2.0.1)
When I try and start the service using just Server.create().start(); then I encounter two WELD-001408: Unsatisfied dependencies

Helidon Version: 2.0.1
Helidon MP
JDK version: 11
OS: Windows
Docker version (if applicable):

Problem Description
Full startup stacktrace:
Listening for transport dt_socket at address: 5002
aug. 18, 2020 3:20:47 PM io.helidon.common.LogConfig doConfigureLogging
INFO: Logging at initialization configured using defaults
2020-08-18 15:20:48,362 [INFO] [:No Correlation ID] org.jboss.weld.Version Thread[main]: WELD-000900: 3.1.3 (Final)
2020-08-18 15:20:49,463 [INFO] [:No Correlation ID] org.jboss.weld.Bootstrap Thread[main]: WELD-ENV-000020: Using jandex for bean discovery
2020-08-18 15:20:49,805 [INFO] [:No Correlation ID] org.jboss.weld.Bootstrap Thread[main]: WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
2020-08-18 15:20:50,039 [INFO] [:No Correlation ID] org.jboss.weld.Event Thread[main]: WELD-000411: Observer method [BackedAnnotatedMethod] public org.glassfish.jersey.ext.cdi1x.internal.ProcessAllAnnotatedTypes.processAnnotatedType(@Observes ProcessAnnotatedType<?>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
2020-08-18 15:20:50,804 [INFO] [:No Correlation ID] org.jboss.weld.Bootstrap Thread[main]: WELD-ENV-002001: Weld SE container fbd4abf2-6fd3-4a55-9fbf-f3ea48c4e382 shut down
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException: Exception List with 2 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Runtime with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject io.helidon.health.checks.HeapMemoryHealthCheck(Runtime, @ConfigProperty double)
  at io.helidon.health.checks.HeapMemoryHealthCheck.<init>(HeapMemoryHealthCheck.java:0)

        at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
        at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
        at org.jboss.weld.executor.CommonForkJoinPoolExecutorServices.lambda$wrap$0(CommonForkJoinPoolExecutorServices.java:70)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1448)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
Exception 1 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ThreadMXBean with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject io.helidon.health.checks.DeadlockHealthCheck(ThreadMXBean)
  at io.helidon.health.checks.DeadlockHealthCheck.<init>(DeadlockHealthCheck.java:0)

        at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
        at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
        at org.jboss.weld.executor.CommonForkJoinPoolExecutorServices.lambda$wrap$0(CommonForkJoinPoolExecutorServices.java:70)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1448)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

        at org.jboss.weld.bootstrap.ConcurrentValidator.validateBeans(ConcurrentValidator.java:72)
        at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:487)
        at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:496)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:93)
        at io.helidon.microprofile.cdi.HelidonContainerImpl.doStart(HelidonContainerImpl.java:293)
        at io.helidon.common.context.Contexts.runInContext(Contexts.java:118)
        at io.helidon.microprofile.cdi.HelidonContainerImpl.start(HelidonContainerImpl.java:245)
        at io.helidon.microprofile.cdi.Main.main(Main.java:80)
        Suppressed: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Runtime with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject io.helidon.health.checks.HeapMemoryHealthCheck(Runtime, @ConfigProperty double)
  at io.helidon.health.checks.HeapMemoryHealthCheck.<init>(HeapMemoryHealthCheck.java:0)

                at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
                at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
                at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
                at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
                at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
                at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
                at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
                at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
                at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
                at org.jboss.weld.executor.CommonForkJoinPoolExecutorServices.lambda$wrap$0(CommonForkJoinPoolExecutorServices.java:70)
                at java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1448)
                at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
                at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
                at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
                at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
                at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
        Suppressed: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ThreadMXBean with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject io.helidon.health.checks.DeadlockHealthCheck(ThreadMXBean)
  at io.helidon.health.checks.DeadlockHealthCheck.<init>(DeadlockHealthCheck.java:0)

                at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
                at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
                at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
                at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
                at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
                at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
                at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
                at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
                at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
                at org.jboss.weld.executor.CommonForkJoinPoolExecutorServices.lambda$wrap$0(CommonForkJoinPoolExecutorServices.java:70)
                at java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1448)
                at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
                at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
                at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
                at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
                at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

Issue is easy to reproduce.

Create a Helidon 2.0 project using JDK 11
Include the implementations I showed in the top in the build.gradle file
Start the service

Can you confirm this issue, or how to fix it please?
Kind regards
Bogedal

Short answer:
Replace implementation 'io.helidon.health:helidon-health-checks' with implementation 'io.helidon.microprofile.health:helidon-microprofile-health. helidon-health-checks is support for some built-in health checks -- not the MicroProfile support.
Long answer:
Helidon provides two bundles for MicroProfile support:

helidon-microprofile-core: this provides just basic MicroProfile support (JAX-RS, CDI, JSON, and MicroProfile config)
helidon-microprofile: this has everything

So an alternate solution would be do change your helidon-microprofile-core dependency to helidon-microprofile`.
If you use -core then you need to add the additional MicroProfile dependencies explicitly. So you would add dependencies like:
    implementation 'io.helidon.microprofile.health:helidon-microprofile-health'
    implementation 'io.helidon.microprofile.openapi:helidon-microprofile-openapi'
    implementation 'io.helidon.microprofile.metrics:helidon-microprofile-metrics'

And another tweak on build.gradle: change  implementation platform to  implementation enforcedPlatform. We have a bug in our example build.gradle files that's getting fixed in the next release. You can see the latest version here: https://github.com/oracle/helidon/blob/master/examples/quickstarts/helidon-quickstart-mp/build.gradle

@barchetta Thanks a lot for your reply
I've tried to implement your suggestions but encountered a small issue
My build.gradle now looks like this :
    implementation enforcedPlatform("io.helidon:helidon-dependencies:${project['io.helidon.version']}")
    implementation 'io.helidon.microprofile.bundles:helidon-microprofile-core'
    implementation 'io.helidon.microprofile.tracing:helidon-microprofile-tracing'
    implementation 'io.helidon.microprofile.health:helidon-microprofile-health'
    implementation 'io.helidon.microprofile.metrics:helidon-microprofile-metrics'
    implementation 'io.helidon.microprofile.openapi:helidon-microprofile-openapi'
    implementation 'io.helidon.tracing:helidon-tracing-jaeger'

However this seems to break CDI as I get a nullpointer exception in my application.java file.
I have a custom made Environment class that is injected in application class which now is null.
I breaktracked the issue to occur with I add the dependency to 'io.helidon.microprofile.openapi:helidon-microprofile-openapi'
If I omit that then the service replies OK to both /metrics and /health also the service functions as expected.

@bogedal I'm curious if changing the helidon-microprofile-core dependency to helidon-microprofile changes the behavior. This would narrow down if this is a dependency issue or something else. In any case, if you have a small reproducer that would help.

@barchetta If I just use
    implementation enforcedPlatform("io.helidon:helidon-dependencies:${project['io.helidon.version']}")
    implementation 'io.helidon.microprofile.bundles:helidon-microprofile'
    implementation 'io.helidon.tracing:helidon-tracing-jaeger'

The issue is the same.
I'll try and create a small service to reproduce the issue. I'll get back to you again shortly

@barchetta I've create a sample project which shows the same issue as above
helidon-2-possible-cdi-issue.zip
Hope this can help track down the issue.

Thanks for the reproducer, and sorry for not getting back to you sooner. The NPE problem looks like a bug in either our OpenAPI support, or our CDI support. I've created a new issue to track it: #2324 .
The issue is that our OpenAPI support performs application scanning during CDI initialization. Looks like it performs that scanning before Injection points have been resolved -- so if your getClasses() method uses an injection point it will be null.
Later during actual loading of your JAX-RS Application, your getClasses() method is called again -- but this time the injection points have been resolved so it works as expected.
The work-around is to code your getClasses() method to deal with this early scanning where injection points might be null.
I'm going to close this issue since the original problem (using health check in a gradle project) has been resolved. See #2324 to track the null injected field  issue.


FakeScheduler changes have made tests flaky again :(

I believe this is because of the way we change the clock at the end of the inner loop, but I'll need to check the tests. (Of course, it doesn't happen locally...)

Fixed by #284.


Need an automated testing system

Should develop a CO capsule that tests the timing of relevant events in the task and looks for any discrepencies from expectation. @ZhixiaoSu want to take a stab at this?

Good point! We really should make sure events are synced. Depending on what we want to start with, I now have code for:

Testing alignment between camera time and behavior time;
Testing alignment between ephys time and behavior time by comparing lick artifact time.
However, these are not enough yet for testing the sync. And more importantly, we don't have a sync test yet. We need to decide:
What we want to test? (camera, ephys, lick sensors, solenoid, .etc)
How often we what to check the sync? (regular daily check or everytime after major change, maybe different schedule for different parts?)
Do we check the sync using daily behavior data or perform specialized 'sync test'? (Depending on 1 and 2)

How about discussing this in our next meeting? (software meeting maybe?) I can come up with a draft of proposal by then. And I think this probably will need a team effort of hardware + behavior control + analysis capsule. (Maybe also RA's effort if we need to do some simple regular check. )

Good point! We really should make sure events are synced and have expected distribution of time. Depending on what we want to start with, I have some draft code for:

Testing alignment between camera time and behavior time;
Testing alignment between ephys time and behavior time by comparing lick artifact time.
Check distribution of some intervals. (ITI, etc)

However, these are not enough yet for testing the sync + relevant timing.
For the sync part, we need to come up with a test first, for example:

What we want to test? (camera, ephys, lick sensors, solenoid, .etc)
How often we what to check the sync? (regular daily check or everytime after major change, maybe different schedule for different parts?)
Do we check the sync using daily behavior data or perform specialized 'sync test'? (Depending on 1 and 2)

How about discussing this in our next meeting? (software meeting maybe?) I can come up with a draft of proposal by then. And I think this probably will need a team effort of hardware + behavior control + analysis capsule. (Maybe also RA's effort if we need to do some simple regular check. )
And for relevant timing distribution, how do you think of plugging in some basic quality check into the Streamlit app?

Thanks for taking charge of this @ZhixiaoSu. I added a discussion point to the agenda for the next software meeting (05/13). A proposal by then would be great. It would be good to think about (1) what we want to test, (2) how often, (3) who does the testing (automated, RAs, scientists, etc), (4) where relevant testing code runs/lives (on the rigs, CO, streamlit)
@bruno-f-cruz mentioned that some testing could be common to all tasks if we (1) have standard logging practices for Harp messages, (2) have common task elements. For example, lick sensors or solenoids should have common testing code, but internal task timing elements should probably be task specific. You should touch base with him, and assume we agree/implement a standard harp logging practice in the short term future.

I can come up with a proposal by next Monday! I think it will be more like a proposal of discussion since we first need to define the task and thus figure out its scale, which I think should be the goal of the discussion. I'll consult Bruno first to make sure I don't miss important parts.

My preference is to solve this more holistically by coming up with a standard for video data collection. We can start by discussing the current implementations and what quality control checks should be in place, but we should make something that leverages a common standard so everyone can use it.

@ZhixiaoSu Did you create a proposal for testing things like task events? It seems like video data is being handled separately.


FE-377 | Make Explain button position more prominent

This PR ensure the Explain button for the query editor is in a prominent place.

Moves Create Debug Packages button  to the top bar
Moved Remove all Results button near the results sections

Screenshot

@palashkaria Do I push the build artifacts?


error: command 'x86_64-linux-gnu-gcc' failed with exit status 1, Please help

I was installing the Nvidia/apex particular tree branch by doing this on colab.
%%writefile setup.sh
git clone -q https://github.com/NVIDIA/apex.git
cd apex
git reset --hard 1603407bf49c7fc3da74fceb6a6c7b47fece2ef8
cd ..
pip install -v --no-cache-dir --global-option="--cpp_ext" --global-option="--cuda_ext" ./apex
I'm getting this whole error:
though this problem with particular branch, if I install the master branch it is getting installed.
.....
csrc/scale_check_overflow.cpp:14:3: note: in expansion of macro ‘AT_CHECK’
AT_CHECK(grads.type().is_cuda(), "grads must be a CUDA tensor");
^
.....
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
Running setup.py install for apex ... error
Cleaning up...
Removing source in /tmp/pip-req-build-wmagyiis
Removed build tracker '/tmp/pip-req-tracker-9l2sbkhe'
ERROR: Command errored out with exit status 1: /usr/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-req-build-wmagyiis/setup.py'"'"'; file='"'"'/tmp/pip-req-build-wmagyiis/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' --cpp_ext --cuda_ext install --record /tmp/pip-record-dmtu3t6t/install-record.txt --single-version-externally-managed --compile Check the logs for full command output.
Exception information:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/pip/_internal/cli/base_command.py", line 153, in _main
status = self.run(options, args)
File "/usr/local/lib/python3.6/dist-packages/pip/_internal/commands/install.py", line 455, in run
use_user_site=options.use_user_site,
File "/usr/local/lib/python3.6/dist-packages/pip/_internal/req/init.py", line 62, in install_given_reqs
**kwargs
File "/usr/local/lib/python3.6/dist-packages/pip/_internal/req/req_install.py", line 888, in install
cwd=self.unpacked_source_directory,
File "/usr/local/lib/python3.6/dist-packages/pip/_internal/utils/subprocess.py", line 275, in runner
spinner=spinner,
File "/usr/local/lib/python3.6/dist-packages/pip/_internal/utils/subprocess.py", line 242, in call_subprocess
raise InstallationError(exc_msg)
pip._internal.exceptions.InstallationError: Command errored out with exit status 1: /usr/bin/python3 -u -c 'import sys, setuptools,

Hi @yash04singh ,
https://stackoverflow.com/questions/26053982/setup-script-exited-with-error-command-x86-64-linux-gnu-gcc-failed-with-exit/35164888


Revert "Automated cherry pick of #11877"

/release-note-none

/e2e-test

Successfully triggered E2E testing!
GitLab pipeline | Test dashboard


move ucsCallback to north bound from south bound

@anhou @pengz1

You can keep this callback API for both southbound and northbound API.


chore: upgrade jenkins-x/jx3-versions to version 1.0.10

from: https://github.com/jenkins-x/lighthouse.git

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign daveconde
You can assign the PR to them by writing /assign @daveconde in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

gsm
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

gsm
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm

kube
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

gsm
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm

kube
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test kube

vault
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

gsm
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm

vault
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test vault

kube
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

gsm
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm

kube
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test kube

vault
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

kube
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test kube

vault
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test vault

gsm
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test kube

vault
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test vault

gsm
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm

gsm-kapp
b11cb44a2617b21f2f6d3ba9e57df6eb11412438
link
/test gsm-kapp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.


Dev postgres

For others to look at and add upon.

To test: create heroku app first
save the heroku config var DATABASE_URL in env variable (done automatically in script)
need to save vault password into heroku config var (will not be prompted when running on heroku)

Is there any special significance to the env var name DATABASE_URL? I.e. is it a reserved env variable name, or does Heroku do something special with this particular env variable that it wouldn't be able to do with other env variables?

env var name DATABASE_URL doesn't hold any significance. In local machine, the env variable can be anything. However, to clarify, the config var for postgres URI for heroku will always be DATABASE_URL. The reason why they may match is to maintain consistency , but you can change it to your convenience.

OK I see what's happening, Heroku auto-populates an env variable called DATABASE_URL after you add the Postgres add-on to an app instance. That's what I meant by special significance, sorry for being unclear.
The reason the special significance matters is because we have a system already for the environment variables prefixed POSTGRES_*, but clearly Heroku does something slightly different. I looked into it a bit more, and I learned that there is a concept in Heroku called heroku stack, and you can set it to be either heroku stack:set heroku-18 and another way that's like heroku stack:set container. The container system takes two different approaches for deployment, the container registry or the "manifest" approach. Etc. Right now we are doing heroku-18, which avoids explicit containerization.
Why's that all matter? The reason is because I was taking the POSTGRES_* config settings style from an open-source project here: https://github.com/cburmeister/flask-bones I figured if it works for them then it should work for us. However, they're deploying using the container registry, which we won't be doing. Which means this config style isn't great for us.
I think your solution to it is fine for now, although in the future we may want to consider consolidating everything a bit since right now the config can have values in it that seem contradictory. You don't need to worry about that though.

Also, I should have clarified that part of the requirements would be to clarify any steps like adding add-ons etc. but I figured it out. (if you think I'm bad at Heroku for not figuring out that first step immediately, the CRWA will also struggle with it...) Later we will have to add the thing about which add-ons to attach that as part of our deployment documentation.

I have your code "working" in the sense that the database is created on Heroku, but right now the database is blank for me. Are you experiencing the same thing there? If so, how do you suppose we initiate the database?
One idea I have is to create a function called database_is_empty(db) that runs really quickly to check to see if the database is empty, and then we can do the following in the create_app() function:
from .data.database import database_is_empty

# ...

def create_app( ... ) -> Flask:

    # ...

    if database_is_empty(db):
        from .data.database import init_db
        init_db()

(We don't want to re-init the database each time the app fires up because due to how Heroku works, it ends up running the create_app() function after every snooze).
That said, I would slightly prefer a solution that uses the Procfile or something like that to initiate the database schema.

Ok sure. I will take a look into automating the init-db so CRWA don't need to go to heroku cli. I will look into saving the password into heroku config vars so that they don't need to remember the password nor exporting the password into heroku config vars.

To clarify, we just need a process to set up and populate the database's tables at all using init_db() in some capacity, whether it's run in the code itself or via the CLI. If it involves using the Heroku CLI then that's fine. It just needs to be easy, replicable, robust, and it needs to not run more than once (or at least not run synchronously with GET requests to the website) so that we don't slow down the website.
Also, that method of running init_db() in Heroku needs to be documented somewhere. Even if it's just a comment here in the PR on how you were able to run init_db() in Heroku, then that's fine.
Were you able to get the database populated? For me following your directions a database existed, but it was blank (no tables whatsoever) because init_db() was not run in the live version (which means in turn schema.sql and the boathouses query were not run.) If your version of the integration server had the populated database, can you clarify how you did it?

There are no issues related to any passwords that need additional work in this issue. The DATABASE_URL contains the password. The URL schema for any Postgres database is postgres://user:pass@host:port/db. So long as Heroku gives you a valid database URL-- and it does-- then this is not a concern. The main concern I was conveying was that the POSTGRES_* values in the Config are not used and may contradict with the DATABASE_URL, which is overall a minor concern but it does make the code more confusing. But I would not focus on that.

I haven't been clear in the issues page but I had to run init_db command in order to create the schemas inside the database. Perhaps it is different in the recent version of this code so I will have to check again.

Never mind on the last part of this request, I found out a pretty decent system for getting the database up and running!


Prometheus failing to start.

I have just deployed a fresh swarm using the docker CE cloudformation template, followed by Traefic (https://dockerswarm.rocks/traefik/) then swarmprom. I have followed the guides exactly, and have the latest version of this repository.
All the containers come up with the exception of prometheus which seems to have some issues around locking the /prometheus directory.
12:00:16
level=info ts=2019-04-01T12:00:16.488751312Z caller=main.go:431 msg="Stopping scrape discovery manager..."
12:00:16
level=info ts=2019-04-01T12:00:16.48884943Z caller=main.go:445 msg="Stopping notify discovery manager..."
12:00:16
level=info ts=2019-04-01T12:00:16.488903369Z caller=main.go:467 msg="Stopping scrape manager..."
12:00:16
level=info ts=2019-04-01T12:00:16.488974076Z caller=main.go:441 msg="Notify discovery manager stopped"
12:00:16
level=info ts=2019-04-01T12:00:16.490750149Z caller=web.go:399 component=web msg="Start listening for connections" address=<IP_ADDRESS>:9090
12:00:16
level=info ts=2019-04-01T12:00:16.508059116Z caller=main.go:427 msg="Scrape discovery manager stopped"
12:00:16
level=info ts=2019-04-01T12:00:16.513500817Z caller=manager.go:657 component="rule manager" msg="Stopping rule manager..."
12:00:16
level=info ts=2019-04-01T12:00:16.513604072Z caller=manager.go:663 component="rule manager" msg="Rule manager stopped"
12:00:16
level=info ts=2019-04-01T12:00:16.513669156Z caller=notifier.go:512 component=notifier msg="Stopping notification manager..."
12:00:16
level=info ts=2019-04-01T12:00:16.513742797Z caller=main.go:616 msg="Notifier manager stopped"
12:00:16
level=info ts=2019-04-01T12:00:16.517522311Z caller=main.go:461 msg="Scrape manager stopped"
12:00:16
level=error ts=2019-04-01T12:00:16.523471029Z caller=main.go:625 err="opening storage failed: lock DB directory: open /prometheus/lock: permission denied"

I have the same error.
I suspect that the file permissions are not set correctly on the volumes binded to /prometheus.
Which user id shoudl i give full authorization to this folder ?

Prometheus is using nobody user. This should solve your problem: chown nobody:nogroup /prometheus/


remove references to reminder.dashboard in frontend

Description
also reorganized the admin dashboard a little

Testing

Please briefly note how you tested and verified your changes.

Reviewers

Tag one or two teammates to review your code. Ideally, you should tag people who have worked on the same files or similar features to notify them of your changes. If you pair programmed with someone, please indicate that here as well.

perf


Dashboard-Profile Creation failing

Click Profile Menu
Fill Fields in Create Volume Page
Click Submit
502 Bad Gateway error coming..

I think the latest code works fine for issues you mentioned, could u take a check?

Issue is with the nginx mapping

@satya-gorli Please test this with the latest code and let us know if the issue persists.
502 errors are usually encountered on a bad network connection, overloaded network or when the osdsapiserver is not running.

Latest its working fine


import should not be in the list of /ve/kontainerenginedrivers as a driver

will let nathan figure out the details

We want import driver removed from the kontainer driver resources because it makes building the UI difficult.  We need to find the best way to remove this driver or else hide it from view, while still making imported clusters work.

This change is removing the import driver from the kontainer drivers /v3/kontainerdrivers endpoint in Rancher API.  It should no longer be listed or accessible at that endpoint.  Importing clusters should still work as normal.

Observed in older master before the fix and observed that import driver was present in /v3/kontainerdrivers as below:
{
"actions": {
"deactivate": "…/v3/kontainerDrivers/import?action=deactivate"
},
"active": true,
"actualUrl": "",
"annotations": {
"lifecycle.cattle.io/create.mgmt-kontainer-driver-lifecycle": "true"
},
"baseType": "kontainerDriver",
"builtIn": true,
"checksum": "",
"conditions": [ 2 items
{
"lastUpdateTime": "2019-02-21T21:41:33Z",
"status": "True",
"type": "Downloaded"
},
{
"lastUpdateTime": "2019-02-21T21:41:33Z",
"status": "True",
"type": "Installed"
}
],
"created": "2019-02-21T21:41:32Z",
"createdTS":<PHONE_NUMBER>000,
"creatorId": null,
"executablePath": "",
"id": "import",
"labels": {
"cattle.io/creator": "norman"
},
"links": {
"self": "…/v3/kontainerDrivers/import",
"update": "…/v3/kontainerDrivers/import"
},
"name": "import",
"state": "active",
"transitioning": "no",
"transitioningMessage": "",
"type": "kontainerDriver",
"uiUrl": "",
"url": "",
"uuid": "749db967-3621-11e9-b009-0242ac110002"
},

Tested with master from Feb 22nd. Observed that /v3/kontainerdrivers did not have an entry for import driver.
Also, tested importing cluster and it was functional.


Inline block with a relationship field (that contains a rich-text ) is not working

Link to reproduction
https://github.com/shefing/payload_Inline_block_with_relationship/tree/Inline_block_with_relationship
Environment Info
Output from 'pnpm payload info':
Binaries:
Node: 20.9.0
npm: 10.2.5
Yarn: 1.22.21
pnpm: 9.10.0
Relevant Packages:
payload: 3.0.0-beta.104
next: 15.0.0-canary.104
@payloadcms/db-mongodb: 3.0.0-beta.104
@payloadcms/graphql: 3.0.0-beta.104
@payloadcms/live-preview: 3.0.0-beta.104
@payloadcms/next/utilities: 3.0.0-beta.104
@payloadcms/plugin-cloud-storage: 3.0.0-beta.104
@payloadcms/plugin-redirects: 3.0.0-beta.104
@payloadcms/plugin-seo: 3.0.0-beta.104
@payloadcms/richtext-lexical: 3.0.0-beta.104
@payloadcms/storage-s3: 3.0.0-beta.104
@payloadcms/translations: 3.0.0-beta.104
@payloadcms/ui/shared: 3.0.0-beta.104
react: 19.0.0-rc-06d0b89e-20240801
react-dom: 19.0.0-rc-06d0b89e-20240801
Describe the Bug
When creating an inline-block with a relationship field to a collection that contains a rich-text field,
The following scenario is problematic:
When inserting the inline-block and clicking the '+' button of the relationship field - the new instance of the collection that is created has disabled rich-text field.
Reproduction Steps
Steps to reproduce:

Clone the link to reproduction ripo and launch Payload
Create a new Post instance
Add the inline-block in the rich-text field
In the pop-up window click on the '+' of the relationship field
Go to the rich-text field in the new Post opened
Try to type

Expected:
Rich-text field is responsive
Actual:
Rich-text field is disabled
Adapters and Plugins
db-mongodb

Looks like it was resolved in latest version @ChannKan you can close it


Improve error handling on deploy

Issue To Be Solved
As pointed out by community members we should provide better feedback when project deploy fails. Now there is only an error the deployment was not successful.
Suggest A Solution
An error should be shown to the user when the deployment fails. This should be already solved by #104

Solved in #104


fix: fix for connection state and selection state not propagating to the Toolbar INTELLIJ-96

Description

Checklist

[ ] New tests and/or benchmarks are included.
[ ] Documentation is changed or added.
[ ] Changelog is updated accordingly.
[ ] I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement).

Open Questions

Merged this despite UI test failures as they are consistent flakes.


Updating the AI Radial menu.

About the PR

AI can now bolt, emergency access and electrocute doors.
Toggling emergency access now makes a sound.
Doors cannot be bolted/unbolted while unpowered anymore.
AirlockComponent now has EmergencyOffSound and EmergencyOnSound.
Why / Balance

Adding missing features and I think there should be a sound for emergency access.
Technical details

Basically copy-pasted code from the bolting part except uses a different component.
Updated ToggleEmergencyAccess to take Entity, EntityUid? user and bool predicted as variables.
Media

https://github.com/user-attachments/assets/5f90503a-8381-43a8-86d7-b3d78d4573a7
Requirements

[X] I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Updated ToggleEmergencyAccess to take Entity, EntityUid? user and bool predicted as variables.
Moved ElectrifiedComponent to Shared.
Changelog

:cl:

add: AI can now bolt, emergency access and electrocute doors.
add: Emergency Access toggle now makes a sound.
tweak: Doors can no longer be bolted while unpowered.

Turning this into a draft until It's finished.

I dont have the strength to keep trying to make this work
If someone wants to make the electrocute action I have a backup of it, ping me on the ss14 discord ill happily send it
It only needs to check if a power wire is cut and make you unable to toggle electrocute on a door if it is and its done

Moved to https://github.com/space-wizards/space-station-14/pull/32012


Invalid @RestControllerAdvice

Hi, maybe a bug have been found out. The specific scene is:
when a customize aop arounds the bean which is
annotated with @RestControllerAdvice and then it's
internal methods which are expected to handle the
exception will make no effect.
Env

Restlight version: 0.0.1-SNAPSHOT
JVM version: openjdk version "1.8.0_252"
OS: Window10

prs are welcome :)

I'd be glad to

fixed by #15


bump dependencies

Applied mkpr on package.json
/tmp/mkpr.sh

:tada: This PR is included in version 1.10.151 :tada:
The release is available on:

npm package (@latest dist-tag)
v1.10.151
GitHub release

Your semantic-release bot :package::rocket:


Possible mistake in documentation

As far as I understand, workspaces have not been added to the currently stable cargo version (0.12.0 ... by "stable version" I don't mean the master branch, but the most recent commit in the master branch that is tagged as a release). However, http://doc.crates.io/manifest.html explains how to use workspaces. Is it intended to document a feature in the mainstream documentation, which has not been implemented in the currently stable release? If yes, I have to say it's confusing for a beginner like me, because I'm thinking I'm doing something wrong on my end if it doesn't work. Thanks for your help! Stefan

I just got caught out by this issue too. I'm guessing that crates.io grabs the ./src/doc/manifest.md from git mater, because the 0.12.0 tag doesn't have any mention of them in its version of the file. Unless a new cargo release is planned soon, I'd recommend removing the mention from crates.io.

Ah yeah this is an unfortunate repercussion of how our documentation is set up, we don't currently have nightly/beta/stable docs like rust does :(

I see. As a further suggestion: if there exists only one version on the main website, shouldn't it be the stable one? Would it be technically difficult (or otherwise disadvantageous) to display the "old" but stable docs? I assume that the majority of people consulting the docs do have the stable cargo version installed.
keeperofdakeys pointed out that the docs are located in src/doc. That helps, now I know how to browse the "stable" *.md files from the github repository. They are nicely formatted too.

Yeah ideally we'd have staged docs like Rust does, where they're promoted every so often, but it's just infrastructure we haven't set up yet :(


feat: add NestedLoopJoin rel

Requires https://github.com/substrait-io/substrait/pull/561 to be merged and released.

https://github.com/substrait-io/substrait/pull/561 has been merged. After it's released over the weekend, we can update the submodule to point to it (preferably as it's own PR).

I went ahead and updated substrait-java with the latest version of substrait, which includes the NestedLoopJoin changes.

I can repro the failure locally. I'm still digging into it, it seems the test case is surfacing an actual bug.

Thank you so much for the help!


[cmake] fix linking coverage library

--coverage looks more like a option than a library. Though somehow it works. I think gcov is better.

It seems this doesn't work.


exit CLI process with 1 if release cancelled

This enables the following workflow:
scripts: { release: "gh-release && npm publish" }

meaning npm publish would only run if gh-release exited successfully. if answering no to final confirmation prompt, shold exit with 1 to fail and end rather than going on with publish step.
make sense @paulcpederson @bcomnes?

/cc @flet

sorry @flet confusing this project temporarily with module-init which you contributed to

Yes. :+1:
I assumed it already worked that way, so I definitely am into it.

@paulcpederson nope https://github.com/ngoldman/gh-release/blob/master/index.js#L62 :(
this is also a project I did before I understood properly decoupling CLI from node API, been planning a refactor to use event emitter pattern internally and move the whole inquirer part to bin/cli

https://github.com/ngoldman/gh-release/blob/master/bin/cli.js#L84
this should be 1 as well

@paulcpederson yep thanks good catch

@ngoldman No worries I'm having a great time reading this stuff :)
This is all accurate so far! :+1:
Another little trick is using || to execute some other command if something exits non-zero
gh-release && npm publish || echo Something went terribly wrong

Neat module btw! I like the idea of putting changelog info in the release. Its a lot richer than just using npm version generated tags. Will try it out for sure.

it meshes with a little idea I had the other day...
lazy-changelog which would push commit messages since the last tag into CHANGELOG.md...
 It could just be used as a seed before hand editing too.
But Imagine: scripts: { release: "lazy-changelog && gh-release && npm publish" }

@Flet sounds interesting! I've been thinking about having a major/minor/patch type of flag to bump version in package.json and change "Unreleased" to that version before the release happens. Something like your lazy-changelog idea would work well with that.

@paulcpederson one last question for this thread. What about dry runs?
Right now it exits with 0: https://github.com/ngoldman/gh-release/blob/v1.1.7/index.js#L59


Update index.html(Added responsiveness)

Added the responsiveness so that it can be accessed on small device.
What does this PR do?
I have added the responsiveness to your code so that the game can be accesd on small device.
Fixes #(issue)
Provided

Type of change
Change in UI.

New feature (non-breaking change which adds functionality)

How should this be tested?

[ ] Test B

Mandatory Tasks

[ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

@Bhumika-00 please solve the merge conflict and then again try to raise pr

Ok, I will check.
On Wed, 23 Oct, 2024, 1:30 am Akhilesh, @.***> wrote:

@Bhumika-00 https://github.com/Bhumika-00 please solve the merge
conflict and then again try to raise pr
—
Reply to this email directly, view it on GitHub
https://github.com/YadavAkhileshh/Alien-Invasion-Defense/pull/356#issuecomment-2430141950,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BKOHTVWBCGEZVL4O2IPBFYLZ42VHJAVCNFSM6AAAAABP4FMF2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZQGE2DCOJVGA
.
You are receiving this because you were mentioned.Message ID:
@.***>


[6696/1880][UI] replace node-sass with dart-sass

LibSass and Node Sass are deprecated.
https://www.npmjs.com/package/node-sass
fix:
https://github.com/apache/dolphinscheduler/issues/1880
https://github.com/apache/dolphinscheduler/issues/6696
Purpose of the pull request
the lib node-sass is deprecated
Brief change log

Replace node-sass with dart-sass

Verify this pull request
This pull request is code cleanup without any test coverage.

Hi @wuliupo , please change the pr title such as [Bug-issueId][UI] pr theme, thxs

After the change, whether to clear the browser's cache of the current page to view the page style?
Is the style of all pages displayed correctly after the change?
Can the build command be executed correctly after the change?

After the change, whether to clear the browser's cache of the current page to view the page style?
-- yes
Is the style of all pages displayed correctly after the change?
-- yes
Can the build command be executed correctly after the change?
-- yes

The above e2e Test / Test (pull_request)
it seems another test issue, not included by this commit.
When I run checkout master and run cd ./e2e && mvn -B clean test -X, it has the same error,

"org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.JAVA_SPECIFICATION_VERSION_AS_ENUM" is null

The below e2e Test / Test (pull_request)
it seems another test issue, not included by this commit. When I run checkout master and run cd ./e2e && mvn -B clean test -X, it has the same error,

"org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.JAVA_SPECIFICATION_VERSION_AS_ENUM" is null

Can you update the code from upstream?

Please rebase the latest code to test the effect on the page to check whether the page style is correct.

You should open the pull request to dev branch

Codecov Report

Merging #7515 (44913ef) into dev (9f56123) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev    #7515      +/-   ##
============================================
- Coverage     41.29%   41.25%   -0.04%
+ Complexity     3674     3671       -3
============================================
  Files           641      641
  Lines         26469    26469
  Branches       2961     2961
============================================
- Hits          10930    10921       -9
- Misses        14514    14521       +7
- Partials       1025     1027       +2

Impacted Files
Coverage Δ

...lphinscheduler/common/task/AbstractParameters.java
51.61% <0.00%> (-8.07%)
:arrow_down:

...e/dolphinscheduler/remote/NettyRemotingClient.java
50.70% <0.00%> (-2.82%)
:arrow_down:

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 9f56123...44913ef. Read the comment docs.

HttpError: Invalid request.
Only 65535 characters are allowed; 112965 were supplied.

it seems environment error.  @CalvinKirs

Due to the refactor of next version base on Vue3, this changes will be unused.


Differences in to_netcdf for dask and numpy backed arrays

What is your issue?
I make use of fsspec to quickly open netcdf files in the cloud and pull out slices of data without needing to read the entire file. Quick and dirty is just ds = xr.open_dataset(fs.open("gs://...")).
This works great, in that a many GB file can be lazy-loaded as a dataset in a few hundred milliseconds, by only parsing the netcdf headers with under-the-hood byte range requests. But, only if the netcdf is written from dask-backed arrays. Somehow, writing from numpy-backed arrays produces a different netcdf that requires reading deeper into the file to parse as a dataset.
I spent some time digging into the backends and see xarray is ultimately passing off the store write to dask.array here. A look at ncdump and Dataset.encoding didn't reveal any obvious differences between these files, but there is clearly something. Anyone know why the straight xarray store methods would produce a different netcdf structure, despite the underlying data and encoding being identical?
This should work as an MCVE:
import os
import string
import fsspec
import numpy as np
import xarray as xr

fs = fsspec.filesystem("gs")
bucket = "gs://<your-bucket>"

# create a ~160MB dataset with 20 variables
variables = {v: (["x", "y"], np.random.random(size=(1000, 1000))) for v in string.ascii_letters[:20]}
ds = xr.Dataset(variables)

# Save one version from numpy backed arrays and one from dask backed arrays
ds.compute().to_netcdf("numpy.nc")
ds.chunk().to_netcdf("dask.nc")

# Copy these to a bucket of your choice
fs.put("numpy.nc", bucket)
fs.put("dask.nc", bucket)

Then time reading in these files as datasets with fsspec:
%timeit xr.open_dataset(fs.open(os.path.join(bucket, "numpy.nc")))
# 2.15 s ± 40.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit xr.open_dataset(fs.open(os.path.join(bucket, "dask.nc")))
# 187 ms ± 26.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Hm... for me the first call  in a session is always slow which suggests its some fsspec auth/setup thing.

I did try many loops and different order of operations to make sure this isn't a caching or auth issue. You can see the std dev of the timeit calls above is pretty consistent.
For my actual use case, the difference is very apparent, with open_dataset taking about 9 seconds on the numpy-saved file and <1 second on the dask-saved one. I can also clearly see when monitoring network traffic that the slow version has to read in hundreds of MB of data to open the dataset, while the fast one only reads the tiny headers.
I also inspected the actual header bytes of these two files and see they are indeed different.

Hmmm open_dataset should really only read metadata
Can you run a line profiler and see what's requesting the reads please.

The slow file:

And the fast file:

Do you think this is tied to fsspec somehow?
Perhaps @martindurant can take a look.

I do generally recommend cache_type="first" for reading HDF5 files, because they tend to have most of the metadata in the header area of the file, with short pieces of metadata "elsewhere"; so the default readahead doesn't perform very well.
As to what the two writers might be doing differently, I only have guesses. I imagine xarray leaves it entirely to HDF to make whatever choices it likes. Dask does not write in parallel, since HDF does not support that, but it may order the writes more logically. It does set up the whole set of variables as a initialisation stage before writing any data - I don't know if xarray does this.

Yeah that seems to be it. Dask's write neatly packs all the needed metadata at the beginning of the file, since we can scale this up to a many GB file with dozens of variables and still read in ~100ms. While xarray is doing a less well organized write of the metadata and we have to go seeking in the middle of the byte range. cache_type="first" does provide some improvement but still not as good as on the dask-written file.
FWIW, I inspected the actual bytes of the dask and xarray written files and they are identical for a single variable, but diverge when multiple variables are being written. So, the important differences are probably associated with this step:

It does set up the whole set of variables as a initialisation stage before writing any data - I don't know if xarray does this.


UI fine tuning (0.6.x)

Some UI enhancements. See the results:
https://issues.jboss.org/secure/attachment/12418840/workbench_dataset_editor_tooltipsfix.mp4
https://issues.jboss.org/secure/attachment/12418842/12418842_new1.png
https://issues.jboss.org/secure/attachment/12418841/12418841_new2.png
The DASHBUILDE-186 is a blocker for QE so it would be good to have it merged sooner than later.
@romartin Can you please merge it? Thanx!

Finally, those annoying popovers are gone. Looks much better now :-) +1 to merge

Merged:
5c710f505d9d026995851d3c1778d81c6cb79600
00d0df80ddaab0b4fae189aadbc5572fd8d5725b
f554aabc683a5bb794770703a65d8ce0dab031cb


[Bug] Cannot execute by AMD Vega integrated GPU

Please carefully review each item in the checklist below | 请认真检查以下清单中的每一项 | 以下のチェックリストの各項目を注意深く確認してください

[X] Searched and didn't find a similar issue | 已经搜索过，没有发现类似issue | 類似の問題が見つかりませんでした
[X] Searched documentation and didn't find relevant content | 已经搜索过文档，没有发现相关内容 | ドキュメントを検索して関連する内容が見つかりませんでした
[X] Tried with the latest version and the issue still exists | 已经尝试使用过最新版，问题依旧存在 | 最新バージョンを試しましたが問題は解消されませんでした

Software Version | 软件版本 | ソフトウェアバージョン
1.1.5
Operating System | 操作系统 | オペレーティングシステム
Windows x64
System Version | 系统版本 | システムバージョン
Windows 10 x64 1909
Describe the bug | 描述错误 | BUGの説明
All the modules I can use properly on CPU only; the GPU-vulkan-based modules always report error messages.
I am using AMD 5700G with Vega 5000 iGPU supporting Vulkan-API up to 1.3.
the graphic driver is the latest adrenalin 23.11.1.
i have the same problem with AMD 2400G iGPU, Vega 11.
I have allocated iGPU with 4GB shared RAM.
To reproduce | 复现步骤 | 再現方法

run final2x
select any pictures with JPG/PNG formats
choose [GPU0] AMD Radeon Graphics
set RealESRGAN as an executive module.
run, error posted during initiation steps.

Error log | 报错日志 | ログ
[{"label":"CPU: Ryzen 7 5700G with Radeon Graphics","value":-1},{"label":"GPU 0: AMD Radeon(TM) Graphics","value":0},{"label":"GPU: Auto","value":114514}]
{"gpuid":0,"inputpath":["C:\\Users\\user\\Desktop\\9545a7303c098c0f972f6a16f81livb5.JPG"],"model":"RealESRGAN","modelscale":4,"modelnoise":0,"outputpath":"C:\\Users\\user\\Desktop","targetscale":0,"tta":true}
2023-12-21 16:06:45.099 | INFO     | __main__:main:58 - projectPATH: C:\Users\user\AppData\Local\Programs\Final2x\resources\app\resources\Final2x-core
2023-12-21 16:06:45.100 | INFO     | __main__:main:71 - config loaded
2023-12-21 16:06:45.105 | INFO     | src.SRFactory.SRBaseClass:_set_sr_n:53 - sr_n set to 1
2023-12-21 16:06:45.105 | INFO     | src.SRFactory.SRBaseClass:__init__:35 - SRBaseClass init
[0 AMD Radeon(TM) Graphics]  queueC=1[2]  queueG=0[1]  queueT=2[1]
[0 AMD Radeon(TM) Graphics]  bugsbn1=0  bugbilz=0  bugcopc=0  bugihfa=0
[0 AMD Radeon(TM) Graphics]  fp16-p/s/a=1/1/1  int8-p/s/a=1/1/1
[0 AMD Radeon(TM) Graphics]  subgroup=64  basic=1  vote=1  ballot=1  shuffle=1
2023-12-21 16:06:48.681 | INFO     | src.SRFactory.REALESRGAN:_init_SR_class:66 - RealESRGAN model loaded
2023-12-21 16:06:48.681 | INFO     | src.SRqueue:SR_queue:25 - Processing------[ 0.0% ]
2023-12-21 16:06:48.717 | INFO     | src.SRqueue:SR_queue:73 - Processing: C:\Users\user\Desktop\9545a7303c098c0f972f6a16f81livb5.JPG, save to: C:\Users\user\Desktop\outputs\4x-9545a7303c098c0f972f6a16f81livb5.png
vkAllocateMemory failed -2
2023-12-21 16:06:48.804 | ERROR    | src.SRFactory.SRBaseClass:process:78 - An error has been caught in function 'process', process 'MainProcess' (22824), thread 'MainThread' (37964):
Traceback (most recent call last):
File "__main__.py", line 88, in <module>
File "__main__.py", line 79, in main
File "src\SRqueue.py", line 74, in SR_queue
> File "src\SRFactory\SRBaseClass.py", line 78, in process
File "src\SRFactory\SRBaseClass.py", line 96, in _process_n
File "realesrgan_ncnn_py\realesrgan_ncnn_vulkan.py", line 188, in process_cv2
File "realesrgan_ncnn_py\realesrgan_ncnn_vulkan.py", line 122, in process
RuntimeError: Caught an unknown exception!
Traceback (most recent call last):
File "__main__.py", line 88, in <module>
File "__main__.py", line 79, in main
File "src\SRqueue.py", line 84, in SR_queue
cv2.error: OpenCV(4.7.0) D:\a\opencv-python\opencv-python\opencv\modules\imgcodecs\src\loadsave.cpp:1109: error: (-215:Assertion failed) !image.empty() in function 'cv::imencode'
[22824] Failed to execute script '__main__' due to unhandled exception!
CLOSE CODE:1

Additional context | 附加内容 | 追加コンテキスト
No response

Will it work fine with native-gpu or gpu-pass-through?

Will it work fine with native-gpu or gpu-pass-through?

many thanks for your quick reply.
These devices I mentioned only contains an integrated Vega GPU.
I have another PC with only AMD RX570 4GB graphic card working fine.
Actually, I am encountering the same problem with a similar application called 'Upscayl*'. But some users said it works fine with miniPC, with 5900H APU (that is mobile version of 5700G)

using some open modules that is identical to Final2X contained.

Will it work fine with native-gpu or gpu-pass-through?

many thanks for your quick reply.
These devices I mentioned only contains an integrated Vega GPU. I have another PC with only AMD RX570 4GB graphic card working fine.
Actually, I am encountering the same problem with a similar application called 'Upscayl*'. But some users said it works fine with miniPC, with 5900H APU (that is mobile version of 5700G)

using some open modules that is identical to Final2X contained.

Certainly
It seems like you're dealing with an issue that comes from upstream
Try use this cli app - https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan
And Not surprisingly, you'll get the same error
Try switching the ncnn library and the vulkan lib version to compile may work, I can provide some tech support for compiling it...

https://final2x.tohru.top/pages/build/xx-ncnn-py.html
The steps for compiling the cli are similar. Try using the latest ncnn and vulkan-lib version...

Hello! your issue has been closed because it has been inactive for a long time.
你好，你的 issue 因为长时间不活跃而被自动关闭。
こんにちは、お問い合わせは長期間活動がないため、閉じられました。


Umbrella issue for documentation enhancements

This issue gathers a variety of tasks that intend to improve the quality of Falco's documentation.

[ ] #666
[x] #667
[x] #668
[ ] #669
[x] #670

/area documentation

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

/remove-lifecycle rotten

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

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


[TypeScript compiler Bug?] subclass function return value's specific type incorrectly recongnized as parent interface more general return type

I am developing a tiny Option/Either library and found out this problem. Not sure if it is a bug with TypeScript compiler.
TSC version: 3.0.3
The observation here is that the line console.log('plusedA is Option? ', plusedA instanceof Option) says plusedA is Option ? true
but when I add following line const ra = plusedA.get(), compiler complained: error TS2339: Property 'get' does not exist on type 'Applicative<any>'.
When I explicitly cast it to Option, as const ra = (plusedA as Option<number>).get(). Compilation passed and code worked as expected.
The test code:
const triplePlusF = (a: number) => (b: number) => (c: number) => a + b + c
const triplePlus = new Some(triplePlusF)
const a = new Some(2)
const b = new Some(3)
const c = new Some(4)
const d = new None()

const plusedA = triplePlus
  .applyMap(a)
  .applyMap(b)
  .applyMap(c) // plusdA = Some( 2 + 3 + 4 )

console.log(plusedA) // plusedA = Some(9)

console.log('plusedA is Option? ', plusedA instanceof Option)
const ra = plusedA.get() // Compilation error: error TS2339: Property 'get' does not exist on type 'Applicative<any>'.
const ra = (plusedA as Option<number>).get() // works
console.log(ra)

Below is the code for the Option library. typecat
export const id = (a: any) => a

export interface Functor<T> {
  fmap<S>(f: (a: T) => S): Functor<S>
}

export interface Applicative<T> extends Functor<T> {
  applyMap(a: Applicative<T>): Applicative<any>
}

export interface Monad<T> extends Applicative<T> {
  flatMap<S>(f: (a: T) => Monad<S>): Monad<S>
}

export abstract class Option<T> implements Monad<T> {
  abstract _value?: T
  abstract fmap<S>(f: (a: T) => S): Functor<S>
  abstract applyMap(a: Applicative<T>): Applicative<any>
  abstract flatMap<S>(f: (a: T) => Monad<S>): Monad<S>
  abstract [Symbol.iterator](): IterableIterator<T>
  abstract get(): T
  abstract getOrElse(defaultValue: T): T
}

export class Some<T> extends Option<T> {
  _value?: T
  constructor(a: T) {
    if (a === undefined || a === null)
      throw TypeError("Some can't be initated with undefined or null")

    super()
    this._value = a
  }

  fmap<S>(f: (a: T) => S): Some<S> {
    return new Some<S>(f(this._value!))
  }

  applyMap(a: Option<any>): Option<any> {
    if (a instanceof None) return new None()

    const f = (this as any)._value as (a: any) => any

    return new Some(f!(a._value))
  }

  flatMap<S>(f: (a: T) => Option<S>): Option<S> {
    return f(this._value!)
  }

  get(): T {
    return this._value!
  }

  getOrElse(defaultValue: T): T {
    return this._value!
  }

  *[Symbol.iterator](): IterableIterator<T> {
    yield this._value!
  }
}

export class None<T = any> extends Option<T> {
  _value?: T
  constructor() {
    super()
  }

  fmap<S>(f: any): Some<S> {
    return new None()
  }

  applyMap(a: any): Option<any> {
    return new None()
  }

  flatMap(f: any): Option<any> {
    return new None()
  }

  get(): T {
    throw TypeError('Value not exist in None')
  }

  getOrElse(defaultValue: T): T {
    return defaultValue
  }

  *[Symbol.iterator](): IterableIterator<T> {
    return
  }
}

This doesn't look like a bug. The return values in your class:
export abstract class Option<T> implements Monad<T> {
  abstract _value?: T
  abstract fmap<S>(f: (a: T) => S): Functor<S>
  abstract applyMap(a: Applicative<T>): Applicative<any>
  abstract flatMap<S>(f: (a: T) => Monad<S>): Monad<S>
  abstract [Symbol.iterator](): IterableIterator<T>
  abstract get(): T
  abstract getOrElse(defaultValue: T): T
}

are returning the interface type, not the Option type. As soon you you call applyMap on an Option you get back an Applicative, losing the type Option.
If you write:
export abstract class Option<T> implements Monad<T> {
  abstract _value?: T
  abstract applyMap(a: Applicative<T>): Option<any>
}

then you wont lose the Option type.
The issue tracker is not really meant for general questions. I would recommend trying StackOverflow first; @dragomirtitian or @jcalz will give better answers than me there anyway. If it really does start to look like a language bug then the issue tracker is correct location.

@jack-williams applyMap is called at the type Some according to the test code. And Some's applyMap signature is applyMap(a: Option<any>): Option<any>. I suppose the return type should be Option.
And also it is inconsistent between run-time instanceof type check and compiler type check.
But after I changed the signature of applyMap defined at Option to abstract applyMap(a: Option<T>): Option<any>, the compiler stop complaining.
And thanks for the advice on where to post the issue. It is the inconsistency between instanceof type check and compiler that made me wondering if it is a bug.

In general 60+-line reports are due to user confusion, not type system bugs.
If you track this down to what you believe to be a bug, please post a small repro.


Fix(VIM-2562): Fix hang with multi-width chars in command line

This PR fixes a hang in the IDE when typing a multi-width character such as an emoji or other non-Latin character in the ex command line or search text field ([VIM-2562[(https://youtrack.jetbrains.com/issue/VIM-2562)).
The issue was due to the handling of the custom caret in the text field. Like Vim, the caret should change its shape as it moves around the field, and to reflect the insert/replace state - block at the end of the text, bar for insert, underscore for replace. See also 'guicursor').
When updating the caret, it is first hidden, then updated and then shown again, so any changes in shape are immediately visible. Unfortunately, hiding the caret causes a layout, and when this happens in a callback due to changing the text to add a multi-width character, the layout algorithm gets stuck in an infinite loop.
The fix is to not hide/show the caret on each update - when moving the caret, or editing text, the system makes sure that the caret is correctly updated as part of the flashing. Changing the insert/replace state of the caret is handled explicitly, so hiding/showing the caret to make the changes visible is handled here instead.

Awesome, thank you for the fix!


missing space in catch statement

ktlint changed catch (e:Exception) to catch(e:Exception), which looks ugly and is not the style used at kotlinlang. https://kotlinlang.org/docs/reference/exceptions.html

@christophsturm Thank you! Will be released as part of 0.1.1 (later today).


tf.hub to ONNX conversion

Hi, nice work first of all!
Secondly, could you help me how to convert a tf model from the tf.hub to an ONNX? I am getting errors unfortunately... I would like to do sth similar but with trillsson.
https://tfhub.dev/google/trillsson5/1
Thanks :)

Hi BaMarcy
Converting with tf2onnx.
python -m tf2onnx.convert --saved-model ./model --output a.onnx

This makes error as below. Probably it does unusual way to use tf.gather (maybe for embedding lookup). If you have source code, you can investigate it. You may try Hugging Face. It has better support of ONNX, it this one is the same as your model  https://github.com/huggingface/transformers/pull/17387
ValueError: make_sure failure: Axis of GatherV2 node must be constant                                          [22/1963]2023-10-22 10:05:24,425 - ERROR - Unsupported ops: Counter({'Rank': 3})                                                 Traceback (most recent call last):                                                                                File "/home/kaiida/anaconda3/envs/py310-tf2/lib/python3.10/runpy.py", line 196, in _run_module_as_main                    return _run_code(code, main_globals, None,
  File "/home/kaiida/anaconda3/envs/py310-tf2/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/kaiida/anaconda3/envs/py310-tf2/lib/python3.10/site-packages/tf2onnx/convert.py", line 714, in <module>
    main()
  File "/home/kaiida/anaconda3/envs/py310-tf2/lib/python3.10/site-packages/tf2onnx/convert.py", line 273, in main
    model_proto, _ = _convert_common(
  File "/home/kaiida/anaconda3/envs/py310-tf2/lib/python3.10/site-packages/tf2onnx/convert.py", line 168, in _convert_common
    g = process_tf_graph(tf_graph, const_node_values=const_node_values,


meanVals_  ,normVals_    no use

in the  mobilefacenet.h
const float meanVals_[3] = {     127.5f,     127.5f,     127.5f };
const float normVals_[3] = { 0.0078125f, 0.0078125f, 0.0078125f };
but I cant see any use for  meanVals_ and normVals_

Some of the model have included the normalization step in the model itself. Open the model file using Netron or similar tool to check initial few layers of the model.

could you provide the mobilefacenet  .pth   link  before converting to .mnn, thanks

@alicera You are talking about face recognition model right? In that case, I believe the model here is originally trained by Insight face using arcface loss function optimization. You can go to insight face github repo and check it for yourself.

https://github.com/MirrorYuChen/mnn_example/issues/8

thanks


Start event of homeassistant doesn't trigger automation anymore

Home Assistant release with the issue:
0.87.0
Last working Home Assistant release (if known):
0.86.4
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Component/platform:
https://www.home-assistant.io/docs/automation/trigger/#home-assistant-trigger
Description of problem:
The start event doesn't seem to trigger automation anymore. I set a theme on startup and it isn't applied anymore, also the latest trigger of this automation is never updated meaning that it never gets triggered.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
automation:
  - alias: on_startup
    hide_entity: true
    trigger:
      - platform: homeassistant
        event: 'start'
    action:
      - service: frontend.set_theme
        data_template:
          name: midnight-remake

I won't be able to reproduce your issue.
You can turn on info level log to get more information
# configuration.yaml
logger:
  default: info

For an unknown reason, this automation (alongside a lot of others got disabled during the upgrade).
I'll close this.

Just in case anybody else get stuck there:
Most of my automations where disabled after Update vom HA 0.86.3 to 0.87.0:

To reenable them change State to on.
You have to reload automation after you reenabled them.
If automation is disabled there will be no INFO message in HA log like:
 "... INFO (MainThread) [homeassistant.components.automation] Initialized trigger Lumi Button 1 on double Click ..."


2 Feature requests: Map pathing images (ala qik), XP/Overlevel tracker

Poking around today and found this tool had recently released an update, but unfortunately the method by which it expects you to manually edit in a build is super archaic. OTOH, it has these nifty images (that I find a bit more intuitive than the occasional text descriptions Lai offers), and would like to request a 'graphic pathing' option for your tool.
Also found the XP/overlevel tracker to be kind of useful, as Im always manually attempting to keep an eye on that, and it seems like a perfect thing to implement here (again that dated tool expects you to manually enter offsets to place each element instead of just dragging as you would in the 21st century, lol).
Thanks for your tool! Have been occasionally following your every addition on the reddit, and finally ZD got me invested into actually installing it for crucible, and it is fantastic!
[(`https://github.com/JusKillmeQik/PoE-Leveling-Guide)]

(that I find a bit more intuitive than the occasional text descriptions Lai offers), and would like to request a 'graphic pathing' option for your tool.

The guide-text is based on exile-leveling, with occasional re-arrangement from my side to better fit the panel.
I'll have to verify if the available layouts are still up to date. I think I read somewhere that GGG changed seeding a while back, but I'm not sure. I'm also unsure about how to implement these graphics, I personally don't like how cluttered the screen looks at times in qik.

Also found the XP/overlevel tracker to be kind of useful, as Im always manually attempting to keep an eye on that, and it seems like a perfect thing to implement here

Certainly easy enough to implement. I'll think about it.

The qik thingy sets it up with a timer you can set to autohide it after some configured amount of time which is helpful. It lets you move them, but its the clunky offset number method again, so feels bad.
There are some maps that alter the layouts (mostly later when betrayers and such start popping in), but generally it is pretty quick to tell if a direction you are headed in seems to match one of the images or not, and I have to mention I just got to the brine king faster than I ever have minutes ago with one, haha.
Im definitely sold at this point, so ill use it either way (I think itd take anyone a single league start to believe, haha), just always nice if it makes sense to get less tools total, especially since your implementation is just so modern by comparison. :)

This is what I'm testing right now for v1.50 (which should hopefully be ready for next league): I have added two small panels that show how many zone-layout img-files are available for the current area (bottom-left, ZL) and how much exp you're getting.
As I mentioned before, I don't like having them pop up or be on screen automatically with every transition, so they will be on the left edge of the screen while holding down TAB (configurable) instead. Scrolling will zoom in/out.
Let me know what you think, and feel free to suggest improvements.


[BUG]<EMAIL_ADDRESS>with walletconnect 2.0 configuration errors with EIP712 signing function not available

Basically the issue is the same as here which is that "Missing or invalid "eth_signTypedData_v4"" and so for a user to make it work the next 28 days (lol), you can still just rely on walletconnect 1.0
https://github.com/wagmi-dev/wagmi/discussions/2240#discussioncomment-6051864

From my experience, WalletConnect 2.0 supports EIP712 (it works when using their w3modal -- you can test), but it seems like this might be related to #35 overall.

WC2.0 seems to be working for me with Rainbow now. Did not make any dependency updates so maybe something changed on the wallet end?

dunno, e.g. the wallet I used claims to be WC2 ready but it doesn‘t work. Rainbow does.

I believe this is an issue on based on every wallet requiring to implementing this method manually rather than on ConnectKit, elsewise it would be on the peer dependency wagmi to implement the function correctly.
Closing this for now since it's not related directly to the ConnectKit library.


wath will block if the caller want to stop the watcher...

func (s *Etcd) watch(key string, opt *store.WatchOptions, recursive bool, stopCh <-chan struct{}) (<-chan *store.WatchResponse, error) {
opts := &etcd.WatcherOptions{Recursive: recursive}
if opt != nil {
opts.AfterIndex = opt.Index
}
watcher := s.client.Watcher(store.Normalize(key), opts)
// watchCh is sending back events to the caller
resp := make(chan *store.WatchResponse)
go func() {
	defer close(resp)

	for {
		// Check if the watch was stopped by the caller
		select {
		case <-stopCh:
			return
		default:
			r, err := watcher.Next(context.Background())-----will block here if caller want to stop watch , because the Next function is block function and can not receive the stopCh channel.
			resp <- s.makeWatchResponse(r, err)
			if err != nil {
				return
			}
		}
	}
}()

return resp, nil

}

yes, that is a problem.

ok.


Changing from using python2 to python2.7

Using python2.7 rather than python2 in 'lint' make target.
Python2.7 should be the true path that python2 is aliased with. For
systems that do not have python2.7 aliased with python2, this fix should
fix their issues.

Codecov Report

Merging #159 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #159      +/-   ##
==========================================
- Coverage   73.23%   73.21%   -0.03%
==========================================
  Files          18       18
  Lines         710      713       +3
==========================================
+ Hits          520      522       +2
- Misses        190      191       +1

Impacted Files
Coverage Δ

firmware/library/L0_LowLevel/delay.cpp
57.14% <0%> (+7.14%)
:arrow_up:

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 e282f3f...99bc609. Read the comment docs.

Covered by #172.


Fix typo

activate was misspelled

Hey @nakami,
Thanks for the correction. There are probably much more of them in the docs though :D


Deno JavaScript runtime

Thank you for great project.
Are there any plans to support Deno JavaScript runtime?

Are you talking about running the compiler on Deno instead of node.js? I have no current plans to do this. What is your use case that requires this?

Yes, running compiler on Deno instead of node.js.
Use case is related to preparation of simple/small and resource limited bundle for JS MCU app developer to develop/prepare app snapshots.

You can already do that with node.js, so what aspect of your situation benefits from Deno specifically?

I hope for better isolation with limits for memory and CPU resources without another os specific sandboxing.
I have no clue how much effort it takes to support Deno's runtime. It may not be worth doing that in the current Microvium state.

Yeah, at the moment it would be quite difficult. The microvium package bundles both the compiler and a native build of the runtime engine which uses NAPI under the hood for native bindings. This could be replaced with the new WASM library but it would be a fair amount of work.

Thanks for info.

After considering the effort involved, I've decided not to pursue Deno support for now, but I'll reconsider if there's more demand in the future. Thanks for your understanding.


docs: add NAT table to BPF map limitations table

Also consistently use the k unit prefix for kilo.

Coverage increased (+0.002%) to 46.593% when pulling 7db360d676a0ec7b5dfc935a6c4ef7fdf693b7e0 on pr/tklauser/scale-docs-add-nat-map into afc48b73b65af521a7a8cb93c766dc28d379ca06 on master.


Can't initialize driver

Hi. I'm using two different ZWave modules. First is the Razberry module (/dev/ttyAMA0) and the other is the UZB stick (/dev/ttyUSB0). Both are very popular for ZWave development.
I tried running the code:
`const { Driver} = require("zwave-js");
const p1 = "/dev/ttyAMA0";
const p2 = "/dev/ttyUSB0";
const driver = new Driver(p1)
driver.once("driver ready", () => {
console.log("ready!");
driver.start();
driver.controller.nodes.forEach(
console.log("Detected a node")
);
driver.destroy();
})`
But in response I get DRIVER   destroying driver instance...
Then I tried to use 'driver.start()' outside of 'driver.once' and I got a more elaborate error message.
18:10:12.511 DRIVER   version 3.5.4
18:10:12.514 DRIVER
18:10:12.516 DRIVER   starting driver...
18:10:12.518 DRIVER   opening serial port /dev/ttyAMA0
18:10:12.544 DRIVER   serial port opened
18:10:12.557 SERIAL » [NAK]                                                                   (0x15)
18:10:14.080 DRIVER   loading configuration...
18:10:16.161 DRIVER   beginning interview...
18:10:16.167 DRIVER   added request handler for AddNodeToNetwork (0x4a)...
1 registered
18:10:16.172 DRIVER   added request handler for RemoveNodeFromNetwork (0x4b)...
1 registered
18:10:16.191 CNTRLR   beginning interview...
18:10:16.193 CNTRLR   querying version info...
18:10:16.217 DRIVER » [REQ] [GetControllerVersion]                                   [P: Controller]
18:10:16.223 SERIAL » 0x01030015e9                                                         (5 bytes)
18:10:17.829 DRIVER   Timeout occured waiting for ACK - scheduling transmission attempt (2/3) in 100 ms...
18:10:17.929 DRIVER » [REQ] [GetControllerVersion]  [attempt 2/3]
18:10:17.931 SERIAL » 0x01030015e9                                                        (5 bytes)
18:10:19.534 DRIVER   Timeout occured waiting for ACK - scheduling transmission attempt (3/3) in 110   0 ms...
18:10:20.634 DRIVER » [REQ] [GetControllerVersion]                                     [attempt 3/3]
18:10:20.636 SERIAL » 0x01030015e9                                                         (5 bytes)
18:10:22.238 DRIVER   Timeout occured waiting for ACK received - maximum transmission attempts for the current transaction reached, dropping it...
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Error: Failed to send the message after 3 attempts
at Driver.handleUnsuccessfulTransmission (/home/pi/testCode/node_modules/zwave-js/build/lib/driver/Driver.js:1119:47)
at Timeout._onTimeout (/home/pi/testCode/node_modules/zwave-js/build/lib/driver/Driver.js:1387:18)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
18:10:22.807 DRIVER   destroying driver instance...
`
At least this showed me that my serial devices are working, but I don't know what I need to change to make this work.
Thank you

First of all, you need to start the driver outside any handlers, like it is shown in the docs
Second, your devices are not responding at all. Are you sure that they are not in use by another application?

In the code I supplied you can see me attempt various methods, one of them was according to the docs, which made the system print the logs (also mentioned above).
18:10:12.518 DRIVER opening serial port /dev/ttyAMA0 18:10:12.544 DRIVER serial port opened 18:10:12.557 SERIAL » [NAK] (0x15) 18:10:14.080 DRIVER loading configuration... 18:10:16.161 DRIVER beginning interview...
I'm seeing the same response even when I use the serial usb port '/dev/ttyUSB0'. Please note that these ports work when I use them with openzwave-shared and with Domoticz and HomeAssistant.
Thanks

Update - I found the problem. When I reinstalled the raspberry pi it started to recognize my device as '/dev/ttyACM0' instead. I was still using the '/dev/ttyUSB0'. I don't know why this happened, but it's fixed at least I don't see failures like before.
Thanks


data tables?

how to properly call data-table? Can't make it work even after setting all requirements.

which framework are you using?


chore: clarify message for when docs are not generated

I noticed an issue we had was that if someone fails to generate docs, it isn't always clear to them that travis is failing for that reason. I wrote out my own module to handle this sort of situation, but with hopefully nicer error reporting.
This PR updates ShellJS to use the module as a dev dependency, with an error message that is hopefully a bit more explanatory than what we had before.

LGTM!


bazel/repo: Fix version export (for apt archive)

apologies @jmarantz my initial attempt at a format fix didnt work - should work now