Create DSGP 1

Just a draft, but I hope it will be accepted soon.

I'll go ahead to merge this. However, it's status is "Pending". So, if this will be applied, the PR to apply the idea should reference to this one, and update the DSGP status.


Added Desktop app MSI installer tip

@devinbinnie - 2 questions:

our MSI install docs for the desktop app specifically reference the version v5.3.1 release. Can admins use other versions of the desktop app?
is this functionality still in beta?

our MSI install docs for the desktop app specifically reference the version v5.3.1 release. Can admins use other versions of the desktop app?

Yes, we've had an MSI for a while actually now, but v5.3.1 is currently the latest (at time of writing)

is this functionality still in beta?

Technically yes, we were going to have some additional work on it before claiming full support, but it's not currently scheduled.


Can't select title if there is only 1 search result

When using search function if the result is only 1, i can't select it. For example in my list there is only 1 version of dariusburst then i can't select it, but if i search tearaway that have 3 version i can select it normally.

Can confirm - selection is at wrong position when there are too few results. I can still move it up (just keep repeating until selection is visible).
I'll fix this.

it also instantly error's out and exits the program if nothing exists with a matching title

That is fixed in #12.


[Bug]: no-unknown-property is missing some valid global properties (event handlers)

Is there an existing issue for this?

[X] I have searched the existing issues and my issue is unique
[X] My issue appears in the command-line and not only in the text editor

Description Overview
Brief description
Several global event handler properties that are valid on all HTML elements are being limited to only a few by this rule.
See the "event handler" section in the MDN documentation on global attributes, and the HTML specification on global event handlers here.
Show example of your code (as text format), add images/videos/gifs to help explain example
and/or Link of repo to where issue is occurring
<svg>
  <image onLoad={() => console.log("Loaded!")} />
</svg>

What is happening? / What is the error?
In the above example, the error is "Invalid property 'onLoad' found on tag 'image', but it is only allowed on: script img, link, picture, iframe, object".
What command(s) did you run to reproduce issue?
Enabled the rule and the above code will show an error.
Expected Behavior
Brief description
Any global event handler should be able to be defined for any HTML element. (Note that most of these are already in @types/react).
Show example of code (as text format), add images/videos/gifs to help explain expected behavior
This code should not show an error for defining onLoad:
<svg>
  <image onLoad={() => console.log("Loaded!")} />
</svg>

eslint-plugin-react version
7.31.11
eslint version
8.28.0
node version
16.14.2

I will submit a PR for this. Should I be assigned ?

No need for assignment.
the tag, however, is <img>, i thought. is <image> valid in svg?

Yeah it is a synonym in SVG (see here). Though that is just an example from my use case where I load an image and perform actions after the load event fires on the <image>. Regardless, onLoad (and many others not in the example) should be valid on any HTML element according to the spec.

That doesn't sound accurate; div, for example, doesn't load anything and thus shouldn't have an onLoad or onError etc.

Note that the PR will need to make sure that image is only considered inside SVG, and not outside in HTML, where it's an invalid element.

I found anther case. And I think no-unknown-property should no apply to this case.
<video>
    <source onLoad={() => {}} />
</video>

@iobuhov thanks, will be fixed in the next release.


Bump genrand dependency to latest version (0.7 ⇒ 0.8)

Bump genrand dependency to latest version (0.7 ⇒ 0.8)

I am sorry for late response


Fix local storage leak from automatic reload system.

When reloading a browser, we store in local storage some data to be accessed again as soon as it finishes loading.  However, if the reload fails, we never garbage-collect the old values.  See, for example:

We should do something similar to #4443 to clear these extra items, probably called from reload.preserve_state or something.

working on this.


[Bug]: useFetcher submit buttons don't include value when clicking on SVG children

Which Remix packages are impacted?

[ ] remix (Remix core)
[ ] create-remix
[ ] @remix-run/architect
[ ] @remix-run/cloudflare-workers
[ ] @remix-run/dev
[ ] @remix-run/express
[ ] @remix-run/netlify
[ ] @remix-run/node
[X] @remix-run/react
[ ] @remix-run/serve
[ ] @remix-run/server-runtime
[ ] @remix-run/vercel

What version of Remix are you using?
1.1.1
What version of Node are you using? Minimum supported version is 14.
14
Steps to Reproduce

Create a <button type="submit" /> with name and value for submitting a form managed by userFetcher().

const fetcher = userFetcher();

<fetcher.Form method="post">
  <button type="submit" name="vote" value="Upvote">
    <svg> ... </svg>
  </button>
</fetcher.Form>

Submit the form by clicking on the SVG element within the button.

Code sandbox repro: https://codesandbox.io/s/upbeat-mirzakhani-mq0bj?file=/app/routes/index.tsx
Notice how you can get the expected behavior by clicking outside of the SVG, but the bug occurs when you click on the icon.
Expected Behavior
The form should be submitted with vote=Upvote when the button is clicked.
Actual Behavior
The click event uses the form as the event target instead of the button. This omits the submitted button's value from the form data.

A workaround is to use pointer-events: none on the svg element, but I wonder if this can/should be handled in useSubmitImpl()

+1, just ran into this bug as well

This was fixed at some point but we didn't catch this issue! Quick repro for you: https://stackblitz.com/edit/node-wu7qb4?file=app%2Froutes%2Findex.tsx


Empty environment parameter specified on command line causes stacker to fail

Version: 1.0.0a6
A command such as:
stacker build -r eu-west-1 -t -e SomeVar= -e OtherVar=foo envfile.env stack.yaml

causes
Traceback (most recent call last):
  File "/usr/local/bin/stacker", line 9, in <module>
    args.run(args)
  File "/usr/local/lib/python2.7/site-packages/stacker/commands/stacker/build.py", line 52, in run
    dump=options.dump)
  File "/usr/local/lib/python2.7/site-packages/stacker/actions/base.py", line 125, in execute
    self.run(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/stacker/actions/build.py", line 283, in run
    plan.execute()
  File "/usr/local/lib/python2.7/site-packages/stacker/plan.py", line 267, in execute
    if not self._single_run():
  File "/usr/local/lib/python2.7/site-packages/stacker/plan.py", line 227, in _single_run
    status = step.run()
  File "/usr/local/lib/python2.7/site-packages/stacker/plan.py", line 74, in run
    return self._run_func(self.stack, status=self.status)
  File "/usr/local/lib/python2.7/site-packages/stacker/actions/build.py", line 209, in _launch_stack
    stack.resolve(self.context, self.provider)
  File "/usr/local/lib/python2.7/site-packages/stacker/stack.py", line 156, in resolve
    self.blueprint.resolve_variables(self.variables)
  File "/usr/local/lib/python2.7/site-packages/stacker/blueprints/base.py", line 365, in resolve_variables
    self.name
  File "/usr/local/lib/python2.7/site-packages/stacker/blueprints/base.py", line 196, in resolve_variable
    raise ValidatorError(var_name, validator.__name__, value, exc)
UnboundLocalError: local variable 'value' referenced before assignment

So, it seems SomeVar is undefined, rather than defined as being the empty string is what I was trying to achieve. Passing -e SomeVar="" has the same outcome.
It really should be possible to specify that a variable is the empty string at the command line, I think.

The way to work around this appears to be to use -e SomeVar=\"\" which I suppose is logical. I do wonder if there's a nicer fix possible, but I can also see why this might not be considered a bug :)

Thanks for letting us know.
This is the default behavior for how our command line argument parsing works, so I don't think the fix will be very trivial. I think it's best to leave it as is for now.
If this is a serious issue for you, feel free to submit a PR and I will take a look at it.

Yes - I think I agree, I can't see a simple way to "fix" this. Actually, I'm not sure it's broken, in fact. Will close.


[video_player_web] Stop buffering when browser canPlayThrough.

The plugin used to remove the "buffering" state of the player when the browser reported canPlay. That event means that the browser can start playback, but doesn't guarantee (with the current network conditions) that the video can be successfully played to completion without additional buffering.
This change removes the "buffering" state when the browser reports canPlayThrough, which ensures that the browser will be able to playback the whole video without additional buffering.
Fixes https://github.com/flutter/flutter/issues/94630
Tests

Ran all the automated tests locally, and they pass.
Added unit test for the expected order of player events.

Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
[x] I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

/cc @NicolasDionB

The logic change LGTM in the sense that it's less wrong, but I don't think this is reporting the same thing as on other platforms; I believe they are reporting whether any buffering is taking place, rather than whether enough buffering has happened. But it's not clear to me from a quick look at the video element APIs that we can tell that; I see that we can get the buffered regions, but I don't see how to tell if that's changing. Maybe poll until the buffer region includes everything from the current position to the end?
But that could be a follow-up later at lower priority even if it is possible.

@stuartmorgan The idea is not to be able to know if the whole content is buffered but if enough is loaded to ensure a playback with no interruption. So validating that everything from the current position to the end is buffered is not what's needed here.

@stuartmorgan The idea is not to be able to know if the whole content is buffered but if enough is loaded to ensure a playback with no interruption.

I don't know what "the idea" refers to here. My comment was about the cross-platform behavior of the video_player API surface, as I said in my comment.
If "the idea" means the request you made in the issue, what you requested and what the plugin's established behavior is aren't necessarily the same thing. And I believe they are not, as explained in my comment.

So validating that everything from the current position to the end is buffered is not what's needed here.

Are you saying that you've tested ExoPlayer and AVPlayer and they don't report buffering the way I have described? Because what this plugin implementation is supposed to do is be coherent with the other implementations to the degree that is possible.

ExoPlayer seems to not be "buffering enough to play continuously until the end". Here's where it's created:

https://github.com/flutter/plugins/blob/bb9dc2254b70a0b0bc2d797c7cc067105bf602f8/packages/video_player/video_player_android/android/src/main/java/io/flutter/plugins/videoplayer/VideoPlayer.java#L74

It doesn't specify any special LoadControl strategy, meaning it uses the DefaultLoadControl. See some suggested tuning by Akamai.
There's an interesting bit, published by Akamai here:

"viewers will start abandoning a video if startup takes longer than two seconds to begin playing and for every additional second of delay, roughly an additional 6% of the audience leaves. [...] with a 10 second delay, nearly half the audience has left."

So maybe, we should drop this PR, and let the browser start playing a video ASAP? It seems users prefer rebuffering events than the video taking longer to start (which is what this change does).

So maybe, we should drop this PR, and let the browser start playing a video ASAP? It seems users prefer rebuffering events than the video taking longer to start (which is what this change does).

Is the web implementation of video_player forcibly linking play/pause status to whether we report buffering? I wasn't expecting this PR to directly affect playback.

Is the web implementation of video_player forcibly linking play/pause status to whether we report buffering? I wasn't expecting this PR to directly affect playback.

You're right, it seems that the only thing used by the plugin is the "buffered" state (to render the current buffered status in the VideoProgressIndicator widget). The isBuffering boolean value isn't used at all.
So this change can't be helping much in playing the video until enough of it has been loaded, unless  :/
(Maybe postponing the "initialized" event on web would help code, as long as we have a way to check it from the outside to render a "disabled"/"enabled" play button or similar, so users can only click play once the video is ready.

Closing for now, this change isn't solving what it's supposed to.

Well I missed the big picture it seems. So this all sounds good. Maybe a little detail though, postponing the initialized event could work for the initial buffering but when you seek in the video, you fall back in buffering mode again so that strategy would not work in that case.
In my understanding, both buffered and canPlayThrough can be useful, as some users might want to trigger different actions using the buffered state but the canPlayThrough event provided by the browser is more useful as it kind of garantees we can safely play the video. Anyways, thanks for all that. Hope you can find a way to implement this.

Closing for now, this change isn't solving what it's supposed to.

Isn't it still something we should land? It seems like it changes us from "reports that buffering is over way too early" to "reports that buffering is over somewhat too early", which is still better. And by just removing code.

"reports that buffering is over way too early" to "reports that buffering is over somewhat too early", which is still better. And by just removing code.

Yeah, the thing is that even if "canPlay" is true and we mark as not buffering, the moment the browser starts buffering again and we'll set buffering to true again.
@stuartmorgan We can land this to remove code and add some tests that weren't there before, but knowing that this doesn't solve the linked issue of "start playing only when enough video has buffered so it won't be interrupted again".

The logic change LGTM in the sense that it's less wrong, but I don't think this is reporting the same thing as on other platforms; I believe they are reporting whether any buffering is taking place, rather than whether enough buffering has happened.

This was wrong for iOS too; it's using playbackLikelyToKeepUp or a full buffer to indicate the end of buffering. So I think this change actually does make it match other platforms (or at least iOS).

We can land this to remove code and add some tests that weren't there before, but knowing that this doesn't solve the linked issue of "start playing only when enough video has buffered so it won't be interrupted again".

It allows clients of the plugin to more reliably control playback themselves though, so they can choose to start playing only when it's likely to work. Isn't that what the issue is requesting?

This was wrong for iOS too; it's using playbackLikelyToKeepUp or a full buffer to indicate the end of buffering. So I think this change actually does make it match other platforms (or at least iOS).

All right, let's land this then! :)

PTAL! I added a bunch of test coverage that I think is interesting. (Also "discovered" a fail-fast way of dealing with streams in tests that makes me want to revisit every other web test that uses streams differently 🤣)


arbitrary precision arithmetic

It's really good to see that great AWK language is not death, and modern implementation is developed. My congratulation!
I used to use AWK a lot, especially to calculate some statistics like sum, mean or standard deviation from data included in text files (usually logs produced by my software). But many time I had to switch to Python, to calculate them accurately. Python has:

arbitrary precision integers (useful to sum huge integers without overflowing, and calculate e.g. accurate mean),
fsum function (in math module), which is able to sum floats accurately, see https://github.com/python/cpython/blob/d9ab95ff1fe81efdf70e545d536d9f6927d1ba81/Modules/mathmodule.c#L1381 for algorithm (I can also share my Rust implementation),
good statistics module.

Please consider adding some of these futures (especially arbitrary precision integers) to frawk.

Hi!  Thanks for your interest in frawk. I have been thinking about adding higher or arbitrary-precision arithmetic to frawk. It's a big question with lots of points in the design space. I'm not sure when I'll be able to get to it, but I'll keep this issue open for the time being, and for you listing out the specific use-case you have for going beyond standard operations 64-bit integers and  double-precision IEEE floats.

@beling gawk has --bignum.


Add NaturalLog axis

This commit adds a new axis type named 'naturalLog' which creates n subTicks per logarithmic step (n == base)
Useful for audio plots or other kind of logarithmic plots.
It looks like this (labels are customized):

@martin31821 Thanks!
Could you provide an example in test about how to use this?

@Ovilia I ported the example from LogScale to NaturalLogScale, it looks like this:

ECharts already has logBase option, which can create axis with given base. If the improvement lies on subTicks, it should enhance the current axis rather than create a new one. So I'm closing this issue.


Feature/add run test.sh

Thanks for your contribution!
Hi, if there is an issue, that your PR adresses, please link it!

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@4dc0866). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #1   +/-   ##
=========================================
  Coverage          ?   81.57%
=========================================
  Files             ?        4
  Lines             ?     1373
  Branches          ?        0
=========================================
  Hits              ?     1120
  Misses            ?      154
  Partials          ?       99

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 4dc0866...0a88c74. Read the comment docs.


ScrollToFixed + Isotope + Header height + Mobile

Hello I have read almost every issue here but couldn't find a way to fix my problem.
My situation is a little bit complex, but I think is solvable, it must be.
The problem is happening in this page: http://wikimaki.augustocarmo.com.br/cardapio
When I access the page for the firs time, everything works perfectly
When I select a filter ( ex: temaki ) in the left side of the page, it looks ok, but when I scroll the page the scrollToFixed element goes to a wrong negative top value, when I scroll to the top of the page the element goes to the right place again.
When I change the filters without scroll the page, the start position of the elements are always right, but with the first scroll, everything starts to go wrong
I noticed that when I select the filter "Bebidas"  the behaviour is a little bit different, at first, it looks wrong, but when I scroll the element goes to the right place and works normally.
Any help is welcome!
Thanks!

:+1:


Please delete, this is irrelevant.

No worries. :)


[Proposal] Resiliency policies across all building blocks

The goal of this proposal is to create a mechanism where resiliency patterns can be applied consistently across all Dapr building blocks.
Design goals are:

Support high-value resiliency policies: Timeouts, Retries/Back off and Circuit Breakers
Resiliency policies are configured at the application scope
Compatibility across all component types and service invocation
Developers must opt-in, default behavior is unchanged
Policies can be configured with sane defaults
Rules can be used to assign specific policies to Dapr API operation

Non-goals are:

Distributed circuit breaking (additive feature)
Bulkheads and Throttling: These can be addressed by future proposals
Fallback operations: These would be handled in code, not declaratively
Retries for application-to-Dapr communication: Developers may still wish to implement lightweight retries in their code logic

Because this proposal targets many resiliency policy types and spans across all building blocks, it is related to several existing issues:

#1820
#3000
#777
#1289
#2716 (Required for timeouts & retry)

Design
Even the simplest resiliency configuration can be 100+ lines of YAML. To prevent polluting the main configuration, a new Resiliency CRD is proposed in order to promote clear separation of concerns from other features like RBAC. It also creates a distinct boundary for SREs and architects to work in without worrying about impacting other aspects of the system. The new CRD has three main sections: policies, buildingBlocks and apis.
Policy definition
The policies section is where timeout, retry and circuit breaker polices are defined. Each is given a name so they can be referred to from the buildingBlocks and apis sections.
Timeouts
Timeouts only require a duration expressed in Go's time.Duration format.
Retries
Retries follow either a constant or exponential configuration with unique settings for each. These will be based on the existing dapr/kit retry package which uses the popular github.com/cenkalti/backoff package.

Constant configuration:

Field
Description
Default

policy
Should be set to constant.

duration
The duration between tries.
0 meaning that retries are immediate

maxRetries
Optional maximum number retries.

Exponential back off configuration:

Field
Description
Default

policy
Should be set to exponential.

initialInterval
The initial retry interval.
500ms

randomizationFactor
The randomization factor for calculating the randomized interval.
0.5

multiplier
The multipler for the next retry interval.
1.5

maxInterval
Caps the randomized retry interval.
60s

maxElapsedTime
Caps the time spent retrying the operation. Setting this to 0 will try indefinitely.
15m

maxRetries
Optional maximum number retries.

The calculation of the interval is:
Randomized interval = RetryInterval *
                      [range of 1 - RandomizationFactor to 1 + RandomizationFactor]

Circuit breakers
Circuit breakers are unique because they store long-lived state for transitioning between closed, half open and open states. This is a key difference compared to timeouts and retries which only live for the duration of the Dapr API request. This behavior means that circuit breakers have an intrinsic 1-to-1 relationship with a single instance of a Dapr building block (a service or component). The developer should be aware that circuit breaker configurations are treated as named templates and automatically instantiated for each building block used by the application.
For reference, here is how the states transition.

Circuit breakers will leverage an existing, battle tested library such as github.com/sony/gobreaker. The configuration settings will likely be aligned with the library. For example:

Field
Description
Default

maxRequests
The maximum number of requests allowed to pass through when the circuit breaker is half-open.
1

interval
The cyclic period of the closed state for the circuit breaker to clear the internal counts. If 0, the circuit breaker doesn't clear internal counts during the closed state.
0s

timeout
The period of the open state, after which the state of the circuit breaker becomes half-open.
60s

trip
A CEL expression evaluated with the circuit breaker's internal counts whenever a request fails in the closed state. If it evaluates to true, the circuit breaker will be placed into the open state.
consecutiveFailures > 5

The following variables that reflect the circuit breaker's internal state are available to the trip CEL expression:

Variable
Description

requests
The total number of requests

totalSuccesses
The total number of successful requests

totalFailures
The total number of failed requests

consecutiveSuccesses
The number of consecutive successful requests

consecutiveFailures
The number of consecutive failed requests

Building blocks
The buildingBlocks section covers most scenarios by applying policies at the service and component level. This section has three sub sections:

services - used for service invocation. Circuit breakers would ideally be scoped to the service endpoint so the application can avoid calling a single bad instance of an application pool. To achieve this, circuit breakers will need to work closely with the service discovery and load balancing functions of Dapr. For a given Dapr App ID, one or all of timeout, retry and circuitBreaker policies can be specified.

actors - used for actor invocation. A circuitBreakerScope setting controls the granularity at which circuit breakers are tracked: by type or to individual actor ids, or both. Since large numbers of active actors are possible, circuit breakers for individual actors should be retrieved from a LRU cache to prevent memory consumption/leak issues. When ids are being tracked, then an optional circuitBreakerCacheSize can be specified. The default cache size might be ~1000. For a given Actor Type, one or all of timeout, retry and circuitBreaker policies can be specified.

components - used for Dapr-to-component communication. Circuit breakers would have a 1-to-1 relationship with component instances. So a circuit breaker named "pubsubCB" would be instantiated for both a Kafka (e.g. kafka1) and Redis (e.g. redis2) component. For a given component name (i.e. metadata.name), one or all of timeout, retry and circuitBreaker policies can be specified.

routes - used for component-to-Dapr communication. In other words, Dapr sending events to your application. Routes are defined in subscriptions (both declarative and programmatic) and soon input bindings. Circuit breakers have a 1-to-1 relationship with each application route. For a given route/path (e.g dsstatus), one or all of timeout, retry and circuitBreaker policies can be specified.

Note: Observability, HTTP middleware, and name resolution building blocks are out of scope.
Specific API scenarios
The apis section contains rules for how Dapr API calls override policies assigned in the buildingBlocks section.  For each of the Dapr API operations below, timeout and retry policies can be overridden to cater to specific scenarios in the application (e.g. Calling an operation that takes several seconds to complete).

Service Invocation

invoke (should HTTP and gRPC be separate?)

Actors

actorinvoke
actordurableinvoke (future feature)
setreminder (or is that handled at the state store?)

Bindings

input (read?)
output (send?)

Pub/Sub

publish
subscribe (which is really message delivery?)

State Stores (including actor state?)

getstate
setstate
deletestate
getbulkstate
setbulkstate
deletebulkstate

Secret Stores

getsecret
getbulksecret

Note: Overriding circuit breakers for specific APIs is not permitted by design.
Each of the operations has a list of rules based on CEL. If the rule matches, the name of timeout and retry policies are used for the API operation. This will be a similar experience to using the experimental PubSub routing feature.
Example YAML configuration
This example shows policies for a combination of service invocation and pubsub components.
apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
  name: daprResiliency
# Like in the Subscriptions CRD, scopes lists the Dapr App IDs that this
# configuration applies to.
scopes:
  - app1
  - app2
spec:

#------------------------------------------------------------------------------
# PHASE 1: Basic policy definition and applying policies to building blocks
#------------------------------------------------------------------------------

  policies:
    # Timeouts are simple named durations.
    timeouts:
      general: 5s
      important: 60s
      largeResponse: 10s

    # Retries are named templates for and are instantiated for life of the operation.
    retries:
      general: {} # Sane defaults

      pubsubRetry:
        policy: constant
        duration: 5s
        maxRetries: 10

      retryForever:
        policy: exponential
        maxInterval: 15s
        maxRetries: 0 # Retry indefinitely

      important:
        policy: constant
        duration: 5s
        maxRetries: 30

      someOperation:
        policy: exponential
        maxInterval: 15s

      largeResponse:
        policy: constant
        duration: 5s
        maxRetries: 3

    # Circuit breakers are automatically instantiated per component, service endpoint, and application route.
    # using these settings as a template. See logic below under `buildingBlocks`.
    # Circuit breakers maintain counters that can live as long as the Dapr sidecar.
    circuitBreakers:
      general: {} # Sane defaults

      pubsubCB:
        maxRequests: 1
        interval: 8s
        timeout: 45s
        trip: consecutiveFailures > 8

  # This section specifies default policies for:
  # * service invocation
  # * requests to components
  # * events sent to routes
  buildingBlocks:
    services:
      appB:
        timeout: general
        retry: general
        # Circuit breakers for services are scoped per endpoint (e.g. hostname + port).
        # When a breaker is tripped, that route is removed from load balancing for the configured `timeout` duration.
        circuitBreaker: general

    actors:
      myActorType:
        timeout: general
        retry: general
        # Circuit breakers for actors are scoped by type, id, or both.
        # When a breaker is tripped, that type or id is removed from the placement table for the configured `timeout` duration.
        circuitBreaker: general
        circuitBreakerScope: both
        circuitBreakerCacheSize: 5000

    components:
      # For state stores, policies apply to saving and retrieving state.
      # Watching, which is not implemented yet, is out of scope.
      statestore1:
        timeout: general
        retry: general
        # Circuit breakers for components are scoped per component configuration/instance (e.g. redis1).
        # When this breaker is tripped, all interaction to that component is prevented for the configured `timeout` duration.
        circuitBreaker: general

      # For Pub/Sub, policies apply only to publishing.
      # Subscribing/consuming is handled by routes.
      pubsub1:
        retry: pubsubRetry
        circuitBreaker: pubsubCB

      pubsub2:
        retry: pubsubRetry
        circuitBreaker: pubsubCB

    # Routes represent the application's URI/paths that receive incoming events from both
    # PubSub and Input binding components. The route values correspond to the value configured
    # in the Subscription configuration or programmatic call. For input bindings, this is
    # configured in the component metadata via #3566.
    routes:
      'dsstatus.v3':
        timeout: general
        retry: general
        circuitBreaker: general

#------------------------------------------------------------------------------
# PHASE 2: Overriding policies for specific Dapr API operations
#------------------------------------------------------------------------------

  apis:
    invoke:
      - match: appId == "appB"
        # Nested rules: Prevent duplicative checks in rules.
        # Its likely that controler-gen does not support this
        # but apiextensionsv1.JSON can be used as workaround.
        rules:
          - match:
              request.method == "GET" &&
              request.metadata.count > 1000
            timeout: largeResponse
            retry: largeResponse
          - match:
              request.path == "/someOperation"
            retry: someOperation

    publish:
      - match: |
          event.type == "important.event.v1"
        timeout: important
        retry: important

    # subscribe is when Dapr attempts to deliver a pubsub event to an application route.
    subscribe:
      - match: |
          event.type == "important.event.v1"
        timeout: important
        retry: retryForever

Default resiliency.yml that could be installed by dapr init.  Might include commented out examples for Redis.
apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
  name: daprResiliency
scopes:
spec:
  policies:
    # Timeouts are simple named durations.
    timeouts:
      general: 5s
      important: 60s
      largeResponse: 10s

    # Retries are named templates for and are instantiated for life of the operation.
    retries:
      general: {} # Sane defaults

    # Circuit breakers are automatically instantiated per component, service endpoint, and application route.
    # using these settings as a template. See logic below under `buildingBlocks`.
    # Circuit breakers maintain counters that can live as long as the Dapr sidecar.
    circuitBreakers:
      general: {} # Sane defaults

  # This section specifies default policies for:
  # * service invocation
  # * requests to components
  # * events sent to routes
  buildingBlocks:
    services:

    actors:

    components:

    # Routes represent the application's URI/paths that receive incoming events from both
    # PubSub and Input binding components. The route values correspond to the value configured
    # in the Subscription declarative or programmatic configurations.
    routes:

  apis:
    invoke:
    publish:
    subscribe:

Implementation phases
As seen in the YAML example, this feature is proposed to be implemented in two phases:

Phase 1: Basic policy definition and applying policies to building blocks
Phase 2: Overriding policies for specific Dapr API operations

The reasoning is that Phase 2 should have more time to receive feedback from the community. It is an incremental feature that has several touch points in the API code. There could be learning from implementing Phase 1 that could influence the approach in Phase 2.
Cautions / Considerations
Resiliency features can often be misconfigured.

Dropping broker messages (e.g. Kafka)
Writing duplicate records
Self-inflicted DoS / thundering herd

What errors in Dapr are retriable or permanent?

Malformed queries (400) vs communication error (socket read error)
Record not found (404) vs an internal server error (500)
Updates cannot always be retried without idempotency or record versions/timestamps (concurrency)
A component or service may enforce rate limiting (429) and return a prescribed retry interval (which is currently not returned by components). This should override the interval calculated by the retry policy.

Timeouts and retries rely heavily on the Context being passed through Dapr's runtime and components. A review of current error handling and usage of context.Context should be part of implementing this feature.
Vote: Lists vs. Keys/Maps in YAML?!
Thanks for reading this far! Here is something you can weigh in on and maybe have some fun at the same time!
The Dapr maintainers would like to know your preference when it comes to "named things" in YAML.
Do you prefer...
Using keys/maps (as the example above)
or
Using lists instead
While, Dapr uses lists in some cases (e.g. component metadata), don't let that influence your decision ;)

Thanks!

Excellent proposal.  Very well written and thought out!
It may be useful to clarify (perhaps in the Non-Goals section) that retires, etc. do not apply in situations where the Dapr side car instance has crashed or was never started.   In other words, they do not apply at the service (aka app)/dapr communication link, but do apply only at the dapr/component-or-service-invocation communication link.
I have recently encountered this in AKS on starts of my test cluster where the services got started but the sidecar injector did not create their sidecars.  And also when using Docker Compose -- If you do not use depends_on (a service depends_on a dapr sidecar) in the yaml, then the dapr sidecar may not be started before the service.
In these kinds of cases it is up to the calling service (aka app) to supply the appropriate retry logic.  Is this indeed true, or am I missing something?
Thanks.

Great point, @georgestevens99! I've added that to the list of non-goals.

look forward to implement this function

As seen in the YAML example, this feature is proposed to be implemented in two phases:

Phase 1: Basic policy definition and applying policies to building blocks
Phase 2: Overriding policies for specific Dapr API operations

Phase 2 is very important so that the policies can be defined by app developers.

I have question how many requests the resiliency take effect? Maybe we should also consider how it work with the trace and metrics.

Closed. Phase 1 work complete

Currently, Middleware is for HTTP request/reply only.
@beiwei30 Are you suggesting that we make sure that the resiliency patterns can be used by middleware? Or are you suggesting there be a cross-building block middleware concept where resiliency can be applied?

cross-building block middleware concept in my opinion.

Late for the dinner, but will we consider an alternative UX to enable this feature in developing time? i.e. resiliency feature that accessible from Dapr SDK.
Declarative configuration is great for existing apps but when building app with Dapr from scratch, it feels a bit weird to leave my critical API calls unreliable intentionally, remember this "issue" somehow, and then configure resiliency policies separately in Ops time. I'd like to code with resiliency in mind at day 0. It also enables advance features such as customized retry logic.

Late for the dinner, but will we consider an alternative UX to enable this feature in developing time? i.e. resiliency feature that is accessible thru Dapr SDK.
Declarative configuration is great for existing apps but when building app with Dapr from scratch, it feels a bit weird to leave my critical API calls unreliable intentionally, remember this "issue" somehow, and then configure resiliency policies separately in Ops time. I'd like to code with resiliency in mind at day 0. It also enables advance features such as customized retry logic.

This is largely outside the scope of Dapr SDKs and is a solved problem in nearly all languages today. Here's an example for Dotnet:
https://github.com/App-vNext/Polly

Late for the dinner, but will we consider an alternative UX to enable this feature in developing time? i.e. resiliency feature that is accessible thru Dapr SDK.

Declarative configuration is great for existing apps but when building app with Dapr from scratch, it feels a bit weird to leave my critical API calls unreliable intentionally, remember this "issue" somehow, and then configure resiliency policies separately in Ops time. I'd like to code with resiliency in mind at day 0. It also enables advance features such as customized retry logic.

This is largely outside the scope of Dapr SDKs and is a solved problem in nearly all languages today. Here's an example for Dotnet:
https://github.com/App-vNext/Polly

Emm, not sure can I also use Polly to retry Dapr state store call in my code?

Late for the dinner, but will we consider an alternative UX to enable this feature in developing time? i.e. resiliency feature that is accessible thru Dapr SDK.

Declarative configuration is great for existing apps but when building app with Dapr from scratch, it feels a bit weird to leave my critical API calls unreliable intentionally, remember this "issue" somehow, and then configure resiliency policies separately in Ops time. I'd like to code with resiliency in mind at day 0. It also enables advance features such as customized retry logic.

This is largely outside the scope of Dapr SDKs and is a solved problem in nearly all languages today. Here's an example for Dotnet:
https://github.com/App-vNext/Polly

Emm, not sure can I also use Polly to retry Dapr state store call in my code?

Sure you can. You wrap the Dapr State SDK call with Polly. Not only will it cover failures from Dapr to the state store, it will cover the HTTP or gRPC call to Dapr itself, something resiliency policies don't cover today as they are only enabled in the runtime.


Notebook + Scrolled Window Issues

When one of the tabs in a notebook is a scrolled window, the scrollbar policy is automatic, and you are holding down the tab, the scrollbar appears even though it really shouldn't. Even when the scrolled window is empty.

So it's looking like I'm the one finding the weird bugs. :S

I'm not sure if I understood your issue right. Can you provide a minimal example please to reproduce the problem?

http://pastebin.com/UrircCqY
Hold down any of the three tabs. Both the horizontal and vertical scrollbars will appear (make it taller to see the horizontal).


Support approximate comparisons using the approx crate

There are many situations when an approximate comparison is useful for floats. The approx crate appears to the the de-facto standard crate supporting standard approximate comparisons, so implementing the traits for f16 as an optional feature could be a useful addition.

I like the idea of supporting the approx crate in principle, but there's some obstacles that make it less than ideal. Approximate floating point comparisons require both a subtract and abs operator, but no numeric operations are implemented for the f16 type, only basic classification and conversion. This is because there's no hardware support for any of these operations for any of Rust's targets (that I know of) so this would have to be implemented in software, which would likely be less performant than converting to f32 to do operations and then back again (especially if using hardware intrinsics for conversion). Even were we to convert to f32 under the hood (a bad idea to hide that imo), the core rust library does not have an abs operator for f32 or f64 either, so no_std would need to implement that (I admit, this is more trivial to do, but annoying).


Change default to disable pinning of scheduler threads to CPU cores

Prior to this commit, if a random user happened to be running
multiple pony applications that are CPU intensive, they would run
into unnecessary CPU contention due to CPU pinning (at least on
Linux) due to the first few cores being the ones used by all the
applications even if the system may have more cores available. This
was particularly troublesome because users may not even be aware
that the application they're running is a pony application.
This commit changes the default to not pin scheduler threads to CPU
cores. It also removes the --ponynopin CLI argument and replaces
it with the --ponypin CLI argument to leave the control for
pinning as an option for advanced users without requiring all users
of pony applications to understand pinning and how to disable it.
Resolves #3023

Big thumbs up on this.

If this is merged, then I think the performance guide on the website needs to be updated.

@dipinhora can you open a PR to adjust the performance section of the website to account for these changes and then we can merge this?

@SeanTAllen https://github.com/ponylang/ponylang-website/pull/394 created to update the performance guide for the --ponypin changes and also to change it for some recent cycle detector changes.

Thanks @dipinhora. This is awesome.


Device is "readonly" when using wireless dongle

Hey there! I just got my Quick Keys a week ago and already have plans to build a custom config editor. I saw this project and tested out the demo but it was only partially working.
I can select my device and see it log the buttons/scroll, but the sliders don't change anything and neither does the overlay.
Also, I was able to get the demo running in StackBlitz, which means it can be edited and debugged by anyone. The key is the "Open in New Window" feature, that allows the HID functionality to work.

I figured it out! I use the included wireless dongle so when I select a device it says "Xencelabs Dongle - Paired". Unplugged the dongle and connected via USB and it showed up as "Xencelabs Quick Keys - Paired", which did update when I changed colors/overlays/etc. on the demo page.

I've got a fix for this, as well as detecting when the surface connects and disconnects to the dongle and hopefully battery level monitoring too

Demo site is updated, and 0.3.0 is published with the fixes

I see the battery level being displayed, but I still can't show an overlay/change the color using wireless. Any special instructions for the app/order to activate things?

Strange.. are you on mac or windows?
And have you made sure that the xencekeys software is not running?

I'm on Windows 10. I will double check that I stopped the Xencelabs software, that might have been it.

So it's still not working for me via the dongle-only. I did try the node version and I get the same outcome, button presses/wheel turns are read, but setting text/colors doesn't update.
What do you use to debug the data sent back and forth between the device. I'm happy to capture traffic/logs (and learn how to read them).

I have been using wireshark with usbcap (I think usbcap is offered as one of the installer steps). If possible it is best to do it on a machine where you dont have anything else usb plugged in, as it avoids the need to filter out data in wireshark.
After figuring out which usbcap interface to listen on (trial and error), make sure the xencelabs software is running and the dongle unplugged. Start wireshark listening, and plug in the dongle.
Once the panel is connected you should have a load of usb packets in wireshark.
Reading the data is tricky. The main thing is to look at the URB_INTERRUPT out and URB_INTERRUPT in lines. out are messages sent from the computer to the device, and in the other way. Each one is formed of a message and an acknowledgement (which are not interesting). Inside those is a HID Data blob of hex, which is the data we are interested in.
If you skim through the URB_INTERRUPT out messages, you should be able to visibly see the text labels from your device.
If you could share a capture of this data that would be helpful so that I can try and look into what it is doing differently. There are 6 bytes in the middle of most of the messages which are required, but I dont know what they mean. Perhaps that is a device id? That would explain why it works for mine but not for others. I did miss it on one command for a bit meaning it worked wired but not wireless

Sounds good, I will setup wireshark on a laptop and give it a shot (I tried it on my desktop, waaaay too much USB traffic, haha).
Thanks for your help!!

So, without getting a full dump, I already see one major difference. These are the bytes when setting five for the bottom left button:
  XenceLabs: 1b 00 e0 47 24 cb 0f d1 ff ff 00 00 00 00 09 00 00 01 00 25 00 03 01 20 00 00 00 02 b1 00 05 00 08 00 00 00 00 ed 74 0e 8a 95 dd 66 00 69 00 76 00 65 00 00 00 00 00 00 00 00 00
WebHID Demo: 1b 00 e0 47 2a c1 0f d1 ff ff 00 00 00 00 09 00 00 01 00 25 00 03 01 20 00 00 00 02 b1 00 05 00 08 00 00 00 00 eb 4f 49 bd d7 fa 66 00 69 00 76 00 65 00 00 00 00 00 00 00 00 00
                         ^^ ^^                                                                                ^^ ^^ ^^ ^^ ^^ ^^

I'm not sure what's going on with that first part but the second set of differences is definitely an identifier. I checked and it matches the "" displayed in the Diagnostics screen of the Xencelabs App. So now the question is can we get that value programmatically?
(see the Paired Devices list below, the byte diff above includes ed 74 0e 8a 95 dd which matches Quick Keys#ed740e8a95dd

Perfect, that is exactly what I was suspecting.
I already starting digging, and found where I think that is coming from, so I shall see if I can read that in properly

So it turns out that the place where the device declares its id is not available through webhid at all, but could be made to be available in the node version, but will take some time for a couple of PRs upstream.
Before I do that I shall see if I can find a weirder way of fetching the id, I am hopeful

You might have found it somewhere else, but it does look like the deviceId is sent with every button press. So one possible approach would be to add a "press any key on device to confirm" and then just extract and re-use that ID. It also includes it when "connected" emits, which could also work.

Yeah, the 'proper' way to get the id is to use hid_get_indexed_string from the underlying library. That appears to be what the xencelabs software is doing.
However, the underlying library has not implemented this on every platform, and there is not a matching way to do it for webhid.
When using the dongle, the software is doing what looks like a query for its connected status, with the response including the id, so that would be a good way to reliably get the id before attempting to do anything with the device.
For wired devices, the id isnt essential and I dont have an idea on how yet. But it would be really useful to have. Something to come back to once wireless is working properly

@jimbuck Thanks for looking into fixing this! I was trying to install your webhid-wireless-single-device fork using npm and tried a lot of different solutions looking around on how to install specific branches using npm but I couldn't get i to work. I much amit I am not that experienced  :) I am building a remote using this node js module and also runs into the problems when I try to run Quickkeys wireless.

I've been working on a rework of the library to better handle this id as well as having multiple panels connected to the one dongle.
Its not done yet, its a complete rethink of how devices are handled/managed as opening the dongle can produce 0, 1 or 2 active panels https://github.com/Julusian/node-xencelabs-quick-keys/pull/5

Great news, thanks Julian! Merry christmas by the way 😊

I am happy with how #5 is behaving, I have updated the webhid-demo to handle multiple concurrent devices, and so it even handles a single panel on the one dongle. Wired devices also still work, but havent been tested in the nodeks implementation yet.
This is a pretty large rewrite of the api for opening devices. I havent added any device auto-detection into the api yet, but I am considering it

Happy New Year! 🥂
I will try to pull it down and test with it this week.

Hi. Just tried the 4.0 webhid-demo in newest Chrome on OS X 11.6 and seems to run just flawless but I don't get how to use this new 4.0 node js module? I am not that experienced. Could someone make a small example like the one in the NPM module frontpage for v3.0? Thanks again Julusian for this great addition of multi device support and by the way my feature request for graphics/icons to XenceLabs was kindly replied that they would forward it to their software team.... Here's for hoping!

I don't have a simple example currently, but you can see the implementation I have written to use this in companion-satellite.
The relevant bits are https://github.com/bitfocus/companion-satellite/blob/feat/satellite-api-v2/src/device-types/xencelabs-quick-keys.ts https://github.com/bitfocus/companion-satellite/blob/feat/satellite-api-v2/src/devices.ts#L39-L46 https://github.com/bitfocus/companion-satellite/blob/feat/satellite-api-v2/src/devices.ts#L168-L178
I do think the api for scanning/getting devices here is a bit unusual, but thats an unfortunate consequence of the wireless dongle supporting multiple panels..
I forgot to update the example in the docs, I shall try and do that soon https://github.com/Julusian/node-xencelabs-quick-keys/tree/main/packages/node#api


[BUG] Importing the @openfeature/launchdarkly-client-provider throws a TypeError

Observed behavior
I installed the @openfeature/web-sdk and @openfeature/launchdarkly-client-provider packages using pnpm install.
Upon trying to simply import the LaunchDarklyClientProvider via import { LaunchDarklyClientProvider } from "@openfeature/launchdarkly-client-provider"; and running my local app (it's the boilerplate Vite React project that the Vite install provides) a TypeError.
open-feature-event-emitter.ts:11 Uncaught TypeError: import_events.default is not a constructor
    at new GenericEventEmitter (open-feature-event-emitter.ts:11:35)
    at new InternalEventEmitter (open-feature-event-emitter.ts:83:8)
    at new OpenFeatureCommonAPI (open-feature.ts:21:30)
    at new OpenFeatureAPI (open-feature.ts:18:5)
    at OpenFeatureAPI.getInstance (open-feature.ts:32:22)
    at open-feature.ts:92:43

Expected Behavior
I expected the provider to be able to be imported without a TypeError being thrown so that it can be instantiated into the OpenFeature.setProvider method.
Steps to reproduce

Install the @openfeature/web-sdk library (This may not be necessary as the issue occurs when just importing the provider library below)
Install the @openfeature/launchdarkly-client-provider library
Create a new file, say featureFlags.ts with the following (this is as bare of code you can write to reproduce the issue, I understand it's not creating a LaunchDarklyClientProvider instance or doing anything with the import, you could skip this step and just import the provider library directly into a file your app is already using)

import { LaunchDarklyClientProvider } from "@openfeature/launchdarkly-client-provider";

Import that file into your app, something like

import './featureFlags';

TypeError is thrown upon running the application

@toddbaert Just created the issue about the constructor error. Please let me know if you need more details.

Thanks @juanparadox . Can you confirm the versions you're using (I'm assuming both @ latest)?
And are you using yarn or npm? (They behave a bit differently with peer dependencies, which may be related to the problem).

@toddbaert Yeah! They are both at the latest versions and I am using pnpm.

@toddbaert Yeah! They are both at the latest versions and I am using pnpm.

I believe pnpm doesn't automatically install peer dependencies. Can you confirm @openfeature/core is installed?

@toddbaert I just manually installed @openfeature/core with pnpm and the error still occurs.

@toddbaert I just manually installed @openfeature/core with pnpm and the error still occurs.

Ok thanks again! I'll try to replicate the issue myself and get back to you 🙏

Thank you very much!

@juanparadox fix is released. Please let me know if your problem is resolved.

@toddbaert Fix looks to have worked! Thank you!


Ability to add subboard/other board via "components" selector?

I'd find it really intuitive if there was a "Other Board" or similar entry in the "components" selector, that lets me add another board (or a subboard) to my current one.
As far as I know, the only way to achieve that currently is to open the other board, copy it's URL and paste that into the first board.

Something like this?


Feature Request: mupdf plugin in Debian repository

On GitLab by @buendia on May 5, 2021, 11:59

This actually is a feature request for viewing epub files on debian based systems without having to set up the plugin by the user.
According to this, mupdf isn't stable enough(?) But it's from 2017, hasn't things changed?

If you want to have a package for that, please package it (see https://mentors.debian.net/intro-maintainers/) or follow up on the bug there. This is the wrong place for questions on Debian packages.

closed


Fixes inconsistent energy between k-RCCSD and k-UCCSD

There is an inconsistency in energy between k-RCCSD and k-UCCSD, which is due to the divergent exact exchange correction of the mean field energy. More generally, I think this will also affect k-RCCSD calculation on top of non-converged HF mean-fields, such as LDA - the main issue is that the k-RCCSD kernel, opposed to all other CCSD kernels, does not set the attribute e_hf,
and the e_tot property thus falls back to using self._scf.e_tot as the mean-field energy.
The inconsistency between k-RCCSD and k-UCCSD then arises hence self._scf.e_tot by default includes the exxdiv correction,
whereas eris.e_hf does not, since the HF potential is build without this correction in the _common_init_ of the ERIs.
For k-RCCSD@LDA the issue will likely be even worse, since E_LDA will be very different from E_HF[DM_LDA].
This fix will make ensure that k-RCCSD behaves like k-UCCSD (and also agrees with the Gamma-point pbc.ccsd classes, for Gamma-point only calculations. The code I used to verify this is attached below.
There is still another, related question, which is if we should not use the exxdiv correction for the HF energy part of the CCSD total energy by default (but not for the eris.fock, used in the CCSD eqs. and correlation energy, of course).
I think there is some justification for this, as exxdiv accelerates convergence to the thermodynamic limit, and combining a HF energy with exxdiv with a CCSD correlation energy without exxdiv is similar to combining, say, a E(HF) on a 6x6x6 k-point grid with a E(corr) calculated on a 3x3x3 grid - a somewhat common approach to converge energetics.
One big benefit of this would be that ccsd.e_tot = hf.e_tot + ccsd.e_corr will be true again (for converged HF calculations), as most users would expect.
example.py.txt

Hi Max, thanks for pointing this out. In fact, I think I had noticed this also but sadly didn't address it further as you just did. I personally would prefer keeping the exxdiv affected HF energy in the total CCSD energy, i.e. changing the behaviour of KUCCSD rather than KRCCSD. I prefer if the total CCSD energy is the sum of HF energy and CCSD corr energy pyscf gives me along the way when calculating and therefore I prefer the behaviour of KRCCSD over KUCCSD, i.e. I think total CCSD energy should differ when I do exxdiv=None or when I do exxdiv="ewald".

I personally would prefer keeping the exxdiv affected HF energy in the total CCSD energy, i.e. changing the behaviour of KUCCSD rather than KRCCSD

Yes that would be my preference as well - unfortunately, the way that k-RCCSD "achieved" this (by using cc._scf.e_tot) is not very robust at all

I had a closer look to follow what you said. It seems like the issue arises from the fact that pbc/cc/rccsd_rhf.py does not call  the ccsd function in cc/ccsd/ccsd.py as for example pbc/cc/rccsd_uhf.py does (via a wrapper) but instead has its own ccsd function. This can probably be improved I think to keep the code cleaner (i.e. make pbc/cc/rccsd_rhf.py call the ccsd function in cc/ccsd/ccsd.py, too, via a wrapper). Why do you think using modifying cc/ccsd/ccsd.py to use cc._scf.e_tot immediately is not a good idea (instead of trying to get e_hf from eris.e_hf first)? A solution might be to modify the ccsd function in cc/ccsd/ccsd.py to not check e_hf from eris.e_hf first but I haven't checked what other implications this might have. The deviation in behaviour is of course, as you said, that eris.e_hf does not contain the effects of exxdiv unless the user set keep_exxdiv to True.

I checked and this usage of eris.e_hf first before trying cc._scf.e_tot was introduced in commit db64a063f42fee15cbb7dc1b348c2ded88291387 to deal with cases where the SCF was not converged. In eris, the HF energy was recomputed, so this non convergence issue was solved. However, in pbc cases, eris often ignores exxdiv and therefore its recomputed HF energy is probably not be used as the HF energy. Maybe there should be a function that recomputes the HF energy refactored out, in the eris class this function can be called with exxdiv removed by default, and in the main CCSD kernels, this class can be called with exxdiv left in.

Hi Verena,
I think not/never using cc._scf.e_tot is the right call - it's not just about non-converged HF, but also DFT, where e_tot is the KS energy.
I also don't really think this mean-field energy belongs into the _ChemistERIs object - I would suggest to add a function to the CCSD class itself, which returns Hartree-Fock potential and energy (based on the density in cc._scf.make_rdm1())
The ERIs can then also use this HF potential in _common_init_, as needed since they also store the (active-space part of the) Fock matrix.
It's also easy to go from a HF potential with exxdiv to one without, you just need to shift the diagonal of the occupied block by a factor of the Madelung constant (at least that's true for 'ewald'), so we can use the potential with exxdiv to calculate the energy, and then remove it (unless keep_exxdiv == True) to pass it to the ERIs.

I agree, I think a function in the CCSD class, or maybe actually in the HF class (?) so it is accessible for other post HF methods, to get the HF energy (containing vhf, dm and finally e_tot evaluation) is a good idea, with lib.temporary_env appropriately placed to remove the effect of exxdiv if required. This can be called from the eris class (exxdiv effect usually removed), as well as the ccsd classes (exxdiv effect not removed) for example. I think we shouldn't use the madelung constant to move from removed exxdiv to applied exxdiv, if we can avoid it, as non ewald exxdiv don't use the madelung constant.

Haha seems like this was merged was faster than our conversation :D . I would prefer if the exxdiv stays in e_tot in CCSD, so I guess I'll make a new PR which does the above mentioned refactoring and then restored the exxdiv behaviour for KRCCSD, but also brings it to KUCCSD, etc :)

I think merging this is good, the exxdiv was already removed in Gamma-point and KUCCSD, as you said, now it's consistent (and for HF mean-fields you can relatively simply use hf.e_tot + cc.e_corr to get the exxdiv corrected energy.
But yes, I'm all for making the change to an exxdiv corrected cc.e_tot.

I guess I misunderstood the issue. When looking at cc.e_tot, I guess most people would think it is e_hf + e_tot . So probably the exxdiv should be consistently contained in cc.e_tot since it is contained in scf total energy by defaults. Otherwise it may get more confusion that HF energy is higher than cc.e_tot.

@sunqm Yes, I agree. I think @verena-neufeld will make a PR to get this behavior.

Without adding any suggestion to refactoring, I want to add that I think
there is now consensus that the CC correlation energy should never be
computing with orbital energies containing an exxdiv correction. If others
agree, then any cleanup of the code shouldn't even allow other choices
(level_shift exists if needed). However, this has an annoying artifact: the
initial CC energy won't match the "correct" MP2 correlation energy (which I
think people agree should be calculated with orbital energies that do
contain an exxdiv correction). I suppose we could make the initial t2 guess
include some kind of exxdiv. Also, I imagine a similar issue pops up for
CCSD(T).
On Wed, Aug 3, 2022 at 12:46 PM Verena Neufeld @.***>
wrote:

I agree, I think a function in the CCSD class, or maybe actually in the HF
class (?) so it is accessible for other post HF methods, to get the HF
energy (containing vhf, dm and finally e_tot evaluation) is a good idea,
with lib.temporary_env appropriately placed to remove the effect of exxdiv
if required. This can be called from the eris class (exxdiv effect
usually removed), as well as the ccsd classes (exxdiv effect not removed)
for example. I think we shouldn't use the madelung constant to move from
removed exxdiv to applied exxdiv, if we can avoid it, as non ewald exxdiv
don't use the madelung constant.
—
Reply to this email directly, view it on GitHub
https://github.com/pyscf/pyscf/pull/1350#issuecomment-1204217334, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGAJCZ7J6PHGDNGGZCH33LVXKPADANCNFSM54XNKSIA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi Tim,
I agree that this is an issue and should be looked at. I have a few questions:

I want to add that I think
there is now consensus that the CC correlation energy should never be
computing with orbital energies containing an exxdiv correction

When you say "orbital energies" do you mean the Fock[occ,vir] * T1 contribution to Ecorr(CCSD) for a non-HF reference?
For this term I assumed it would not matter if done with or without exxdiv, since the latter only affects the occupied-occupied block, i.e. only modifies the mean-field energy itself?
There is of course a difference when it comes to which Fock matrix is used for the T-amplitude updates; have you found that this should better be the uncorrected Fock matrix (as it is in the code right now)?

However, this has an annoying artifact: the
initial CC energy won't match the "correct" MP2 correlation energy (which I
think people agree should be calculated with orbital energies that do
contain an exxdiv correction). I suppose we could make the initial t2 guess
include some kind of exxdiv

I actually thought the MP2 intial guess does include the exxdiv correction, since it uses eris.mo_energy (rather than eris.fock) to construct the amplitudes and the latter should be exxdiv corrected? This might be only true for the 'ewald' correction though.

Hi Max,
Yes, I mean the second part (i.e., "which" Fock matrix, and whether Foo has
corrections) and indeed believe that the "uncorrected" one is appropriate
to use in CC. Roughly, if you consistently track the appearance of all
leading-order G=0 divergences, e.g., in ERIs like (pp|qq), then, in
addition to those appearing in the Fock eigenvalues, there are also a set
of corrections that appear in the T amplitude updates, and it turns out
that they all cancel. So whether you correct for this everywhere or
nowhere, you get the same answer; correcting only in the Fock eigenvalues
is inconsistent. I have a rough set of notes I'm happy to send you
separately if you're interested.
Regarding MP2, yes, I think you're right -- it's been a while since I've
looked at the code! It looks like everything behaves the way I would
suggest (with the ewald type correction playing two roles, i.e. to make
the initial guess the correct MP2 one and to improve convergence as a kind
of modified preconditioner/level shift).
On Tue, Oct 11, 2022 at 6:40 AM Max @.***> wrote:

Hi Tim,
I agree that this is an issue and should be looked at. I have a few
questions:
I want to add that I think
there is now consensus that the CC correlation energy should never be
computing with orbital energies containing an exxdiv correction
When you say "orbital energies" do you mean the Fock[occ,vir] * T1
contribution to Ecorr(CCSD) for a non-HF reference?
For this term I assumed it would not matter if done with or without
exxdiv, since the latter only affects the occupied-occupied block, i.e.
only modifies the mean-field energy itself?
There is of course a difference when it comes to which Fock matrix is used
for the T-amplitude updates; have you found that this should better be the
uncorrected Fock matrix (as it is in the code right now)?
However, this has an annoying artifact: the
initial CC energy won't match the "correct" MP2 correlation energy (which I
think people agree should be calculated with orbital energies that do
contain an exxdiv correction). I suppose we could make the initial t2 guess
include some kind of exxdiv
I actually thought the MP2 intial guess does include the exxdiv
correction, since it uses eris.mo_energy (rather than eris.fock) to
construct the amplitudes and the latter should be exxdiv corrected? This
might be only true for the 'ewald' correction though.
—
Reply to this email directly, view it on GitHub
https://github.com/pyscf/pyscf/pull/1350#issuecomment-1274484908, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGAJCZ4NUZMSSYQZBQ7T3LWCU7Y5ANCNFSM54XNKSIA
.
You are receiving this because you commented.Message ID:
@.***>

Yes, I mean the second part (i.e., "which" Fock matrix, and whether Foo has
corrections) and indeed believe that the "uncorrected" one is appropriate
to use in CC. Roughly, if you consistently track the appearance of all
leading-order G=0 divergences, e.g., in ERIs like (pp|qq), then, in
addition to those appearing in the Fock eigenvalues, there are also a set
of corrections that appear in the T amplitude updates, and it turns out
that they all cancel. So whether you correct for this everywhere or
nowhere, you get the same answer; correcting only in the Fock eigenvalues
is inconsistent. I have a rough set of notes I'm happy to send you
separately if you're interested.

This is quite interesting. If you say correcting everywhere and nowhere get's the same answer, why do you favor the uncorrected approach? It seem's that the corrected approach might be more in-line with the way we do MP2?
There is also the dependence on the HF orbitals, rather than just the orbital energies:
with correct nowhere, do you mean that the HF itself is converged without an exxdiv correction?

This is quite interesting. If you say correcting everywhere and nowhere get's the same answer, why do you favor the uncorrected approach? It seem's that the corrected approach might be more in-line with the way we do MP2.

[edit: It came to me that "correcting everywhere" probably requires changes in additional terms in the CCSD amplitude update, not currently implemented in PySCF...]

Yes, exactly (the edit). If you get the same answer, then might as well use the simpler version. 😅

There is also the dependence on the HF orbitals, rather than just the orbital energies:
with correct nowhere, do you mean that the HF itself is converged without an exxdiv correction?

Right, I'm strictly assuming HF orbitals throughout, and note that the HF orbitals are identical with exxdiv=None and exxdiv='ewald' (but not for other exxdiv). So when I say "correct nowhere", I mean you have a converged HF solution with either of those two options, such that the orbitals are identical (but the HF total energy and HF occupied orbital energies are different by terms proportional to the Madelung constant).


Jonmv/messagebus avoid config self subscription

@baldersheim please review and merge.

Oof, branch name used as PR name. Will change. Yes, just reading code so far :)

Guess those conflicts were resolved by a revert of something else? :P

Yeah, this one: https://github.com/vespa-engine/vespa/pull/15495


Why does 3.0 look so much like react? Have you considered the ideas of most Vue developers?

SB
！！！！！！！！！！！！！！！！！！

I think it's good :> Please see RFC know the detail more.
The feature so handy to development

It looks nothing like React and it was asked for by devs for better code reusability and better TypeScript support. And, it's progressive, meaning, if you don't want to use it, you don't have to.
Scott

yeah, as Even say, you can continue using v2 if you like, it's not forced. v3 complete compatible with v2, v2 not deprecated


[BUG] Old version stays behind

Describe the bug
Currently, the old version of an updated mod doesn't get removed, causing errors at startup
To Reproduce
Steps to reproduce the behavior:

Update a mod
Exit the game
Start the game again with updated mods
See error

Expected behavior
When updating a mod, remove the older version
Screenshots

** Please complete the following information:**

OS: Windows 10 Pro
Minecraft version: 1.17.1
Version 1.0.2-alpha

Additional note
When saving the file, try to look for any mods with a similar name and ignore the numbers, and delete it.

@PKMNPlatin

I will close this when the issue persist feel free to open this again

Opening again because of #66

My problem is it also downloads the wrong version of a mod that is for a older version of minecraft

Can you open a separate issue for that one and upload you log files to that


dev-it tests fail on Java 17

For issue tracking
Additional context and information found in #1525

Resolved with #1571


question

@314 Looking at #350 I see the example of an '=' but are there other operators I can leverage, for example if I wanted to do a like 'something' or in(a,b,c) would it be possible to do?

https://github.com/kentik/ktranslate/blob/9cf390bb2fe675d6d84ea7a209bb3db296451972/pkg/inputs/snmp/metrics/device_metrics.go#L429 that leads me to believe we only support exact matches, yes?

You are right in your hunch that right now only = will work. Wouldn't be that hard to extend though to other operators.


Add Hash#last_key and Hash#last_value

Cloned from Hash#first_key and Hash#first_value.
Enumerable#last isn't done yet.

Somebody to review?


Selection chip component

Acceptance Criteria:

"Selection chip" Figma design
See selection chip examples for Screen reader behaviour
Allow a Leading Icon, and if one is supplied, it takes precedence over our leading icon
This is a new component

Closing as we need more evidence that this component is actually needed


Review association scores and ranking features within platform

Description

[ ] WHY - What is the problem this feature would answer?

Develop additional scores to enable prioritisation (e.g. tractability)

Develop and refine scoring methods and scores that improve the identification and prioritisation of targets

Develop and assess new methods that will contribute to improved scoring

[ ] HOW are we going to solve the problem?

Review technical options and viability to validate and prioritise requirements suggested below as part of this:
a) As a user, I would like the ability to exclude a particular dataset or datatype from the association score.
b) As a user, I would like a facet in the associations page to filter the score - either numerically, or via category eg. "high confidence", "some evidence", "low confidence".
c) As a user I would like to change the weightings in the score dynamically as an advanced view (may be of value to fewer users overall).
d) As a user, I would like to associate targets to a disease based upon similar differential expression profiles in the disease
e) As a user, in the disease associations page, I would like to find the ranking of my gene
For example, for Multiple Sclerosis, >2700 targets but user may wish to focus on CD86, for example so how can they find out if this is in the top 200 genes?  (currently via download of csv).
f) Targets which have failed clinical trials should be severely penalized in the overall ranking. Currently we only consider biological evidence, but we don't leverage the real world evidence which often shows the lack of efficacy of some of the targets associated with disease.
g) Should we take information on the off-target effect of drugs into the scoring system?

[ ] WHAT would this look like?

Progress Tracker

Closing as any agreed actions will be addressed as appropriate within platform repository roadmap epics.


Kernel, Distro, VM object types not documented

[ ] Distro
[ ] Kernel
[ ] VM
[ ] PERL

Code:
say WHAT $*DISTRO;
say WHAT $*KERNEL;
say WHAT $*VM;
say WHAT $*PERL;

Result:
(Distro)
(Kernel)
(VM)
(Perl)

https://github.com/rakudo/rakudo/blob/beec02a6fa69e3ac290b4dd24c07d87a9f248b13/docs/announce/2014.05.md#L30
What does full blow object means in this context?
***added $*KERNEL, $DISTRO, $VM, $PERL as full blown objects

What does full blown object means in this context?

Actually, not much. But, for example, $*PERL previously returned a Hash.
For example (results before and after it was changed):

<AlexDaniel> c: 0a6c98c05d4^,0a6c98c05d4 say $*PERL
<committable6> AlexDaniel, ¦0a6c98c05d4^: «{"compiler" => {"release-number" => "", "ver" => "2014.04-264-g3216e7334", "name" => "rakudo", "codename" => "", "build-date" => "2017-05-22T19:44:33Z"}, "name" => "rakudo"}» ¦0a6c98c: «Perl 6»

And we can see when exactly they were implemented like so:

<AlexDaniel> bisect: old=Bajor~100 new=Bajor say $*DISTRO
<bisectable6> AlexDaniel, Bisecting by exit code (old=Bajor~100 new=Bajor). Old exit code: 1
<bisectable6> AlexDaniel, bisect log: https://gist.github.com/25c485ccd0e67beed0a48e5330b155c0
<bisectable6> AlexDaniel, (2014-05-12) https://github.com/rakudo/rakudo/commit/4555386e9e1e823477d5dadb6a21e32fe646b4fa

So here are the relevant commits:

$*KERNEL – https://github.com/rakudo/rakudo/commit/26ddce236338d7e600cdeede66ea71f8632ced46
$*DISTRO – https://github.com/rakudo/rakudo/commit/4555386e9e1e823477d5dadb6a21e32fe646b4fa
$*VM – https://github.com/rakudo/rakudo/commit/65f75fb765d1e0c334c30fe5c3a52622e8b72afb
$*PERL – https://github.com/rakudo/rakudo/commit/0a6c98c05d41aedd570af53aea916d4ded8e8174

Initial version of Distro information pushed with 6fef43cb4a7c3ff5f

Initial version of VM information pushed with db79ec9c3da23f6d0f

Initial version of Perl information pushed with b558e0936b

Probably need to add Systemic and Compiler to this list.  But too tired for that now.

Should we add a warning that all this stuff is not specced?


amberol: add updateScript

Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/1016/22

It doesn’t need here. https://github.com/NixOS/nixpkgs/pull/182549#discussion_r928163642

It never got auto update. Maybe something went wrong. https://r.ryantm.com/log/amberol/2022-12-12.log Not sure if repology.org is always up-to-date.


Create Create Calendar.c

Created Calendar for the year 2021 using C language.

@all-contributors add @tmahima for code


Load partial context dynamically

i was trying to turn that fiddle http://jsfiddle.net/crl/5yt6M/104/ in this one http://jsfiddle.net/crl/5yt6M/106/ where the tree is flattened, and next nodes are accessed by a global helper, problem: I don't think the current syntax supports this

The problem is that you've tried to use the global helper as an array.
Slight changes to the helper and to how you call the helper, and we get a working solution:
http://jsfiddle.net/5yt6M/107/

yes good point, thanks, nice, (I'll post on SO with the right tag next time)
where can I read on what are the possible expression inside ()?


Angular 9+: Warning: Entry point 'ng2-ace-editor' contains deep imports

Hi,
Using Angular 9 and 10, it shows the following Warning:
Warning: Entry point 'ng2-ace-editor' contains deep imports into <project>/node_modules/brace/theme/monokai'. This is probably not a problem, but may cause the compilation of entry points to be out of order.
Regards,

We also need support for angular 10 too. Currently facing this warning during build
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.

I created angular 9 version , hope it helps
https://github.com/martinpagesaal/ngx-ace-editor-wrapper

how about Angular 12 version?

Any workaround lib for Angular 12 version?

Currently looking any upgrade version Angular 13 version.

npm i --force worked for me


scripts: don't build platform during build metasystem; simplify platform install; rename scripts corresponding to components names

Dependencies:

https://github.com/ostis-ai/sc-machine/pull/372
https://github.com/ostis-ai/sc-component-manager/pull/88
https://github.com/ostis-ai/ostis-web-platform/pull/108

You test some another branch


Find partials in bin/resolve by using both shorthand and absolute path strings

Fixes #49.
The Problem
Since bin/resolve is dynamic in how it handles developers' input, it was a bit of a challenge to find the files. The fix I proposed in #23 helped smooth things over for resolving devise/shared/oauth, but it didn't get to the root of the problem.
The Approach
There were two main things I tackled here:

Resolving partials depending on whether they started with app/ or not when reading the annotation string.
Resolving partials that needed locals we weren't providing, resulting in an error when trying to call ApplicationController.render.

I stumbled across the second issue here when trying to run the following commands, which didn't work:
> bin/resolve account/shared/forms/errors
> bin/resolve shared/fields/password_field

However, I managed to return the proper strings, although the code itself isn't entirely conventional since I used error handling to find the correct partial. I'd be glad to look over the code, but at any rate this should return the correct partials when using either shorthand or absolute paths:
> bin/resolve devise/shared/oauth
> bin/resolve --interactive
# And then copying and pasting <!-- BEGIN /home/gazayas/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bullet_train-themes-light-1.0.22/app/views/themes/light/layouts/_devise.html.erb -->

Tests are failing because we don't have spring installed, but we should be fine besides that.

Brought up in bullet_train#238, but the tests were failing here so I merged in main to fix the previously failing test.
With this branch, we should currently get the following result:
> bin/resolve --interactive

OK, paste what you've got for us and hit <Return>!

<!-- BEGIN /home/gazayas/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bullet_train-1.0.81/app/views/devise/sessions/new.html.erb -->

Absolute path:
  /home/gazayas/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bullet_train-1.0.81/app/views/devise/sessions/new.html.erb

Package name:
  bullet_train-1.0.81

Would you like to eject the file into the local project? (y/n)
y
Ejecting `/home/gazayas/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bullet_train-1.0.81/app/views/devise/sessions/new.html.erb` to `./app/views/devise/sessions/new.html.erb`

Looking at the TODO in the resolver system test (and the comments in bullet_train-themes-light#19), I think this PR in part helps resolve the test over there, I'm currently just looking to see how it'll point to the current main repository where the file was ejected as opposed to the bullet_train-themes-light package.
I think I'll make another PR over there that:

Relies upon this one
Updates light in the resolver system test to the current_theme

I updated the logic here so whenever a theme is ejected, bin/resolve will ignore searching for a package and simply look in Rails.root for the correct partial. The resolver system test will pass after ejecting a theme as long as we have the logic in bullet_train-themes-light#28 included.

Trying to mull over how we should handle developer input like this:
> bin/resolve app/views/themes/light/layouts/_devise.html.erb

A Possible Solution
The only solution I can currently think of is to grab all the packages via bundle show package_name, use something like File.exists?, and then return the file when it hits true.
The only thing I'm afraid of is that bundle show will be too slow if we try to get every package.
So my question is, would we want to implement this using bundle show, or should we just raise an error saying they should provide the absolute path? Is there a more efficient way without the context of the package?
Package names with absolute path
The reason I'm asking is because we have an if statement in the current resolver that looks like this when the path is provided:
if result[:absolute_path].include?("/bullet_train")
  base_path = "bullet_train" + result[:absolute_path].partition("/bullet_train").last
  # etc...
end

Since we have the absolute path with this code it's easy to infer which package they're using from the string provided, but I'm afraid things will get a little sticky if we aren't provided the package name.

@gazayas Great stuff here! Feel free to open up a new issue for the more recent thing. Thanks!

@andrewculver Sounds like a good idea, that would help to hear everybody's feedback now that people have been using bin/resolve for a bit.


VS Mac .NET Core tutorials

Fixes #18512
Fixes #18513
Fixes #18749
In addition to creating the VS Mac series, this PR makes the 3 "swim lanes" as similar as possible, so some changes were made to the VS and VS Code series as well.

A related issue:  given that Macs have keyboard labels all in lowercase (enter, control, option, command, etc., should those keys be represented by, e.g., command or Command


Warn instead of erroring when max_font_atlases is exceeded

Objective
Fixes #6642
In a way that doesn't create any breaking changes, as a possible way to fix the above in a patch release.
Solution
Don't actually remove font atlases when max_font_atlases is exceeded. Add a warning instead.
Keep TextError::ExceedMaxTextAtlases and TextSettings as-is so we don't break anything.
This is a bit of a cop-out, but the problems revealed by #6642 seem very challenging to fix properly.
Maybe follow up later with something more like https://github.com/rparrett/bevy/commits/remove-max-font-atlases later, if this is the direction we want to go.
Note
See previous attempt at a "simple fix" that only solved some of the issues: #6666

bors r+

bors retry

bors r+


Android Studio

Add Android Studio support from elementc

@yurembo have you built this yet? I actually still haven't overcome any of the bugs and problems I listed in the forum thread. Was waiting for AS2 which is supposed to have some NDK fixes.

@elementc
yes, this works really fine from "the box"!
thanks for your great job!

If it's alright, mind if I issue the PR from my repo directly? For my resume.

Of couse, you should make this!

Issued as #278, feel free to close. Thanks for the extra testing!

I have noticed only one thing: Windows users would append ".cmd" to the lines $ndkDir/ndk-build in a "build.gradle (Module: app)" file. Otherwise a building process would fall. Because command files on Mac OS X have not an extension but on Windows these have a ".cmd" extension.

I'd welcome a PR to fix that, I don't have a windows machine with AS set up at the moment.


spinlock: validate: fix the dependency with MP_NUM_CPUS

the implementation of spinlock validation uses two LSB bits in the
bottom of a pointer union to store a CPU index, which only has space
for 4 CPUS. the MP_NUM_CPUS should be <= 4.
https://github.com/zephyrproject-rtos/zephyr/blob/43187e2723cfa6d095968f74726b24d7297329d5/kernel/thread.c#L861-L890

@abrodkin  care to review this please?

@abrodkin  care to review this please?

@andyross  review please.

@andyross  review please.


Any way to get the new index I dragged to

I am using dropModel event but there is no argument about the index.
I am trying to get the index like that:
Vue.vueDragula.eventBus.$on('dropModel', ([bag, el, target, source]) => {
  const index = Array.prototype.indexOf.call(target.children[i], el)
})

But the index always is -1, because the new element from target is not equal to the old element from source (More than 2 containers), it's a new object.
BTW, Is there any way to get the item from v-for array? Not the HTML element.

An unsatisfactory solution:
Vue.vueDragula.eventBus.$on('drop', ([bag, el, target, source, sibling]) => { // replace dropModel with drop event, and has 4 arguments
  let index = -1
  if (sibling) index = Array.prototype.indexOf.call(target.children, sibling) - 1
  else index = target.children.length - 1
})

Any better way?

dropIndex is exposed as a 5th element in dropModel callback args


Duplicate SOMRIG devices created during import

I have 3 SOMRIG button devices in my smart home setup. During the inital setup I've ended up with 6 devices in total in HA. The duplicates are all named IKEA Dirigera Hub : <IP_ADDRESS> and do not have any entities.

dirigera-devices.json

Can you check with the latest release again.

Duplicates still there with <IP_ADDRESS>. I removed the devices and re-paired with Dirigera. The duplicates reappeared once again.

I got some time to look at the JSON. The hub returns two devices with different id but same serial number.
For example the first SOMRIG with name EntranceButton has two entries with almost same id except _1 and _2 at end. Same serial number but different attribute "switchLabel".
In one case the attribute value is "Shortcut 1" and other has "Shortcut 2"
Can you tell me how this is related to the physical device as I dont have one

The SOMRIG remote control consist of two buttons, each button supports single/double/long click as separate triggers.
After investigating the scene configuration dump I created fromthe https://github.com/Leggin/dirigera library it's clear that the two "devices" actually represents the two buttons of a single remote. The devices having suffix _1 represents the top button (the one with a single dot imprinted), while _2 represents the lower button.
The latter always has an empty customName and missing the attributes batteryPercentage and  room. Otherwise identical.

Closing this Issue, we shall track with the issue #29

Not sure how this relates to #29. I'll working a on contribution that will remove the duplicate devices.

My bad, will get to fix this once we fix the empty scene creation that @slajob  is working on.

I drafted https://github.com/sanjoyg/dirigera_platform/pull/33. @slajob will hopefully be able to reuse most of the additional code introduced in his solution.


The connection was reset (mesos, marathon UIs)

Hi,
After Merge pull request #305 from CiscoCloud/fix/marathon-race, I keep getting Connection reset from 8080 and 5050, over http

@nmarasoiu Web UI for marathon and mesos not available too?

Right, both give RST, both from the vagrant host and the vagrant guest

I must say I also got that with earlier commits, when rolling back with reset --hard..

Are you aware of any version (commit; hash; tag) which could be more stable than the current master?
I tried 0.1.0, 0.2.0 and master, and all are failing to me, with the bugs I have put this week here, some were fixed, but currently all 3 are blocked right now for me.

Can you ssh to host and validate that something running at port 8080 and 5050 netstat -nlupt | grep 8080 ?
And that is tcp or tcp6? What result of  nc -v <master_host>  8080 ?

tcp6       0      0 :::8080                 :::*                    LISTEN      10536/docker-proxy
tcp6       0      0 :::5050                 :::*                    LISTEN      9189/docker-proxy
nc -v localhost 8080
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to ::1:8080.
Yes, option to disable all security (or just consul one)

@nmarasoiu would you be open to doing a screen share so that I can walk through one of your deployments? I'd like to get a better feel of what is going on.

Lets change it a little bit.
Can you try instead ./security-setup --enable=false:

./security-setup
./security-setup --mesos-iptables=false --mesos-framework-auth=false ?

Yes, right now I am starting a fresh instance (vagrant destry + up) with option 1 above i.e. no option given to the security command

I give to the

I am available for a screen share, what tool do you suggest?

NOTIFIED: [zookeeper | wait for zookeeper to listen] **************************
failed: [default] => {"changed": true, "cmd": ["zookeeper-wait-for-listen.sh"], "delta": "0:00:59.980486", "end": "2015-05-20 11:46:35.193057", "rc": 1, "start": "2015-05-20 11:45:35.212571", "warnings": []}
FATAL: all hosts have already failed -- aborting
TASK: [mesos | add mesosphere repository] *************************************
FATAL: no hosts matched or all hosts have already failed -- aborting

And running ansible again, it's back to: (an existing open issue made by me):
failed: [default] => {"changed": true, "cmd": ["docker", "run", "--rm", "-e", "ZK_AUTH=super:+Nt5e/wmF5gt4tN04SB/syZnqam10nNjoTHL1m+d4bt5", "-e", "ZNODE=/mesos", "-e", "ZNODE_ACL=world:anyone:r,digest:mesos:J+OaGBhZLLsFv0iG/Dpj4HWXTyI=:cdraw", "-e", "ZK_SERVER=zookeeper.service.consul:2181", "--entrypoint", "/usr/local/bin/setacl.sh", "ciscocloud/zookeeper:0.2"], "delta": "0:00:02.505259", "end": "2015-05-20 12:00:03.651818", "rc": 1, "start": "2015-05-20 12:00:01.146559", "warnings": []}
stderr: Exception in thread "main" org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /mesos
at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)


Update for CUDA 12.4.1

xref: https://github.com/conda-forge/cuda-feedstock/issues/23

@conda-forge-admin, please rerender

One of the Travis CI jobs on main timed out. Restarted here

Missing packages are up. Just need to mirror


HTML Formatter

Vote on this issue by adding a 👍 reaction.
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Is your feature request related to a problem? Please describe.
As a developer, I'd like to be able to quickly format an HTML snippet.
Describe the solution you'd like
Add an HTML Formatter that includes inner JavaScript and CSS code.

Hi,
This is a good idea for an extension, but I don't think it fits DevToys' default tools.
Thanks


Navigate events seem to behave differently than documented

Expected behavior
According to the docs:

'navigate'|state.events.NAVIGATE
Choo emits this event whenever routes change. This is triggered by either 'pushState', 'replaceState' or 'popState'.

navigate event handlers should fire immediately after push/replaceState.
If I load the page on / and click an anchor to goto /foo, I would expect any navigation event handlers to fire, and state.href === '/foo'
Actual behavior
navigation event handlers fire, but state.href === '/'
Steps to reproduce behavior

Bind to 'navigate' event
Load page on /
Click anchor link to /foo

https://www.webpackbin.com/bins/-KsoH1Rql9FF4-a_GZTS

Derp, dunno how I didn't see this before. Dupe of #530


CHECKDB PhysicalOnly on VLDB in emergency mode

The execution of below command on a vldb in emergency mode ends immediately successfully without doing anything :
EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'DBName',
@CheckCommands = 'CHECKDB',
@PhysicalOnly = 'Y'
GO
Why ?
How to resolve this issue ?
Thank you
Regards

Do you have the output from the command?

Hello,
Only command executed successfully.
Thank you
Best regards
Brigitte LE ROUX
Consultante Bases de données
Mobile:<PHONE_NUMBER>
<EMAIL_ADDRESS>
De : Ola Hallengren @.***>
Envoyé : jeudi 30 décembre 2021 22:28:10
À : olahallengren/sql-server-maintenance-solution
Cc : Brigitte LE ROUX; Author
Objet : Re: [olahallengren/sql-server-maintenance-solution] CHECKDB PhysicalOnly on VLDB in emergency mode (#550)
Do you have the output from the command?
—
Reply to this email directly, view it on GitHubhttps://github.com/olahallengren/sql-server-maintenance-solution/issues/550#issuecomment-1003186658, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACRA2BE6FOUAGJOUYOA455TUTTFGVANCNFSM5BI22EIA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>

This issue has now been fixed.
https://ola.hallengren.com/versions.html

Hello,
Thank you
Best regards
Brigitte LE ROUX
Consultante Bases de données
Mobile:<PHONE_NUMBER>
<EMAIL_ADDRESS>
De : Ola Hallengren @.***>
Envoyé : vendredi 31 décembre 2021 20:08:07
À : olahallengren/sql-server-maintenance-solution
Cc : Brigitte LE ROUX; Author
Objet : Re: [olahallengren/sql-server-maintenance-solution] CHECKDB PhysicalOnly on VLDB in emergency mode (#550)
This issue has now been fixed.
https://ola.hallengren.com/versions.html
—
Reply to this email directly, view it on GitHubhttps://github.com/olahallengren/sql-server-maintenance-solution/issues/550#issuecomment-1003437522, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACRA2BCHAEKSVAIBAIZFRADUTX5RPANCNFSM5BI22EIA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>