Refactor usages of physicalSizeTestValue to simplify code and improve DX

Just a small refactor. Using:
  set physicalSizeCurrentTestValue(ui.Size value) {
    physicalSizeTestValue = value;
    addTearDown(clearPhysicalSizeTestValue);
  }

We can make setting physical size test values a bit better in the following two aspects:

Code is less duplicated. Originally need to specify set value + clear value, now only need one call
Writing new tests are less error-prone, especially for new learners of Flutter, thus increasing DX. When I firstly learn Flutter, I often wrongly write down set test value calls, without the clear value calls. Then the tests works pretty well when isolated, but you know, it fails weirdly when run sequentially because the later tests have wrong physical size. As a new learner of Flutter (years ago), it took me some time before realizing it is this bug. Thus, it would be great to avoid the possibility of such problem from the beginning.

Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] All existing and new tests are passing.

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

Secondly, I think having two similarly named setters, one that cleans up after itself and one that doesn't, is still pretty unintuitive for developers. There is still a lot of potential for making a mistake, say by accidentally setting physicalSizeTestValue instead of physicalSizeCurrentTestValue and expecting it to automatically do clearPhysicalSizeTestValue.

What about renaming it to: physicalSizeTestValue vs physicalSizeTestValueAutoClear? Then nobody can use it by mistake since the latter says "auto clear"

I like the goal of this (easier tests, less likely to make mistakes), but I have a couple of concerns with this as implemented:

Does this hide a problem, rather than addressing it?

It's pretty common that addTearDown and tearDown calls are missed as you pointed out in your description. This PR makes it easier to not miss those calls for a few specific cases, but it doesn't really address why those calls are missed or drive users to write better tests in other cases.

Does adding these methods here set a standard that the testing framework will be expected to stick to elsewhere?

How do we determine which properties or fields should/shouldn't have versions that auto clear?
How should adding those auto clear versions be prioritized?
If/when those versions break, should it be considered a breaking change and should the breaking change process be followed for just the auto clear version, or for auto clear and standard versions?

Will this cause unintuitive behavior in other use cases?

Specifically I'm thinking of someone trying to use this for setting up a group of tests. Since this makes use of addTearDown, it'll only behave as expected for individual tests. If someone tries to use the "AutoClear" version in a group, it'll throw an exception.
In combination with number 2, would any "AutoClear" versions also need an "AutoClearGroup" version?

Personally, I'd lean towards pushing the convenience method part to a separate package where the expectations for support, maintenance, and coverage won't be as high. It'd also allow for more community contributions for different conveniences and extensions to be added without needing to go through as much process as this repo requires. As for the fixes to our own tests, it's a great catch and should be included, but IMO without using the convenience method.

@Renzo-Olivares @justinmc done :)

@pdblasi-google

Does this hide a problem, rather than addressing it?
It's pretty common that addTearDown and tearDown calls are missed as you pointed out in your description. This PR makes it easier to not miss those calls for a few specific cases, but it doesn't really address why those calls are missed or drive users to write better tests in other cases.

So what do you think is the reason "why those calls are missed"? I indeed am not sure - maybe because they just forget?

Does adding these methods here set a standard that the testing framework will be expected to stick to elsewhere?
How do we determine which properties or fields should/shouldn't have versions that auto clear?

For fields that have a set somethingTestValue and clearSomethingTestValue I guess?

How should adding those auto clear versions be prioritized?

IMHO this is quite trivial to implement (if you like I can submit more)

If/when those versions break, should it be considered a breaking change and should the breaking change process be followed for just the auto clear version, or for auto clear and standard versions?

Sorry, not sure about the question

Will this cause unintuitive behavior in other use cases?
Specifically I'm thinking of someone trying to use this for setting up a group of tests. Since this makes use of addTearDown, it'll only behave as expected for individual tests. If someone tries to use the "AutoClear" version in a group, it'll throw an exception.
In combination with number 2, would any "AutoClear" versions also need an "AutoClearGroup" version?

Luckily, not a problem! If you like I can put the following code which automatically uses addTearDown vs tearDown and is used internally in my app:
void autoSetUpTearDownOrAddTearDownSync(
  void Function() setUpBody,
  void Function() tearDownBody,
) {
  // ref: test_api :: test_structure.dart :: addTearDown
  // `Invoker.current==null` will lead to a message `addTearDown() may only be called within a test.`
  // so use this to determine whether in test
  if (Invoker.current == null) {
    setUp(setUpBody);
    tearDown(tearDownBody);
  } else {
    setUpBody();
    addTearDown(tearDownBody);
  }
}

@fzyzcjy
Personally, I think those calls are missed because they aren't made obvious to users through documentation and examples.  As such, I'm not sure hiding those calls behind convenience methods promotes better usage of those methods.
Adding the convenience methods also increases our API surface, which increases our maintenance burden, and sets up expectations for other parts of the testing framework that don't actually solve the problem of those methods being missed, but instead makes it even less likely that users will run into an example using them correctly.
Long story short, I don't think the convenience methods are worth the long term cost of introducing that pattern to the framework. Hence suggesting creating a package for them, where the maintenance costs and coverage expectations are going to be lower.
It's also worth noting that there's work at the moment to move from a single window to multiple views (to support desktop better), which may be a great opportunity to improve on these particular fields' APIs from the ground up. I believe @goderbauer is driving that initiative, though he's out until next Tuesday.

@pdblasi-google

Personally, I think those calls are missed because they aren't made obvious to users through documentation and examples.

Not sure how other people do, but I am not this case personally. I have this simply because I forgot to call the clear :/ I do vaguely remember the clear, and if you test me in a questionaire I will remember it, but when programming I just set the value - doing the minimal necessary work - while forgetting the clear.

Hence suggesting creating a package for them

Then what should we do for the flutter framework itself? Or shall we mark them @internal so flutter framework can use it?

It's also worth noting that there's work at the moment to move from a single window to multiple views (to support desktop better), which may be a great opportunity to improve on these particular fields' APIs from the ground up. I believe @goderbauer is driving that initiative, though he's out until next Tuesday.

Looks interesting!

If the convenience methods are moved to a package, I would suggest just not using them in the flutter repo and updating the tests here to use the addTearDown methods where appropriate to clear the values. That way, those tests can serve as an example of how to use the standard addTearDown pattern.

not using them in the flutter repo*

Then the tests are not DRY ;)

Then the tests are not DRY ;)

I mean, if you want to get the tests really DRY, then the setup/teardown would be moved out to the group level and done either once for the entire group, or set up to happen before and after each test with the group level methods.
Since we're working on a public API though, we don't necessarily want to be DRY on everything. We have to balance trying to keep our internal stuff as clean as we can with not making the API too specific to our internal use cases.

then the setup/teardown would be moved out to the group level and done either once for the entire group

Well, those tests are not in the same file, so IMHO they cannot be solved by group.

Since we're working on a public API though, we don't necessarily want to be DRY on everything. We have to balance trying to keep our internal stuff as clean as we can with not making the API too specific to our internal use cases.

I see. Btw, it is not "too specific to our internal use cases" as it is used everyday by external users

I have to agree with @pdblasi-google, I'm not certain that this is better than the existing API, so I don't think we should make this change.  Instead, here's what I think we can do about this problem:

Clearing should happen immediately after setting.  This makes it obvious to future readers of the test that these values need to be cleared, and it makes it less likely the test will end without the values being cleared.  I think this could be done in this PR or in a new PR.

Old way:
tester.binding.window.devicePixelRatioTestValue = 1.2;
tester.binding.window.physicalSizeTestValue = const Size(250, 300);

... // Rest of test

 tester.binding.window.clearPhysicalSizeTestValue();
 tester.binding.window.clearDevicePixelRatioTestValue();

Should be changed to:
tester.binding.window.devicePixelRatioTestValue = 1.2;
addTearDown(clearDevicePixelRatioTestValue);
tester.binding.window.physicalSizeTestValue = const Size(250, 300);
addTearDown(clearPhysicalSizeTestValue);

... // Rest of test

devicePixelRatioTestValueAutoClear and physicalSizeTestValueAutoClear could be released as a Pub package if desired.

Like @pdblasi-google said, ideas about autoclear and other patterns that avoid this problem should be directed at @goderbauer's work to move from TestWindow to TestView, since we have the opportunity to start fresh here and change the API.  He has a design doc, which it doesn't specifically mention this about testing so it might be worth bringing it up in a comment there.

Hmm I see. Then maybe I will refactor like what you said.
P.S Did a comment there just now.

Getting back to this PR. It looks like we are already using addTearDown(tester.view.reset) in the master. So what should I do now :)

As a note, I have an issue (#121917) that'll handle the more generic case. Not sure when I'll get to it, but it should cover the fixes that were worked on here originally as well when I do.

I think so. Just wanted to hear your opinions :)

Sounds good, thanks for helping us figure this out even though there's nothing to change here!


OnDisconnected event

The client does not react in any way when the connection with the server is lost.

Thanks for reporting @derwish-pro, now Client.OnClose and Room.OnLeave are being invoked properly.


atom-beautify auto formats

I am new to front end field and just installed atom text editor. After many google searches  I finally found out about atom-beautify and installed it. It worked perfectly but one issue I am having is when ever I type any text  the text gets automatically formatted but what is want is only to formats whole code only if I press CTRL + S. Is it possible? if so how?

If you still need this and are looking for something to fill the spot that Atom left, I am using Pulsar the successor to Atom...   This package is working except for one deprecated error listed in #2605
If you don't need this anymore, can you please close this out so it's not just sitting there? Thanks


WGAN-GP batch size

I would like to know how to train WGAN-GP with variable batch sizes. I couldn't find a way to set the batch size in the function below dynamically. This is needed because my last batch is not complete.
class RandomWeightedAverage(Add):
    """Provides a (random) weighted average between real and generated image samples"""
    def _merge_function(self, inputs):
        alpha = K.random_uniform((32, 1, 1, 1))
        return (alpha * inputs[0]) + ((1 - alpha) * inputs[1])

Hi can you explain me please why there is no accuracy value in wgan and wgan-gp code?

Here's how i did it.
class RandomWeightedAverage(Add):
    # Provides a (random) weighted average between real and generated image samples
    def _merge_function(self, inputs):
        input1, input2 = inputs
        alpha = K.random_uniform((K.shape(input1)[0], 1, 1, 1))
        return (alpha * input1) + ((1 - alpha) * input2)


Added Loading animation to API call in dictionary

This PR addresses the issue #63
This adds a user friendly message "Loading data from API... //" for the duration of the data being fetched from the API.
It happens so fast that i can't take a screenshot for preview but does work.

Good work! Merged.


[MM-50269] Show app icons for disabled apps

Summary
Fix a regression introduced in https://github.com/mattermost/mattermost-plugin-apps/pull/336 that blocked disabled apps from showing their icon.
Ticket Link
https://mattermost.atlassian.net/browse/MM-50269

Codecov Report
Base: 20.74% // Head: 20.74% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (c973f7e) compared to base (76a4501).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #452   +/-   ##
=======================================
  Coverage   20.74%   20.74%
=======================================
  Files          80       80
  Lines        5366     5365    -1
=======================================
  Hits         1113     1113
+ Misses       4114     4113    -1
  Partials      139      139

Impacted Files
Coverage Δ

server/proxy/invoke_static.go
21.87% <0.00%> (+0.66%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

/update-branch

/update-branch


Connection to 8883 from MKR1000 using Wifi101 not working.

Hi has anyone been successful in connecting using SSL to any broker? I have issues with my own broker, Arduino and Azure IoT Hub. If it isn't possible with PubSubClient anyone know a library that can.
Thanks in advance.

Hi @AdamMiltonBarker
this library depends on you providing a network client library for establishing the underlying TCP connection. It's at that layer that any SSL connection is negotiated - not in this library. So it isn't a question of whether this library is able to do it or not - it's all about the network library.
I have heard some have successfully used https://www.arduino.cc/en/Reference/WiFi101SSLClient to create secure connections, but I don't know if it was to Azure IoT Hub specifically.

Hi thanks I am using this I just couldn't find the library again, but fails at each attempt.
https://github.com/arduino/cloud-examples/blob/master/mqtt/mqtt_send_digital/mqtt_send_digital.ino

I have added an issue on their repo, I will let you know if it gets resolved in case anyone else has an issue in the future.

Still no reply yet from about the other library, will close this issue down and just update it when I work it out in case anyone comes over it in the future.

I've posted some updates on this here: https://github.com/arduino/cloud-examples/issues/3#issuecomment-209627682.
Just incase anyone runs into this:

the root cert for the Azure IoT Hub domain needs to be flashed on your board. See the WiFi101-FirmwareUpdater read me for how to do so.

Since the credentials for the Azure broker are super long (password alone is 138 bytes). The buffer size (MQTT_MAX_PACKET_SIZE) in this library needs to be increased, the default size 128 bytes. I successfully connected after using a buffer size of 1280 bytes (this could be lowered with some experimentation). Since I was using a SAMD based board which has 32kB of RAM, a bigger buffer is not an issue. For AVR this would not be feasible.


Arduino IDE version

Does it have to be 1.6.x or can the current version (1.8.x) also be used?
If it needs to be the older version it would be great to state that explicitly in INSTALL.md and maybe explain why.

thanks for raising this issue! I've update the INSTALL.md :)


wlogout "logout" function hangs if activated by mouse click.  Hotkey ("e") works fine.

Hyprland Version
 System/Version info
<Paste the output of the command here>

Bug or Regression?
Bug
Description
Just got the latest hyprland-git today and did not have this behavior prior to it.
If I run wlogout and try to logout with a mouse click, it will hang until i hit a key.  If I use the hotkey for logout ("e"), it works just fine.  If I just type the command called by wlogout in a terminal ("hyprctl dispatch exit 0"), it also works just fine.    So, it seems to be an issue with the mouse click.
Lock, reboot, and shutdown all work just fine (I don't use suspend or hibernate on this machine).
How to reproduce
Call wlogout and attempt to logout using a mouse click.
Crash reports, logs, images, videos
No response

wouldn't that make it an issue with wlogout?

wlogout code hasn't changed in years and this issue started with the latest hyperland-git update.  My suspicion is that it's something to do with grabbing the mouse input on the hyprland side.

wlogout code hasn't changed in years and this issue started with the latest hyperland-git update. My suspicion is that it's something to do with grabbing the mouse input on the hyprland side.

if it is a regression mark it as one
do a git bisect (aka find the commit where it broke)

It's this commit: 5eeec8860e2dc8ff80dda26243778b5ecc923ca2
It's because the exit flag processing only happens inside of onKeyboardKey()
Even in the case where it 'works' it's actually firing on the e key-up event. If I navigate to the logout entry with the arrow keys and then hit enter, it usually misses the enter-up event, causing me to have to hit another key to trigger the exit.

I use wleave instead of wlogout. wleave can use existing wlogout configs, it's literally a drop in replacement. Try with that instead?

I use wleave instead of wlogout. wleave can use existing wlogout configs, it's literally a drop in replacement. Try with that instead?

I did actually, and the issue persist.  For now, I'm just using hotkey "e" to logout.

I'm not a developer so I don't really know "bug" vs "regression".

Bug is "it's always been an issue"
Regression is "it used to work, now vaxry broke it"

Fixing this involves not processing the exit flag inside of the keyboard event handler. But where to put it? I don't know the motivation behind the patch that moved it there, so I'm afraid that anywhere I do move it might just be reintroducing some issue this was meant to fix. Halp

I don't see why exits can't be processed in both onKeyboardKey and onMouseMoved, which should allow it to work.  I'm going to try a patch locally

That just means instead of having to hit a key, I can also wiggle the mouse. It doesn't address the fundamental race condition.

I don't see why exits can't be processed in both onKeyboardKey and onMouseMoved, which should allow it to work. I'm going to try a patch locally

It should quite frankly not be processed in either of those, what if you want to execute it from inside a script?

Yes, unless you are performing dispatch exit from a timer, it has to come from some input mechanism.  Mouse and keyboard covers most of the bases.

Yes, unless you are performing dispatch exit from a timer, it has to come from some input mechanism. Mouse and keyboard covers most of the bases.

I have a script that gracefully closes all applications first before closing hyprland.

It looks like the purpose of that commit is to prevent the cleanup from happening in the dispatch handler.  It is instead attached to the keyboard listener, but it should be able to work in any listener.  I've looked at the list of listeners in Compositor.cpp and there doesn't seem to be any per-frame listeners.  It shouldn't be too tough to use a different listener.  The surface onCommit should be called frequently enought to be able to handle the processing:
https://github.com/hyprwm/Hyprland/blob/main/src/desktop/WLSurface.cpp#L129
I'm debugging another issue right, if no movement has happened in this issue in a couple of days, I'll try a patch.

So I just tested moving this to WLSurface onCommit.  It works, but it's not as fast as using the input manager callbacks.  (Takes 3-5 seconds before exiting).
Since there are multiple surfaces, and not a single global like the input manager, I moved the exit signalling into the compositor, and the first event to hit the exit signal resets it, then requests the compositor exit.
My patch is against 0.36, not 0.37.1.
I'm going to look for another event to see if there is one which happens per-frame, even if I have to add the listener.

I forgot to attach the patch:
0001-Move-exit-trigger-to-surface.patch.txt

...and I've solved it.  monitorFrame is what I wanted.  Here's the patch to 0.36:
0001-Move-exit-trigger-to-monitor-frame.patch.txt

@vaxerski, can it be reopened? https://github.com/hyprwm/Hyprland/issues/4849#issuecomment-2113644323


chore() Merge dependencies from develop to main

What's Changed

chore(deps): update dependency release-it to v15.5.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/40
chore(deps): update dependency @types/jest to v29.1.2 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/41
fix(deps): update dependency firebase-admin to v11.1.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/42
chore(deps): update dependency eslint to v8.25.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/43
chore(deps): update typescript-eslint monorepo to v5.40.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/44
chore(deps): update dependency @types/node to v16.11.65 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/45
chore(deps): update node.js to v16.18.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/46
chore(deps): update dependency jest to v29.2.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/47
chore(deps): update dependency @types/node to v16.11.66 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/48
fix(deps): update dependency firebase-admin to v11.2.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/50
chore(deps): update dependency @types/jest to v29.2.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/51
chore(deps): update dependency jest to v29.2.1 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/53
chore(deps): update dependency @types/node to v16.11.68 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/54
chore(deps): update dependency eslint to v8.26.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/55
chore(deps): update dependency @types/node to v16.18.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/56
chore(deps): update typescript-eslint monorepo to v5.41.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/57
chore(deps): update dependency jest to v29.2.2 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/58
chore(deps): update dependency @types/node to v18 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/59
chore(deps): update dependency @types/node to v18.11.6 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/60
chore(deps): update dependency @types/node to v18.11.7 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/61
chore(deps): update dependency @types/node to v18.11.8 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/62
chore(deps): update commitlint monorepo to v17.2.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/63
chore(deps): update typescript-eslint monorepo to v5.42.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/64
chore(deps): update dependency @types/jest to v29.2.1 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/65
chore(deps): update dependency @types/node to v18.11.9 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/66
chore(deps): update dependency @types/jest to v29.2.2 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/67
chore(deps): update dependency eslint to v8.27.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/68
chore(deps): update typescript-eslint monorepo to v5.42.1 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/69
chore(deps): update dependency jest to v29.3.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/70
chore(deps): update dependency husky to v8.0.2 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/71
chore(deps): update dependency jest to v29.3.1 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/72
chore(deps): update dependency @nestjs/common to ^7.0.0 || ^8.0.0 || ^9.2.1 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/107
chore(deps): bump qs and formidable in /examples/nodejs/nestjs/typescript by @dependabot in https://github.com/hebertcisco/nestjs-firebase-admin/pull/109
chore(deps): update dependency prettier to v2.8.1 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/110
chore(deps): update dependency typescript to v4.9.4 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/112
chore(deps): update typescript-eslint monorepo to v5.46.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/113
chore(deps): update dependency @types/node to v18.11.13 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/119
chore(deps): update typescript-eslint monorepo to v5.46.1 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/120
chore(deps): update dependency @types/node to v18.11.14 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/124
chore(deps): update dependency @types/node to v18.11.15 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/126
chore(deps): update dependency eslint to v8.30.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/133
chore(deps): update dependency @types/node to v18.11.16 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/132
chore(deps): update dependency @types/node to v18.11.17 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/134
chore(deps): update typescript-eslint monorepo to v5.47.0 by @renovate in https://github.com/hebertcisco/nestjs-firebase-admin/pull/135

Full Changelog: https://github.com/hebertcisco/nestjs-firebase-admin/compare/v0.0.73...v

Codecov Report

Merging #140 (e8fe047) into main (4eb902a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #140   +/-   ##
=======================================
  Coverage   25.28%   25.28%
=======================================
  Files           9        9
  Lines         178      178
  Branches       56       56
=======================================
  Hits           45       45
  Misses        133      133

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


Create new example using Leaflet layer control

It would be useful to have an example showing how to include several CartoDB layers with Leaflet.

assign it whoever you want

@andrewxhill

Actually: http://bl.ocks.org/iriberri/074a71940dc606d98079
On Tuesday, May 26, 2015, Santiago Giraldo Anduaga<EMAIL_ADDRESS>wrote:

@andrewxhill https://github.com/andrewxhill
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb.js/issues/121#issuecomment-105661358.

--
Carla Iriberri
CartoDB

boom
On Tue, May 26, 2015 at 5:09 PM, Carla<EMAIL_ADDRESS>wrote:

Actually: http://bl.ocks.org/iriberri/074a71940dc606d98079
On Tuesday, May 26, 2015, Santiago Giraldo Anduaga <
<EMAIL_ADDRESS>wrote:

@andrewxhill https://github.com/andrewxhill
—
Reply to this email directly or view it on GitHub
<https://github.com/CartoDB/cartodb.js/issues/121#issuecomment-105661358
.

--
Carla Iriberri
CartoDB
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb.js/issues/121#issuecomment-105665388.

--
andrewxhill http://twitter.com/andrewxhill
http://cartodb.com

@iriberri why don't you add that example to examples folder?


[Visual Studio Code - Project Manager] the default open application be changed

Extension
https://www.raycast.com/MarkusLanger/vscode-project-manager
Description
I am using the VS Code Insiders version. Can I change the default open application?
Who will benefit from this feature?
No response
Anything else?
No response

You can. If you go to the extension's configuration, you can select from:

Visual Studio Code
Visual Studio Code - Insiders
VSCodium
VSCodium < 1.71

Bottom right in this image.

oh thanks, i see

Bottom right in this image. 这张图片的右下角。这张图片的右下角。  这张图片的右下角。  <img alt="Screenshot 2023-05-04 at 10 58 06" width="1112" src="https://user-images.githubusercontent.com/3605078/236158039-67a8c377-101c-4d51-9aaf-97a450

Bottom right in this image.

oh thanks, i see


nvim .9 breaking on yank.

nvim v0.9.0-dev
pop os
steps to reproduce
git clone https://github.com/LazyVim/starter ~/.config/nvim
wait for install.
f into a file
yy -> death.

Yeah, that's a known issue. For more information, check:
https://github.com/folke/noice.nvim/issues/298
The issue is caused by https://github.com/neovim/neovim/issues/21604


Support enforcement of NOT NULL column declarations

This commit enforces NOT NULL column declarations on write
in the Presto engine, so it applies to all connectors.  The
existing Postgres and Mysql tests named testInsertIntoNotNullColumn
were changed to check for the new error message, and a new test
with the same name was added to TestIcebergSmoke.
One possible concern with this commit is that the error message
issued by the Presto engine when writing a null to a NOT NULL
column is a different message than the Connector might issue
if no value was supplied for the NOT NULL column.  I think this
is ok, because the error messages supplied by the Connectors are
completely specific to the Connector.

Thanks!


vagrant/scripts: bump k8s to v1.18.2

Signed-off-by: André Martins<EMAIL_ADDRESS>

Coverage increased (+0.006%) to 44.643% when pulling 44387605ff281d5ad8c660a96258127f1d750ded on pr/bump-k8s-version-dev into 531e61f884ccfceaa249d6b2bd7e3baaf446068b on master.


patch-agx7-2023-3-2.tar.gz is not in gzip format

Hi, it seems the file is corrupted. You may want to double-check the integrity of each asset.
$ tar -zxvf patch-agx7-2023-3-3.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

$ gunzip ./patch-agx7-2023-3-2.tar.gz

gzip: ./patch-agx7-2023-3-2.tar.gz: not in gzip format

Hi Cohen, thanks for the reply. The file name was a typo and it's "-2".
But you gave me a good hint that I should use "tar -xvf" instead of "tar -zxvf."
Thanks for the heads-up. I'll close this one.


need to account for running tests in nested deployments with scope "inner"

if the expression eval scope is "inner" for a nested deployment, some of the tests won't work properly ( like variable/param not being used) - need to take a inventory of tests to see which need special handling and which do not.

If a template contains a nested deployment where evaluationoptions have scope==inner, then that nested template needs to be tested as it's own template, not as part of the json file it's currently in.  So some workflow could be:

parse template
does it contain any Microsoft.Resources/deployment where:

                "expressionEvaluationOptions": {
                    "scope": "inner"
                },

If so, extract the template property and call Test-AzTemplate on those contents (which would recurse becuse this can be nested)
See: https://github.com/bmoore-msft/AzureRM-Samples/blob/master/dynamicSecretId/azuredeploy.inline.json#L25-L45

If a template contains a nested deployment where evaluationoptions have scope==inner, then that nested template needs to be tested as it's own template, not as part of the json file it's currently in.  So some workflow could be:

parse template
does it contain any Microsoft.Resources/deployment where:

                "expressionEvaluationOptions": {
                    "scope": "inner"
                },

If so, extract the template property and call Test-AzTemplate on those contents (which would recurse becuse this can be nested)
See: https://github.com/bmoore-msft/AzureRM-Samples/blob/master/dynamicSecretId/azuredeploy.inline.json#L25-L45


Bracket computing

Provide a configurable device path resolver timeout
For some clouds, a device path resolver timeout of 500ms is too aggressive.
Providing a configurable way of being able to define it in the agents.json file.

Hello, I haven't received any responses or comments on this yet. Let me know if there are any questions or concerns regarding this change.

@krishnanrs Hmm. I've been thinking more about this change and looking over a few code paths. I've reopened https://github.com/cloudfoundry/bosh-agent/pull/79 and I think we'll pull that change in instead of making this configurable.

Will close this one.

Dimitri, appreciate you looking into this and agreeing to a change for setting a larger timeout value. However I still think that there is a value in making this timeout configurable.
Is there a possibility to accept both changes? I can re-submit the original change with a lower timeout value (maybe 5 secs. instead of 30 secs.). 500 ms. is definitely too aggressive in my opinion.

@krishicks one of our goals is eventually to get to a "generic" stemcell which means that bosh-agent should work out of the box with the same configuration for all iaas-es (slowly getting there...), so adding additional agent options would actually be going the other way.
given that we are going to use higher value for the timeout as you proposed, why do you want to make this value configurable?

@cppforlife I think you meant to tag @krishnanrs.
^_^

@cppforlife providing additional agent options avoid overriding hard-coded values, especially given that the go-agent needs to be compiled for all supported OS. Hence my preference is to use a slightly higher default value and also providing agent options.


Add features to distill template

While using the distill template, I noticed it lacked many features available in the regular post template, such as typograms, echarts, and other interactive elements. To address this, I included the necessary scripts and dependencies for these features in distill.liquid, referencing them from misc.liquid. Now, the distill template offers the same interactive functionality as the post template.

Have you tested this? Also, can you create maybe a new distill post with all these included in it, so we can demonstrate how to use and how they'll appear?

After testing, I verified that currently only the scripts {% include scripts/badges.liquid %} and {% include scripts/pseudocode.liquid %} cannot be used in Distill. Therefore, I removed these two lines of code from distill.liquid.

The other scripts have been validated successfully. I updated 2018-12-22-distill.md and added a tutorial in the blog on how to use these scripts.

Just missing prettier complaints and it will be merged.

I have reviewed the code and fixed the prettier issues.

Just missing the prettier complaints.

Just missing the prettier complaints.

Locally, Prettier confirms all files are correctly formatted, and the version I pushed passed Prettier checks on my machine. However, the GitHub Action still reports a Prettier failure.

This error was already fixed in the main branch. Just rebase your branch with main and it should fix this.

Thanks for your contribution.


Fail test on purpose

#patch#
Travis test

Visual Acceptance tests:
Changed
Firefox: Simple
     Diff Current Baseline
### PhantomJS: Simple
     Diff Current Baseline
### SlimerJS: Simple
     Diff Current Baseline


FCS and the Visual F# Tools

From time to time the various people involved in FSharp.Compiler.Service (FCS = http://github.com/fsharp/FSharp.Compiler.Service), Visual F# Tools (VFT = http://github.com/Microsoft/visualfsharp) and Visual F# Power Tools have been discussing what to do about moving VFT onto FCS.   Currently the Visual F# Tools are a bit of an outlier in the F# universe since they are the only tooling not built on FCS.  Eventual convergence here would be great.
Compared to the internal compiler service implementation in VFT, FCS contains a number things relevant to this discussion:

bug fixes and some features relevant to symbol reporting
the ability to check against library projects before the library project is compiled to a DLL on disk
a virtualized file system to allow checking against buffer contents rather than on-disk files
some changes to allow FCS to compile as a Silverlight component (these are likely to be discarded)
a revamped SourceCodeServices API (see vs\service.fsi) including better resilience in some cases
a revamped symbols API
a revamped expression tree API to walk the resolved form of TAST expressions
a hosted F# interactive component (there are a large number of changes in fsi.fs)
additions to allow the correspondence between symbols in signature and implementation files to be established more accurately
various modules like PrettyNaming are made public
a couple of micro features pulled over from the http://github.com/fsharp/fsharp repo such as the --gccerrors flag

These features are nearly all used by the Visual F# Power Tools.
You can see the overall diff between FCS and VFT by comparing the src/fsharp and src/absil directories of Microsoft/visualfsharp (OOB) and fsharp/FSharp.Compiler.Service (master). FCS is a series of additions + deletions over fsharp/fsharp which in turn is a series of additions+deletions over VFT (see below for information about the "deletions")
Bringing all these changes back wholesale and immediately into VFT is not likely to be to the taste of Microsoft considering the status of VFT as a long-term enterprise supported toolkit.  (That said, every other tool that ships F# editing capabilities effectively sits on all of this, so it's not entirely clear that Microsoft shouldn't as well, but that's ultimately up to the VFT owners at Microsoft. I expect they would want to take an incremental approach to this)
Achieving convergence can mean a number of things, here's the rough list of what's possible (though not all may be desirable):

Ensure that we can integrate new compiler and language functionality from VFT --> FCS repos
Ensure that the compiler implementations don't diverge by maximally aligning FCS and VFT through selective textual alignment
(a) Build a version of FCS in VFT and use it to implement VFT OR
(b) Use the nuget packages of FCS to implement VFT
Bring back bug fixes in FSharp.Compiler.Service into Visual F# Tools
Use FCS to implement new functionality in VFT
Take functionality from Visual F# Power Tools and put it in VFT
Publish a stable, known version of FCS as a public-facing component in Visual Studio, for the benefit of extra tooling like Visual F# Power Tools, and to halve the memory pressure on Visual F#

We have been able to do (1) for a while now.
Today I've submitted a set of somewhat tactical PRs to VFT to do much of (2).  These are just preparatory work to reduce the overall diff between FCS and VFT.  It's this work that's allowed me to write the catalogue of exactly what's in FCS above.
With this basis established, we can now consider what to from here.   For example, there is a choice between 3a and 3b - do we build a private FSharp.Compiler.Service.dll in VFT and modify the Visual F# Tools to use the updated copy of the compiler service API?  Or do we use the existing FCS nuget packages?
Because of the nature of VFT, it seems best to go down path 3a initially: Microsoft build a private copy of the FSharp.Compiler.Service.dll.  Indeed, currently Microsoft VFT already does this: there two components which are similar to FSharp.Compiler.Service.dll: FSharp.Compiler.dll and FSharp.LanguageService.Compiler.dll. There is also a second small adhoc compiler API into FSharp.Compiler.dll used by the test infrastructure.

Aside: Why does Microsoft use two compiler DLLs? This is to do with memory footprint in Visual Studio: FSharp.LanguageService.Compiler.dll doesn't include some components like the IL binary writer and ILX code generator, hence a lower footprint because of a smaller NGEN image. However I was always sceptical about the value of this micro-optimization - saving a few MB of 32-bit address space - and this may no longer apply now VFT is shipped as a separate component to the rest of VS.

Personally I think the ideal outcome for step 3a would be to have VFT building one private compiler service DLL which includes the new FCS API.
Looking into the long term, I think it would be great if a future version of Visual Studio included a specific FCS DLL as a public facing component, or at least for specific use by the Visual F# Power Tools.  But that's a long term goal and it's not on the roadmap for this repo yet, just an aspiration.

Aside: Why deletions? Roughly speaking http://github.com/fsharp/fsharp is a fork of http://github.com/Microsoft/visualfsharp which deletes all the vsintegration/... and some of the test suites that we can't easily run, and adds some features and tests relevant to cross-platform and Mono.     http://github.com/fsharp/FSharp.Compiler.Service is a fork of fsharp/fsharp which deletes everything except the code under src/absil/... src/fsharp/... needed to build FSharp.Compiler.Service.dll, and adds the build scripts need to test and publish that component as a nuget package)

Thanks for the detailed explanation.

@latkin I pushed the combination of the four PRs to branch https://github.com/Microsoft/visualfsharp/tree/fcs.  I think it's best to take the PRs one at a time though, so this is just a temporary combination branch in case you want to build and test that.

Does the whole of the short-term FCS source alignment comprise those 4 PRs? Or should we expect more along these lines?

Yes, that's it for now. The remaining code differences nearly all represent substantive changes that represent new functionality in FCS that is relatively hard to isolate.
Note that you can also view these PRs as a very thorough code review of FCS - I've been going over it line by line for the past 24 working hours - snipping out the non-functional changes and leaving the substantive changes (bug fixes, new functionality, revamped API, symbol API, expression API, hosted F# Interactive).
Getting these PRs into Microsoft\visualfsharp will really help keeping these repos in line and put us in good shape to make progress on the goals above when we choose to.

great @dsyme, i'd like to see more of these long term alignments and cleanup :smile: :+1:
Long term i hope there is an out of process service (like roslyn, out of vs process, easier to debug/profile for performance and usefull for other ides ), and VFT and VFPT (and others ide integrations ) are clients.

closing old discussion, since this phase of FCS alignment work is done


Added Postman API collection, updated README.md, more to come!

Just a small bit of contribution to your project. I stumbled onto your project this afternoon, after writing my own tools to inject a master blocklist of over 900k entries into NextDNS.
I created a quick Postman API collection mapping to "most of" the API endpoints in NextDNS, with a few tiny exceptions which I'll work out later (adding/deleting/blocking domains from the hashmap). I also added a boolean toggle for flipping the switches on/off for those bool options.
I'm going to be leveraging this heavily to create a Grafana dashboard of all of these analytics, which I'll also drop into extras/grafana when that's finished up.
Great work, keep it up!

This is truly amazing. Thank you for all the work that you've poured into document this for Postman. Truly appreciate it. Just give me around an hour to go over the changes and I will push the changes.
Thanks again @desrod,
@rhijjawi


TypeError: Cannot redefine property: Symbol(kBoundListener)

The following error is thrown when reusing the same function as an event listener for WebSocket:
TypeError: Cannot redefine property: Symbol(kBoundListener)

client.addEventListener('message', clientMessageListener)
client.addEventListener('message', clientMessageListener)

It is thrown because the kBoundListener symbol is trying to be redefined for another listener being attached:
https://github.com/mswjs/interceptors/blob/4fab617266b94e1c84235e355bad1e86687c1850/src/interceptors/WebSocket/WebSocketClientConnection.ts#L91-L96
Instead, we should check if kBoundListener is defined, and if it is, ignore that definition. That means you are reusing the same listener.

Released: v0.36.2 🎉
This has been released in v0.36.2!

📄 Release notes
📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.


Swift3 support question

I have a question about whether you have supported swift3?

Closing because issue does not contain completed Issue Template.


Inconsistence behavior when providing configurable values with run command

Observed this while running a single file.
Running bal file directly
D:\test\alpha4>bal run temp.bal -CGH_TOKEN=%packagePAT%
ballerina: unmatched command argument found: -CGH_TOKEN=

USAGE:
    bal run [--experimental] [--offline]
                  [<executable-jar | ballerina-file | package-path>] [-- program-args...]

Running generated jar
D:\test\alpha4>bal build temp.bal
Compiling source
        temp.bal

Generating executable
        temp.jar

D:\test\alpha4>bal run temp.jar -CGH_TOKEN=%packagePAT%
OK

D:\test\alpha4>

To pass a command line argument in the run command we have to use the following:
bal run temp.bal -- -CGH_TOKEN=%packagePAT%

Note the -- after the file name

Still, this is inconsistent. Source file requires  -- and the jar file fails with --. Technically there is semantic behavior, but from the user's point of view, this is confusing. @hevayo @sameerajayasoma @manuranga  Thoughts?

If you run bal run for module or bal file, it will go through the cli tool. So Cli bal run command will have its own options hence we need to pass the programs options or config values as args after '--'.
But for bal run program.jar which bypass the CLI run command and directly handle in bal script, which will be similar to java jar command. So if you bal run jar or use java -jar  then we do not need '--' which is by design

But from the user point of he executes a single command bal run @sameerajayasoma thoughts?


Randomly learned abilities only for singular jobs

I don't think there's any option to have a character start as a job with only 3-4 random abilities instead of a mastered for all of them, or having something like Blue Mage but instead of every single one mastered just a couple so it's balanced a little, maybe a check box next to number of abilities that says "only for this job
Also maybe the ability to only randomize certain jobs... sorry just thinking up additions as I write this out, you know just if you want to add it

Been playing the randomizer all day and having a blast, do you know if it's possible to change our Marche/Montblanc in party randomizer and maybe also put in bonus characters like Ritz/Babus?

@randoomdude, you're correct that there's nothing in the current version to specifically target a random number of abilities for specific jobs. The options are a number of random abilities across all jobs or mastering a random number of jobs. The first option sounds closer to what you're looking for, but not exact.
Marche and Monty must be in the party, but you can roll them as any race instead of being locked to human and moogle, respectively. I received another request to allow guest characters, so that is one we've heard people would like.

This has been added to version 3.2.3


Correctly populate target health check on existing records

This is a fix for https://github.com/kubernetes-incubator/external-dns/issues/720.
It uses the ProviderSpecific field of Endpoint to capture the value of EvaluateTargetHealth on existing ALIAS records in provider.Records(). It allows it to correctly delete those records in a later stage (provider.ApplyChanges).
For new records it uses the value of the --aws-evaluate-target-health flag.

For anyone who wants to try out this fix I pushed an image to:
registry.opensource.zalan.do/teapot/external-dns-test:v0.5.7-1-gf21f45b1

/LGTM

@linki we should merge this and release it ASAP.

/approve


PeerDiscovery liveness violation with four nodes

TLC2 Version 2.18 of Day Month 20?? (rev: 95d980c)
Running breadth-first search Model-Checking with fp 117 and seed<PHONE_NUMBER>450774076 with 1 worker on 10 cores with 7282MB heap and 64MB offheap memory [pid: 67426] (Mac OS X 12.3.1 aarch64, Homebrew 18.0.1 x86_64, MSBDiskFPSet, DiskStateQueue).
Parsing file /Users/markus/src/TLA/_specs/TLAplusFun/PeerDiscovery/MC.tla
Parsing file /Users/markus/src/TLA/_specs/TLAplusFun/PeerDiscovery/PeerDiscovery.tla
Parsing file /private/var/folders/7d/4x6z2cc91jl588ysynlc1tfc0000gn/T/tlc-6677445440072312092/TLC.tla (jar:file:/Applications/TLA+%20Toolbox.app/Contents/Eclipse/tla2tools.jar!/tla2sany/StandardModules/TLC.tla)
Parsing file /private/var/folders/7d/4x6z2cc91jl588ysynlc1tfc0000gn/T/tlc-6677445440072312092/FiniteSets.tla (jar:file:/Applications/TLA+%20Toolbox.app/Contents/Eclipse/tla2tools.jar!/tla2sany/StandardModules/FiniteSets.tla)
Parsing file /private/var/folders/7d/4x6z2cc91jl588ysynlc1tfc0000gn/T/tlc-6677445440072312092/Naturals.tla (jar:file:/Applications/TLA+%20Toolbox.app/Contents/Eclipse/tla2tools.jar!/tla2sany/StandardModules/Naturals.tla)
Parsing file /private/var/folders/7d/4x6z2cc91jl588ysynlc1tfc0000gn/T/tlc-6677445440072312092/Sequences.tla (jar:file:/Applications/TLA+%20Toolbox.app/Contents/Eclipse/tla2tools.jar!/tla2sany/StandardModules/Sequences.tla)
Semantic processing of module Naturals
Semantic processing of module Sequences
Semantic processing of module FiniteSets
Semantic processing of module PeerDiscovery
Semantic processing of module TLC
Semantic processing of module MC
Starting... (2022-05-09 08:59:24)
Implied-temporal checking--satisfiability problem has 2 branches.
Computing initial states...
Finished computing initial states: 1 distinct state generated at 2022-05-09 08:59:24.
Progress(5) at 2022-05-09 08:59:24: 6,501 states generated, 625 distinct states found, 0 states left on queue.
Checking 2 branches of temporal properties for the complete state space with 1250 total distinct states at (2022-05-09 08:59:24)
Error: Temporal properties were violated.

Error: The following behavior constitutes a counter-example:

State 1: <Initial predicate>
/\ dns_request_enabled = <<TRUE, TRUE, TRUE, TRUE>>
/\ peers = <<{}, {}, {}, {}>>

State 2: <Request_DNS line 28, col 5 to line 29, col 21 of module PeerDiscovery>
/\ dns_request_enabled = <<TRUE, TRUE, FALSE, TRUE>>
/\ peers = <<{}, {}, {1, 4}, {}>>

State 3: <Request_DNS line 28, col 5 to line 29, col 21 of module PeerDiscovery>
/\ dns_request_enabled = <<TRUE, FALSE, FALSE, TRUE>>
/\ peers = <<{}, {1, 3, 4}, {1, 4}, {}>>

State 4: <Request_DNS line 28, col 5 to line 29, col 21 of module PeerDiscovery>
/\ dns_request_enabled = <<TRUE, FALSE, FALSE, FALSE>>
/\ peers = <<{}, {1, 3, 4}, {1, 4}, {1, 3}>>

State 5: <Request_DNS line 28, col 5 to line 29, col 21 of module PeerDiscovery>
/\ dns_request_enabled = <<FALSE, FALSE, FALSE, FALSE>>
/\ peers = <<{3, 4}, {1, 3, 4}, {1, 4}, {1, 3}>>

State 6: Stuttering
Finished checking temporal properties in 00s at 2022-05-09 08:59:24
6501 states generated, 625 distinct states found, 0 states left on queue.
The depth of the complete state graph search is 5.
Finished in 00s at (2022-05-09 08:59:24)
Trace exploration spec path: ./MC_TTrace_1652111963.tla

b3cf945 fixes the bug
I guess my DNS had to be a little smarter...
I also got stuttering steps where there shouldn't be in the version of the spec with two variables. Then I added a third and this stopped being an issue.


Issue 26: Make name_generator hash configurable and complete the RFC 4122 implementation

NOTE: This PR includes contents from another already submitted, see PR history.  It should be committed before this one.
Deprecate name_generator
Adds name_generator_sha1
Adds name_generator_md5
Currently name_generator is a typedef for name_generator_sha1 to remain backwards compatible.
Deprecates old position of the sha1.hpp file (moved into detail).
Deprecates old position of the seed_rng.hpp file (modes into details).
Added public domain md5 implementation and modified it.

@Lastique I'd appreciate if you could look over my use of Boost.Concept here  I'm not sure it's really necessary.  I added the definition into the documentation as well and I updated

All the CI builds for uuid passed.


[MRG] Shorthand for prior of Real variables

This PR adds the shorthand (lower, upper, prior) for defining Real parameters. Also includes some cosmit changes.

Just some minor comments. Otherwise LGTM

Thanks! Comments addressed. Merging.


Drop v1alpha1 DevWorkspaces from DWO

What does this PR do?
This PR is for dropping support for v1alpha1 DevWorkspaces from the DWO. WIP because we still need to wait for the devfile/api changes.
This PR targets 0.11. See https://github.com/devfile/devworkspace-operator/issues/599#issuecomment-936462475 for more info
What issues does this PR fix or reference?
https://github.com/devfile/devworkspace-operator/issues/599
Is it tested? How?

PR Checklist

[ ] E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)

[ ] v8-devworkspace-operator-e2e: DevWorkspace e2e test
[ ] v8-che-happy-path: Happy path for verification integration with Che

Closing as out of date. v1alpha1 support is required for the time being as this apiVersion is used by OpenShift 4.9.


Crash: dyld: dyld cache load error: shared cache file open() failed dyld: Symbol not found

Issue Description
After adding the MagicSDK pod and run the app, the application gets crashes with the bellow crash log. This crash happens with the latest versions 2.2.1 and 2.2.0.
Crash Log
dyld: dyld cache load error: shared cache file open() failed
dyld: Symbol not found: __ZN5swift34swift50override_conformsToProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEPFPKNS_18TargetWitnessTableIS1_EES4_S8_E
  Referenced from: /Users/appdeveloper/Library/Developer/CoreSimulator/Devices/3AB65244-F53C-475D-8857-8F150635EE78/data/Containers/Bundle/Application/2DC78AB9-B909-4533-9D67-D3DAA9A51350/MagicSDK-Demo.app/Frameworks/MagicSDK.framework/MagicSDK
  Expected in: /Users/appdeveloper/Library/Developer/CoreSimulator/Devices/3AB65244-F53C-475D-8857-8F150635EE78/data/Containers/Bundle/Application/2DC78AB9-B909-4533-9D67-D3DAA9A51350/MagicSDK-Demo.app/Frameworks/PromiseKit.framework/PromiseKit
 in /Users/appdeveloper/Library/Developer/CoreSimulator/Devices/3AB65244-F53C-475D-8857-8F150635EE78/data/Containers/Bundle/Application/2DC78AB9-B909-4533-9D67-D3DAA9A51350/MagicSDK-Demo.app/Frameworks/MagicSDK.framework/MagicSDK
dyld: launch, loading dependent libraries

Podfile
target 'MagicSDK-Demo' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for MagicSDK-Demo
  pod 'MagicSDK'

  # Required for XCFramework
  post_install do |installer|
    installer.pods_project.targets.each do |target|
      target.build_configurations.each do |config|
        config.build_settings['BUILD_LIBRARY_FOR_DISTRIBUTION'] = 'YES'
      end
    end
  end
end

Environment
Xcode Version: 12.3 and 12.5
Swift Version: 5.3
Platform(s) running : iOS 14.3
macOS version running Xcode: intel - macOS Big Sur 11.1

Hi @kishanraja, I tried to reproduce it, but I'm not able to.
Could you try to do shift+k to clear the cache and reinstall the pods? Plz let me know if the error persists. 😄

Hello, @Ethella Thanks for looking at this.
I have tried this many times and create a new 2 - 3 fresh project but not solved. I just install the pod and run the app.
Here I attached a demo project link that might be helpful: https://github.com/kishanraja/MagicDemo.git
For now, I'm using the old version of SDK (v2.1.2) but it will also give us an error during the send transaction process
: Magic-SDK Error: DecodingError.typeMismatch(Swift.Int, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "response", intValue: nil), CodingKeys(stringValue: "error", intValue: nil), CodingKeys(stringValue: "code", intValue: nil)], debugDescription: "Expected to decode Int but found a number instead.", underlyingError: nil)) (code 4864)
let me know if you need more info.
Thank you.

Taking a look right at your repo now.
For the decoding issue, we are currently working on it.

@kishanraja I tried a couple of times to reproduce it but it still comes with no luck. And I also try to find relevant issues on the internet and I found no positive results.
Unfortunately, I guess I'll have to punt this issue and see if anyone else has encountered the same issue and fill in more context to help triage it.

@Ethella  Thank you for checking this. I will try my side to find more context and will update you. If possible can you please sare the environment like build architectures and Xcode version etc. so I can try to run the project on that environment. Or is there any external setting required for the build settings?

@Ethella Thank you for checking this. I will try my side to find more context and will update you. If possible can you please sare the environment like build architectures and Xcode version etc. so I can try to run the project on that environment. Or is there any external setting required for the build settings?

There's no more external configuration or build architectures required other than the ones listed in the doc.
Pod 1.10.1
Xcode 12.5 (12E262)
Big Sur 11.4

swiftc -version
Apple Swift version 5.4 (swiftlang-1<IP_ADDRESS> clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin20.5.0

Thanks, @Ethella.  Your information helped me. After updating Xcode from 12.3 to Xcode 12.5.1, it works fine.

Thanks, @Ethella. Your information helped me. After updating Xcode from 12.3 to Xcode 12.5.1, it works fine.

Glad it helps! 😄


Support vite 5.0

Description
The plugin should work with Vite 5. Currently it does not, since it returns the plugin type from v4, which is not compatible with the plugin type from v5.
Suggested solution
Upgrade the Vite dependency to v5.
Alternative
No response
Additional context
No response
Validations

[X] Read the FAQ.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

I'm not sure about this bug report. I am using the dts plugin with vite 5.0.2 and it works without any issues so far. Do you have a minimal repo where I could see the problem?

I also got issues, when i upgraded to vite 5 . it precisely throws error like
The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.
Your configFile is invalid: {{path}}

It threw an error when required, check the stack trace below:

TypeError: (0 , vite_plugin_dts_1.default) is not a function

I am using it as import dts from 'vite-plugin-dts';

@DesDevCharan https://github.com/padcom/mrdr-example/blob/master/packages/c/package.json
It's a test for my mrdr tool, but it contains a project built with vite 5, using the dts plugin to rollup the types. And it works, no problem. The thing that I did, however, was to set the type of the package to "module". Maybe that'll help you out...

Dunno if related but, now the dist includes the src for the d.ts so the types of the project are not resolving correctly anymore.
Does anyone else have this issue?

@alvarosabu Yea at some moment my dts plugin stopped producing index.d.ts in library mode and now i'm relaying on that src folder.

HAving the same issue, I changed my types property in package.json by
"types": "./dist/src/index.d.ts",
however other packages using this one now have this kind of error
There are types at 'shared/dist/src/index.d.ts', but this result could not be resolved when respecting package.json "exports". The 'shared' library may need to update its package.json or typings.

@alvarosabu @Xenossolitarius @mbret Seems you having a issue differences form this, please create a new issue with reproduction.

My issue is the same, the typescript files are generated under dist/src rather than dist/ previously. To fix the issue I just changed entryRoot to "src" and the types are now correctly generated under dist/ as before.

@mbret Well, but this issue is about the plugin's type definition.

You are right, my fault. the initial issue is indeed not what I was talking about. The further discussion on the issue itself led to this problem being talked as well.


WFLY-4473 timeout exception does not include EJB name

Linux Build 6198 is now running using a merge of b140f9106ab8c5b50cb3d8e84c9a975d2f8ff1e6

Windows Build 1310 is now running using a merge of b140f9106ab8c5b50cb3d8e84c9a975d2f8ff1e6

Linux with security manager Build 1174 is now running using a merge of b140f9106ab8c5b50cb3d8e84c9a975d2f8ff1e6

Linux with security manager Build 1174 outcome was SUCCESS using a merge of b140f9106ab8c5b50cb3d8e84c9a975d2f8ff1e6
Summary: Tests passed: 822, ignored: 356 Build time: 0:14:08

Windows Build 1310 outcome was SUCCESS using a merge of b140f9106ab8c5b50cb3d8e84c9a975d2f8ff1e6
Summary: Tests passed: 2840, ignored: 416, muted: 1 Build time: 0:52:29

Linux Build 6198 outcome was SUCCESS using a merge of b140f9106ab8c5b50cb3d8e84c9a975d2f8ff1e6
Summary: Tests passed: 2840, ignored: 416, muted: 1 Build time: 0:56:21


Update scodec-bits to 1.1.24

Updates org.scodec:scodec-bits from 1.1.20 to 1.1.24.
GitHub Release Notes - Changelog - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scodec", artifactId = "scodec-bits" } ]

labels: library-update, semver-patch

Superseded by #110.


Views vs External Tables & FK's

Hi Guys, from this article it is actually not clear on what's the difference between external views and external tables. Plus, would be good to understand if we could link external views/tables. E.g. we have DWH facts table and Dates table and want to have a FK to simpler analyze it in PowerBI

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

ID: 0653685e-b445-b5c2-e901-0e86685e3ba4
Version Independent ID: 7f29d81d-fd6e-eabc-d438-75a9e53b9b08
Content: Create and use views in SQL on-demand (preview) - Azure Synapse Analytics
Content Source: articles/synapse-analytics/sql/create-use-views.md
Service: synapse-analytics
Sub-service: sql
GitHub Login: @azaricstefan
Microsoft Alias: v-stazar

@yahorsi - Thank you for bringing this to our attention. We are evaluating your inquiry and will provide an update to you shortly.

Thank you for reaching out @yahorsi. PKs and FKs are not supported for external tables and views.
External tables do not support filepath and filename functions at this moment which means you cannot do partition elimination on external tables. For example: if your data is partitioned into folders (month=/month=/*.parquet), you could eliminate partitions using OPENROWSET/VIEW+WHERE clause, while for external tables you can't. We are working on supporting these functions with external tables which will enable partition elimination on external tables. Other than that, there is not much of a difference from usage and performance perspective.

@azaricstefan  L: Thanks for the comment .
@yahorsi  ; We are going ahead and clsoing this issue for now .


Added LearnAppMaking to iOS development company blogs

Added LearnAppMaking to iOS development company blogs. Thanks! 🙏

Thank you 👍


artwork image isn't always correct

artwork returns COMObject unknown, don't know how to fix (yet)

erm why issue urself


Compose key not respected

Looks like goneovim doesn't respect my Compose key (Plasma/Wayland).
I set the compose key by going to Settings → Keyboard → Advanced → Position of Compose Key → Right Alt.
Goneovim ignores this. When I press the right alt I get a weird question mark symbol. The right alt works fine in all other applications.
Steps to reproduce:

Set compose to right alt Settings → Keyboard → Advanced → Position of Compose Key → Right Alt.

Type a digraph / accent. For instance press Right Alt then - then >.

This should produce →. It does this on all applications, except goneovim where it produces an undefined character.

@gi1242
Hi, Thanks for this issue report.
Hmmm, goneovim's key handling is heavily based on Neovim-qt, but this problem appears to be unresolved on the Neovim-qt side as well. https://github.com/equalsraf/neovim-qt/issues/181
Also, it seems to me that more user examples are needed to elaborate on the issue. (I don't think your report of the problem is wrong, but it seems to me that the OS configuration is also very much involved, and I would expect a situation where some people are fine and others are having problems).

Strange. I just tested on my system: the compose key works fine in neovim-qt, but doesn't work in goneovim. Is there anything I can do to help you reproduce it?

I have the same issue using the official binary. Building goneovim from source did solve the issue on my sice.
The main difference is that I have the latest qt 5.15 installed whereas goneovim official binaries are built against Qt 5.14.2.
The second difference is that I have the qtwayland module installed, but I tried with QT_QPA_PLATFORM=xcb and compose-key still worked.
My guess is that updating Qt on the CI should get rid of the issue (and maybe adding the qtwayland could be a nice addition)

@rainDiX
Thanks for comment! That information is very helpful.
@gi1242
I update the Qt version for building goneovim linux artifact.
Would you confirm that compose-key works with this artifact?
https://github.com/akiyosi/goneovim/actions/runs/3128139266

@akiyosi the compose-key still do not work with this binary.
My best guess know is that some Qt modules are missing. After some digging, the install-qt-action seems to install qtwayland and qtx11extras libraries, but they seems to be ignored when the bindings are generated. Maybe some dependencies like libxcb-xkb are missing.
I'm testing things on my side and I'll comment back here if I find anything relevant.

I update the Qt version for building goneovim linux artifact.
Would you confirm that compose-key works with this artifact?

Unfortunately it didn't work. (Something was wrong with the artifact though; it wouldn't run natively under Wayland, and needed XWayland.). I can try buidling from source this weekend...

@gi1242 @rainDiX
Thanks for confirming!
It seems that qtwayland is not a valid module name but qtwaylandcompositer is.
Would you please check if this CI artifact solves the problem?
https://github.com/akiyosi/goneovim/actions/runs/3149172021

Somehow the artifacts always start with the message
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""

and then just run under xwayland. (The compose key problem is present in this case.) I'll try building form source and report back.

I just built from source both with 56341a43817549844a68229f55bb41262d50949c, and with the latest nightly (c87cba6). It runs under Wayland directly now; however the compose key is not respected by either.

@gi1242
Sorry for the late reply.
I have created a goenovim built based on the latest version of Qt.
Could you please confirm that it works with the artifacts generated by the following CI?
https://github.com/akiyosi/goneovim/actions/runs/3247244936

@rainDiX
If you have time, could you please show me the dependencies of the goneovim binaries you have built? For example, I would like to know the results of the ldd /path/to/goneovim or lddtree /path/to/goneovim commands.

Hi, here's the output, looking at my build, it is not very clean.
$ ldd ./goneovim
		linux-vdso.so.1 (0x00007ffe2997e000)
	libQt5Widgets.so.5 => /home/rain/Development/packages/goneovim-git/src/go/src/github.com/therecipe/env_linux_amd64_513/5.13.0/gcc_64/lib/libQt5Widgets.so.5 (0x00007f7af7400000)
	libQt5Gui.so.5 => /home/rain/Development/packages/goneovim-git/src/go/src/github.com/therecipe/env_linux_amd64_513/5.13.0/gcc_64/lib/libQt5Gui.so.5 (0x00007f7af6a00000)
	libQt5Core.so.5 => /home/rain/Development/packages/goneovim-git/src/go/src/github.com/therecipe/env_linux_amd64_513/5.13.0/gcc_64/lib/libQt5Core.so.5 (0x00007f7af6200000)
	libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f7af737a000)
	libQt5Svg.so.5 => /home/rain/Development/packages/goneovim-git/src/go/src/github.com/therecipe/env_linux_amd64_513/5.13.0/gcc_64/lib/libQt5Svg.so.5 (0x00007f7af5e00000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f7af5bc9000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f7af7292000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f7af7272000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f7af59e2000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f7af7c55000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f7af7258000)
	libicui18n.so.56 => /home/rain/Development/packages/goneovim-git/src/go/src/github.com/therecipe/env_linux_amd64_513/5.13.0/gcc_64/lib/libicui18n.so.56 (0x00007f7af5400000)
	libicuuc.so.56 => /home/rain/Development/packages/goneovim-git/src/go/src/github.com/therecipe/env_linux_amd64_513/5.13.0/gcc_64/lib/libicuuc.so.56 (0x00007f7af5000000)
	libicudata.so.56 => /home/rain/Development/packages/goneovim-git/src/go/src/github.com/therecipe/env_linux_amd64_513/5.13.0/gcc_64/lib/libicudata.so.56 (0x00007f7af3600000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f7af7253000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f7af724e000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f7af60c3000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f7af7c7c000)
	libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007f7af592a000)
	libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007f7af69cc000)
	libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f7af3565000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f7af3422000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f7af6098000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f7af69c5000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f7af69bd000)

@gi1242 @rainDiX
Hey all, just wanted to say hi.
I think I was able to create a goneovim binary that integrated qtwayland.
I do not have the wayland environment on my hands at the moment, so I am not able to test this immediately. I would appreciate it if you could test this new binary in the wayland environment to see if the compose key works.
https://github.com/akiyosi/goneovim/actions/runs/3256119760

Thank you so much! This worked perfectly for me.
Now I can start using goneovim again. (No compose key was a dealbreaker for me, so I had to use a different front end in the meantime.)
Thanks again!

@gi1242
Thanks for confirming!
Now I would like to merge these changes.
This issue is closed.

I have an issue with the compose key on X. As soon as I press the right alt key it shows this weird symbol

Compose key shows this: �
����
�


Add implementation of widget ADFFViewer

It allows rendering a video stream based on an Area Detector FFmpeg plugin PV prefix.

Thanks Emilio, this looks very nice and is quite small and clean :+1:
Can I ask why you provided the prefix prop rather than just using pvName as is? Is this how the current implementation works?

It's a way of organizing elements in a tree, area detector plugins use a prefix for all its PVs, if we pass the prefix instead of the pvName that will allow the widget to be expanded easily (the same widget could be using many different PVs)... so I assumed there will be a area detector hierarchy with a top level area detector widget passing the prefix to each one of the plugins widgets, I think it's cleaner letting each plugin's widget deal with all its related PVs.

@willrogers this widget is fairly simple but looks to me like a subset of a potential Image component. Should I work on the more general component and make this fit into that or work with Emilio to clean up this component to merge it?

Good point, an image component wouldn't look much different. We should make a generic image component then see whether we need any extension to handle ffmpeg.
First priority is getting changes from the demo merged and deciding what the default app looks like,

It would be easy to pull an image widget from the RawADFFComponent, however I would still keep this widget as it is, decoupled from an image widget, the reason is that an image could have a huge number of transformations and CSS properties without affecting performance, if we use an image widget for the ADFFViewer, then every change in CSS properties or any transformation we do in that widget will be applied to every single frame of the stream... making performance much worse,  thus it's nice keeping them separate and having RawADFFComponent with a minimum number for transformations (just re-sizing  to the parent container)

Closing as we now have a widget for camera streams in cs-web-lib.


Stop CI when Godot crash

Closes https://github.com/godotengine/godot/issues/61600
Added simple check for specific messages in logs.
This already works fine in Godot fuzzer for a while, so I don't expect any strange CI failures
In future it is possible that most of this checks won't be needed, but this require to fix this strange leaks which comes from thirdparty libraries(probably xserver) but to test it I need to recompile mesa from source or add debug symbols to OS
Direct leak of 72704 byte(s) in 1 object(s) allocated from:
    #0 0x7f69ee7b3868 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7f69c1ca1335  (/usr/bin/godot4s+0x8bc4c335)
    #2 0x7f69c1c61bda  (/usr/bin/godot4s+0x8bc0cbda)

Direct leak of 6304 byte(s) in 4 object(s) allocated from:
    #0 0x7f69ee7b3a66 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7f69dde6630f  (<unknown module>)

Direct leak of 1024 byte(s) in 1 object(s) allocated from:
    #0 0x7f69ee7b3c9e in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163
    #1 0x7f69dde6554a  (<unknown module>)

Thanks!

Cherry-picked for 3.5.


Configure the platform for DTC support

Enable the necessary Kubernetes functionality for DTC, and populate it with the
appropriate API object types.

Can you rebase on #274? There are a few conflicts to [resolve](Tested after rebase at https://github.com/dghubble/coreos-baremetal/tree/dtc).
Are there there followup docs or links that should go with this? To answer user questions "what do I get by enabling this?" and "how do I verify its working?".

Rebased. I'll work on docs.

Expecting to do this in this PR or another? We could have a dedicated dtc.md document under Documentation.

I don't think baremetal is the place for it, other than just telling people how to enable it - the rest of the docs aren't going to depend on the deployment method

I'll try out a deploy with this.

This distributed trusted computing work was ahead of its time. Its not the focus at this moment, but I hope to revisit it someday.


How to declare a function with a "fixed" type parameter

I would have looked for existing issues or questions, but I wasn't sure how this should be worded. Please let me know if this kind of question has already been asked.
I am trying my hand at flow for the first time, and I've come across a case that I can't quite see how to express with flow.
I have a binary search function that takes an array of strings or numbers and a string or number to search for:
export function binarySearch(array, value) {
    const index = 0;
    ...
    const element = array[index];
    ...
    if (element < value) {
    ...
}

I've trimmed down the implementation to just the parts relevant for this discussion.
So this function can take either numbers or strings (normally it would just take a number, but the library I'm writing can accept strings for this function). My first pass at annotating it was this:
export function binarySearch<T: string | number>(array: T[], value, T): number {
    ...
}

When I ran flow, I got this error:
src/utils.js:8
  8:         if (element < value) {
                           ^^^^^ number. Cannot be compared to
  8:         if (element < value) {
                 ^^^^^^^ string

src/utils.js:8
  8:         if (element < value) {
                           ^^^^^ string. Cannot be compared to
  8:         if (element < value) {
                 ^^^^^^^ number

I assumed that by using a type parameter rather than just this:
export function binarySearch(array: string[] | number[], value: string | number) {

that it would be implied that the function takes a single subset of T for all instances of T rather than any T for each instance of T. So invocations with matching types (e.g. array of numbers and a number) would pass, but invocations with mismatched types (e.g. array of numbers and a string) would fail.
Is there a way to express what I'm trying to express with flow? I realize that I can accept either strings or numbers and then enforce a particular type inside the function, but I want this to be performant, and manual type coercions are something that I'd like to avoid because they aren't strictly necessary.
If there isn't, I'm happy just using any, but I would hope that this is possible.
Thanks!

Immediately after posting this, I tried this:
declare function binarySearch(array: string[], value: string);
declare function binarySearch(array: number[], value: number);

And it worked! Sort of unfortunate that this can't be done inline with the function declaration.
I'm going to keep this open because I consider the solution above to just be a workaround for the actual feature I'm suggesting.

In your first export example you have a value , T not a value: T. Is this what you tested?

Sorry, I copied that down manually. It was supposed to be value: T. That is what I tested

And it worked! Sort of unfortunate that this can't be done inline with the function declaration.

You should be able to express this with intersections. From your example it would probably look something like this:
type Search =
  & ((array: string[], value: string) => number)
  & ((array: number[], value: number) => number);

const binarySearch: Search = (array, value) => {
  …
}

You shouldn't need to declare the type separately either but I find it tends to make these cases more readable. You can also probably do it polymorphically by adding further constraints but in this case it doesn't seem worth it.

Would be nice if this worked, but this attempt on the Try Flow page didn't work. The interface just silently coerced the whole function signature to any, and it wasn't possible to create any errors, and the typedef doesn't fix it.

@STRML here is a version that seems to work.

Something is not quite right - appears the definition is being respected but they're being silently coerced to any types inside the function body.

@STRML you can make it work if you use mixed or unions for the type of the arguments and then guard type specific operations with typeof checks. See here.
I think this is just a limitation of how intersection checking works with functions. Flow would have to check the function against each branch of the intersection individually otherwise. So I think the general approach is to use a less precise type locally and then use an intersection type at the top level to provide a cleaner interface.

By the way, since the interface will enforce that the function can only be called with elements of array having the same type as value, you could just do a single typeof check for value and use coercions for the rest. It's kind of ugly but it should be okay.

The typeof checks there are a lot of manual work for something Flow should be able to figure out on its own - and if you screw it up, there's no type error. It's apparently manually coercing to any. I'm going to keep investigating if there's a way to jostle it in the right direction.

The typeof checks there are a lot of manual work for something Flow should be able to figure out on its own - and if you screw it up, there's no type error.

If you use the version I linked to, you will get type errors if you try to do something that flow doesn't recognize as being allowed. The same is true if you use mixed.
The typeof checks only serve to refine the type information. So if you have foo: number | string you can refine to one of the type branches locally. But that doesn't mean you could suddenly treat foo as an Object or Function or some other type.

Strangely, it seems you can refine to absolutely anything and Flow will accept it, and even ignore the refinement as a return value.
Also interestingly, the union refinement actually sticks in bar, it just seems to get lost with the Array type.

Interesting. I think being able to refine to anything is perfectly fine (since only valid branches should ever be reached) but you shouldn't be able to refine to a wrong type and then return. So the one in foo looks like a bug to me.
The second one I've seen before and I'm not sure if it's something the flow devs intend to address or not. It would be nice if it worked but I suspect it doesn't because of how the refinements are tied to the conditional. For instance, if you only did a return from within a branch where the type was refined to string or number, it would be okay.
If you return outside of one of those branches, the type refinement information is not available anymore. But if you don't have a top level return, flow complains that you may implicitly be returning undefined (in case none of the conditional branches are ever taken).
So I think in order to make the second one work flow would at least need some sort of exhaustivity checking. That should be possible when you have a finite union as a bound like here, but it's more problematic in the general case.

Actually I guess the return in the first one isn't really a problem either since that branch well never be taken. It does seem a little counterintuitive though.

I didn't get caught up with this entire thread, but this does seem like a bug with refinements and polymorphic types:
function bar<T: string | number>(value: T): T {
  if (typeof value === 'number') {
    return Math.abs(value);
        // ^ number. This type is incompatible with the expected
        // return type of some incompatible instantiation of `T`
  } else {
    return value;
  }
}

function bar(value: string | number): string | number {
  if (typeof value === 'number') {
    return Math.abs(value);
  } else {
    return value;
  }
}

@thejameskyle not sure but my guess is that when you write this
function bar<T: string | number>(value: T): T

Flow will enforce that the return type must be compatible with any subtype of number | string (for example string which is a subtype of number | string). So when you return a number Flow complains because is not compatible with string.
Can anyone confirm my assumption?

Using overload is the right approach.


Question - committers not showing - what is required to display that?

We are using Github as our SCM and pipelines. Committers are not showing despite ticking the option. Is there anything that needs to be enabled for this to work? Perhaps a minor doc. could help if this a widely known issue but after Googling I could not find anything

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Known issue. Here's my PR for the fix:
https://github.com/jan-molak/jenkins-build-monitor-plugin/pull/293
You could build that locally and install manually into your Jenkins.

Thanks a lot!