Remove Unit ID from bulk data files

Context
Modify bulk data files to exclude unit id. Will need to modify the c sharp process to complete this task.

Need to complete modifications to the streaming endpoints first before this ticket can be worked on

Moving to new tickets to discuss in the next stand-up.

Agreed to not move forward with this ticket


ENH: stats: optimised MLE for the lognormal distribution

Reference issue
Part of gh-11782.
What does this implement/fix?
When the location is known (i.e., two-parameter lognormal), the MLEs for shape and scale have analytical expressions; this case was already handled.
When the location is unknown, the three-variable numerical optimisation can be cast to a one-variable optimisation. Marginal gains in accuracy and an appreciable speed-up follow.

Performance improvement is still good:

I messed something up with recording the NLLF data, so I'll post that information when it's done running again.

What I do is add at the very beginning of fit:
        if kwds.pop('superfit', False):
            return super().fit(data, *args, **kwds)

Then here's the experiment code:
import numpy as np
from scipy import stats
from time import perf_counter
import matplotlib.pyplot as plt

rng = np.random.default_rng(2433006235492611347)
qrng = stats.qmc.Halton(5, seed=rng)

N = 1000
times_pr = np.full(N, np.nan)
times_super = np.full(N, np.nan)
nllfs_super = np.full(N, np.nan)
nllfs_pr = np.full(N, np.nan)

for i in range(N):
    print(i)
    sample = qrng.random()
    sample = stats.qmc.scale(sample, [-3, -3, -3, 1, -1], [2, 3, 3, 5, 1])[0]
    s, loc, scale, size = 10**sample[:4]
    loc_sign = np.sign(sample[4])
    loc *= loc_sign
    size = int(size)

    dist = stats.lognorm(s, loc, scale)
    rvs = dist.rvs(size=size, random_state=rng)

    try:
        tic = perf_counter()
        s_fit, loc_fit, scale_fit = stats.lognorm.fit(rvs)
        toc = perf_counter()
        nllf_pr = stats.lognorm.nnlf((s_fit, loc_fit, scale_fit), rvs)
        nllfs_pr[i] = nllf_pr
        times_pr[i] = toc-tic

    except Exception as e:
        print(f"Failure: {e}")

    try:
        tic = perf_counter()
        s_fit, loc_fit, scale_fit = stats.lognorm.fit(rvs, superfit=True)
        toc = perf_counter()
        nllf_super = stats.lognorm.nnlf((s_fit, loc_fit, scale_fit), rvs)
        nllfs_super[i] = nllf_super
        times_super[i] = toc-tic

    except Exception as e:
        print(f"Failure: {e}")

nllf_diff = (nllfs_pr - nllfs_super)/np.abs(nllfs_super)
nllf_diff = nllf_diff[np.isfinite(nllf_diff)]
nllf_diff_good = -nllf_diff[nllf_diff < 0]
nllf_diff_bad = nllf_diff[nllf_diff > 0]

plt.hist(np.log10(times_pr), alpha=0.5)
plt.hist(np.log10(times_super), alpha=0.5)
plt.legend(('PR', 'main'))
plt.xlabel('log10 of `fit` execution time (s)')
plt.ylabel('Frequency')
plt.title('Histogram of log10 of `fit` execution time (s)')

# plt.hist(np.log10(nllf_diff_good))
# plt.xlabel('log10 of NLLF relative improvements')
# plt.ylabel('Frequency')
# plt.title('Histogram of log10 of NLLF relative improvements')

# plt.hist(np.log10(nllf_diff_bad))
# plt.xlabel('log10 of NLLF relative regression')
# plt.ylabel('Frequency')
# plt.title('Histogram of log10 of NLLF relative regression')

The advantages being that there is no restriction on eta, which can span the real line (even though numerical problems can still arise for small values, because of the exponential); and no need to iteratively determine a bracketing interval for minimize_scalar.

Why does that help, though? You mean that the bracket is the entire real line? (By the same logic, then, we can already set the bracket between -1e300 and np.min-eps, so I wouldn't understand the advantage here.)

I made two improvements:

There are some problems for which dL_dLoc is positive extremely close to np.min(data) but turns negative just a little further away (but still close). We want to find an rbrack such that dL_dLoc(rbrack) is negative. Turns out it works pretty well to iterate to find such an rbrack (before iterating to find lbrack:

            rbrack = np.nextafter(min(data), -np.inf)
            i = 1
            delta = np.min(data) - rbrack
            while dL_dLoc(rbrack) >= 0:
                i *= 2
                rbrack = np.min(data) - delta*i

In some cases, this led to rbrack being very, very far to the left, when eventually dL_dLoc goes negative - probably just due to numerical noise, whereas in reality it tends toward positive zero. If this is the case, that means that dL_dLoc is always positive, meaning that there is no root to be found. This was the case I asked about above:

This brings to mind another possible issue - is the optimal solution ever at loc = rbrack?

Yes. If you detect that dL_dLoc is always positive, set loc = np.nextafter(min(data), -np.inf) and use the formulas for shape and scale.
I get the following (much better) results:

I'll still need to study those few remaining regressions to see what is going wrong.

Or - is there some way to definitively determine whether the dL_dLoc is always positive based on the data (without searching) based on some sort of bounding arguments?_

I do not see anything obvious. log(data-loc)/(data-loc) is clearly bounded from above; but throwing in shape and scale makes things less obvious.
I set a threshold on the ratio (min(data)-loc)/(max(data)-loc), based on the idea that loc should stay relatively close to min(data).
For the datasets generated in the Montecarlo experiment, that ratio goes up to 310, with a median of 3.6e-1; I set the limit to 1000 and got histograms very similar to yours.
I put them back in the changes to the docstring and the typo fix in tests/test_distributions.py that were rolled back.

Hypothesis points out i in the rbrack loop should be promoted to a float.
I also can put back the derivative bit, just to cover the case of an initial guess for loc being passed; or mention in the docstring that it will be ignored.
Do you see other changes to make?

I would state that guesses are ignored. That's fine if we can provide a relatively bulletproof implementation. I'm still finding counterexamples, though, so I think we need a little more tuning.

I made a few tweaks; hypothesis is happy, except for very small-sized samples, but performance took a hit.
This paper suggests an estimation method based on a measure of skewness (not the usual sample skewness, but an index depending only on the first and last order statistics and the median), which has an analytical solution. The author uses it as a starting point to make suggestions for confidence intervals on loc, which could be used as bounds when iteratively searching a bracket.
However, they would require solving numerical problems, themselves, which is not ideal. I will run experiments to see whether  "acceptable" variations in this skewness could be bootstrapped and inverted to analytically get a threshold on lbrack.

"except for very small-sized samples"
We could revert to super based on sample size. I've noticed that they tend to be the most problematic, too.

@Tartopohm what do you think we should do here? Previously, my philosophy for these fit overrides has been to "do no harm", to the extent that if we observe cases in which the super fit method does better, the override is not ready.
My recent overrides of weibull_min.fit and skewnorm.fit don't strictly follow that philosophy, but really they only attempt to improve the guess of the generic optimization routine rather than provide analytical MLEs. So they are only better on average.
Should we take that stance here? This is almost always better, but we can still find edge cases. Would you be willing to do more to make it bulletproof, or would you prefer it be accepted as-is?

@Tartopohm what do you think we should do here? Previously, my philosophy for these fit overrides has been to "do no harm", to the extent that if we observe cases in which the super fit method does better, the override is not ready.
My recent overrides of weibull_min.fit and skewnorm.fit don't strictly follow that philosophy, but really they only attempt to improve the guess of the generic optimization routine rather than provide analytical MLEs. So they are only better on average.
Do you think that is ok here? This is almost always better, but we can still find edge cases. Would you be willing to do more to make it bulletproof, or would you prefer it be accepted as-is?

I could not work on it as much as I would have wanted recently.
As I see it now, the two main edge cases are:

divergence when loc goes to min(data);
absence of a maximum to the LL function, e.g. the derivative goes to 0 only at negative infinity, but numerical noise before that leads to ridiculously small location values.

You handled the first case. For the second case, I think preemptively setting a lower bound of acceptable locations seems to work well.
For N=5000, I got the following:
>>> np.array((sum(nllf_diff < 0), sum(nllf_diff == 0), sum(nllf_diff > 0)))/N
array([0.9898, 0.0076, 0.0026])
>>> nllf_diff[np.nonzero(nllf_diff > 2e-15)[0]]
array([1.74568658e-06, 1.77223498e-05, 4.68319332e-05])

These first two "fails" have smallish sample size (10, 11), and negative sample skewness.
The last one is fixed by setting the root_scalar xtol argument to 1e-14.
Performance is better 100% of the time.

(Realising later that the labels are not all correct, but you get the idea!)
I am still running a few tests, I will push something asap

Sorry that this is taking so long @Tartopohm. The latest commits were quite complex, so I'll need some time to play with this some more.

It sounds like this could be quite useful. Just to keep my release duties somewhat sane, I'm going to bump the milestone because there's a merge conflict and this hasn't had activity in over a month + mention of the complexity of some recent commits here. Certainly if this gets merged before I branch for the next release, go ahead and add the milestone of course. Just trying to keep the list of "blockers" for the release reasonably sized.

Thanks @tylerjereddy I was just coming here to clear the milestone.

Rather than let this sit forever, I reverted the last few commits; better to get something merged than nothing.
There is always a balance to strike considering complexity and performance. If this isn't going to be perfect, it should at least be simple. We can reconsider those commits in a separate PR if desired.
I also made adjustments so that the override bails and reverts to the default fit method if anything seems to be awry. I've only ever seen this occur when the MLE of loc is the minimum of the data, but I can't rule out the possibility that this occurs for some other reason. So for now, it seems better to be safe than give an incorrect result. Again, we can consider changing this back in a separate PR if desired.
A backup branch from before tonight's changes is here.
I'll run some more computer experiments tomorrow. If things look good, I'll go ahead and merge.

@tupui Lint is complaining about lines that weren't touched in this PR. Can these be ignored?

Rather than let this sit forever, I reverted the last few commits; better to get something merged than nothing.
There is always a balance to strike considering complexity and performance. If this isn't going to be perfect, it should at least be simple. We can reconsider those commits in a separate PR if desired.
I also made adjustments so that the override bails, resorting to the superclass fit method if anything seems to be awry (nans, infs, unexpectedly large gap between distribution minimum and location). I've only ever seen this occur when the MLE of loc is the minimum of the data, but I can't rule out the possibility that this occurs for some other reason. So for now, it seems better to be safe than to give an incorrect result. Again, we can consider changing this back in a separate PR if desired.
A backup branch from before tonight's changes is here.
I'll run some more computer experiments tomorrow. If things look good, I'll go ahead and merge.

All good! Anything off with the last commits, or just complexity?
Happy for it to be merged as is; I'm quite busy at the moment, but I can look at it again in the future if needed.

@mdhaber the linter is picking up the benchmark file because it has been touch. The linter used to work on diff only and we moved away from that because it's unreliable. This is one of the reason we were stuck with an old version of flake8 as they also moved away from doing this. i.e. you can always decide to not fix lines you are not touching in a PR. CI would just be red for this PR.

@Tartopohm No, I didn't find anything wrong with the last commits. It just got quite complex.
I think the complexity is probably warranted in the general case since there can be more than one root of the likelihood equation. However, this only seems to occur when the scale and/or shape are fixed at very poor values. Otherwise, the maximum likelihood seems to occur either at the root of the likelihood equation or at the minimum of the data. So, faced with the two alternatives - a conceptually complex solver that is nearly but still not perfectly robust and a simpler solver that is nearly but not perfectly robust - I have to opt for the latter.
Yes, let's go ahead and merge this and consider making other improvements later. It is already a huge improvement.


Unable to run spring-security-oauth

Hi,
I am new to spring-boot, please answer my below question. Million thanks in advance..
In the Read-me file I see below details:
Make sure to run the project on port 8081
Run 4 sub-modules simultaneously
spring-security-oauth-server
spring-security-oauth-resource
spring-security-oauth-ui-implicit
spring-security-oauth-ui-password
But, how do I run all the above modules simultaneously. If I run individual module, only the first oauth-server would run, then it starts complaing about port already been used. So, I am confused how to run all the modules at one shot. Your help is appreciated.

I was able to do it by configuring with different ports. Thanks, and hence closing ticket.

Sounds good - glad it worked out. Cheers,
Eugen.


Revert "Update golang Docker tag to v1.22.0 (main)"

Reverts Dynatrace/dynatrace-operator#2688

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (ac02bfa) 67.72% compared to head (befb87b) 67.72%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2696   +/-   ##
=======================================
  Coverage   67.72%   67.72%
=======================================
  Files         250      250
  Lines       13637    13637
=======================================
  Hits         9235     9235
  Misses       3593     3593
  Partials      809      809

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


Invalid "ballerina openapi gen-service" Code Generated

For example, it generates code similar to below:
    resource function getPetById (http:Caller outboundEp, http:Request _getPetByIdReq, string petId) returns error? {
        http:Response _getPetByIdRes = getPetById(_getPetByIdReq, petId);
        _ = outboundEp->respond(_getPetByIdRes);
    }

The return value from "respond" action is ignored here, where it can't be ignored now, since it is an error value, thus resulting in a compile error.

Also, we need automated tests for this.

The PR has been sent to fix the issue to the ballerina master branch, and I have attached a patch for version 0.991.0 to fix this issue. Please extract and copy the openapi-to-ballerina-generator-0.991.0.jar to the following path replacing the current jar.
$BALLERINA_HOME\bre\lib
openapi-to-ballerina-generator-0.991.0.jar.zip

Thanks!.


[DOC] update gh-pages with docs build from dev branch

PR Description
Please describe the changes proposed in the pull request:

Not sure if this is the right approach, but I noticed that the docs haven't been updated recenlty. I think this is due to the fact that we are using a gh-pages branch and haven't merged updates to it recently.
I executed a make docs from the dev branch and uploaded the html files to the gh-pages branch within this PR.

See conversation with @samukweku in #865
PR Checklist
Please ensure that you have done the following:

[X] PR in from a fork off your branch. Do not PR from <your_username>:dev, but rather from <your_username>:<feature-branch_name>.

[X] If you're not on the contributors list, add yourself to AUTHORS.rst.

[X] Add a line to CHANGELOG.md under the latest version header (i.e. the one that is "on deck") describing the contribution.

Do use some discretion here; if there are multiple PRs that are related, keep them in a single line.

Automatic checks
There will be automatic checks run on the PR. These include:

Building a preview of the docs on Netlify
Automatically linting the code
Making sure the code is documented
Making sure that all tests are passed
Making sure that code coverage doesn't go down.

Relevant Reviewers

Please tag maintainers to review.

@ericmjl

@loganthomas thanks for doing this! We'll merge this one in to get a quick fix on the latest docs. However, I think we should also create a GitHub actions workflow for building docs. I'll raise an issue to describe what needs to be done.


Async rendering part 2

Description
New NAPARI_ASYNC env var to toggle on async loading via a thread pool.

[x] New feature (non-breaking change which adds functionality)

References

Async Part 1: #1565
Full async PR: #1510

How has this been tested?

[x] Manual testing

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

This is ready to review. This is a smaller step that outlined in #1510 but I think it's needed. I left out the Cache and all the statistics which seemed like they could go in as separate steps.

Still ready for review. I just did some clean and tried to anticipate some objections.

tried to anticipate some objections.

Nobody expects the Spanish Inquisition!!!
(Couldn't resist, I mean, it's friggin Python code...)

The visibility (render to black) gets added in async-3 which you can see here until we make a Napari PR for it:


Remove olivere elastic client from OTEL

Signed-off-by: Pavol Loffay<EMAIL_ADDRESS>This should completely remove dependency on olivere client from OTEL. It's not needed as we use only the elastic.co client.

cc) @joe-elliott :)


STYLE: Reformat main function files

this will reformat all other files under databricks/* dir

emm, seems it's a bug in black... the errors look like the same... just did some search, and i think need to ignore some error codes in flake8,,, I need think a bit more...


Fix bug in reading items from json

Edited file path names to reflect changes in file paths

Codecov Report

Merging #72 (89a2628) into master (193ff49) will not change coverage.
The diff coverage is 57.14%.

 Learn more


Missing RequestId & HostId From mocked cognitoidp service API response

This was using botocore at  1.34.7 and moto at  4.2.9
What Actually Happened
When I use moto to mock cognitoidp, I expected to see RequestId & HostId in the ResponseMetadata it's not the case actually.

Hi @filol, marking it as an enhancement to add these fields.
Do you have any documentation on the HostId-field? I couldn't find any info on the meaning/value of it.

Hi @bblommers, thanks !
Didn't find any information inside the boto3 documentation. Only a mention here : https://boto3.amazonaws.com/v1/documentation/api/latest/guide/error-handling.html#parsing-error-responses-and-catching-exceptions-from-aws-services
But i find this in the JAVA SDK documentation for S3  : "Amazon S3 also includes a host ID that can be provided to Amazon Web Services support when debugging an issue with Amazon S3."
https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/S3ResponseMetadata.html

@filol
I just tested a range of CognitoIDP operations against AWS (admin_create_user, list_users, list_resource_servers, and a few others), and they all contain the RequestId-header. I'll probably refactor Moto a bit to return this field everywhere, not just for CognitoIDP, as I believe it is returned for all services.
However: none of these operations returned the HostId-header. Was there a specific operation where you saw that returned?

The RequestId will be part of every request from Moto v5.
We've released an alpha version yesterday if you want to try it out: moto==5.0.0alpha2
See the release announcement here to see the breaking changes:
https://github.com/getmoto/moto/issues/7198

Moto v5 is now released: https://pypi.org/project/moto/5.0.0/


Way to increase GPU usage?

Hey everyone,
I've been able to run bark on text and get back great results, but it only seems to use 8 gb of VRAM on my GTX 3090
Is there anyway to increase that to improve performance?

hard to improve latency without changing the architecture, but throughput could be increased by implementing batch predictions

closing in favor of https://github.com/suno-ai/bark/issues/279


openssh 7.5p1

It seems like patch for launchd is shipping upstream.

I had removed libressl due to audit complain.
$ brew audit homebrew/dupes/openssh --online
homebrew/dupes/openssh:
  * Formulae should not depend on both OpenSSL and LibreSSL (even optionally).
Error: 1 problem in 1 formula

test failure looks to be intermittent

Thanks for your pull request! :tada: Homebrew thrives because of contributions like this one.

@tdsmith you are welcome!


Support for APISpec

Hello!
Despite the effort on sanic-openapi, it would be great to have a plugin for apispec.
One exists for Flask but I couldn't easily port the Flask extension for sanic, it's still quite different internally.
https://github.com/marshmallow-code/apispec
https://github.com/marshmallow-code/apispec/blob/dev/apispec/ext/flask.py
WDYT?
Thanks!
Cheers,
Raphaël Dehousse

I'm actually going to close this. A plugin can be created if desired, but with the reorganization and ownership borders that were set up in 2018, I don't think this fits in the core sanic project.


Terraformer import crashes while importing gcp resourses.

I am trying to import gcp resources using terraformer import but the plugin crashes while doing so and I do receive a blank state file in the end.
terraform {
required_providers {
google = {
version = "~> 4.78.0"
}
}
}
Crash Report:
2023-08-16T14:07:23.703+0530 [TRACE] plugin.terraform-provider-google_v4.78.0_x5: Sending request downstream: @module=sdk.proto tf_proto_version=5.3 tf_provider_addr=registry.terraform.io/hashicorp/google tf_req_id=be675dfe-90f2-606b-f9a3-aca736bbc328 @caller=github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/internal/tf5serverlogging/downstream_request.go:17 tf_rpc=ReadResource tf_resource_type=google_container_node_pool timestamp="2023-08-16T14:07:23.702+0530"
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: panic: interface conversion: interface {} is nil, not *transport.Config
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5:
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: goroutine 197 [running]:
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: github.com/hashicorp/terraform-provider-google/google/services/container.resourceContainerNodePoolExists(0x4a8f3b8?, {0x0?, 0x0?})
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	github.com/hashicorp/terraform-provider-google/google/services/container/resource_container_node_pool.go:756 +0x58d
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).RefreshWithoutUpgrade(0xc000dc3a40, {0x4a8f3b8, 0xc001024810}, 0xc000cc0340, {0x0, 0x0})
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	github.com/hashicorp/terraform-plugin-sdk/v2@v2.24.0/helper/schema/resource.go:992 +0x397
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0xc000e7d368, {0x4a8f3b8?, 0xc0010246f0?}, 0xc00167b6c0)
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	github.com/hashicorp/terraform-plugin-sdk/v2@v2.24.0/helper/schema/grpc_provider.go:613 +0x4a5
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: github.com/hashicorp/terraform-plugin-mux/tf5muxserver.muxServer.ReadResource({0xc000e349c0, 0xc000e34a20, {0xc0010f01c0, 0x2, 0x2}, {0x0, 0x0, 0x0}, {0x0, 0x0, ...}, ...}, ...)
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	github.com/hashicorp/terraform-plugin-mux@v0.8.0/tf5muxserver/mux_server_ReadResource.go:26 +0x102
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadResource(0xc00021f860, {0x4a8f3b8?, 0xc000ffb830?}, 0xc00127a2a0)
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/tf5server/server.go:748 +0x4b1
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadResource_Handler({0x430c980?, 0xc00021f860}, {0x4a8f3b8, 0xc000ffb830}, 0xc00138a000, 0x0)
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:349 +0x170
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: google.golang.org/grpc.(*Server).processUnaryRPC(0xc000f70b40, {0x4a983c0, 0xc001216680}, 0xc000c846c0, 0xc0014d0000, 0x621a5b0, 0x0)
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	google.golang.org/grpc@v1.56.2/server.go:1337 +0xdf0
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: google.golang.org/grpc.(*Server).handleStream(0xc000f70b40, {0x4a983c0, 0xc001216680}, 0xc000c846c0, 0x0)
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	google.golang.org/grpc@v1.56.2/server.go:1714 +0xa2f
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: google.golang.org/grpc.(*Server).serveStreams.func1.1()
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	google.golang.org/grpc@v1.56.2/server.go:959 +0x98
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: created by google.golang.org/grpc.(*Server).serveStreams.func1
2023-08-16T14:07:23.706+0530 [DEBUG] plugin.terraform-provider-google_v4.78.0_x5: 	google.golang.org/grpc@v1.56.2/server.go:957 +0x18c
2023-08-16T14:07:23.709+0530 [ERROR] plugin: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/google/4.78.0/darwin_amd64/terraform-provider-google_v4.78.0_x5 pid=27587 error="exit status 2"

Also having issues with GCP provider
2023-08-22T16:07:38.634-0400 [ERROR] plugin.terraform-provider-google_v4.78.0_x5: Response contains error diagnostic: @module=sdk.proto tf_provider_addr=registry.terraform.io/hashicorp/google tf_req_id=e3513184-a0ab-4dd2-483a-f11c1ba7ab1d diagnostic_attribute=""
diagnostic_detail=
| An unexpected error was encountered trying to build a value. This is always an error in the provider. Please report the following to the provider developer:
|
| Received null value, however the target type cannot handle null values. Use the corresponding types package type, a pointer type or a custom type that handles null values.
|
| Path:
| Target Type: fwmodels.ProviderModel
| Suggested types Type: basetypes.ObjectValue
| Suggested Pointer Type: *fwmodels.ProviderModel
diagnostic_severity=ERROR diagnostic_summary="Value Conversion Error" tf_proto_version=5.3 tf_rpc=Configure @caller=github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/internal/diag/diagnostics.go:55 timestamp=2023-08-22T16:07:38.634-0400
2023-08-22T16:07:50.763-0400 [ERROR] plugin: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/google/4.78.0/darwin_arm64/terraform-provider-google_v4.78.0_x5 pid=52595 error="exit status 2"
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 rpc error: code = Unavailable desc = error reading from server: EOF
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:50 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry
2023/08/22 16:07:51 rpc error: code = Canceled desc = context canceled
2023/08/22 16:07:51 WARN: Fail read resource from provider, wait 300ms before retry

Looks like terraformer does not have support for latest provider releases, I was able to make the import work with version "4.59.0".

Would not close this as this is still a problem and switching to version 4.59.0 is just a workaround


Update contract

Can you update the contract for  for ERC721A or some low gas minting?

lakai, I can do this on my own fork for you. I'm not sure that it will be merged into the main branch but I'll do a pull and see what jeongmincho thinks. In the meantime, here is the link to my fork https://github.com/Shiva-Tzu/test-dapp.
I'll update it for ERC-721A by the end of the day.


Get tests green again

Great improvements @tas50. Any reason why we remove 16.10?

That was the part that failed previously

@tas50 this is related to some docker issues we have in combination with travis. Those are timing errors and can be happen to all operating systems. We try to find the root cause.


Account daily snapshot

Is it even possible that we can have a daily account snapshot? I want eventually let users to see the daily change of the account. This affect to those accounts which has delegation as the reward (and commission for validators) keep changing on every block. We can't just rely on the transfer transactions to track the changes.

I think this can be done easily. How often do you think will be a fair refresh rate? 15 seconds or less often?

As discussed during the call of today, I will implement this by:

Parsing MsgSend and MsgMultiSend messages in order to get new accounts as they are created.
Querying the LCD daily to get the balances of the accounts themselves.


Docs: fix broken link to readme

Just fixing the link in the documentation that is no longer working.
Thanks!

thanks @mumoshu , I don't have write so ill leave this up to you. Thanks again!

@cogito-cmurphy I was just waiting for the CI to pass. Thanks for the reminder 😄


import cv2 fails with CUDA 8.0

So, I updated tensorflow to r0.11, which required upgrading to CUDA 8.0 to be able to use the prebuilt Tensorflow binary for Ubuntu/Linux 64-bit, GPU enabled, Python 2.7.
Tensorflow runs correctly but
python ./suiron/train.py
import cv2
fails with
Traceback (most recent call last):   File "./train.py", line 5, in <module>     from suiron.utils.datasets import get_servo_dataset   File "/data/home/me/my_tensorflow/suiron/suiron/suiron/utils/datasets.py", line 9, in <module>     from suiron.utils.img_serializer import deserialize_image   File "/data/home/mer/my_tensorflow/suiron/suiron/suiron/utils/img_serializer.py", line 5, in <module>     import cv2 ImportError: libcudart.so.7.5: cannot open shared object file: No such file or directory
I spent a lot of time looking for a version of cv built against CUDA 8 but did not find anything.
Any thoughts on the best way to resolve?

Unfortunately I have no affiliates with CUDA/OpenCV, the only thing I would recommend is to install an older version of CUDA

There are compatibility issues with opencv and CUDA 8.0. I found a solution in opencv repo

For everyone else having this problem, here is the solution from thrust issue#800 proposed by @bramton
clone: https://github.com/thrust/thrust.git
and replace the thrust folder from CUDA 8 toolkit with the one from thrust 1.8.3 branch you cloned.
Nvidia told User @bramton They already fixed the issue and we will get the official fix with the next version of cuda 8 toolkit
I will comment again when I checked if everything works.

Try if it works :smile:

(sudo) pip install opencv-python did the trick for me

thinks, it just worked for me, too


Feature-extraction Task Page

This is the tracker for completion of task page for feature-extraction task. The page is here: https://huggingface.co/tasks/feature-extraction You can contribute parts of a task or the whole task! (There's no single assignee to a task, these are wikipedia-like pages)
You can refer to https://github.com/huggingface/hub-docs/issues/369 if you want to contribute! 🤗
List of items to contribute:

[x] Task description
[x] Task Schema
[ ] Subtasks (if there is any)
[x] Most used dataset for the task
[x] Most used model for the task
[ ] Metrics that are used to evaluate the task
[x] Libraries used for the task
[x] Use cases
[x]  Small snippet for inference that demonstrates the task
[x] Model for the Widget

@merveenoyan Do you see any more improvements that can be made to this task? I can help with the rest of it so as to close this issue. Metric section seems to be tricky because it depends on the objective of the task. I would suggest to add a general comment under Metric such as "Evaluation of feature-extraction depends on the objective of the task that the model is used to solve. This objective would vary with the modality, ie. whether it is an NLP, computer vision or audio task."


Guide users at ETModel for ETMoses

On the front page of ETMoses there are three images that explain how to manouvre through ETModel in order to create a scaled scenario.
However to switch between tabs from ETMoses and ETmodel is asking a little too much from the 21 century Internet user.
So I'd like to suggest to use http://usablica.github.io/intro.js/
To create a small guide for ETMoses on ETModel.
Thought? @ChaelKruip @antw @dennisschoenmakers

I like the idea but I have two reservations:

These things always take a lot of time to do well
The typical ETMoses user is not someone who stumbles on the website by accident and goes exploring on his own. Rather, we want to advertise our workshops I think (see https://github.com/quintel/etmoses/issues/495). ETMoses is too much of an expert tool to let someone loose there without proper guidance. So, having a slick introduction might actually give the wrong impression: "Hey, this is fun! Let's go explore!"

Sorry to be a negative Nancy here :disappointed:

I agree with @ChaelKruip. BTW: We used intro.js on etflex! It is awesome!

I agree also. I'm going to close this issue. :+1:


Convert lowering tests to be functional tests

Convert apply tests to be functional

Fix a bug in handling row/column apply_operator

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.09%) to 85.954%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
4565

Relevant Lines:
5311

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.09%) to 85.962%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
4568

Relevant Lines:
5314

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.09%) to 85.962%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
4568

Relevant Lines:
5314

💛  - Coveralls


lv2: reduce closure

Motivation for this change
gtk2 is optional
Before:
$ nix path-info -Sh ./result
/nix/store/ysdp0p56qpnx9kd6lyyx6rgbwnz97wq6-lv2-1.18.2	 327.1M

After:
$ nix path-info -Sh ./result
/nix/store/q1rcs1dkj4zrrd0nd3qk3dnn5akh1b9g-lv2-1.18.2	 141.5M

related: https://github.com/NixOS/nixpkgs/issues/159612
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

honestly, I lost all will to continue this, this package is just a nebulous web of symlinks and hacks.

Looking at the code, it should work if we pass the correct includedir flag to waf:
https://github.com/lv2/lv2/blob/6cefc7df1a6158c79d23029df183c09b10b88cad/wscript#L347-L355

Yeah, the relativization is ugly but seems to work:
--- a/pkgs/development/libraries/audio/lv2/default.nix
+++ b/pkgs/development/libraries/audio/lv2/default.nix
@@ -18,7 +18,11 @@ stdenv.mkDerivation rec {
   nativeBuildInputs = [ pkg-config wafHook ];
   buildInputs = [ libsndfile python3 ];

-  wafConfigureFlags = lib.optionals stdenv.isDarwin [ "--lv2dir=${placeholder "out"}/lib/lv2" ];
+  wafConfigureFlags = [
+    "--includedir=${placeholder "dev"}/include"
+  ] ++ lib.optionals stdenv.isDarwin [
+    "--lv2dir=${placeholder "out"}/lib/lv2"
+  ];

   passthru.tests = {
     inherit pipewire;

Result of nixpkgs-review pr 159875 run on aarch64-darwin 1

3 packages marked as broken and skipped:

audacity
rkrlv2
suil-qt5

4 packages failed to build:

audacity-gtk2 (audacity-gtk3)
gxmatcheq-lv2
gxplugins-lv2
suil (suil-qt4)

4 packages built:

lilv
lv2
lvtk
sratom


Cron isse: Want to run every 32 minutes, but runs at top of the hour + top of the hour and 31 minutes.

Discussed in https://github.com/alexjustesen/speedtest-tracker/discussions/1359

Originally posted by fischerphilipp April  8, 2024
Hi Alex,
thanks a lot for creating and maintaining this tool, really helpful for me.
When configuring and adjusting the speedtests I discovered the following:
I initially had the speedtests run at the top of the hour, like 8:00, 9:00 etc. However apparently some speedtest servers are at maximum capacity at that time because I discovered that when there are breaches to the set thresholds, this almost always occurs at the top of the hour. If I move the tests to a little later, then the results are way more consistent and reaching my ISP top speed.
My current Cron setting is */32 * * * *
However I have two issues with the tests:

Although I set it to run at /32 I always also get a test at the the top of the hour. No idea where this is coming from (see screenshot).
The cron generator you linked says that /32 should let the test run every 32 minutes (which is what I want), instead I see the tests running always at 32 minutes past the hour. Because I want ~two tests within one hour I would prefer it to run as the generator says. Is that an issue with the linked cron generator or with Speedtest tracker?

Thanks in advance and best regards,
Philipp

*/32 searches for the 32th minute in the hour starting at the hour ( so in total 2 times ). I think there is no way to do what you want using crontab ( maybe with systemd timers )
https://en.wikipedia.org/wiki/Cron ( slash section ).

Duplicate of #1359, also take a look at https://github.com/alexjustesen/speedtest-tracker/issues/552#issuecomment-2028532010 and this will help you get started with offset schedules.

Thanks so much. @wdog After you responded and before your added example I also tried this which I could now also verify to work:
28,58 * * * *
However I’m not sure what the difference between your suggestion and mine is. The outcome seems to be similar.


[Feature-Request] Center window

It would be really nice if the window can be centered and the margins get applied afterwards.
Like this the position stays the same on different monitors

What's stopping you? You'd set all anchors to false and the window will always be centered.

Ah nice
Adding this to the docs would be good though


Use valid category value in library.properties

The previous category value caused the warning on every compilation:
WARNING: Category 'DeviceControl' in library XYZrobotServo is not valid. Setting to 'Uncategorized'

Reference: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification#libraryproperties-file-format

Thank you!  I forgot to put the space in Device Control.

I merged this pull request, @per1234, and I moved the 1.0.0 tag to point to the merged version.  Please let me know if there is anything else I need to do to get the library listed in the library manager.  Maybe I need to make a new tag?

This PR was not required for Library Manager inclusion. It was just an issue I noticed while I was checking that it was compliant with the Library Manager requirements. cmaglie goes through all the outstanding requests on the arduino/Arduino issue tracker once or twice a week, adds them to the index, and then closes the issue report when that's done. The library will be available to installation via Library Manager shortly after that. Sometimes he encounters a problem such as a name conflict and that delays inclusion until the next cycle but I don't see any issues with your repository.


parser: implement Restore for DefaultExpr

Implement Restore and unit test for DefaultExpr.
Issue: https://github.com/pingcap/tidb/issues/8532

thanks for your contribution!

LGTM


Suggestion: Allow declaring class members within a constructor

Problem Statement: In TypeScript 1.1, there are two basic ways to initialize complex properties with strong typing via a parameterized class constructor.  Both have disadvantages.  I will illustrate this with a simple example that uses Knockout, but this issue applies to any other JavaScript library that implements complex objects via initializer functions.
"Method 1" is to instantiate the properties outside of the constructor using a throw-away value, and then to set the desired value inside the constructor (see RightTriangle1 below).  This method has the advantage of being rather simple to program/maintain because TypeScript automatically infers the property's type.  However, this has the potential to cause ripple effects or performance issues at runtime because the code to instantiate each property is run at least twice.
class RightTriangle1 {
    public height = ko.observable(0);
    public width = ko.observable(0);
    public hypotenuse = ko.computed(() => {
        console.log("hypotenuse 1 calculated");
        return Math.sqrt(this.height() * this.height() + this.width() * this.width());
    });
    constructor(height: number, width: number) {
        this.height(height);
        this.width(width);
    }
}
var rt1 = new RightTriangle1(3, 4);
console.log("hypotenuse 1: " + rt1.hypotenuse());  // 5

Knockout happens to have an advanced feature to defer execution of a computed, but that's beside the point.  Other libraries may not support such a feature and it's just one more thing for the developer to keep track of.
"Method 2" is to declare the properties with an explicit type outside of the constructor, and then to instantiate them inside the constructor (see RightTriangle2 below).  This method has the advantage of eliminating the runtime double-instantiation issue, but it also eliminates the convenience of having TypeScript infer the types.
Method 2 has the drawback of extra work if a type is ever changed, but much worse than that, it places the burden on the developer to figure out what the type of each member should be.  For trivial members (string, number, etc.) or libraries you've written yourself, this is merely busy-work, however for complex types used by a JavaScript library it is sometimes difficult to determine unless the developer is quite familiar with the library's definition.  Lastly, this is just the sort of syntax that would make a JavaScript developer who was new to TypeScript think, "This is exactly what I was afraid of!  Look at all that extra code I'm forced to write that just gets thrown away in the end!"
class RightTriangle2 {
    public height : KnockoutObservable<number>;
    public width: KnockoutObservable<number>;
    public hypotenuse: KnockoutComputed<number>;
    constructor(height: number, width: number) {
        this.height = ko.observable(height);
        this.width = ko.observable(width);
        this.hypotenuse = ko.computed(() => {
            console.log("hypotenuse 2 calculated");
            return Math.sqrt(this.height() * this.height() + this.width() * this.width());
        });
    }
}
var rt2 = new RightTriangle2(6, 8);
console.log("hypotenuse 2: " + rt2.hypotenuse()); // 10

In summary of the problem, "Method 1" begs performance or logic problems, and "Method 2" is too wordy.
Proposal: "Method 3" Fairly early on in the public life of TypeScript, the team added the ability to indicate retained fields by placing visibility modifiers on constructor parameters.  This feature is awesome, but it only helps with trivial properties.  I would like to propose adding a new feature to TypeScript to allow this idiom within the body of a constructor as well.  This would permit compiling the code in the RightTriangle3 example below.  Note the public modifiers on height, width, and hypotenuse.
class RightTriangle3 {
    constructor(height: number, width: number) {
        public this.height = ko.observable(height);
        public this.width = ko.observable(width);
        public this.hypotenuse = ko.computed(() => {
            console.log("hypotenuse 3 calculated");
            return Math.sqrt(this.height() * this.height() + this.width() * this.width());
        });
    }
}
var rt3 = new RightTriangle3(9, 12);
console.log("hypotenuse 3: " + rt3.hypotenuse()); // 15

With this proposal:

There are no breaking changes; code that compiled in TypeScript 1.0 works without any modification in this proposed future version.
The RightTriangle3 class would have the identical JavaScript emit as RightTriangle2.
The RightTriangle3 TypeScript compile-time type interface would also be identical to RightTriangle2.
The developer is not required to separate the declaration of the property from its instantiation just to get strong typing when using a parameterized constructor.
The developer is not required to update the type of a property if the class interface ever changes - they can just update the initializer code.
The TypeScript code in RightTriangle3 is the most succinct of the three.  RightTriangle1 is 12 lines long (besides being "wrong"), RightTriangle2 is 13, RightTriangle3 is just 10.  Additional observable or computed properties in RightTriangle1 and RightTriangle2 add two lines of code each; with RightTriangle3 only one line of code is added each.
The TypeScript code in RightTriangle3 is still very close to the emitted JavaScript (and therefore unlikely to create future incompatibility issues).
The new syntax is also very similar to the existing TypeScript parameter property declaration shorthand.
The pattern demonstrated in RightTriangle3 enables a simple cut+paste migration path to implement a constructor (the developer would just have to paste in "this." on each line).  With TypeScript 1.0, implementing a constructor is a lot more work.  For example if converting RightTriangle1 to RightTriangle2, the developer must determine and explicitly type out each member declaration with its type before migrating the instantiation code.

Specifics:
Inside a class constructor function only, a visibility modifier (public, private, or protected) may modify a property on the instance variable this.  If so, the statement is considered a declaration of that property on the class and the type is inferred according to the normal TypeScript rules.  The following example class A is legal under this proposal:
class A {
    constructor(property3: boolean) {
        public this.property1;  //any
        private this.property2 : string;  //string
        protected this.property3 = property3;  //boolean
    }
}

The above code is identical to this TypeScript 1.1 code:
class A {
    public property1;
    private property2: string;
    constructor(protected property3: boolean) {
    }
}

Use of a visibility modifier is otherwise not permitted within the body of a constructor.  For example, class B below would be a syntax error because property1 is not qualified as a property of this.  This condition should cause a new emit-preventing type error along the lines of Visibility modifiers within a constructor may only modify properties of "this".
class B {
    constructor(val: string) {
        public property1 = val;
    }
}

Use of a visibility modifier is similarly not permitted within a normal function member.  For example, class C below would be a syntax error, because in this proposal class properties can only be declared in this manner within the constructor.  This condition should cause a new emit-preventing type error along the lines of Visibility modifier declarations are only legal within the parameter list and body of a class constructor.
class C {
    doSomething() {
        public this.property1: string = "test";
    }
}

Use of the static modifier is similarly not permitted within a normal function member or the constructor.  For example, class D below would be a syntax error because under this proposal, static class properties can only be declared using the existing TypeScript 1.0 syntax (within the body of the class).  This condition should cause a new emit-preventing type error along the lines of Shorthand visibility declarations may not be used on static properties.
class D {
    constructor(val: boolean) {
        public static property1: string = "test";
    }
}

What happens if a declaration occurs inside of a branch?
For the purpose of the TypeScript type system, any branching, looping, etc. inside the constructor should be ignored.  Furthermore, the JavaScript should be emitted exactly as if the public, private, or protected modifier were not present.  Under this proposal, TypeScript should consider class E below to be valid.  At compile time, TypeScript will consider class E to have a property called description of type string (even though at runtime the initialization code would never execute).
class E {
    constructor() {
        if (1 === 0) {
            public this.description = "";
        }
    }
}

What happens if there is a duplicate declaration and the types match?
This should not prevent the emit.  The second and successive duplicates should raise error TS2300: Duplicate identifier 'PROPERTY_NAME_HERE'. just like how existing duplicate declarations work.
What happens if there is a duplicate, but one is a subtype of the other, or even if the types do not match?
The same type resolution logic should be applied if the duplicates occurred as simple type declarations in the class body (outside the constructor).  The second and successive duplicates should raise error TS2300: Duplicate identifier 'PROPERTY_NAME_HERE'..  This should not prevent the emit.  This may incidentally result in downstream error TS2339: Property 'PROPERTY_NAME_HERE' does not exist on type 'THE_PROPERTY_TYPE'. wherever sub-properties of the property are used (just like in TypeScript 1.0).
In all other scenarios (such as with inheritance chains, subtypes, supertypes, assignability relationships, and generics), the same behavior as a class written like RightTriangle2 in TypeScript 1.0 should be used when evaluating what should happen with a class written like RightTriangle3 using the new shorthand syntax.
I believe that this syntax fits in nicely with both the goals and non-goals of TypeScript and I hope that you'll consider it or something similar.  Thanks for reading this.

@danquirk, were you leaning towards reopening this issue?

@danielrosenwasser not really. This doesn't solve the problem of 'my ES6 code is an error in TypeScript'. It still requires new syntax at which point I don't think it's adding enough value over the current syntax options once you've decided it's worth the effort to augment your code to satisfy a TypeScript rule. If we were actually solving the ES6 problem that'd be interesting (ex inferring from this.foo assignments in the constructor to implicitly infer the shape of your type) or else people might just lean towards the future ES class syntax like we propose now https://gist.github.com/jeffmo/054df782c05639da2adb

I still appreciate the consideration, Dan.  I'm definitely interested to hear how the constructor signature short-hand snuck into the language if this isn't adding enough value for you.  Do you regret adding that?

FWIW class parameter properties have existed in TypeScript basically forever (i.e. before I joined the team which was well before we went public).
Given the historical context of how much the ES6 class design was moving around, I think it was the right decision. The proposed syntax is very similar (identical?) to the 'harmony' class proposal that was popular at the time (http://wiki.ecmascript.org/doku.php?id=harmony:classes#proposal_history). Had TypeScript implemented some sort of constructor-body semantics and then had ES6 land on the harmony proposal with slightly different semantics, that would have been a disaster. Constraining those keywords to parameter positions was a good trade-off for avoiding conflicting with a future ES6 standard while still adding a ton of convenience to the language.

This is really interesting.  I would love to hear more details about how TypeScript really came about some day and the early days of the project.  Sometime when you folks aren't busy (lol), that would be a pretty cool Channel 9 video or blog post (or .NET Rocks podcast or something).
In the meantime, I suppose that I have to admit that this proposal is entirely fixable via IDE refactoring tools, so perhaps I can switch to begging for "implement this" to be added as a Roslyn refactoring to undeclared properties on this in a constructor.  I'll have to look into that once I get VS 2015 going and work with Bas to get it into atom-typescript.

Hey, I'm having a compiler error where it tells me property x does not exist on type {}.
export class Auth {
    constructor(private api: Api, private session = {}) {
        //
    }

    login(credentials: any) {
        return this.api.post('auth', credentials)
            .do((response) => {
                this.session.user = response.user;
                this.session.token = response.token;
            });
    }
}

The compiler keeps giving me these errors:
ERROR in ./angular/app/shared/auth/auth.service.ts
(23,46): error TS2339: Property 'user' does not exist on type '{}'.

ERROR in ./angular/app/shared/auth/auth.service.ts
(24,47): error TS2339: Property 'token' does not exist on type '{}'.

What's the issue here?

@jaesung2061 this error is caused by the type of response. i do not know what is the definition of do to be able to tell you why you are getting this error. in general SO is a good place for such questions.

@mhegazy You were right. I added an any type anotation to response and it fixed the issue. I was thinking it was the session object and never thought about the response object. Thanks.

@RyanCavanaugh @danquirk this was labeled 'Too Complex' and declined in 2014. But this is still an issue and keeps popping up: https://github.com/Microsoft/TypeScript/issues/6373 https://github.com/Microsoft/TypeScript/issues/2606 https://github.com/Microsoft/TypeScript/issues/2393 https://github.com/Microsoft/TypeScript/issues/12613
Something very close to this looks like it went into 'Salsa': https://github.com/Microsoft/TypeScript/issues/4955
@danquirk I don't agree that this is just about brevity - it's about how painful it is upgrading an es6 project to TypeScript. Anecdotally, I've found this to be the cause of more than half of initial errors when upgrading projects. @nycdotnet still have any interest in this?
Any chance this making it into the language proper could get looked at again?

Wow 2 1/2 years ago - amazing how time flies.
I still feel that taking maximum advantage of type inference is the correct way to use TypeScript.  I still feel that doing work inside a method signature is icky (as in RightTriangle4, above).  Since the time I wrote this, ES6 has become mainstream - not in small part due to the efforts of the TypeScript team.  As far as I am aware, the syntax I proposed does not collide with ES6 or any likely future official ECMAScript syntax.  I agree with you, @mmkal, that having to provide type definitions is a tedious and non-value-added task that hits you hard in the face on day 1 of using TypeScript (assuming not using --allowJs).
So in the end, I feel that this proposal is still sound and would be a welcome addition to the language, HOWEVER - it is also something that could be implemented by tooling in an editor (which would produce RightTriangle2).
This proposal was from the days before VS Code and when atom-typescript was ~ v0.5, so writing that tooling would have also been the job of the TypeScript team then.  Now, we're approaching the time when it's plausible a community member could do it for either of those two editors, but it remains that it does not exist.  It would be awesome for it to exist - either as part of the language or as a tool.

I still feel that taking maximum advantage of type inference is the correct way to use TypeScript.

I strongly agree with this.
Every day I see code like
class MyComponent {
  names: Array<string> = ['hello', 'world']; // redundant
}

or worse
class MyComponent {
  names: any = ['hello', 'world']; // depressing.
}

It is amazing how the poorly coded official tutorials written for a popular framework can have such a negative impact on the use of a language.
However, looking over your original proposal, and I might be missing something here, it seems that there would be no new syntax required to implement it. It would simply imply tracking assignments to this altering the shape of the class along the way.
What I mean is that this
class RightTriangle3 {
    constructor(height: number, width: number) {
        public this.height = ko.observable(height);
        public this.width = ko.observable(width);
        public this.hypotenuse = ko.computed(() => {
            console.log("hypotenuse 3 calculated");
            return Math.sqrt(this.height() * this.height() + this.width() * this.width());
        });
    }
}
var rt3 = new RightTriangle3(9, 12);
console.log("hypotenuse 3: " + rt3.hypotenuse()); // 15

could just as well be this
class RightTriangle3 {
    constructor(height: number, width: number) {
        this.height = ko.observable(height);
        this.width = ko.observable(width);
        this.hypotenuse = ko.computed(() => {
            console.log("hypotenuse 3 calculated");
            return Math.sqrt(this.height() * this.height() + this.width() * this.width());
        });
    }
}
var rt3 = new RightTriangle3(9, 12);
console.log("hypotenuse 3: " + rt3.hypotenuse()); // 15

The effect on the JS code would be identical, in fact that is a valid JavaScript constructor body.
The Salsa language service exhibits this behavior.

I get why they don't allow that by default.  Allowing implicit declarations - even just in constructors - opens the door to classes of bugs that TypeScript is intended to prevent.  This proposed syntax was a way to make such declarations explicit.  Perhaps an --allowImplicitMemberDeclarations switch (to mimic Salsa) is a better solution, however that would continue to add to the present constellation of switches, which is another day 1 problem (can't blame TS team for this one, though).

I understand the desire to be explicit but wanted to point out that it doesn't require new syntax. New syntax in value position is a showstopper.

fair enough.

I think this deserves another go-around. We infer from this assignments in JS and considered doing this for TS classes with zero local property declarations. But without a global quickfix, I think we're potentially making class-based ES6 -> TS migration too difficult (ironically)

Thought about it again but outcome is basically the same ( https://github.com/Microsoft/TypeScript/issues/766#issuecomment-58293623 ).
Particularly, ES-Next public field initializers are coming down the pipe, so constructor-initialized properties should be getting less common at some point in the future.

Thank you for reconsidering it.


'merge' documentation

In the documentation, it is unclear that the 'merge' feature concatenates embeddings across the 'names' axis as opposed to the vector axis.
It would be great to either make this explicit in the documentation, or to allow a merge operation that concatenates embedding sets such that they are concatenated across the numeric / vector axis
e.g.
EmbeddingSet(Embedding('name', [1, 2, 3])).merge(EmbeddingSet(Embedding('name', [4, 5, 6]))) => EmbeddingSet(Embedding('name', [1, 2, 3, 4, 5, 6]))

Right now I am not aware of an option to do this.
The current behavior returns the following:
EmbeddingSet(Embedding('name', [1, 2, 3])).merge(EmbeddingSet(Embedding('name', [4, 5, 6]))) => EmbeddingSet(Embedding('name', [4, 5, 6]))

as it is designed to merge EmbeddingSets of different names. It would be very useful to concatenate across embedding vectors to combine distinct representations together into single Embeddings.

Thanks for raising this issue, @Imod7 will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗

I think you raise an interesting point, but I'd like to double check that I am interpreting it correctly. It seems like you're interested in concatenating vectors that have the same token. I'm assuming that the use-case is to combine the output of language models.
Am I correct here? If you're interested in combining language models, it feels like we might want to have a way to concatenate vectors at the Language-level, which is a step before the EmbeddingSet-level.

Hi @koaning, yeah, exactly, that was what I intend to say. Taking a quick look, it might seem that introducing such a feature at  the EmbeddingSet would make it more flexible, since this would allow combination of arbitrary name/vector sets that don't necessarily provene from the preset language model APIs. But perhaps this is not an issue? One of my vector sets, for example, requires reading in names and vectors with the EmbeddingSet.from_names_X method as the embeddings are from a model that aren't supported in the 'Language' class loading.

I'm closing issues because ever since the project moved to my personal account it's been more into maintenance mode than a "active work" mode.


Aws::Rails::SqsActiveJob#execute captures StandardError which is too wide

Steps to reproduce

Set up AWS RDS to manage master passwords and rotate
Configure your database details via environment properties
Wait for your DB password to change

Once step 3 occurs my ActiveRecord jobs start throwing ActiveRecord::NoDatabaseError which is a subclass of StandardError
The current behaviour of Aws::Rails::SqsActiveJob#execute captures StandardError.
Expected behavior

I would expect an ActiveRecord::NoDatabaseError NOT to be caught.
I would expect the poller to die.

In my case the poller process finishing would kill the container which would be rescheduled with refreshed environment properties.
Actual behavior
The poller continues consuming from the queue, retrying messages at a great rate of speed.
System configuration
Rails version: 7.1
Ruby version: 3.3

We've revamped the error handling in aws-activejob-sqs 1.0 and added a configuration for a user provided error handler which allows propagation of errors out of the executor.   Thanks for suggesting this!


[Deserialization] Don't add an OverrideAttr if the 'overridden' decl is a convenience init when deserializing

The convenience initializer isn't really being overridden, and the attribute is only introduced after serializing and then de-serializing the AST. The attribute was causing us to incorrectly add the 'override' modifier on such initializers when printing the module interface as part of the merge-modules step. Trying to then consume them would give error: initializer does not override a designated initializer from its superclass.
Resolves rdar://problem/49856927

@swift-ci please test

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - a3c6759acb3946b1206d3b209aa83d069e0cf84e

Build failed
Swift Test OS X Platform
Git Sha - a3c6759acb3946b1206d3b209aa83d069e0cf84e

@swift-ci please test OS X Platform

@jrose-apple @harlanhaskins are you both ok with this now?


Small CLI bugs

[x] COB update or create does not update signed refs
[x] rad init shouldn't announce refs by default, since it tells the user to call rad push
[x] rad node should prompt for passphrase if RAD_PASSPHRASE isnt' set
[x] rad rm prompt looks broken
[x] rad init fails if node isn't running, but still creates the project

Closed by #386


Vespa  container crash during startup

Describe the bug
We have a single node  vespa environment which failed to come up after restart.
Could you us understanding what the issue could be
[2023-07-13 14:45:13.697] INFO    container-clustercontroller Container.com.yahoo.vespa.clustercontroller.core.EventLog Added node only event: Event: storage.0: Node got back into slobrok with same address as before: tcp/d190259-356.dc.gs.com:19106
[2023-07-13 14:45:13.701] INFO    searchnode       proton.status        Starting status web server on port 19107.
[2023-07-13 14:45:13.999] WARNING searchnode       stderr       /builddir/build/BUILD/vespa-8.137.25/searchlib/src/vespa/searchlib/diskindex/pagedict4file.cpp:28: Abort called. Reason: should not be reached
[2023-07-13 14:45:14.000] WARNING searchnode       stderr       terminate called after throwing an instance of 'std::runtime_error'
[2023-07-13 14:45:14.000] WARNING searchnode       stderr         what():  Fatal: Reading<PHONE_NUMBER>3709551615 bytes, got 0 from '/opt/vespa/var/db/vespa/search/cluster.vespadoc/n0/documents/vespaDocumentType/0.ready/index/index.fusion.12/docStorageMode/boolocc.idx' failed: short read
[2023-07-13 14:45:14.001] WARNING searchnode       stderr       terminate called recursively
[2023-07-13 14:45:14.001] WARNING searchnode       stderr       terminate called recursively
[2023-07-13 14:45:14.001] WARNING searchnode       stderr       terminate called recursively
[2023-07-13 14:45:14.000] ERROR   searchnode       proton.diskindex.pagedict4file       Could not open /opt/vespa/var/db/vespa/search/cluster.vespadoc/n0/documents/`vespaDocumentType/0.ready/index/index.fusion.12/accountNumber_s/dictionary.ssdat for write: error=24("Too many open files") fileStat[name=/opt/vespa/var/db/vespa/search/cluster.vespadoc/n0/documents/vespaDocumentType/0.ready/index/index.fusion.12/accountNumber_s/dictionary.ssdat errno=2("No such file or directory")] dirStat[name=/opt/vespa/var/db/vespa/search/cluster.vespadoc/n0/documents/vespaDocumentType/0.ready/index/index.fusion.12/accountNumber_s mode=40755 uid=1000 gid=1000 size=57 mtime=1689259512]
[2023-07-13 14:45:14.003] ERROR   searchnode       proton       /builddir/build/BUILD/vespa-8.137.25/searchlib/src/vespa/searchlib/diskindex/pagedict4file.cpp:28: Abort called. Reason: should not be reached
[2023-07-13 14:45:14.014] WARNING searchnode       stderr       terminate called recursively
[2023-07-13 14:45:14.015] WARNING searchnode       stderr       /builddir/build/BUILD/vespa-8.137.25/searchlib/src/vespa/searchlib/diskindex/pagedict4file.cpp:28: Abort called. Reason: should not be reached
[2023-07-13 14:45:14.862] INFO    container-clustercontroller Container.com.yahoo.vespa.clustercontroller.core.EventLog Added node only event: Event: storage.0: Node is no longer in slobrok. No pending state request to node.
Environment (please complete the following information):

Infrastructure: Podman

Vespa version
8.137.25

The limit for number of open files is too low (cf. Too many open files message) in the container.

What's the output of ulimit -n? Assuming it's a low number (e.g. 1024), try increasing it substantially, for example ulimit -n 262144 (disclaimer: this is not a scientifically chosen value, just happens to be what I've got on my dev system).

The max user processes and open files limit is currently set to 65536

Yes, that might be too low for deployments with many schemas and fields.


Equivalent of DeclareMathOperator?

I'm toying with using KaTeX instead of MathJax for the Felix language category theory primer. The file uses MathJax's DeclareMathOperator, and KaTeX is throwing a parse error. What should I use instead?

We don't currently have anything like DeclareMathOperator in KaTeX. Since \DeclareMathOperator is basically the same as \operatorname, this should be merged into #145.

(In conjunction with support for defining macros #37.)

@xymostech , I find DeclareMathOperator to be useful to generate operators in all the document instead of writing them again and again:
$$
\DeclareMathOperator{\rank}{rank}
$$

Now I can use it:

$$
\rank \left( \boldsymbol{A} \right) = 4
$$

Any chance to have it?


Add explicit dependency to everit-json-schema

Adding this explicit declaration overrides apicurio's transitive dependency of com.github.everit-org.json-schema:org.everit.json.schema:jar:1.14.0 which uses jitpack

If I checkout the branch and I dump the dependency tree of the camel-connector-maven-plugin modules I still see the everit-json-schema dependency that belong to the com.github.everit-org.json-schema group in addition to the new one:
[INFO] +- io.apicurio:apicurio-registry-schema-util-json:jar:2.2.0.Final:compile
[INFO] |  +- io.apicurio:apicurio-registry-schema-util-common:jar:2.2.0.Final:compile
[INFO] |  |  \- io.apicurio:apicurio-registry-common:jar:2.2.0.Final:compile
[INFO] |  |     \- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.1_spec:jar:2.0.1.Final:compile
[INFO] |  +- org.projectlombok:lombok:jar:1.18.22:compile
[INFO] |  +- com.github.everit-org.json-schema:org.everit.json.schema:jar:1.14.0:compile
[INFO] |  \- com.fasterxml.jackson.datatype:jackson-datatype-json-org:jar:2.13.4:compile
[INFO] +- com.github.erosb:everit-json-schema:jar:1.14.1:compile
[INFO] |  +- org.json:json:jar:20220320:compile

Am I doing something wrong ?

Both depencies are there. Maven choses to use the one declared in the project. You can see that with mvn dependency:tree -Dverbose.
I could add an excludes clause to guarantee that the jitpack one is never used.

Both depencies are there. Maven choses to use the one declared in the project. You can see that with mvn dependency:tree -Dverbose.
I could add an excludes clause to guarantee that the jitpack one is never used.

That would be nice so that can save some headache in the future

@lburgazzoli I added the exclusion clause and mvn dependency:tree does not show com.github.everit-org.json-schema:org.everit.json.schema:jar:1.14.0 anymore.


Add dependancy injection for handlers

Currently the package provides a logger in a sort of DI way which is extremely useful.
I believe it should be possible to generalise this so users could add their own dependancy objects to pass to handlers when building endpoints.
I've got some code that can sort of do this already however it is not perfect yet and would be a breaking change when it shouldn't be so not ready for a pull request yet.
An example usage would be
new EndPointFactory(...)
  .addDependancy({db:SomeDataBaseObject})
  .build({
    input:...
    output:...
    handler: async ({input, db, logger})=>{
      db.query();
      return ...;
    }),
  });

Sorry for any mistakes, its 04:00 am here.
What do you think of this?
I'd also like to expand it to add dependancies that get created with a function on each request too for stuff like specific database connections instead of a single database object.

@Isaac-Leonard , for me this method looks redundant, since you're connecting this db dependency in the same place where your handler is implemented, so you can use it directly within handler without passing it through the factory.
In case this entity somehow depends on incoming data or available for limited users, the existing method .addMiddleware() is designed for passing the desired entity within options parameter of the handler.
Perhaps I'm missing something. Please let me know if these two solutions are not suitable for your case (with some more details). Thank you!

Actually yeah you're right, I really should read the full documentation first before trying to add features.bThe only differences I would maybe make is to add the properties on options directly to the argument passed to handler instead of as a options property but really that doesn't make much of a difference and not requiring the createMiddleware boilerplate..

Actually no
Looking at it more there is currently no typing on the options object.
Thats what My solution would add.
I've pushed my changes on my fork if you would like to look although they are a bit messy, its got tests demonstrating its typesafeness.
Currently it requires a breaking change as typescript can't infer types without it.
It currently allows for anything to be added to a dependancies object that gets passed to the final handler but only static data for now, making it dynamic such as creating individual db connections or authenticating users with a type safe user object being added to the result however should be doable.
The current options object is just typed as any.

The current options object is just typed as any.

I'd recommend to check the type of your middleware's output and how you connect this middleware.
Usually it works this way (in a project, that utilizes express-zod-api):

and not requiring the createMiddleware boilerplate..

I agree, that in some cases, especially for empty inputs, there may be some sort of shorthand for providing Endpoints with options easier. Need to think on it a little bit...

@Isaac-Leonard , please check out PR #234.
Does it fulfill your needs?

It looks good, sorry I've been busy with other things lately.
Would it be possible to pass a plain function to it too that returns an object?
Also it doesn't fix the options being typed as any on the endpoint handler, I believe it should be possible to fully type it properly but would require breaking changes.

Actually options object seems to be typed fine, sorry.


[Landcover Toolkit] Add default vis args for common representations

bands: ['TC1', 'TC2', 'TC3']
bands: ['SWIR1', 'NIR', 'Red']
bands: ['SWIR1', 'NIR', 'Green']
bands: ['NIR', 'Red', 'Green']
bands: ['NIR', 'SWIR1', 'Red']
I have generally decent stretches for all of these.

Closing due to inactivity. Please reopen as necessary.


[BUG]: uncaught connections errors

Description of the bug
Connection errors should be caught and processed, or at least there should be a silent paramater, that says, if an error should be thrown. There is an argument to be made, that this actually shouldn't be the case, but imo the silent parameter should exist.
I also reccomend using logging, then you could just print a warning. When I find the time I am gonna open a pr for this, if you haven't implemented it.
Also sorry if I come of rude, this library really is helpful, but it just crashed my 10 000 lines program. xD
Seriosly keep going.
<33
EDIT: IMO the silent attribute should just return an empty array if anything fails, because yk not segments.
Steps To Reproduce

Use the programm
Pull out your ethernet cable

Additional Information
No response

I agree that connection errors should be caught. I don’t know why I didn’t add this the first time lol. But yeah It should be raised as an error.
The silent attribute is a good idea too. And I have thought about using logging since the beginning but just didn’t get the chance to implement it
I may be able to add these in the next few days

Great thank you! You'd do me a huge favor with this.


stop using multiple <br's>

Description:

Related Issue (if applicable):

Screenshots:

Nice find! :)

@all-contributors add @hriaksnv5678 doc

no dont

it's my alt

lol


Ethan: Watch newscarter.com

Ethan requests the watch of the watch_keyword newscarter\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

newscarter\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Nisse Engström in Charcoal HQ


📝 Add article "Tortoise ORM / FastAPI 整合快速筆記" to External Links

Thanks! I tweaked it a bit to include the new Taiwanese section in the docs. :nerd_face:


Add RFC 9540 to SVCBs to indicate Oblivious HTTP is available

Hi folks!
The IETF just recently published a new RFC 9540. It introduces a new SVCB parameter ohttp to a service binding DNS RR to indicate Oblivious HTTP is available on the target host. Note that the value is always empty. It can be either used in the HTTPS SVCB or in the SVCBs for DDR (Disovery of Designated Resolvers) (see RFC 9462).
I've added the new SVCB type and added also the tests from the different RFCs.

lgtm, could you do the small favor and update the README with these RFC nums too? ta

doing it myself


[mango.modules] Remove modules

In GitLab by @mnebel-wenner on Dec 12, 2022, 14:15
We should remove the mango.moduls module. In my opinion, these convinience methods should not be part of mango. It might be usefull, to implement some microservice architecture for an agent, however, I don't see the point in providing this module.

@rcschrg this is solved in #104


Interpolation nodes incorrect

Pyramid quad face nodes do not match tensor product quad nodes.

Triangular interpolation nodes also appear to be non-symmetric...

Symmetry is fixed - was an issue with edge parametrization.

Still need to dispatch on pyramid nodes, which don't yield tensor product quad nodes.

fixed in cbcba88


podcast:alternateEnclosure should remove the bitrate attribute

<podcast:alternateEnclosure> allows for a bitrate attribute. While this is interesting because it would allow a podcast app to download episodes of a reasonable quality for the current connection, it suffers from significant shortcomings:

The bitrate of a file in many codecs isn't a useful apples-to-apples comparison between audio formats. An MP3 at 192kbps CBR is far larger than AAC at 128kbps, but both are (roughly) considered "transparent". Bitrate tells you little about what to expect within the file: the byte length would tell you far more.
Not all encodings have a fixed bitrate (e.g., VBR audio)

In the "happy" case, the bitrate could be used to help inform the consumer about their choice of quality and data use. However, this requires the consumer to understand implementation details of the encoding of the content. The podcast app could try to make intelligent decisions, but the information provided—even when complete—offers little ability for a podcast app to make a meaningful choice based on the consumer's pre-specified intent.
Moreover, when the tags represent different types of content, the bitrate gives no data that's useful at download time.
I'd recommend removing the attribute unless there's a compelling use case for it.

The bitrate of a file in many codecs isn't a useful apples-to-apples comparison between audio formats.

It isn't a useful comparison for "audio quality". However, it's a bloody useful way to learn which file is going to cost me more money to download, or which file I might actually be able to stream on my 56k6 modem. The latter is not (immediately) answered by the total bytesize.
A use-case might be that an app would download the high-bitrate version when on wifi, but the low-bitrate version when on mobile. However, if the content is different, I agree it would be helpful to know that. I wonder if there's a way to flag this?

Not all encodings have a fixed bitrate (e.g., VBR audio)

VBR audio is not suitable for podcasting, and should not be used.

What about avoiding the specific bitrate numbers altogether and instead using a nomenclature like “low”, “medium” or “high”.  That’s a pretty good indicator that the app can flag on to know what to grab if the connection is poor or great.

I might actually be able to stream on my 56k6 modem

Is it a US Robotics Dual Host? I loved mine!

it's a bloody useful way to learn which file is going to cost me more money to download

Wouldn't the length of the enclosure be a better attribute to use in that case?

What about avoiding the specific bitrate numbers altogether and instead using a nomenclature like “low”, “medium” or “high”.

Interesting! Do you think we need to support 3 different alternates? Would 2 work?

A long time ago, I was involved in a specification that had a "small", "medium" and "big" size for radio station logo. Built for the displays in use then, the sizes were 16x16, 32x32 and a staggering 64x64. I'm not much of a fan of those descriptions, having made that mistake.
For video, "low", "medium" and "high" may well suffer from the same problem.
In terms of making the feed - as a podcaster, I know I'm making a 128kbps file; I don't know that today's is 3,357,242 bytes long. The most complicated bit about rolling my own RSS feed has been working out durations and filesizes. I'd like to make things easy if possible.
But, if you feel that length is better, then that's fine. It occurs to me that the normal enclosure has that, and perhaps we should be aiming to mirror that.

Needs more time to bake.  I always knew this would be one of the more complex tags to figure out.  I'm fine with booting this to phase 2 for now.  The world won't end.  :-)