check for vcvarsall.bat normally before guessing pre-defined paths

Some people (like me) may have the path to their vcvarsall.bat in their system path. This will check for it and just use it directly if available before using the pre-defined directories.

I don't think this is an useful approach, and it doesn't always work.
Since Microsoft stopped putting VS information in environment variables, there is a different recommended scheme.
Use one of the Developer Command Prompts that is provided as part of the installation of Visual Studio or Visual Studio Build Tools.   This will cause the search path and all of the environment variables to be set as part of the opened Command Prompt.  vcvarsall will also have been run.
This will set some environment variables such that a batch script can tell that the build environment is established.   This works no matter where Visual Studio is installed and does not depend on knowing the path to anything, the version being run, etc.
I made an alternative version of build-windows.bat that does that and more as VCrayApp.bat.  You can find the 0.1.0 beta release (working but unannounced until documentation completed) at
nfoTools VCrayApp.

@derpy54320 thanks for the improvement but I agree with @orcmid on this change.


How to debug ruby program?

It is easy to debug PHP with vdebug and xdebug.
I almost develop with ruby recently, and how to debug ruby with vdebug?

Hi @wusuopu,
Sorry that it's taken so long to get back to you. There is actually some documentation on debugging with ruby in the vim help file for vdebug. Run :help VdebugSetUpRuby to see it.
However, ruby is not as well supported as PHP, so you may run into some issues.
Thanks


feat(coral): Allow users to delete clusters

Linked issue
Resolves: #2282
What kind of change does this PR introduce?

[ ] Bug fix
[x] New feature
[ ] Refactor
[ ] Docs update
[ ] CI update

What is the current behavior?
There is not way to delete clusters from Klaw currently
What is the new behavior?

Add context menu to Clusters table row with Delete option (will also have Edit option later)
Add ability to delete clusters
Do not show if user does not have the permission addDeleteEditClusters

https://github.com/Aiven-Open/klaw/assets/20607294/635b0ca7-4425-47cb-b576-0c3592125d4e
Other information

Added the possibilty to pass React.ReactElement as children to Dialog
The copy is still being worked on by @harshini-rangaswamy

Requirements (all must be checked before review)

[x] The pull request title follows our guidelines
[x] Tests for the changes have been added (if relevant)
[x] The latest changes from the main branch have been pulled
[x] pnpm lint has been run successfully

@mathieu-anderson and @programmiri
For the copy, let's change Delete to Remove. "Remove" is better here as we are clearing or removing the cluster association in Klaw. For ref: https://aquarium.aiven.io/43ae72f19/p/925433-word-list/t/678211
Also, I suggest updating the label next to the delete icon to "Remove" instead of "Delete." We have something similar in the Aiven Console, for example.

Scenario 1: When users cannot remove cluster as it is associated with an env
Remove cluster
'DEV' is linked to an environment and cannot be removed from Klaw. Unlink the environment to proceed.
Scenario 2: When users can remove clusters
Remove cluster
Confirm removal of 'TEST2'. The cluster will be excluded from Klaw.
Buttons: Cancel, Remove

@harshini-rangaswamy implemented the changes here: 35d9e5e

@harshini-rangaswamy implemented the changes here: 35d9e5e

Looks good, thanks!

@programmiri regarding putting the connect button in the dropdown, I considered it, but I decided against because:

it is different in nature: in the dropdown, it is actions on the cluster: delete and dedit. In the button, it's an informational help.
I believe that the connect information would be something that users would want easy access to, as opposed to operation which seems unusual in a normal flow (delete and edit)

Regarding accessibility, yeah, this is for sure an issue :/ But I think it should probably be acted on at the DS level?
At any rate, I think we can modify this later, as it's not central to the functionality. Well, except for the accessibility issues, which are a little tricky to address...

Yes, your thinking with the button makes sense 🤔  I still would verify with Kate, as I remember a discussion about this (with Mustafa maybe?) and the "rule" was: if there more than one action, it should be a menu. But that may not be applicable for this case.

But I think it should probably be acted on at the DS level?

It's a colour and focus visibility issue, that's nothing that is planned in the near future to be looked into. We could maybe check if we can apply a simple css fix for this, but that's out of scope for this PR I think!

Kate has seen the UI, as I asked here if a modal worked in the context of deleting the cluster, so I think she doesn't have any opposition to what is currently implemented. But I can ask another confirmation ^^

No if she has seen it that's perfect! :D


Replacing ExpectedException on async method is not adding aync on lambda expression

Old code
[Test]
[ExpectedException(typeof(InvalidCalcException), ExpectedMessage = "Invalid calculation passed.")]
public async Task FailedCalculationThrowsException()
{
      var task = calculator.PerformNewCalculationAsync(new CalculationArguments("DivideAnythingByZero"), CancellationToken.None);
      await task; //throws exception
}

After migration
        [Test]
        public async Task FailedCalculationThrowsException()
        {
			var ex = Assert.Throws<InvalidCalcException>(() =>
			{
				var task = calculator.PerformNewCalculationAsync(new CalculationArguments("DivideAnythingByZero"), CancellationToken.None);
				await task; //throws exception
			});
			Assert.That(ex.Message, Is.EqualTo("Invalid calculation passed."));
        }

But then I am getting

This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.

I could solve it using
var ex = Assert.Throws(async () =>
Maybe either the migrator can skip all async methods or it adds the async to lambda expression. I don't know which one would be better idea.

Thanks for raising this issue. Let me see what it's feasible in the next days.

Just fixed, a new version (1.1.2) should be available on nuget in a few minutes.

Thank you for the fix. It worked.


Allow usergroups in typeahead with or without @ prefix.

Earlier typeahead did not include user groups when user typed @ in the pil input, thus there were complains about having
confusing flow for adding user groups to streams. So we allow user groups in pill typeahead as this helps in having a less confusing flow in adding user groups to streams.
Fixes: #22448.

Screenshots and screen captures:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

I'm not sure about second point mentioned in issue description,

Sort groups above other users in the typeahead when @ is typed.

As we use centralized logic for sorting typeahead items in almost all of the places where pill typeahead is used. So I think it would helpful to discuss it before moving ahead with making changes for it.

Hm, the thinking here is that typing @ in this context likely means that you're trying to input a group (as opposed to a stream or a user's name).
What would be helpful in terms of discussion? Please feel free to kick one off in whatever stream is appropriate.

@m-e-l-u-h-a-n how much work would it be to have the prefer_user_group option affect the sorting too?


Do not use a search box as the main control to add features

When the feature type search box isn't focused, it does not contain any useful information, but potentially confusing information. The unfocussed search box should be replaced with a "Add feature" button for the following reasons:

The button seems to be more intuitive to add a feature.
The button could be smaller than the seach box to save valuable space in the topbar.
The seach box might be confusing due to containing the feature type of a recent search while the user is drawing a different feature by using a favorite, or while is diferent feature is selected.
In browse mode with open sidebar two search boxes are shown, which might also confuse new users.

When pressing the add feature button, the button should open the focused seach box in place of the button.

Sorry, but we are committed to the new search bar UI.  We'll rewrite the walkthrough, so it wont' be confusing..


Critical bug: ign-fuel download unusable after last update - creates regular files instead of directories

Environment

OS Version: Ubuntu 18.04
Source or binary build? binary 5.1.1

Description

Expected behavior: ign fuel download works
Actual behavior: It fails with errors like:

[Msg] Downloading model [https://fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures]
[Err] [Filesystem.cc:459] Failed to create directory [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures]: Not a directory
[Err] [Zip.cc:152] Error creating directory [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures]. Do you have the right permissions?
[Err] [LocalCache.cc:415] Unable to unzip [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/ctu_cras_norlab_marv_sensor_config_1.zip]
[Err] [SystemPaths.cc:369] URI [https://fuel.ignitionrobotics.org/1.0/OpenRobotics/models/CTU_CRAS_NORLAB_MARV_SENSOR_CONFIG_1/tip/files/meshes/evetar_lens.dae] resolved to path [/meshes/evetar_lens.dae] but the path does not exist

The permission denied is there because the subdirectories Fuel should create are actually regular files:
$ ll "/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials"
-rw-r--r-- 1 robot robot 0 May  1 01:22 /home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials

Steps to reproduce

$ rm -rf "~/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1"
$ ign fuel download -v4 --url "https://fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1"
Downloading model:
  Name: ctu_cras_norlab_marv_sensor_config_1
  Owner: openrobotics
  Server:
    URL: https://fuel.ignitionrobotics.org
    Version: 1.0

[Msg] Downloading model [https://fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures]
[Err] [Filesystem.cc:459] Failed to create directory [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures]: Not a directory
[Err] [Zip.cc:152] Error creating directory [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures]. Do you have the right permissions?
[Err] [LocalCache.cc:415] Unable to unzip [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/ctu_cras_norlab_marv_sensor_config_1.zip]
Download failed.

I haven't found any relevant commit in ign-fuel. Might it be related to https://github.com/ignitionrobotics/ign-common/commit/cdfbe87f5b632dca6caa07e881519641e76fa7f0 ?

@nkoenig This is a usability blocker, requires attention ASAP.

Fix underway in https://github.com/ignitionrobotics/ign-common/pull/209

Workaround - gradually try to download the models, remove the wrong files, make the folders manually, and repeat.
$ rm -rf ~/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials
$ mkdir -p ~/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures
$ ign fuel download -v4 --url "https://fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1"
Downloading model:
  Name: ctu_cras_norlab_marv_sensor_config_1
  Owner: openrobotics
  Server:
    URL: https://fuel.ignitionrobotics.org
    Version: 1.0

[Msg] Downloading model [https://fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures/battery.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures/chassis.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures/chassis_emissive.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures/flipper_color.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/materials/textures/ouster-os0.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/basler_ace.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/basler_ace2_pro.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/battery.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/belt.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/big_wheel.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/chassis.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/deck.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/evetar_fisheye_lens.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/evetar_lens.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/flipper.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/flipper_arm.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/flir_boson.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/item20.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/item_angle40x40.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/mobilicom.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/mote_deployer.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/motor_housing.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/motor_housing_mirrored.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/ouster-os0.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/reflector.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/small_wheel.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/meshes/tfmini_plus_lidar.dae]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/metadata.pbtxt]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/model.config]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/model.sdf]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/thumbnails]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/thumbnails/1.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/thumbnails/2.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/thumbnails/3.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/thumbnails/4.png]
[Dbg] [Zip.cc:175] Created file [/home/robot/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models/ctu_cras_norlab_marv_sensor_config_1/3/thumbnails/5.png]
Download succeeded.

Fix in https://github.com/ignitionrobotics/ign-common/pull/209

Fix underway in ignitionrobotics/ign-common#209

Thanks!

Addressed by https://github.com/ignitionrobotics/ign-fuel-tools/pull/178


several error logs of the last few days

hey, just FYI:
config.yml:
RUN_EVERY: 0.3 (I understood this doesn't matter anymore?)
TEST: True
log #1:
working...
HTTPSConnectionPool(host='api.binance.com', port=443): Max retries exceeded with url: /api/v3/ticker/price (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x000001A023CD9C10>: Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))
HTTPSConnectionPool(host='api.binance.com', port=443): Max retries exceeded with url: /api/v3/ticker/price (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x000001A023CD9D90>: Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))
HTTPSConnectionPool(host='api.binance.com', port=443): Max retries exceeded with url: /api/v3/ticker/price (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x000001A023CD9C10>: Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))
HTTPSConnectionPool(host='api.binance.com', port=443): Max retries exceeded with url: /api/v3/ticker/price (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x000001A023CD9D90>: Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))
...

log #2:
working...
HTTPSConnectionPool(host='api.binance.com', port=443): Read timed out. (read timeout=10)
HTTPSConnectionPool(host='api.binance.com', port=443): Max retries exceeded with url: /api/v3/ticker/price (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x000001E9D7DC9520>, 'Connection to api.binance.com timed out. (connect timeout=10)'))
HTTPSConnectionPool(host='api.binance.com', port=443): Max retries exceeded with url: /api/v3/ticker/price (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x000001E9D7DC68B0>, 'Connection to api.binance.com timed out. (connect timeout=10)'))
...

log #3:
working...
HTTPSConnectionPool(host='api.binance.com', port=443): Read timed out. (read timeout=10)
APIError(code=0): Invalid JSON error message from Binance:
<title>502 Bad Gateway</title>

502 Bad Gateway

nginx

HTTPSConnectionPool(host='api.binance.com', port=443): Read timed out. (read timeout=10)
HTTPSConnectionPool(host='api.binance.com', port=443): Read timed out. (read timeout=10)
...

I had the same error for response #1
https://github.com/CyberPunkMetalHead/binance-trading-bot-new-coins/issues/31

RUN_EVERY is obsolete now yes. I've come across the same issues, as above. They might be due to a brief drop in the Internet connection but can't verify that. I was expecting the try and except block to resolve this.


[BUG]-The method JoinMapHelper.GetJoinMapBase(string) has been removed in latest release.

Describe the bug
Some plugins rely on this method. Can we get this method added back in and marked as deprecated.

Please try hotfix-174 and let me know if if fixes the issue. If it does, we'll get it into a new release shortly.

I don't see hotfix-174 on builds repo yet. I did built that version and tested, so far it looks good.


Improvements for Offline File Cache

When managed identity (or any AAD authentication) is used to connect to App Configuration, the user need to provide Key, IV and SignKey as part of OfflineFileCacheOptions.
We should allow OfflineFileCache used with AAD auth but throw a more helpful exception when the above condition is detected.
https://github.com/Azure/AppConfiguration-DotnetProvider/blob/de3fc18aad838ede93a4796f924a803b67656f7b/src/Microsoft.Extensions.Configuration.AzureAppConfiguration/OfflineFileCache.cs#L247
See https://github.com/Azure/AppConfiguration/issues/101 for more details fo the discussion.

If the user connects to the App Configuration store using a connection string and specifies one or two (not all) of the three parameters Key, IV and SignKey, we can handle it in several ways.

Use the connection string for encryption and ignore the user specified options. This allows the offline cache to work with auto-generated values for all parameters based on connection string.
Throw an error that either all three or none of the options should be set. Since the user's intention here might be to use custom parameters for encryption, it lets the user know that all three are required, and fails if partial input is provided.
Use the user-specified values for encryption parameters that were specified, and auto-generate the remaining parameter values from the connection string. This ensures that the user-specified values are actually used, and the ones that were skipped are auto-generated.

@zhenlan @MSGaryWang @jimmyca15
Which of these approaches do you think is better? I prefer the last one.

Here is a summary of the issues and proposed changes for the offline cache based on my discussion with Drago and Jimmy. The current plan is to address these issues together as a breaking change in the 4.0.0 release for the configuration provider, instead of fixing some of these partially in our next 3.0.1 release. Let me know if I missed anything.
Issues with Current Implementation

We do not support offline cache to be used if a connection string is not being used to connect to the configuration store.
The encryption and signing key parameters are optional. If these are not set, we auto-generate these from the connection string. This is a bad practice since the connection string is not meant to be used for the purpose of encryption or signing.
In the default scenario, we use the same auto-generated key for encryption as well as signing. Using a separate key should allow us to spread the risk in case one of the keys is compromised and improve the security of the data.
We expose IV (initialization vector) as a public property in OfflineFileCacheOptions to be overridden by the user. This is an internal implementation detail that could be hidden from the user and simplify the public interface.
We attempt to load the offline cache when we fail to fetch the key-values from the configuration store during initial load or refresh all scenario even when the server returns a 401 (Unauthorized) or 403 (Forbidden) status code. In this case, we should clear the offline cache since the user no longer has access to the store.

Additional Feature Improvements to Offline Cache

Allow users to specify the encryption algorithm to use to encrypt the data (currently SHA256).
Allow configuration refresh to also update the offline cache.
Set up offline cache to expire after N days and allow users to configure TTL for the cache.
Update initial configuration load to retrieve settings from the offline cache before updating them with the configuration store for improved development experience.

Any updates on this?  Did it make it into the 4.0 release?

This didn't make it into the 4.0 release. We are working on a redesign of the feature. It involves a bit more work. We didn't want to hold the 4.0 release for this.

@zhenlan Is there a workaround for this issue in the meantime?

@zhenlan Is there a workaround for this issue in the meantime?

Hi @bvirkler, we are evaluating how Offline Cache is used in different applications. Could you please help us understand the problem you are trying to solve by using Offline Cache?

We're using App Configuration for apps hosted on-premises.  We wanted to use offline cache to minimize the impact of a loss of connectivity to Azure.

We decided to completely remove offline caching capabilities. Please see this announcement for more details: https://github.com/Azure/AppConfiguration-Announcements/issues/20


add xmerl to applications list

this adds xmerl to the applications list. without it, xmerl is missing in (exrm-)releases.

Thanks, I'll release a patch version for this.

Hey guys,
I'm having issues making a release with mix release:
===> Provider (resolve_release) failed with: {error,
                                                     {rlx_prv_release,
                                                      {failed_solve,
                                                       {unreachable_package,
                                                        xmerl}}}}

==> ERROR: "Unable to find application xmerl. See the debug output for more information."

erl/OTP 19 and elixir 1.3.2

So I had to install erlang-xmerl (on ubuntu), issue solved.
(should we document it?)

I haven't experienced (or heard of) the issue on Ubuntu before. How was Erlang installed, from an apt repo or from Erlang Solutions? Either way, I'd welcome a note about it in the README.


Implement SEP-10 2.1.0 Support

TL;DR
The SEP-10 protocol has been updated to relax the requirements of the single Manage Data operation included in SEP-10 challenge transactions, and should be implemented by October 21st. On this date the SDF will announce the SDK updates to Anchors and Wallets, urging them to update as soon as possible.
Background
To provide context, the SEP-10 2.0 changes replaced SEP-10 challenges' Manage Data operation anchorName key with a home_domain key. However, we quickly realized there was confusion and misunderstanding about the value of the home_domain parameter introduced in most SDKs earlier. Specifically, some users of the SDK believe the home_domain value is the home domain used to request the SEP-10 challenge, while others believe it is the home domain that requires the JWT authentication token.
This is problematic because SDK's implemented equality checks on the home_domain value of the Manage Data operation, so mismatched domains would result in client-server (wallet-anchor) incompatibility.
SEP-10 2.1.0 Changes
The following changes have been made to the SEP-10 protocol:

Clients are no longer required to validate the home_domain value in a SEP-10 challenge's first Manage Data operation
SEP-10 challenge transactions may now have additional Manage Data operations as long as the source account of the operation is the SEP-10 server's SIGNING_KEY

Note: additional Manage Data operations will be added in future changes, so any added Manage Data operations added by the issuer of the challenge will need to come after the Manage Data operations defined in this document

References
SEP-10 2.1.0 Changes
Go SDK SEP-10 2.1.0 Support
JavaScript SDK SEP-10 2.1.0 Support
Looking Forward
Soon after SEP-10 2.1.0 is implmenented and announced, the SDF will ask SDK's to upgrade to SEP-10 3.0, but no action needs to be taken for this yet.

subscribing  to issue notifications

Done in release: https://github.com/Soneso/stellar-ios-mac-sdk/releases/tag/1.9.1


checkAuthentication

i can not login to quay.io
PHP Catchable fatal error:  Argument 1 passed to Symfony\Component\OptionsResolver\OptionsResolver::resolve() must be of the type array, string given, called in /data/www/vendor/jane/open-api/src/Client/QueryParam.php on line 60 and defined in /data/www/vendor/symfony/options-resolver/OptionsResolver.php on line 744

Can you provide an example of the failing code ?


Getting Error when i run it

My file is attached below. Please rename to compile_commands.json to test.
I am getting python errors when i try to run below. I tried in Windows and WSL ubuntu.
'compdb -p . list > compile_commands.json'
Traceback (most recent call last):
File "/home/jthomas1/.local/bin/compdb", line 8, in
sys.exit(main())
File "/home/jthomas1/.local/lib/python3.10/site-packages/compdb/cli.py", line 291, in main
command.execute(config, args.args)
File "/home/jthomas1/.local/lib/python3.10/site-packages/compdb/cli.py", line 89, in execute
included_by_database = builder.build(database)
File "/home/jthomas1/.local/lib/python3.10/site-packages/compdb/includedb.py", line 271, in build
for compile_command in database.get_all_compile_commands():
File "/home/jthomas1/.local/lib/python3.10/site-packages/compdb/core.py", line 50, in
return itertools.chain.from_iterable((db.get_all_compile_commands()
File "/home/jthomas1/.local/lib/python3.10/site-packages/compdb/backend/json.py", line 39, in get_all_compile_commands
return map(self._dict_to_compile_command, self._data)
File "/home/jthomas1/.local/lib/python3.10/site-packages/compdb/backend/json.py", line 56, in _data
self.__data = json.load(f)
File "/usr/lib/python3.10/json/init.py", line 293, in load
return loads(fp.read(),
File "/usr/lib/python3.10/json/init.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
compile_commands - Copy.json

Nevermind had to run:
compdb -p ./ list > temp.json


Global search broken when using vue-good-table in DOM template

The table in my project is defined as follows:
<vue-good-table
        id="data-table"
        :columns="workerTableColumns"
        :rows="workerTableData"
        :paginate="true"
        style-class="table table-bordered table-striped"
        v-bind:row-style-class="getThisRowClassAndId"
        :global-search="true"
        :sortable="false"
        :per-page="50"
>

With 1.19.0 search works in my table. Starting from 1.19.2, search produces an error in the console:

@advicepyro thanks for pointing this out, fix coming up shortly

@advicepyro this should now be fixed in 1.19.3

im on vue 2.5.13 and vue beta.7 and this is still the problem.


codacy integration

Coverage remained the same at 100.0% when pulling 38c1b406c41c715f0414b0166decb1b553f2eeec on codacy into e75b392102d2f61b8e51089f7d59d1eb8a9201de on master.

Coverage remained the same at 100.0% when pulling 7b13890442742a218f9d04c044674244db87f1fd on codacy into e75b392102d2f61b8e51089f7d59d1eb8a9201de on master.


PostgreSQL binding for Spring-Petclinic-Microservices

This unit is by Spektra to add PostgreSQL binding for the sample app.

@Aryan-CC please add necessary instructions for the PostgreSQL binding

I am ok with this PR
What's the plan to update the app configurations and the guides to use postgresql?

Hi @selvasingh,
Do you want me to add the instructions for PostgreSQL configurations in docs directory of this repository?
If yes, do you want me to create a new files for PostgreSQL instructions?

yes as discussed


Storing and requesting access tokens / login flow

When someone logs in with github the only data that returns is the "code" then you can get the access token and then you get finally the username. This process has to happen everytime? Even if I store all this information, I have nothing to lookup the access_token again. Is this true?

The access_token: username mapping is typically stored in a database on the back-end outside of node-github.


FormBuilderSignaturePad to image

Hello,
How I can convert the value of FormBuilderSignaturePad to an image.
Appreciate the help.
Regards.

How about to save to a file?

import 'package:path_provider/path_provider.dart';
import 'dart:io' as io;

var path = (await getApplicationDocumentsDirectory()).path;
var file =  new io.File('$path/${DateTime.now().toUtc().toIso8601String()}.png')..writeAsBytesSync(data);
print(file);


Must be timezone aware

Recently getting this error from signer.py  from signed_time variable --- ' ValueError('Must be timezone aware') while constructing asn1crypto.core.UTCTime'
I think the fix to remove this error is to pass the timezone using pytz. Please check.
datetime.now(tz=pytz.utc).

I have changed datetime.now to datetime.utcnow.
Please check if this is sufficient

ok that should also work.  Thanks

Travis says a build error, so currently requires Pytz as you suggested


Document logical replication tables

Source:
https://github.com/crate/crate/tree/master/server/src/main/java/io/crate/replication/logical/metadata/pgcatalog
https://www.postgresql.org/docs/current/catalog-pg-publication.html
https://www.postgresql.org/docs/current/view-pg-publication-tables.html
https://www.postgresql.org/docs/current/catalog-pg-subscription.html
https://www.postgresql.org/docs/current/catalog-pg-subscription-rel.html
Checklist

[ ] Added an entry in CHANGES.txt for user facing changes
[ ] Updated documentation & sql_features table for user facing changes
[ ] Touched code is covered by tests
[ ] CLA is signed
[ ] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

retest this please

retest this please

retest this please


docs: updated the readme.

Updated the readme to match the current state of the app.

Looks good! It captures the entire additional API process correctly and is clear to understand. The additional comments regarding A2 and A3 work is also reflective of the work we did and is correct, nice job!


Assigning to @const used in goog.string.Const.from expression should result in error, not just warning

ConstParamCheck intends to enforce that the argument to goog.string.Const.from is a compile time constant; i.e. should produce a compilation error in code where this is not so.  goog.string.Const is primarily used in security-related APIs, such as the goog.html.TrustedResourceUrl type.
ConstParamCheck in turn relies on the InferConsts pass, which in turn essentially trusts the @const annotation.  However, ignoring an @const annotation only results in a compiler warning, not an error.
For example:
http://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520SIMPLE_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250Avar%2520goog%2520%253D%2520%257B%257D%253B%250Agoog.string%2520%253D%2520%257B%257D%253B%250Agoog.string.Const%2520%253D%2520%257B%257D%253B%250Agoog.string.Const.from%2520%253D%2520function(x)%2520%257B%257D%253B%250A%250A%250A%252F**%2520%2540const%2520*%252F%250Avar%2520y%2520%253D%2520'foo'%253B%250A%250Afunction%2520evil(foo)%2520%257B%250A%2520%2520y%2520%253D%2520foo%253B%250A%2520%2520return%2520goog.string.Const.from(y)%253B%250A%257D%250A
Ideally, assigning to an @const that is used as part of a goog.string.Const expression should result in a compilation error, not just a warning.

We can also stop trusting IS_CONSTANT_NAME at https://github.com/google/closure-compiler/blob/fb05a42b/src/com/google/javascript/jscomp/Var.java#L130 and trust only IS_CONSTANT_VAR. If I understand it correctly, IS_CONSTANT_NAME is used for @const (even if overridden) and IS_CONSTANT_VAR is used for variables the compiler thinks are constant. Any IS_CONSTANT_NAME that is not overridden should be also IS_CONSTANT_VAR.

If you want this warning to be an error, just add --jscomp_error=const to the compiler command line.


Maplibre(Mapbox) Adapter: Source "td-point" already exists.

if the layer of td-point already exists, it shows the error of Source "td-point" already exists for Maplibre adapter when setMode is called.
I think we can check at the below code whether the source already exists, and only add source if it is not there
https://github.com/JamesLMilner/terra-draw/blob/868018e34d4806f13676794fbcd55870dd544d10/src/adapters/mapbox-gl.adapter.ts#L52-L61
I faced this bug because I am storing the entire style.json in the database and restoring it. So in the second time, these sources and layers are already in style, in such case, the plugin does not need to add sources again

Hey @JinIgarashi thanks so much for raising this - let me experiment with this and your PR and get back to you properly. I am actually in the middle of a PR for the other bug on the issue tracker to do with handling clicks which I think may resolve this.

@JinIgarashi I'm just looking at this and trying to understand why this would be happening. The source/layer should never be added twice - it is only added one time and the cleared up when the adapter is unregistered.
Would you be able to share some of the code to reproduce the issue? Specifically am interested what you mean when you say

faced this bug because I am storing the entire style.json in the database and restoring it

Look forward to resolving this for you!

Hey @JinIgarashi
Thanks for getting back to me. This sounds like an exciting project, would love to see how I can help :)
I think I see what you are doing, let me see if I can provide some guidance. I hadn't anticipated people storing the whole source/layer somewhere before but that's an interesting use case/approach. Let me suggest how I would recommend handling this :)
I would suggest instead of storing the whole style object, instead you can use Terra Draws mechanisms to do a similar sort of thing.
For stopping you could do something like this (pseudocode):
const snapshot = terraDraw.getSnapshot()
toLocalStorage(terraDrawDataKey, snapshot)
terraDraw.stop()

Then you can restore it you can do something like this:
const snapshot = fromLocalStorage(terraDrawDataKey)
terraDraw.addFeatures(snapshot)

This keeps it in the lifecycle of Terra Draw and should achieve what you are trying to do. Here Terra Draw will handle all the styling that you have passed to the specific modes you use. I am going to add a section in Common Patterns guide to explain how to do this full flow and give an example.
Let me know if this is helpful, if not I can work with you more to make this work!

@JinIgarashi appreciate your persistence here! Okay, let me know how you get on - I'm happy to help you here to make sure this works as this is a very common use case. I will aim to get some good documentation around this as soon as possible.

Hey @JinIgarashi just wanted to check how you were getting on with this?

I have updated the documentation guides to cover exporting and restoring data from Terra Draw - see it here: https://github.com/JamesLMilner/terra-draw/blob/main/guides/2.STORE.md
I am going to close this issue in a little while if there's no follow up. Feel free to open a new issue if you have any further problems after that 👍🏻

@JinIgarashi no problem! Happy to help where I can. Don't hesitate to ask any more questions or let me know if you get stuck on anything 👍🏻


elevation plot (or Icon) missing when using mobile Browser

Hi; as already pointed out in the google group, the elevation plot (or Icon for plot in lower right corner) is missing on maps.openrouteservice.org when using Android or IOS Browser.
This is a real bummer, as it renders this great app/website useless during a bicycle tour. Whereas it otherwise has features which NO other routing App has - especially the avoid hills / set max steepness feature.
It would be great, if this issue could get priotized (and fixed) soon!

Hi;
I tried to test ‚it‘ - i.e.:
„it is now possible to set the visibility of the heightgraph from the settings.“
However, there is nothing in the settings to do toggle the heightgraph (or I am blind)
Can you pls clarify?
Thank you, Heiner
Von<EMAIL_ADDRESS>Gesendet: Donnerstag, 9. August 2018 17:38
An<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Betreff: Re: [GIScience/openrouteservice-app] elevation plot (or Icon) missing when using mobile Browser (#234)
Closed #234https://github.com/GIScience/openrouteservice-app/issues/234 via d939576https://github.com/GIScience/openrouteservice-app/commit/d939576d84f0a46617295f7b6f94aad13b830596.

Hi @heinerolli,
These changes are still unreleased but will be live within the next days (hopefully tomorrow).
best regards


Fix insecure option for chart pull/push

What this PR does / why we need it:
This PR is based on the work in #8477. In that PR, the original author proposed to add insecure and plain-http options to helm chart push/pull commands.
This PR adds more TLS options to helm chart pull/push and addresses some comments from the reviewers by adding more registry client options to keep Run signature.
This PR also makes the insecure-skip-tls-verify, cert/key file options of helm pull/install work with oci registry.
close #6324

Hi @jdolitsky, can you please help review this?

@jdolitsky , can you please take a look at the latest one? I made some changes so that the same registry client can be used by different subcommands.

@jdolitsky are there pieces here we should keep around after #9782 is merged? Looks like there is some resolver code as well as some ocigetter fixes in here.

Is there an ETA when this PR be merged?


Fix broken link:node.md

Fix broken link:node.md

NOTE: Please check the “Allow edits from maintainers” box below to allow
reviewers fix problems on your patch and speed up the review process.
Please delete this note before submitting the pull request.

This change is

/lgtm

Thanks, @zhangxiaoyu-zidif

@caesarxuchao my pleasure and honor =)


[backport] Fix cupyx.scipy.ndimage.zoom for outputs of size 1 when mode is 'opencv'

Backport of #7192 by @hadipash

/test mini


refactor then controller to update discussion so it returns newly updated data

isn't this suppose to be done in the frontend
re fetching data??

@Horlakz No reply?

when a data is updated, it needs to return the new data that includes the update

@struckchure Ohh I get you now, alright

close this issue na


Makefile should build in parallel by default

Invoking make should build translation units in parallel (think: make -j $(nproc)).
It does not at the moment:
https://github.com/osmcode/libosmium/blob/ccaab086d46c8298f8b57d443cd2779e7573f0c9/Makefile
Is there a reason for this @joto?
(Just stumbled upon this, called make, went for a coffee and it was still running when I came back)

The "wrapper" Makefile shouldn't really be there. Instead people should use CMake directly, so they can set all options etc.

I have removed the Makefile in 76e153d2c72bbc6472a7a408bd1f5c7157330c1c.


web interface error

SERVER_ADDRESS=<IP_ADDRESS>:8012 POSTGRES_PASSWORD=ropassword TIMEZONE=America/Mazatlan docker compose up --build -d

Hello @mikrotickets
I noticed 2 details here:
1- SERVER_ADDRESS should contain the name that you will be accessing the server. In your case, it should be routerfleet.zerolan.network. Do not declare a port here, it will not work as you expect and probably will break django.
2- Looks like you are using a proxy in front of routerfleet. Your proxy is serving https:// and you are querying the routerfleet nginx over http. Your proxy should point to the https address.
Yesterday I noticed that my redirect from http to https was being overwritten by the default nginx virtual host (the page you are seeing)
With this adjustments, it should work fine ;)

I am experiencing the same issue. I am running Routerfleet on a non-default port, specifically port 3443, and without modifying the Django configuration files, I am encountering CSRF errors when using the IP in SERVER_ADDRESS. When I use the IP and port, I receive a 'Bad Request' error.
Perhaps we should consider adding an option to build a Docker image that allows the CSRF option to be set to <IP_ADDRESS>/0. I only use Routerfleet within my LAN, so there is no attack surface here. While I could expose Routerfleet to the internet and assign a domain to it, I do not want to expose such a sensitive service.

Disabling the CSRF protection is not recommended due to security concerns. even if the routerfleet installation is not exposed directly to the internet.
routerfleet deals with important information, such as multiple router address and passwords. I don't believe in lowering security settings for this case.
I didn't tested running the project in a different port to check if declaring SERVER_ADDRESS=hostname:port will work or not.
To change the port, you need to change the nginx entry on the docker-compose file.
The SERVER_ADDRESS variable needs to have the name that is displayed in your browser unless you have a reverse proxy with extra settings.
If you configure the SERVER_ADDRESS properly, you will not have issues with csrf.

@mikrotickets i'am facing same issue, so i fix this problem by editing entrypoint.sh inside container "routerfleet". Just add port to end of this string and restart container, unfortunately this step is necessary after each update of container :( but it works :)

Hello there, I fixed this issue in the last  build.
Just configure your .env file with the port declared in SERVER_ADDRESS line.
example: SERVER_ADDRESS=example.com:8443
You will also need to change the port mapping in docker-compose.yml file.
Thanks for pointing this out.


Text display support

The C++ micro::bit runtime includes a 5x5 font, and support for scrolling text display.
I wrote some Rust code to do the same in 2019 (it's the main reason why the display code goes via a Render trait rather than just expecting a bitmap).
I copied the 'pendolino3' font from microbit-dal, which is MIT-licensed.
You can see the original implementaion in rmicrobit (though it can be improved now const generics are available).
I think it would be nice for the microbit crate to have at least an example showing how to do text, and I've now got some time to look at these things again.
Do you think it would make more sense to add this support to the display::nonblocking module (parallel to image.rs), or to do this in a separate crate like tiny-led-matrix?
At present the font code returns BitImages, which are defined in microbit's image.rs.

Text display support would be amazing!
I personally think it would be best in a separate crate with an example in this crate. I really like the batteries included approach you get with the official micro:bit runtimes. They certainly make getting started a little easier. I feel like one of the goals of this project should be to introduce people who may not be familiar with embedded programming or Rust programming to the embedded Rust ecosystem and it's norms. One of those norms seems to be small libraries that solve specific problems and can be plugged together.
If we do go with separate crates I think it would be good to figure out a good way of directing users towards other crates that work well on micro:bit and they may be interested in.
What are your thoughts?

That seems reasonable.
Making a separate crate is easy enough; the one complication is getting at BitImage.
If I understand correctly, microbit-common won't compile without specifying either the v1 or the v2 feature.
So if I made a new crate depend on microbit-common so it could get at BitImage, I think the new crate would itself need v1 and v2 features, even though nothing in it should care about the micro:bit version.
I think to start with the expedient thing will be to duplicate BitImage in the new crate; then we could think about the best place for it to live.

With const generics could BitImage and GreyscaleImage live in tiny-led-matrix?

I don't think Rust is quite up to doing BitImage::new for an arbitrary size yet. I'd want array::from_fn but that's not const, and currently nightly-only anyway.

I don't have any cleverer ideas for what to do with BitImage, and it's not a large piece of duplication (most of the code disappears at runtime), so let's just close this.


Data Transactions lost following Meteor Logout.

In our application we are trying to clear out our GroundDB record on logout and then refresh the web page. However, when this happens, we find that GroundDB is refilled (the data remains).
The Remove function is working (proven with console logs) but the 'remove' action seems to get rolled back or lost on a page reload, within a given time period.
It seems to be a timing issue.
The following function demonstrates the issue
myDB = new Ground.Collection('privateStuff', {connection: null});
function logoutAndClear()
{
// Clear Data
myDB.remove({});
// Log out of Meteor
Meteor.logout(function(err) {
        // On successful logout, refresh page (don't re-load source from server)
        location.reload(false);    // If you remove this line - it works.
    });

}

https://github.com/GroundMeteor/db#additional-api

Thanks for your reply. I've tried the "removeLocalOnly()" call, and the "clear" call. removeLocalOnly doesn't seem to do anything at all. clear suffers from the same issue.
In this case, the GroundDB is local only {connection:null}, it contains data generated on the mobile device, that I want to stick around - so GroundDB seems like a good choice.  However, if users log out intentionally - we want to clear the data out and refresh the page.
The logout above is essentially a distraction The following Code also demonstrates the issue ( I ran it in the Chrome console).
function clearDB() {
    myDB.clear();
    location.reload(false);
}

I'm guessing there is some asynchronous call going on here , that I need to wait on (?)

I'm wondering why https://github.com/GroundMeteor/db/blob/connection-driver/groundDB.client.js#L223-L248 isn't working?

Thanks, I think that explains it.
I see the local Storage function clear has a callback, but we're just passing in 'noOp' so not waiting for it to complete.
This Works : - perhaps the 'clear' function needs a callback parameter for cases like mine.
function logoutAndClear() {
    myDB.grounddb.storage.clear(function() { location.reload(false);});
}

I've made a pull request, but sorry I messed it up a little - it's come in as 104 - not linked to this issue.


disable python2 travis-ci

This PR removes Python2 travis-ci testing :tada:
As a part of technical debt, the appropriate changes are now in place within the .travis.yml to commence iris-grib tests.... however, there are 5 errors and 10 failures that require to be addressed.
I'll raise a separate issue to cover this, see https://github.com/SciTools/iris/issues/3447.

Hi @bjlittle Just to check I've understood this...
To actually re-enable the iris-grib tests, we need to also insert a mention of iris-grib into the requirements/all.txt file,
as " all"  is what gets added to $CONDA_REQS_GROUPS within .travis.yml, when it runs without the TEST_MINIMAL flag .
Yes?

P.S.
To install iris-grib under Python3 for testing, we will also need to install eccodes-python explicitly with pip, as iris-grib currently does with this conda requirement and this pip install
Yes?

@pp-mo This is a bit of a mess, and we need to sort this out, but I'd highly recommend that is done outside this PR...
Anyways, in an attempt to clarify the iris-grib dependency actually lives in the requirements/extensions.txt. However, the extensions.txt is not referenced anywhere. It may have been at some point previously, either implicitly baked into the requirements/gen_conda_requirements.py or within the .travis.yml, but certainly not now. Infact, within the extensions.txt there is an empty #conda: directive, which means that the requirements/gen_conda_requirements.py will skip this for conda, but not pip.
This leads me to believe that iris-grib was dealt with in a bespoke way within the .travis.yml, as it is kinda now. The other factor is that if we use conda to install iris-grib then we need to do so with --no-deps otherwise the PR version of iris that travis-ci is meant to be testing is clobbered by the conda-forge version of iris pulled in by iris-grib - and the fun factor there is that the conda-forge version of iris has all the iris.tests and iris.tests.results ripped out - hence all the test fail!
Anyways, I can see a way forwards using either using pip or conda for iris-grib installation within the .travis.yml. This is probably all better highlighted in a concrete PR rather than described in imprecise prose - at least there would be a concrete thing to poke at and ponder over. Happy to take the first step and iterate with you... if you're game?
Otherwise, I'd suggest we leave the whole debate for later outside this PR. Are you trusting enough to believe me that there is nothing to worry about here? :smiling_imp:
So iris-grib trauma aside, is this PR good to go?

@bjlittle thanks for the clarity.

PR good to go?

Yes, given that we all understand that grib testing is still missing, and that's the way we want it !

@pp-mo Awesome, thanks :+1:


Mockery::hasSubstrings() matcher

Use as Mockery::hasSubstrings('needed substring', 'another needed substring')
I wrote the NonMatchingCase test in a different way than the other tests, because it seems to me that there's something wrong.  If you change, for instance, the third call to foo() in testHasKeyConstraintNonMatchingCase(), to $this->mock->foo(1, array('a'=>1)), the test still passes; I think it should fail?

Closing as met by Hamcrest matchers.
@davedevelopment We need a new issue for the test question?

Usually GitHub repos don't have ways to ask questions. For that reason it's common for people to post new issues with questions.
Are there any solutions for that except for https://gitter.im/ ?

Well, in this case it looks like a question that may technically be a testing bug. Ah, running afoul of the very thing I wrote Humbug for. The irony.

In review, I think the test is correct, though the behaviour is vague.

It is? Irony avoided!


CORS-3689: API changes in config/v1 to hold eipAllocations in cluster ingress object.

The eipAllocations when set by installer for default AWS NLB IngressController are set in the cluster ingress object the for the ingress operator to refer and then create a default Ingress Controller. This API field holds the eipAllocations value set by installer which were set via install-config.yaml

@JoelSpeed @gcs278 PTAL

@JoelSpeed I have made the requested changes. PTAL.

@JoelSpeed  the tests are failing with the following error:
INSUFFICIENT CI testing for "InstallEIPForDefaultNLBIngressController".
F1022 01:20:04.603312  172416 root.go:64] Error running codegen: error: "install should succeed: overall" only passed 94%, need at least 95% for "InstallEIPForDefaultNLBIngressController" on {azure amd64 ha }
make: *** [Makefile:56: verify-scripts] Error 255
Does it mean I need to add more tests ?

@JoelSpeed the test ci/prow/verify is failing with the following error:
INSUFFICIENT CI testing for "InstallEIPForDefaultNLBIngressController".
F1022 01:20:04.603312 172416 root.go:64] Error running codegen: error: "install should succeed: overall" only passed 94%, need at least 95% for "InstallEIPForDefaultNLBIngressController" on {azure amd64 ha }
make: *** [Makefile:56: verify-scripts] Error 255
Does it mean I need to add more tests ?

Have you added any tests to openshift/origin that are gated by the feature gate you're introducing here?

here in this API do we represent whether an NLB is int

Actually we don't set scope via installer. So, that is why I did not feel the need to add a field for this.
The CIO by default  creates a ingress controller with external scope. If a default ingresscontroller is created by the installer with eips the scope will be set to external by default. If someone later tries to change the scope from the operator/v1 ingress i.e Ingress Controller then it won't be allowed.

Generally looks good to me. I have a lot of open questions that I have explored in https://docs.google.com/document/d/1Y-Z8gaKYv5dczbdwvXanbzBl-HjZ7zasRC0WaJGBWkA/edit?tab=t.0#heading=h.sya755lm2fbe about the IngressConfig API.
The main one that I hope to get answered soon that affects this PR is "Should we split Ingress Config into defaulting for the default IngressController and defaulting for user-created IngressControllers?"
My concern is that IngressConfig.spec.loadBalancer is growing with new fields that have inconsistent purposes. I'd hope to have a discussion with the API team soon about this. @JoelSpeed Maybe the answer is to keep on the path we are (continue with this PR as is) and look for a path for deprecation or a V2.

Should we split Ingress Config into defaulting for the default IngressController and defaulting for user-created IngressControllers?
[Grant] I think our Ingress Config API could benefit from two structures that accomplish two different things
Naming is going to be really difficult. How do you distinguish between default for default ICs and default for user-created ICs?. spec.defaultIngressControllerDefaults and spec.userCreatedIngressControllerDefaults?
[Joel] We should definitely do this, to make the UX of creating the ingress config much more obvious to the end user, though as mentioned, naming is hard, we can discuss this in a wider forum to come up with something everyone is happy with, ingressControllerDefaults with fields of default and userCreated could be the way, but the default is unfortunate, we’d have to document it well
Reference: https://docs.google.com/document/d/1Y-Z8gaKYv5dczbdwvXanbzBl-HjZ7zasRC0WaJGBWkA/edit?tab=t.0#heading=h.1196heeu6pjk
Answer: @JoelSpeed  @deads2k @gcs278 Shall I split it ? However this will deprecate the old API so do we handle this ?

@JoelSpeed the test ci/prow/verify is failing with the following error:
INSUFFICIENT CI testing for "InstallEIPForDefaultNLBIngressController".
F1022 01:20:04.603312 172416 root.go:64] Error running codegen: error: "install should succeed: overall" only passed 94%, need at least 95% for "InstallEIPForDefaultNLBIngressController" on {azure amd64 ha }
make: *** [Makefile:56: verify-scripts] Error 255
Does it mean I need to add more tests ?

Have you added any tests to openshift/origin that are gated by the feature gate you're introducing here?

No, can you point me exactly where the tests are needed ?

If someone later tries to change the scope from the operator/v1 ingress i.e Ingress Controller then it won't be allowed.

How as an end user, would I change the scope from external to internal?

No, can you point me exactly where the tests are needed ?

Tests are expected in an appropriate location with origin

/close


Add an event post for our figure-making event on 04/05

This is for the figure-making event described in #83. I'll wait to merge to make sure we've got the Estin Room reserved.

we have the estin room - i'll merge this pr


Mark IDL's as "in production"

Currently IDL has the effect of assuming all IDL's are "in production" - that is to say, everyone is viewing IDL as if they could download the thrift files and immediately start calling these services in prod.
This isn't the case, and it will get worse when we have include support across the board, since shared IDL's will need to be committed to master in order for child services to begin implementing them.
I suggest we create an idl mark command or something similarly named, that users can integrate with their deploy systems to mark IDL's as "in production".
Thoughts? cc @uber/rpc

+1

Our current publishing strategy (and what the readme encourages) is to run idl publish as an automated process. Our current approach to automation only runs idl publish as a Phabricator Herald rule when an arc diff is landed on master. So for our purposes, every published idl is the idl on master.
Now our current m.o. at Uber is that you should always deploy what is on master. i.e. once you run arc land you are then expected to deploy to production and monitor your deployment to make sure everything went smoothly (in case automated tests didn't catch a problem that only happens in production). Since we have an expectation that master represents production, there is only a very tiny window between when an idl is published by CI and when it is available in production.
An alternative approach would be to run idl publish not as part of CI upon landing on master, but to run idl publish as a pre-deploy task.
With all this in mind, I don't see the value of this feature since you'd still want to automate marking what idl is in production and the approach to doing that would be no different than the approach to automating publishing. As such, this is a wontfix unless someone has additional reasons for how idl mark would be semantically different from idl publish.

Furthermore, since publish works by only updating idl files by hashed idl content comparison, rollbacks that trigger idl publish would also have the effect of rolling back the published idl to the previous state.

I disagree that there's only a tiny window between when an idl is published at when it's available in production. There's a few things that can happen:

There is no requirement or expectation that you deploy a change as soon as you land it. A lot of changes can be queued up, waiting for the next release.
A deploy may be rolled back, so the window would grow larger
Thrift changes can be made independently of code changes that actually add the functionality

I like the idea of running idl publish as a pre-deploy task though. It does seem like that'll fix the issues, without requiring a separate command.

+1 to @prashantv and @breerly.


etc/images.yml: add AlmaLinux 8.6

Signed-off-by: Johannes Kastl<EMAIL_ADDRESS>

Replaced by #298


Remote Desktop not working. Windows 10 Home 64bit

Not working remote desktop as i can see its can't find any SCREENS "0".
But when i press thumbnail i can see computer desktop.
You should fix that.

It has been tested on win7 win8.1 win10 x64. It's working just fine.
You need to provide more information. maybe a debug log.

@1337q Screen 0 is the default screen, that dosent mean no screens are detected. the only possible cause aside from corruption or code modification is a GPU mismatch. is your PC a laptop with a Nvidia card and integrated (Intel HD or AMD) graphics card?

It sometimes work sometimes don't @1337q


func filler() doesn't seem to serve a purpose. if true, i'm happy to take it out. :)

Hi!
This method embedded in viewDidLoad() of a few vc's in the example code doesn't get called anywhere in the code source --
func filler(_ date: Date) -> ChartAxisValueDate
It's in
CandleStickExample, CandleStickInteractiveExample, CustomUnitsExample
Is it there for future use?
If not, I'd be happy to remove it and submit a pull request.
p.s. sorry if that sounds like a lame change. as a framework user combing through the examples to get an idea of how to do what i want to do (which was a date drive x-axis), the filler method just serves as an unnecessary decoy is all.

Hi, feel free to remove it, thanks!


Expose undo stops in API?

Monaco has a concept of "undo stops" but doesn't give a way to access it without actually invoking undo.
I instrumented the onDidChangeContent with:
const model = editor.getModel();
model.onDidChangeContent(() => {
  console.log(model.getAlternativeVersionId());
});

And I can see that if I type "one two" then press undo, I see:
1 // o
2 // n
3 // e
4 // space
5 // t
6 // w
7 // o
3 // undo restores the text to "one"

So Monaco has decided to put an undo-stop in after version 3 based on some internal logic.
My wish: I'd like a field in IModelContentChangedEvent to indicate when an undo stop is created.  eg.
model.onDidChangeContent(({isNewUndoStackElement}) => {
  // In the above example, isNewUndoStackElement would be true on the 1st and 4th call
});

The reason I want this is so I can integrate this into the broader undo stack of the document in which the monaco editor is embedded.  eg. my document would have many monaco editors and when the user invokes undo, it would pick which of the monacos to send that undo request to; but in order to do so correctly, I would need an accurate recording of how many undo stops are being emitted by each of the monaco editors as their models change.  For even more context, see here.

@KevinWuWon apologies for resurrecting an extremely old issue, but I'm trying to do something similar, and was wondering if you had any luck / workarounds with exposing the undo stop functionality in monaco -- any pointers are very much appreciated!

I did not, sorry.

I did not, sorry.

No worries; really appreciate your taking the time to respond!

For anyone looking at this in the future, after looking through the source code (in the microsoft/vscode repo, not this one) I came up with a hacky solution which appears to be working for my purposes (though of course ymmv with these kinds of things). The idea is to just intercept Monaco at the relevant functions so we can create our own event emitter.
Here's what I'm using, depending on your use case you may want to change it a bit.
function interceptMonacoEditStack(model: editor.ITextModel, beforePushOrPop: () => void): { destroy(): void } {
    const pushStackElement = model.pushStackElement;
    const popStackElement = model.popStackElement;

    model.pushStackElement = function pushStackElement_hijacked() {
        beforePushOrPop();
        pushStackElement.apply(this);
    };

    model.popStackElement = function popStackElement_hijacked() {
        beforePushOrPop();
        popStackElement.apply(this);
    };

    return {
        destroy() {
            model.pushStackElement = pushStackElement;
            model.popStackElement = popStackElement;
        }
    };
}

This is the approach I ended up taking too (patching pushStackElement). The other things needed were:

A way to check whether the model actually had any pending changes that got pushed, since this method could be called even when three was nothing to be done. This could be checked via model._commandManager._undoRedoService.getLastElement(model.uri)?._data?._changes != null

Registering hotkeys that override the default behavior for undo / redo -- when orchestrating across multiple editors, an undo in editor A may actually need to trigger a "local undo" in some other editor B.

I ended up not patching popStackElement since for my use case I only needed to see when an undo stop got pushed due to normal interactions of text input (and undo stops only get popped when you explicitly ask for an undo).
I also needed to make my patched pushStackElement default to the original behavior in case something like a redo was explicitly applied, which I didn't want to watch (just wanted to watch when undo stops were pushed via typing / text input).


Fix Broken Links in API Docs

Purpose
This fixes more broken links in API docs.
Fixes #19800
Approach

Describe how you are implementing the solutions along with the design details.

Samples
Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #19888 into ballerina-1.0.x will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           ballerina-1.0.x   #19888   +/-   ##
================================================
  Coverage            20.51%   20.51%
================================================
  Files                   52       52
  Lines                 1394     1394
  Branches               216      216
================================================
  Hits                   286      286
  Misses                1095     1095
  Partials                13       13

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 17cedf0...0f9ce4d. Read the comment docs.


Run upstream tests based on commit message

This PR enables us to run an upstream test build when a commit message contains the phrase test-upstream. We do this by adding a new check job to our existing upstream GHA workflow which utilizes xarray-contrib/ci-trigger to search the corresponding commit message for test-upstream. If it is found in the commit message then the upstream build is launched otherwise the upstream build is skipped.
The extra check job takes ~5 seconds to run, so I don't anticipate it impacting our CI backlog in a meaningful way.
Here are a couple of example CI builds which demonstrate the upstream tests being skipped or not:

https://github.com/jrbourbeau/dask/runs/2047507385 -- did not contain test-upstream in the commit message
https://github.com/jrbourbeau/dask/runs/2047551865 -- did contain test-upstream in the commit message

This is really cool!

I was looking at the Xarray repo and noticed they were doing this -- totally agree it's a neat thing to have. We used to have this functionality back when we were on Travis CI, and I recall it being nice to have from time to time

Do you think this will grow to other libraries ?  If so, maybe we should rename to something more specific, like test-upstream-xarray

Ah, I mean I was looking at Xarray's own upstream CI in their repo and saw they were able to launch their own upstream CI tests based on test-upstream being in a commit message (xref https://github.com/pydata/xarray/blob/37522e991a32ee3c0ad1a5ff8afe8e3eb1885550/.github/workflows/upstream-dev-ci.yaml#L14-L27). This PR adds similar infrastructure to what's in the Xarray repo for parsing commit messages to Dask, but the tests which are run here are still our existing upstream tests. Today our upstream tests only run on pushes to the main branch and on a cron.

Ah, ok!  Thanks for the explanation

This is great! Do you know why contains(github.event.head_commit.message, 'test-upstream') didn't work as expected?

I don't totally remember why. Jim gave something similar a shot in https://github.com/dask/dask/pull/6196 and I also tried at one point but wasn't able to get things to work easily

Thanks for that context! There is one of these in ci-additional as well for test-hdf. Do you want to convert that one as well in this PR? Also happy to merge as is.

I'm okay limiting the scope of this PR to just upstream. I've opened up https://github.com/dask/dask/issues/7337 to track doing something similar with HDFS tests


Remove/conditionally import references to UIKit to allow macOS support?

I haven't dug into the internals of the code yet, but would it be possible to add support for conditionally importing any references to UIKit?  As it stands, the references to UIKit are preventing this library from being used in macOS SwiftUI applications.

Hello @TheGeekPharaoh
Currently this library, not support by mac OS as we need some UIKit reference. Also, adding conditions will not work. In the future will possible.

The Package.swift file still indicates that macOS is supported.  This should likely be removed.


Detect experimental and beta code

Hi! I created a new plugin for IntelliJ/Android Studio to detect code that is annotated with @Experimental or @Beta annotations and show an icon on the gutter. Can you add it to the list? Check out it here. The name of the plugin is Icons for Java annotations
Cheers!

Hi i'll try this plugin and if it's good i'll add it in current project.

Ok sir...
Firstly i want to do some hand over MVP then i will try further stuff but
surely i will look over this plugin.
On Wed, 7 Mar 2018 at 4:51 PM, BAL SIKANDAR<EMAIL_ADDRESS>wrote:

Hi i'll try this plugin and if it's good i'll add it in current project.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/balsikandar/Android-Studio-Plugins/issues/5#issuecomment-371107968,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVuxOKltS5vEcfCwf-QWuXH-BwZsCd6-ks5tb8LAgaJpZM4PbfV0
.


Update to angular2.rc-2

Angular 2 RC2 has been released.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/35242034-update-to-angular2-rc-2?utm_campaign=plugin&utm_content=tracker%2F32095848&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F32095848&utm_medium=issues&utm_source=github).

expect an update by the weekend


[Code app]: File content should be saved by CTRL+s instead of loose focus

EPAM AI DIAL chat version
0.21.0
How to reproduce
Steps:

Open Add code app form
select folder with source files
in code editor add new file
edit new file's content
set focus to another file

Actual result
Changes to file is saved by switching focus to another file or control
Expected result
Save operation should happen by clicking CTRL (CMD)+s
Confidential information

[X] I confirm that do not share any confidential information

verified on staging successfully

command+s does not work for saving edited files


{Network} az network application-gateway private-link: Migrate commands to codegen v2

Related command

az network application-gateway private-link
Description

Total: 10 commands
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Network


NeuralForecast |TimeMixer Model - exogeneous variables support

What happened + What you expected to happen
Using exogenous variables in TimeMixer model, whether historical or future, leads to an error message. As a result, the model can currently not be used with exogeneous variables, however, these are very crucial for good forecasts in many applications.
The issue has been raised also in Github Issue 1016.
@marcopeix, @kwuking: Do you have a timeline of when this issue can be fixed?
Versions / Dependencies
Name: neuralforecast
Version: 1.7.4
Reproduction script
see above
Issue Severity
High: It blocks me from completing my task.

The original paper doesn't seem to support exogenous features. Upon learning this I don't see a reason to support this.
Note that it's not easy to include exogenous - it is insanely hard to do this right, so it seems a limitation of the architecture that we are not placed to solve.
I'd vote for closing unless I'm misunderstanding here.

I'm really keen to harness this model's potentiality especially on multivariate / exogenous features, too.
TBH I'm not a data scientist, so I could be missing the nuances of multivariate time series and exogenous features. I read in the original paper that TimeMixer supports multivariate, though. How can I feed additional covariates into this model other than 'y' feature?


Version 1.1.0

Looks like we've got a good batch of changes merged into 'master'. Let's plan to cut a 1.1.0 release by end of week.
Here's what I've gathered for a changelog so far. Let me know if there's anything I'm missing!

Adjusted project structure to better support Travis-CI. CI is fully up-and-running on all 3 currently supported platforms. Carthage is now required to work on the library and run the example projects (Cocoapods is no longer used). Clone the repo, run carthage update, and then open Hyperspace.xcworkspace to get started. Fixes #3.
Can now cancelAllTasks() on BackendServiceProtocol.
NetworkService logic extracted into NetworkServiceHelper to better support future framework compatibility with URLSessionDelegate implementations.
NetworkService can now represent loading via the global network activity indicator shown in the device's status bar. Just initialize your NetworkService with a NetworkActivityIndicatable (ex: NetworkService(networkActivityIndicatable: UIApplication.shared)).

PENDING
* Improved code coverage > 90%. Fixes #1.
* Re-enabled SwiftLint. Fixes #9.
* MacOS Support. - #6
Release checklist:

Update Podspec (podspec version and git tag)
Validate Readme
Reverse commit f7281549a4c5ad2fa16f15a62cfd344c3bdaa24d (to re-enable pod spec lint command on Travis-CI)

@tylermilner Do we want to wait on macOS support for 1.1 or move forward with 1.1 and put that in a tentative 1.2 release?

@wmcginty I'm cool with releasing 1.1 without macOS support. We can always do a quick 1.2 fast-follow with macOS support.

I believe as soon as #16 is merged, we're good to tag and push to trunk.

1.1.0 has been pushed to trunk.


can helm get pause from local?

when helm init:
unable to pull sandbox image "gcr.io/google_containers/pause": Error response from daemon: {"message":"Get https://gcr.io/v1/_ping: dial tcp: i/o timeout"}"
so, how can i modify helm to get pause image from local docker respo?

The pause container is something kubernetes fetches to reserve the network namespace for the pod. This can be configurable from the kubelet via the --pod_infra_container_image flag, so you will need to change your kubelet's boot flags to fetch a local docker image instead. This isn't something that can be changed within helm as this is handled by the kubelet.

further context: https://github.com/kubernetes/kubernetes/issues/4896#issuecomment-77917065

thx first, another, can u tell me where is the kubelet configuration?

It's dependent on how your cluster was set up. I can't give you a definitive answer as it is cloud provider specific or specific to the instructions you followed to install kubernetes onto your cluster. I would follow up with your cloud provider's documentation.


Add more hub features to the table of features

This is a follow-up to https://github.com/2i2c-org/infrastructure/pull/2839  towards the sprint 1's  version of https://github.com/2i2c-org/meta/issues/628
Adds:

user id anonymisation
allusers setup
community specific domain
custom login page

Though I think something is up with the hub statistics table

Merged this to unblock the list of hubs, and will look into the other issues tomorrow.


Canvas-slideUpIn not removed after animation - "breaks" position: fixed CSS property

Category

[ ] Question
[ ] Typo
[x] Bug
[ ] Additional article idea

Expected or Desired Behavior
HTML elements rendered inside an SPFx webpart with a CSS position value of fixed should be position relative to the viewport.
Observed Behavior
HTML elements with a position property value of fixed are positioned relative to the webpart's parent canvas control
Steps to Reproduce

Create an SPFX webpart (^1.9)
Add an HTML element and set its position to fixed via CSS/style
Observe position of element
Go in F12 tools and remove the Canvas-slideUpIn from your webpart's immediate ancestor
Fixed position element should now be positioned relative to viewport instead of parent element

Suggested Fix
Once the webpart is rendered and the slide animation is finished, the Canvas-slideUpIn class should be removed automatically as its CSS contains a transform. Although the animation is no longer active (it only happens once per page load), an undesirable side effect is persisted and the element is forced to become a containing block (think iframe) so postion: fixed stops acting the way a dev might expect.
Further information from W3C

For elements whose layout is governed by the CSS box model, any value other than none for the transform property also causes the element to establish a containing block for all descendants. Its padding box will be used to layout for all of its absolute-position descendants, fixed-position descendants, and descendant fixed background attachments.

W3C example
Workaround 1 (supported)
Use a single part app page. At time of writing, there is no such animation on single app part pages but of course you forgo the use of 1st party web parts.
Workaround 2 (unsupported)
Overwrite CSS of parent element to unset the transform properties or remove the Canvas-slideUpIn class using DOM manipulation
https://github.com/SharePoint/sp-dev-docs/issues/3218#issuecomment-457364664

@StfBauer you'd have more insight into possible CSS issues than I...

Don't use position fixed. The value you are looking for is position: relative.
Then the position is relative to the viewport while fixed position it fixed.
Your fixed positioned element will appear somewhere on the page defined by the values of top, bottom, right, left. Fixed but not relative.
Definition position fixed: MDN

The element is removed from the normal document flow, and no space is created for the element in the page layout. It is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform, perspective, or filter property set to something other than none (see the CSS Transforms Spec), in which case that ancestor behaves as the containing block. (Note that there are browser inconsistencies with perspective and filter contributing to containing block formation.) Its final position is determined by the values of top, right, bottom, and left.

Can you provide an example that shows what you try to accomplish? This would help for a better understanding. I tested your scenario just by positioning the elements and in case of the fixed it even hasn't shown up on the page. Plus it is not really supported to break with a fixed positioned element out of the web part context instead you could use an application customizer as an extension.

@StfBauer
I've provided an example (instructions in the example) of a symptom but please note that this is just an example to demonstrate what I believe is an undesired side effect.
https://codesandbox.io/s/react-toastify-or3pr
I've simulated a container with a css that Canvas-slideUpIn applies. Apart from an animation, does this class have any other intended side effects? If not, is it not good practice to remove it after the animation is finished (and hence, its usefulness spent)?
If you do intend to to create a containing block for each webpart, you should probably have a another class for that intended purpose (e.g. class="Force-Containing -Block"). And if you do intend to have this side effect, the behavior should be consistent with single page apps but I don't see why you'd want that. Anyway, as you can see from #3218, I'm not the only one seeing this as a problem.

@semopz The documentation looks really nice. I wasn't aware of such a tool yet. Any chance you can provide a Repo with an actual SPFx solution? Otherwise, it would be hard to reproduce your issue other than building the solution myself. Which then still looks different than yours.

Thanks for your patience @StfBauer
I've created a working example that you can clone
https://github.com/semopz/examples/tree/master/toast
Even if you don't agree with the implementation of the tool, there's other implications of leaving the transform active on the webpart's parent element. The notifications library is just an example of the undesirable side effects of doing so.

We've confirmed this is a bug; thanks for the repros! We are evaluating removing the animation class on animationend to avoid the transform layer related problems with position: fixed;. Also to avoid SPFx developers from DOM manipulating as a workaround as that is an unsupported scenario.

@semopz Can you monitor your tenant to verify when the fix has been rolled out? Once you see it, you can close. this issue. Thanks!

As of version 16.0.19805.12034, the fix is not yet available will update when I see change.

As of 16.0.19819.12035, Canvas-slideUpIn doesn't seem to linger anymore. Thank you all


SQL with Excel

Describe your changes
Issue number
Closes #354
Checklist before requesting a review

[X] Performed a self-review of my code
[X] Formatted my code with pkgmt format
[X] Added tests (when necessary).
[X] Added docstring documentation and update the changelog (when needed)

:books: Documentation preview :books:: https://jupysql--423.org.readthedocs.build/en/423/

@idomic PR is ready to merge


Gitlab redirect broken

Example URL(s)
https://developers.cloudflare.com/pages/platform/gitlab-integration
Actual Behavior
Redirect broken
Expected Behavior
https://developers.cloudflare.com/pages/platform/gitlab-integration should link to https://developers.cloudflare.com/pages/platform/git-integration
Additional information
No response

Closing as page is not visible in dash


Version 3.4.1 on Linux

The newest version is available for OSX, but not for Linux. What is it that makes Circle fail? The latest build reports a permission issue during recipe checkout, maybe the updated tokens fix that?

@conda-forge-admin, please update circle.

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I updated the circle-ci deploy key and followed the project.

Try restarting the CircleCI build now, @kohr-h.

Thanks @jakirkham. I'm not the maintainer of the feedstock, so I'll ping @grlee77

Ok, have restarted it just now. Should be up soon.
For future reference, here is info on the command I used and other related commands.

Build succeeded. Thanks @jakirkham.