Add Homebrew distribution

Hi David,
it might be interesting to add the homebrew distribution channel of the binaries so people could easily install it via brew install markdownlint-cli2 command.
Kind regards

I'm not a Homebrew user/believer, so this is not particularly appealing to me.
See this issue for a discussion of the topic which seems very relevant here: https://github.com/igorshubovych/markdownlint-cli/issues/111
One thing that may be new is GitHub Actions to do the update: https://github.com/marketplace?type=actions&query=Homebrew+

Note to anyone reading: I'm unlikely to make this change myself, but if someone wants to do so and implements it in a way that it's fully automated (perhaps via GitHub Action), I'm open to accepting their PR. The solution should be simple, reliable, and easy to understand - I don't want to have to become a Homebrew expert to fix this if it breaks. 😄

markdownlint-cli2 is now available in brew via https://github.com/Homebrew/homebrew-core/commit/41a41a38044b7ad8bb0efa96bf01533c8433e3f6
I'll look at some further automation around this but I suspect the bump bot may pick it up automagically.


Set project name with CLI

Problem description
Project info can be set from CLI like this:
project description set
except for name. It would be useful to include 'name' in this also:
project name set  "myProject"

This is an obvious next addition! Contributions are welcome!

May I try this one? Is the idea that there would be two commands, one to set the name and one to get it, like:
pixi project name get

pixi project name set <name>

Hi @LiamConnors,
Yes, I would have done that! Please give it a go!

Closing as done!


Docs: explain the algorithm behind global enumeration

Hey Vlad, hope all is good on your end. Are you planning to document these issues? Wondering how you solved the global secondary index including tradeoff analysis - for example, how easy and efficient is to replay the entire global stream, if some kind of filtering is allowed, assigning global index on original commits vs using streams/lambda to do it asynchronously, etc. Thanks!


Different colours for selected and activated annotations is confusing (and not consistently implemented)

It is hard to understand which coulour means what. In the end it confuses more than it helps. I suggest we only use the old version of highlighting active annotations and ged rid of the new one.
Here's whats not consistent:

Single click= red
Double click = red & Playhead jump to this position (correct would be YELLOW)
Single click > double click on the same annotation = yellow & Playhead jump to this position

The selected annotation should always be red IMO. Otherwise there is no way to tell whether it is selected or even whether there is an active selection at all. Of course if it is red, you can't see whether it is active, but that information is readable elsewhere: You can visually see whether the playhead intersects the annotation or not.
The reason I implemented this distinction is that the concept of the selection and the "active" annotations are not the same. They don't behave the same when you interact with them, etc., so I don't think they should look the same.
We could think about using different means of distinguishing them, so both statuses can be visible at the same time, though, instead of just the inner shadow color. Maybe an inner vs. outer shadow?

I agree: The selected annotation should always be red. But then the colors should be the other way around: Selected = yellow; Active = red
But I do not see the need for this distinction between selected and activated annotations. Reasons:

Mainly because a user does not understand it right away what this different colors mean.
If I select an annotation via single click and then the play head runs over it, I expect that it changes its color (at the moment from red to yellow), because now it is not only selected but also active. But it does not.
I do see no need to differentiate between direct double click (at the moment = red)  and double click after a single click (at the moment = yellow).

So please, get rid of the distinction.

The most important thing for the user is to get indicated where he/she should look at or is working on. For this reason the one color is enough.

I agree: The selected annotation should always be red. But then the colors should be the other way around: Selected = yellow; Active = red

Okay, we can discuss the colors, I don't have any hard opinion on the specifics, but I do think that the selection color should be more noticeable than the activation color, hence the current choice.

But I do not see the need for this distinction between selected and activated annotations. Reasons:

Mainly because a user does not understand it right away what this different colors mean.

I think the old behavior is more confusing. For example: It is not possible to "unactivate" an annotation by clicking it, but you can unselect a selected one. And in general in your scenario, clicking on some red annotations would behave different from clicking on others.

If I select an annotation via single click and then the play head runs over it, I expect that it changes its color (at the moment from red to yellow), because now it is not only selected but also active. But it does not.

But that doesn't happen when everything is red, either. And moreover, when the play head leaves the selected annotation behind, you are left wondering why it is still red, because you might not know for sure that it is selected. :thinking: But okay I will grant you the point that this is somewhat unexpected and my solution would be to introduce another "discriminator" beside the inner shadow color.

I do see no need to differentiate between direct double click (at the moment = red)  and double click after a single click (at the moment = yellow).

When you double click a selected annotation, it gets unselected and the playehad jumps to it. I admit that I don't like that behavior, but it is a combination of constraints coming from the timeline library and the fact that I wanted to retain the ability to unselect annotations by clicking on them again. So a double click on an annotation is basically like a single click now, but it also moves the playhead.
The alternatives to that, as far as I see it, are to

not make clicking a selected annotation unselect it

but then there is no way to unselect an annotation in the list view

just handle every click individually as before

that would mean that double clicking a selected annotation would unselect it and select it again, but more annoyingly, double clicking an unselected annotation would select it, then unselect it again and placing the playhead there.

But I digress. The color change you describe is due to this behavior. You double click a selected annotation -> The playhead gets placed there so it is now active -> it is unselected.
Without the distinction, that annotation would still be red, but unselected now, which I still find very confusing.

So please, get rid of the distinction.

To be honest, I would really rather not. We can talk about the specifics, but reverting to the previous behavior is not really an option. Both, because I don't want, but also for some technical reasons: Implementing the double click behavior was only possible in a clean way by fixing some bugs in the old selection code. Some of the weirdness I mentioned below your first point are actually a result of these changes, but they are arguably the more correct behavior, because for example previously, the tool couldn't even distinguish between selected and active annotations reliably internally, and so you could unselect active annotations although they should actually still be active. That could throw off the "automatic opening and closing of active annotations" sometimes and stuff like that.
The internal distinction is actually on my TODO list for a long time now, and it was necessary for something that you wanted. The visual distinction is not something that you wanted, I get that, but it was also just a less than 5 minute change, that I made because I think it is the right thing to do for the project. :thinking:

Our top priority should be the behavior a user expects. I think we should quickly discuss this thoroughly in an online meeting. Do you have time today? I do, expect from 3-4pm.
See some remarks below.

But I do not see the need for this distinction between selected and activated annotations. Reasons:

Mainly because a user does not understand it right away what this different colors mean.

I think the old behavior is more confusing. For example: It is not possible to "unactivate" an annotation by clicking it, but you can unselect a selected one. And in general in your scenario, clicking on some red annotations would behave different from clicking on others.

Your example is perfectly possible with the old bevahior: I can make the red frame of an active annotation disappear by clicking on it.

If I select an annotation via single click and then the play head runs over it, I expect that it changes its color (at the moment from red to yellow), because now it is not only selected but also active. But it does not.

But that doesn't happen when everything is red, either. And moreover, when the play head leaves the selected annotation behind, you are left wondering why it is still red, because you might not know for sure that it is selected. 🤔 But okay I will grant you the point that this is somewhat unexpected and my solution would be to introduce another "discriminator" beside the inner shadow color.

Yes, it does not change the color when everything is red. That's exactly what I want.
Tor your "moreover": I prefer living with selected annotations not getting "unframed" when the play head leaves the selected annotation behind than with all the other unexpected stuff.

I do see no need to differentiate between direct double click (at the moment = red)  and double click after a single click (at the moment = yellow).

When you double click a selected annotation, it gets unselected and the playehad jumps to it. I admit that I don't like that behavior, but it is a combination of constraints coming from the timeline library and the fact that I wanted to retain the ability to unselect annotations by clicking on them again. So a double click on an annotation is basically like a single click now, but it also moves the playhead.

As a user I do not expect an annotation to be unselected when double clicking on it. So it would be an advantage if selecting and activating have the same color: The users does not get confused.

The internal distinction is actually on my TODO list for a long time now, and it was necessary for something that you wanted. The visual distinction is not something that you wanted, I get that, but it was also just a less than 5 minute change, that I made because I think it is the right thing to do for the project. 🤔

We think (I discussed it with colleagues, so it's not only my opinion) it's not the right thing to do. And if it was less than 5 minute of change, please get rid of it an we can try how the user experience it.

But I digress. The color change you describe is due to this behavior. You double click a selected annotation -> The playhead gets placed there so it is now active -> it is unselected.
Without the distinction, that annotation would still be red, but unselected now, which I still find very confusing.

Yes, it is still red. But it is much less confusing than the different result of double clicking an annotation depending on its selection (selected or deselected).

To sum up again: The most important thing for the user is to get indicated where he/she should look at or is working on. The differentiation between selected and active is less important.
Important to now why I insist on the one color:

I didn't want the distinction between the two colors.
The reason why we implemented the distinction between single and double click (which made you introduce the two colors): the click-wideness of the red line covers the whole clickable region of newly inserted annotations. And this click-wideness of the red line you didn't not want to change.

Our top priority should be the behavior a user expects. I think we should quickly discuss this thoroughly in an online meeting. Do you have time today? I do, expect from 3-4pm.

We should discuss this and other things in a meeting, you will get an email from me. But I can't let some things just sit unanswered here, I'm sorry. :sweat_smile:

See some remarks below.

But I do not see the need for this distinction between selected and activated annotations. Reasons:

Mainly because a user does not understand it right away what this different colors mean.

I think the old behavior is more confusing. For example: It is not possible to "unactivate" an annotation by clicking it, but you can unselect a selected one. And in general in your scenario, clicking on some red annotations would behave different from clicking on others.

Your example is perfectly possible with the old bevahior: I can make the red frame of an active annotation disappear by clicking on it.

I know it's possible. What I'm saying is that that's a bug.

I do see no need to differentiate between direct double click (at the moment = red)  and double click after a single click (at the moment = yellow).

When you double click a selected annotation, it gets unselected and the playehad jumps to it. I admit that I don't like that behavior, but it is a combination of constraints coming from the timeline library and the fact that I wanted to retain the ability to unselect annotations by clicking on them again. So a double click on an annotation is basically like a single click now, but it also moves the playhead.

As a user I do not expect an annotation to be unselected when double clicking on it. So it would be an advantage if selecting and activating have the same color: The users does not get confused.

If you don't want double click to unselect, the color does not matter. If that behavior is to be kept for whatever reason, though, having the same color is the actual confusing part, because it suggests that the annotation is still selected but it is not.

The internal distinction is actually on my TODO list for a long time now, and it was necessary for something that you wanted. The visual distinction is not something that you wanted, I get that, but it was also just a less than 5 minute change, that I made because I think it is the right thing to do for the project. thinking

We think (I discussed it with colleagues, so it's not only my opinion) it's not the right thing to do. And if it was less than 5 minute of change, please get rid of it an we can try how the user experience it.

As the de facto maintainer of this open source project, I think I am allowed to make some decisions on my own. The 5 minute fact was only mentioned to suggest that you do not have to fear that you paid for it or anything, but that also means that the decision to revert that change or not is not yours alone. Should it be mine alone? Probably not; if I don't listen to the community at all, the project is basically doomed to die, but the same is true IMO if the maintainer just blindly follows every client wish.
And so I suggested a compromise, and I also discussed this with Rüdiger, who agrees with the reasonableness of my change and independently came up with a similar compromise. We can and should discuss this further in a proper meeting, though.

I am looking forward to the meeting. I'm shure we will find a decent compromise.
In my opinition we need to fix these two things when we decide to stick to the two colors:

The result of a double click (= annotation gets selected AND activated) must be independent of whether the annotation was already selected or not.
Selected AND active annotation must be specially marked. So both status must be visible at the same time (as you suggested above).

First of all, I think it's great that it is now possible to distinguish between active and selected annotations.
Although I have to agree that it can be confusing to have two colours which both are displayed as a frames around the annotation in the timeline. But, I also understand the need to distinguish between these two states. However, both states can also happen at the same time. A selected annotation can also be the active annotation which leads to the problem that it is not clear what should be displayed in that case. I suggest the following:

The selected annotation is framed in red.
The active annotation gets the inner shadow.
A selected annotation that is also active would thus have a red frame and an inner shadow.

I have to admit that this is not really easier to notice, as it is a detail, but it has the advantage of reducing the number of colours needed which makes it easier to understand for new users and experienced users are still able to distinguish between the different states.
This suggestion could then lead to the following behaviour:

When a user single clicks on a annotation, it gets the red frame.
When the playhead then moves to the selected annotation the inner shadow is added.
If the user now single clicks on the selected and active annotation the annotation is now longer selected and the red frame removed, but the inner shadow remains.
When the playhead leaves the annotation the inner shadow is also removed.

Lastly I have to agree that the result of a double click should be independent of the previous state of the double clicked annotation. It should always lead to the double clicked annotation being selected and active. (Simply because it makes no sense to me to keep another selected annotation if one wants to jump to a different annotation.)
I hope this helps.

When a free text annotations gets selected: Please make the grey strips slightly brighter as to improve contrast between the black text.

@dagraf

Now (the stripes actually being black with an opacity of 0.15)

Opacity 0.1

Opacity 0.05

One of those? Something in between? I prefer 1, but could live with 2 or something in between the two. I think 3. is too pale.
The problem I see with lower contrasts, even 2. already, is that the selection gets less noticeable for short annotations, where you really only get one line in, and it is probably covered by text. :thinking:

I would prefer 2, but can live with 1. Should we agree on something in between? Meaning an opacity of 0.125?
FYI: When opening the annotation tool on SWITCHcast-Staging (https://unibe-ch.annotate.cast-test.switch.ch/) the differentiation between active an selected annotations do not get shown anymore. Could you please take care that I can test your bugfixes?

I would prefer 2, but can live with 1. Should we agree on something in between? Meaning an opacity of 0.125?

Sounds fair :smile:

FYI: When opening the annotation tool on SWITCHcast-Staging (https://unibe-ch.annotate.cast-test.switch.ch/) the differentiation between active an selected annotations do not get shown anymore. It seems to me, that an older version of the annotation tool is running on cast-test.switch.ch. Could you please take care that I can test your bugfixes again?

Will do.

After having having seen it now on the timeline I would no also prefer 1 (opacity 0.15).
But we still have a contrast issue in the list of annotations (see screenshot). Could you make the text black and not grey?

@dagraf

?

Perfekt! Danke!

Looks and works fine. Thx!


Energy consumption of CPU is 0

Describe the bug
Checking "Pod Current Energy Consumption" on Grafana dashboard, CPU energy consumption of each pod is 0. Checking Prometheus, "pod_curr_energy_in_core_millijoule" of all pods are 0. "Total" and "DRAM" have data but "CPU" is 0.
The issue exists on both RHEL8.6 and Ubuntu 22.04 host.

@rootfs I have also seen this happening in recent commits, can this be related to #120, #150 and #156? I have lost track of changes made in the core energy department, but there has been some movement in this matter, no?
@ruomengh what CPU are you using? Maybe there is different handling of RAPL on various CPUs if some are not seeing this.

There are several nodes using different Intel CPUs in my cluster. All of them have the same issue after running for a while. When a new node just joined the cluster, it can show CPU energy.

I have seen one similar bug from a few months before, #96. @rootfs, how can we check if this is an instance of that?

Are you running Kepler in a Bare-metal node?
There some architecture that does not report the CPU core power...
For example the node that I have, I can only see the package power (i.e., CPU socket)
Can you run the following application in your node?
https://github.com/deater/uarch-configure/tree/master/rapl-read

@ruomengh if pod_curr_energy_in_core_millijoule has values and becomes 0 after a while, that could have a few possible reasons:

do you happen to see any value in pod_curr_energy_in_pkg_millijoule metrics?
the pod is not actively using cpu, so eBPF program cannot detect it. The metrics then turns to 0. To see if this is the case, can you find and kill the process (not delete the pod) in the container that has this problem?
there are some potential stat reading problem. Can you see if node_energy_stat metrics is there and node_curr_energy_in_pkg_joule in that metrics is non-zero?
can you turn on verbosity and redeploy kepler so we can see the logs? e.g. set v=5 here

Can you check the pkg energy pod_curr_energy_in_pkg_millijoule  and check if there are any readings there?

Both through metrics and directly in Kepler verbose log, I can see that the package and DRAM energies are reported as nonzero, while eCore stays 0. Sample log parts:
I1014 07:23:47.547824       1 node_energy.go:95] node energy stat core 0 (0) dram 58632 (47861778) uncore 0 (0) pkg 559072 (354463555)
gpu 0 sensor 0 (0)

I1014 07:23:47.547993       1 reader.go:362] energy from pod (1 processes): name: console-dd56f49d4-qzm78 namespace: openshift-console
        cgrouppid: 0 pid: 13172 comm: bridge
        ePkg (mJ): 9809 (4859081) (eCore: 0 (0) eDram: 1029 (516579) eUncore: 0 (0)) eGPU (mJ): 0 (0) eOther (mJ): 0 (0)

Both node_curr_energy_in_pkg_joule and node_energy_stat seem to work properly.

thank you @Feelas so this is indeed a result of #150 and #156. We trust the pkg energy than the old way of deriving missing core energy (when core RAPL domain is missing)
@ruomengh can you check the pod_curr_energy_in_pkg_millijoule and node_curr_energy_in_pkg_joule on your setup?

node_curr_energy_in_pkg_joule{container="kepler-exporter",` endpoint="http", exported_instance="css-dev-ken", instance="css-dev-ken", job="kepler-exporter", namespace="kepler", pod="kepler-exporter-8swnk", service="kepler-exporter"}
pod_curr_energy_in_pkg_millijoule{command="adapter", container="kepler-exporter", endpoint="http", instance="css-dev-ken", job="kepler-exporter", namespace="kepler", pod="kepler-exporter-8swnk", pod_name="prometheus-adapter-678b454b8b-vt7mp", pod_namespace="monitoring", service="kepler-exporter"}

Can you check the pkg energy pod_curr_energy_in_pkg_millijoule  and check if there are any readings there?

Both through metrics and directly in Kepler verbose log, I can see that the package and DRAM energies are reported as nonzero, while eCore stays 0. Sample log parts:
I1014 07:23:47.547824       1 node_energy.go:95] node energy stat core 0 (0) dram 58632 (47861778) uncore 0 (0) pkg 559072 (354463555)
gpu 0 sensor 0 (0)

I1014 07:23:47.547993       1 reader.go:362] energy from pod (1 processes): name: console-dd56f49d4-qzm78 namespace: openshift-console
        cgrouppid: 0 pid: 13172 comm: bridge
        ePkg (mJ): 9809 (4859081) (eCore: 0 (0) eDram: 1029 (516579) eUncore: 0 (0)) eGPU (mJ): 0 (0) eOther (mJ): 0 (0)

Both node_curr_energy_in_pkg_joule and node_energy_stat seem to work properly.

@ruomengh @Feelas if pod_curr_energy_in_core_millijoule has values and becomes 0 after a while, that could have a few possible reasons:

do you happen to see any value in pod_curr_energy_in_pkg_millijoule metrics?
the pod is not actively using cpu, so eBPF program cannot detect it. The metrics then turns to 0. To see if this is the case, can you find and kill the process (not delete the pod) in the container that has this problem?
there are some potential stat reading problem. Can you see if node_energy_stat metrics is there and node_curr_energy_in_pkg_joule in that metrics is non-zero?
can you turn on verbosity and redeploy kepler so we can see the logs? e.g. set v=5 here

@rootfs

pod_curr_energy_in_pkg_millijoule has values for all pods
node_curr_energy_in_pkg_joule is not 0, but node_energy_stat is 0

pod_curr_energy_in_pkg_millijoule has values for all pods

This is good, it means that the pod energy consumption is being calculated

node_curr_energy_in_pkg_joule is not 0

This metric node_curr_energy_in_pkg_joule is used to calculate the pod_curr_energy_in_pkg_millijoule

RAPL can expose the power consumption of CORE, UNCORE, PKG, DRAM or PLATFORM
However, not all systems expose all these metrics.
And most likely your system only has CORE and DRAM!
So that's why you can't see pod_curr_energy_in_core_millijoule, but you can see pod_curr_energy_in_pkg_millijoule...
Note that package means socket in intel RAPL terminology...

There are some works that use pkg instead of core, when the later is not available.... But pkg is not the core, it has many more components involved. We decided to make it transparent to the user...
I understand it should be better documented, but this is not a bug, it's how the system should be working...

Yes, RAPL package measures the energy consumption of the entire socket. It includes the consumption of all the cores, integrated graphics and also the uncore components. If CPU is the only thing of concern for Kepler for now, it makes sense to display core other than pkg. No matter cpu or pkg is exposed to users, cpu = 0 looks like a bug to me.
Besides, the issue doesn't exist on all nodes. I have a node which just joined the cluster, pod CPU consumption on this node are not 0.

RAPL package measures the energy consumption of the entire socket. It includes the consumption of all the cores, integrated graphics and also the uncore components

Right, we cannot use this as the CORE energy...

No matter cpu or pkg is exposed to users, cpu = 0 looks like a bug to me.

We could disable the core energy if it is not possible to export....but missing metrics will also looks like a bug....
Anyway, I think that as far as it will be well documented, this should not be a big concern....

@marceloamaral good analysis!
@ruomengh would you like to post a documentation PR on this issue? Thanks!

there is a trouble shooting guide in doc that covers this case, we can close this issue now.


[Impeller] rrect blur has weird artifacts sometimes

reproduction
TEST_P(DlGoldenTest, LargeDownscaleRrect) {
  impeller::Point content_scale = GetContentScale();
  auto draw = [&](DlCanvas* canvas, const std::vector<sk_sp<DlImage>>& images) {
    canvas->Scale(content_scale.x, content_scale.y);
    DlPaint paint;
    paint.setColor(DlColor::kYellow());
    paint.setMaskFilter(
        DlBlurMaskFilter::Make(DlBlurStyle::kNormal, /*sigma=*/10));
    canvas->DrawCircle(SkPoint::Make(0, 0), 500, paint);
  };

  DisplayListBuilder builder;
  draw(&builder, /*images=*/{});

  ASSERT_TRUE(OpenPlaygroundHere(builder.Build()));
}

observed output

@gaaclarke what is the scaling factor here? Does this look weird at regular scales, or is this a "galaxy" scale issue?

@gaaclarke what is the scaling factor here? Does this look weird at regular scales, or is this a "galaxy" scale issue?

The scaling factor isn't big, it would just be the 2x from content_scale.x.

@flar have you seen this before?  Any theories?

I remember having seen banding like that. When I looked at the math of the fast blurs I believed that it was due to the way the minimal number of bands being averaged were chosen.
I don't think the squircle solutions suffer from this effect because they provide a more continuous answer.

fixed in https://github.com/flutter/engine/pull/55604


SubscriptionChange does not have typescript interface

await serverClient.createWebhook({
      Url: `https://webhook.com`,
      MessageStream: 'newsletter',
      Triggers: {
        Delivery: {
          Enabled: true,
        },
        Bounce: {
          Enabled: true,
          IncludeContent: false,
        },
        SpamComplaint: {
          Enabled: true,
          IncludeContent: false,
        },
        Open: {
          Enabled: true,
          PostFirstOpenOnly: true,
        },
        Click: {
          Enabled: true,
        },
        // @ts-ignore
        SubscriptionChange: {
          Enabled: true,
        },
      },
    })

The SubscriptionChange does not have a typescript interface and prompts linter error.
However, the webhook is created with subscription change enabled.

Thanks @ciocan
sorry for late response, will see to check this out soon

We have fixed this issue in version 2.7.6


InAppWebView failed to record audio on the Windows platform. Is it not supported?

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
No audio stream has been captured.
In the script, The AudioContext, getUserMedia, createMediaStreamSource, and createScriptProcessor have all been successfully called.
When microphone function is opened, the headphones can already hear a "rustling" sound of electric current (which disappears when the microphone is stopped, so the microphone is confirmed to be properly opened).
However, the scriptProcessor.onaudioprocess() callback is not executed. So cannot capture the audio stream.
I confirmed that permissions are enabled. The same code runs normally on macOS and Android.
Expected Behavior
The callback code in scriptProcessor.onaudioprocess() should be executed, and audio stream is captured
Steps with code example to reproduce
const constraints = {
    audio: {
      sampleRate: 24000,
      channelCount: 1,
      echoCancellation: true,
      noiseSuppression: true
  }
};

stream = await navigator.mediaDevices.getUserMedia(constraints);
audioContext = new (window.AudioContext || window.webkitAudioContext)({
  sampleRate: 24000,
});

audioInput = audioContext.createMediaStreamSource(stream);
scriptProcessor = audioContext.createScriptProcessor(4096, 1, 1);

scriptProcessor.onaudioprocess = function(audioProcessingEvent) {
  const inputBuffer = audioProcessingEvent.inputBuffer;
  // Some other codes...
  window.flutter_inappwebview.callHandler('onAudioData', pcmData);
};

audioInput.connect(scriptProcessor);
scriptProcessor.connect(audioContext.destination);

Stacktrace/Logs

Stacktrace/Logs
<Replace this line by pasting your stacktrace or logs here>

Flutter version
v3.24.0
Operating System, Device-specific and/or Tool
Windows 11 with VS code 2022
macOS 15.1.1 with Xcode 16.1
Plugin version
v6.1.0, v6.1.5
Additional information
No response
Self grab

[ ] I'm ready to work on this issue!

It seems that the scriptProcessor.onaudioprocess event is Deprecated, check for more details and alternatives on the official js docs: https://developer.mozilla.org/en-US/docs/Web/API/ScriptProcessorNode/audioprocess_event

Check also this answer on StackOverflow for other possible examples: https://stackoverflow.com/questions/65447236/scriptnode-onaudioprocess-is-deprecated-any-alternative

It seems that the scriptProcessor.onaudioprocess event is Deprecated, check for more details and alternatives on the official js docs: https://developer.mozilla.org/en-US/docs/Web/API/ScriptProcessorNode/audioprocess_event

I've tried using AudioWorklet to capture audio stream, but it seems it's not supported: AbortError: Unable to load a worklet's module

It seems that the scriptProcessor.onaudioprocess event is Deprecated, check for more details and alternatives on the official js docs: https://developer.mozilla.org/en-US/docs/Web/API/ScriptProcessorNode/audioprocess_event

I've tried using AudioWorklet to capture audio stream, but it seems it's not supported: AbortError: Unable to load a worklet's module

I have solved this problem, the audioContext.state is suspended by default. Call audioContext.resume() and it is OK now


react/jsx-no-target-blank not working as expected on conditionals

Code
const openInNewTab = true; // could be true or false

export default function App() {
  return (
    <a
      href="https://google.com"
      target={openInNewTab ? "_blank" : "self"}
      rel={openInNewTab ? "noreferrer" : undefined}
    >
      Open Google
    </a>
  );
}

Currently what's happening
If I pass target='_blank' based on some condition as shown in the above snippet, and pass rel='noreferrer' on same condition. It is still showing me warning/error as per the config.
What should happen?
Ideally if the condition is same for both the props it should recognise it and should not give us warning/error.
Please let me know if I am missing something?
Reference:
Sample Codesandbox - https://codesandbox.io/s/mystifying-lake-l0420z?file=/src/App.js

I agree, this would be a good enhancement to add. This seems highly similar to #2748, in case anyone wants to tackle it.


parse config before postprocess

This is just to demonstrate how to post process the config dict given multiple entities.

I think it's a good approach to expose the dict and being able to do post processing on it.
The changes being made for this look all good.

Great, I merged it in already now.


[SPARK-12630][Python][MLlib][DOC] Update param descriptions

Updates the param descriptions in python mllib scripts to be consistent. See [SPARK-11219] for more
details.

Can one of the admins verify this patch?

thanks @vijaykiran!  I marked a few things for correction and I think in general we should extend the comments to the 100 character limit where applicable.

@BryanCutler  Thanks for the review, I added a new commit - will review update other two PRs with 100 fill-column as well.

LGTM.  It's not necessary to squash commits, but could you update the PR title/description to indicate that this is for PySpark MLlib classification?
ping @jkbradley @mengxr

I just added a note to the parent JIRA about a formatting issue affecting all 5 PRs: [https://issues.apache.org/jira/browse/SPARK-11219?focusedCommentId=15090225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15090225]
Could you please check it out & ping when I should review again?  Thank you!

Hi @vijaykiran , will you be able to update the param descriptions to be only up to 74 character limit?  Sorry for the mixup, but I think this should be mergable after that.

ping @BryanCutler - Updated the param descriptions, can you take a look ?

I viewed in pydoc with a window size of 80 and LGTM, cc @jkbradley to take a look.  Thanks @vijaykiran!

@vijaykiran , I missed one line that is a bit too long, could you please fix that, otherwise LGTM

ping @BryanCutler @jkbradley - can you guys please take a look again?

LGTM

@vijaykiran @BryanCutler Please run make html under python/docs and check the warning messages. This is what I got:
/Users/meng/src/spark/python/pyspark/mllib/classification.py:docstring of pyspark.mllib.classification.LogisticRegressionWithSGD.train:23: ERROR: Unexpected indentation.
/Users/meng/src/spark/python/pyspark/mllib/classification.py:docstring of pyspark.mllib.classification.LogisticRegressionWithSGD.train:26: WARNING: Block quote ends without a blank line; unexpected unindent.
/Users/meng/src/spark/python/pyspark/mllib/classification.py:docstring of pyspark.mllib.classification.LogisticRegressionWithLBFGS.train:17: ERROR: Unexpected indentation.
/Users/meng/src/spark/python/pyspark/mllib/classification.py:docstring of pyspark.mllib.classification.LogisticRegressionWithLBFGS.train:20: WARNING: Block quote ends without a blank line; unexpected unindent.
/Users/meng/src/spark/python/pyspark/mllib/classification.py:docstring of pyspark.mllib.classification.SVMWithSGD.train:23: ERROR: Unexpected indentation.
/Users/meng/src/spark/python/pyspark/mllib/classification.py:docstring of pyspark.mllib.classification.SVMWithSGD.train:26: WARNING: Block quote ends without a blank line; unexpected unindent.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.LinearRegressionWithSGD:3: ERROR: Unexpected indentation.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.LinearRegressionWithSGD:4: WARNING: Block quote ends without a blank line; unexpected unindent.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.RidgeRegressionWithSGD:3: ERROR: Unexpected indentation.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.RidgeRegressionWithSGD:4: WARNING: Block quote ends without a blank line; unexpected unindent.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.LassoWithSGD:3: ERROR: Unexpected indentation.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.LassoWithSGD:4: WARNING: Block quote ends without a blank line; unexpected unindent.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.IsotonicRegression:7: ERROR: Unexpected indentation.
/Users/meng/src/spark/python/pyspark/mllib/regression.py:docstring of pyspark.mllib.regression.IsotonicRegression:12: ERROR: Unexpected indentation.

@mengxr thanks, will take a look today

@vijaykiran Thanks! Please ignore the warnings from regression.py. That will be addressed in https://issues.apache.org/jira/browse/SPARK-12986.

ok to test

Test build #50152 has started for PR 10598 at commit bf8f8a0.

Test build #50152 has finished for PR 10598 at commit bf8f8a0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50152/
Test PASSed.

@vijaykiran Could you fix the doc warnings in classification.py? Thanks!

Thanks for working on this @vijaykiran , I finished up the remaining fix in https://github.com/apache/spark/pull/11183 so please close this one up.
cc @mengxr

@vijaykiran I merged #11183 into master. Do you mind closing this PR? Thanks!


YustTextField showSelected not consistent

The property 'showSelected' in the class YustTextField should also affect icons if set to false. If set to true, it currently affects only the properties 'label' and 'prefixIcon'.

We do not need the property showSelected.


Fix for: Exception Livewire Calendar not correctly configured. Check initial inputs.

There was an error when changing month in certain circumstances, see: asantibanez/livewire-calendar#22
I used the code others did to fix it, thanks for their input.
Specifically this commit from @nohumans https://github.com/nohumans/livewire-calendar/commit/dd6841d385815c0ad1a0a5df611fb2e16644adc3

Why is this pull request not merged?
The mentioned error is occurring again switching from October to November.

@maatien I think they fixed this here: 31d01a4a31ae7b3c6039936d881b5d81df612457
Personally I made a fork at the time and I just use that.

@chris-arated thanks for hint, unfortunately, the error appears again. I'll open a new issue for this.


Add a new dataset list page

Add a page to list all the datasets with links to their folder in GitHub repo.
mkdocs somehow cannot convert each dataset's README.md to webpage. We need better design for this page.

Hmm,  GitHub seems not running.


Desktop app for Mac crash when running packaged app

I made Compose Desktop application, but it keeps immediately closing after startup of the App inside dmg.
runDistributable - successfully run the App.
I've tried to run it from Terminal:
 ./MyApp.app/Contents/MacOS/MyApp and it shows error:
"Error opening "/PathToApp/MyApp.app/Contents/Contents/app/MyApp.cfg" file: No such file or directory" - I was surprised by the duplication of Contents directory.
When I moved MyApp.app/Contents/MacOS/MyApp to MyApp.app/Contents/MyApp and run it from Terminal - it successfully started.
I am using:

compose 0.4.0
kotlin 1.5.10
java 15.0.2

@imptah can you share a sample reproducible project?

ComposeBug.zip
Here is reproducer from https://github.com/JetBrains/compose-jb/issues/928 (looks like the same issue)

@imptah can you share a sample reproducible project?

Sorry for the long reply. I have figured out the issue. It was related to the creation of the new files inside the packaged App. After switching off logging and making the database work in memory, the App successfully started.
Here is the sample that reproduces it. It's just a template App with the creation of a File in fun main(). If you run packaged App in .dmg, it will close immediately. If you do runDistributable, it will create the file and run the App.
Maybe it is somehow related to the permissions inside the MacOS ecosystem? Do you have any ideas on how it can be fixed?
Uploading NewFileError.zip…

Reproduced with v1.0.0-alpha3 as well

Issue still exists with 1.3.0. Mostly related to Mac Permissions

As @anikrajc mentioned. The issue still exists.
I'm using SqlDelight with KMM project. The packaged app fails when start the application from generated *.app file (packageDMG). But if I start the app from Contents/MacOs/ it works. If I configure SqlDelight to use IN_MEMORY it works fine. It seems an issue with write permissions of the starting process.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Notebook: New Notebook from Cluster Manage sets the Kernel to Python 3 and Attach to is local host

Issue Type: Bug
Steps to reproduce:

Connect to a cluster
Go to Manage and click New Notebook or right click on the cluster and select New Notebook.
Right click on a CSV file HDFS and select Analyze in Notebook.

Actual:
Kernel is Python 3 and Attach to is localhost

Expected:
Kernel needs to be Pyspark 3 and Attach to needs to be the cluster.
Azure Data Studio version: Azure Data Studio 1.3.7-insider (5a3087859918b1564d2622b95defa662facdbef6, 2018-12-07T03:09:14.777Z)
OS version: Darwin x64 17.2.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz (8 x 2200)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: enabledrasterization: enabledvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 3

Memory (System)
16.00GB (2.06GB free)

Process Argv
/private/var/folders/d3/kw4dh3311gncx1kstyqss_hr0000gn/T/AppTranslocation/D64B6402-C693-45E6-8623-ED16F61E1EC3/d/Azure Data Studio.app/Contents/MacOS/Electron -psn_0_2802348

Screen Reader
no

VM
0%

Extensions (6)

Extension
Author (truncated)
Version

vscode-sanddance
dan
0.0.1

agent
Mic
0.35.1

import
Mic
0.4.2

profiler
Mic
0.5.1

sql-vnext
Mic
0.9.0

whoisactive
Mic
0.1.1

Just verified this is still happening in December release candidate. We'll take a look as this is definitely a regression.

Fixed


OCPEDGE-811: chore: dependency bumps for k8s 1.29

Depends on https://github.com/openshift/release/pull/47808 for go toolchain directive support in go.mod

/lgtm

/test all

/test unit-test

/test lvm-operator-e2e-aws-sno

/lgtm


Test flanky: Test Live Azure Images

Azure Live Image tests are still flanky and need to be fixed to ensure PR test results can always be trusted:
https://github.com/redhatcloudx/rhelocator/actions/runs/3820765256/attempts/1

Stability increased after switching to Azure enterprise account. Ticket is closed for now.


Fix #363 and fix #371

@axel-lauer Could you please test if this solves your issues?

I am also aware of these two issues, since we discussed them with @axel-lauer
I've tested this branch with lwp and swcre and in my opinion it solves both issues.


Programmatically find new version of EuroSciVoc

Determining the URL of the version latest version
Original versioned download link
Until now, we were using the following page:
https://op.europa.eu/en/web/eu-vocabularies/euroscivoc
Which has a "download" link which goes to the page:
https://op.europa.eu/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/euroscivoc

This page explicitly shows that the latest version is 1.5 and the RDF download link is:
https://op.europa.eu/o/opportal-service/euvoc-download-handler?cellarURI=http%3A%2F%2Fpublications.europa.eu%2Fresource%2Fdistribution%2Feuroscivoc%2F20241002-0%2Frdf%2Fskos_ap_eu%2FEuroSciVoc-skos-ap-eu.rdf&fileName=EuroSciVoc-skos-ap-eu.rdf
Other version-less download link
There is however another page which is similar to the HE download page, the H2020 download page and the FP7 download page.
It follows the same URL structure, with the slug name of the dataset in the URL.
The URL for this page is:
https://data.europa.eu/data/datasets/euroscivoc-the-european-science-vocabulary?locale=en

However this page wrongly states that it is version 1.3, while it is in fact the very latest version (version 1.5).
The direct link to download the vocabulary file is:
https://publications.europa.eu/resource/distribution/euroscivoc/rdf/skos_ap_eu/EuroSciVoc-skos-ap-eu.rdf
Verification that both files are the same
$ curl -o EuroSciVoc-skos-ap-eu-version-1.5.rdf "https://op.europa.eu/o/opportal-service/euvoc-download-handler?cellarURI=http%3A%2F%2Fpublications.europa.eu%2Fresource%2Fdistribution%2Feuroscivoc%2F20241002-0%2Frdf%2Fskos_ap_eu%2FEuroSciVoc-skos-ap-eu.rdf&fileName=EuroSciVoc-skos-ap-eu.rdf"

$ curl --location -o EuroSciVoc-skos-ap-eu-version-less.rdf "https://publications.europa.eu/resource/distribution/euroscivoc/rdf/skos_ap_eu/EuroSciVoc-skos-ap-eu.rdf"

$ md5sum EuroSciVoc-skos-ap-eu-version-*.rdf
63ab5d5269309e03dafd951388e37da1  EuroSciVoc-skos-ap-eu-version-1.5.rdf
63ab5d5269309e03dafd951388e37da1  EuroSciVoc-skos-ap-eu-version-less.rdf

Determining if a new file is available
One thing that could be done, but which is not required, would be to check if a new version of the file exist in order to not wastefully reimport the same vocabularies again.
Checking for new version via RSS
One way of determining if a new file exists is to use the dataset RSS feed URL:
https://data.europa.eu/api/hub/search/en/feeds/datasets/euroscivoc-the-european-science-vocabulary.rss
And to rely on rss.channel.pubDate:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<rss version="2.0">
    <channel>
        <pubDate>Fri, 25 Oct 2024 14:06:12 +0000</pubDate>
<!-- ... -->

Checking for new version via REST API
Another option is to use the dataset REST API URL:
https://data.europa.eu/api/hub/search/datasets/euroscivoc-the-european-science-vocabulary
And to rely on result.catalog_record.modified:
{
  "result": {
    "//": "...",
    "catalog_record": {
      "modified": "2024-06-11T16:10:39Z",
      "issued": "2021-12-03T11:44:39Z"
    },
    "//": "..."
  }
}

Note for Zenodo RDM: once EuroSciVoc v1.5 is imported, we should reimport H2020 and HE awards, and then reindex.


RainLoop Software License Agreement

What do you think about new license for standard edition (say goodbye to Creative Common).

LICENSE AGREEMENT
RainLoop Webmail (Standard edition) is released under RainLoop Software License
By using RainLoop Webmail (Standard edition), you confirm that you have read and agreed to this license agreement.

You may use the product on commercial websites by purchasing a commercial license (subscription).
A commercial website means:

any site which is built, owned or maintained by a profit-making person or organisation, even if the site does not generate revenue;
any site which generates revenue, even if it is otherwise non-commercial;
any government, government-agency or political-party websites.

You may use the product on non-commercial websites free of charge subject to the terms of this license.
A non-commercial website means:

personal or hobby sites which generate no revenue (whether from advertising, commissions, sales or any other source);
websites owned and maintained by charitable or not-for-profit organisations;

You must choose the appropriate license (subscription) for your needs:

Basic subscription (non-commercial websites).
Premium one year subscription (for single web domain).
Premium lifetime subscription (for single web domain).

The term "website" means a single website of a single person or organisation. (In most cases, that would be a single domain, although there could feasibly be multiple websites on a single domain e.g. through the use of subdomains). The website could be your own or a website you build/maintain for someone else.
You may not sell, redistribute or offer for download any of our products in any form or in any medium, whether original or modified or for profit or not.
You agree not to alter, remove or decode any of the source code without explicit written permission from RainLoop.
You can not agree to these terms on behalf of a third-party - if your own interest in the site is in any way commercial (for example, a freelancer being paid to build it) then a commercial license is always required, even if the site is for a non-commercial organisation.
You agree not to use the product on illegal sites, or on pages which contain illegal material.
You may not use the product at all in jurisdictions where this agreement is itself illegal, or where you are not empowered to enter into such an agreement.
You guarantee not to hold RainLoop responsible for any problems you may encounter, whether directly or indirectly caused by your use of any of our products.

Disclaimer: I'm not going to interfere in the discussion whether you should switch license and if so, how etc. I'm not into that enough. I'm just giving my opinion on the text above.
I don't understand number 7. If a non-for-profit organization "for and by" elderly people hire a person to help them with installing the RainLoop Webmail system for them, they are not allowed to use it? I don't understand that.

You agree not to alter, remove or decode any of the source code without explicit written permission from RainLoop.

The only change I'm interested in, is to change the favicon to match my domain's (Standard Basic, personal use, 1 domain, 1 user, access locked to 2 IPs - home and work). Should I inquire by email or is this change non-negotiable?

This is not the final version of the license.
@ervee
It is necessary to remove the misunderstandings about the commercial use of the product.
But ok, probably I need remove this list item.
@megadr01d - fixed
You agree not to alter, remove or decode any of the copyright notices or author attribution
without explicit written permission from RainLoop.

:+1: Thanks. I absolutely support the original attributions (copyright, title, author, "powered by" links, etc.) even if I had a commercial interest in it. It's sad when we don't wish to support independent developers but don't mind supporting the big corporations everyday (Gmail, Hotmail, Microsoft, Apple, Adobe...).


Inconsistent java formatting with Eclipse and IntelliJ

Google Java style guide says nothing about blank lines after class declaration.
However IntelliJ rules leaves blank line after class declaration:
IntelliJ Rules
whereas Eclipse rules define 0 blank lines:
Eclipse Rules
Which option is valid?

The inconsistency applies for other values too, for example the indentation size:
eclipse indent size = 4
vs.
intellij indent size = 2

@max-susi That's a different issue and it's actually a non-issue as explained in the comments in https://github.com/google/styleguide/issues/98


Update Segmented Controls [Fiji]

Zeplin:
https://app.zeplin.io/project/5d0356be2f25b319dcc5944b/styleguide/components?cseid=5dfc12e12ec4d6975469c160
https://app.zeplin.io/project/5d0356be2f25b319dcc5944b/styleguide/components?cseid=5dfc1338bdb90d17d2aa628c
https://app.zeplin.io/project/5d0356be2f25b319dcc5944b/styleguide/components?cseid=5dfc1308cb89a49855c3063e
Please pay attention to the details. It took me a while to set up spacing, color, fonts.

@hboon Few small tweaks. It needs to be taller and wider (increase spacing). Also, the bottom line is 1pt "Alto". You have 41 pt bg height (should be 49), and 2pt bottom line (should be 1).

There are some studies, where a minimum tappable area is 44 pt (fingertip).

Also, kill the top line (in between Search bar and Segmented Controls)

@vladyslav-iosdev would you help to check if we missed anything so we can close the issue? I think it's just https://github.com/AlphaWallet/alpha-wallet-ios/issues/1634#issuecomment-585134112

@hboon currently there is no line over segment control on tokens screen.

Good then. Thanks


fix: pass sdkUrl into init() in worker

When a worker is calling init(), if the sdkUrl isn't passed in, the sdk url will be reset due to this code in index.ts:
if (initValue.sdkUrl) {
  setSDKUrl(initValue.sdkUrl.toString());
}
else {
  setSDKUrl(new URL("index.mjs", import.meta.url).toString());
}

It may cause some bugs since the default sdk url isn't available due to hashing in filename and etc.

Great call! Merging

Wow what a quick merge! Thanks a lot.
Any chance we can get a new version of @wasmer/sdk in npm? I'm having some breaking bugs in production due to this bug right now.

Yup, let me try do release it soon


Fix of lamda parameter detection

nice regex!

Just a thought: but I think the replace statement in javascript takes a regular expression, so you could combine this into one line... I might be wrong though...


Add posts page

Add a page that contains all the posts. Should still have a couple posts on the main page

How taxing would it be to add a tag filter to search through all the articles?

Not too hard. There is some built in support for it. Would only have to style the page

Sweet! Let me know when you have time to create it :-)

Doubled checked.

Make sure you have tags in the post front matter

Have 'Resources' in the navbar and 'posts' and 'tags' as children


⚠ Exoticaz has degraded performance

In 7a3b9b1, Exoticaz ($EZ) experienced degraded performance:

HTTP code: 200
Response time: 6414 ms

Resolved: Exoticaz performance has improved in c3b999f.


Social Page UI enhancement

Improved Social page
Before -

After -

Please make an issue first then work on it, directly making a PR isn't a good practice as reviewers could find it difficult what the PR is about.

@DonnieBLT review this
Thanks


Suggestion to replace intercalate " " by unwords when I have my own intercalate

From https://code.google.com/p/ndmitchell/issues/detail?id=396:
Given
> module Delme (bob) where
>
> intercalate :: String -> [String] -> String
> intercalate = undefined
>
> bob :: [String] -> String
> bob = intercalate " "

hlint suggests
Delme.lhs:9:9: Error: Use unwords
Found:
  intercalate " "
Why not:
  unwords

Can hlint recognize that intercalate is not the expected one for this suggestion and so not fire the rule? Presumably this also holds for other transformations?
In the actual code base the signature of intercalate is MBuilder -> [MBuilder] -> MBuilder but I wanted to simplify things for the example.
@ndmitchell replied:
Yes, HLint 1.8 gained the ability to recognise modules, so I should be able to say Data.List.intercalate " " => unwords, and then the replacement won't match for your example. I'll go through and do this for all hints.
In fact, I should have import Data.List(intercalate) in the hint list, which makes the imports accurate and checkable, but keeps the hints readable.

A very similar issue on 1.9.35 and a custom function named evaluate:
evaluate :: (a -> Float) -> Expr a -> Float
evaluate varmap ex = undefined
evaluateStd :: [Float] -> CharExpr -> Float
evaluateStd vals = evaluate $
\x -> fromMaybe (error "invalid variable") (vals ^? element (fromEnum x - fromEnum 'a'))
hlint gives this warning:
src/Lib.hs:62:20: Warning: Redundant evaluate
Found:
evaluate $
\ x ->
fromMaybe (error "invalid variable")
(vals ^? element (fromEnum x - fromEnum 'a'))
Why not:
return
(\ x ->
fromMaybe (error "invalid variable")
(vals ^? element (fromEnum x - fromEnum 'a')))


Enable label position as percentage of the size

Fix #553
TODO

[x] line annotation
[x] box annotation
[x] label annotation
[x] test cases
[x] types
[x] documentation

I have tested your suggestions but it seems something is not correct:

See y>1 and y<0

Ok, now I undestand better your commits and there is a misunderstanding.
The position as number is not in PIXEL but is a value between 0 and 1 (as percentage) but numeric. I don't know if makes sense to allow the number as position in PX because there is already x/yAdjust options for that.

If we don't to provide the number as percentage, it's better to remove it and enable only the percentage as string.
What do you think?

Ok, now I understand better your commits and there is a misunderstanding.
The position as number is not in PIXEL but is a value between 0 and 1 (as percentage) but numeric. I don't know if makes sense to allow the number as position in PX because there is already x/yAdjust options for that.

If we don't to provide the number as percentage, it's better to remove it and enable only the percentage as string. What do you think?

I don't think having 2 ways to do the same thing (define percentage) is good. It creates many code paths for the same result and could be confusing to users.
So, I agree, it would be better to remove and only enable the percentage string.
I think a good set of helpers could be (would also make the width: 'invalid string' option for images fall back to the actual width):
const isPercentString = (s) => typeof s === 'string' && s.endsWith('%');
const toPercent = (s) => parseFloat(s) / 100;

export function getRelativePosition(size, positionOption) {
  if (positionOption === 'start') {
    return 0;
  }
  if (positionOption === 'end') {
    return size;
  }
  if (isPercentString(positionOption)) {
    return toPercent(positionOption) * size;
  }
  return size / 2;
}

export function getSize(size, value) {
  if (typeof value === 'number') {
    return value;
  } else if (isPercentString(value)) {
    return toPercent(value) * size;
  }
  return size;
}

Again my thoughts only, I can agree to other implementations too.

OK, fine for me! Let me change the code and test it!

the getRelativePosition is working well only with position 'start'. I need to refactor it.

the getRelativePosition is working well only with position 'start'. I need to refactor it.

It's assuming you remove paddings and margins etc extra adjustments and pass the actual available size.

It's assuming you remove paddings and margins etc extra adjustments and pass the actual available size.

yes, and forgive my lack of knowledge. But for instance, setting 'end', this is returning the size but I can not add to start point but I need to calculate the space anyway. And to do that, I need to re-check the position value (if statement). The same for center where I have to take care about the label size.
A label is drawn passing the box where the label must be drawn (see also textAlign).
For what I can see now (but open to change my idea) the best is to have something like was implemented before....
But again, feel free to correct me because I can not see another good way to do it.

In my poor opinion, trying to "centralize" the logic of the position, we could risk to increase complexity.

See https://github.com/pepstock-org/chartjs-plugin-annotation/pull/1

See pepstock-org#1

@kurkle really thank you for support! I really appreciate.
They are code climate similar code... But as we did before, we could accept it.

Yes, we can ignore the codeclimate here.
But there are still things to do.. The docs need to be updated, as it was agreed not to accept the number variant of the percantege. Also the getTPoistion function is unused I think.

yes, I am also rebasing to have the another PR.. need some minutes (let me finish another stuff, unfortunately not related to this).

Yes, we can ignore the codeclimate here.

How can I set it to be ignored? :(

Yes, we can ignore the codeclimate here.

How can I set it to be ignored? :(

Don't look at it :)

Only one mistake left, made by me.

Hmm, I can't. Maybe the "allow cnages by maintainers" flag was not checked in the PR.
Also it needs a update to the fixture, so can't do that directly here too :)

Only one mistake left, made by me.

Hmm, I can't. Maybe the "allow cnages by maintainers" flag was not checked in the PR.
Also it needs a update to the fixture, so can't do that directly here too :)

I can do it.


Unable to Install or Save poshy-env-proxy from PSGallery

Expected Behavior
Should be able to install or save module from PSGallery
Current Behavior
Unable to save or install module from PSGallery
System.Exception: Unable to save the module 'poshy-env-proxy'

Save-Module -name poshy-env-proxy -Path . -Repository PSGallery
WARNING: Package 'poshy-env-proxy' failed to be installed because: The file 'C:\Users\username\AppData\Local\Temp\50fex4uo\[Content_Types].xml' already exists.
WARNING: Package 'poshy-env-proxy' failed to install.

Steps to Reproduce

Attempt to Save-Module from PSGallery
Attempt to Install-Module from PSGallery

Context (Environment)
$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.3.6
PSEdition                      Core
GitCommitId                    7.3.6
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Fixed in https://github.com/pwshrc/poshy-env-proxy/releases/tag/v0.5.10. Thanks for reporting this!


MAINT: Delete unused operators for spmatrix handle class

Description
This PR deletes the copy and copy-assignment operators for the sparse matrix handle class, in order to clear warnings from static code analyzers.

PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.
You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).
Checklist to comply with before moving PR from draft:
PR completeness and readability

[x] I have reviewed my changes thoroughly before submitting this pull request.
[x] Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
[x] I have added a respective label(s) to PR if I have a permission for that.
[x] I have resolved any merge conflicts that might occur with the base branch.

Testing

[ ] All CI jobs are green or I have provided justification why they aren't.


Transaction rollback cause unhandled rejection

Example code:
const knex = require('knex')(/* config */);

process.on('unhandledRejection', err => {
    console.log('unhandled!');
    console.log(err);
});

async function test() {
    const trx = await knex.transaction();
    await trx.rollback();
    console.log('OK');
}

test();

Output:
03:15:36.907 info: OK
03:15:36.915 error: Transaction rejected with non-error: undefined
03:15:36.915 info: unhandled!
03:15:36.917 info: Transaction rejected with non-error: undefined

I can not define error handler cause .transaction() returns trx.initPromise.
https://github.com/tgriesser/knex/blob/master/src/util/make-knex.js#L41-L52
My temporary workaround:
const trx = await new Promise(resolve =>
    knex.transaction(trx =>
        resolve(trx)
    ).catch(() => {})
);

@Niklv See #3235 :D. You can try 0.17.1-next (the only version that included this change) and see if it causes any unwanted side-effects.
Had discussion with @elhigu recently about this. Quote:
There actually is kind of a good reason for forcing to have handler for rejects... transaction may be implicitly rejected from database side (actually even postgres does that by default if any of the queries done in transaction fails) and we should always have some kind of handler to catch those implicit rejects. That is actually something which for we should tests and documentation.
so basically one should always get result of transaction through that result promise that is given when transaction is created... i don't know... that stuff is pretty ugly 😒
we should try to come up some good syntax which handles explicit and implicit rejects nicely...

So current behaviour is more or less intended but could be (cautiously) improved.

And probably we need to expose same promise that you get from .transaction(callback) for .transaction() somehow.

@Niklv This issue was addressed in master. Would releasing 0.18.0-next3 with this change be helpful for you?

@kibertoad Godd job, thank you! Will try it in my projects.

@Niklv All right<EMAIL_ADDRESS>with this feature is out.


Upgrade Watson SDK to 0.37.0

A semver issue in a dependecy has broken all projects using the Watson SDK before release 0.36.0.  Please upgrade to version 0.37.0 to ensure dependency resolution will work.

I see versions are not locked in the Cartfile, so maybe this kit is not impacted.

@christiancompton is the interface changed in Watson SDK for viz rec? if yes we need to change if not just version change should not affect it.
I will test it though.

It sounds like the dependency should have a release artifact deleted and be re-released.

@dolph I concur, but no dice.  https://github.com/daltoniam/Starscream/issues/587

@sanjeevghimire There are no interface changes that I am aware of.

will be solved in #36


App.screenshot() method doesn't return screenshot full path and name on cloud.

In our application we want to read screenshot as a bytes array or stream to read OCR character from screenshot, but App.screenshot() method return "FileInfo" class instance which contains that screenshot information, but on cloud (appcenter) it doesn't work.
As per the appcenter team reply, it is not possible in code (There is no direct way of taking all the screen shot but We have the ability to download screenshots via our App Center API,Use the GET/v0.1/apps/{owner_name}/{app_name}/test_runs/{test_run_id}/report endpoint).
But in the code we have no test test_runs  and test_run_id information.
Could you please provide a solution for same case?
Note: we are using xamarin.uitest 3.0.3 dll and nuint 3.12.0.

Thanks for the feature request! Tagging my colleague who can give you updates on when we can address this.


audio not forwarded

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: [e.g. Debian, Windows, macOS...]
ubuntu 22.04
scrcpy version: [e.g. 1.12.1]
1.21
installation method: [e.g. manual build, apt, snap, brew, Windows release...]
apt install scrcpy
device model:
pixel3
Android version: [e.g. 10]
android 12

Describe the bug
A clear and concise description of what the bug is.
just run scrcpy on ubuntu and I can use android freely on ubuntu including video playing, except audio stays on the phone(not forwarded)
On errors, please provide the output of the console (and adb logcat if relevant).
scrcpy 1.21 <https://github.com/Genymobile/scrcpy>
* daemon not running; starting now at tcp:5037
* daemon started successfully
/usr/share/scrcpy/scrcpy-server: 1 file pushed. 0.9 MB/s (39473 bytes in 0.043s)
[server] INFO: Device: Google Pixel 3 (Android 12)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6.0 NVIDIA 525.125.06
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2160
[server] INFO: Device clipboard set
INFO: Device clipboard copied

Please do not post screenshots of your terminal, just post the content as text instead.

You need the latest version: https://github.com/Genymobile/scrcpy/blob/master/doc/linux.md#latest-version

tried release scrcpy 2.1.1 but got error: java.lang.IllegalArgumentException: The server version (2.1) does not match the client (2.1.1), seems like a 2.1.1 release bug?

Read this comment wihich explains why the install_release.sh script may not be included in the tag, but only one commit after: https://github.com/Genymobile/scrcpy/issues/4098#issuecomment-1600332180
It is intended to be run from master.


fix: Issue 34961 GraphQL Logo seems to be incorrect

Description

[!TIP]
Issue: The GRAPHQL plugin logo is shown same as RestAPI plugin.
Fix: Imported the right logo for graphql and used the right image in the img tag

Fixes #34961
or
Fixes Issue URL

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test<EMAIL_ADDRESS>:mag: Cypress test results

[!CAUTION]
If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[x] No

Summary by CodeRabbit

New Features

Updated the New API screen to display the GraphQL logo instead of the Plus logo.

Hi @ayushpahwa . Please review.

Hi @ayushpahwa , please review this PR.

/build-deploy-preview skip-tests=true

@ayushpahwa do we need any tests for this?

@NilanshBansal for UI changes like this, snapshot tests might be relevant but they are not really maintainable. I have done manual test on the DP generated however. Lemme know if there's any other suggestions/reservations.

All automation tests passed, okay to merge.


MINOR: Add comment to onPartitionsLost override

This adds comments to the ConsumerRebalanceListener overrides, in order to briefly explain why we are overriding these methods, when they are called, and what you can or can't do. Especially onPartitionsLost can create some confusion given the default implementation.

Thanks @showuon, noted.

@dajac are you good with these changes?

Failed tests are unrelated.


feat(rtc_auto_mode_manager)!: add auto mode status array

Description
This PR needs https://github.com/tier4/tier4_autoware_msgs/pull/70
add auto mode status array

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@tkimura4 @tkhmy
can you review this PR please?

@rej55 could you approve this?


[PATTERN] Add a star pattern in JavaScript, Pattern38

Description
Task:
for the given input n the following pattern should print (n=5 for the below pattern):
Pattern Image

Filename
Pattern38.js

Hi @Vishal21121, I would like to contribute to this issue. Can this be assigned to me??

ok, @johnweslee you can work on this issue.

Hi @Vishal21121,
I have created a PR ( #73 ) for this issue. Kindly take a look when you have a chance.


TokenRelay Exception Due To ReadOnlyHttpHeaders

Describe the bug
Today's update to Spring Boot 3.3.5 caused the TokenRelay filter in Spring Cloud Gateway 2023.0.3 to throw an exception.  It looks like Spring changed the default HttpHeader to ReadOnlyHttpHeader.
For now, I have had to roll back to Spring Boot 3.3.4 and pin.
Sample
Here's a snippet of the exception up to the TokenRelay start.
java.lang.UnsupportedOperationException at org.springframework.http.ReadOnlyHttpHeaders.set(ReadOnlyHttpHeaders.java:110)
Suppressed: The stacktrace has been enhanced by Reactor, refer to additional information below:
Error has been observed at the following site(s):
*__checkpoint ⇢ org.springframework.cloud.gateway.filter.WeightCalculatorWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ AuthorizationWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ ExceptionTranslationWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ LogoutWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ ServerRequestCacheWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ SecurityContextServerWebExchangeWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ LogoutPageGeneratingWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ LoginPageGeneratingWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ OAuth2AuthorizationCodeGrantWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ AuthenticationWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ OAuth2LoginAuthenticationWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ OAuth2AuthorizationRequestRedirectWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ OAuth2AuthorizationRequestRedirectWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ ReactorContextWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ CsrfWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ HttpsRedirectWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ HttpHeaderWriterWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ ServerWebExchangeReactorContextWebFilter [DefaultWebFilterChain]
*__checkpoint ⇢ org.springframework.security.web.server.WebFilterChainProxy [DefaultWebFilterChain]
*__checkpoint ⇢ org.springframework.security.web.server.WebFilterChainProxy [DefaultWebFilterChain]
*__checkpoint ⇢ HTTP GET \"/api/foo\" [ExceptionHandlingWebHandler]\nOriginal Stack Trace:
    at org.springframework.http.ReadOnlyHttpHeaders.set(ReadOnlyHttpHeaders.java:110)
    at org.springframework.http.ReadOnlyHttpHeaders.set(ReadOnlyHttpHeaders.java:39)
    at org.springframework.http.HttpHeaders.set(HttpHeaders.java:1735)
    at org.springframework.http.HttpHeaders.set(HttpHeaders.java:76)
    at org.springframework.http.HttpHeaders.set(HttpHeaders.java:1735)
    at org.springframework.http.HttpHeaders.setBearerAuth(HttpHeaders.java:830)
    at org.springframework.cloud.gateway.filter.factory.TokenRelayGatewayFilterFactory.lambda$withBearerAuth$5(TokenRelayGatewayFilterFactory.java:92)
    at org.springframework.http.server.reactive.DefaultServerHttpRequestBuilder.headers(DefaultServerHttpRequestBuilder.java:117)
    at org.springframework.cloud.gateway.filter.factory.TokenRelayGatewayFilterFactory.lambda$withBearerAuth$6(TokenRelayGatewayFilterFactory.java:92)
    at org.springframework.web.server.DefaultServerWebExchangeBuilder.request(DefaultServerWebExchangeBuilder.java:58)
    at org.springframework.cloud.gateway.filter.factory.TokenRelayGatewayFilterFactory.withBearerAuth(TokenRelayGatewayFilterFactory.java:92)
    at org.springframework.cloud.gateway.filter.factory.TokenRelayGatewayFilterFactory.lambda$apply$2(TokenRelayGatewayFilterFactory.java:65)

Ugh.  Bad stack trace output.  Please give me a few minutes and I will get it formatted so you can read it.

Experiencing same readonly header with spring boot 3.2.11

Experiencing same readonly header with spring boot 3.2.11

Hmmm... Perhaps there is another underlying library that updated and came along in a BOM update?  I was reading through the SB 3.3.5 release notes and didn't see anything specific.  But rolling back the SB to 3.3.4 definitely fixed it.

I wonder if https://github.com/spring-projects/spring-framework/commit/ef77b4064fe0cc6da3986059cbeac3f471a8fd92 needs to be backported to spring-framework, that is the library that boot brings in.
@simonbasle @rstoyanchev

I'm experiencing this in gateway itself.

I'm experiencing this in gateway itself.

I'm sure the problem extends further than I reported.  In my case, all requests to my SCG trigger a TokenRelay filter first.

In fact, any mutating of request headers is broken.

https://github.com/spring-projects/spring-security/issues/15989

See this issue for a workaround if you want to keep the boot 3.3.5 upgrade https://github.com/spring-projects/spring-security/issues/15974

do you suggest this workaround for 3.2.11 also?

For those experiencing this issue, DO NOT disable Spring Security's firewall as a workaround to the underlying Spring Framework issue. Instead, you can use the following as a workaround:
@Bean
@Order(Ordered.HIGHEST_PRECEDENCE)
WebFilter writeableHeaders() {
	return (exchange, chain) -> {
		HttpHeaders writeableHeaders = HttpHeaders.writableHttpHeaders(
				exchange.getRequest().getHeaders());
		ServerHttpRequestDecorator writeableRequest = new ServerHttpRequestDecorator(
				exchange.getRequest()) {
			@Override
			public HttpHeaders getHeaders() {
				return writeableHeaders;
			}
		};
		ServerWebExchange writeableExchange = exchange.mutate()
			.request(writeableRequest)
			.build();
		return chain.filter(writeableExchange);
	};
}

You can find a complete demo of the workaround at https://github.com/rwinch/spring-sample/pull/new/spring-framework-33789-readonly-headers

Thanks @rwinch.  That fix seems to have done the trick.  I will put this in my application until a more permanent fix is ready.
Speaking of which, do you think this will be fixed in Spring Boot 3.3.6?  Or is this something that the Spring Cloud Gateway team needs to resolve?

As mentioned above, the fix is in spring framework, which a future version of spring boot will pick up

@danielshiplett I'd reach out to Spring Framework team on https://github.com/spring-projects/spring-framework/issues/33789 to see what versions will be fixed in Spring Framework


Using fastify-gql in place of Apollo Gateway does not work

Hi,
As a proof of concept, I tried taking this demo repository and replace Apollo Gateway with fastify-gql. The federated services start fine (as expected). Then, when I try to start the Gateway server, I get this error:
Error: The directive "@key" can only be used once at this location.
    at assertValidSDLExtension (/Users/julienheller/projects/federation-demo/node_modules/graphql/validation/validate.js:124:11)
    at extendSchema (/Users/julienheller/projects/federation-demo/node_modules/graphql/utilities/extendSchema.js:78:45)
    at buildFederationSchema (/Users/julienheller/projects/federation-demo/node_modules/fastify-gql/lib/federation.js:253:22)
    at buildGateway (/Users/julienheller/projects/federation-demo/node_modules/fastify-gql/lib/gateway.js:151:18)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async fp.name (/Users/julienheller/projects/federation-demo/node_modules/fastify-gql/index.js:119:15)

My guess is that both the original definition for Product and its extended clause have a @key directive, which are trying to be merged together. I wonder how Apollo handles this situation?
Here's my fork to try it for yourself.
npm i
npm run start-services
npm run start-fastify-gateway

Wow, good finding and thanks for checking this out.
I’m a bit unsure how that would work... would you like to send a Pull Request to address this issue? Remember to add unit tests.

I would help, but I don't know the proper expected implementation of the Gateway (in this case the expected way to handle conflicting directives when creating the combined schema). I tried looking for a specification, but could only find an implementation specification for the Federated services, and an API specification for the Gateway, but not a specification for implementing a Gateway. Under what basis was the Gateway implementation designed? By just reverse engineering the Apollo Gateway implementation?
I could do my best to try different things regarding directives using the Apollo implementation and copy the observed functionality over to fastify-gql, if there's no better expected methodology.

I just found this:

At composition time, ApolloGateway strips all definitions and uses of type system directives from your composed schema. This has no effect on your implementing service schemas, which retain this information.

So, I guess we can strip directives from the service schemas before merging them? I'll see if doing that seems to bring parity in behavior.

Amazing, I think that would work!

Did some work on this today. The problem seems to be that, as stated above, the Gateway should not expose TypeSystemDirectives (however ExecutableDirectives will be exposed, and they need to match between services). We can exclude TypeSystemDirectives from within getStubTypes(), and then the server starts up. But since makeResolver() references the built schema for this directive information, things get messed up.
From where I'm seeing it, we need to refactor makeResolver() to not reference the schema for directive information, although I don't fully understand all aspects of this system and this might not be the best solution. I see that @frikille did most of the work on this, maybe he could give some input?

The problem seems to be partially resolved by passing true to assumeValid to the last extendSchema() call in buildFederationSchema() when building for the Gateway:
  // Add all extensions
  federationSchema = extendSchema(
    federationSchema,
    {
      kind: Kind.DOCUMENT,
      definitions: extensions
    },
    { assumeValid: isGateway },
  )

This change allows the service to run and successfully execute queries. However, I'm not sure if this is opening up the system to problems due to skipping validation. Furthermore, the TypeSystemDirectives are still being passed to the final schema incorrectly, which seems to be a fundamental problem with the implementation, since makeResolver() depends on these directives.

Would you like to attempt a PR? I would not be able to help much in the coming weeks :(. I think your hot fix is feasible and should unstuck you.

I'm not stuck per-se. I'm shopping around for a solution that can offer Federation as well as subscriptions, and am willing to put work into bridging gaps. I don't feel comfortable submitting a PR that might introduce bugs and/or repercussive implications due to not fully understanding the system.
I really do think that the current implementation needs to change from depending on schema directives at query time to depending on configuration that is derived from the directives before they are removed. This will also lay a foundation for providing validation of compatibility across federated services, which Apollo Server currently provides.

I am still curious as to what the answers are to questions I asked originally:

Under what basis was the Gateway implementation designed? By just reverse engineering the Apollo Gateway implementation?

@frikille might be able to answer that.

I've done some investigation on this whilst I was looking at https://github.com/mcollina/fastify-gql/pull/220
I think I have found the underlying issue, these are my findings:

The issue is not with service B extending a type from service A nor the fact the the extend also includes the same @key directive as the type it is extended
It is actually expected that service B extending a type from service A also includes the sane @key directive, according to the apollo website: https://www.apollographql.com/docs/apollo-server/federation/entities/#referencing

The @key directive indicates that Product uses the upc field as its primary key. This value must match the value of exactly one @key defined in the entity's originating service, even if the entity defines multiple primary keys.

The bug exposed here occurs when two services both extend the same type from another service. In the example from the original post it is the Product type that is extended by both the reviews and the inventory service
The errors occurs in https://github.com/mcollina/fastify-gql/blob/master/lib/federation.js#L253. Apparently graphql's extendSchema raises an error when it is passed two definitions that extend the same type at the same type.
If we make multiple calls to extendSchema for the extensions and keep the extensions to the same type in separate extendSchema it will work
I think we may raise this to graphql-js
In the meantime a quick albeit inefficient fix is to add extensions to the schema one by one

I've created a quick PR to demonstrate the issue and a potential fix.

I don't have time to look into this, but just wanted to comment on

It is actually expected that service B extending a type from service A also includes the sane @key directive, according to the apollo website: https://www.apollographql.com/docs/apollo-server/federation/entities/#referencing

While this is true that this is expected, that doesn't mean that it's valid to attach the same directives to extended types. The way Federation defines how separate services need to attach directives to their own schemas does not dictate what is valid within the same schema.

The errors occurs in https://github.com/mcollina/fastify-gql/blob/master/lib/federation.js#L253. Apparently graphql's extendSchema raises an error when it is passed two definitions that extend the same type at the same type.

Based on what I remember when testing, this is not the case. If you have a type with a directive, and extend the type with the same directive, then it will give the error. It's possible I'm remembering wrong, however.
In any case, in order to abide by Apollo's documentation we still need to strip the directives from the final schema. Since this is necessary, then removing them before extending kills two birds with one stone. It just means we need to capture the configuration as defined by these directives beforehand.

I don't have time to look into this, but just wanted to comment on

It is actually expected that service B extending a type from service A also includes the sane @key directive, according to the apollo website: https://www.apollographql.com/docs/apollo-server/federation/entities/#referencing

While this is true that this is expected, that doesn't mean that it's valid to attach the same directives to extended types. The way Federation defines how separate services need to attach directives to their own schemas does not dictate what is valid within the same schema.

Let me rephrase that. The Apollo docs clearly state that when extending entities, the extend must include the same @key directive as the original type definition. This is the case for stubs and actual extensions.

The errors occurs in https://github.com/mcollina/fastify-gql/blob/master/lib/federation.js#L253. Apparently graphql's extendSchema raises an error when it is passed two definitions that extend the same type at the same type.

Based on what I remember when testing, this is not the case. If you have a type with a directive, and extend the type with the same directive, then it will give the error. It makes sense that you'd be getting the error with multiple extensions of the same type with the same directive, for this reason. It's possible I'm remembering wrong, however.

As far as I can see, this is not the case - or at least it's not enforced at the graphql-js level.
Fastify-gql builds the schema in buildFederationSchema (https://github.com/mcollina/fastify-gql/blob/master/lib/federation.js#L230). In there the concatenation of the schemas from the federated services is parsed and then split in type stubs, extensions and definitions. It then proceed to make a call to extendSchema with each of those three groups.
The error we get in the demo repository (and also in fastify-gql own example in https://github.com/mcollina/fastify-gql/blob/master/examples/gateway-subscription.js) is thrown by the call to extendSchema that tries to add all extensions at the same time.
This happens regardless of how many type extensions with the same @key directive have been added beforehand: the problem is just with calling extendSchema with the extend for the same type with the same directive.
To prove that I made this small change https://github.com/mcollina/fastify-gql/pull/221/files#diff-d9185daf57698ed90d572d1966e61b16R253-R258 where extensions are added one at the time and that fixed the issue: a sign that extendSchema is accepting multiple extend with the same key directive if each one happens in their own call to extendSchema

In any case, in order to abide by Apollo's documentation we still need to strip the directives from the final schema. Since this is necessary, then removing them before extending kills two birds with one stone. It just means we need to capture the configuration as defined by these directives beforehand.

I agree with this. Regardless of what is actually causing the exception we are seeing, the correct implementation would be to replicate the behaviour of Apollo, which is to strip the directives in the federated schema.
I took a look at Apollo's code and that appears to be happening in https://github.com/apollographql/apollo-server/blob/5bab3aedeeb1e70c636f3aa3ac7a147679f450f7/packages/apollo-federation/src/composition/normalize.ts#L20 (more specifically in https://github.com/apollographql/apollo-server/blob/5bab3aedeeb1e70c636f3aa3ac7a147679f450f7/packages/apollo-federation/src/composition/normalize.ts#L270).
So, to sum up my point:

I find the behaviour of parse and extendSchema from graphql-js weird: a schema parsed without errors by parse throws and error in extendSchema, and that also depends on the fact that you make only one call or multiple calls to it. May be worth further investigating into this and report to graphql-js
Regardless of that, fastify-gql should replicate Apollo's behaviour and strip the directives

I've spent more time debugging this, and I have come to the conclusion that my understanding of the issue as expressed in the previous message was incomplete.
Here's my new understanding:

Apollo-server is indeed stripping directives, but only the directive definitions from the implementing service schemas, not the directive usages in extensions. I.e.

    extend type User @key(fields: "id") {
      id: ID! @external
      comments: [Comment]
    }

get's added to the schema as is, still retaining the @key part
2. Apollo-server overcomes the error we are getting by calling extendSchema with the option assumeValidSDL as @flux627  suggested at one point. See it here: https://github.com/apollographql/apollo-server/blob/00887a1e57a26075483ba397098f6d088a706499/packages/apollo-federation/src/composition/compose.ts#L373
3. Apollo-server however add its own validations before extending the schema: https://github.com/apollographql/apollo-server/blob/00887a1e57a26075483ba397098f6d088a706499/packages/apollo-federation/src/composition/compose.ts#L371. It uses a private function from graphql-js: validateSDL. It's the same function function used internally by validateSchema, but apollo-server replaces the rules it uses
I'm working on a PR to replicate the behaviour by calling extendSchema with assumeValidSDL set to true but also adding the validations.


Comments Rating

It would be cool that you could rate the comments

Hey,
I ask you to resume this section for development, since ratings are always important for the static use of a particular article (section book).
please consider the improvement:
article rating both positive (+1;...+4 ) and negative ( -1;...-4 );
write a complaint to the author or authors of the article (it would be great if this functionality could be filled in when creating an article)
complain to the system owner
consolidating page of statistics on the use of pages (page opening, rating, number of complaints)
thus the system will be able to be updated more quickly, more complete and more applicable in the business segment


#153 Add how to create JSON data to docs

I added @isms' post to the documentation.
It references issue #153 .

CLA

[X] I have signed the CLA; if other committers are in the commit history, they have signed the CLA as well

Thanks!


Bug: 500 on GET /api/opportunities

When I run
$ flask db upgrade
I'm thrown an error:
ERROR [root] Error: No support for ALTER of constraints in SQLite dialect
I think this is the reason I get a 500 status on GET /api/opportunities.
Pull my fork to test this error.
To test this error:

pull my fork
follow instructions in docs
start the server & front-end
login at '/'
You're redirected to /dashboard, where a GET /api/opportunities is automatically called. Check your browser's console to see a 500 error.

FYI I am authorized and have a bearer token for the api.


Decode URI before saving for non-Latin characters

Non-Latin characters in Category or Article names are encoded within
page address and should be decoded back before sending page saving
request to API. Resolves #61.

I'm reviewing this now

Thank you @yaruson
Merged!
I tried it with Mandarin Chinese and all worked with your patch while editing.
I'll add your same edit to the "delete" option to get that working too.
Ryan


VMAS simple tag MADDPG with TorchRL Tutorial - Memory map device

Hi!  Thanks for sharing your work on MARL with VMAS!  The tutorial was great and included lots of details and explanations!  I have been looking for examples with non-sharing parameters between agents within the same group, as well as centralized vs decentralized training.  This tutorial is exactly what I need!  Thank you!
I was trying to test on the performance of the CPU version with PettingZoo vs GPU version with VMAS.  Apparently on replay buffer section, I am getting the error "ValueError: Memory map device other than CPU isn't supported." so I follow the instruction to cast the data by adding a line of code "replay_buffer.append_transform(lambda x: x.to(device))".  So my question is:
Would this step slows down the training since there is a transform to change the device from CPU to GPU?
Could we use a replay buffer other than storage=LazyMemmapStorage if there is such a limitation?  Which one could we use?
Thanks!

Hello, if this is about the torchrl tutorial could you open it there and tag me? I can reply there. I believe benchmarl is not related to this. Thanks

Thank you!
https://github.com/pytorch/rl/issues/2515


[WIP] Exercise 2 review for TWF

General notes

It takes quite some time to hit F5 and see if it runs. Feels like big-bang approach. Should we make the whole process more incremental? e.g. put explicit CTA to run current version of the the exercise?
How much commentary do we expect from the Trainer? e.g.

Inside OrderSubmittedHandler in Finance it might not be obvious why we need the InitiatePaymentProcessCommand
Should we go through PaymentClient to show what kind of data it requires to make a payment before we show InitiatePaymentProcessCommand creation?
Should we mention potential ordering issues in Shipping?
Do we go through error cases or wait until Exercise 3?

I think @tmasternak needs to add the text to "back-up the claim" mentioned in comments?

OK, I was a bit confused, because the claim we are talking about backing up is removed in this PR. However, I think get what you mean. Rather than remove that claim, we change it to a fact ("records prices for the items") and then we have a separate, specific sentence (or sentences) to explain why that happens?

@adamralph done

@dvdstelt @tmasternak I tweaked the changes. Please review.


Refactor func processVmShutdown

What this PR does / why we need it:
Refactor this function in pkg/virt-handler/vm.go,
so its cognitive complexity is reduced below 15
and corresponding sonarcloud issue is fixed.
Signed-off-by: Tomas Psota<EMAIL_ADDRESS>Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:
NONE

/ok-to-test

/lgtm

/retest

/approve