fix: set jspdf to 1.4.1 to avoid semver resolution of newer versions

Synopsis:

jspdf version in package.json is specified as ^1.4.1, 1.4.1 explicitly is locked in package-lock.json so this version is used for development.
Because of the way semver works, when installing html2pdf.js as a consumer npm is not resolving 1.4.1 it's resolving the latest minor version 1.5.3
<EMAIL_ADDRESS>does something really nasty: imports a dependency directly from github.

Evidence:

https://github.com/MrRio/jsPDF/blob/v1.5.3/package.json#L27

Problem:

Personal: I'm not comfortable with this and I'm sure many others feel the same
My org: For security reasons, our CI does not allow dependencies that aren't proxied through our private registry
General: This makes the library not proxiable/replicatable in a private npm registry because the dependency exists outside of npm, which is a problem for more than just my org

Solution:
jspdf have already remedied this problem in 2.x.x, but rather than take on the cost of any potential breaking changes they've introduced I'm proposing we simply lock the version to 1.4.1. This way the jspdf version consumers use matches the one developers of this library use.

Hi @jakewhelan, thank you very much for the contribution, sorry it's taken me so long to take any action. I've just incorporated this change into v0.9.3 - the change is already made, but I'll merge your PR anyway. Thanks again!


Conflicting SNI's between HTTPRoute & TLSRoute

What happened:
If I have the same fqdn defined in both an HTTPRoute as well as a TLSRoute, what could the conflict resolution be in that case?
The current docs on a TLSRouteMatch sort of lead me to think that TLSRoutes should match first before HTTPRoutes, but might be nice to raise a Condition for this in the event that one is ignored over another.
Just curious if others have thought about this yet or if I'm maybe misunderstanding the spec. =)

At any time, a listener on the Gateway can only select routes of one kind, so conflicts shouldn't happen between route of different types.
I'm curious how you are running into this.

I thought you could duplicate listener ports in a Gateway and then the controller should collapse them:
If the implementation does collapse compatible Listeners, the hostname provided in the incoming client request MUST be matched to a Listener to find the correct set of Routes. The incoming hostname MUST be matched using the Hostname field for each Listener in order of most to least specific. That is, exact matches must be processed before wildcard matches.

I guess we can apply the same conflict logic within the same type (e.g. HTTPRoutes), but do across types which would make the behavior consistent in a way, but would need to raise a condition on the object to alert the user.
// ref: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.Gateway

I see the problem.
 87     // 1. Either each Listener within the group specifies the "HTTP"
 88     //    Protocol or each Listener within the group specifies either
 89     //    the "HTTPS" or "TLS" Protocol.

I think the or in  "HTTPS" or "TLS" is the reason for the confusion.
I could be wrong here but I think multiplexing HTTPS and TLS routing configuration on the same port isn't something we have discussed before. Collapsing should really happen only for listeners which have the same protocol type.
I don't think many implementations would be able to support such a configuration. Is that something you already support (or even plan to support)?
/cc @robscott @jpeach @Miciah

Is that something you already support (or even plan to support)?

Today Contour supports a single insecure/secure listener, so all traffic routes through those two listeners essentially. Someone could potentially create a TLS route with the same fqdn as an HTTPRoute and you'd have a conflict. We handle this today by only supporting one or the other if users create them on the same fqdn.

I see the problem.
 87     // 1. Either each Listener within the group specifies the "HTTP"
 88     //    Protocol or each Listener within the group specifies either
 89     //    the "HTTPS" or "TLS" Protocol.

I think the or in  "HTTPS" or "TLS" is the reason for the confusion.
I could be wrong here but I think multiplexing HTTPS and TLS routing configuration on the same port isn't something we have discussed before. Collapsing should really happen only for listeners which have the same protocol type.
I don't think many implementations would be able to support such a configuration. Is that something you already support (or even plan to support)?
/cc @robscott @jpeach @Miciah

IIURC an implementation can either conflict the route on this, or could choose HTTPS (on the principle that most specific wins).

Today Contour supports a single insecure/secure listener, so all traffic routes through those two listeners essentially. Someone could potentially create a TLS route with the same fqdn as an HTTPRoute and you'd have a conflict. We handle this today by only supporting one or the other if users create them on the same fqdn.

TLSRoute implies that the traffic flowing through the byte stream could be non-HTTP. Can you multiple HTTP/non-HTTP traffic on the same TCP port via Contour? Only then can this conflict occur.

IIRC an implementation can either conflict the route on this, or could choose HTTPS (on the principle that most specific wins).

@jpeach, is such a conflict even possible though?

Can you multiple HTTP/non-HTTP traffic on the same TCP port via Contour?

No you can't, but if someone tries to configure this, there should be some set of conditions to warn them that one was rejected and the other is used. I was just trying to think through what should happen in that case, which resource "wins" and what conditions to set so the user is aware of what's happening.

No you can't, but if someone tries to configure this, there should be some set of conditions to warn them that one was rejected and the other is used.

In that case, shouldn't there be a conflict of listeners error on the Gateway status?
Let's say we have the following:
  listeners:  # Use GatewayClass defaults for listener definition.
  - protocol: HTTP
    port: 80
    routes:
      kind: HTTPRoute
  - protocol: TLS
    port: 80
    routes:
      kind: TLSRoute

In this case, shouldn't the controller signal an error on the Gateway resource stating that these two listeners are incompatible?

In this case, shouldn't the controller signal an error on the Gateway resource stating that these two listeners are incompatible?

Sorry @hbagdi I feel like I haven't been super clear. I agree with you on that this should be an error but trying to understand who would win in this case? Do all the corresponding routes that are selected by these two listeners get rejected?
If the HTTP listener was valid and the TLS was added, what should we do? I'm not sure if there are any good rules to apply short of rejecting both, but worry that you'd drop all traffic in this case.

To summarize my interpretation:

You have 2 listeners on port 443
The first "HTTPS" listener matches HTTPRoutes
The second "TLS" matches TLSRoutes

You end up with both an HTTPRoute and a TLSRoute binding to the same hostname (i.e. SNI name).

Either each Listener within the group specifies the “HTTP” Protocol or each Listener within the group specifies either the “HTTPS” or “TLS” Protocol.

So the spec claims that this ought to be OK (the rationale is that you can still route properly based on the TLS SNI). However, there's no language that prevents an implementation rejecting this configuration though (it's stated as "an implementation might", not MUST).
So I can think of 3 options:

Reject the TLS listener as Conflicted.

Accept the HTTPRoute and refuse the TLSRoute. This follows the "most specific wins" rule. In this case, HTTP is more specific than TLS, so the HTTPRoute binds to the name and the TLSRoute is refused. The listener that matches TLSRoutes would get the false condition ResolvedRefs with the reason DegradedRoutes and the TLSRoute would get the false condition Admitted.

Accept the configuration. Another way to resolve the conflict is to configure the listener using ALPN protocol names. You could send HTTP protocols to the HTTPRoute and everything else to the TLSRoute. That probably has limited value in practice, but it would be a direct mapping of the requested configuration. If you do this, there won't be any errors in this config.

Catching up on this one, I think @jpeach has nailed this, and I think we should do his option 2 above.

I think option 1 may be preferable/simpler to handle. I can't think of a use case where you'd want an HTTPS and TLS listener for the same hostname on a Gateway. If users attached different certs to each listener it could get especially difficult to implement. It seems significantly simpler to me to consider that invalid.

I may be missing something but seems like 1 and 2 are the same? Or is the difference just rejecting the listener vs rejecting all routes on the listener? If the latter, I slightly prefer 1, seems a bit simpler.
I agree (3) could be done but seems a bit complex and not likely portable, so I would prefer to defer it (likely indefinitely)

Yeah, my interpretation was that 1 would reject the entire listener instead of just specific routes. That would be my preferred option.

I think 1 is fine too, and agree that it is simpler.

/lifecycle frozen

Despite this issue being quite old, we the maintainers are still pretty convinced that we want to have this functionality in a future release. We are marking this help wanted as we're looking for contributors with strong use cases to help champion and drive this forward.

Since the problem here comes up in conflicts between HTTPRoutes and TLSRoutes we don't expect this to be needed for v1.0.0 as we expect only GatewayClass, Gateway and HTTPRoute to be going GA for that release. We should however choose one of the options for resolving this problem and get this solved prior to beta for TLSRoute.

Since We want to promote TLSRoute for 1.2, I'm adding this to the TLSRoute epic, as we need to figure out how to deal with such a situation.
Said that, I lean toward solution 1, for its simplicity.

Does anyone have capacity for this one? Should we sync about the future plans for TLSRoute soon to make sure we're all on the same page?

I think we should talk more about TLSRoute as part of scoping for 1.3, once 1.2 is released, yes.

/remove-lifecycle stale
@robscott this one should probably be included in revisions we're doing to TLS config.


Typo in example config.xml for splash screens

The splash screen example code for config.xml contains a type in the splash tags:
<gap:splash ...> should be <splash ...>

Fixed in commit c8eb7d632774b32e9b8f98d3706fb72a25f36ccd.
Published to npm registry with version 0.2.7


Manifest contains the same information twice

The child elements section seems to show the same section twice.

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

ID: 24a8dcfa-d75f-b8d1-c020-e3fa6b74eb28
Version Independent ID: c5389f9a-25a0-6cd5-f542-fa49a3625314
Content: Manifest Element - PowerApps
Content Source: powerapps-docs/developer/component-framework/manifest-schema-reference/manifest.md
Service: powerapps
GitHub Login: @Nkrb
Microsoft Alias: nabuthuk

@psyduck101
Thanks for the feedback. We have updated the docs with the correct information and pushed to live. Closing the issue.


Data disappearing while zooming/panning when y-values are not ordered by x

Modify the Scatter plot demo thus:
add a line 99:
    double xv = (double) (arc4random_uniform(count)) + 3;

modify the next line which is now 100:
    [yVals1 addObject:[[ChartDataEntry alloc] initWithValue:val xIndex: xv]];

Start panning and zooming and many of the data points will not be rendered. Also, the value labels are frequently not rendered.
The problem is in ScatterChartRenderer.swift this code appears in two places:
            if (!viewPortHandler.isInBoundsRight(point.x))
            {
                break;
            }

This code at lines 91 and 217 assume that the X data is ordered. Removing the conditional break's fixes the problem.
in fork: https://github.com/gjpc/ios-charts
Patch:
diff --git a/Charts/Classes/Renderers/ScatterChartRenderer.swift b/Charts/Classes/Renderers/ScatterChartRenderer.swift
index 073e45c..f688630 100644
--- a/Charts/Classes/Renderers/ScatterChartRenderer.swift
+++ b/Charts/Classes/Renderers/ScatterChartRenderer.swift
@@ -87,12 +87,7 @@ public class ScatterChartRenderer: ChartDataRendererBase
             point.x = CGFloat(e.xIndex);
             point.y = CGFloat(e.value) * phaseY;
             point = CGPointApplyAffineTransform(point, valueToPixelMatrix);
-
-            if (!viewPortHandler.isInBoundsRight(point.x))
-            {
-                break;
-            }
-
+
             if (!viewPortHandler.isInBoundsLeft(point.x) || !viewPortHandler.isInBoundsY(point.y))
             {
                 continue;
@@ -213,12 +208,7 @@ public class ScatterChartRenderer: ChartDataRendererBase
                 var lineHeight = valueFont.lineHeight;

                 for (var j = 0, count = Int(ceil(CGFloat(positions.count) * _animator.phaseX)); j < count; j++)
-                {
-                    if (!viewPortHandler.isInBoundsRight(positions[j].x))
-                    {
-                        break;
-                    }
-
+                {
                     // make sure the lines don't do shitty things outside bounds
                     if ((!viewPortHandler.isInBoundsLeft(positions[j].x)
                         || !viewPortHandler.isInBoundsY(positions[j].y)))

Though the patch allows viewing and interaction with a non x ordered scatter data set, utility functions such as entryIndex expect ordered x data and fail. So the patch is only good if you are just displaying the data. There might be other package architectural dependencies on ordered x data.  Anyone in the project care to comment?  Dan, you have been very quite about my posts.

Actually, many functions in the project depends on the y values being ordered on the x axis. That's because in many places we know that we can stop at a certain point, and not loop through more data. This is done for either rendering or even just preventing calculations on data that's our of the viewport.
I'll continue a discussion on this with Phil, in the other issue on the MPAndroidChart repo. https://github.com/PhilJay/MPAndroidChart/issues/718.
You can follow up on it there, and when we have a conclusion I'll give an update here.

Yes, I have noticed that and I would think in many non-biological areas it would be fine, it's a good optimization. Perhaps setting a flag in a DataSet object's first scan of the data to let the renderers know it aint so. I may be advisable to just to go ahead and set the flag when realtime data manipulation occurs.

We've come to a conclusion that the values must be ordered - as it is considerably less expensive to sort the data by x-index before passing to the chart, than to loop over the whole data and do the bounds-checking for each and every point.
So this is going to be closed for now. If there's a request for a specific special feature please open a relevant issue :-)

If anyone wants a scatter char that actually works they can go to my branch....

If anyone wants a scatter char that actually works they can go to my branch....

Or work correctly with the API. The scatter chart works.

It does not :P

@gjpc Hi, I've tried implementing your changes to remove the condition checking on my project that suffers this issue as well, but it does not seem to fix it either. Have any advice?

@micnguyen I need a bit more information before I may offer any advice.

@micnguyen I am not sure you implemented my changes or @danielgindi branch of my changes that may or may not contain my changes properly implemented. I just pushed a major enhancement to the Independent Scatter Chart demo to illustrate exactly what and Independent scatter plot does.  Please go to my branch and see it that solves your problems.

@gjpc I basically created a time series charge with lots of x-axis intervals (spaced by 1 minute). So there will data points at say, interval 1 and another data point at interval 61 if they are an hour apart. The issue I have been seeing is if you zoom until a point is off the screen, the line that connects them disappears. I assumed your change of removing the conditionals on line 91 and 217 fixed that - or have you tackled another issue that I may be mistaking?

@micnguyen I chose not to draw a line unless both points are visible on the screen.  I find it easier to zoom out to find the next dot's position, panning and then re-zooming a more natural mode of analysis. In a particularly dense data set I found too many lines running off the screen in so many different directions obscured the data under study. I'll consider adding a flag allow connection to the off-screen points.

@gjpc Our testers and myself personally have found the disappearing lines odd behaviour. In our situation, we only have 1 data set that all have unique x-y values. The lines that connect said data points do provide some information to the user (especially if your data points do not have large explicit markers). I hope the changes to achieve that won't be too much work - thank you.

@micnguyen it is a trivial fix if you don't mind the line transversing to the off screen data point crossing the axis lines. It is more work to stop it at the axis, but there is a certain amount of positive feedback in indicating the data exists, but it is out of the view port.
What do you think?

@gjpc It looks great! It appearing out of the axis lines is rather unfortunate and undesirable however. But if the lines and data points don't disappear when out of the viewport, that's great.

@micnguyen You are right, pickup the finish at https://github.com/gjpc/ios-charts

@micnguyen I don't know if this will effect you, but I just did a rebase and force push to get rid of commit error


digital envelope routines::unsupported

Node.js v19.5.0
node:internal/crypto/hash:71
  this[kHandle] = new _Hash(algorithm, xofLen);
                  ^

Error: error:0308010C:digital envelope routines::unsupported

I think should upgrading your webpack to 5.*


Command line arguments are incorrectly echoed in TRACE.

See this output:
[2021-12-05T12:11:07Z INFO  librespot] librespot 0.3.1 7160dc1 (Built on 2021-12-05, Build ID: dLpKscF9, Profile: release)
[2021-12-05T12:11:07Z TRACE librespot] Command line argument(s):
[2021-12-05T12:11:07Z TRACE librespot] 		--name Speakers
[2021-12-05T12:11:07Z TRACE librespot] 		--backend alsa
[2021-12-05T12:11:07Z TRACE librespot] 		--device hw:1,0
[2021-12-05T12:11:07Z TRACE librespot] 		--mixer alsa
[2021-12-05T12:11:07Z TRACE librespot] 		--alsa-mixer-device hw:1
[2021-12-05T12:11:07Z TRACE librespot] 		--bitrate 320
[2021-12-05T12:11:07Z TRACE librespot] 		--cache /tmpfs/spotify/
[2021-12-05T12:11:07Z TRACE librespot] 		--cache-size-limit 512M
[2021-12-05T12:11:07Z TRACE librespot] 		--volume-ctrl cubic
[2021-12-05T12:11:07Z TRACE librespot] 		--verbose
[2021-12-05T12:11:07Z TRACE librespot] 		--initial-volume 100
[2021-12-05T12:11:07Z TRACE librespot] 		--enable-volume-normalisation
[2021-12-05T12:11:07Z TRACE librespot] 		--normalisation-method dynamic
[2021-12-05T12:11:07Z TRACE librespot] 		--normalisation-gain-type track
[2021-12-05T12:11:07Z TRACE librespot] 		--normalisation-pregain
[2021-12-05T12:11:07Z TRACE librespot] 		-3
[2021-12-05T12:11:07Z TRACE librespot] 		--format S24_3
[2021-12-05T12:11:07Z TRACE librespot] 		--username XXXXXXXX
[2021-12-05T12:11:07Z TRACE librespot] 		--password XXXXXXXX
[2021-12-05T12:11:07Z TRACE librespot] 		--autoplay

The part that says -3 belongs to the argument before that.
The argument is parsed correctly, because the other part of the log is correct:
[2021-12-05T12:11:25Z DEBUG librespot_playback::mixer::alsamixer] Alsa forcing linear dB mapping: false
[2021-12-05T12:11:25Z DEBUG librespot_playback::player] Normalisation Type: Track
[2021-12-05T12:11:25Z DEBUG librespot_playback::player] Normalisation Pregain: -3.0 dB
[2021-12-05T12:11:25Z DEBUG librespot_playback::player] Normalisation Threshold: -2.0 dBFS
[2021-12-05T12:11:25Z DEBUG librespot_playback::player] Normalisation Method: Dynamic
[2021-12-05T12:11:25Z DEBUG librespot_playback::player] Normalisation Attack: 5ms
[2021-12-05T12:11:25Z DEBUG librespot_playback::player] Normalisation Release: 100ms
[2021-12-05T12:11:25Z DEBUG librespot_playback::player] Normalisation Knee: 1.0

So it seems only the echo is incorrect. Minor error, but could be fixed whatsoever I believe.

Seems the problem is around this line: https://github.com/librespot-org/librespot/blob/e66cc5508cee0413829aa347c7a31bd0293eb856/src/main.rs#L669
The code expects a minus sign always denotes a new item, while a minus sign in this case denotes a negative value instead.

I got it that's my bad. I'll just make sure anything followed by a - is only 1 char and a leter that should do it.

I got it that's my bad. I'll just make sure anything followed by a - is only 1 char and a letter that should do it.

That check would probably be enough, unless (-)[a-z] would be a valid username and/or password, i.e. --username -a or --password -a which I am fairly certain are not valid.

Now that I think of it, device name should probably be valid as --name -a, which would break the rule, but should work.
Anyone correct me please?

@coderootme try that.

Now that I think of it, device name should probably be valid as --name "-a", which would break the rule, but should work.
Anyone correct me please?

I take care of that with:
        let is_defined_and_present = |mut arg: String| {
            if arg.starts_with("--") {
                arg.replace_range(..2, "");
            } else if arg.starts_with('-') {
                arg.replace_range(..1, "");
            }

            if matches.opt_defined(&arg) {
                matches.opt_present(&arg)
            } else {
                false
            }
        };

The basic idea is to loop though the args and see if the string "is_defined_and_present" to see if it's a "key" if it's a "key" we check to see if the next arg is a "value" with "is_defined_and_present" again but this time it must return false to be considered a "value".

That check would probably be enough, unless (-)[a-z] would be a valid username and/or password, i.e. --username -a or --password -a which I am fairly certain are not valid.

And to clarify, that part of the code does not check the validity of the args.
Command line args are checked with a combination of opts.parse and evaluating their values.
If they fail opts.parse you won't get a list of args, you'll get a parsing error. If they fail at the evaluation stage you'll get a list and hopefully a meaningful error explaining what failed and why.
For environment variables the trace message is generated after opts.parse so if that fails you will not get a list. Otherwise you'll get a list and hopefully a meaningful error explaining what failed if anything did.

With the PR:
--verbose "totally invalid because --verbose is a flag" --name --name -N "totally invalid because -N is a flag" --normalisation-pregain -3.0 -d -a -u stuff

Outputs:
[2021-12-06T01:08:05Z TRACE librespot] Command line argument(s):
[2021-12-06T01:08:05Z TRACE librespot] 		--verbose
[2021-12-06T01:08:05Z TRACE librespot] 		--name --name
[2021-12-06T01:08:05Z TRACE librespot] 		-N
[2021-12-06T01:08:05Z TRACE librespot] 		--normalisation-pregain -3.0
[2021-12-06T01:08:05Z TRACE librespot] 		-d -a
[2021-12-06T01:08:05Z TRACE librespot] 		-u XXXXXXXX

"--name" is kinda weird but still a valid device name.
"totally invalid because --verbose is a flag" and "totally invalid because -N is a flag" are never actually evaluated by librespot because --verbose and -N are flags so we only check if they exist.
"-a" is technically valid I guess maybe? Although I'd bet it would fail as soon as you tried to use a device named "-a".
-u is the short version of --username so "stuff" is redacted.

Also @coderootme a couple notes about your args:
--backend alsa is not necessary unless you have also have other backends compiled into librespot.
Unless you have some special reason to use --mixer alsa (like you're using some alsa feature that requires that you use alsa volume control) software volume control in librespot is objectively superior to alsa hardware volume control, and much less potentially jankey because it actually works 100% of the time as apposed to alsa volume controls.
--normalisation-method dynamic is redundant. dynamic is already the default.
--normalisation-gain-type track Unless you really prefer track mode all the time you might just leave that out so it defaults to auto. Which changes from track to album automatically depending on what you're listening to.

Unless you have some special reason to use --mixer alsa (like you're using some alsa feature that requires that you use alsa volume control) software volume control in librespot is objectively superior to alsa hardware volume control, and much less potentially jankey because it actually works 100% of the time as apposed to alsa volume controls.

The advantage of using alsa's mixer, for me at least, with DACs that support it, is that the volume change is instant, while the software volume control delays the volume change (because of buffer, I think). For audiophile setup, I do not use any mixer at all and change the volume with the volume knob on my amplifier only, which is not really that often when the whole gear is of high quality and all tracks are outputted at the same LUFS.

--normalisation-method dynamic is redundant. dynamic is already the default.

Yes, I know, I will probably erase it. I've been using it for a long time now and I like to configure all parameters like these, in case the defaults might change in the future (I manage multiple librespot-powered devices and I wouldn't like some settings changing by itself just because the project development decides to change the default, when no value is specified.
How probable is this situation with FOSS?

--alsa-mixer-device hw:1 is also redundant as it defaults to whatever you set --device to.

I thought so too, but it doesn't work without that parameter. Here is the output log when I completely remove --alsa-mixer-device hw:1 from the command:
[2021-12-06T07:58:37Z INFO  librespot_playback::mixer::alsamixer] Mixing with Alsa and volume control: Cubic(0.0) for device: hw:1,0 with mixer control: PCM,0
ALSA lib conf.c:5084:(parse_args) Unknown parameter 1
ALSA lib conf.c:5217:(snd_config_expand) Parse arguments error: No such file or directory
ALSA lib control.c:1471:(snd_ctl_open_noupdate) Invalid CTL hw:1,0
thread 'main' panicked at 'Could not open Alsa mixer: Error("snd_mixer_attach", Sys(ENOENT))', playback/src/mixer/alsamixer.rs:42:60
stack backtrace:
   0:   0x8d09b0 - std::backtrace_rs::backtrace::libunwind::trace::hd738fd9ee0e1e0e7
(... backtrace continues ...)

--normalisation-gain-type track Unless you really prefer track mode all the time you might just leave that out so it defaults to auto. Which changes from track to album mode automatically depending on what you're listening to.

Yes, I currently really prefer track mode. I usually do not listen to whole albums and when I do, I do not mind that the relative volume of songs is changed. For very good masters, like Dire Straits/Mark Knopfler for example, I find the track mode relatively okay-ish, and for anything with bad mastering, I don't like changing the relative volume of songs. The convenience of listening without touching the volume knob too often is more important to me than listening to an album with crappy mastering as the author intended, when the intention is shit in the first place. I'm not sure I'm making any sense here. But I will happily change my opinion in the future, as I have changed many opinions in the last years.

The advantage of using alsa's mixer, for me at least, with DACs that support it, is that the volume change is instant, while the software volume control delays the volume change (because of buffer, I think)

I wouldn't think there should be any noticeable delay normally, the buffer should only be 0.5 secs?

I thought so too, but it doesn't work without that parameter. Here is the output log when I completely remove --alsa-mixer-device hw:1 from the command:

That would be a bug for @roderickvd the ,0 part of hw:1,0 should probably be stripped off in that case and in the case that --device takes the form of something like hw:CARD=Generic,DEV=0 it should probably be just hw:CARD=Generic? Idk about that one? That would require some more testing?
In the meantime you can use hw:1 for --device since it's the same as hw:1,0. 0 is the default device. Any place anywhere in any alsa config (not just librespot) if the device is 0 you can omit it.

Yes, I currently really prefer track mode.

Fair enough.

I don’t know for sure either, but it does look redundant (and so not functioning). You can file an issue or PR for it. Right now still hard at work at other librespot stuff so it’d on the backlog.

I manage multiple librespot-powered devices and I wouldn't like some settings changing by itself just because the project development decides to change the default when no value is specified.

How probable is this situation with FOSS?

You should already be getting warning messages about --normalisation-method dynamic in dev. But really librespot is not stable and makes not promises about stability whatsoever. Args can and have changed and may in the future with little to no notice.

You can file an issue or PR for it

I'll add it to my list which adds it to your list,lol!!!

@roderickvd along the way I'll see about making the mixer not explode on errors,lol!!

While I feel that API and command line option stability is important, consider everything as tentative baselined until 1.0.0 and it’s up to FOSS to keep up. I’m a moOde user myself and make efforts to keep that up to date.

You should already be getting warning messages about --normalisation-method dynamic in dev. But really librespot is not stable and makes not promises about stability whatsoever. Args can and have changed and may in the future with little to no notice.

Yes, I was wondering about that. Why is the librespot development team thinking of removing the basic normalisation method?
I know many audophiles do not like any dynamics compression whatsoever; myself included, except for some special cases, for example when listening on speakers at night as a background noise when doing something else, but definitely not when fully focused on music using good gear.
Removing simple method leaves users who want to equalize tracks to the same LUFS to use dynamic with very low preamp value, I think -9 is the safest value. Which is OK, as long as your DAC and AMP have very high SNR, which most don't.
simple normalisation method solves this at least a bit for poor setups, in my opinion.
But the whole audio theory is so difficult and trying to satisfy all categories of users, casual listeners and audophiles, is sometimes impossible. But removing an already implemented function which simply works, is always so strange to me.
mpd has this function too. It is called replaygain_limit and by default it is enabled, i.e. it works the same as librespot's simple volume normalization. See: https://github.com/MusicPlayerDaemon/MPD/blob/22403272869228dce81e37523eda9da0c4305489/doc/mpdconf.example#L401
I love how these issue threads always result in discussions where all users learn something new. This community is so amazing! I love being here and reading all your posts and ideas. Obviously many developers here are very knowledgeable about the whole project, which is awesome!

Yes, I was wondering about that. Why is the librespot development team thinking of removing the basic normalisation method?

The idea being that dynamic is objectively better than basic. Basic is literally just the volume being turned up and down as you've figured out. And 99.99% of people would rather use dynamic.

I know many audophiles do not like any dynamics compression whatsoever; myself included, except for some special cases, for example when listening on speakers at night as a background noise when doing something else, but definitely not when fully focused on music using good gear.

Currently you really can't put "audiophile" in the same sentence as Spotify since it's lossy audio. When they roll out the HiFi tier and start streaming FLAC maybe.

Removing simple method leaves users who want to equalize tracks to the same LUFS to use dynamic with very low preamp value, I think -9 is the safest value. Which is OK, as long as your DAC and AMP have very high SNR, which most don't.

simple normalisation method solves this at least a bit for poor setups, in my opinion.

But the whole audio theory is so difficult and trying to satisfy all categories of users, casual listeners and audophiles, is sometimes impossible. But removing an already implemented function which simply works, is always so strange to me.

It's mostly about trying to pair the code and options down. There's no point keeping options and code that most people don't use. Code is not a static thing it has to be maintained. As other parts of the program are updated and changed that mostly unused code also has to updated and changed putting undo burden on devs.
The consensus I think was that dynamic > basic to most users and that audiophiles generally would not use it at all for the most part.

@coderootme point did make me think it over. It's fair enough not to remove existing functionality that's working well and used in the wild, even when I don't think by a lot of people. Honestly in this particular case it is so little lines of code that the burden of maintainability isn't really an issue.
On the other hand there's the argument of toning down on configuration options which is an agreed direction.
Where the logic seems flawed however is the point on catering to audiophiles (count me in as one so it's not at all that I object to that group!). Audiophiles with a poor setup, little headroom or poor SNR, is just an oxymoron.
The dynamic limiter (yeah, actually a compressor) preserves DNR for 99% of the time by only throwing away bits (potentially, depending on the sample format) when the track is over limit. The basic limiter throws away DNR for the entire track even if it's just a short passage that's over limit.
For most music and playlists it really won't matter that much. You'd be surprised how little the limiter engages at the default settings with music that is mastered sensibly. I'm not talking about hip hop and pop rock of course, there's little to save there even for an audiophile. But start throwing classical into the mix and at those fringes of dynamic range, it really shows that the basic limiter is a poor man's tool.
@JasonLG1979 is right: by these accounts the dynamic limiter is objectively better. I understand that there will always be exceptions to that rule, but I'm not buying into the audiophile argument here.

For most music and playlists it really won't matter that much. You'd be surprised how little the limiter engages at the default settings with music that is mastered sensibly. I'm not talking about hip hop and pop rock of course, there's little to save there even for an audiophile. But start throwing classical into the mix and at those fringes of dynamic range, it really shows that the basic limiter is a poor man's tool.

Even with pop, rock, hip-hop and metal (generally what I listen to) if you set the --normalisation-pregain to -3.0 and --normalisation-threshold to -3.0 you're basically adhering to the ReplayGain standard with 3dB of additional headroom for tracks that might not be mastered the greatest. With those settings I have never noticed the limiter kick in either audibly or by skimming the logs.

You can get pretty deep in the weeds when you start talking audiophile jargon with some of if grounded in reality more other things but generally speaking I tend to be an objectivist when it comes to hardware and software design. We can't know what every system sounds like so we have to go with the math and science as the great equalizer.

Even with pop, rock, hip-hop and metal (generally what I listen to) if you set the --normalisation-pregain to -3.0 and --normalisation-threshold to -3.0 you're basically adhering to the ReplayGain standard with 3dB of additional headroom for tracks that might not be mastered the greatest. With those settings I have never noticed the limiter kick in either audibly or by skimming the logs.

I agree. This is a good point.


feat(prettier): print es5 comma for object expression

Current dependencies on/for this PR:

main

PR #1574   👈

This stack of pull requests is managed by Graphite.


refactor(trial): Deprecate default behaviour of begin()

Currently trial.begin() will silently eat errors and relies on an explicit idiom of checking the exception after the block. While this is convenient, it's silent behavior and it's better to have users explicitly enable it.
New behavior to be enabled at some point is to just raise it by default. Users can either deal with it on their own, e.g. with a try: catch: to attach it trial.fail(), let the exception bubble up, or use trial.being(catch_exceptions=True) to have the current deprecated functionality.
The signature of trial.fail() was improved to allow the exception as a positional argument to make this easier. It will automatically fetch the stack trace and append it to itself.
For now, there is merely an annoying deprecation warning that will tell you to explicitly set your preferred behavior, until this default option can be changed.
# Previously required idiom

# You would not expect this to eat your errors unless you've been told/read the docs
with trial.begin():  # catch_warnings=True (old default)
   raise ValueError()

# Linters might even complain code could never reach here

if trial.exception: # I wouldn't know I need to check this without having read about it
   trial.fail()

trial.success()

I suggested way is a lot more explicit and does not hide the details from the user by default.
with trial.begin():  # catch_warnings=False (new default)
    try:
   		raise ValueError()
   	except Exception as e:
   	    return trial.fail(e)

# Otherwise you can do things here...
trial.success()

There are a few changes that should be made to the optimization guide and this should be included along side it.

I decided it's probably just better to remove trial.begin() altogether and will create a new PR


Use same sass files as in foundation-sass

What is the reason for using pure css files when there is a sass port of foundation that you maintain that would work with rails?

+1


feat(@angular-devkit/build-angular): allow transformation of i18n extraction builder configuration

This change allows the underlying webpack configuration of the i18n extraction builder to be modified when programmatically using the builder.  This change also aligns the i18n extraction builder with the other Webpack-based builders in the package.
Programmatic usage of the @angular-devkit/build-angular builders is currently considered experimental.

Can you reference https://github.com/angular/angular-cli/issues/16679?


Block drag

Resolves
In preparation for fixing https://github.com/LLK/scratch-gui/issues/1234
Proposed Changes
Send events when blocks are dragged out to the right of the workspace. Reset drags when they end to the right of the workspace.

I think I have a better implementation for isOutside now and am ready for re-review


Handle language switching in code editor and update styling

Let's update the styling and handle multi-language syntax highlighting that syncs across users.

Multi language syntax highlighting with synchronisation

Updated question stats page

Formatted question topics and complexity

LGTM


Temporarily replace github.com/dgrijalva/jwt-go with golang-jwt

Change Overview
Adding replace directive to remove indirect dependencies of github.com/dgrijalva/jwt-go through IBM library.
This has been fixed upstream but there are other k8s library dependencies preventing its upgrade. We can revisit this later.
Pull request type
Please check the type of change your PR introduces:

[ ] :construction: Work in Progress
[ ] :rainbow: Refactoring (no functional changes, no api changes)
[ ] :hamster: Trivial/Minor
[x] :bug: Bugfix
[ ] :sunflower: Feature
[ ] :world_map: Documentation
[ ] :robot: Test

Issues

fixes #issue-number

Test Plan

[ ] :muscle: Manual
[ ] :zap: Unit test
[ ] :green_heart: E2E

#1367


”Grădinari”, ”Tântava”, ”Zorile” are listed in the drop-down menu

Description:
When user writes ”Grădinari”, ”Tântava”, ”Zorile” the locations appear in the drop-down menu next to the comune and the county witch is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Grădinari"

Expected results
The location appears in the drop-down menu as "Sat Grădinari, GIURGIU (Grădinari)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Tântava"

Expected results
The location appears in the drop-down menu as "Sat Tântava, GIURGIU (Grădinari)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Zorile"

Expected results
The location appears in the drop-down menu as "Sat Zorile, GIURGIU (Grădinari)".


[proposal] Allow user-specified --name for tw launch command

At the moment it isn't possible to provide a --name parameter to the tw launch parameter because the launch id is tracked internally. If we run tw runs list then you can see a Run Name in the tabular output (as shown below) but that is randomly assigned by NF at run-time. However, this can be overwritten via nextflow run -name <MY_NAME>.
  Pipeline runs at [org / test ] workspace:

     ID             | Status    | Project Name                          | Run Name               | Username      | Submit Date
    ----------------+-----------+---------------------------------------+------------------------+---------------+-------------------------------
     2kcht7kGLfXXXX | SUCCEEDED | nf-core/fetchngs                      | gloomy_roentgen        | drpatelhh     | Thu, 18 Nov 2021 14:22:09 GMT
     3IjYgpDCG8XXGa | CANCELLED | nf-core/fetchngs                      | elated_hawking         | drpatelhh     | Thu, 18 Nov 2021 14:18:27 GMT
     4MBcnTTQXXbiMZ | FAILED    | nf-core/fetchngs                      | backstabbing_payne     | drpatelhh     | Thu, 18 Nov 2021 13:51:15 GMT

I propose that we have an explicit tw launch --name parameter (with the appropriate validation for format and existence) that overwrites the -name parameter provided to NF. This would be very useful when using the CLI to come up with user-specified run names that can be propagated through subsequent tw commands without having to look for the appropriate identifier.

This is not trivial becuase introduces a new concept Project Name that currently does not exists

This proposal is to change the Run Name and not the Project Name? So for example replacing gloomy_roentgen in the table above with my_custom_run_name.

I see, there's a similar need on Tower as well.

Duplicated #200


[CLOSED] Error while using while using  Kitura v. 20 for onResponseEnd member

 Issue by Wilson-Ding1
Thursday Sep 28, 2017 at 04:08 GMT
Originally opened as https://github.ibm.com/IBM-Swift/Kitura-ResponseTime/issues/1

 Issue by Kam21
Saturday Jul 16, 2016 at 12:38 GMT
Originally opened as https://github.com/IBM-Swift/Kitura-ResponseTime/issues/1

Error on  "response.onResponseEnd "  -   value of type  'RouterResponse' has no member 'onResponseEnd;
Function:
public func handle(request: RouterRequest, response: RouterResponse, next: () -> Void) throws {
startTime = NSDate()
    let previousOnResponseEnd = **response.onResponseEnd** ?? nil
    **response.onResponseEnd** = { [unowned self, unowned response] in

}

 Comment by Wilson-Ding1
Thursday Sep 28, 2017 at 04:08 GMT

 Comment by ianpartridge
Friday Dec 02, 2016 at 14:14 GMT

I'm sorry we missed this issue. Please reopen if you still need help.


[circleci] split reno and team assignment linters

What does this PR do?
Split reno and team assignment linters to avoid confusion.
Also using this opportunity to rename reno_linting to release_note_linting to make it clearer for external contributors.
Note
Not sure if I need to edit something on github side - testing it with this PR

I think we'll need to change the required checks there: https://github.com/DataDog/datadog-agent/settings/branch_protection_rules/1441780, but apart from that, lgtm.

Thanks for the link, I wasn't able to find it. Seems like it picks them up automatically : Status checks found in the last week for this repository. Merging this and disabling reno_linting requirement should be enough then

And enabling both new checks as required too


Add documentation for controlled Selects

The Select documentation appears incomplete. First off, there's no guide to use a Select as a controlled component. More importantly, the type information at the bottom is completely missing. I'd assume this is because of the recent update to v6.
Thanks for maintaining this amazing project! v6 is looking exciting already.

Thanks for calling out the missing props. This project relies heavily on automatic documentation generation to stay in sync and a recent reorganization of the select code was preventing its props from being generated.
As for the select docs, I can add an example of using it as a controlled component, however it works just like a native select.

@jamesmfriedman All but the Select and Menu documentation is missing from the site.

Well, sometimes you fix one thing and break everything else.... Really fixed this time, thanks for reporting that.

Just added a section for controlled vs uncontrolled selects in the docs.


Overview Blade_While copying identifier value, identifier not to be select.

Describe the Bug with repro steps
1.Open a created standard LA having run identifier.
2.Try to copy the identifier value.
Expected: Only copy action should be work.
Actual: while copying the identifier value, only value is to be copied, here whole identifier is selected while using copy function.

What type of Logic App Is this happening in?
Standard (Portal)
Are you using Preview Designer or GA Designer
Preview
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
No
Workflow JSON
No response
Screenshots or Videos
No response
Browser
Edge
Additional context
Environment Details:
URL: https://aka.ms/emastaging-flowstip1
Version: "2.30613.1.2"
AB#24278155

This is by design


metric definitions does return the “supported aggregation types” for each metric

It appears "supportedAggregationTypes" when calling metric definitions never returns any values. The object returned for it is always empty/none.  https://docs.microsoft.com/en-us/rest/api/monitor/metricdefinitions/list#examples We have customers who want additional aggregations but right now we can only use the primaryAggregationType

Hi @DanielLanger
I don't reproduce it :(
In [25]: from azure.mgmt.monitor.models import MetricDefinition

In [26]: m
Out[26]:
{'category': 'Capacity',
 'id': '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/clitest.rg000001/providers/Microsoft.Storage/storageAccounts/clitest000002/providers/microsoft.insights/metricdefinitions/UsedCapacity',
 'isDimensionRequired': False,
 'metricAvailabilities': [{'retention': 'P93D', 'timeGrain': 'PT1H'},
  {'retention': 'P93D', 'timeGrain': 'PT6H'},
  {'retention': 'P93D', 'timeGrain': 'PT12H'},
  {'retention': 'P93D', 'timeGrain': 'P1D'}],
 'name': {'localizedValue': 'Used        capacity', 'value': 'UsedCapacity'},
 'namespace': 'Microsoft.Storage/storageAccounts',
 'primaryAggregationType': 'Average',
 'resourceId': '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/clitest.rg000001/providers/Microsoft.Storage/storageAccounts/clitest000002',
 'supportedAggregationTypes': ['Total', 'Average', 'Minimum', 'Maximum'],
 'unit': 'Bytes'}

In [27]: md = MetricDefinition.deserialize(m)

In [28]: md.supported_aggregation_types
Out[28]:
[<AggregationType.total: 'Total'>,
 <AggregationType.average: 'Average'>,
 <AggregationType.minimum: 'Minimum'>,
 <AggregationType.maximum: 'Maximum'>]

When you say does not return it for "each" metric, does it mean you have it sometimes? and sometimes not?

Closing, since I believe issue is solved, or not issue. Fell free to contact us Daniel if that's not the case. Thanks!

How can i get the used capacity (in bytes) value through metrics.
Please help me

Call it like this:   metric.primary_aggregation_type.value


chore(build): add signed mac builds back to tag creation (releases in github)

What this PR does 📖
This just adds the mac signing stuff back in to the github actions/makefile, will test the windows build stuff and get the appropriate cert next

Which issue(s) this PR fixes 🔨

Resolve #

Special notes for reviewers 🗒
Additional comments 🎤

Can merge when reason since this is more on CI than code itself unless somebody else would like to take a look at it


synx seems to break Xcode's temperamental asset handling.

Storyboards, Images, and it seems like any asset in the  "copy Bundle Resources" section of xcode don't like to be moved. The files tend to be missing from the built target. It doesn't seem to matter if Xcode is open or not when I run synx. In theory, i think i can fix this on a per file basis by removing the asset from xc and then re-adding it. The problem is that I'm working on a project with 184 different asset files, and its not realistic to refresh all these files. I'd wonder if anyone else has experienced issues like this.

... It actually might matter if Xcode is open. In retrospect it might have been the case that Xcode saved the xcodeproj file after the fact or something. :/


Failed to execute script worker,AttributeError: module 'azure.functions_worker' has no attribute 'start'.

#322 was closed, so I open a new one issue for the same error.
Publish function using func azure functionapp publish app_name --build-native-deps --no-bundler was working perfectly (That is why #322 was closed)
I have updated my function and so I have tried to re-publish the function but I got the same error again.
Error :

Function (confluence_call) Error: Failed to start language worker process for: python. bash exited with code 255 [84] Failed to execute script worker,AttributeError: module 'azure.functions_worker' has no attribute 'start'.

There is my requirement.txt : (It didn't change since #322 )

azure-functions
azure-functions-worker
azure-storage
azure-storage-blob
grpcio==1.14.2
grpcio-tools==1.14.2
protobuf==3.6.1
six==1.12.0
pandas

I have also tried to republish the function with the previous version of the code worked Monday but got the same error too.
I even tried to just make a new function following this documentation https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function-azure-cli-linux but nothing to do the error is always here.

@Flexron, can you update your azure-functions-core-tools version and try again? The latest version is 2.4.317.

@Flexron are you still seeing the error? Closing as issue should be resolved with a Core Tools update. Please feel free to re-open if this is not the case.


QueryHelpers.AddQueryString to update the query or UpdateQueryString

Current situation:
var url = "http://example/path?key1=value1&key2=value2";

Console.WriteLine(QueryHelpers.AddQueryString(url, "key1", "value3"));

// http://example/path?key1=value1&key2=value2&key1=value3

The desired behavior was to update the key, not cause the duplicate: http://example/path?key1=value3&key2=value2.
If this is some kind of an uncanny breaking change, can we at least have an override: QueryHelpers.AddQueryString(string url, string key, string value, bool overwrite = false) and in the above example, call it like QueryHelpers.AddQueryString(url, "key1", "value3", overwrite: true) to get the desired result? Alternatively, a separate UpdateQueryString method?

This API is not remotely that smart. Right now it just checks if it needs to add ? or not. Reparsing the existing query string for a key match is a whole different level, not to mention inefficient.  If this happens it should be a separate method like the UpdateQueryString you suggested.

We won't be adding this for RTM. This can be implemented as an extension on the app level.


Document supported TypeScript version

Article URL
Office Scripts Code Editor environment
Issue
The article listed above mentions that Office Scripts are written in TypeScript, but it doesn't mention which version.
Based on some trial and error I'm fairly confident that (as of Excel version 2310) it's TypeScript v3.7, but I'd love to see some official documentation on this :)

Hi @HoldYourWaffle,
Thanks for this question. I'll reach out to the product team and get an answer for you.

Hi @HoldYourWaffle
The version of TypeScript used by Office Scripts is currently 4.0.3. We are currently looking at a way to update the *Script versions without risking breaking existing scripts. Given that this upgrade path is still undefined in the product, that we have a layer of additional TS restrictions for Office Scripts (some of which that limit the IntelliSense), and that the nature of Excel platforms and update channels complicates this whole conversation, we’re hesitant to document specific implementation details at this time. When this active discussion resolved, we’ll update the documentation accordingly.

The version of TypeScript used by Office Scripts is currently 4.0.3. We are currently looking at a way to update the *Script versions without risking breaking existing scripts. Given that this upgrade path is still undefined in the product, that we have a layer of additional TS restrictions for Office Scripts (some of which that limit the IntelliSense), and that the nature of Excel platforms and update channels complicates this whole conversation, we’re hesitant to document specific implementation details at this time. When this active discussion resolved, we’ll update the documentation accordingly.

There are now lots of useful APIs available at runtime but missing TS types. In my smallish ~400-line script, I've had to resort to multiple hacks to get around this:
// let x = distances.at(-1)!
let x: number = distances['at'](-1)

// const obj = Object.fromEntries(...)
const obj: Record<string, string> = Object['fromEntries'](...)

// const settled = await Promise.allSettled(...)
const settled: ({ status: 'fulfilled', value: QueryResultData } | { status: 'rejected', reason: unknown })[] = await
Promise['allSettled'](...)

// const result = results.findLastIndex(...)
const result = results['findLastIndex' as string as 'findIndex'](...)

// const locale = new Intl.Locale(...)
const locale: { language?: string, script?: string, region?: string } = new Intl['Locale'](...)

It'd be really nice to have access to the latest APIs in TS as well as at runtime, especially given the lack of any support.
If the upgrade path is complicated by backward compatibility concerns, is there any possibility of relaxing the strict type checking requirements? I.e. scripts with type checking errors still run, they just show squiggly lines in the editor (and maybe warnings in the console), much like running TypeScript code in Deno without the --check flag.


Mood Style

Hi @jsmariegaard
I ended up doing a new branch with mood style as per your suggestion. Much cleaner.
I think we can close the old branch: https://github.com/DHI/fmskill/pull/150
by default now you get this

and when style=MOOD

Sure, no idea why they are gone, they should have been there.
I will add them

I don't why you changed the font size, but the monospace font now makes the alignment work. You still miss the equal signs, though.

Because I looked at the formatting done by Hendrik and he had those 2 lines (font size and left justification), I just copied the lines from the old PR


Aur build

makepkg no longer supports running as root, so I've made some changes to sudo execute as nobody, and to create the directories with enough permissions for nobody to write to them.

Note, it appears that this is being addressed in https://github.com/jesseadams/pacman/pull/4, but that hasn't been merged yet.  Happy to drop my pull request if we can get that one landed.


Add pentane molecule

[x] needs unit test

Just updated with some of ramanish's suggestions as well as some parametrization checks. Once these pass, LGTM!


The object created by the class becomes '[object Object]' in body, not JSON

Hi!
class SomeClass {
  x: number = 5;
}

const obj = new SomeClass();

console.log(obj); // SomeClass {x: 5}

function handleClick() {
  $fetch('http://localhost:7500/api/someurl', {
    method: 'POST',
    body: obj, // converted to string '[object Object]'
  })
  .then((result) => {
    console.log(result);
  })
  .catch((err) => {
    console.log(err);
  });
}

$fetch sends '[object Object]', not JSON.
Such ugly solution solves the problem:
  $fetch('http://localhost:7500/api/someurl', {
    method: 'POST',
    body: JSON.parse(JSON.stringify(obj)),
  })

Other solution of stange problem:
body: { ...obj },

Problem source: isJSONSerializable function from /src/utils.ts:
  return (val.constructor && val.constructor.name === 'Object') ||
   typeof val.toJSON === 'function'

@pi0
It would be appreciated if you let us know which the fact is: the conditional logic is intentional or could be improved.
If it's intentional, I'm glad to submit a PR to explain it in a part of README.

Hi sorry for not responding for long. In fact if you want to support serializable classes as body, they need to implement toJSON method. (PR welcome to improve docs and add an example 👍🏼 ) (closing for triage)


tests failing due to non transpiled code in node_modules

Version
react-native-router-flux v3.22.0
react-native v0.22
Expected behaviour
Tests run correctly
Actual Behaviour
When running tests, any imports of react-native-router-flux are breaking as throwing errors, 'unexpected import' . This is due to node_modules not being transpiled by babel. Looking through other packages in my node_modules, it seems the others are pre-transpiled.
I am following the code outlined in the enzyme guide for react native:
"scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "mocha --require react-native-mock/mock.js --compilers js:babel-core/register --recursive test/*.js"
  }

My own code is being transpiled correctly. A guide I have found have suggests that libraries should be transpiled, so I thought I'd see what your view was, and if you could recommend a solution.

https://github.com/aksonov/react-native-router-flux/issues/613

Duplicate of #613.

@cridenour : I see this issue as closed. But I am not able to clearly see a resolution. Do you have a recommendation / steps to fix the issue
@sattaman : Were you able to resolve the issue ?

@sathyakumarseshachalam I was able to get this project transpiling
http://stackoverflow.com/questions/37251534/how-to-test-project-when-3rd-party-modules-used-arent-transpiled
I have also moved my references to this project into my container components, which has allowed me to test my inner ones,
My current error thrown by this component is due to NavigationExperimental not being mocked, I noticed aksonov has an issue open regarding mocks for this. I also noticed that someone has PR'd mocks although not looked yet.

I'll chime in here, perhaps unnecessarily.
I too ran into this issue. The solutions in that StackOverflow post (which I believe are derivations of the real solution from the author of Enzyme) work great for other RN modules in general, but I still ran into RNRF issues, specifically issues with PNG images and the new react-native-experimental-navigation module.
In the end, I found it easier to use mockery:
const mockery = require('mockery');
mockery.enable({
    warnOnReplace: false,
    warnOnUnregistered: false
});
mockery.registerMock('react-native-router-flux', {Actions:{}});

I got this error after adding RNRF to my project:
`SyntaxError: ../node_modules/react-native-router-flux/src/menu_burger.png: Unexpected character '�' (1:0)

1 | �PNG
| ^
`

I have a setup.js file in my tests folder that set up everything needed to test in our project. Using the approach that @hellogerard used was great and it fixed my issues. Are there any downsides to using it though?

I got that error, uninstalled my app and reinstalled it on the next build, and it went away

@Twitchkidd did you get the error during runtime or automated testing? I'm able to run the project and it works great, but for the automated testing I get it

Oops, sorry, at runtime
On Monday, August 8, 2016, Cristian Asenjo<EMAIL_ADDRESS>wrote:

@Twitchkidd https://github.com/Twitchkidd did you get the error during
runtime or automated testing? I'm able to run the project and it works
great, but for the automated testing I get it
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aksonov/react-native-router-flux/issues/628#issuecomment-238379734,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJu0ifP6GcMbF-e4ZNTPZwOCU6s60l7pks5qd5xSgaJpZM4IWSsc
.


Initial support for Operator::Mult with multiple RHS

Interface upgrades for #3072, which is based on this branch.
Includes:

Operator::Mult(const Array<Vector *> &X, Array<Vector *> &Y) overload for application to multiple RHS. Base class implementation just loops over columns of the input and calls Mult on each Vector.
Operator::AddMult and Operator::AddMultTranspose methods to the base Operator class for derived classes which already implement this.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#3073
@sebastiangrimberg
@mlstowell
@psocratis + @jandrej
6/16/22
⌛due 6/30/22
⌛due 7/7/22

@jandrej Would you like me to close this one in favor of reviewing all of the changes together in #3073, or keep it open and review them separately in order?

If the Multigrid PR includes all changes here, I think it's quicker to review just the Multigrid PR.


reducer not updating state from action

🐛 Bug Report
I'm new to redux  and trying to get an action to produce a simple state update and component rerender in a new reactboilerplate project (that uses immer). Component to action is functioning correctly as confirmed by console.log, and I'm not passing any data, just an action that changes a boolean.
To Reproduce
Reducer:
import produce from 'immer';
import { SET_HOME_VISIBLE } from './constants';

// The initial state of the App
export const initialState = {
  homeVisible: false
};

/* eslint-disable default-case, no-param-reassign */
const homeReducer = (state = initialState, action) =>
  produce(state, draft => {
    switch (action.type) {
      case SET_HOME_VISIBLE:
        draft.homeVisible = true;
        break;
    }
  });

export default homeReducer;

Selectors:
/**
 * Homepage selectors
 */

import { createSelector } from 'reselect';
import { initialState } from './reducer';

const selectHome = state => state.home || initialState;

const setHomeVisible = state => state.homeVisible || initialState;

  const makeHomeVisible = () =>
  createSelector(
    setHomeVisible,
    homeVisibleState => homeVisibleState.homeVisible,
  );

export { selectHome, makeHomeVisible, setHomeVisible };

Actions (for continuity):
import { SET_HOME_VISIBLE } from './constants';

/**
 * Changes the input field of the form
 *
 * @param  {string} username The new text of the input field
 *
 * @return {object} An action object with a type of CHANGE_USERNAME
 */

export function setHomeVisible(homeVisible) {
  return {
    type: SET_HOME_VISIBLE,
    homeVisible
  };
}

Expected behavior
homeVisible should change from false to true in state.
Link to repro (highly encouraged)
Please provide either a CodeSandbox demo or a minimal repository on GitHub.
Environment

Immer version:
[ ] Occurs with setUseProxies(true)
[ ] Occurs with setUseProxies(false) (ES5 only)

Your reducer isn't used at all in your example code and I don't see any state. Please provide an isolated, runnable test case before filing a bug report. If you're not sure how to wire and organize reducers and the context of this question is Redux; try one of the official resources or Stack Overflow.
Without a reproduction this issue will soon be closed.

As mentioned above, this is a react-boilerplate project. You can easily start up a new clone of the package from https://github.com/react-boilerplate/react-boilerplate


how to style docs-description content

Let's say I would like to style h2 from a markdown description like:
 ## My new element

describe my element.

I am aware I can use ::part(docs-description) to set inherited css properties, like font-family. For instance, this will work (and all child elements from [part=doc-description] will inherit from the style):
      api-viewer::part(docs-description) {
        font-family: 'Roboto', 'Noto', sans-serif;
        -webkit-font-smoothing: antialiased;  /* OS X subpixel AA bleed bug */
      }

However, what would be the option if I want to style a h2 element within my markdown description? This for instance has no effect on h2 title element:
api-viewer::part(docs-description) h2 {
    font-size: 34px;
    font-weight: 400;
    letter-spacing: -.01em;
    line-height: 40px;
}

Any other better alternative than dynamically appending a link[rel=stylesheet] tag to api-viewer-content ?

Hi, if you want to provide your own styles, you can import base class and then register your own custom element, which lets you provide your own styles using css tagged literal.
However I think we can fix that by doing a set of RegExp replacements to marked output:
'<h2>'.replace(/<(h([2-6]))>/, '<$1 part="docs-$1">'); // "<h2 part="docs-h2">

So, thanks for the idea! I think this improvement makes a lot of sense. Will add to my TODO list.

Thanks for this rapid answer !

Hi, if you want to provide your own styles, you can import base class and then register your own custom element, which lets you provide your own styles using css tagged literal.

That makes sense. So we would have - in the extended custom element
static get styles() {
    return [
      ...super.styles,
     css`
     [part='docs-description'] h2 {
        your new style
      }
     `
  }

As we can already provide templates for demo, what about using a similar mechanism for injecting style (I suspect the proposed regex solution might fall short in a lot of situation - what about table, list...)?
<template data-target="parent">
   <style>
      your style
   </style>
</template>

I miss vaadin-theme sometimes ; )

I'm ok to also provide API for injecting styles, but please create another issue where we could discuss it so you could better illustrate the problem that you are trying to solve.
Regarding Vaadin styling approach, the ultimate idea of <api-viewer> is to avoid any opinionated solutions and to purely rely on the platform API - for example, <template> and ::part.

@web-padawan - all right and many thanks.
Actually, extending the base class works well and solves my use case.
For reference and potential future users having similar requirements :

import { ApiViewer } from 'api-viewer-element';
import { css } from 'lit-element';

class DemoApiViewer extends ApiViewer {

  static get styles() {
    return [
      super.styles,
      css `

       [part='docs-description'] h1 {
          font-size: 45px;
          font-weight: 400;
          letter-spacing: -.018em;
          line-height: 48px;
        }

        [part='docs-description'] h2 {
          font-size: 34px;
          font-weight: 400;
          letter-spacing: -.01em;
          line-height: 40px;
        }

        [part='docs-description'] h3 {
          font-size: 24px;
          font-weight: 400;
          letter-spacing: -.012em;
          line-height: 32px;
        }

        [part='docs-description'] h4 {
          font-size: 16px;
          font-weight: 400;
          line-height: 24px;
        }

        [part='docs-description'] h5, [part='docs-description'] h6 {
          font-size: 14px;
          font-weight: 500;
          line-height: 24px;
        }
   `
    ];
  }
}

customElements.define('demo-api-viewer', DemoApiViewer);

Done by #22 and will be included to the upcoming 0.4.0 release.


iOS addOnBackgroundMessage and  addOnMessage not working

xcrun simctl push booted com.app.app push.json

{
  "aps": {
    "alert": {
      "title": "Test",
      "body": "hello message"
    }
  }
}

onInit(){

Push.instance.addOnMessage((message) {
      log('RemoteMessage received while app is in foreground:\n'
          'RemoteMessage.Notification: ${message.notification} \n'
          ' title: ${message.notification?.title.toString()}\n'
          ' body: ${message.notification?.body.toString()}\n'
          'RemoteMessage.Data: ${message.data}');
      showMaterialBanner(message.toString());
    });

    Push.instance.addOnBackgroundMessage((message) {
      log('RemoteMessage received while app is in background:\n'
          'RemoteMessage.Notification: ${message.notification} \n'
          ' title: ${message.notification?.title.toString()}\n'
          ' body: ${message.notification?.body.toString()}\n'
          'RemoteMessage.Data: ${message.data}');
      _showMaterialBanner(message.toString());
    });

}

There's not enough information here yet.

can you explain what's happening?
What version of push are you using?
Can you try using the send_ios.sh tool and see if that works? https://github.com/ben-xD/push/blob/4798e922ed1e21a68b9270dbe79f495c52f5ac2e/tools/ios/README.md#L1


Backdrop does not go behind scrollbar on chrome

Short description of the problem:
The backdrop does not go behind the scrollbar on chrome leaving an area with no backdrop on the right side of the screen.
Which Ionic Version? 2.x

After researching the issue i have found that if you set ::-webkit-scrollbar to display: none in the css that it fixes this issue. This css property causes the scrollbar to be hidden by default, even with a mouse plugged in, in all webkit based browsers (chrome, safari etc etc).


JAVA_HOME is not set and no 'java' command could be found in your PATH

Steps to Reproduce

fresh install android studio
try to run any flutter app

Logs

Launching lib\main.dart on Android SDK built for x86 in debug mode...
Running Gradle task 'assembleDebug'...
ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
Exception: Gradle task assembleDebug failed with exit code 1

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.7.0, on Microsoft Windows [Version 10.0.22000.1516], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[X] Android toolchain - develop for Android devices
    X cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
[√] Chrome - develop for the web
[X] Visual Studio - develop for Windows
    X Visual Studio not installed; this is necessary for Windows development.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components
[!] Android Studio (version 2022.1)
    X Unable to find bundled Java version.
[√] Connected device (4 available)
[√] HTTP Host Availability

! Doctor found issues in 3 categories.

btw I managed to solve this issue by coping the content of jbr directory in jre.
But it still a bug and I have spent 2 days debugging it.

Thanks for the report @MunibullahShah
I think your issue probably is similar to https://github.com/flutter/flutter/issues/110807 so please check the same and confirm if you can follow-up in that issue for further updates.

The issue is that Jetbrains moved the location of the Java runtime from jre to jrb and the code in flutter/packages/flutter_tools/lib/src/android/android_studio.dart, does this:
final String javaPath = globals.platform.isMacOS ?
        version != null && version.major < 2020 ?
        globals.fs.path.join(directory, 'jre', 'jdk', 'Contents', 'Home') :
        globals.fs.path.join(directory, 'jre', 'Contents', 'Home') :
        globals.fs.path.join(directory, 'jre');

For this to work, it should either have an "else" to deal with newer versions (2022.1 'electric eel' is the new one) where the path is jbr instead.
I have not tried this, as modifying the Dart files alone is not enough according to my limited understanding on how flutter <command> functions; one would have to "recompile" the flutter binary.

@darshankawar mine is little different, the issue you mentioned does not want to use default jdk, I want to use that but it can't find jdk.
It moved its jdk from jre to jbr but it still looks in jre for the files

Thanks for the update @MunibullahShah and for sharing your findings @Gryzor
I see that there's similar issue with all the details and a potential fix related to AS Electric eel version https://github.com/flutter/flutter/issues/106674 in which you can follow-up for further updates. You may also share your findings in that issue for better tracking.
I'll close this in favor of the linked issue. If you disagree, write in comments and I'll reopen it.


System.ObjectDisposedException occured after reopen folder in workspace.

Steps to Reproduce
1.Open Folder in vs
2.Right click ->add new item->python->Empty Module, rename as test_1.py
3.Typing test code in test_1.py
4.Enable unittest and open TE
5.test_a can be found in TE at this time, no error in Output-> Tests tab, and the click File->close folder and reopen this folder.
Expected behavior
test_1 should be found in TE with no error
Actual behavior
test_1 could not be found, and error occurred.
Output->Tests log
Log level is set to Informational (Default).
Test data store opened in 0.053 sec.
---------- Starting test discovery ----------
Starting unittest discovery for the New folder (5) workspace. This can take up to 60 seconds.
cd C:\Users\vwazho\Downloads\New folder (5)
set PYTHONPATH=C:\Users\vwazho\Downloads\New folder (5)\
C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\python.exe C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\PREVIEW\COMMON7\IDE\EXTENSIONS\MICROSOFT\PYTHON\CORE\PythonFiles\testing_tools\run_adapter.py discover unittest --output-file C:\Users\vwazho\AppData\Local\Temp\tmp2D9C.tmp -- . test*.py
========== Test discovery finished: 2 Tests found in 3.6 sec ==========
System.ObjectDisposedException: The CancellationTokenSource has been disposed.
   at System.Threading.CancellationTokenSource.ThrowObjectDisposedException()
   at Microsoft.VisualStudio.TestWindow.Internal.TestWindowViewModel.CancelOrStopProgressBarSpinning()
   at Microsoft.VisualStudio.TestWindow.Internal.TestWindowViewModel.<<OnStateChanged>b__80_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Extensibility.ILoggerExtensions.<CallWithCatchAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
System.InvalidOperationException: Failed to perform operation, the store is closed.
   at Microsoft.VisualStudio.TestWindow.Host.TestWindowStoreService.ThrowOnClosedStore()
   at Microsoft.VisualStudio.TestWindow.Host.TestWindowStoreService.<>c__DisplayClass25_0.<RemoveViewAsync>b__0()
   at Microsoft.VisualStudio.TestWindow.Extensibility.ILoggerExtensions.<CallWithCatchAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
System.InvalidOperationException: Failed to perform operation, the store is closed.
   at Microsoft.VisualStudio.TestWindow.Host.TestWindowStoreService.ThrowOnClosedStore()
   at Microsoft.VisualStudio.TestWindow.Host.TestWindowStoreService.<>c__DisplayClass25_0.<RemoveViewAsync>b__0()
   at Microsoft.VisualStudio.TestWindow.Extensibility.ILoggerExtensions.<CallWithCatchAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
Test data store opened in 0.030 sec.
---------- Starting test discovery ----------
========== Test discovery finished: 0 Tests found in 4.6 sec ==========

build info

Filed internal bug 1134815


Support for Markdown strikethrough

I don't understand the relationship between between VS Code and this extension. But VS Code just added support for rendering ~~strikethrough text~~ in Markdown files differently in the editor. However, with your theme "Noctis Bordo", it currently isn't rendered any different.
Since your read-me lists Markdown as a supported language, is there anything you can do about that, so that strikethrough text is rendered differently -- I'd imagine with strikethrough effect?

Hi, this should have been fixed. Please let me know if that's the case.

The whole ~~strikethrough text~~ now has a strikethrough effect. However, the rendering differs from *italic* and **bold** text. For italic and bold, the asterisks making the text italic or bold are also italic or bold, respectively. But they're also gray! So, ~~ to the left and to the right should follow that pattern and be gray.
But since strikethrough interferes with the text, I think it would be best to omit the strikethrough effect for ~~. Without strikethrough effect, it's like a continuation of the strikethrough, anyway.
The strikethrough line is also a bit thick. Is there a way to make it thinner? You should be able to quite easily read the text, while still quickly and intuitively understanding that there's strikethrough markup. If it's impossible, it's okay.

I grayed out tilde character and removed "Cinnabar" color from the strike-through text. I think this should make it more readable. There is no way, as far as I know, to fiddle with the strike-through line, so I'll leave it as is.

Okay. Then let's close this. Thank you!


Actually retry starting instance on timeout

Add some logging, simplify logic.
review by @lrytz, please

LGTM!

Thanks! Will update plugin on next jenkins restart, I think. It's already at the download site where chef will download it.

(This is not yet automated -- I did:
mvn package
cp /Users/adriaan/git/ec2-start-stop/target/ec2-start-stop.hpi ~/Dropbox/Public/ec2-start-stop.hpi

chef is configured to download it from my dropbox and install the plugin on its next run. Chef-client runs every 30 mins on jenkins-master)


Fix macos compatiblity

Pre-installs necessary packages for it to work on Mac OS.

Yes, make it upstreamed instead of a separate dub package will be good


fetch: convert a NULL property query to ""

Previously, a NULL property query was never cached and this lead to a
performance degregation.  Now, such a query is converted to an empty string
and cached.
Fixes #17752
Fixes https://github.openssl.org/openssl/openssl/issues/26

[ ] documentation is added or updated
[ ] tests are added or updated

Unless the performance improvement here is very significant, this shouldn't be backported to 3.0.

Do we need a test for the inner_ossl_decoder_fetch returning 0 on NULL propquery?

I don't feel a strong need for such a test.  This is internal non-user facing code.

Merged to master.

@paulidale should this be merged also to 3.0? The original issue has the 3.0 branch label.
I'd be OK with merging it there.

@mattcaswell what do you think about 3.0 for this?
I thought about it but we've not back ported performance fixes previously.

Added to today's OTC discussions.


Verify cull_mode is correct in all pipelines

Looks like it's turned off

Confirmed the only culling we really want to do right now is backface culls on meshes


Change: standard logging --> github.com/sirupsen/logrus

This PR is addressed to #57

@aleksei-burlakov update to go.sum is missing (see CI failure)

@aleksei-burlakov I would take advantage to work more on this task.
We would need to setup a proper logging system, which send the logs to a configured log file with used log levels etc.
I would expect to have some logfile in /var/log/trento/agent.log (be default) or so, and be able to configure the logging level.
I think it would make sense to work it in this PR

Hmm, hey Xabi, I disagree here: as we previously discussed, I don't think we need to implement logging on files. Cloud-native applications can just log to stdout, and rely on other external mechanism to gather the logs into something else.

Hey Aleksei, can we have a new cli flag to change the log level?

Sure. It will come in a new comit.

@aleksei-burlakov I would take advantage to work more on this task.
We would need to setup a proper logging system, which send the logs to a configured log file with used log levels etc.
I would expect to have some logfile in /var/log/trento/agent.log (be default) or so, and be able to configure the logging level.
I think it would make sense to work it in this PR

Hmm, hey Xabi, I disagree here: as we previously discussed, I don't think we need to implement logging on files. Cloud-native applications can just log to stdout, and rely on other external mechanism to gather the logs into something else.

I commented this because most of the well known logging libraries in all languages don't implement this in the code, it comes just in a configuration file. I just commented to have the option to have this configuration, that again, comes from a configuration file, so it would be agnostic.
If this is not the case in golang/logrus, omit my comment.

PD: I'm sure we will finish implementing the log to file mechanism. This is how many sys admins like to work, and even though you say cloud-native, the trento agent will be just yet another package/daemon running in a machine ;)

Yes, of course we'll do that, but my point is that we don't need this within the Trento application itself, because there are other OS facilities that we can use for it, e.g. the systemd journal. :)

PD: I'm sure we will finish implementing the log to file mechanism. This is how many sys admins like to work, and even though you say cloud-native, the trento agent will be just yet another package/daemon running in a machine ;)

Yes, of course we'll do that, but my point is that we don't need this within the Trento application itself, because there are other OS facilities that we can use for it, e.g. the systemd journal. :)

I have accidentally closed the PR. Reopening it.

Hey Aleksei, can we have a new cli flag to change the log level?

Done. In the new commit.


Mutation rate in AlphaPeel

We should clarify what mutation rate is used in AlphaPeel and we should possibly make it as an input parameter (assuming we do not have this yet!?)

Does this mean rewriting an existing penetrance function？

Last time I checked I think that mutation rate is baked (fixed) in the code - in the  Mendelian transmission function. The penetrance function deals with genotyping and sequencing errors. While we provide a way to specify these error rates, we do not provide a way to specify mutation rate (I think).
@AprilYUZhang please check this and let’s work on this aspect via this issue. Thanks!


TP2000-1071  Implement workbasket detail view redesign

TP2000-1071  Implement workbasket detail view redesign
Why
In preparation for the Workbasket Summary design improvements, the Workbasket Detail view (accessible via Find and View Workbasket) must undergo a redesign, bringing across the component list from the summary view from which users will be able to view and remove workbasket items.
What

Adds WorkBasketDetailView to display details of a workbasket under 'Details' tab
Adds WorkBasketChangesView to display workbasket items and allow deletion under 'Changes' tab
Enables sorting of workbasket items by component type, action or activity date
Prevents users without change_workbasket permission from removing items in a workbasket or when the workbasket is not in EDITING state
Adds two new URL routes (<pk>/changes/delete/ and <pk>/changes/confirm-delete/) for deleting workbasket items from new Workbasket Changes view
Modifies the existing WorkBasketDeleteChanges view to maintain deletion capability with Workbasket Summary view until the full redesign work is implemented
Styles pagination as a 'Load more' button, returning the previous pages' plus the new page's results and displaying a progress indicator
Adds view tests

Before

After
Detail view

Changes view

Changes view pagination

Codecov Report
Attention: 26 lines in your changes are missing coverage. Please review.

Comparison is base (fafe3dd) 92.77% compared to head (dd20223) 92.77%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1066      +/-   ##
==========================================
- Coverage   92.77%   92.77%   -0.01%
==========================================
  Files         460      460
  Lines       34124    34262     +138
  Branches     2601     2614      +13
==========================================
+ Hits        31659    31785     +126
- Misses       1967     1973       +6
- Partials      498      504       +6

Files
Coverage Δ

workbaskets/tests/test_views.py
96.65% <100.00%> (+0.37%)
:arrow_up:

workbaskets/urls.py
100.00% <ø> (ø)

workbaskets/views/ui.py
86.36% <69.41%> (-0.04%)
:arrow_down:

... and 2 files with indirect coverage changes

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


#128 Remove gas based commission

@nevendyulgerov,
The PR #140 is already merged. Therefore, a rebase should solve the build problem here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.2%) to 72.506%

Files with Coverage Reduction
New Missed Lines
%

apps/staking/src/components/pools/steps/CommissionModel/FlatRateCommission.tsx
2
84.38%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
2317

Relevant Lines:
3046

💛  - Coveralls


Images fromHTML are not scaled correctly

jsPDF v1.3.3
Steps to reproduce
var doc = new jsPDF("p","mm","letter");
doc.fromHTML($("#element").get(0), 15, 15, {
   'width': 170, function(a) {
      doc.save("Image.pdf");
});

This is some test text with a test image.

Live Example
http://jsbin.com/hekaguheza/edit?html,js,output
What I saw
The image element will be scaled from 100 x 100px to 100 x 100mm without any scaling, which results in a disproportionate image compared to the rest of the document.
What I expected
I expected that the pixel width and height be scaled from pixels to millimeters (100 * 0.264583) before rendering.

Maybe it will be fixed by modifying from_html.js
renderer.pdf.addImage(cached_image, imageX, renderer.y + additionalSpaceTop, cn.width, cn.height);
changing to:
renderer.pdf.addImage(cached_image, imageX, renderer.y + additionalSpaceTop, cn.width*renderer.pdf.internal.scaleFactor, cn.height*renderer.pdf.internal.scaleFactor);
if it works, maybe in a further place you have to do the scaleFactor too, because the renderer has to know the correct position

We are closing this issue, because we will not support any longer fromHTML and addHTML.
Explaination:
We are working on a new html2pdf plugin, which will be based on html2canvas and our context2d plugin. This should lead to more reliable results for your projects. And it will give us the time to focus on the core functionality of pdf-generation because we will not use our energy for writing/supporting/extending 2 html plugins. If you still want to use addHTML or fromHTML you can still use jsPDF 1.4.1.
Best Regards


Damping subprotocol

This PR introduces a Damper object which is responsible for:

Tracking flappy members. A flappy member is one whose damp score exceeds the suppress limit.
Periodically running a background damp timer that asks N-random other members for the damp scores of the same flappy members
"Damping members" if the damp scores from the N-random members also exceed the suppress limit.
Expiring damped members after members have been damped for greater than the suppression duration.

This PR does not actually 'treat' damped members other than logging an error when a Ringpop would have put a member in the damped status. The behavior to treat damped members will come in a later PR.
This PR is over 1200 lines. Take your time with it and of course, let me know if you have any high-level or fundamental questions.
Would like a lgtm from: @thanodnl @CorgiMan
Would appreciate eyes and high-level feedback from: @benfleis @danielheller
@uber/ringpop

Overall love the style and efforts for clarity. For me as a reader, there are a couple places that fall short of the high standard:

rVal and nVal seem undernamed -- they tell me nothing by name, and I didn't see an introduction giving them context.
IMHO some things should be prefixed with Damp/Damping, a la suppression events, reuse. If the intention is that suppress and reuse are "generic", I might also suggest more generic and clearly complementary (and idempotent) names, e.g., Ignore/Unignore, Exclude/Include, Embargo/Allow :), etc. (I didn't spend enough time to understand how generic they related funcs/code could be.)
if (foo) bar(); - this seems to violate what we've been doing thus far, as well as uber-standard.  (grep -r 'if .*;' *.js lib test)
request_response.js doesn't feel 'top level', especially when accessing internals like ringpop.dissemination: -> lib/?

I am done.


SVGIconImageDemoFMX not compiling with Delphi 11.1

btw, I tried that demo since it had "Stretch" option. How can I tell TSVGIconImage to stretch its SVG? It seems to do place/fit action always with no property to select you want to allow stretch to occur (nor other more advanced placement options like tiling etc.)


Forbid wrong 'expires' values when low-level API is used that silently results in always expired responses

This PR closes https://github.com/requests-cache/aiohttp-client-cache/pull/286
As I explained on that page:

convert_to_utc_naive()  is not called for low-level API and it is a user responsibility to convert to a naive datetime. On our side we can raise an error.
save_response() and from_client_response() allow to save any random object as expires, including classes, functions, etc. and all these bad things work silently.

An alternative solution is moving convert_to_utc_naive() call inside the from_client_response().

Notes:
        except (AttributeError, TypeError, ValueError):

AttributeError is impossible because self.expires = None is the default class attribute.
TypeError is handled now by verifying that we work with a naive datetime.
ValueError - I have no idea how you can get it when you compare two datetime objects. Perhaps an old leftover.

Breaking changes:
There are no breaking changes.
Users who used the low-level functions directly (save_response() and from_client_response()) incorrectly by passing a wrong expires value will get an error. This is expected because so far, with the old code, their cache never worked correctly.

The commit history is clean and tidy, so do not squash the commits.

@layday Would you like to take a look on this change?

Do you have time to publish a patch release for this?
If not, I can do that after work today.

Do you have time to publish a patch release for this?
If not, I can do that after work today.

Please update the changelog and release a package today/tomorrow if you have time.

Sure, sounds good.

Hi @JWCook @alessio-locatelli, can you please release a version with this fix?

@JWCook @alessio-locatelli I tried to use 0.12.4.dev33
And got a failure:
self = CachedResponse(method='GET', reason='OK', status=200, url=URL('https://pypi.org/simple/ddtrace/?q=RNvnAvOpyEVAoNGnVZQU...org/simple/ddtrace/?q=RNvnAvOpyEVAoNGnVZQU'), history=(), last_used=datetime.datetime(2024, 10, 30, 9, 25, 18, 370048))

    @property
    def is_expired(self) -> bool:
        """Determine if this cached response is expired"""
>       return self.expires is not None and utcnow() > self.expires
E       TypeError: can't compare offset-naive and offset-aware datetimes

.venv/lib/python3.12/site-packages/aiohttp_client_cache/response.py:170: TypeError

So I believe the original issue still exists?

@JWCook @alessio-locatelli I tried to use 0.12.4.dev33
And got a failure:
self = CachedResponse(method='GET', reason='OK', status=200, url=URL('https://pypi.org/simple/ddtrace/?q=RNvnAvOpyEVAoNGnVZQU...org/simple/ddtrace/?q=RNvnAvOpyEVAoNGnVZQU'), history=(), last_used=datetime.datetime(2024, 10, 30, 9, 25, 18, 370048))

    @property
    def is_expired(self) -> bool:
        """Determine if this cached response is expired"""
>       return self.expires is not None and utcnow() > self.expires
E       TypeError: can't compare offset-naive and offset-aware datetimes

.venv/lib/python3.12/site-packages/aiohttp_client_cache/response.py:170: TypeError

So I believe the original issue still exists?

@shaked-seal  I have no idea how to reproduce this unless you show a small example of how you use the library.

I was able to reproduce when overriding "expires" to have a time-zone. We removed that. I added a check that when using CachedResponse the expires shouldn't be with timezone.
Thank you for the quick fix!


Add more useful error for bad credentials.

The www-authenticate: basic response currently gets caught by
the token transport, which fails to parse it and spits out
a rather oblique "malformed auth challenge header" error.
Make the token transport ignore basic auth types, and make
the error transport handle any 401 responses that reach it.

Thanks!

Oops, sorry! Done.

Thanks!!!


Remove the need for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to be set with Digital Ocean deployment

Closes #1343
Changes introduced in this PR:
AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY will be automatically set based on SPACES_ACCESS_KEY_ID and SPACES_SECRET_ACCESS_KEY.
Types of changes
What types of changes does your PR introduce?
Put an x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features to not work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[X] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing
Requires testing

[X] Yes
[ ] No

Further comments (optional)
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered and more.

@viniciusdc this will allow you to remove the need for setting those environment variables for the Digital Ocean deploymet.

@costrouc may I ask if you can do a DO render over this branch to validate if everything works? -- as the CI envs here possess all the necessary keys already, we might be unable to identify some exceptions

I will be testing this on DO, today

HI @costrouc sorry for the messy revert there, It seems that the destroy command fails with the missing environments -- I tried adding a quick workaround, but the error persisted so I reverted the PR.

to fix the destroy part we just need to add the new terraform state context manager in gather_stage_outputs and destroy_stages of destroy.py


[CELEBORN-1469] Support writing shuffle data to OSS(S3 only)

What changes were proposed in this pull request?
as title
Why are the changes needed?
Now, Celeborn doesn't support sinking shuffle data directly to Amazon S3, which could be a limitation when we're trying to move on-premises servers to AWS and use S3 as a data sink for shuffled data.
Does this PR introduce any user-facing change?
No
How was this patch tested?

Hi @zhaohehuhu, there is some tools that can check codes PR locally.
Run ./dev/reformat could check code style and compilation errors.

@zhaohehuhu, please add comment for the test result.

UPDATE=1 build/mvn clean test -pl common -am -Dtest=none -DwildcardSuites=org.apache.celeborn.ConfigurationSuite
This could update the docs as you have changed CelebornConf.

Hi @zhaohehuhu, there is some tools that can check codes PR locally. Run ./dev/reformat could check code style and compilation errors.
Done. Thanks.

UPDATE=1 build/mvn clean test -pl common -am -Dtest=none -DwildcardSuites=org.apache.celeborn.ConfigurationSuite This could update the docs as you have changed CelebornConf.

Done. Thanks.

@zhaohehuhu, please add comment for the test result.

Got it. Thanks.

@zhaohehuhu, please add comment for the test result.

Hi bro, The PR is only part of S3 storage layer feature, so I can't provide a complete test now. But the above screenshot shows the shuffle data was successfully sink in S3 already.

Thanks for your effort. I'll complete the review within the next week.

@zhaohehuhu Thanks for your effort. The review will be done within this week.
BTW,I noticed the binary package of Celeborn grows up to 468MB and there is a single jar "aws-java-sdk-bundle-1.12.367.jar" which is 310 MB.
Is there any solution to reduce the binary package size?

The public cloud client jars size is crazy, especially aws(v1 300MiB+, v2 500MiB+), we should not ship them by default.

You can fix the style issues and license issues using the following commands
./dev/reformat
build/mvn org.apache.rat:apache-rat-plugin:check -Pgoogle-mirror,spark-3.3

crazy

got it.

You can fix the style issues and license issues using the following commands
./dev/reformat
build/mvn org.apache.rat:apache-rat-plugin:check -Pgoogle-mirror,spark-3.3

OK. Thanks

Merged into main(v0.6.0)