doc: document/reassert that last two releases are supported equally

The policy for what does and doesn't get backported is currently documented at https://golang.org/wiki/MinorReleases.

Our default decision should always be to not backport, but fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the most recent two release branches, if applicable to that branch.
Fixes for experimental ports are generally not backported.
A “serious” problem is one that prevents a program from working at all. "Use a more recent stable version" is a valid workaround, so very few fixes will be backported to both previous issues.

This is pretty vague, and it detaches from practice in quite a few ways. We discussed a more complete framework that reflects the current reality with @dmitshur.
I propose we document it at https://golang.org/doc/devel/release.html#policy (in keeping with #34038) with the following text.
/cc @golang/osp-team

Backporting policy
Most recent major release. The following changes are are eligible for backporting to the latest major release.

Security fixes, in their own release, according to the security policy.
Fixes for serious problems with no workaround. A “serious” problem is one that prevents a program from working at all. This includes, for example, miscompilation issues.
Early fixes for regressions and issues in new functionality. As the release matures, the bar for these changes gets higher: while the first minor release in a series will accept most fixes for user-visible regressions, after five months they will be mostly rejected. As more of the ecosystem upgrades, fixing regressions with workarounds becomes less and less valuable, and the tradeoff with stability shifts.
Documentation changes that fix incorrect public docs.

Fixes for experimental ports are generally not backported.
Previous major release. The only fixes eligible for backporting to the previous major release (for example, to Go 1.10, once Go 1.11 has been released) are those that address external changes that would make the release unusable. This includes security fixes and platform compatibility fixes (for example, if a new version of an OS breaks Go programs).
We consider upgrading to the latest major release a valid workaround, and the purpose of maintaining the previous major release is only not to force users to upgrade unexpectedly, so pre-existing serious issues and regressions are only fixed in the latest major release.

I find this a little confusing, because fixes to the most-recent release are also called "backports". The above text seems to address only the previous release.

Would changing "latest" into "most recent" here help?

The following changes are are eligible for backporting to the latest major release.

Ah, I didn't see that the bullet list and paragraph pertain to different categories. It would help if the policy had two subsection heads.
Re the policy, a lot of folks would rather not upgrade deployments to a new major release until they've had the chance to evaluate its performance in their systems, and iron out any wrinkles. So early in the life of a most-recent release, they'd want to see all backports land on both releases.
Tangentially, I think the best policy would be long-term-support versions of the toolchain & runtime, and a rolling-release of the stdlib... But that's prob outside the scope here :-)

Edited it with paragraph headings, thank you.

Re the policy, a lot of folks would rather not upgrade deployments to a new major release until they've had the chance to evaluate its performance in their systems, and iron out any wrinkles. So early in the life of a most-recent release, they'd want to see all backports land on both releases.

That's why we still backport things that are necessary to stay on the previous major release, but after six months, there are very few regressions that can still be found, and stability becomes more important (as well as limited team resources).

It would help if the policy gave a time frame for full support of the previous release, e.g. 90 days. That would let deployment teams know the earliest date on which they might have to either roll out the most recent release, or consider custom builds.

I'll find somewhere to link https://golang.org/s/release if that's what you mean?

No. The previous-release policy seems vague and perhaps contradictory:

the purpose of maintaining the previous major release is only not to force users to upgrade immediately

How long is "not immediately", i.e. how long will the previous release get all backports? It's apparently less than 6 months. Could the policy give a time frame?

The only fixes eligible for backporting to the previous major release ... are those that address external changes that would make the release unusable

For fixes outside that set, one apparently has to upgrade immediately?
A lot of sites would prefer to postpone major upgrades as long as possible, and some even skip over an entire cycle.

@networkimprov, sites who intend to skip an entire cycle should be very careful to test the beta and/or RC releases of the next release they do intend to pick up, since the window for the previous release closes as soon as the new release occurs.
You really don't want to be in a situation where you're, say, stuck on 1.11 and neither 1.12 nor 1.13 works for you because of some 1.12 regression that you didn't detect until after the 1.13 release.

For fixes outside that set, one apparently has to upgrade immediately?

Yes: if something non-critical is broken and has been for a long time, then it can presumably remain non-critically broken for a little while longer while you upgrade.

Oh, I see what's unclear. What I am trying to say is that if you upgrade your Linux kernel and Go 1.12.5 stops working with it, and we only backport the fix to Go 1.13, you are now forced to upgrade to Go 1.13 immediately. You can't stay on Go 1.12 until you are ready.
OTOH, if you are running Go 1.12.5 and it was working for you, it's fine to say you need to upgrade to Go 1.13.2 to get some fix.
The difference is external forces.

It's awkward to be the only one asking about this; I hope I haven't misunderstood something basic.
But I'm startled to learn that regression backports cease on the day the next major release appears. I'd assumed that a previous release would be fully supported for 6 months. (Would anyone expect otherwise?)
Suppose I wait until 1.12.5 to upgrade from 1.11.x, and then discover a regression on the day 1.13 comes out, I'm outta luck? Either upgrade again to 1.13 or resort to a custom build?
What I suggested above is that regression backports cease at a later date, e.g. 90 days following the next major release, and that the policy should document the time frame.

The difference is external forces

A distinction between regressions and "external forces" seems arbitrary. If one could fully evaluate a deployed application running on a new release within a known period, that would surface any regressions before the backport window closes. But that's not achievable in many cases.

stuck on 1.11 and neither 1.12 nor 1.13 works for you because of some 1.12 regression that you didn't detect until after the 1.13 release.

@bcmills I gathered that fix would be backported to 1.13 since it broke something working in 1.11?

I gathered that fix would be backported to 1.13 since it broke something working in 1.11?

Yes; but if you're still on 1.11 due to some unreported regression, it may take a while to identify and backport the fix, and in the meantime you'd either be stuck with the regression or stuck with an unsupported Go release.
So it's a risky situation either way — it's much less risky to either upgrade through every release, or ensure that you test the betas and RCs of the next release after you skip one.

A lot of sites would prefer to postpone major upgrades as long as possible, and some even skip over an entire cycle.

It would be interesting to know how widespread this preference is, and what motivates it.
E.g., my first assumption was this only affects stubborn enterprise customers (who presumably could afford support contracts). But until Debian's latest stable release earlier this year, they were still shipping Go 1.7. Ubuntu 16.04LTS and 18.04LTS provide Go 1.6 and Go 1.10, respectively. Presumably other Linux distros are similarly affected.

Honestly I would expect that most large sites skip releases.  I would be astonished if they adopt every release.  At a large site each new release requires full re-qualification and testing.  Nobody has time for that, unless they anticipate some large benefit.
(That's not to say that we need to do anything different.  Our resources are limited.  There is clearly space for commercial support organizations.)

Ubuntu 16.04LTS and 18.04LTS provide Go 1.6 and Go 1.10, respectively

That is a great argument for LTS releases.

Honestly I would expect that most large sites skip releases.

[cries in security engineer]

✋👍

No one's addressed https://github.com/golang/go/issues/34536#issuecomment-535762710
Should I open a new issue to suggest changing the regression-backports window for previous releases?

I think the current text reflects the reality of the current policy, and it would be good to document it properly before we discuss changing it. If you are ok with this text going into release.html and then discussing changing the policy it reflects in another proposal, I think that would be a good way forward.

Then I think you should add a sentence to the effect of "Any regressions found in the previous release will not be fixed."

Then I think you should add a sentence to the effect of "Any regressions found in the previous release will not be fixed."

That's not the current policy, serious regressions without workaround are still fixed, but are only backported to the latest major release, because we consider it ok to make someone who is upgrading to Go 1.12 late and finds a regression simply jump forward to Go 1.13.

Sorry I meant "Any regressions found in the previous release will not be fixed in that release."
The current language could be misinterpreted. The above makes it clear.

Does that add anything over "The only fixes eligible for backporting to the previous major release [...] are those that address external changes that would make the release unusable."?

Indeed it does. The language you quote is easily misinterpreted, especially if you assume (as most would) that a previous release is fully supported.
"External changes" could be read to mean CLs produced outside the core team, for example.

Updated the last paragraph to

We consider upgrading to the latest major release a valid workaround, and the purpose of maintaining the previous major release is only not to force users to upgrade unexpectedly, so pre-existing serious issues and regressions are only fixed in the latest major release.

Ok, thanks.

I really don't understand this thread. The current policy says:

Each major Go release is supported until there are two newer major releases.  We fix critical problems, including critical security problems, in supported releases as needed by issuing minor revisions (for example, Go 1.6.1, Go 1.6.2, and so on).

What part of this is unclear?

@rsc Empirically, there have been a few discussions around different interpretations of the current text, so I am suggesting a more explicit version here. For example, what qualifies as a "critical problem"?
The OSP team developed consistent guidelines to decide what to backport, and I think it would be good to try to capture them in the policy. It might not even be proposal-worthy, really. Should I just send a CL with the suggested text (in the issue description, under the <hr>)?

After reading also #34536 and #34622 I see that what's unclear is how our recent behavior in #34536 follows our stated policy. I am not sure that it does. If not, this issue would be about changing, not clarifying our policy. That would be very significant and absolutely worth treating as a proposal. Please do not send a CL.
I will talk to @andybons to get more context about the state of the world and then follow up on this issue.

how our recent behavior in #34536

This is #34536, typo?

Thanks, fixed.

I closed #34622 as a duplicate of this issue, because both of these issues are about deciding and then making sure we are all clear about the rules for what does and does not get backported.

Even tho this issue was opened first, it has little discussion about changing the policy, whereas #34622 is entirely about that. If you're open to changing the policy, I'd suggest reopening that one and closing this.

I spoke to @andybons yesterday to get more context about the team's actions and decisions here and in #34713. I think there has been some confusion about the release policy itself and in particular perhaps not enough awareness of a change we made two years ago.
Background: Release Policy Change in 2017
The original Go release policy (before 2017) was that we did backports to the most recent one release for critical fixes, and to the most recent two releases for security releases. This had the unfortunate effect that on the day a major release was issued, the previous release was instantly unsupported, which left users feeling, well, not very supported. Not everyone can upgrade instantly: bugs and other incompatibilities do happen in new releases, and qualification tests take time, so it can quite reasonably take users a while to be ready to upgrade their production uses. If they hit critical bugs in the interim, they feel abandoned if we don't provide fixes. It's important not to abandon users who have not yet been able to upgrade to the latest release at the instant that the next release comes out. This was a common complaint when we talked to companies using or thinking about using Go, at least those who had read the release policy carefully.
In early 2017, after a brief, uncontentious discussion on #19069, we changed the policy to support the most recent two releases equally for all critical problems, not just critical security problems.
Omitting illustrative examples, the old release policy was:

Each major Go release obsoletes and ends support for the previous one.
We fix critical problems in the current release as needed by issuing minor revisions.
As a special case, we issue minor revisions for critical security problems in both the current release and the previous release.

After the discussion on #19069, we changed the policy, in CL 37531 aka 86abfbb93131, to:

Each major Go release is supported until there are two newer major releases.
We fix critical problems, including critical security problems,
in supported releases as needed by issuing minor revisions.

The implication of this policy—not just an accident of the wording but the intended effect—is that the two most recent releases are supported equally. Again, this was an explicit recognition that not everyone can quickly upgrade to the latest release to work around a critical problem.
Recent Actions

In December 2018, the https://golang.org/wiki/MinorReleases wiki page was edited. Originally it said:

Our default decision should always be to not backport, but fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the two supported major releases. For example a fix developed during the 1.11 cycle will be backported to a 1.9.x (if applicable) and 1.10.x release. Fixes for experimental ports are generally not backported.
A “serious” problem is one that prevents a program from working at all.

The change added one more sentence:

"Use a more recent stable version" is a valid workaround, so very few fixes will be backported to both previous issues.

This sentence seems to me to be in direct conflict with the policy change we made in 2017. It is stating the pre-2017 policy, not the current policy.

In September 2019, this issue (the one you are reading right now) was filed to elaborate on the December 2018 change and add it to the official release policy. I believe the title is “clarify backporting policy”—clarify, not change—because it wasn't appreciated that this a deviation from the stated policy.

In October 2019, there was a request for a backport of the fix for #33953, deemed a critical problem. The backport to Go 1.13 was #34714 (accepted and done), and the backport to Go 1.12 was #34713 (declined). In the discussion on #34713, there were multiple  comments echoing the December 2018 wiki page change. For example, “Upgrading to 1.13 will be a valid workaround after #34712 is released.”

The Options
The release policy states that the last two major releases are supported equally. That is, assuming releases are on time, a release is supported for six months during which it is the most recent release, and then six more months during which it is the “previous release.” Let's call this the 6+6 policy.
Before 2017. we had a 6+0 policy, in which a release is only supported when it is the most recent release. Our actions over the past year or so have in some cases been more consistent with the 6+0 policy than the stated 6+6 policy. This issue (the one you are reading right now) suggests that we “clarify” that the policy is 6+0, but that would be a reversion to the pre-2017 policy from the current stated 6+6 policy.
Faced with the claims and recent implementation of a 6+0 support policy, #34622 suggests that we at least adopt a 6+3 policy, or 6+N for some N > 0. I closed that issue as a duplicate of this one because both that one and this one are really about deciding what the policy is and making sure everyone agrees.
Is it 6+6, as currently stated?
Is it 6+0, as some of our recent actions would suggest?
Or should it be 6+3 or something else in the middle?
What Should We Do?
As far as I can tell, no one over the past twelve months intentionally deviated from our 6+6 release policy. No one intentionally rolled back the 2017 change. People simply assumed the policy was 6+0, as if the change had never happened, and acted accordingly. But the change did happen. Our stated policy is 6+6, and companies have adopted Go based on that stated policy, that promise of support.
We could decide to change the stated policy, officially moving to 6+0 or 6+3. That would mean providing less support in 2020 than we said we would in 2017, possibly (likely?) alienating users relying on the stated policy.
Or we could decide to keep the current stated policy, staying at 6+6. That would mean admitting we made some mistakes over the past 12 months, correcting them as much as possible, and taking steps to avoid them in the future. In particular I think it would mean fixing the MinorReleases wiki and reopening #34713 for a backport in a future Go 1.12 point release.
To be very clear, I believe everyone was acting in good faith, and it is not my purpose here to point blame at anyone by pointing at specific actions that happened. In particular, I've omitted the names of the actors because they are unimportant. We the Go team did these things and are responsible for them together. The specifics actions we took, however, are important: we need to understand what we did in order to decide what to do moving forward, including correcting anything we now believe to be a mistake.

Personally, I think we should honor and keep the commitment we made in 2017.
That is, I think we should keep 6+6 and correct the things we've done that are inconsistent with 6+6.
The reasons seemed compelling to me at the time, and with twice as many Go users today, they only seem more compelling to me now. But even more important is that we committed to doing so. Backing down to 6+0 or even 6+3 breaks the promise we made. Doing that without a very good justification and a clear explanation will erode user trust. I realize that wasn't the intention, but I believe it would be the effect.
Please thumbs up if you agree with 6+6 + fixing mistakes;
thumbs down if you think we should do 6+0 or 6+3 instead (and maybe comment to elaborate).
Thanks.

Thank you @rsc for the detailed background, I indeed didn't know about the 2017 discussion, and I agree that the wording of the policy I'm suggesting is a meaningful change from #19069.
As additional background, I'll try to provide my perspective on why we veered away from it, and I'll try to argue that the policy in this issue does address #19069. However, while I was sharing the release management responsibilities with the rest of the OSP team during this discussion, they are now handled by a subgroup I am not part of, so my opinion carries little weight at this point.
Over the past year, as the OSP team expanded, we made an effort to document and distribute various tasks, including approving backports. That required formalizing, at least internally, what made an issue critical. We found that particularly hard: "critical" is fairly subjective, and we struggled to elaborate on the criteria. Moreover, we noticed that at the beginning of a cycle many less-critical regressions were fixed by backport, which made sense, but was not encoded in the policy. Eventually, we resorted to making these decisions in meetings to make them consistent.
What worked fairly reliably in the decision process was asking two questions:

Is this going to stop many people from upgrading?

Is this going to force many people to upgrade?

What's nice about (1) is that it naturally scales with time: if many months have passed, and no one noticed an issue, surely it's not blocking many people from upgrading. (2) nicely includes security issues.
Note how (1) becomes pretty meaningless when applied to the previous release: why are users upgrading to the old release when a new one is available? This policy suggests fixing issues passing (1) in the current release, and issues passing (2) in both.
I'd argue that provides a good level of long(-ish) term support to slow-to-upgrade users: we promise we'll not force you to upgrade more often than every 12 months, because such issues would pass (2) and get backported all the way. However, you don't get to upgrade to the previous release when there's a new one available: just always upgrade to the latest if you are upgrading, and if you need a long lead time to qualify it, start with the beta.
Note how #19069 would pass (2) and would have been backported to both releases under this proposed policy.
I think a policy based on those two questions (which I might or might not have done a good job of formalizing in this proposal) would provide a clear and consistent framework to the team, while still delivering 12 months of support for releases, in the same sense that LTS distributions support staying on an old release.

@FiloSottile, I can't tell whether you agree with my suggestion that we honor our commitment to the 6+6 support policy. Are you arguing that we should change the policy away from 6+6?

I am arguing for the following policy: for 6 months, we backport fixes for issues that would stop many users from upgrading; for the next 6 months, we only backport fixes for issues that would force current users of that release to upgrade (like security issues and incompatibilities with new OS versions, but not newly observed regressions).
That's what I tried to propose with this issue. As far as I understand, this is a different kind of 6+6 than what you called 6+6, because the second 6 months have a stricter criteria.
(Unless that was implicit in your interpretation of "critical", the subjectivity of which is what I've been trying to solve.)

I don't understand your criteria. How does a newly observed regression in a 6-month old release not force current users to upgrade if they start running into it?
The answer to that aside, the fact that I don't understand your criteria means users won't either and is exactly why the current 6+6 policy is better: it's much easier to explain "if something is deemed critical to fix in any release, it gets fixed in the last two."
And again, that's what we promised users in 2017, that the last two releases are equally supported. In the absence of very compelling new information that that was a mistake, we should do what we said we would do. Your argument seems like it is splitting hairs in a situation where hair-splitting is not something we want to inflict on users.
The consensus on this issue, including from the open source team who has to do the work, seems to be overwhelmingly in favor of keeping 6+6. I suggest we reaffirm that the last two releases are equally well supported.

The consensus on this issue, including from the open source team who has to do the work, seems to be overwhelmingly in favor of keeping 6+6. I suggest we reaffirm that the last two releases are equally well supported.

Sounds good. As I mentioned, the open source team's opinion is strictly more relevant than mine here.
Would you like me to close this issue, or leave it open to update the wiki? (I'm happy to do it myself, but I might not be the best person to word the policy now.)

Let's leave the issue open and let the open source team use it to track any doc changes they need to make.

Based on the discussion above, it sounds like everyone involved now agrees that we should support the last two releases equally - either something is backported to both (assuming the bug was in the N-2 release) or neither.
As retitled, this is now a likely accept.

it sounds like everyone involved now agrees that we should support the last two releases equally

Yes, this is my understanding. But I would like to clarify the next part of what you said:

either something is backported to both (assuming the bug was in the N-2 release) or neither.

By this, do you mean the same as:
"For a bug was in the N-2 release, either something is backported to both or neither."
I'm asking for this clarification because I feel your original phrasing can be interpreted differently.

I don't understand the rewording, or else how it's different from what I wrote.
For concreteness, if the most recent release was Go 1.14:

If the bug was introduced in Go 1.13, then either both Go 1.13 and Go 1.14 get the fix, or neither do.
If the bug was introduced in Go 1.14, then clearly only Go 1.14 gets the fix.

No other final comments, so accepting.

I believe that https://golang.org/wiki/MinorReleases now states the agreed policy (it was corrected as part of #37097).
I believe the agreed policy is also stated at golang.org/x/website/content/static/doc/devel/release.html.
So I don't think there is anything else to do here.  Closing.  Please comment if you disagree.

@ianlancetaylor Issue #37097 was about a problem on the Go-Release-Cycle page.
I spotted a problematic statement in the MinorReleases page; filed #40206 about it.

I don't believe we have a better place we can link to other than Russ's comment in this issue when referencing this aspect of the release policy. The https://golang.org/wiki/MinorReleases page was made less misleading in #40206, but it seems more needs to be done before this can be closed.


Add IServiceProvider as an input to AddAuth0AuthenticationClient

It would be nice to have IServiceProvider available to fetch other services for populating configuration.
services.AddAuth0AuthenticationClient((config, provider) => {
    var configuration = provider.GetRequiredService<IConfiguration>();

    config.Domain = configuration["AUTH0_DOMAIN"];
    // etc.
});

Adding the overload isn't a big deal so I'll throw it into the next version, but IConfiguration is already readily available via *ApplicationBuilder/Startup.cs, which would be accessible to wherever this is being called.


Auto Sync Updates

What's New?

Use "X-Farmbot-Rpc-Id" instsead of "X-Request-Id" because Heroku was using that apparently.
Set data consistency timeout to 3500
Never disable the sync button.

Coverage decreased (-0.006%) to 84.014% when pulling 51779b58ca4f5ce44ffb5fc78f1781bc4a439ad3 on RickCarlino:dont_disable_sync into f9b35083a8f11c44fa6c94c193b69d71d1f19909 on FarmBot:staging.

Coverage decreased (-0.006%) to 84.014% when pulling 51779b58ca4f5ce44ffb5fc78f1781bc4a439ad3 on RickCarlino:dont_disable_sync into f9b35083a8f11c44fa6c94c193b69d71d1f19909 on FarmBot:staging.

Coverage increased (+0.02%) to 84.037% when pulling 9f4c381d14d4080ff2dbbbb9cf37757cf3449999 on RickCarlino:dont_disable_sync into f9b35083a8f11c44fa6c94c193b69d71d1f19909 on FarmBot:staging.

Coverage increased (+0.02%) to 84.847% when pulling 83773dab2149d5f09724fe15dba82e63e66bd647 on RickCarlino:dont_disable_sync into 447f0c3884097b75280d03821c36658607b43955 on FarmBot:staging.


Added check if subnet.DefaultForAz is not nil

Added check if subnet.DefaultForAz is not nil

subnet.DefaultForAz is an optional parameter and can be empty.
if subnet.DefaultForAz is empty, it is considered as false.

Reference: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Subnet.html

@nathanleclaire I would be glad if you could look at this. I have another PR depending on this. Thank you.

It causes panic if trying to dereference and not instantiated I suppose?

LGTM

@nathanleclaire yes, exactly. Thank you.


Improved compatibility for Android

Make CNN based glsl shaders compatible with Android. #99

This is strange, the SPIR-V compiler must be different for android devices...

This is strange, the SPIR-V compiler must be different for android devices...

Yes, for other non-CNN shaders, some of them still not working, I haven't looked into where the problem is, but I guess it's in Implicit type conversion too.


fix GEARPUMP-174 update shaded akka-kryo version to 0.4.1

[Current coverage][cc-pull] is 70.59%
[][cc-pull]

No coverage report found for master at ec667d4.

Powered by Codecov. Last updated by [ec667d4...36183d1][cc-compare]
[cc-base-branch]: https://codecov.io/gh/apache/incubator-gearpump/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/apache/incubator-gearpump/compare/ec667d45dba50579020b67a2a39a68d5e2e23a30...36183d120665af31badf2d5fcd656fd542522192
[cc-pull]: https://codecov.io/gh/apache/incubator-gearpump/pull/58?src=pr

+1


Feature request: Immediately black out the screen when --immediate flag is used

When locking the screen before the PC suspends, it's important that this happens fast. It's really disconcerting when the monitor is visible for a couple of seconds after waking the PC before the lock screen fades in, and it could conceivably be a security issue in some cases.
I think it would be nice if the --immediate flag caused hyprlock to black out the screen as soon as possible, before doing any other non-critical setup like loading images.
This would ensure that when the machine resumes, there's only a black screen while hyprlock finishes its setup and can fade in the nice lock background image.
For backwards compatibility this could also be a new flag with the name --sleep, --blackout etc.

+1 for this.
I did some testing, and it seems that loading the background image is what causes this issue. As a temporary workaround, I've set a background color instead of an image, this makes the lock screen appear immediately. I think adding a reload option for the background image would fix this.

I think we could do something like rendering the configured color when the background is not available yet.
Although even my shitty laptop renders a 8mb image very fast and I have no delay at all. I also cannot relate to the suspend thing, because I have never experienced hyprlock still showing the workspace, when the device wakes again.

Yeah, that should fix this.
I have no idea why it takes so long to render the image, there's a delay with even small images ( under 200kb). At first I thought it was something to do with nvidia, but it's the same with an igpu.

Any thoughts about these decisions?

Should this also be a config option or just a flag?
Should fade_in also be disabled when this is used? (In my current impl it still fades. Also works but maybe you want no fade in that case)
--blackout is ok as a name, but you can configure the color. Any naming ideas would be a better fit?

I think it should be a config option, but that's just my preference and I don't really think there's any issue with it being a flag either.
I think it should just respect whatever is present in the config and not overdrive the fade_in option.
--blackout seems ok, but perhaps, --unloaded or --no_load is better suited, as hyprlock essentially starts without anything rendered in.

Please check out the PR if you have time and tell me what you think :)

For the purposes of covering the screen as fast as possible, it would be better if the fade animation was disabled as well.

True, but i kinda like it more just having it independent of the fade-in. I guess we could just add a --no-fade-in cli flag as well and then you have to fastest way actually mute your screen with --immediate --immediate-render --no-fade-in.
But in your case, I guess it starts to fade in the solid color and then switches to fading in the actual background??
For path=screenshot the background is always fast enough to not show a solid color on my system, so for me, using general:immediate_render also just improves the startup time, which is nice.
But it is not a default, because rendering the solid color can definitely happen and that can look a bit yanky.


[icu] Fix removing tests with alternative lib dir name

On some Linux distros (e.g. OpenSUSE) lib64 is used instead of lib for
libraries.
Take that into account when removing the tests, otherwise the tests are
not removed and the file(REMOVE) call fails because the variable is
empty

the lib64 problem bites me in other places as well, so maybe it makes more sense to force icu to install to lib instead of lib64 somehow

I think the better way to fix this is passing '--libdir=${prefix}/lib' to the configure args since the lib64 causes trouble in other places too

I think the better way to fix this is passing '--libdir=${prefix}/lib' to the configure args since the lib64 causes trouble in other places too

If it works, we should set it into vcpkg_configure_make, but:
https://github.com/microsoft/vcpkg/blob/63aa65e65b9d2c08772ea15d25fb8fdb0d32e557/scripts/cmake/vcpkg_configure_make.cmake#L494
cc @Neumann-A

I guess icu just use a different (or no) parameter for the test libs. In that case it needs another parameter or patch.

Closing in favor of https://github.com/microsoft/vcpkg/pull/19666


Various Dockerfile-based updates for 22.11

Closes #464

@raykallen for DS codeowners review

@gpucibot merge


Create liverpool.txt

University website: https://www.liverpool.ac.uk/
Example IT course: https://www.liverpool.ac.uk/study/undergraduate/courses/computer-science-meng-hons/overview/
Proof of using the domain as email: https://www.liverpool.ac.uk/csd/quickstart/email/

@Rytchet Pull request merged. Thank you!


Add discretization test

At the moment there are no unit tests that cover discretization.

I have added the supervised discretization strategy.
Please, implement tests for both techniques.
Check, in particular, if:

the bins cover the entire feature space for each feature, from min to max value and without gaps between bins;
the first and the last bins are from/to -inf/inf.


Data exceeds the local storage quota of 5MB

After fully loading the statistics, this error is being thrown:

Hmm, interesting - which browser is that? Might be worth trying with a different one just to see how big it really becomes (or trying to adjust the active browser's quota if possible).
Since I don't know anything about your data, do you think this is realistic?
For reference, I personally have ~70k messages over 100+ DMs and 100+ servers, and my stats are around 2MB. From what I've seen from others, nobody else seems to have run into this but it's certainly possible to get into that range.
Might have to split the stats into smaller packages, it's tough to test this if you only have one dataset 😅.

I'm using chrome and the local storage max size is 5MB (as specified in the HTML5 spec). There is no way to change that in chrome (or any other chromium browser) unfortunately.
My zipped data package is 115MB. Not sure if thats a lot though. I've been using discord for a few years now

Yeah, the data package is much larger, but that's pretty common cause it contains a ton of garbage.
Just read about Chrome's limitation there - the more you know...
I have some ideas how I could get around that, will update the issue when I've looked into the details.

Alright, I had a closer look and decided to switch from localStorage to IndexedDB which should be way more scalable. It depends a bit more on browser implementation but generally the max size is more bound to actual physical size limitations as opposed to a randomly defined number.
I've tried it locally with sizes up to 25MB but generally this should support way more.
Updated it in https://github.com/davidbmaier/discord-recap/commit/0a59161a46c105939d57f9af2cc5b63278ec63af, feel free to test it on the live version and let me know if that fixes it for you.

Yup, that fixed it for me! Thanks

Awesome, good to hear!


when uploading Storage.uid check problem

There is a problem uploading the file.
First of all, I left the target role as anon while the user logged in.
(bucket_id = 'bucket-origin'::text)
If you set permissions on that bucket as above, you can register the file normally.
The problem is that I want to have a folder for each user's uid and upload a file.
((auth.uid())::text = (storage.foldername(name))[0]))
Common sense is that I tried bringing both [0]th and [1]th, but I couldn't bring anything in.
((auth.uid())::text = 'e6074db4-7957-4aa6-9730-f4f1c2efcca8'::text)
Can you tell me what the problem is because I can't check it even if I give it to you manually?

Is the C# library unable to read user authentication information from the server because it does not send public or auth-related information when uploading?

f so, I wonder if uploading should be done by uploading to public anon and setting select or delete as owner.
Thank you every time. From MAUI Developer

I was able to get it to work on my end with a couple policies (you will still likely need to modify them for your use case!)
This would cover bucket operations that has a user_id in the path {ANY_BUCKET}/{USER_ID}.
Under storage.buckets
CREATE POLICY "Allow User to Access ANY Bucket Folder containing OWN uid" ON "storage"."buckets"
AS PERMISSIVE FOR ALL
TO authenticated
USING (((uid())::text = ANY (storage.foldername(name))))
WITH CHECK (((uid())::text = ANY (storage.foldername(name))))

A further policy would be needed to cover operations inside a bucket:
Under bucket.testing
CREATE POLICY "Allow User to Access ALL OPS in OWN Bucket Folder 1bi83kg_0" ON storage.objects
FOR SELECT TO authenticated
USING (bucket_id = 'testing' AND ((uid())::text = ANY (storage.foldername(name)))));

CREATE POLICY "Allow User to Access ALL OPS in OWN Bucket Folder 1bi83kg_1" ON storage.objects
FOR INSERT TO authenticated
WITH CHECK (bucket_id = 'testing' AND ((uid())::text = ANY (storage.foldername(name)))));

I thought about it, but if I want to access it from C#, it's ServerKey, so I know it's anon and anon=anonymous.
Then maybe he doesn't have access to "auth.uid"?
I thought it would be automatically put on when I did SignIn, but that's not it, and even though I covered up the JWT logged into SetAuth, I wonder if it would be anonymous.

Contrary to my expectation, I checked the role of auth and received it as anon. If I do this, I don't think Uid will come out.
After logging in, I entered as below.
"await client.Storage.From("bucket-origin").List("d2d97e78-fb29-4d5b-a481-e601cf5b2f2f")"
But the actual role I received from the supabase is anon. If I add authentication information, it seems necessary to be processed as authenticated instead of anon, is there any way?

var storage = Supabase.StatelessClient.Storage(url, currentUser.AccessToken);
storage.From("bucket-origin").List("d2d97e78-fb29-4d5b-a481-e601cf5b2f2f");
or
Supabase.Client customClient = new Supabase.Client(url, currentUser.AccessToken, new Supabase.SupabaseOptions { AutoConnectRealtime = true });
customClient.Storage.From("bucket-origin").List("d2d97e78-fb29-4d5b-a481-e601cf5b2f2f");

Oh, I understand now.
When you create an instance of Supabase.Client, the first factor, Url, is the same, and the second factor is usually anon public (serverKey), right?
Something was wrong, so I put in the login user's accessToken and sent it, and the above mentioned auth.Role() changed from anon to authenticated.
Although not mentioned in official documents or anywhere else, SetAuth simply replaces the current user and requires the client instance to be created and sent as needed.
It would be better if there was such information in the readme.

Well I love Supabase. I will make a good sample with MAUI.

@honeyhead my apologies that the documentation was unclear, but I'm glad you found an answer!
Was it the SetAuth method that should be clarified? Or the new Supabase.Client()?

@acupofjose
I understood how to log in after initializing with a public key.
After logging in with the public key, I believed that using SetAuth would switch from anon to authenticated.
Maybe the CustomSupabaseSessionHandler you're talking about is the way to keep the session. I'm working on this in MAUI, so I'm keeping it in SecureStorage.
If I keep it like this, I don't need to try a new login because CurrentUser or CurrentSession won't be null every time I turn on the app.
But that's not what I'm saying.
I'm going to assume there's a Supabase instance Client called HeyClient.

HeyClient initializes the anon key as the second parameter when it is created.

The user then logs in as SignIn or SignInWithPassword to keep the new session in SessionHandler.

If you take this session and attempt to save something to Storage, Auth.Role() is anon.

Therefore, the user must re-create the Subbase Instance Client and initialize it by sending the SessionHandler or the Access Token of the current current Session to the second parameter.

If you request the Instance Client that received the AccessToken in the second parameter, the Auth.Role() will not be anon.

I know that to get a user's session, the app needs to initialize with anon key and implement login.
However, in order to comply with the server's policy, it seems that the new Instance Client has to be created and requested by that Client.
Of course, if CustomSupabaseSessionHandler exists, developers can declare the AccessToken as the second parameter in a saved session when they create a single Supabase Instance Client.
Maybe this is the basic way. However, I didn't know that if I didn't set up a DefaultSessionHandler or anything else, the user who initialized using anon key and logged in through signin had to re-create the Instance Client with the AccessToken again.
I think I thought it would be SetAuth, etc. without creating a new client because I already have a session logged in and have a session, and SetAuth supports changing to authenticated instead of anon key in code other than C# example.
In a way, it may be natural to create and initialize a new Client with Access Token, but since the example is stored and received in storage regardless of server policy, it would be nice if the server said, "Initialize by inserting the second parameter into the logged-in user access token."
If this library supports, I think it would be good to decide whether to send it Anon or Authenticated if one Client has CurrentSession.
I'm going to post at least a sample of MAUI on Github, so I hope it helps someone.
Thank you for your answer.

@acupofjose
I understood how to log in after initializing with a public key.
After logging in with the public key, I believed that using SetAuth would switch from anon to authenticated.
Maybe the CustomSupabaseSessionHandler you're talking about is the way to keep the session. I'm working on this in MAUI, so I'm keeping it in SecureStorage.
If I keep it like this, I don't need to try a new login because CurrentUser or CurrentSession won't be null every time I turn on the app.
But that's not what I'm saying.
I'm going to assume there's a Supabase instance Client called HeyClient.

HeyClient initializes the anon key as the second parameter when it is created.

The user then logs in as SignIn or SignInWithPassword to keep the new session in SessionHandler.

If you take this session and attempt to save something to Storage, Auth.Role() is anon.

Therefore, the user must re-create the Subbase Instance Client and initialize it by sending the SessionHandler or the Access Token of the current current Session to the second parameter.

If you request the Instance Client that received the AccessToken in the second parameter, the Auth.Role() will not be anon.

I know that to get a user's session, the app needs to initialize with anon key and implement login.
However, in order to comply with the server's policy, it seems that the new Instance Client has to be created and requested by that Client.
Of course, if CustomSupabaseSessionHandler exists, developers can declare the AccessToken as the second parameter in a saved session when they create a single Supabase Instance Client.
Maybe this is the basic way. However, I didn't know that if I didn't set up a DefaultSessionHandler or anything else, the user who initialized using anon key and logged in through signin had to re-create the Instance Client with the AccessToken again.
I think I thought it would be SetAuth, etc. without creating a new client because I already have a session logged in and have a session, and SetAuth supports changing to authenticated instead of anon key in code other than C# example.
In a way, it may be natural to create and initialize a new Client with AccessToken, but the example is stored and received in storage regardless of server policy, so if the server does not ask anon, I hope the following words are in the readme or sample. "Initialize the second parameter in the instance client by inserting the logged-in user access token."
If this library supports, I think it would be good to decide whether to send it Anon or Authenticated if one Client has CurrentSession.
I'm going to post at least a sample of MAUI on Github, so I hope it helps someone.
Thank you for your answer.

Thanks for taking the time to answer - I really appreciate it! You're right that we could use some more documentation on how to use the library.
I'll gladly take any pull requests and would be happy to add your example project to the readme on this repo!

@honeyhead I found the issue - you were right - specifically the storage client was always using the anon key and not the user's key. GREAT catch - thanks so much for that! The fix is available in v0.8.3.


add optional extra parameter to resize method

add optional extra parameter to resize method of the ImageHelper class to customize jpeg compression quality of image being generated
Related Ticket: # 857
Issue
The default setting set_quality method of Wordpress' WP_Image_Editor class is 90%, which is not a very desirable quality for jpeg compression for web use. Also, it would just be a really nice feature to have implemented to be able to customize what compression quality resize() puts out.
Solution
Add a new optional parameter to resize() call to customize jpeg quality, 0-100. Personal suggestion for a default setting if nothing passed: 60 (as reflected in my code).
Impact
Since it's an optional extra parameter added to the end of the current parameters, it should be backwards compatible.
Usage Changes
{{ image.src | resize( 300, 200, 'top', false, 50 ) }} (would produce 50% jpeg quality)
Considerations

Would also maybe help to throw error if user passes something other than the accepted 0-100 integer.
Would need to update Timber docs.

Coverage decreased (-4.5%) to 89.896% when pulling 892fc679e907b64e0ded968c64bad2ced20efd23 on columbian-chris:857_resize_compression_quality into b9300aacca1afbd306d748cc6619d9af1233ee74 on timber:master.

Coverage decreased (-4.5%) to 89.896% when pulling 892fc679e907b64e0ded968c64bad2ced20efd23 on columbian-chris:857_resize_compression_quality into b9300aacca1afbd306d748cc6619d9af1233ee74 on timber:master.

@chrisguitarguy — thank you so much for this PR to resolve #857. I added a test and made a change so the default quality is the same as WP's (82). It's easy to override with WP's wp_editor_set_quality filter. Running the tests now and will then merge..
https://make.wordpress.org/core/2016/02/22/proposal-increase-the-default-image-compression-in-wordpress/

I'm going to close for now as a result of #1666 and the discussion in #857. Perhaps more to come here with a more flexible way of sending args to the resize filter.
Thanks again @columbian-chris for your work here. Even though this didn't make it in verbatim, we've made good progress on integrating with WP-native compression settings and have a clear roadmap for allowing arbitrary adjustments of specific images

@jarednova Perhaps a good goal for the 2.0 release to be able to pass an object parameter with any custom settings?
<img src="{{ img|resize({ w: 300, h: 200, q: 75, etc... }) }}">


chore: remove docs peer dependencies

A weird workflow (https://github.com/changesets/changesets/issues/1011) in changesets causes packages depending on others in the monorepo through peer dependencies to cause a major update on the upstream package. This is undesired in this scenario. Example:
design-system-components-angular has a patch update and is a peer dependency of the documentation. Because of that patch, the documentation has a major version bump for this release, even if there are no breaking changes.

Superseded by https://github.com/swisspost/design-system/pull/3009


Series/Movie toggle

A toggle that enables you to switch from movie engines to series engines. When clicked, engine dropdowns should only have the relevant engines e.g when toggled to series, only tvseries should be in the dropdown

Won't be working on this for now due to the tour feature


make MiqAeObject a node and delete MiqAeDigraph

MiqAeDigraph essentially kept a one to one mapping between a Node object and a MiqAeObject object.  If we move the parent and child pointers to the MiqAeObject class, and directly consult the object for it's parents and children, then we can remove the MiqAeDigraph class.
Benefits of this PR include cutting object allocations in half (we only
need to allocate one object, the MiqAeObject rather than both an
MiqAeObject and a MiqAeDigraph::Node), fewer method calls, and we can
delete code.
/cc @mkanoor @Fryguy

:heart_eyes:

@tenderlove were there tests for this that need to be migrated/deleted since we now cut out the digraph layer?

@jrafanie there were no tests that directly tested the digraph class.  We did have tests for MiqAeWorkspace (which used the graph), and they pass.

cc @chessbyte

@tenderlove you can get rid of the rubocop warning by wrapping the assignment in the conditional in parens.

I think we have code to serialize a workspace...we should probably verify that... @gmcculloug @mkanoor ?

I'm not really a fan of fighting with Rubocop.  :(
Is there a way I can run it before I commit?  Similar to javac? :trollface:

Yes, @tenderlove. Check out the manageiq guides repo. We have a .rubocop.yml for our guidelines. You can gem install rubocop and have the yml in your manageiq checkout and run it against the changed files. I'm sure you can configure vim to auto run it on your open file.

@tenderlove @chessbyte @gmcculloug @Fryguy @jrafanie
The Automate model is controlled by what users build, at runtime we resolve the class model and execute methods as needed by the different instances in the model. The end result of all of this is a directed graph, so removing the notion of a directed graph and making it a simple hierarchical tree might be overly optimizing the code. My recommendation would be to leave the digraph the way it is there since it would allow us to improve upon it instead of removing it completely.

The end result of all of this is a directed graph, so removing the notion of a directed graph

I'm not removing the notion of a directed graph.  The MiqAeObject objects are nodes are the directed graph.  I'm removing the MiqAeDigraph class because it doesn't make sense.  Nodes linked together make a graph, not this class.  I proved that the class was keeping a 1 to 1 mapping between MiqAeObject and the Node class.  That means that MiqAeObjects are nodes.  Since that is the case, it means that the MiqAeDigraph is essentially a useless proxy object.

My recommendation would be to leave the digraph the way it is there since it would allow us to improve upon it instead of removing it completely.

I think we should only add improvements as we need them.  It doesn't make sense to carry around code for "what if" situations.

Sounds good.  This looks good to me.  Also, I spoke to @mkanoor about the changes, and he seemed good with it.  I think he was concerned this lost the concept of the graph, and didn't realize that the node themselves are the graph now (technically a tree, but we can make it a graph later if needed)

I think he was concerned this lost the concept of the graph, and didn't realize that the node themselves are the graph now (technically a tree, but we can make it a graph later if needed)

Makes sense.  It's really hard to explain on a PR, I think.  I will try to make better explanations in the future.  :(

@tenderlove @Fryguy @gmcculloug
Jason explained to me the changes I am ok with it


HTTP header parsing too "strict"?

Version of Beast
167
Problem
Some websites send an invalid HTTP header (in my case, a Set-Cookie header), which leads to request rejection by the parser.
For example, the response of a GET request to https://www.cryptopia.co.nz/signalr/negotiate (via HTTP/1.1) sends two wrongly-formatted cookies (according to the RFC): one having a \01 byte inside the cookie value and one with two \r\n bytes inside the cookie value.
The culprit is the basic_parser::parse_token_to_eol function that returns an error while parsing the \01 byte. (I don't know how it would parse the second cookie, if it returns an error or simply ignore the cookie with \r\n.)
While the problem comes from either the website or their CDN (Incapsula), I think there should be a way to deal with such a situation. Curl, WGet and web-browsers seem to ignore the \01 byte and treat the cookie with \r\n as 2 different headers.
Is there a way to make the parser less "strict" or to hook a user-defined function before parsing the header to rewrite the faulty header?
Steps necessary to reproduce the problem
curl  --http1.1 -D /tmp/header -vvv "https://www.cryptopia.co.nz/signalr/negotiate"
Then open /tmp/header with an hex editor and look for cookies ___utmva and ___utmvb.

Is there a way to make the parser less "strict" or to hook a user-defined function before parsing the header to rewrite the faulty header?

Kind of. You can filter the incoming data to strip out the \01 and replace the spurious \r\n with spaces. Here's an example of a stream filter:
https://github.com/boostorg/beast/blob/e23ecc8ac903b303b9d1a9824b97c092cb3c09bd/include/boost/beast/experimental/http/icy_stream.hpp#L23
I would be more than happy to answer questions about this code and help you get your filter working.

I found a bit overkill to define a full new Stream just to filter three bytes.
I was thinking of defining my own http::parser deriving from the http::response_parser and override the put method to filter there, but it fails at calling my method (I guess because put is not virtual, but not 100% sure).
So far here what I did (for my very specific case, I use a dynamic_body  and a flat_buffer):
class MyParser : public http::response_parser<boost::beast::http::dynamic_body> {
    using http::response_parser<boost::beast::http::dynamic_body>::parser;

public:
    std::size_t
    put(boost::asio::const_buffer const& buffer, boost::system::error_code& ec) override {
        BOOST_LOG_TRIVIAL(info) << buffer.data();
        return parser::put(buffer, ec);
    }
};

Another possibility that I want to explore before going the "Stream way" is to define my own buffer type, do you think it's possible?

override the put

That's not going to work for a few reasons. put is not virtual, and the stream algorithms see basic_parser&, not your derived class. This is by design.

I found a bit overkill to define a full new Stream

This is subjective. You should not be afraid of creating your own stream wrapper. It is straightforward, efficient, and easily tested in isolation. You don't even have to allocate memory like the icy_stream, since you can filter the mutable buffer sequence in-place.
As I said, if you go this route I am more than happy to help. In fact, you could submit it as an improvement, located in the <beast/experimental/http> directory.

I finally went the Stream way, which I still think is overkill: my version is mainly a copy/paste of the boost::asio::ssl::stream just to wrap the async_read_some method and add the filtering logic.
My version is available here for anyone who needs an example. Note that this has been tested with an SSL stream, both with https requests and wss.
Thanks for your help.

I took a look at your stream code. It isn't necessary to copy the entire interface of ssl::stream, you only need the read and write functions plus the accessors for the executor and next layer. This way, your wrapper can work for regular TCP/IP connections as well as SSL connections.
In your read_op, it is not necessary to use handler_ptr. This is because your operation has what we call a trivial state (cheap to move). You can move the members of the data struct directly into the read_op class. And you'll have to add the handler as a data member. It also appears that data::match is unused.

Thanks for the feedback! I am starting to wrap my head around the move notion in C++, so as you pointed out there are some inefficiencies in my code. I'll try to improve the code when I have the time.
Regarding your remark about not copying the entire interface, are you saying that I only need to copy the methods that the HTTP/WS layer might call? One of the advantage of copying everything (if I understood correctly boost asio/beast) is that I can directly call methods like async_shutdown() on my stream instead of calling explicitly next_layer().async_shutdown() (but I might be wrong if there is some kind of forwarding that I didn't see).


Rename Authentication template files

Related to https://github.com/rails/rails/pull/53103
Follow-up to rails/rails#53098
The corresponding commit in rails/rails nested the template files (including the view templates) under an app/ directory.
This commit makes a corresponding change, nesting the views/ templates under app/views/.

@guilleiguaran What's your plan for making sure this is backwards compatible with Rails 8 beta1? Currently this change breaks with Rails 8 beta1, which means I can't cut a release of this gem until there's a beta2 with the above change.

@flavorjones we can revert this and cut the release of the gem and then re-apply to ensure this is in place for the beta2 compatible release.

I'll figure it out.

See https://github.com/rails/tailwindcss-rails/pull/408 and https://github.com/rails/tailwindcss-rails/pull/409


Documentation

ok... uh everyone update your block comments from the start of the year!
Cool, then:

[ ] Vision documentation overview (show how we implemented it)
[X] RPM documentation

Got RPM docs

[ ] hi

Vision is currently being held off in favour of glowworm

Vision is currently being held off in favour of glowworm

I think this is safe to close now


Unable to preventDefault inside passive event listener

The latest version of Chrome throws the following error with the Zoom component:
[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/6662647093133312

Ah yes, this is a fun one. Will get this fixed in a non-breaking way (hopefully).
related

https://developers.google.com/web/updates/2019/02/scrolling-intervention
https://github.com/facebook/react/issues/14856
https://github.com/facebook/react/issues/6436

Thanks for your quick response @hshoff!
Wondering if you have any thoughts on how to implement pinch-to-zoom using a trackpad for the zoom component. I could post this in a separate issue if it's unrelated.


icon anchor

Is there is any way to define the icon anchor as stated in Mapbox SDK?

Interesting. Can you please add links to the sdks?

Android
https://www.mapbox.com/help/android-markers/
IOS
https://www.mapbox.com/ios-sdk/examples/marker-image/ (here it is called
center offset)
2017-07-31 18:48 GMT+02:00 Eddy Verbruggen<EMAIL_ADDRESS>
Interesting. Can you please add links to the sdks?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/EddyVerbruggen/nativescript-mapbox/issues/151#issuecomment-319129501,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMmIGZ09z4VN-UAHcbvJlKHxDGB4W-5jks5sTgV4gaJpZM4OoVNk
.


MinGW warning: incompatible pointer type

Building 3.1.8, this is with both GCC 13.1.0 on MSYS2 UCRT64/MINGW64/MINGW32 and Clang 16.0.4 on CLANG64/CLANG32:
C:/_/B/src/openexr-3.1.8/src/lib/OpenEXRCore/internal_dwa_compressor.h: In function 'exr_compress_buffer':
  C:/_/B/src/openexr-3.1.8/src/lib/OpenEXRCore/internal_dwa_compressor.h:57:21: warning: passing argument 2 of 'compress2' from incompatible pointer type [-Wincompatible-pointer-types]
     57 |                     &compbufsz,
        |                     ^~~~~~~~~~
        |                     |
        |                     size_t * {aka long long unsigned int *}
  In file included from D:/M/msys64/mingw64/include/zlib.h:34,
                   from C:/_/B/src/openexr-3.1.8/src/lib/OpenEXRCore/internal_dwa.c:117:
  D:/M/msys64/mingw64/include/zlib.h:1244:31: note: expected 'uLongf *' {aka 'long unsigned int *'} but argument is of type 'size_t *' {aka 'long long unsigned int *'}
   1244 | ZEXTERN int ZEXPORT compress2 OF((Bytef *dest,   uLongf *destLen,
        |                               ^~

same issue also in openexr-3.1.8/src/lib/OpenEXRCore/internal_zip.c:
/home/claude/win/posix/x86_64/src/openexr-3.1.8/src/lib/OpenEXRCore/internal_zip.c: In function ‘apply_zip_impl’:
/home/claude/win/posix/x86_64/src/openexr-3.1.8/src/lib/OpenEXRCore/internal_zip.c:365:21: warning: passing argument 2 of ‘compress2’ from incompatible pointer type [-Wincompatible-pointer-types]
  365 |                     &compbufsz,
      |                     ^~~~~~~~~~
      |                     |
      |                     size_t * {aka long long unsigned int *}
In file included from /home/claude/win/posix/x86_64/include/zlib.h:34,
                 from /home/claude/win/posix/x86_64/src/openexr-3.1.8/src/lib/OpenEXRCore/internal_zip.c:15:
/home/claude/win/posix/x86_64/include/zlib.h:1244:31: note: expected ‘uLongf *’ {aka ‘long unsigned int *’} but argument is of type ‘size_t *’ {aka ‘long long unsigned int *’}
 1244 | ZEXTERN int ZEXPORT compress2 OF((Bytef *dest,   uLongf *destLen,
      |                               ^~

This patch seems to fix the warning.  Seems there would be problems (in many places, not just here) with buffers >= 4GiB in size (the uLong limit), but I don't know how likely that is to occur in real life.
--- a/openexr-3.1.8.old/src/lib/OpenEXRCore/internal_dwa_compressor.h
+++ b/openexr-3.1.8/src/lib/OpenEXRCore/internal_dwa_compressor.h
@@ -41,7 +41,7 @@ static exr_result_t exr_compress_buffer (
     size_t out_bytes_avail,
     size_t *actual_out )
 {
-    size_t         compbufsz;
+    uLong          compbufsz;

     if (level < 0)
     {
diff --git a/openexr-3.1.8.old/src/lib/OpenEXRCore/internal_zip.c b/openexr-3.1.8/src/lib/OpenEXRCore/internal_zip.c
index f3980ae..68cc6f3 100644
--- a/openexr-3.1.8.old/src/lib/OpenEXRCore/internal_zip.c
+++ b/openexr-3.1.8/src/lib/OpenEXRCore/internal_zip.c
@@ -347,7 +347,7 @@ static exr_result_t
 apply_zip_impl (exr_encode_pipeline_t* encode)
 {
     int            level;
-    size_t         compbufsz;
+    uLong          compbufsz;
     exr_result_t   rv;

     rv = exr_get_zip_compression_level (

@kmilos and @claudeha, could you possibly try your build again against the main branch? The underlying code has changed and hopefully the compilation no longer fails, but I'd like to confirm.

Confirming the main branch at commit c9b6b73e no longer issues this warning w/ GCC 13.1.0 on MSYS2 UCRT64.
The only warning left (as expected?) is the deprecated Imf_3_2::dwaCompressionLevelAttribute()

Confirming main branch no longer has this warning for me.
Host is Debian Bookworm compiling with MINGW mingw-w64 10.0.0-3
(x86_64-w64-mingw32-g++ (GCC) 12-posix).


Fix UG inconsistencies found during peer review

Fixes #346
Fixes #350

Codecov Report

Merging #341 (354254b) into master (c39687d) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #341   +/-   ##
=========================================
  Coverage     71.28%   71.28%
  Complexity      695      695
=========================================
  Files           128      128
  Lines          2302     2302
  Branches        258      258
=========================================
  Hits           1641     1641
  Misses          548      548
  Partials        113      113

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Thanks for this reference, closing now :).