show quoted identifiers with quotation marks in Database Navigator

For Postgres connections. the Database Navigator shows Columns with names and data type but gives no indication as to whether or not the identifier is quoted with " or the case of each character.
I suggest showing Column identifiers as quoted and with their true case, if that is how they are stored in the schema (not specific to Postgres, though Postgres in its default configuration is more sensitive about exact matches on case and quoted identifiers than other DBs, such as mySQL).
Alternative solution is to access Generate Sql > DDL, which pops up a window showing the statement creating the identifier as it was originally declared with case and quoted attributes.  This extra step is a minor inconvenience for the user, so this suggestion would not be a high priority.
If this does get implemented, it could be offered as an option where users who prefer not to see the "ugly" quoted identifiers can turn it off.
For those of us required to use quoted identifiers to show names as exactly as they are defined by external sources (honoring case, spaces, hyphens, parens, etc.)   this would be a helpful feature especially when dealing with tables made up of dozens of fields.

We don't understand the idea and the use case. Could you show example of how does your table names look like in some other tool?
For example, if you're creating the table tAbLe in database where identifiers are stored in lower-case, then table with name table will be created unless you're using quotes "tAbLe". What do you want us to show in this case? Do you want to see this "tAbLe" in navigator with quotes?

Yes, I would want an option to see "tAble" in navigator with quotes.  This would apply to columns and any other objects where a quoted identifier can be used.   With the Generate SQL->DDL preview, we can see what we need to.  I suggest this as a low priority, as it would make checking object names just a little faster and easier by showing up in their actual quoted/unquoted format in the Database Navigator.
Don't need another tool to demonstrate this, as dBeaver has the DDL feature.  Use case is when I'm working with a table and need to specify column name identifers precisely.  For example in Database Navigator shows

but when I use that table in code, I need to know the exact format of the identifier, which is always shown correctly in DDL:

Same applies to tables, for example:

is actually this in code:

The quoted table is the exact outside filename from source as specified in the outside source design and as it is delivered to our system.  Anything we derive or generate internally is in lowercase_underscore unquoted format.
We have tables that are mix of quoted fields from outside sources and internal fields we create as part of our process, like the integer count at the top here:

The formatting is not obvious if using Database Navigator:

We don't have any examples outside of tables and columns, but any object (view, function, etc.) where a quoted identifier is allowed would be subject to this suggestion.
————————
You may be wondering "Why? Why would anyone choose this?"  The suggestion is of no use on projects where object names are not quoted, as is best practice on a greenfield project.
We chose to use the identifiers so that fields coming in from different sources can immediately be identified by their quirky name on a spreadsheet or CSV such as "a1( idclass, legacy)"—a real example— and not translated to, say, a1_idclass_legacy.  We also have fields coming in with names ike SELECT, PRIMARY, NAME, etc. that are actual Postgres keywords, produced by sources where adaptation to a database was never under consideration.  Rather than adapt the names to some sort of convention, we decided to just quote them directly.  With hundreds of tables from outside sources, each with dozens of fields, this took away the need to remap object names to something different.  Just quote them and go.
Not sure it was the best design choice, but Postgres allows it and we went that way.  dBeaver is 3/4 of the way there already, with DDL preview and the quotation respect shown by autocomplete on quoted fields (it was just fixed in 23.2.4, in fact).
I can imagine many users would be horrified to see quotes showing up uninvited in the Database Navigator (though case already does), so this should be an option, not a fixed feature.  Again, not a high priority, but would be nice to have for the few of us working with object names such as "Name (as registered ®)" (another real example).

I see. Thank you for detailed explanation ☺

I added the wait-for-votes label for other users:
You can vote for the issue with the emoji under the issue description to promote it to a higher priority.


fix: override mgs

Codecov Report
Attention: Patch coverage is 73.91304% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 75.25%. Comparing base (106b88f) to head (7b60f1c).
Report is 52 commits behind head on main.

Files
Patch %
Lines

alzlib.go
64.70%
3 Missing and 3 partials :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #85      +/-   ##
==========================================
+ Coverage   70.66%   75.25%   +4.59%
==========================================
  Files           6        6
  Lines         900      772     -128
==========================================
- Hits          636      581      -55
+ Misses        193      117      -76
- Partials       71       74       +3

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


Building with podman-remote hangs

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Trying to do a podman build over podman-remote, and the connection gets stuck.
This happens with both 1.9.0 and 1.9.1, but works OK with 1.8.2. On Ubuntu 19.10
The workaround is running "sudo podman build" remotely (over ssh), which works.
But that means that the user needs to transport the entire build context themselves.
From https://github.com/kubernetes/minikube/issues/8063
Tried to debug, but not sure how ?
Steps to reproduce the issue:

minikube start --driver podman

eval $(minikube podman-env)

podman-remote build .

Describe the results you received:
 podman-remote build .
^C

Describe the results you expected:
 podman-remote build .
STEP 1: FROM busybox
STEP 2: RUN true
--> Using cache 98bc298a4242e40d67a4f37d2a2d37f2cf7ab3b71e1499a67a278bd131e20398
98bc298a4242e40d67a4f37d2a2d37f2cf7ab3b71e1499a67a278bd131e20398

Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Version:            1.9.1
RemoteAPI Version:  1
Go Version:         go1.12.10
OS/Arch:            linux/amd64

Output of podman info --debug:
Package info (e.g. output of rpm -q podman or apt list podman):
podman/unknown,now 1.9.1~1 amd64 [installed]

Additional environment details (AWS, VirtualBox, physical, etc.):

@baude PTAL

can you provide the dockerfile in question?

Here it is:
FROM busybox
RUN true

Thanks @baude:
I tried upgrading (to 904ee39) and it seems to have fixed the first issue.
But it now seems to hang on the second step, and eventually time-out:
STEP 1: FROM busybox
Getting image source signatures
Copying blob sha256:d9cbbca60e5f0fc028b13c01e70e96cc2eefe7858ccc5a33c9a8faa8b03286aa
Copying config sha256:78096d0a54788961ca68393e5f8038704b97d8af374249dc5c8faec1b8045e42
Writing manifest to image destination
Storing signatures
STEP 2: RUN true
Error: unexpected EOF

Is there something similar needed, for other parts of the protocol too ?
Client:
Version:            1.9.1
RemoteAPI Version:  1
Go Version:         go1.13.8
Git Commit:         37a3aa6c83603ec774939a8d07c950dd3b26110a
Built:              Sun May 10 19:03:51 2020
OS/Arch:            linux/amd64

Server:
Version:            1.9.1
RemoteAPI Version:  1
Go Version:         go1.13.8
Git Commit:         904ee392f1cdf4368d8554b149415906dbb25ba0
Built:              Mon May 18 22:18:08 2020
OS/Arch:            linux/amd64

Here is how it looks with 1.8.2: (i.e. when not cached, same VM as above)
STEP 1: FROM busybox
Getting image source signatures
Copying blob sha256:d9cbbca60e5f0fc028b13c01e70e96cc2eefe7858ccc5a33c9a8faa8b03286aa
Copying config sha256:78096d0a54788961ca68393e5f8038704b97d8af374249dc5c8faec1b8045e42
Writing manifest to image destination
Storing signatures
STEP 2: RUN true
STEP 3: COMMIT
--> 3797f36bb81
3797f36bb8166a81a8335c925512148d0994f17437bf815a24bddc949297ead5

@afbjorklund it finished for me ... ill try multiple times.

STEP 1: FROM busybox
STEP 2: RUN true
--> Using cache 8050b40a3a397abc62ccaac3b2f89b8fed96f71ce6d8aa8bb8fe83ac443ff64b
STEP 3: COMMIT foo
--> 8050b40a3a3
8050b40a3a397abc62ccaac3b2f89b8fed96f71ce6d8aa8bb8fe83ac443ff64b

Version:            1.9.1
RemoteAPI Version:  1
Go Version:         go1.14.2
Git Commit:         904ee392f1cdf4368d8554b149415906dbb25ba0
Built:              Mon May 18 15:38:09 2020
OS/Arch:            linux/amd64

Server:
Version:            1.9.1
RemoteAPI Version:  1
Go Version:         go1.14.2
Git Commit:         904ee392f1cdf4368d8554b149415906dbb25ba0
Built:              Mon May 18 15:38:01 2020
OS/Arch:            linux/amd64```

The environment is still a bit shaky in general, it's not unheard of to get timeouts and such.
ssh: exit status 255
It is running a privileged container (in podman), and in this one it runs the varlink bridge...
Both started with sudo.

I don't think the VM-based environment has similar issues, then again it still runs 1.8.2.
So I will check if we have the same problems in VirtualBox too, after upgrading to 1.9.x

Upgraded to Ubuntu 20.04 and podman 1.9.2 (from the opensuse kubic repositories), same thing.
So most likely we will downgrade this to 1.8.2 for the release. Will try to rebuild the source package:
git checkout -b debian v1.8.2
https://github.com/containers/libpod/releases/tag/v1.8.2
git cherry-pick debian
https://gitlab.com/rhcontainerbot/podman/-/tree/debian

@afbjorklund Have you had a chance to try this with podman v2?

@rhatdan : Haven't tried 2.0 RC yet, but it works OK with podman 1.9.3


FirstOfWeek added to Event. Used by Weekly interval.

Added FirstDayOfWeek property to Event. When Frequency Weekly is used, weekstart is defined by Event FirstDayofWeek.

I'll make a new pull request with correct spacing.


Mac osx tests work locally but not via github actions.

Doesn't matter too much but it'd be nice to guarantee a local build for devs. This is what's breaking the pipeline. Any idea what it means @Koeng101?
https://github.com/allyourbasepair/allbase/runs/3050366244#step:4:39

Closing for now as it's not a priority.


multi-gpu gradientFlowTest and reference conf implementation

This solves #22: the gradientFlowTest now also works for multi-GPU by exchanging the 8^3x4 test conf with the newly added reference conf that can be obtained via GaugeUpdate::set_gauge_to_reference()
And that means that #46 can also be closed.

Maybe #46 can now be changed instead of closed, namely to "make tests use reference conf"

All tests pass


As a logged-in user I want to create Video-post so that I could publish it

As a logged-in user I want to create Video-post so that I could publish it.
Preconditions:

Registered User is logged in
Registered User has Active status
User pressed Create Video button in the header

Video creation page should contain:

List of topics
The video title
The editor
Preview button
Publish button

Topics section.
Use #129 User story for the list of the topics.
The editor
Editor functions:

Video addition
Underlined, Bold, Italics text
Normal or Heading text style, changing text style with button
The picture addition us unavailable

Buttons.
Use #129 User story for Preview button, Publish button. By default buttons are unlabeled. Buttons become active after downloading the video and adding the description.
Acceptance criteria:

Topics section is displayed
The video title length is from 10 to 1000 symbols
Number of chosen topics is from 1 to 3
At least one topic are required
The editor is displayed
Description length is from 2000 to 63206 symbols //уточнить. может ли быть без описания?
Normal text style is a default text style
Preview and Publish buttons are unlabeled until downloading the video and filling the description.
Click on Preview button should redirect to "Preview Page". #125
Click on Publish button should redirect to "Post Page". #128

BA check 18/07/21
Not accepted.
Preview button is active before downloading the video and adding the description.
Description length is not approved.
Note:  there is specific way of downloading video from youtubewhich not suitable for majority of users.

BA check 20/07/21
Not accepted.
Preview button is active before downloading the video and adding the description.
Description length is not approved.
To choose at least one topic is not implemented as an obligatory requirement - you can preview video-post without choosing a single topic.
UI design is outdated.


Teams creation limit for Azure AD app registration

Hi there!
I'm planning to set up the Graph API application that would create teams using Azure AD APP Registration for authentication in the tenant.
What limit on teams creation is for Azure AD App Registration?

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

ID: 905e2c09-ef3e-07cc-0809-6ff171157c47
Version Independent ID: c0d33162-183d-fff8-32e9-a999f391ea51
Content: Limits and specifications for Microsoft Teams - Microsoft Teams
Content Source: Teams/limits-specifications-teams.md
Service: msteams
GitHub Login: @SerdarSoysal
Microsoft Alias: serdars

@SashaSidorenko From the article you linked we see that:

In Microsoft Graph, Microsoft Teams is represented by a group resource

And the limit of groups an admin can create is 500k per tenant, as described here.

@SashaSidorenko  Please let us know if you still have any question regarding the issue you have raised initially.
The issue is being closed since your question seems to be answered. Feel free to re-open this issue if you feel that it hasn't been answered or that there are further suggestions to improve the documentation itself.
Thanks.


Tags inputs in upload do nothing

They're supposed to add a tag as accepted but right now all of the inputs do strictly nothing so i have made them invisible for the time being

Fixed by #1461


Getting endpoints failed after successful deployment

my kubeconfig name is somthing different than "config" so when I deploy bdc, I gave the right config name and everything worked fine. However, after deployment was done, getting the endpoint failed becuase the azdata command didn't have the right config name. the environment variable was not set correctly I think. here's the error:

azdata login -n mssql-cluster
stderr: ERROR: azdata Please specify arguments and/or environment variables in non-interactive mode. For a better understanding of the arguments, please run 'Missing --endpoint arg in non-interactive environment. You may also place your kube config in the default location of /.kube/config or use the KUBECONFIG env var to specify the location of the config, i.e. export KUBECONFIG=path/to/.kube/config. login --help'.
stderr:

$azdata login -n mssql-cluster    ... exited with code: $1
azdata login -n mssql-cluster   ... errored out: Process exited with code 1

@alanrenmsft If you get to this, great. But it's fine to punt. Kevin agrees.

@llali If we understand correctly, you are running the azdata command outside of the context of notebook, and we only want to control the KUBECONFIG within the context of notebook. closing as by design.


Fix text_chosen and text_rejected

We do not directly create text_chosen from chosen_messages (same for rejected), as chosen_messages contains only an assistant message and it may raise jinja error (raise_exception('Conversation roles must alternate user/assistant/user/assistant/...')) in many chat models' chat_template (example. Instead, we remove the prompt part from the whole chosen_messages's input text.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@lewtun Hi, could you please check what's wrong with my commits/pr?

May I ask why this PR isn't reflected on the main branch?


feat: update aiohttp to support python 3.12

Closes: #187

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 96.944%

Totals

Change from base Build<PHONE_NUMBER>:
-0.002%

Covered Lines:
2696

Relevant Lines:
2781

💛  - Coveralls


Added support for method calling on requires

Fixes Issue #5. Tried to match coding style but open to changes to get this functionality merged in.

Hi! Thanks for the PR :)


CASMNET-1791/CASMNET-1940 - ncn_add_pre-req.py fixes

Description

CASMNET-1791 - Update ncn_add_pre-req.py script to actually remove the HSM ethernetInterfaces record instead of just printing that it's going to do it.
CASMNET-1940 - Add a check to ncn_add_pre-req.py so it aborts if the calculated DHCPStart value equals or exceeds DHCPEnd so an invalid configuration can't be uploaded to SLS which breaks Kea.

Checklist

[X] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[X] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[X] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

/backport release/1.5

/backport release/1.4

/backport release/1.3


[PE-D][Tester B] [inspect] Invalid name inspect gives the wrong error message

Input: inspect unknownname

Labels: type.FunctionalityBug severity.Low
original: jehousoh/ped#7

Same as issue #128


Eliminate the term "Preview" from js-debug

Currently VS Code does not seem to have a "standard or "final" Node.js debugger:

There is either a "legacy" debugger or a "preview" debugger.
I suggest to eliminate "preview" as soon as possible from Node.js, Chrome, and Extension Development.
And maybe we should consider to rename "legacy" to "node.js < 8.0".
Shouldn't we do this even for the November release?

Do we still need to make the changes to the now-legacy debug adapters? Is there a plan yet for moving the debug adapter types to get rid of "pwa"?

Do we still need to make the changes to the now-legacy debug adapters? Is there a plan yet for moving the debug adapter types to get rid of "pwa"?

I plan to do the type-swap this month. We've been targeting early this year to remove the old debuggers from being built-in

I plan to do the type-swap this month. We've been targeting early this year to remove the old debuggers from being built-in


InvalidSessionToken error doesn't return correctly in iOS

I tried to simulate InvalidSessionToken scenario in Unity Editor and it does return the error code correctly.
When I try to build on iOS, it just return 400 OtherCause.
Why does it working on Unity Editor but not on iOS ?

I noticed it has been fixed in Unity 5.2


Multiple terminals

For now it is possible only to use one terminal inside Monokle. We should be able to create multiple terminals that we can use in parallel.

https://github.com/kubeshop/monokle/pull/2150


Select data for benchmarking

Task
Select 1+ datasets that can be used as test / example data for NLP-based drift detection methods
Impact
Helps test other tools / any algorithms developed within menelaus

[ ] incorporate wilds datasets as optional dependency
[ ] attribute appropriately per license


update strategy text

#55  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @leonchike and the rest of your teammates on  Graphite


Fix python-pytest-popup

It is now obsolete, it has been renamed to python-pytest-dispatch in
https://github.com/wbolster/emacs-python-pytest/commit/ee61741d4e35dc639b5e269efaa488d743da9c35
Not sure if we need to update the keybindings, though.

@hlissner is there anything else I can do here? Or do you have other plans?
Unfortunately, we need to explicitly do M-x python-pytest-dispatch once if we want SPC m t p to work.

Sorry for the tremendously late response! Thanks for the help!


Can't style zoom slider with js

Hi, thanks for the plugin
I'm facing an issue at the moment. I need to style the zoom slider with js as default css doesn't work in my case (i need a different color for the filled part of the range, but i can't achieve it in webkit browsers with the help of css).
I tried two different plugins for styling range input with jquery and none of them worked. The slider is generated, but real range value isn't changed, and as a result the image isn't zoomed in/out. But the plugins work okay with an ordinary input(if you make the real input visible, you can see it)
see fiddle here (now it uses rangleslider.js but I tried formstone as well, the same result)
https://jsfiddle.net/ohn1xbn1/7/
I also tried to call rangeslider after image change
https://jsfiddle.net/ohn1xbn1/8/
and also with setTimeout
none of them works
What can I do
Regards
Lusine

I haven't tried it personally, but you might try using this implementation of rangeSlider that's not using jQuery.  The problem is rangeSlider is triggering a change with jQuery, and to the best of my knowledge jquery events and native events aren't compatible.
Otherwise, I'm thinking eventually we're going to add a setZoom(v) method on croppie, so that might solve your problem.

Thanks, I'll try this way too though  I already managed to style only webkit range with js.
Yes setZoom will be very useful,
Thanks

so, was this solved by setZoom method ?


Impove ffmpeg backwards compatibility

Allows building with ancient ffmpeg on Centos6 and up to ffmpeg 3.0
Also api documentation state that av_free_packet should be called before
each av_read_frame call, unless packet is duped. Not doing that
can sometimes lead to segfaults. Better be safe.
Calling avcodec_close with null pointer caused segfaults on ancient ffmpeg.

LGTM. Builds fine on all the Travis images as well as my home machine. I just need to double check that it builds properly with the systems I use at work, if so I will merge it on Monday.

Merged into master.
Will merge into RB-1.6 in a couple days if nobody complains about trouble in master.

Or do you even need it on RB-1.6?

No, I'm on master


Download a copy of video from Council of Prague

Joseph Bagaric and the Chrono Logic team shared the raw footage here https://www.dropbox.com/sh/vod004nk7rpqkcm/AABBf-bWeCuop7SFTBM4Nyzca?dl=0
Joseph will also be editing it and posting to YouTube, but that may take a little while.
For this item, please leave a comment once you have stored a copy somewhere, including a link.
Also needed, is a description of the file name to when / where it was taken.

Pt.1 https://drive.google.com/open?id=1onX0bkVN6tP807-hP1HkZFHjZJ7m1I3Z
Pt.2 https://drive.google.com/open?id=1KO6DWqFyXXbIVYqx5KPRc7UHq5ZzcqWj
Still need to do the Cannon M50 videos ~ I have run out of space on my computer. I regret buying 256 gbs
https://www.dropbox.com/sh/vod004nk7rpqkcm/AAALtqprW7Yt63Q3P6tROHLoa/Canon M50?dl=0&subfolder_nav_tracking=1


Mark failing test as pending on versions of powershell < 4

This case has never worked before 6c724e866274a728bc66740ab352db7da7d7958f.
It was fixed for 4, however it seems that does not apply to versions < 4.
cc @smurawski @btm

that failed in appveyor. I think you want to use this instead:
it "returns the -27 for a powershell script that exits with -27", :windows_powershell_dsc_only do

:+1:


WP8 Cordova routing issue due to url formatted with x-wmapp0

Angular throws an error in the function "matchUrl(url, obj)" due to the URL being formatted as such: "x-wmapp0:www/index.html".
Apparently the URL scheme is specific to Cordova/WP. This happens when attempting to use routing.

The correct way to handle this is to add x-wmapp0 to the $compileProvider.aHrefSanitizationWhitelist


[boost-thread:x86-mingw-dynamic] build failure

Host Environment

OS: Windows 10
Compiler: g++ (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 8.1.0 - This is up to date version shipped with Qt

To Reproduce
Steps to reproduce the behavior:
-- In PS --
setx PATH "C:\Qt\Tools\mingw810_32\bin"
-- restart PS --
git clone https://github.com/microsoft/vcpkg
cd vcpkg
./bootstrap-vcpkg.bat
./vcpkg --triplet x86-mingw-dynamic install boost-thread
Failure logs
This is output from build (last step, I cut off installation of required packages):
https://pastebin.com/5FkNYqWC
This is content of install-x86-mingw-dynamic-dbg-out.log
https://pastebin.com/GzbHjrsV
This is run from scratch as you can see. I tried with older mingw - 7.3.0 and with 64 bit version as well, also from scratch but with the same effect

I found out that Jamroot.jam contains a lot of references to libboost*.so file, while their names are *.dll.a, so by simply modifying that I am able to build package manually.

This should be fixed by the upgrade to boost 1.74.0 a while ago, which had much better support for mingw targets.


Uncletopia.com website broken

Probably api error?
News empty. Wiki empty. Rules, events, donate internal server error. SourceTV something went wrong. Cannot sign in.

yes its down for the moment, will be back shortly


Allows the addon-operator pod(s) to be deployed to non-request-serving nodes.

What type of PR is this?
(bug/feature/cleanup/documentation/test/refactor)
bug
Allows the addon-operator pod(s) to be deployed to non-request-serving nodes.
What this PR does / why we need it?
Allows the addon-operator pod(s) to be deployed to non-request-serving nodes.
Which Jira/Github issue(s) this PR fixes?
Fixes MTSRE-1845
Fixes #
Special notes for your reviewer:
Pre-checks (if applicable):

[ ] Tested latest changes against a cluster
[ ] Ran make go-test command locally to run all the unit tests and mock tests locally.
[ ] Included documentation changes with PR

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

Project coverage is 72.76%. Comparing base (7939bd0) to head (b9531bd).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #609   +/-   ##
=======================================
  Coverage   72.76%   72.76%
=======================================
  Files          51       51
  Lines        3294     3294
=======================================
  Hits         2397     2397
  Misses        754      754
  Partials      143      143


Is the storage reported in Gibabytes (GB) or in Gibibytes (GiB)?

Just wanted to make sure whether the ASR Deployment Planner tool reports disk sizes in GB or in GiB. This seems to indicate GB, but other Azure documentation is very explicit about using GiB for measuring storage (see https://azure.microsoft.com/en-us/pricing/details/managed-disks/)

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

ID: 39afb641-fa83-3f39-d35b-c12382d03a42
Version Independent ID: 73280edf-c418-52d0-bb68-b647f2bdfb1e
Content: Analyze the Azure Site Recovery Deployment Planner report for disaster recovery of VMware to Azure
Content Source: articles/site-recovery/site-recovery-vmware-deployment-planner-analyze-report.md
Service: site-recovery
GitHub Login: @mayurigupta13
Microsoft Alias: mayg

@cap273 Thanks for the Comment. We are actively investigating and will get back to you soon.

@mayurigupta13 To confirm if the data unit is in GB or GiB

@cap273 For deployment planner the unit of data measurement is in GB.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


adding missing atlas terms

In order for the tests to work, we need to add the new terms to this file
FYI: @MFSY

Please push the terms changing to the docs branch.


[openSUSE Tumbleweed] Build errors

Hi guys. I was trying to build RPM package for openSUSE Tumbleweed x86_64, after applying jaggr/xpp#11 patch got some new errors.
xcb-util-devel
Repository     : openSUSE-20180209-0
Name           : xcb-util-devel
Version        : 0.4.0-1.10

xcb-proto-devel
Repository     : openSUSE-20180209-0
Name           : xcb-proto-devel
Version        : 7.6_1.12-6.1

xcb-util-cursor-devel
Repository     : openSUSE-20180209-0
Name           : xcb-util-cursor-devel
Version        : 0.1.3-2.1
Arch           : x86_64

xcb-util-image-devel
Repository     : openSUSE-20180209-0
Name           : xcb-util-image-devel
Version        : 0.4.0-1.10

xcb-util-wm-devel
Repository     : openSUSE-20180209-0
Name           : xcb-util-wm-devel
Version        : 0.4.1-4.3

xcb-util-xrm-devel
Repository     : openSUSE-20180209-0
Name           : xcb-util-xrm-devel
Version        : 1.2-2.3

[  195s] CMakeFiles/polybar.dir/utils/bspwm.cpp.o: In function `polybar::v3_1_0::bspwm_util::root_windows(polybar::v3_1_0::connection&)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/utils/bspwm.cpp:22: undefined reference to `xcb_icccm_get_wm_class'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/utils/bspwm.cpp:22: undefined reference to `xcb_icccm_get_wm_class_reply'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/utils/bspwm.cpp:29: undefined reference to `xcb_icccm_get_wm_class_reply_wipe'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::initialize()':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:17: undefined reference to `xcb_ewmh_init_atoms'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:17: undefined reference to `xcb_ewmh_init_atoms_replies'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::supports(unsigned int, int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:25: undefined reference to `xcb_ewmh_get_supported'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_supported_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, xcb_ewmh_get_atoms_reply_t*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:698: undefined reference to `xcb_ewmh_get_atoms_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::supports(unsigned int, int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:32: undefined reference to `xcb_ewmh_get_atoms_reply_wipe'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:28: undefined reference to `xcb_ewmh_get_atoms_reply_wipe'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_wm_name[abi:cxx11](unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:40: undefined reference to `xcb_ewmh_get_wm_name'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_wm_name_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, xcb_ewmh_get_utf8_strings_reply_t*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:1804: undefined reference to `xcb_ewmh_get_utf8_strings_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_reply_string[abi:cxx11](xcb_ewmh_get_utf8_strings_reply_t*)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:68: undefined reference to `xcb_ewmh_get_utf8_strings_reply_wipe'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_visible_name[abi:cxx11](unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:49: undefined reference to `xcb_ewmh_get_wm_visible_name'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_wm_visible_name_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, xcb_ewmh_get_utf8_strings_reply_t*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:1837: undefined reference to `xcb_ewmh_get_utf8_strings_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_icon_name[abi:cxx11](unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:58: undefined reference to `xcb_ewmh_get_wm_icon_name'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_wm_icon_name_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, xcb_ewmh_get_utf8_strings_reply_t*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:1870: undefined reference to `xcb_ewmh_get_utf8_strings_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_current_desktop(int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:76: undefined reference to `xcb_ewmh_get_current_desktop'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_current_desktop_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, unsigned int*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:1223: undefined reference to `xcb_ewmh_get_cardinal_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_desktop_viewports(int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:84: undefined reference to `xcb_ewmh_get_desktop_viewport'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:84: undefined reference to `xcb_ewmh_get_desktop_viewport_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_desktop_names[abi:cxx11](int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:96: undefined reference to `xcb_ewmh_get_desktop_names'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_desktop_names_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, xcb_ewmh_get_utf8_strings_reply_t*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:1302: undefined reference to `xcb_ewmh_get_utf8_strings_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_active_window(int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:105: undefined reference to `xcb_ewmh_get_active_window'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_active_window_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, unsigned int*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:1419: undefined reference to `xcb_ewmh_get_window_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::change_current_desktop(unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:111: undefined reference to `xcb_ewmh_request_change_current_desktop'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_desktop_from_window(unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:118: undefined reference to `xcb_ewmh_get_wm_desktop'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_wm_desktop_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, unsigned int*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:1934: undefined reference to `xcb_ewmh_get_cardinal_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::set_wm_window_type(unsigned int, std::vector<unsigned int, std::allocator<unsigned int> >)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:124: undefined reference to `xcb_ewmh_set_wm_window_type'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::set_wm_state(unsigned int, std::vector<unsigned int, std::allocator<unsigned int> >)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:130: undefined reference to `xcb_ewmh_set_wm_state'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_wm_state(unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:137: undefined reference to `xcb_ewmh_get_wm_state'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:137: undefined reference to `xcb_ewmh_get_wm_state_reply'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::set_wm_pid(unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:145: undefined reference to `xcb_ewmh_set_wm_pid'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::set_wm_pid(unsigned int, unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:151: undefined reference to `xcb_ewmh_set_wm_pid'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::set_wm_desktop(unsigned int, unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:157: undefined reference to `xcb_ewmh_set_wm_desktop'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `polybar::v3_1_0::ewmh_util::get_client_list(int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/ewmh.cpp:171: undefined reference to `xcb_ewmh_get_client_list'
[  195s] CMakeFiles/polybar.dir/x11/ewmh.cpp.o: In function `xcb_ewmh_get_client_list_reply(xcb_ewmh_connection_t*, xcb_get_property_cookie_t, xcb_ewmh_get_windows_reply_t*, xcb_generic_error_t**)':
[  195s] /usr/include/xcb/xcb_ewmh.h:784: undefined reference to `xcb_ewmh_get_windows_reply'
[  195s] CMakeFiles/polybar.dir/x11/icccm.cpp.o: In function `polybar::v3_1_0::icccm_util::get_wm_name[abi:cxx11](xcb_connection_t*, unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:9: undefined reference to `xcb_icccm_get_wm_name'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:9: undefined reference to `xcb_icccm_get_wm_name_reply'
[  195s] CMakeFiles/polybar.dir/x11/icccm.cpp.o: In function `polybar::v3_1_0::icccm_util::get_reply_string[abi:cxx11](xcb_icccm_get_text_property_reply_t*)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:19: undefined reference to `xcb_icccm_get_text_property_reply_wipe'
[  195s] CMakeFiles/polybar.dir/x11/icccm.cpp.o: In function `polybar::v3_1_0::icccm_util::set_wm_name(xcb_connection_t*, unsigned int, char const*, unsigned long, char const*, unsigned long)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:25: undefined reference to `xcb_icccm_set_wm_name'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:26: undefined reference to `xcb_icccm_set_wm_class'
[  195s] CMakeFiles/polybar.dir/x11/icccm.cpp.o: In function `polybar::v3_1_0::icccm_util::set_wm_protocols(xcb_connection_t*, unsigned int, std::vector<unsigned int, std::allocator<unsigned int> >)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:30: undefined reference to `xcb_icccm_set_wm_protocols'
[  195s] CMakeFiles/polybar.dir/x11/icccm.cpp.o: In function `polybar::v3_1_0::icccm_util::get_wm_urgency(xcb_connection_t*, unsigned int)':
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:35: undefined reference to `xcb_icccm_get_wm_hints'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:35: undefined reference to `xcb_icccm_get_wm_hints_reply'
[  195s] /home/abuild/rpmbuild/BUILD/polybar-3.1.0/src/x11/icccm.cpp:36: undefined reference to `xcb_icccm_wm_hints_get_urgency'
[  195s] clang-5.0.1: error: linker command failed with exit code 1 (use -v to see invocation)
[  195s] gmake[3]: *** [bin/CMakeFiles/polybar.dir/build.make:1868: bin/polybar] Error 1
[  195s] gmake[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/polybar-3.1.0/build'
[  195s] gmake[2]: *** [CMakeFiles/Makefile2:574: bin/CMakeFiles/polybar.dir/all] Error 2
[  195s] gmake[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/polybar-3.1.0/build'
[  195s] gmake[1]: *** [Makefile:133: all] Error 2
[  195s] gmake[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/polybar-3.1.0/build'
[  195s] make: *** [Makefile:24: install] Error 2

I'm not able to reproduce this on a newly setup tumbleweed VM. What is the output of rpm -ql xcb-util-wm-devel and nm -D /usr/lib64/libxcb-ewmh.so?

@patrick96 when I will back at home I'll check. But something else I found. On first spec file I use in %build section a %cmake macro, when changed to just cmake . RPM package is building. I think the %cmake macro is broken and just doesn't work with files to build. Now I've got another problem. Why CMake is installing polybar in /usr/local instead of /usr ?

I don't know what spec files you are talking about, there are no official polybar build files for OpenSUSE, so if you have problems with a third-party build file, you'll have to talk to the person that created it.
cmake installs to /usr/local by default (this is independent of polybar), if you want to change that, you can pass -DCMAKE_INSTALL_PREFIX=/usr to cmake. In general, if you're not actually building a package that you later install with your package manager, it is best to install to /usr/local.

@patrick96 of course I didn't say any word. I'm making a spec file for polybar, so this is unofficial. I'll work with this today. I think, we can close that.

Were you able to resolve the linker error?

@patrick96 yes. The problem was with %cmake macro. Changed to normal command and works. Build went smooth, you can check here


Change Password Improvements

This PR's goal is to

Strength password changing rules. #990
Solve new ispconfig change password issues (related to crypting). #1298

It seems it works well!!

As far as I can tell, the Change Pw plugin in rainloop still does not work. Where is the latest version?


My Operations + UI Stability improvements

Resolves #2241
What is being addressed

Adds a new endpoint to the API to get 'my' operations - those initiated by the current user. This is a single call which executes quickly and I would say mitigates #2104 as the operations are loading before the resource lists.
UI Updates:

Moved the api-calling logic for individual operations into the Item level rather than the collection level. This improves readability and prevents having to work with collections.
Improved error handling when an operation is invalid (bad data / unrecoverable issue in the backend), so it renders an error with the Op Id to help support staff clean up data.
Improved stability when locking/refreshing/removing resources. Moved away from a separate 'component actions' collection which was prone to edge cases of re-rendering to the components just subscribing to the operations list directly, and not mutating that collection.
Improved the callout message when an operation completes, to indicate what just happened.
The 'bell' icon now shows a mini progress bar underneath when there are running operations, in the same way the Azure Portal does.

/test

/test-force-approve
tests have run previously


Certain hls videos wait forever for eos in mediaCodec

Version
ExoPlayer 2.18.1
More version details
No response
Devices that reproduce the issue
Samsung Galaxy S22, Android 12
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
No
Reproduction steps

Start broadcasting through apple low latency hls
Stop broadcasting.

Expected result
return Player.STATE_END from onPlayerStateChanged listener
and isPlaying() is false
Actual result
return Nothing from onPlayerStateChanged listener
and isPlaying() is alway true
Media
[MediaCodecRenderer.drainOutputBuffer:1822]

If you play it again with the same media link, there is no problem, and problems occur only when the stream is cut off during video playback, making it difficult to attach media files.
Instead, when I checked the MediaCodecRender through debugging, I found that I was checking the infinite loop in the above state
Please let me know if you need any additional information
Bug Report

[ ] You will email the zip file produced by adb bugreport to<EMAIL_ADDRESS>after filing this issue.

Hi @PsPLoG,
Thanks for reporting! Let me try to clarify the problem:

problems occur only when the stream is cut off during video playback

Is the scenario like while the client watching the broadcast and something happens at the provider end so the broadcast cannot continue?

@tianyif
There is a glitch when the streamer ends the broadcast or when the transmission shuts off due to an error.

The exoplayer received the endtag but it gets stuck in an infinite loop due to the problem mentioned above.

Hi @PsPLoG ,
Thanks for the information! The player which received the EXT_X_ENDLIST tag may not add the BUFFER_FLAG_END_OF_STREAM to the buffer properly, so the media codec is not informed.
However, after the attempt to investigate the issue with barely looking into the code in the absence of a sample media, we still feel difficult in identifying the detailed cause, so we probably need to try some hacky approaches to simulate the scenario. I apologize in advance if it will take longer :)

@tianyif
Does that mean it's not the cause??
If you give me information about how BUFFER_FLAG_END_OF_STREAM is called, I'll analyze the code

@tianyif


Layout widget should also expose [min/max]_[width/height] properties

I don' t remember why we did not include this in the Layout attributes, but it is really missing in the case of widget for that

should stretch in a flexbox where align-items is stretch
have a minimal size, in case align-items is unset.

+1


Inactive PID redirects to localhost

Note: When inactive PID with test URL is entered in browser search, it goes to http://www.localhost.com:3000/link/inactive rather than http://uclibs.org/link/inactive. Is this just an issue with the test PIDs?
eg: enter inactive pid http://d2d-pid-dev.cdlib.org/link/1192
click on pid and it redirects to http://www.localhost.com:3000/link/inactive

Fixed- Invalid url reports is created using active record orm. cron job is scheduled to run every weekend


phaser v2.2.0-RC12 camerafollow bug with arcade physics (sprite jitters)

Hi Phaser-Team,
I am testing phaser v2.2.0-RC12 (Built: Thu Nov 27 2014 21:10:45) and I am experiencing the following problem with camera follow:
Set the camera to follow a sprite, move this sprite via setting it's arcade body velocity.
Expected behavior:
As long as the cam has not reached any bounds I would expect the sprite to be absolutely still in the middle of the screen.
what actually happens:
the sprite around jitters by a pixel
jsfiddle:
http://jsfiddle.net/jppresents/ab4r7ekv/
(hold cursor right to see the effect, there is no actual sprite, but the green-error-box jitters instead of beeing still).
also: if you move the sprite by setting x or y every frame, then there is no jitter.
I would consider this bug critical, because it makes camera follow with arcade physics unusable.
Another user has found this problem too in a phaser 2.x version:
http://www.html5gamedevs.com/topic/10377-bodyvelocity-camerafollow-is-choppy/
(unresolved, only workarounds posted)

I've spent some time looking into this today - and the solution proposed in the PR doesn't actually solve the issue. Pixi by default works on sub-pixel boundaries when rendering. It does not compensate for this, and setting camera.roundPx = true won't make any difference in the jsfiddle above, because the Sprite itself is still at a non-integer position.
The solution is to tell Pixi to not render sub-pixels. This only needs doing once in the renderSession, and will stop all the 'jiggling' going on without having to round any values internally (physics, camera or otherwise):
game.renderer.renderSession.roundPixels = true
Add that line to the jsfiddle and notice the difference! I'm going to close this issue off as the above should be the way this is handled. I'm half-tempted to turn it on by default, but that's a considerable change and doesn't suite all art styles, so maybe not for now. I will however mention it in the Camera part of the docs.

thanks for looking into it and providing a solution :)
On Wed, Feb 11, 2015 at 4:30 PM, Richard Davey<EMAIL_ADDRESS>wrote:

Closed #1377 https://github.com/photonstorm/phaser/issues/1377.
—
Reply to this email directly or view it on GitHub
https://github.com/photonstorm/phaser/issues/1377#event-233996171.

We started a game in Phaser two years ago and had to leave the project because this. It's a shame that two years later nothing changed at all, even with game.renderer.renderSession.roundPixels = true; Check this out: http://jsfiddle.net/7LLqnxw1/16/


Information box toggle

When the information box, which displays the neume name and pitch information, is closed, the box never displays again even when selecting a neume on the canvas.

Refer to #136


Access to submit apps

From https://accrescent.app/faq I tried adding an app via: https://dev.accrescent.app/login
Logging in with GitHub I got:
Registration not permitted
Accrescent developer registration is currently invite-only. Please come back when registration opens for everyone.

https://accrescent.app/docs/guide/getting-started/new-app.html says:
To upload a new app, click the "New app" button on your dashboard.

How does one get access to this?  Perhaps a link to the contact info would help in the 2nd and 3rd links above?

Thanks for reporting this! The sign-up process is now documented.

Excellent, cheers!!


Submission for Coding Challenge - baikovsj

https://people.sap.com/baikovsj

Thanks a lot for your contribution. The solution looks great and I'll close this PR now!
You should receive your badge soon.


Release v2.14.3+rev1

@resin-jenkins retest this please

Superseded by https://github.com/balena-os/balena-iot2000/pull/20


I am interested in using your game on my website. Could you add a license file like the MIT one in this pull request so I know how you want your software used?

Sure thing. Though I feel like I should mention that this is project was never completed. It was a side project I did during a software testing course to try out the workflow for using TDD.

That's ok. Thanks!


Reducing callbacks with Explicit Resource Management

This is my first time going through this proposal, and as I was looking at the following example, I couldn't help but feel like I was in callback hell again:
const asyncVar = new AsyncContext.Variable();

// Sets the current value to 'top', and executes the `main` function.
asyncVar.run("top", main);

function main() {
  // AsyncContext.Variable is maintained through other platform queueing.
  setTimeout(() => {
    console.log(asyncVar.get()); // => 'top'

    asyncVar.run("A", () => {
      console.log(asyncVar.get()); // => 'A'

      setTimeout(() => {
        console.log(asyncVar.get()); // => 'A'
      }, randomTimeout());
    });
  }, randomTimeout());

  // AsyncContext.Variable runs can be nested.
  asyncVar.run("B", () => {
    console.log(asyncVar.get()); // => 'B'

    setTimeout(() => {
      console.log(asyncVar.get()); // => 'B'
    }, randomTimeout());
  });
}

I understand that this is probably not a practical example, but regardless, the proposal only offers a callback-style API. So it got me thinking about how we could flatten these callbacks, and I realized that there is an opportunity to interoperate with the Explicit Resource Management proposal. Specifically, AsyncContext.Variable instances could also have a set() method which returns a Promise that resolves to a disposable resource when the context value is updated, and upon disposing the resource, the context is changed back.
In the case of the example above, we would be able to clean it up like so:
const asyncVar = new AsyncContext.Variable();

// Sets the current value to 'top', and executes the `main` function.
asyncVar.run("top", main);

function main() {
  // AsyncContext.Variable is maintained through other platform queueing.
  setTimeout(() => {
    console.log(asyncVar.get()); // => 'top'

    using _ = await asyncVar.set("A");
    console.log(asyncVar.get()); // => 'A'

    setTimeout(() => {
      console.log(asyncVar.get()); // => 'A'
    }, randomTimeout());
  }, randomTimeout());

  // AsyncContext.Variable runs can be nested.
  using _ = await asyncVar.set("B");
  console.log(asyncVar.get()); // => 'B'

  setTimeout(() => {
    console.log(asyncVar.get()); // => 'B'
  }, randomTimeout());
}

To be clear, the lifetime of an AsyncContext value using set() isn't quite semantically equivalent to using run(), but this idea is more about readability and exposing interoperability with other patterns.
Another example I believe it helps clean up a bit is one where you need to pass the fulfilled values of an array of promises to an AsyncContext, like shown here:
const asyncVar = new AsyncContext.Variable();

function deeplyNestedFunctions(data) {
    console.log(data, asyncVar.get());
}

promises.map(async (promise) => {
    asyncVar.run(await promise, () => {
        deeplyNestedFunctions(data)
    });
})

On the other hand, the set() version looks slightly better to me:
const asyncVar = new AsyncContext.Variable();

function deeplyNestedFunctions(data) {
    console.log(data, asyncVar.get());
}

promises.map(async (promise) => {
    using _ = await asyncVar.set(await promise);
    deeplyNestedFunctions(data);
})

Obviously this is a pretty nitpicky suggestion, but I'd be interested in hearing what other people think about it.

I understand that this is probably not a practical example

In a real example, the callbacks would typically be input to an API responsible for the invocation of those callbacks in some way (event handlers, timer scheduling, etc), hence the need for managing their “async contexts” at all, right? For inline code, AsyncContext.Variable already exists — “LexicalScope.Variable”.
let asyncVar;

// Sets the current value [of the lexical binding] to 'top', and executes the `main` function.
asyncVar = 'top';
main();

function main() {
  // [lexical scope] is maintained through other platform queueing.
  setTimeout(() => {
    console.log(asyncVar); // => 'top'

    {
      let asyncVar = 'A';
      console.log(asyncVar); // => 'A'

      setTimeout(() => {
        console.log(asyncVar); // => 'A'
      }, randomTimeout());
    }
  }, randomTimeout());

  // [lexical scopes] can be nested.
  {
    asyncVar = 'B';
    console.log(asyncVar); // => 'B'

    setTimeout(() => {
      console.log(asyncVar); // => 'B'
    }, randomTimeout());
  }
}

At least that’s my understanding — I could be missing something, but my impression was that this was pretty intrinsic to the motivations for the API.

For inline code, AsyncContext.Variable already exists — “LexicalScope.Variable”.

Yes, the fully inline case is trivial and not something that we can't already do with lexically-scoped variables. However, in other cases, AsyncContexts aren't equivalent to lexically-scoped variables, in that they still behave as contexts which can bypass argument drilling for deeply nested (async and non-async) functions. And ultimately my suggestion is about preserving that ability while reducing the callbacks necessary to update the context values.

We had actually discussed using using bindings and allowing general mutability of the context a while ago, but decided against it. The big problem I have with this is that if you miss the using (or the manual dispose at the end of the block), you've now leaked your data into other execution contexts. With the callback API, that's impossible, you always have a correct execution context that will be cleaned on exit.

We had actually discussed using using bindings and allowing general mutability of the context a while ago, but decided against it.

Thank you for the link to that discussion, it was a very interesting read.

The big problem I have with this is that if you miss the using (or the manual dispose at the end of the block), you've now leaked your data into other execution contexts.

That's a valid point. It's certainly a worse kind of error to leak data between execution contexts than it is to forget to close/release some resource. However, another issue of the callback-style API lies in the use and setting of multiple async contexts at a time. My understanding of the current API is that multiple contexts can only be set at once by daisy chaining run() calls like so:
{
  const ctxA = new AsyncContext.Variable();
  const ctxB = new AsyncContext.Variable();
  const ctxC = new AsyncContext.Variable();

  ctxA.run(1, () => {
    return ctxB.run(2, () => {
      return ctxC.run(3, sum);
    });
  }); // 6
}

That's a bit of an eyesore in my opinion. With using bindings, we could simplify that daisy chain to just:
{
  const ctxA = new AsyncContext.Variable();
  const ctxB = new AsyncContext.Variable();
  const ctxC = new AsyncContext.Variable();

  using _a = ctxA.set(1);
  using _b = ctxB.set(2);
  using _c = ctxC.set(3);
  sum(); // 6
}

However, in hindsight, even the discards look out of place, and as you mentioned, accidentally leaking data is too risky. An obvious workaround would be to combine those contexts into one object, but it doesn't always make sense to group data. So perhaps the better solution is to actually provide some API to run() multiple contexts simultaneously. Perhaps a static compose() method:
namespace AsyncContext {
  export declare function compose<F extends (...args: unknown[]) => unknown>(
    assignments: [AsyncContext.Variable<unknown>, unknown][],
    fn: F,
    ...args: Parameters<F>
  ): ReturnType<F>;
}

AsyncContext.compose(
  [
    [ctxA, 1],
    [ctxB, 2],
    [ctxC, 3],
  ],
  sum
); // 6;

Imho all of this can be solved in library code which actually makes use of the async context.
Also, I think that many libraries making use of this feature would only ever create a single AsyncContext.Variable and store an object or whatever with context data within it.
An example I could think of would be a middleware like to following to provide information about the request.
That would allow a generic logger to use this information without passing all of this along to any deeply nested code:
interface TraceInfo {
    traceId: string;
    userId: string;
    url: string;
}

const traceVar = new AsyncContext.Variable<TraceInfo>();

// export helper to get current trace info
export function getTraceInfo() {
    return traceVar.get();
}

export async function traceInfoMiddleware(ctx: Context, next: NextFunction) {
    // Collect tracing information
    const traceId = createRandomTraceId();
    const traceInfo: TraceInfo = {
        traceId,
        userId: ctx.user.id,
        url: ctx.req.url,
    };
    // Run next middleware with trace info in async context now
    await traceVar.run(traceInfo, next);
}

That is also probably the #1 feature I'm dying to use this for once it becomes available 🚀

It's worth calling out that different parts of the data a user wants stored will likely need to change at different parts of the graph. For example, in tracing we likely have a single trace id stored for a request and all descending async activity, however we would also want to store a span id from the start to the end of a particular interesting execution we want to draw a span around. A span may contain many inner behaviours. If we just stuff everything in one big object we have to reallocate a copy of other things like the trace id reference, which has not changed, every time we change the span id. We would actually prefer to have different stores for different singular purposes.

The big problem I have with this is that if you miss the using (or the manual dispose at the end of the block), you've now leaked your data into other execution contexts.

I am prototyping adding using declaration support to AsyncLocalStorage: https://github.com/nodejs/node/pull/52065. To address unexpected declarations without using, a leakage check is performed when a task (AsyncResource in Node.js) callback is finished. If there is any active disposable async local storage value, an error is emitted to hint at such misuse.

I understand that this was discussed in yesterday's meeting, and the decision was that it could be added later as a follow-on.  I want to caution that this would likely be a very difficult follow-on to polyfill.
Consider a situation in which the engine has a working AsyncContext implementation, but does not support this usage pattern.  It's not clear that one could polyfill this short of abandoning the entire built-in implementation in favor of a brand new polyfill, which isn't cheap.  Worse, it may be difficult to determine statically whether the extra functionality is needed at all (i.e. just seeing using _ = someName.set(value) isn't a given without following the reference to someName, possibly in a different file, and determining its type).
Given this difficulty, it seems to me that if we think it likely that this will land eventually, then there may be good reasons to do it now rather than later.

@Qard

It's worth calling out that different parts of the data a user wants stored will likely need to change at different parts of the graph. For example, in tracing we likely have a single trace id stored for a request and all descending async activity, however we would also want to store a span id from the start to the end of a particular interesting execution we want to draw a span around. A span may contain many inner behaviours. If we just stuff everything in one big object we have to reallocate a copy of other things like the trace id reference, which has not changed, every time we change the span id. We would actually prefer to have different stores for different singular purposes.
We actually also have many internal things we store for internal visibility, so as it is currently we'd be doing a lot of object rebuilds per request if we tried to fit everything in one object. Whereas if we store each of our differently propagating pieces of data in their own separate stores most of them can just reuse the same store value as the outer async context rather than doing a fresh run and building a new state all the time.

I totally understand your concerns. But even in such cases - where additional properties might be needed in some spans - I still believe it would be less costly to just create a clone of the state object with additional properties than running many async contexts together, considering the amount of work that the JS engine has to perform behind the scenes.
Compared to that a simple { ...currentContext, spans: [..currentContext.spans, newSpan ] } feels both easier to work with and I think would probably be even more performant or pretty much equally as fast as setting multiple async contexts.
There's also the cost of not only setting multiple async variables, but also retrieving multiple of them to get all required values.

It's definitely not less costly. I have measured this extensively at Datadog through various permutations of AsyncLocalStorage designs, including with heavy edits to V8.
A trace id is set once per request. A span id is typically set a few hundred to a thousand times per request, sometimes tens of thousands in extreme cases. It's not uncommon for context to be propagated across async barriers a hundred thousand or so times per request. I have seen well over a million async transitions in a single request before.
The present state of Node.js is effectively doing an object rebuild on every transition, and the performance is...not great. Doing a map clone and edit on-change in JS and then only passing through the frame reference otherwise is about 15x faster. In my experiments with ContinuationPreservedEmbedderData in V8 it can be made an order of magnitude faster with a native map that can be directly memory-cloned and only the changed slot modified. The closer that separation of differently-timed changing data lives to the metal, the faster it is.
This is roughly what we've tried to achieve with the AsyncContextFrame concept used in Cloudflare and my in-progress rewrite of AsyncLocalStorage in Node.js. It spawned from a need to heavily prioritize performance of propagating data over performance of altering data, since most context data changes far less frequently than it propagates, while still having reasonable performance for the things which do change somewhat often.
An AsyncContextFrame is only built when a store.run(...) happens. Otherwise, the frame value is passed through directly by-reference. By moving the separation machinery to a lower level rather than tracking it at object level, it enabled the optimization of propagation by-reference while at the same time also making it even more desirable to have separate stores as it reduced the frequency that data needed to change for the context management to flow.
It's not as optimal as it could be as implemented in JS it can't do the memory-cloned map optimization, but even with rebuilding the map it still managed to be much faster than the object clone version.

An interesting case is generators:
function* gen() {
  using _ = storage.disposable(value);

  yield 1;

  // what context is restored here?
}

Of course we'd want value restored into the context, but how would that work? We'd have to mutate the generator's internal [[GeneratorAsyncContextSnapshot]] field to point to the new mapping, because we can't modify the old one directly (something else may have snapshotted it). Or we'd have to re-enter the disposable every time the generator resumed so that it could push the modified mapping onto the stack again. Either way it's messy.

That's @Qard, that's some very interesting insights which I didn't expect.

@jridgewell I don't understand your question; why would there be any mutation?

Because I'm still within the same scope, the using binding isn't discarded at the end of a yield. Why wouldn't you expect value to be the current value?

Related: https://github.com/rbuckton/proposal-using-enforcement/issues/1

I think avoiding nesting can be solved without explicit resource management if we're willing to require some setup for the functions that want to switch within their invocation.
const varA = new AsyncContext.Variable();
const varB = new AsyncContext.Variable();

const doStuff = AsyncContext.bindVariables((setVariable, foo) => {
  setVariable(varA, 123);
  setVariable(varB, foo);

  someOtherCall();
});

doStuff("foo");

I think that achieves the same 1-layer-nesting that runAll does.

I think that achieves the same 1-layer-nesting that runAll does.

Right, but with the additional ability to conditionally switch variables during the execution of the function. Not sure if that's a use case, to be honest I'm fuzzy on the motivations.

It's not clear to me that runAll really addresses the issue in the OP: in their example, there's only a single var being set at each point.
To my  mind, as long as you own the context, there's not really anything too troubling about mutating a variable within that context.  The problem with the disposable approach is that you may be in a shared context and thus leak your mutations somewhere unexpected.
A simple userland workaround if you happen to own the variable is to add an extra level of indirection: use a Variable<() => T> instead of a Variable<T>, and then when you run with a new value, you can hold onto a setter that only affects the context you already own.  This has poor ergonomics and doesn't work for variables you don't own - but ultimately it's context ownership that should matter, not variable ownership.
@mhofman's suggestion of exposing a setter that only works in your owned context seems like a good compromise, though I suspect the API could be less confusing as a "run" rather than a "bind" (but maybe there's a performance reason I'm unaware of where the bind approach makes more sense?):
const result = v.runWithSetter((setV, boundArg1, boundArg2) => {
  // do stuff
  setV(newValue);
  // do more stuff
  return someResult;
}, arg1, arg2);

Or the batched approach
const result = AsyncContext.runWithSetter((setVariable, ...boundArgs) => {
  setVariable(varA, 123);
  setVariable(varB, 456);
  // do stuff
  setVariable(varA, 789);
  // do more stuff
  return someResult;
}, ...passedArgs);

I could also imagine a method or function decorator doing this a bit more automatically (though the changed signature might be a dealbreaker depending on how TypeScript ultimately handles that):
@bindVariables
function(setVariable, arg1, arg2) { /* ... */ }

But I agree that without a better understanding of the use case, it's hard to justify.  Different approaches to solving this are easier/harder to polyfill, particularly in an incremental way.  For what it's worth, I'm inclined to strictly enforce wrapping AsyncContext.Variable with a userland AsyncVar class in my own organization, in order to maintain an extra level of indirection, at least while these questions are still shaking out.  This allows transparently implementing the workaround I mentioned above, and even potentially experimenting with some of these mutation APIs if there's developer demand for it.

@shicks

It's not clear to me that runAll really addresses the issue in the OP: in their example, there's only a single var being set at each point.

See https://github.com/tc39/proposal-async-context/issues/60#issuecomment-1632019120 for the authors intention. runAll should solve it with 1-layer of nesting, the same as runWithSetter.

suggestion of exposing a setter that only works in your owned context seems like a good compromise, though I suspect the API could be less confusing as a "run" rather than a "bind" (but maybe there's a performance reason I'm unaware of where the bind approach makes more sense?):

I don't understand why moving mutation into the callback is a better choice than having them grouped outside the callback with runAll. I think that introduces a new "is this mutable" problem that doesn't exist with scoped callbacks. runAll is a direct parallel to run, just with multiple variables done before calling the cb.

runAll allows de-nesting when setting multiple variables at a single point in time, and can be easily accomplished in userland.
runWithSetter handles the above use case but also allows de-nesting when setting a single variable at multiple points in time:
v.run(1, () => {
  const a = doSomething();
  v.run(2, () => {
    const b = doSomethingElse();
    v.run(3, () => {
      putItAllTogether(a, b);
    });
  });
});

vs.
runWithSetter(set, () => {
  set(v, 1);
  const a = doSomething();
  set(v, 2);
  const b = doSomethingElse();
  set(v, 3);
  putItAllTogether(a, b);
});

This latter use case is not possible in userland unless you have control over the variable and are willing to add an extra layer of indirection, which likely also hurts usability.  One might argue that if you don't own the variable, you shouldn't be able to mutate it - but in this case, you do own the scope in which you're mutating it, and that's at least something.  It satisfies the condition that you can't affect your caller's scope, but it does have the potential downside that functions you call can no longer rely on variables being immutable across async continuations (i.e. the values can change out from under them), which may still be a concern.


PTFE-719: runner group startup

Codecov Report

Merging #341 (d00ca92) into main (ec7b24a) will decrease coverage by 2.53%.
The diff coverage is 12.50%.

@@            Coverage Diff             @@
##             main     #341      +/-   ##
==========================================
- Coverage   79.96%   77.44%   -2.53%
==========================================
  Files          24       25       +1
  Lines         549      563      +14
==========================================
- Hits          439      436       -3
- Misses        110      127      +17

Flag
Coverage Δ

api
58.43% <12.50%> (-1.50%)
:arrow_down:

unit
61.45% <12.50%> (-2.12%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

runner_manager/jobs/runner_groups.py
0.00% <0.00%> (ø)

runner_manager/models/settings.py
100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

Ended up taking the work of this PR, and applying my own review.


Closing the native window should gracefully close the image

Shutdown Pharo without saving when space is closed:
BlSpace new
   title: 'Close me';
   extent: 200@200;
   addEventHandler: BlSpaceShutdownOnCloseListener new;
   show

Shutdown Pharo saving the image when space is closed:
BlSpace new
   title: 'Close me';
   extent: 200@200;
   addEventHandler: (BlSpaceShutdownOnCloseListener new shouldSave: true);
   show

We also need to add it to GtWorld I think.


CI Integration

Is there any way to set-up alias-hq CLI as a CI tool?
Basically, I’d want to use GitLab pipelines to run alias-hq and fail if a path alias is not used, to enforce that the entire project always uses them.
So, the requirements would be:

Run some sort of command (e.g. yarn run alias-hq --check)
Command uses exit code 1 if some issue was found
Command uses exit code 0 if no issue was found

Thanks for the tool BTW, really useful and well-done

Hey Florian,
Thanks for the kind words!
So I don't know much about CLI / Pipelines, but if I understand you correctly, you'd like to:

reuse the existing (or have similar) codemod functionality which trawls the import statements of a project
to check they always use aliases rather than local paths (or, at least adhere to the logic that the shortest path is used)
and have this exposed via the command line and pass or fail in a manner than is appropriate for a build pipeline tool

I haven't worked on this for a good few months, but I don't see why that wouldn't be possible.
I don't have much time at the moment, which is a problem (I have an existing PR for renaming aliases which I've not touched in months too!)
I'd be happy for you to submit a PR though. The codemod side of things is surprisingly straightforward; I'd be happy to help you if you needed it.

Looking at file which sets up the source transforms:

https://github.com/davestewart/alias-hq/blob/master/cli/modules/source/transformer/transformer.js#L41

If newPath is returned, it means the import / require could be simplified, so I presume at this point you would want to exit with code 1.
One of the surprisingly challenging bits of this project was working out how best to ask questions and how best to preview and report results, so I suspect you might also want to think about that, rather than just exiting?

Any more interest in this @FlorianWendelborn or should I close the issue?

Any more interest in this @FlorianWendelborn or should I close the issue?

@davestewart I’d say neither. I don’t have the time right now to develop this, but I still think it’s a useful/vital piece of what this software should be able to do. I’d hope that tagging it as Help Wanted, one day someone will have time to submit a PR.

@davestewart I’d say neither. I don’t have the time right now to develop this, but I still think it’s a useful/vital piece of what this software should be able to do. I’d hope that tagging it as Help Wanted, one day someone will have time to submit a PR.

Sure. I'm also busy, but I'll leave this open and maybe find time to do it when I need a break from something else!

Closing as stale / not high priority. Feel free to reopen!


Adds support for styleModule

This PR adds support for the styleModule configuration, a way to change the (currently hardcoded) module that gets imported during the styled-jsx transpilation.
Part 1 of https://github.com/zeit/next.js/issues/10149

@arcanis thanks for the PR! Looking at the issue I wonder if this could be fixed in Next.js by rewriting the import declaration source with a Babel plugin so that it points to the right module or with a webpack alias?

I think idiomatically the 'right' path should be configurable by the transforms themselves - this is for example what transform-runtime does (kinda) with absoluteRuntime which instructs it to use the absolute path rather than the regular package name. In our case I think it's better for portability to avoid absolute paths and use the Next.js package name instead.

Thank you @arcanis and sorry for the delay! I'll release a minor version


Demos don't give good running instructions

The demo Makefiles currently give this as the instruction to run them: LD_LIBRARY_PATH=../.. ./EVP_MD_demo.
It would be better if this were ../../util/wrap.pl EVP_MD_demo or similar.

Hmmm, I know that at least the Debian package libssl-dev has these demos copied to /usr/share/doc/libssl-dev/demos.
They were designed to be fairly self contained, so making them depend on our internal scripts might not be the best idea.

For an OS installation, they just run as is.  So not a problem there.
The solution might be to remove the instructions entirely.

We might want to write a more complete and generic set of instructions in demos/README.txt (including the very simple variant that builds against the system installation), and simply refer to that file from the Makefiles

Or just not referring to it from the Makefiles at all.  Reading the README isn't an unreasonable thing to do if stuff doesn't appear to work.

It isn't wrong to have that extra reference...


[resource/device_posture_integration] Remove extra id parameters

the terraform-plugin-sdk adds the "id" to the schema when d.SetID is
used. therefore, there is no need to have this extra parameter in
the schema.
The use of this extra id is causing the pulumi schema to pull a
duplicate argument
sdk/python/pulumi_cloudflare/device_posture_integration.py:377: error: Duplicate argument "id" in function definition

i attempted to resolve this for you but your fork does not allow changes from maintainers. instead, here is a patch you can apply and we can get this merged.
From d100290c39f762b7943d429f480bd2e3cb7ff865 Mon Sep 17 00:00:00 2001
From: Jacob Bednarz<EMAIL_ADDRESS>Date: Fri, 11 Mar 2022 11:26:03 +1100
Subject: [PATCH] add CHANGELOG entry

---
 .changelog/1504.txt | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 .changelog/1504.txt

diff --git .changelog/1504.txt .changelog/1504.txt
new file mode 100644
index 00000000..8b156d0a
--- /dev/null
+++ .changelog/1504.txt
@@ -0,0 +1,3 @@
+```release-note:bug
+resource/cloudflare_device_posture_integration: remove superfluous `id` from schema
+```
--
2.33.0

feel free to use it or add your own commit addressing this.

Thanks @jacobbednarz - I've just pushed this now - apologies for not having edits switched on on the branch!

np! thanks for the fix.

Thanks for the fix!!


[Refactor] Refactor Map<String, Range>  into PartitionRange

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[x] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:heart_eyes: pass : 153 / 162 (94.44%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/common/PartitionRange.java
18
21
85.71%
[30, 60, 63]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
10
11
90.91%
[1189]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMvRefreshProcessor.java
39
43
90.70%
[683, 684, 995, 997]

:large_blue_circle:
com/starrocks/catalog/OlapTable.java
20
21
95.24%
[1151]

:large_blue_circle:
com/starrocks/sql/common/SyncPartitionUtils.java
53
53
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/transformation/materialization/MvUtils.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/MvTaskRunContext.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/common/RangePartitionDiff.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/connector/PartitionUtil.java
6
6
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 147 / 154 (95.45%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/common/PartitionRange.java
18
21
85.71%
[30, 60, 63]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
10
11
90.91%
[1189]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMvRefreshProcessor.java
33
36
91.67%
[683, 995, 997]

:large_blue_circle:
com/starrocks/catalog/OlapTable.java
20
20
100.00%
[]

:large_blue_circle:
com/starrocks/sql/common/SyncPartitionUtils.java
53
53
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/transformation/materialization/MvUtils.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/scheduler/MvTaskRunContext.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/common/RangePartitionDiff.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/connector/PartitionUtil.java
6
6
100.00%
[]


Remove special modifiers from the draw pile when drawn

I know that you should remove those two kind of cards from your deck after they are drawn :

But what about these ones?

I can't find anything online @orichalque

I checked the rules, blessings and curse should be destroyed on draw
the -1 added by the scenario should be removed at the end of the scenario :)

Closed with commit 58e120a5b19abae89d950d7d54b311c79fc68758


CIV-000 fix test

Change description
Fix test for interest rate calculator
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

Closing this as change will be added in https://github.com/hmcts/civil-service/pull/2730


add travis

@namusyaka  I tried to add a travis build (see travis.yml).
I got as far as having it compile but then it errors on the tests (https://travis-ci.org/hjson/hjson-rb), e.g. NoMethodError: undefined method positive?' for -1:Fixnum`
Do you know what the problem is?

I'll take a look in a few days :)
2016年8月19日金曜日、Christian<EMAIL_ADDRESS>
@namusyaka https://github.com/namusyaka I tried to add a travis build
(see travis.yml
https://github.com/hjson/hjson-rb/blob/travis/.travis.yml).
I got as far as having it compile but then it errors on the tests (
https://travis-ci.org/hjson/hjson-rb), e.g. NoMethodError: undefined
methodpositive?' for -1:Fixnum`
Do you know what the problem is?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hjson/hjson-rb/issues/1, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAS4Ud35YuhNtIFsOAQ1fITjxdmSaaDsks5qhKppgaJpZM4JnzS9
.

Fixed and pushed. Thanks for adding an integration of travis.


Updates to transitive dependencies are incompatible

The current dependencies in setup.py have incompatibilities in the dependency tree.
Both msrestazure versions ~=0.4.11 and 0.5.0 are required.
An update to azure-mgmt-batch, azure-storage-blob, and azure-mgmt-storage resolves this issue.

Maybe adopt pipenv? https://docs.pipenv.org/
It solves the problem of non-fixed dependency versions.

pipenv is great for locking down the entire dependency tree. However, the project makes a distinction between a library (code that is published and reused) and an application (code that is to be deployed to a specific environment, and not depended on by other projects). pipenv only caters to applications, not libraries. Aztk falls into the library category since it has an SDK (and we publish to pip using the standard python tooling).
So unfortunately, pipenv just doesn't work for our use case. We do, however, use pipenv in aztk today for the code deployed on the Azure Batch compute nodes. That code falls into the application category as it is deployed on a specific environment (Batch) and needs to be reproducible. In that case, we get the benefits of locking the entire dependency tree.
The unfortunate end result of this is if any of our direct or transitive dependencies do not correctly specify versions or break semantic versioning, we will get broken for new installs. This seems to be a universal python library issue, though.

While AZTK SDK is a library, AZTK CLI on the other hand is an application.
I've recently encountered version conflicts installing AZTK CLI from older commit via pip install -e ..
IMO this could have been avoided if project contained Pipenv.lock.
Of course, the obvious workaround is for AZTK clients to use pipenv themselves. But that's an extra step.

Oh, I noticed there is requirements.txt in the project root. I guess I should first install them before installing aztk.


Peter.obert firstassettest

Readme fixed with asset names and usage

OIC - Recipes and Accelerators - Exploit Reuse
.... nevie,m ale nejaky taky by som chcel napr na ten parking lot pre Batch

Please comment in English. Comments are also public information and  I need to be able to check them. @PeterObertTCE


Cell formats not applied when importing data

Describe the bug
When initializing the component with cells that only have a value and a desired format, but aren't pre-formatted, the raw value is displayed directly.
https://github.com/ruilisi/fortune-sheet/blob/e2527a5fe656e0c91fd788f238a8072c7d93acbe/packages/core/src/modules/format.ts#L317-L319
However it would make sense to generate and cache the m formatted value using the cell's format.
To Reproduce
Initialize with e.g.
  const [sheets, setSheets] = React.useState<Sheet[]>([{
    name: "Sheet1",
    celldata: [
      { r: 0, c: 0, v: { v: "69420", ct: { "fa": "_(\"$\"* #,##0.00_);_(\"$\"* \\(#,##0.00\\);_(\"$\"* \"-\"??_);_(@_)", "t": "n" } } }
    ]
  }]);

The currency format isn't applied until we edit the value.
Expected behavior
The cell appearing as $69,420.00 instead of 69420 immediately.
Additional context
LuckySheet actually was applying formats on initialization. I'm porting LuckyExcel, which didn't generate the m pre-cached text values itself (and it'd be annoying to generate them since the formatter isn't actually exposed in the API), and it worked fine on the original version.
As an ugly workaround I'm currently using setCellFormat with the existing formats everywhere:
      <Workbook key={key} ref={sheetRef} data={sheets} style={{ flex: '1' }} onChange={() => {
        // This handler is run when the sheets themselves change, *not* any piece of data inside them.
        for (const sheet of sheetRef.current.getAllSheets()) {
          if (!sheet.data) continue;
          for (let r = 0; r < sheet.data.length; r++)
            for (let c = 0; c < sheet.data[r].length; c++)
                if (typeof sheet.data[r][c]?.ct === 'object' && sheet.data[r][c].ct.t !== 's')
                  sheetRef.current.setCellFormat(r, c, 'ct', sheet.data[r][c].ct, { id: sheet.id });
        }
      }} />

I believe that this issue closely mirrors #499, which is essentially the sheet needing manually calculated values of cells containing any types of formulae - since it updates the cells only upon editing something.
I have been using a hack to make the sheet set values programatically as a workaround, but it quickly runs into issues at scale. I believe the way to solve all of these issues without much effort would be to call jfrefreshgrid after the sheet is done loading for the first time.


dependabot support issue for gradle lockfile

As of now, dependabot has gradle lockfile support issue.

https://github.com/dependabot/dependabot-core/issues/2222

As of now, dependabot has gradle lockfile support issue.

I don't think so? The issue you refer to is still open..


Inaccurate varName in logs when printing for null value attribute

When looking in the log.txt file for problems at loading time, it seems there is a small issue when printing the variable attributes that have a null value. Here is an example of what I got:
Warning: varName=units attribute=units has values=null
Warning: varName=sdn_uom_urn attribute=sdn_uom_urn has values=null
Warning: varName=sdn_uom_name attribute=sdn_uom_name has values=null
Warning: varName=sdn_uom_name attribute=sdn_uom_name has values=null
Warning: varName=units attribute=units has values=null

As you can see, the "varName" actually takes the same value as the "attribute".
I have erddap version 2.23.

@ChrisJohnNOAA I think I found a relevant fix for this.
Attribute att = (Attribute)it.next();
String name = att.getName();
attributes.add(name, getAttributePA(name, att));

getAttributePA requires the arguments varName and attribute and here we pass the attribute name instead is probably the cause(or I may be wrong)
However I am unable reproduce the issue and cannot test the solution out, some help on how I could reproduce these Warning messages in my log.txt would be great.
For reference:

I am using the default at the time of download datasets.xml file which is serving 70 datasets by default
I am able to access the datasets normally via my local setup but the log file is filled with a bunch of http errors.

@ChrisJohnNOAA I think I found a relevant fix for this.
Attribute att = (Attribute)it.next();
String name = att.getName();
attributes.add(name, getAttributePA(name, att));

getAttributePA requires the arguments varName and attribute and here we pass the attribute name instead is probably the cause(or I may be wrong)
However I am unable reproduce the issue and cannot test the solution out, some help on how I could reproduce these Warning messages in my log.txt would be great.
For reference:

I am using the default at the time of download datasets.xml file which is serving 70 datasets by default
I am able to access the datasets normally via my local setup but the log file is filled with a bunch of http errors.

@ayushsingh01042003 I haven't run into this issue myself.
@robitaillej any advice on reproducing the bad logs? Is there perhaps a specific dataset that caused the issue?

I'm speaking from memory, not having looked anything up, but I think that:

A data source, e.g., a .nc file, may have an attribute with a null value.
If addAttributes (in datasets.xml) has an attribute with a null value, it is telling ERDDAP to remove this attribute.
So the message in the log is from when processing a data source.
The message is likely to be shown by generateDatasetsXml, as it processes new data sources and prints a lot of diagnostics. It may also be shown by ERDDAP in various situations.
I think the standard for the IOOS Glider DAC (https://gliders.ioos.us/) specifically says to use null attributes if there is an unknown value (as a placeholder). So you can probably find sample files with null attributes at the IOOS Glider DAC or by contacting John Kerfoot or someone else there.

Hello,
The dataset that was causing the problem no longer does because I looped through the data in order to get rid of the attributes causing the warning. But attached is an example of a file that will cause the warning because, as Bob mentionned, there are attributes that have null values. And it does print the warning when loading the dataset, but also when requesting data from the dataset. So it quickly pollutes the logs if those attributes are left in the files.
CTD_1982001_10_10_DN.ODF.zip

@ChrisJohnNOAA

I was wondering how can I get my local erddap to serve this .nc file. Uptill now I was just using default datasets.xml which used the < sourceUrl > and a url inside it to serve the datasets so if you could point me the relevant steps I need to do that would help.

Also as mentioned the given dataset is causing the issue because of certain null attributes, what I want to understand is are the warnings caused due to the dataset file alone or some null tag xml that we are writing for the dataset

for example:
<dataset type="EDDGridFromDap"    datasetID="erdTAsshl1day">
    <sourceUrl>https://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/TA/sshl/1day</sourceUrl>
    <reloadEveryNMinutes>10080</reloadEveryNMinutes>
    <addAttributes>
        <att name="cols">null</att>

Here, att name = 'cols' as null  so is it this piece of xml thats causing the warning or the dataset erdTAsshl1day alone causing the warning or maybe both.
(Sorry if it was not very clear, I can articulate some parts better if you need me to)

@ayushsingh01042003 @ChrisJohnNOAA That THREDDS is no longer active,  that is why it is failing. To link to that data use EDDGridFromErddap from https://coastwatch.pfeg.noaa.gov/erddap/griddap,  datasetID erdTAsshl1day.  However that will fail until about 6:00pm PDT because our building is totally shutdown for electrical work.
Also it is just good practice to check your URL before including in the datasets.xml file

For setting up a new dataset, it might be useful to take a look at GenerateDatasetsXml.

Yes,  always try to use GenerateDatasetsXml first.  But for that particular dataset,  that program will be unhappy until we come back up later today.

@ayushsingh01042003, This code:

null
will not cause the error. The incorrect log message only occurs when an attribute in a source data file has a value of null.

Warning: varName= attribute=cruise_description has values=null
Warning: varName= attribute=acknowledgment has values=null
    ioos_category=Unknown for |prespr01|||prespr01|
Warning: varName=PRESPR01_QC attribute=units has values=null
Warning: varName=PRESPR01_QC attribute=sdn_uom_urn has values=null
Warning: varName=PRESPR01_QC attribute=sdn_uom_name has values=null
    ioos_category=Unknown for |dephpr01|||dephpr01|
Warning: varName=DEPHPR01_QC attribute=units has values=null
Warning: varName=DEPHPR01_QC attribute=sdn_uom_urn has values=null
Warning: varName=DEPHPR01_QC attribute=sdn_uom_name has values=null
Warning: varName=PSALST01 attribute=sdn_uom_name has values=null
    ioos_category=Unknown for |psalst01|||psalst01|
Warning: varName=PSALST01_QC attribute=units has values=null
Warning: varName=PSALST01_QC attribute=sdn_uom_urn has values=null
Warning: varName=PSALST01_QC attribute=sdn_uom_name has values=null
    ioos_category=Unknown for |temps901|||temps901|
Warning: varName=TEMPS901_QC attribute=units has values=null
Warning: varName=TEMPS901_QC attribute=sdn_uom_urn has values=null
Warning: varName=TEMPS901_QC attribute=sdn_uom_name has values=null
    ioos_category=Unknown for |sigteqst|||sigteqst|
Warning: varName=SIGTEQST_QC attribute=units has values=null
Warning: varName=SIGTEQST_QC attribute=sdn_uom_urn has values=null
Warning: varName=SIGTEQST_QC attribute=sdn_uom_name has values=null

It looks like I was successful at reproducing the logs and printing the correct varible names. If this solution seems acceptable can I raise a PR?


GitcoinDAO Sybil Hunter Challenge 2022 No.2

GitcoinDAO Sybil Hunter Challenge No.2
Main Task:
Design 5 POAP "Proof Of Attendance Protocol" for the Sybil Hunter Challenge event happening on GitcoinDAO.

Bronze POAP
Silver POAP
Gold POAP
Platinum POAP
Sybil Hunter Master POAP 2022

Feel free to change these names here (Bronze, Silver, Gold, Platinum) and let go your imagination/creativity
Each POAP must contain these words:

GitcoinDAO
Sybil Hunting Challenge 2022

You can create the POAP using any software of your choice
Image requirements:

Mandatory: PNG / APNG format
Recommended: measures 500x500px, round shape, size less than 200KB

I will approve 2 worker to work on this bounty, 250$ each paid in Ethereum
Here is an example of the past work done: digitea00
Simply Fork this repository, add your work and submit it once you are done.

Is it over?

Is it over?

Yes it is!
Thank you very much for your interest and to everyone who participated!


Docs: Adding auditlog support for CNF Tesbed

This file documents the process of enabling auditlogs, followed by testing and finally retrieval.

@devaii: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: devaii
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [devaii]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@devaii: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

apisnoop-process-audits
3f98ed5b5399ec2f3628f0ca6738b9b44746149e
link
/test apisnoop-process-audits

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

LGTM label has been added.  Git tree hash: 48662d8557eca2762408502e20d855da796ebd33

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: devaii, hh
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [devaii,hh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: devaii, hh
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [devaii,hh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment