Git commit

Okay this one works but is definitely not as clean as I wanted. And there are way too many levels of nesting. Thoughts?

Would you mind rebasing or merging in master? 🙏

@mdiep done

Looks good apart from this.

Thanks for taking the time to review!


Fix conditions for builtins

This should fix the repeat behaviour for the f/F/t/T builtins (raised here: #24). As part of making this fix I have done some cleanup as well for logically unneeded conditions or arguments. Hopefully, this would make it easier to follow/debug the code.
This works fine on my local for the 4 builtins and custom mappings for both original and directional modes.
As a stretch I have also removed the seemingly (?) unneeded warning. As the warning was not behind any condition, nor could it be affected by any user config, I feel it should not be here. At least in the form it is now. Do let me know if there was any other idea behind it.
Let me know your thoughts.
Thanks!

This should fix the repeat behaviour for the f/F/t/T builtins (raised here: https://github.com/ghostbuster91/nvim-next/issues/24).

I wasn't able to reproduce the issue, so I cannot really test if this fixes anything as it was still working for me for some reason. Maybe a different nvim version? :thinking:
I tested your changes and it still works :+1:

As part of making this fix I have done some cleanup as well for logically unneeded conditions or arguments.

nice cleanup!

As a stretch I have also removed the seemingly (?) unneeded warning. As the warning was not behind any condition, nor could it be affected by any user config, I feel it should not be here. At least in the form it is now. Do let me know if there was any other idea behind it.

Yeah, I can't recall why I put it there. It doesn't make much sense :)

Thanks for the PR! @devansh08

I wasn't able to reproduce the issue, so I cannot really test if this fixes anything as it was still working for me for some reason. Maybe a different nvim version? :thinking:

Honestly, after looking at the issue again now I realise what I saw in my local might not exactly match it 😅. For me basically both ; and , were going in the same direction, regardless of the repeat_style. Initially looking around led me to that issue and then after diving into the code I guess I lost context on what I started with. Just began trying to get it to fix my local 😁.
But regardless the default config does seem to behave as expected for me (and you), so all should be good! Hopefully, this fixes whatever issue #24 had as well.


[1.19.2] Copper and iron large cogwheels cant be crafted from small cogwheels of the same type.

Large copper and iron cogwheels are missing the craft upgrade from their smaller version:

Possibly related the oak large cogwheel have crafts involving iron and copper ingots

Thanks for notifying me I wasnt aware of the incorrect tags for iron and copper, those have also been patched, in the latest patch (1.1.2) which should be on curseforge in a few hours once it's approved


cherry-pick #1331: fix: Using different protocols at the same time in…

… ApisixUpstream
Signed-off-by: Jintao Zhang<EMAIL_ADDRESS>
Type of change:

[x] Bugfix
[ ] New feature provided
[ ] Improve performance
[ ] Backport patches

What this PR does / why we need it:

cherry-pick #1331
Pre-submission checklist:

[ ] Did you explain what problem does this PR solve? Or what new features have been added?
[ ] Have you added corresponding test cases?
[ ] Have you modified the corresponding document?
[ ] Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

Codecov Report

:exclamation: No coverage uploaded for pull request base (v1.5.0@dd5acd3). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             v1.5.0    #1464   +/-   ##
=========================================
  Coverage          ?   29.45%
=========================================
  Files             ?       81
  Lines             ?    10176
  Branches          ?        0
=========================================
  Hits              ?     2997
  Misses            ?     6852
  Partials          ?      327

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


User buildbot is assumed to exist

When running a build where the user in the VM is named runner there's a permissions error
mkdir: /Users/buildbot/builds/runner-37/concurrent-0/externals/test/externals/test.tmp: Permission denied
Error: buildFailure

This appears to be caused by:
https://github.com/RLovelett/gitlab-fusion/blob/7a19fdbf3f713d722ab6b9266238a5add779f4e0/Sources/gitlab-fusion/Stages/Config.swift#L38
I think the --ssh-username should be used here instead.

Check the config help. Use --builds-dir to override this path. You may also need to override the cache directory as well (e.g., --cache-dir).

I think this is worth updating the top level README
https://github.com/RLovelett/gitlab-fusion/blame/main/README.md#L157-L159

If you'd like to submit an update to the README I would review it.


Add US census info to sources

@trescube did you add the Census Data by hand? Or via a script?
If by script we should add City data to https://github.com/openaddresses/openaddresses/blob/master/apply-us-data.py


fix 621, where unnamed window functions shall be differentiated by partition and order by clause

Which issue does this PR close?
Closes #621
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

should we update physical column name as well for better readability in the query output? https://github.com/apache/arrow-datafusion/blob/master/datafusion/src/physical_plan/planner.rs#L137-L139

should we update physical column name as well for better readability in the query output? https://github.com/apache/arrow-datafusion/blob/master/datafusion/src/physical_plan/planner.rs#L137-L139

i think this is more of the strategy on how we name unnamed columns in the schema. for window functions without an alias, it'll be created with a unique name, given the function type, arg name, partition by clause, order by clause, and window frames. any of these are equivalent then the columns can be thought of the same and thus deduplicated in the projection phase, otherwise they will be planned separately.

Postgres is totally okay with dup names in the projection phase:
[postgres] # select max(c1) over (), max(c1) over (), max(c1) over (partition by c1) from test limit 3;
 max | max | max
-----+-----+-----
 e   | e   | a
 e   | e   | a
 e   | e   | a
(3 rows)

if we are okay with dup names then i guess just keeping the function name would be enough

We do allow query outputs (i.e. record batch schema and physical plan schema) to contain columns with same names. This is quite common in join queries where more than one relations contain the same column name.
My previous comment was more around the inconsistency on how window function names are generated in logical plane v.s. physical plane. For example, in physical plane, we don't take partition by clause, order by clause, and window frames into account when creating the column name. If we don't want to maintain this consistency, I think we should update this invariant instead: https://github.com/apache/arrow-datafusion/blob/master/docs/specification/invariants.md#the-physical-schema-is-invariant-under-planning.
https://github.com/apache/arrow-datafusion/blob/master/docs/specification/output-field-name-semantic.md contains some rules on how we want to generate field names for physical schema. We don't have any rules for window functions at the moment, so maybe worth formalize it in that document as well.

We do allow query outputs (i.e. record batch schema and physical plan schema) to contain columns with same names. This is quite common in join queries where more than one relations contain the same column name.
My previous comment was more around the inconsistency on how window function names are generated in logical plane v.s. physical plane. For example, in physical plane, we don't take partition by clause, order by clause, and window frames into account when creating the column name. If we don't want to maintain this consistency, I think we should update this invariant instead: https://github.com/apache/arrow-datafusion/blob/master/docs/specification/invariants.md#the-physical-schema-is-invariant-under-planning.
https://github.com/apache/arrow-datafusion/blob/master/docs/specification/output-field-name-semantic.md contains some rules on how we want to generate field names for physical schema. We don't have any rules for window functions at the moment, so maybe worth formalize it in that document as well.

Thanks for the advice let me address in another pull request


W600 svd?

You seem to have added some basic support for the W600 chip, do you happen to have the svd files?

What's a svd file for W600? I don't remember to use any svd file.

http://www.keil.com/pack/doc/cmsis/svd/html/index.html
I guess you don't, thanks for answering though


Get annotations from cvat_db

My actions before raising this issue

[x] Read/searched the docs
[x] Searched past issues

Hi , I have cvat installed on a server . My labels on UI got deleted( dont know how) and after that all my annotations in all the tasks of project were gone .
I tried to add labels on UI again in hope to get my annotations back but it did not .[ while adding same labels cvat would give it different id , which is why i think it did not work ]
I looked in db_cvat volume /var/lib/postgresql/data folder .
I found pg_wal  folder having two files , when i opened those through dbeaver i could see only the Bounding Box's co-ordinates everything else looked kind of encrypted. [ added image for the reference ]

My Questions :

Can I get my annotations from this encrypted looking data ?
Can I add labels again with same id to revert everything back to normal ? [ i have old labels and their id saved in json format ]
Any other way to get annotations back ?
Where is mapping of labels and label id stored in cvat ?

Hi, the only way to delete labels is to send explicit flag "delete" to the server. Unfortunately, if your labels actually were deleted, the annotations is also were deleted from the database (relations rules). On UI you can remove labels on project/task page, but we have confirmation messages there.
I am not expert in databases, but google says that pg_wal stores WAL (Write-Ahead Logging) journals. And there is no way to restore data having only them:

If you only have the WAL, with no base backup (copy of the data directory, pg_basebackup, etc), you cannot restore.

https://dba.stackexchange.com/questions/183505/restoring-postgresql-database-from-wal-without-backup
This is not final NOT answer on your question, but restoring data this way is definitely not CVAT issue. I would suggest trying to find help in postgres community


Add a select html element that listen changes

Hi,
I would like to know if it would be possible to add the html select element in addition to the input and textarea element. I would like to load content based on the changes of a selector. Would it be possible to consider this? It just means adding the possibility to consider this element.
Thanks!

Hey @brunoprietog, thanks for the issue 👋🏻
I don't think we'd like to add that functionality to remote-input-element. It makes assumptions that only apply to elements that can take text input and if we add <select> to the mix then we'd have to have a lot of branching logic to accommodate.


Date and timezone [EST / IST] has to be mentioned. Just Day-x and time are displayed now.

Schedule -> For an event,  Date and timezone [EST / IST] has to be mentioned. Just Day-x and time are displayed now. Hence, it may be confusing for many and may not remember date and day mapping.

Go ahead and implement the day thing but time zone isn't required as there's a setting to set the time zone. Be careful while changing the implementation for days as it's dynamic currently based on what the generator data specifies.  Thanks

Thank you. It has to be picked up by some one. I had volunteered to test and share my feedback only. I am a XI class student.

Okay great but whose working this? Can you point me to the similar issue? Thanks!

I am searching, but unable to share with you a similar issue. Will revert back to you soon.

I do not think any one else is working on this. This is up for grabs! Best wishes.


Gh 627 tables difficult to scroll

#627

I've managed to get rid of the second scrollbar without changing the flex. Just need a review.

Problem here is that clicking and dragging could be used for trying to highlight text but now moves the table which is bad for user experience in the event a user is trying to copy a seed for input into a follow on operation. It should scroll when the users mouse moves close to the left and right. Alternatively you could find a way of always showing a scroll bar permanently

Done, but do you want me to write some unit tests aswell?

If you can, that would be great

Okay I had a go at writing unit tests for this but struggled. I'm not sure how to test the html elements without mocking them, they should be created but when I do getElementById() I just get null. To mock them I would have to just copy all of the code that adds the event listeners into the tests aswell and the code that controls the scroll behaviour. That doesn't seem like a nice way to test it to me. Any suggestions? Otherwise I'll leave this for now and let someone else have a go.


Database password written to process list

Environmental Info:
K3s Version: k3s version v1.18.4+k3s1 (97b7a0e9)
Node(s) CPU architecture, OS, and Version: Linux pluto 4.19.0-9-amd64 rancher/k3s#1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
Cluster Configuration: one master, five workers
Describe the bug:
If you initialize a k3s cluster with database connection details in it those details are written directly to ps. For example:
$ curl -sfL https://get.k3s.io | sh -s - --datastore-endpoint=postgres://k3s:supersecret@localhost:5432/k3s

$ ps -ef | grep k3s
root       3799      1  8 Jul10 ?        04:32:08 /usr/local/bin/k3s server --datastore-endpoint=postgres://k3s:supersecret@localhost:5432/k3s

Steps To Reproduce:

Installed K3s: see the description above

Expected behavior:
I would expect, at a minimum, that the password would be replaced with asterisks in the ps output. It might also be great to be able to put the password into a configuration file rather than store it in the systemd configuration file.
Actual behavior:
The password is free to anyone to see who has any access to the system.
Additional context / logs:
I suppose that one such solution to this would be to put the postgres database password into a .pgpass file owned by root but that wouldn't work for mysql, I don't think.

This is probably best addressed by either

using environment variables instead of command-line args
waiting for #1899 and putting the datastore uri in the config file

Those are both good ideas and reasonable solutions but I don't think that they go far enough. As long as you accept a database URI on the command line, the application should venture to obscure the password from visibility. IMO this is actually a security issue but I did not see anywhere to submit security bugs.

FYI, You can submit security issues to<EMAIL_ADDRESS>but no need to change or resubmit this issue since it is already in the open.

@plockaby does this work for you?

This is perfect. Thanks for looking into it so quickly!

Validated using the current latest commit
This now just shows the server or agent command, without additional args:
$ curl -sfL https://get.k3s.io | INSTALL_K3S_COMMIT="6fcec6aea9fcb8d79c7020cdea217ac40ccac72c" sh -s - server --datastore-endpoint="mysql://user:pass@tcp(somedb:3306)/k3s"
$ ps -ef | grep k3s
root        4064       1 56 19:01 ?        00:00:09 /usr/local/bin/k3s server
ubuntu      4327    2047  0 19:01 pts/0    00:00:00 grep --color=auto k3s
root        4328    4096  0 19:01 ?        00:00:00 /var/lib/rancher/k3s/data/d8a1e0e2fcdb1dc0a99617cda153dee4de24891e3ba102a9c272ef52e5695db4/bin/unpigz -d -c


Add a prelude

It would be nice to have a prelude module so that most code could get away with use x11rb::prelude::*;.
(But before actually creating such a module, more examples should be written to figure out what should and shouldn't be in the prelude.)

Is it worth having a prelude? Somehow I read a lot of advice towards "don't do that" recently. So perhaps this issue should just be closed.

I personally don't like preludes because I like to have more control of what gets imported into my namespace. I also think that wildcard imports will hide things from the programmer. For example:
use some_lib::prelude::*;
use other_lib::prelude::*;

// Where does this `Connection` come from?
// (I now that this would be an error if both wildcards imported
// a `Connection`, but it still won't be obvious for someone who
// don't know the libraries).
fn do_something(conn: &Connection) {
    ...
}


maxWidth or maxHeight

A beneficial addition would be the inclusion of maxWidth or maxHeight. Currently if you have a ScrollView of image assets, you cannot assign a maxWidth correctly. This proves problematic if you want to set a series of images to a specific height and have them dynamical resize, but restrict the resize to a maximum value (i.e. logos with vastly different dimensions).
Is there a way to accomplish this?

You should pass maxWidth inside styles, it should work because internally we use Image component from react native and we're passing to it all received styles. According CSS documentation the value of the max-height property overrides the height property.
You could try something like this:
<ScaledImage source={localImage} height={100} styles={{maxWidth: 200}} />

Tell me if it works. Regards!


fix(userspace/libsinsp): disable HTTP proxy for CRI connection

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
This change explicitly configures GRPC channel used for CRI socket communication to skip HTTP proxy configuration.
Since the CRI path already hardcodes unix://, the proxy will not be used anyway, but by disabling it we are silencing the unnecessary error message.
See https://github.com/grpc/grpc/blob/2de2e8dd8921e1f7d043e01faf7fe8a291fbb072/src/core/ext/filters/client_channel/http_proxy.cc#L111 and https://github.com/grpc/grpc/blob/2de2e8dd8921e1f7d043e01faf7fe8a291fbb072/src/core/ext/filters/client_channel/http_proxy.cc#L122-L125 .
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: wigol
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

LGTM label has been added.  Git tree hash: 4c895fcb8306238c373d3bebb1b9def1c1ce3151

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, wigol
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 [Andreagit97]

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: Andreagit97, FedeDP, wigol
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 [Andreagit97,FedeDP]

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


ValueError: whence != 'time' is no longer supported

I'm trying to use a tracking software which can take a video file as an input in place of a camera. However, whenever I try to run it on my desktop the feed plays a single image instead of a video, and I receive the following errors:
File "C:\Users\Work\anaconda3\lib\multiprocessing\process.py", line 315, in bootstrap
self.run()
File "C:\Users\Work\anaconda3\lib\site-packages\stytra\hardware\video_init.py", line 362, in run
container.seek(0, whence="frame")
File "av\container\input.pyx", line 232, in av.container.input.InputContainer.seek
ValueError: whence != 'time' is no longer supported
The video file works just fine with the same setup I have on my other machine, but can't find any notable differences in the environment. Is this error something you've come across before? Google doesn't seem to pull anything up, but I'm suspecting it's some issue occuring with av. Thank you!

This syntax for seek is no longer support since PyAV 7.0.0, see the changelog:
https://github.com/PyAV-Org/PyAV/blob/main/CHANGELOG.rst#v700


Feature request : override keybindings

Hi,
First, I've been waiting for such a tool for quite a time, thanks for the work. It looks really promissing !
It would be really appreciable to be able to override keybindings completely ! Is it on your roadmap ?
Thanks in advance !

I've had a few requests for vim bindings specifically, which I think is harder (supporting multiple modes); this might be doable. What would your preferred config format look like?

There may be a need for modes outside the query input area, yes, but I think that first allowing to override basic keybindings would be a good start.
For the format, what about create [bindings.*] sections in the toml file where * can be catalog, query or general ?
For specifying the keys, I dont have a préférence !

Right now setting key bindings at runtime isn't supported by Textual; I'm going to convert this to a discussion until we get an API for that.


[AIRFLOW-358][AIRFLOW-430] Add connections cli command

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

AIRFLOW-358
AIRFLOW-430

Testing Done:

core.CliTests.test_cli_connections_list
core.CliTests.test_cli_connections_add_delete
Travis CI tests pass on my branch
Also tested functionality in a Docker airflow deploy.

Here are a couple of screenshots that show the functionality

Also, I just realized that I left a change in there that is not necessary.  I defined a _types variable in the Connection model which is only used in the webserver view.  It makes sense to me to leave the definition of _types in under the Connection model,  but if it is deemed out of scope I can take it back.

Current coverage is 65.74% (diff: 90.78%)

Merging #1802 into master will increase coverage by 0.17%

@@             master      #1802   diff @@
==========================================
  Files           124        124
  Lines          9587       9663    +76
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6286       6353    +67
- Misses         3301       3310     +9
  Partials          0          0

Powered by Codecov. Last update ff45d8f...1f3b789

@PedroMDuarte +1 for taking connections list out of view and putting it under model.

@PedroMDuarte Plz follow the 50/72 rules for commit messages, i.e. commit heading should not be longer than 50 chars. You can write detailed description with each line limited to 72 chars.

@msumit Thanks for the feedback!  Just updated the commit message.

@jgao54 Did you also have a similar PR? Just an FYI.

@PedroMDuarte I'd like to merge your changes. Are you planning on taking out the _types variable?

Hi @r39132 ,  in my opinion the _types variable has a better home in the models.   But since it is unrelated to the connections CLI functionality that was implemented I would be happy to revert that change.  Let me know what you think.  Also I will go ahead and rebase this within the next hour or so.

IMO models are the best place for such information. It also helps in keeping the code DRY. If someday we've to transfer these information to a db table, then it would be straight as well.

+1 Sorry for the delay!

@PedroMDuarte +1 Sorry for the delay. Merging.


SGSSB: vxn ~~~> Gligars

Had a very similar move on my repo so it's proven work.

@HoeenCoder up to you


createEach method doesn't trigger afterCreate lifecycle callback

Sails version: 1.0.0-37
Node version: 4.5
NPM version: 2.15
Operating system: MacOs

Hello!
I just found that if you use the createEach method to create an array of objects the beforeCreate method is not called for each document.
I'm using the latest mongo adapter: 1.0.0-9
Best

@Josebaseba Do you happen to know what the behavior was on Sails v0.12.x?  I'm guessing it did fire for each record, since AFAIK createEach used to just do multiple create calls, whereas now it actually leverages the underlying database's ability (if it exists) to do batch creates...

I didn't try it with previous sails version so I can't confirm it... but I thought it was the default behavior. If this is not gonna be the default behaviour then probably it should be documented in the createEach docs 👍  Thanks!

What about having a beforeCreateEach? it should be atomic, though. And of course document both use cases

@Josebaseba @luislobo @mikermcneil Did some tests and this was definitely supported in v0.12.x, so I made a PR to add beforeCreate and afterCreate support back in 1.0.

@luislobo re: "beforeCreateEach" -- that's the plan going forward  (that's why this wasn't originally included).  But we can wait to do that until a future breaking change in Sails v2 :)   (so @josebaseba doesn't strangle me in my sleep)

@sgress454 Fair enough, and thanks @Josebaseba for using it already! You are definitelly iron in out all mongo things I will not have to worry later :grin:


Question about the evaluation

Dear Author,
We noticed that you changed your evaluation code from NOCS because the original way to calculate 3D IoU is buggy.
However I am wondering that why did you chang all your evaluation codes rather than just replace the function and keep other evaluation code:
def asymmetric_3d_iou(RT_1, RT_2, size_1, size_2):

In my experiments, your model could report this metrics in your evaluation, which is the same as the result reported in your paper

mAP 25
mAP 50
mAP 75
10cm
10°
10° 10cm
5° 5cm
10° 5cm

78.5
26
0.1
99.9
48.7
48.2
17.4
17.7

but report this result when simply repalce the asymmetric_3d_iou

mAP 25
mAP 50
mAP 75
10cm
10°
10° 10cm
5° 5cm
10° 5cm

82.9
72.3
10.3
98.1
47
46.2
16.5
44.4

Could your explain why did you chang your evaluation code in this way? Thanks a lot!

Hi, @Van5SE , thanks for asking and this is a good question that I would like to clarify.
Notice that in https://github.com/qq456cvb/CPPF/blob/main/utils/util.py#L764 and https://github.com/qq456cvb/CPPF/blob/main/utils/util.py#L754, we are denormalizing both RTs and scales.
Original NOCS assumes that gt_RTs and pred_RTs are all multiplied by the norm of the scale, and the scales would have a unit length if you print it. This step seems to be counter-intuitive, and we reverse it for code readability.
Now the scales are the actual real-world sizes of the bounding box and the determinant of rotation part of gt_RTs and pred_RTs would be 1, meaning they are proper rotation matrixes.
Return to the question, if you simply replace asymmetric_3d_iou without denormalizing rotation and scale, you will not get the correct IoU since we are assuming a real-world size and proper rotation (not really for rotation because we reverse the rotation scale on https://github.com/qq456cvb/CPPF/blob/main/utils/util.py#L188, but scales are not reversed to the real-world size, our bad anyway). To correct this, you can either reverse the real-world scales, e.g., scales *=* np.cbrt(np.linalg.det(RT_1[:3, :3]), or denormalize RTs and scales in the first place like we do.
Hope this clarifies the concern. Feel free to ask if you have any questions.

Dear Author @qq456cvb ,
Very appreciate for your replay！ I will futher understand the code based on your explanation .
Other than above, I got another question. What is your understanding of the original NOCS code on calculating 3D IoU is buggy？ I think the NOCS author might forget to add a tranpose after transform_coordinates_3d
https://github.com/hughw19/NOCS_CVPR2019/blob/14dbce775c3c7c45bb7b19269bd53d68efb8f73f/utils.py#L249 , which lead to an unreasonable 3D IoU results.
If we add a transpose we can make the results more resonable， which is the same as https://github.com/OasisYang/Wild6D/blob/main/lib/utils.py#L283 .
I was wondering whether the original code made any physical meaning or not？
Thank you very much!

Not really, the original code is calculating IoU between volumes made by bounding box corners. However, transform_coordinates_3d applies the rotation to the bounding box, making it skewed, meaning that the bounding box volume cannot be simply calculated by the product of (max - min) xyz coordinates. Therefore, this piece of code is correct only if the bounding box happens to be axis-aligned after the rotation.

So do you mean that neither origin nor transpose performs well in reality. Ojbectron is the best one to solve this problem?

Actually, we are not solving any problem or compare methods. All we need is an accurate metric that reflect the performance of different methods. We borrow the evaluation code from Objectron without using its method.

I get it . Thank you very much for your kindly patience.
Best wishes!


Update 04_Extractive_QA_with_Elasticsearch.ipynb

In vscode or local dev environment, the original code will not start the elastic search server. By launching the elastic search server in a separate command line window, the rest of the script is able to connect the elastic search server and continues successfully.

Thank you for the contribution!


Invocation of adaptive card or custom form works fine on Teams Desktop App but not in Mobile App(iOS)

I have used the TeamsTaskModule sample from the Bot Builder SDK sample. It displays the adaptive card with 3 options as below:

and ,clicking adaptive card button works fine on the Desktop app but not in Web App (Edge).

@SonOfJesseAsSnekithan - We have tested the TeamsTaskModule sample. We have checked in Edge browser but it was working fine at our end.
Could you please share the console logs to investigate further?

Sorry for the late response, it works in desktop/web app, but not in the iOS App where it gives error message, something went wrong we can not open the app right now.

It works fine now. Few things I did : (1) approve the app in teams tenant for iOS teams client to work, side loading the app is enough for desktop client. (2) updated the teams app.

@SonOfJesseAsSnekithan - Glad to hear that its working at your end.
We are closing this issue, please feel free to reopen it, if required.


kudeadm: Replace "master" with "control plane node"

This replaces the word "master" with "control plane node" in order to use
more inclusive language.
Also uses consistent wording / spelling in this context.
References: #21621
Suggested-by: Lubomir I. Ivanov<EMAIL_ADDRESS>

To complete the pull request process, please assign savitharaghunathan
You can assign the PR to them by writing /assign @savitharaghunathan in a comment when ready.

/assign @savitharaghunathan

i think we have "control-plane" more consistent in the kubeadm related pages, but it's also in the source code of kubeadm for user facing text:
https://github.com/kubernetes/kubernetes/search?q=path%3A%2Fcmd%2Fkubeadm+"control-plane"&unscoped_q=path%3A%2Fcmd%2Fkubeadm+"control-plane"
so my preference is "control-plane" for this change.

so my preference is "control-plane" for this change.

Done in 4a78a30f6d9220dd37d763525028509dbd08ba4b

Thanks. Please squash the commits to one.

Ping @neolit123 for tech review lgtm :)


concerned about DBS Migrate server design

I have opened a set of issues lately, but in the end they were all "minor technicalities", some bugs, some work on clarifying new migration server semantic and nailing down details of communication with new DBS servers. Let me do something different now.
In here I'd rather like to suggest a change in DBS Migrate server design. Up to you to listen and in case discuss further or agree or reject or whatever. This does not affect mechanics of CRAB/DBS interactions, it is only a worry of mine about possible problems.
I know it is your server and your code and in the end you will do whatever you see better. But I felt I have to voice
my concern at least once. I understand that we are late in the development cycle, maybe too late to entertain design changes, but I was not aware of how things work internally in new DBS code until now.
AFAIU current design is:

client submit request to migrate block B from some input DBS instance (typ. prod/global)
DBSMigrate looks up this block in prod/global and also locates all its ancestors
DBSMigrate creates migration requests for this blocks and all ancestors in proper cronological order and stores them in the DB
then DBSMigrate returns to client the full list of all migration requests that it creates

I see a problem there, because some blocks (imagine MINIAOD or NANOAOD) have hundreds of ancestors (I have seen one
migration request create in excess of 600 block migration requests).Therefore creating all of them takes time and exposes to the risk that an error occurs at some point in the process leaving the requests in an undefined state.
I have been looking at DBSMigrate server log with tail -f while I was submitting migration requests and I think I have seen cases where it just stops at some point w/o reaching the usual termination.
I understand that this may be rare, may happen more now because I am using testbed which may have less crunching capability,
etc. etc. and that in the end this may be a matter of taste, since worst that can happen is that migration request is ends in error and it will be retried (hopefully with delay and exponential backoff) at which point some ancestor blocks my have been migrated already.
But ....

I do not like to get errors
I do not like to receive that list of 600+ migration requests since I only care if my block eventually makes it (yes, Valentin gave me a way to check status of only that block, but.. what am I supposed to do with the list then ? dump it in my log in case it is needed for debug ?
I do not like that in case of problems debugging of DBSMigrate/DBSMigration interaction[] requires CRAB logs
[](DBSMigration is another server which reads the list of migration requests from the DB and actually performs them, in proper order and porting all parentage realtionships to new DBS instance).
I worry that even if everything works, the connection from my Client to DBSMigrate needs to stay up during the full time that all the above happens, risking to trigger cmsweb FrontEnd timeouts (like e.g. the HTTP 502 in https://github.com/dmwm/dbs2go/issues/64)
In any case my client is exposed to a lot of what are actually internal details of how migrations are done inside DBS, which it should instead be protected from. To imagine an extreme situation, DBS developerss should be free to completely change the algorithm in the current design, w/o clients like CRAB being aware.

I would rather propose that the design here follows the same line (IIUC) as old python-based DBS:

DBSMigrate is very simple and robust, and simply records the request to migrate one block in its DB and immediately assigns it a unique number which client can use to track it
later on DBS Migration server can do all the complicated work to derive parentage and migrate ancestor blocks in proper order etc.etc. and can keep track as it likes using a new DB table or creating more migrationIds or whatever.
In this way client is fully isolated, and clinet/server transaction are quick, simple and with maximum chance of success.
debugging of problems if any is fully inside DBS domain, no access to client logs needed, only a migration request ID to point to the problem
it goes w/o saying that this different design has worked extremely well for many years. Of course new implementation with a different language offers a chance to simplify and change things and new code will be extremely robust and well debugged etc. etc., I am not putting that into question. We all know difference between design and implementation.

end of preaching/ranting/hot-air-puffing.... do whatever you want with this

Stefano, thank you for your feedback. I always strive to get better experience with users.
The DBS migration process (not migration of dataset but rather entire system) is very tedious since many things are different. I'll not point to them but only to the process. As such, I followed very closely the DBS Python server architecture and only modernize it to newer technology. Said that let me first answer to your "But ..." questions

I agree that no one wants to get errors, but when things go south we need to know what happens. Many things in Python codebase were unclear, hidden, etc. I tried to standarize them and make all issues visible because, see next item
all processing should be logged, moreover, the verbose log allows to identify and debug issues. I would strongly suggest to keep log of requests and dump output of submit API. This will allow to debug the issue and idenfity what is wrong. As you keep CRAB server log, as I keep DBS, WMArchive, Monitoring, apache, k8s logs the DBS migration server output is not that different. And, if you (will) keep CRAB Publisher logs it is very good.
the crab initiate the requests and therefore it is ultimate source of the initial request. When you experience problem with DAS client, I always ask what is your query. Here is the same, I need to know your query in order to start debugging. Building scalable, concurrent system is not an easy task and asking client (in this case CRAB) to provide what it was doing is starting point of any debug process
this request is debatable, but certainly any request should be accepted within minimal interval of time. Until I investigate  #64 I can't say much and will not speculate
current design does not force anything from CRAB client, i.e. you call /submit API and feel free to close the connection. There is not requirement to keep it alive, there is no requirement to get back the results since client knows the migration input and therefore can check its status at any time using /status API.

Said that, I'll evaluate your design feedback to see how it fits. But w/o saying the Python server had so many issues that even client have not seen them on its side, we always struggled with them on server side, large RAM footprint, inability to port code to k8s, no horizontal scalability, etc. As such finding a compromise is a big challenge and we almost done it. I truly appreciate your commitment to validate the process but moving DBS from one implementation to another is significant effort and getting things working w/o errors taking time. We made it for DBSReader and DBSWriter, and significantly improved them, ported to k8s, etc., and I'm sure will reach stability of migration server soon.

thanks Valentin, I do not see need to further debate. Things are surely clear to you.
Yes, we keep Publisher logs as well, and wherever possible preferred the 'ignore the error and try again in 30 min'. Of course I need to watch for things not getting better after retries and that can be tricky, but we'll need to switch at some point, adapt monitoring to new conditions and again learn as we go. I have inherited this Publisher from others (Diego Ciangottini) and have been trying to adapt as needed w/o totally disrupting it, even if great logging was not Diego's strong point. My problem is that I do not have an easy way to retry block insert, but migrations already use the the submit-now-and-check-later which you advice,  simply a matter to make it clear when it is time to report a problem.
As you well know our problem is to deal with rare exceptions. Everything we run usually works well, we have a successful Computing system at the end of the day and CMS processes its data timely, but we process a lot of stuff and things which happens 1/10^6 become a visible operational disturbance :-(
Anyhow, we'll make it.

Stefano, I had a look at architecture of new server and walk through your suggested list. The main difference between new implementation and old one is that in new server parents of requested migration input are resolved in DBSMigrate server rather in DBSMigration one. This has two implication:

obviously due to extra work on a client side we have larger time to wait for output from '/submit' API. And, it shows multiple migration requests instead of one. This is what you observe.
but on server side it reduce RAM/CPU requirements on DBSMigration server which now only pick up migration blocks from migration table and transfer the data from one DBS to another. As such it can scale better.

I'll evaluate both approaches and make a decision but only after I will get resolution of my request for schema changes from DBA. What I plan to do is to benchmark how much time it takes to resolve parents within migration submission request and make a decision if I need to move this part into DBSMigration server. Apart from that, the work flow  and architecture among Go and Py are very similar (both servers share the same DB schema). I'll post my findings in this ticket and will follow closely your guidelines.

Yes. I think that's all I meant. There's some work to do, you need to decide if to make client wait while you do or not.
As a client, of course, I prefer not to wait. But for you that means an extra step in migration server.
You clearly understand pros and cons here.

Stefano, in order to do proper benchmarking of time required to find out all parents of a specific input I need to find out a dataset or block which may have large number of parents. If I recall correctly you mentioned before that you saw output from submit API which had hundreds of entries (I think you mentioned 600). Do you know by any chance a dataset or block which may have large number of parents, or at least give me some pointers to which pattern of datasets I should look at. This will help me to perform stress tests to decide about proper design architecture of the server.

Sure, I will look for it. But let's not worry too much here. First priority is to get it to work and deploy in production. Optimizations like this are transparent to users and can be done at any time once we have good understanding and some more experience.

here we go:
dataset='/ST_t-channel_top_4f_InclusiveDecays_TuneCP5_13TeV-powheg-madspin-pythia8/RunIISummer19UL18NanoAODv2-106X_upgrade2018_realistic_v15_L1v1-v1/NANOAODSIM'
I submitted migration request for the full dataset, 537 migrationIds in "seconds" !!
dataset='/ST_t-channel_top_4f_InclusiveDecays_TuneCP5_13TeV-powheg-madspin-pythia8/RunIISummer19UL18NanoAODv2-106X_upgrade2018_realistic_v15_L1v1-v1/NANOAODSIM'
data = {'migration_url': globUrl, 'migration_input': dataset}
print(data)
print(migrateApi.url)

result = migrateApi.submitMigration(data)
print(len(result))

gave
dataset='/ST_t-channel_top_4f_InclusiveDecays_TuneCP5_13TeV-powheg-madspin-pythia8/RunIISummer19UL18NanoAODv2-106X_upgrade2018_realistic_v15_L1v1-v1/NANOAODSIM'
data = {'migration_url': globUrl, 'migration_input': dataset}
print(data)
print(migrateApi.url)

result = migrateApi.submitMigration(data)
print(len(result))

[sorry I use Jupyter notebook for this test and have not found a way to properly copy/paste]

here's a dataset with data (not MC), 309 blocks migrations, I counted elapsed seconds:
{'migration_url': 'https://cmsweb.cern.ch/dbs/prod/global/DBSReader', 'migration_input': '/EGamma/Run2018D-UL2018_MiniAODv2_NanoAODv9-v3/NANOAOD'}
https://cmsweb-testbed.cern.ch:8443/dbs/int/phys03/DBSMigrate
309
elapsed secs: 2.6593685150146484

Stefano, thanks for finding this large datasets. If I read your posting correctly you are submitting for migration to cmsweb-testbed int/phys03 which means it is Go based server, am I right or wrong? If so, it means that current server implementation does not add additional overhead when look-up parents (which is what I expect).

Yes, you read correctly, this is go-base server. Yes "when it works it flies" :-)   BTW, you can very likely pick any NANO* dataset and get same amount of parents, i got those in the list of what CRAB users are using currently in ES, but others should also do.

@belforte , after your report with https://github.com/dmwm/dbs2go/issues/72 and https://github.com/dmwm/dbs2go/issues/69 I made necessary changes to DBS Migrate server to switch its behavior similar to Python server. Your concerns outlined here and filed issued convinced me to made a switch. The change was applied in this commit 134af018b35190a8eda4e77bf8f23bbf23d3724e and I tagged new version as v00.06.17
What is changed and how it will affect you (clients):

originally, I processed client's request directly to find out its parents and return all migration requests back to the client. As you correctly observed this lead to some latency. Until number of parents is relatively small it is not an issue. But with larger number of parents, e.g. on a scale of O(1K) it becomes an issue since we may hit FE threshold. Since I do not know if large number of parents is going to be common use-case it leads me to conclude that we should support async behavior of DBSMigrate server.
to do that, I added new code called QUEUED (with new id 5) which is what is returned back to the client with its request. It means the following:

the request is accepted and its parentage info is started in background (using goroutines, in Python server it was done through threads), i.e. it is not blocking operation. This is why only ONE entry will be returned.
once parentage information is obtained, the request is moved to PENDING status. It means that it is ready to picked up by DBSMIgration server for processing.
the rest behavior is identical with sync server, i.e. the DBSMigration server will pick up PENDING requests and process them (i.e. migrate blocks) in their correspoding order

This redesign will allow to avoid long requests which may lead to FE timeouts, but at the same time will preserve existing functionality. As such I don't expect you need to change anything in CRAB client code. The returned JSON is still a list of requests, but this time it will contain only one request dict (the original migration input). This will restore behavior of python server too where your client will not be blocked and will only see one migration request output.
I'm building new code and once it is ready I'll updated testbed with it. Then I'll ask you to submit usual amount of duplicate migration requests that we'll verify its functionality. Please note, I only made changes to change behavior of DBSMigrate server from sync to async mode. As such I do not foresee any changes in migration logic. But of course we will need a fresh test of new version.

BTW, I setup context timeout of new async server to 600sec. It means that this is maximum amount of time the new DBSMigrate server will use to find parents. This is configurable parameter though. Based on your example in https://github.com/dmwm/dbs2go/issues/69 I estimate that for O(7K) parents we need 300 seconds. I consider this as extreme outlier and therefore decided to use 600sec as default value for async server. It also means that after this time interval the DBSMigrate will cancel this async request to find parents (and free resources). This will allow to perform parent retrieval in background without blocking original client's request and at the same time avoid FE timeouts.

And, the new DBSMigrate async server now is deployed on cmsweb testbed. Please resume testing and report back with your findings.

Thanks Valentin. I am always amazed by how fast you are.
Parasitic migration to testbed is continuously running since a week, let's see how it goes. if I find problems I will open new issues.
Did you give any thought to the fact that building a separate ancestors tree for each block to be migrated will result in a very large number of duplicates and it may be much more expedient to identify the (few) ancestor datasets and simply migrate them fully w/o bothering to know which blocks are exactly needed ?

Building separate migration trees (requests) will be very challenging task since it will require knowledge of order between independent trees. So far I doubt it is possible and worth to do until we get production ready DBS migration servers. Since I made a change to async server I think we will be in a good shape but I'll put separate thoughts on how to parallelize things in a future since new architecture allows such parallelization.

hmm... I am not sure we are talking about same thing here and do not want to push you into more work, especially by mistake. I am looking for simplifications. Maybe I simply fail at it.

closing as resolved before migration to k8s.


add sample for acm certificate

This PR:

Adds a sample for generating an ACM certificate for a domain via Terraform.
Adds specific documentation for the instructions to run the sample.

Based on the community support case here


Upstreaming and/or mentioning wasmtime-async ?

Hello,
I've just finished polishing wasmtime-async, a crate designed to make it easy to run wasm code interleaved with rust async code.
So I wanted to mention it here, so you know that I've done that :) And I also wondered whether you might be interested in upstreaming its contents, and/or mentioning it somewhere in wasmtime's docs, to make it more discoverable.
Anyway, I mostly wanted to submit that to show you some thanks for having done wasmtime!
Have a nice day,
Leo

Thanks for submitting this! While I read in the docs that this is aimed at calling wasm code which does little but call async host code, for Wasmtime itself I expect we also want to consider use cases that let the runtime and WASI implementations integrate with the async mechanism, which looks like it would be hard to do with this approach. That said, this is an interesting point in the design space that I expect works well for the kinds of use cases described in the docs :-).

The world you describe would be even greater indeed! Though it looks to me as though WASI is currently not designed in a way that permits async code to exist… but maybe there are plans to change that? :)

I've opened https://github.com/bytecodealliance/rfcs/pull/2 for what it might look like supporting this in wasmtime itself, curious to hear what others think!

Awesome, thank you for this! :D


localeStructure without sub-directory keeps searching for subdirectory

localeStructure without sub-directory keeps searching for subdirectory
When changing the configuration to use a flat directory structure like this, so I can use files like common.en.json or something-else.fr.json there is an error thrown, expecting the language directory to be there.
configuration:
const path = require('path')

module.exports = {
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'de', 'fr'],
  },
  localeStructure: '{{ns}}.{{lng}}',
  localePath: path.resolve('./public/translations'),
}

Error:
Error: ENOENT: no such file or directory, scandir '/Users/con/work/project/app/public/translations/de'
at Object.readdirSync (fs.js:1047:3)
at getLocaleNamespaces (/Users/con/work/project/app/node_modules/next-i18next/dist/commonjs/config/createConfig.js:180:23)
at /Users/con/work/project/app/node_modules/next-i18next/dist/commonjs/config/createConfig.js:188:20
at Array.map (<anonymous>)
  at getNamespaces (/Users/con/work/project/app/node_modules/next-i18next/dist/commonjs/config/createConfig.js:185:44)
  at createConfig (/Users/con/work/project/app/node_modules/next-i18next/dist/commonjs/config/createConfig.js:228:29)
  at _callee$ (/Users/con/work/project/app/node_modules/next-i18next/dist/commonjs/serverSideTranslations.js:199:53)
  at tryCatch (/Users/con/work/project/app/node_modules/regenerator-runtime/runtime.js:63:40)
  at Generator.invoke [as _invoke] (/Users/con/work/project/app/node_modules/regenerator-runtime/runtime.js:294:22)
  at Generator.next (/Users/con/work/project/app/node_modules/regenerator-runtime/runtime.js:119:21) {
    errno: -2,
    syscall: 'scandir',
    path: '/Users/con/work/project/app/public/translations/de'
  }

Occurs in next-i18next version
8.8.0
Steps to reproduce
change the configuration to the one above
Expected behaviour
The loading of the files works as expected.
Additional context
I did some debugging in the createConfig.js from node-modules and found out, that the combinedConfig variable is filled correctly and these variables also look correct:
var defaultLocaleStructure = localeStructure.replace("".concat(prefix, "lng").concat(suffix), lng).replace("".concat(prefix, "ns").concat(suffix), defaultNS);
var defaultFile = "/".concat(defaultLocaleStructure, ".").concat(localeExtension);
var defaultNSPath = path.join(localePath, defaultFile);
var defaultNSExists = fs.existsSync(defaultNSPath);

console.log(defaultLocaleStructure);
console.log(defaultFile);
console.log(defaultNSPath);
console.log(defaultNSExists);

outputs:
common.de
/common.de.json
/Users/con/work/project/app/public/translations/common.de.json
true

So I think the problem relies in some un-configured namespace configuration below where path is concatinated without respecting the combined config.
var namespacesByLocale = locales.map(function (locale) {
return getLocaleNamespaces(path.resolve(process.cwd(), "".concat(serverLocalePath, "/").concat(locale)));
});

Sounds like you've debugged it thoroughly. Would definitely accept a PR for this bug fix if you have the time?

I will try to do this in the next couple of days ✌

I've created a PR for this Issue.
The basic idea is that there is a check wether the language is part of the folder structure or of the filename. If it is part of the folder structure we continue as always.
But if the language is part of the filename we assume that files of multiple languages were placed in one folder. Then we get all files of that folder and remove the language from the filename to get unified namespaces. The language is removed with a regex that will only match if the language is not part of a word. This prevents that a filename like default.de.json will be fault and not default. I have also written some tests for that regex and for the new structure.
If i unterstood Issue https://github.com/isaachinman/next-i18next/issues/1116 correct, this schould also be fixed with this PR.
Let me know if anything is missing :)

@BeckerNico Much appreciated! However, I don't think this should be solved via a regex. The solution should be declarative via the templating syntax.

Perhaps check the i18next ecosystem for inspiration, as this is where the templated path option comes from.

@isaachinman i adjusted the PR by removing the regex and using only the templating syntax to extract the namespace from the filename. What do you think?

thx @BeckerNico for taking care of this :v:

@isaachinman did you have time to look into the updated PR?

@bartrail @BeckerNico Here are my thoughts:
Based on comments like https://github.com/isaachinman/next-i18next/issues/1202#issuecomment-947779838:

I would recommend against allowing a custom localePath as this makes it not able to be statically analyzable and it will not be able to detect the files being needed automatically.

I think the most "custom" fs support we'd proceed with in next-i18next would be to allow the user to provide a custom function to resolve files/namespaces, instead of trying to predict and support all possible permutations.
I am envisioning a future state where next-i18next has a rigid expectation of ./public/locales/{{locale}}/{{namespace}}.{{ext}}, and if you want to use anything else, you will need to provide your own resolution function.
I am very hesitant to merge a PR like #1546, as it will just lead to further and further edge cases pop up, as the possibilities are literally infinite.

Hi @isaachinman, I am thinking to make this PR as you said, since Couchers is transitioning to NextJS and we need this functionality.
I was thinking to keep localeStructure/Extension for backwards compatibility, and overload loadPath to take a function as with other i18next backends, in which case localStructure/Extension would be ignored. How does that sound?

@lucaslcode I think we'd be better off introducing a new/dedicated config property, rather than overriding any i18next props.

@isaachinman my bad sorry - I meant override localePath, not loadPath

@isaachinman this is coming along. I just have a question about the workings that I can't quite figure out.
You're using i18-fs-backend as the backend by default. This only works on node afaik, yet you're creating a separate config for the client which strips /public from the path to the translation files. Does the client actually use the files or is there some other reason for this? Does that mean the resources by necessity need to be in the public directory in order to be reachable from the client?
Thanks so much!

Does that mean the resources by necessity need to be in the public directory in order to be reachable from the client?

If you want it to work out of the box, yes. The docs are here.
Let me know if I can answer any other questions, and a massive thanks for digging into this!


Adopt Sender.append() and flush()

Implements the Sender.append() and Sender.flush() methods requested in https://github.com/jaegertracing/jaeger-client-python/pull/186#pullrequestreview-125400053 in an attempt to get those changes sourced.
Signed-off-by: Ryan Fitzpatrick<EMAIL_ADDRESS>

@ProvoK, if you're interested in continuing with these changes, do you mind rebasing your branch to update the dependencies for successful CI runs?

@rmfitzpatrick Hello there,
thanks for continuing the work! Yes I'm interested, I was a lot busy in the last period, that's why I was not working on it.
I'll update my branch and review your change asap 😉

@rmfitzpatrick I've fetched upstream master and merged into my branch. This is what I can do till Monday, sorry!

Codecov Report

Merging #1 into send_spans_over_http will increase coverage by 0.4%.
The diff coverage is 100%.

@@                   Coverage Diff                   @@
##           send_spans_over_http       #1     +/-   ##
=======================================================
+ Coverage                 94.86%   95.27%   +0.4%
=======================================================
  Files                        26       26
  Lines                      1812     1840     +28
  Branches                    227      228      +1
=======================================================
+ Hits                       1719     1753     +34
+ Misses                       59       55      -4
+ Partials                     34       32      -2

Impacted Files
Coverage Δ

jaeger_client/senders.py
98.73% <100%> (+4.98%)
:arrow_up:

jaeger_client/reporter.py
95.89% <100%> (+2.55%)
:arrow_up:

Continue to review full report at Codecov.

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

@ProvoK, thanks for the feedback, which I believe I've addressed as requested with the exception of https://github.com/ProvoK/jaeger-client-python/pull/1#discussion_r202802357 to match the logic of other clients.  Let me know if you still request that change and I'll be happy to do so, or if you have any other notes.

@ProvoK, the idiomatic exception handling seems to be swallowing exceptions.  Currently investigating, but I did have luck with the unified exception tornado.gen.Return style.  Would you be okay if we submitted that approach to the jaeger team for their thoughts?

Thanks @rmfitzpatrick for your work, I'm going to merge this, and I'll quote in in the original PR.


Lift + shift for cross-db macros

Continues #594
This is a:

[ ] documentation update
[ ] bug fix with no breaking changes
[ ] new functionality
[ ] a breaking change
[x] behind-the-scenes refactor

Description & motivation
See:

https://github.com/dbt-labs/dbt-core/pull/5298
https://github.com/dbt-labs/dbt-redshift/pull/120
https://github.com/dbt-labs/dbt-snowflake/pull/162
https://github.com/dbt-labs/dbt-bigquery/pull/192

To do before merge

[ ] Reset dev-requirements.txt back to original
[x] Explicitly document the definition of dbt_utils.current_timestamp() before and after (for each database)

[x] Determine if the definitions are logically equivalent or not

[x] Determine how to handle tests decorated with @pytest.mark

current_timestamp()
Database adapters already had a previous definition of current_timestamp(), and it is often expressed differently than within dbt-utils. I worry that this could lead to a breaking change, so we should determine if they are logically equivalent or not.
core/dbt/include/global_project/macros/adapters/freshness.sql
We have some options for how to handle this:

Keep the existing definition within each database adapter and discard the dbt-utils definition
Overwrite the existing definition within each database adapter in favor of the dbt-utils definition
Keep the existing definition within each database adapter and re-institute the dbt-utils definition back into the macros/cross_db_utils folder.

Comparisons
See below for a comparison between the existing adapter definition vs. the dbt-utils definition.
Default
Adapter:
core/dbt/include/global_project/macros/adapters/freshness.sql
{% macro default__current_timestamp() -%}
  {{ exceptions.raise_not_implemented(
    'current_timestamp macro not implemented for adapter '+adapter.type()) }}
{%- endmacro %}

dbt-utils:
cross_db_utils/current_timestamp.sql
{% macro default__current_timestamp() %}
    current_timestamp::{{dbt_utils.type_timestamp()}}
{% endmacro %}

Postgres
Adapter:
plugins/postgres/dbt/include/postgres/macros/adapters.sql

{% macro postgres__current_timestamp() -%}
  now()
{%- endmacro %}

dbt-utils:
cross_db_utils/current_timestamp.sql
{% macro default__current_timestamp() %}
    current_timestamp::{{dbt_utils.type_timestamp()}}
{% endmacro %}

Redshift
Adapter:
dbt/include/redshift/macros/adapters.sql

{% macro redshift__current_timestamp() -%}
  getdate()
{%- endmacro %}

dbt-utils:
cross_db_utils/current_timestamp.sql
{% macro redshift__current_timestamp() %}
    getdate()
{% endmacro %}

Snowflake
Adapter:
dbt/include/snowflake/macros/adapters.sql

{% macro snowflake__current_timestamp() -%}
  convert_timezone('UTC', current_timestamp())
{%- endmacro %}

dbt-utils:
cross_db_utils/current_timestamp.sql
{% macro default__current_timestamp() %}
    current_timestamp::{{dbt_utils.type_timestamp()}}
{% endmacro %}

BigQuery
Adapter:
dbt/include/bigquery/macros/adapters.sql
{% macro bigquery__current_timestamp() -%}
  CURRENT_TIMESTAMP()
{%- endmacro %}

dbt-utils:
cross_db_utils/current_timestamp.sql
{% macro bigquery__current_timestamp() %}
    current_timestamp
{% endmacro %}

@dbeatty10 Amazing work thus far!
Let's split out the current_timestamp work into its own separate effort: https://github.com/dbt-labs/dbt-utils/issues/599. That way, the unresolved questions there don't have to block the bulk of this work, even if it means we need another follow-on PR in each plugin.
One realization I had with regard to backwards compatibility, which I don't think I was clear on in https://github.com/dbt-labs/dbt-utils/pull/594: This approach will break, I believe, anyone who is currently using a "shim" package (e.g. spark-utils, tsql-utils), and dispatch config that redirects macros from the dbt_utils namespace to prefer the "shim" package namespace. That is, if I have this in my project, as recommended:
# dbt_project.yml
dispatch:
  - macro_namespace: dbt_utils
    search_order: ['spark_utils', 'dbt_utils']

Because dbt_utils.dateadd is now being dispatched into the dbt namespace, rather than the dbt_utils one, it will stop preferring spark_utils.spark__dateadd. That's ameliorable in one of three ways:

We also add spark__dateadd to dbt-spark, which we should do (https://github.com/dbt-labs/dbt-spark/pull/359), but can't necessarily rely on all adapter maintainers to be complete with this
We tell users to switch the macro_namespace in that dispatch config from dbt_utils to dbt —  which works, but we should really aim to avoid any required changes to user project code when upgrading minor versions
We add slightly more boilerplate code in this PR (blech), to preserve dbt_utils as one step along the dispatch train. So replacing this:

{% macro any_value(expression) -%}
    {{ return(adapter.dispatch('any_value', 'dbt') (expression)) }}
{% endmacro %}

With this:
{% macro any_value(expression) -%}
    {{ return(adapter.dispatch('any_value', 'dbt_utils') (expression)) }}
{% endmacro %}

{% macro default__any_value(expression) -%}
    {{ return(adapter.dispatch('any_value', 'dbt') (expression)) }}
{% endmacro %}

And maybe a note at the top of every file, "This is here for backwards compatibility only"?

Sounds great @jtcohen6 -- I will split out the current_timestamp work as you described.
In terms of backwards compatibility, I'm most attracted any solution that preserves full backwards compatibility without users or shim maintainers needing to do anything. So I'll take a swing at implementing the approach you described in the 3rd option for amelioration.
If we want, we can also add a deprecation warning so we have the option to fully remove this boilerplate in a future major release.

@dbeatty10 Oy, this gets deep quickly. I stuck a few debuggers in a few places, and came up with strong evidence that this is indeed a circular dependency. Some printing from the end of this method:
dbt_redshift.redshift__dateadd: MacroDependsOn(macros=['macro.dbt_utils.default__dateadd'])
dbt_postgres.postgres__dateadd: MacroDependsOn(macros=[])
dbt.dateadd: MacroDependsOn(macros=['macro.dbt_redshift.redshift__dateadd'])
dbt.default__dateadd: MacroDependsOn(macros=[])
dbt_utils.dateadd: MacroDependsOn(macros=['macro.dbt_utils.default__dateadd'])
dbt_utils.default__dateadd: MacroDependsOn(macros=['macro.dbt_utils.dateadd', 'macro.dbt_redshift.redshift__dateadd'])

dbt_redshift.redshift__dateadd → macro.dbt_utils.default__dateadd → macro.dbt_redshift.redshift__dateadd
That first bit doesn't look quite right, but everything else does. I'd expect dbt_redshift.redshift__dateadd to depend on macro.dbt.default__dateadd, not macro.dbt_utils.default__dateadd! Well... I think this is because we have special macro resolution rules for "internal" macros (dbt.*), since they're more eagerly overridden by end users who want to reimplement internal functionality: get_macro → this search order is defined here (prefer dbt_utils > dbt). Ultimately, instead of returning dbt.default__dateadd, this line returns dbt_utils.default__dateadd.
We could go very deep on this logic... or we could just duplicate the dateadd logic in dbt-redshift:
{#-- redshift should use default instead of postgres --#}
{% macro redshift__dateadd(datepart, interval, from_date_or_timestamp) %}
    dateadd(
        {{ datepart }},
        {{ interval }},
        {{ from_date_or_timestamp }}
        )
{% endmacro %}

That "just works."

Thank you for the explanation and examples, @jtcohen6!
As an aside
Do you interpret this as an issue? i.e., is it worth creating a ticket in dbt-core that describes this (undersireable?) behavior when mixing dispatch to an internal and non-internal package?
My next actions
As you suggested, I will copy-paste all the relevant logic into the Redshift adapter. Then all the tests should pass and then we'll be safe to merge this batch of pull requests.

Do you interpret this as an issue? i.e., is it worth creating a ticket in dbt-core that describes this (undersireable?) behavior when mixing dispatch to an internal and non-internal package?

It's a very niche edge case, but it all adds up to some unexpected behavior. I think an issue for it is totally justified. That could be me or could be you, let's take it as a TODO.

Comparison, revisited
In this comment, I showed the results of a functional test to comparing the competing definitions for current_timestamp() from the adapter vs. dbt-utils. At the time, that testing didn't find any differences when comparing values.
The method used to obtain this result always made me feel uneasy -- just because it didn't find any differences doesn't guarantee that there weren't any differences! 😅
Since @colin-rogers-dbt is digging into an implementation for https://github.com/dbt-labs/dbt-core/issues/5521, I revisited this comparison and took a different approach.
Approach

Get the rendered SQL for both adapter vs. dbt-utils for each adapter
Manually look up the vendor-specific documentation for relevant functions to determine the final data type
Translate the final data type to its semantic data type

Semantic data types
Snowflake has 3 different timestamp data types that are (generally*) representative of the observed behaviors across different databases: TIMESTAMP_TZ, TIMESTAMP_NTZ, and TIMESTAMP_LTZ.
At risk of further confusion (and introducing a 15th competing standard), I will use the following nomenclature instead of the Snowflake-specific counterpart:

TIMESTAMP_TZ → "offset timestamp"
TIMESTAMP_NTZ → "civil timestamp"
TIMESTAMP_LTZ → "session timestamp"

Results

Takeaways

❌  There appear to be data type mismatches between dbt-utils and dbt-core+adapters for Snowflake and Postgres

✅ Meanwhile, Redshift, BigQuery, and Spark appear to have matching data types between implementations

⚠ The implementations across dbt-utils use a mix of all 3 timestamp data types

Snowflake, Postgres, Redshift all use civil timestamps whereas BigQuery* uses offset timestamps and Spark uses session timestamps

⚠ The implementations across dbt-core+adapters also use a mix of all 3 timestamp data types

Redshift uses civil timestamps, Snowflake and BigQuery* use offset timestamps, and Postgres and Spark use session timestamps

The best way to verify these results intra-database would be to materialize tables with the results and then query the datatypes.
Being able to automatically discover the semantics of different data types across databases (based on behaviors) will require a bit more ingenuity.

* From the best I can tell, there are 3 different alternatives for how to think about the TIMESTAMP data type in BigQuery:

"session timestamp" where UTC is the session default, but it can be changed (👈 maybe this is the correct way to think about it? This seems to lend credence in this direction.)
"offset timestamp" where the offset is always UTC (what I've chosen here, somewhat arbitrarily)
A unique fourth timestamp data type

Would love to be shown the light by anyone that knows for certain.
Regardless of which of the three is most accurate, it doesn't affect the takeaways above.


Add @ivey.ca

https://www.ivey.uwo.ca/

@nobodyrandom Could you please rename lib/domains/ca/ivey to lib/domains/ca/ivey.txt? The .txt extension is mandatory in this repository. Also, you may wish to correct spelling in the description of the school, which now says "Ivey Busines School". You can actually keep it untouched if you think that there is no typo there. Thank you!

@philipto The university name is correct
Thanks

@nobodyrandom Pull request merged. Thank you!


Release notes broken in 1.2

After upgrade to 1.2.0, the release notes page is still showing the "Restart and update" button and is missing the release notes for the current version:

I have the same issue on OSX 10.10.5 :+1:

Win 7 here, same thing.

Same to.

Thanks for the report! This looks like a duplicate of https://github.com/atom/atom/issues/8315 - let's keep the discussion going there.


Phpunit tests fails on 64-bit systems

I'm seeing 2 tests fails on Win 10 64 bit.
This definitely happens because of PHP integer overload on 64 bit systems.
This can be fixed by adding quotes to dataprovider values in LuhnTest to convert em to a strings.
Especially, values<PHONE_NUMBER>01825 and<PHONE_NUMBER>13942
There were 2 failures:

1) Faker\Test\Calculator\LuhnTest::testComputeCheckDigit with data set #9<PHONE_NUMBER>01825, '0')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'0'
+'7'

E:\Projects\faker-fork\test\Faker\Calculator\LuhnTest.php:34

2) Faker\Test\Calculator\LuhnTest::testComputeCheckDigit with data set #10<PHONE_NUMBER>13942, '4')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'4'
+'3'

I created PR to fix that https://github.com/fzaninotto/Faker/pull/983

Fixed by #983


Change binder's color in runtime

Hey! Is there an actual way to change the color of the binder attached via script? Or any way to access the colors of the current theme? Some situations require to dynamically update component's color in runtime.
Some other comments:

in the readme the package name includes a "`" at the end which prevents installation
happened only once but when closing Unity and opening back all the changes done in the theme window were reverted (scene was saved before closing)
would be great to re-order colors in the theme window

Thanks a bunch for your work, it's a very clean asset to manage themes!

@LeMutique Hey, thank you!
Sounds like you are looking for this:
Theme.Instance.CurrentTheme.colors

Thanks, just fixed that
Hm, not sure about that. Please let me know if you can catch it and provide more information
Totally agree, I wanted to add this feature. It needs more time, it will be added a bit later

Excellent thank you very much, will open an issue if I manage to reproduce the saving issue!


fix cni mtu logic

Describe what this PR does / why we need it
Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.摩羯 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


SQL: use default location from resource group

SQL commands should use new get_default_location_from_resource_group validator to create servers in the default location for the resource group.

Let's not close this. We should do it.


npth: install npth-config binary

Description of changes
We need the configure flag otherwise the binary won't get installed.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

cc @alyssais @stuebinm

[just fyi: my only change in this package was an automated script to add a value to mainProgram; I have otherwise no involvement with this package recipe and thus also no opinion on any changes touching it, and will unsubscribe from this thread again]

Often we put -config binaries in a dev output. Is that worth doing here?

I don't know if this implies other breaking changes. I'd prefer to leave it as is for now.

Unless I'm mistaken, it's not a breaking change to do it now, but it would be a breaking change to move it later, so we have to get it right now.  Is there a reason it shouldn't be in dev?


Error: failed to compile spl-token-cli v3.3.0, with latest Rust and Solana cli along with cargo cant install spl token cli

When installing using command cargo install spl-token-cli I get the following error
error: failed to compile spl-token-cli v3.3.0, intermediate artifacts can be found at /tmp/cargo-install8eI2bJ

Hey there, I can't seem to reproduce the issue. I think it would help if you shared the specific version of cargo you're using. The Solana CLI shouldn't be involved here.
There's also a --verbose flag you should use when running cargo install in order to potentially show some more information about the error.


[Android] Disable StatusBar

I am using:
  <View style={{flex: 1}}>
      <StatusBar hidden={true} />

but when I press any button or there is some event status bar is showing. Is there any option for disable it like forever. I am using WebView..

@facebook-github-bot stack-overflow


formatCardNumber kills change events in IE11

change events are never fired in IE11 if formatCardNumber is set on that input.

Reproducible: http://output.jsbin.com/yujefiqari/1

Looks like reFormatCardNumber rewrites the input during the input event, but outside the initial event loop, which in some what kills the change event. Been testing for a bit, but browserstack is killing me with it's slowness.

same with reFormatNumeric

having the same issue with IE11

Having tried your fiddle, it looks like binding solely to the change event doesn't work in Firefox 40 either. Although it's a mildly different issue, in my own script I'm binding to input change focusin paste, which works for the most part except when spaces are automatically inserted between the numbers (which should come under change, as far as I'm aware) - it waits until I add another number, and then suddenly adds the last number of the set before the space, the space, and then the next number. I can't figure out how fix it.

Sorry for the late reply!
I believe this is actually an issue with browsers disagreeing (and possibly jquery itself). Here is a jsfiddle that demonstrates the issue: using $(input).val(newVal) will kill change events in Safari and Chrome under some circumstances, but not in Firefox. You can find more discussion about browsers disagreeing about 'change' events here. Since 'change' is so non-standard, I recommend binding on other events as well (just like jquery.payment itself does).

We are still seeing this issue on IE11. @jenanwise we are binding to 'input' and 'paste' events as you suggested, but as @indextwo pointed out the e.preventDefault() also prevents bubbling in IE11. We followed his fix and the issue was resolved.


SubSupText asserts when running the xss (cross site scripting) string test

This was originally noticed on Resistance in a Wire, see https://github.com/phetsims/resistance-in-a-wire/issues/72.  When testing with the query parameter stringTest=xss (for checking whether any vulnerabilities exist for cross site scripting), the code hits the following assertion in SubSupText:
assert && assert( matchString === '' || matchString === ''

Without assertions enabled, the sim crashes in SubSupText due to undefined variables.
I discussed this with @jonathanolson and he says that this doesn't mean that there actually is any sort of cross scripting vulnerability.  He suggested adding a workaround in SubSupText to detect the query parameter and substitute a different string, but I find this a bit distasteful.  Marking for the next dev meeting and we can decide what to do.

I'm not familiar with how the xss test is implemented, so I have nothing to recommend.

The XSS test sets every string to the following:

It has things that SubSupText treats like invalid tags (for it), so it fails out. Since SubSupText can't cause XSS problems, it would be best if we had it basically ignore those strings.

+1 for having SubSupText ignore invalid tags.

@jonathanolson suggests a minor rewrite so that assertions will still fail, but so that when assertions are removed it will .....??
@jessegreenberg suggests putting sub/sup elements in the test string:
hello<img src="data:image/png;base64,...

How about
if (global.runningXSSTest){
  string='hello'
}

?

@jbphet said we should extract any parts of the string SubSup text can't handle.

@jonathanolson points out that the long term solution is to do server-side validation of the strings.

We cannot run ?ea for translators, it could cause the sim to fail to start up, and the translator wouldn't know why.

@jbphet will create a rosetta issue for server-side validation.
For now we will ignore any tags that SubSupText doesn't understand.

Added breaks that only happen if an assertion would have failed, and prevents bad nesting.

Reopening. This is still failing in resistance-in-a-wire and all sims that use SubSupText.  It came up during code review of function-builder, in https://github.com/phetsims/function-builder/issues/84.

I'm also unclear on the Rosetta-side implications of this. Do we have a translation problem that we don't know about for sims that use SubSupText?

Assigning to @ariel-phet because (1) @jonathanolson is on leave, and (2) this impacts all sims that use SubSupText (acid-base-solutions, beers-law-lab, build-a-molecule, graphing-lines, molarity, ph-scale, reactants-products-and-leftovers, resistance-in-a-wire,...)

In one of the comments above, @pixelzoom asks,

Do we have a translation problem that we don't know about for sims that use SubSupText?

There is a chance that a user could mess up a SubSupText string and cause the simulation to not run correctly, which is what issue https://github.com/phetsims/rosetta/issues/130 is all about.  As @jonathanolson says above, this is not a cross site scripting vulnerability, it's just an issue for the sims themselves.  To our knowledge, none of the translations have run into this issue, which is why this isn't a top priority to fix.

Then is shouldn't cause an assertion failure with stringTest=xss, non?  Otherwise we can't fully test XSS, since there may be other issues that occur after this incorrect failure.

Perhaps the solution is as simple as: "the stringTest=xss test should be run with assertions disabled" ??

We are currently going to ignore for function builder, and address this when @jonathanolson returns from leave

Added workaround for now, so function builder and other things that have SubSupText will not fail when passed the XSS testing string. Just ignoring unrecognized tags seems like a recipe to have things break without throwing an error.

The commit above looks incorrect, and I believe that it is causing problems for SubSupText.  It looks like it is expecting to not enter the if clause if the tested string is not found, but the return value is -1, which is not 'falsey', and the clause is being entered.
    if ( text.indexOf( 'data:image/png;base64' ) ) {
      text = 'XSS Test, see Scenery issue #528';
    }

Right, it looks like it should be changed to
    if ( text.indexOf( 'data:image/png;base64' )>=0 ) {
      text = 'XSS Test, see Scenery issue #528';
    }

Fixed in https://github.com/phetsims/scenery-phet/commit/b7374526d5e9c1c110e3651ce768af845de833a0.

Thanks, sorry about that. Commit looks good.

Noticed by @phet-steele.
@jonathanolson SubSubText is failing when for several sims when run with stringTest=xss.  acid-base-solutions, beers-law-lab, build-a-molecule, capacitor-lab-basics,...

Assertion failure is at line 141 of SubSupText:
          assert && assert( matchString === '' || matchString === '',
            'Unexpected tag in normal mode: ' + matchString );

Should be handled properly in the above commit. I should have noticed setText earlier (the constructor AND setText both set this._text, which is somewhat atypical).

Change to workaround verified in ABS (previously failed) and BCE (previously passed).

When ?stringTest=xss, window.phet.chipper.mapString is set on line 340 in initialize-globals.js.  I.e.:
             stringTest === 'xss' ? '' :

The current workaround duplicates part of the assigned value:
if ( this._text.indexOf( 'data:image/png;base64' ) >= 0 ) {
  this._text = 'XSS Test, see Scenery issue #528';
}

Here's a workaround that doesn't have that problem:
if ( phet.chipper.queryParameters.stringTest === 'xss' ) {
   this._text = 'XSS Test, see Scenery issue #528';
}

@jonathanolson should we change this?

I like that change. Committed.

Verified again with ABS (previously failed) and BCE (previously passed).

Ah crap... The change that I suggested causes the workaround to be applied for all strings, not just translated strings.   And that creates brand new i18n layout issues like https://github.com/phetsims/balancing-chemical-equations/issues/121.  So I have reverted that change.
@jonathanolson Any other ideas to address the fragility noted in https://github.com/phetsims/scenery/issues/528#issuecomment-291257852?  Or should we just leave this alone.

Reverted in https://github.com/phetsims/scenery-phet/commit/8ea5852c9b9d9d088573a3143447e32770cbb93c.

Would looking into using RichText be an acceptable (almost) replacement for SubSupText?
It's not fully compatible, as RichText treats its content as HTML, so the & character (if desired) would need to be encoded as & in RichText.
RichText does handle bidirectional text properly, where SubSupText only combines LTR (reversing the order for RTL text), so replacement may be desirable.
Thoughts?

Assuming that we have review and consensus on RichText (see https://github.com/phetsims/scenery-phet/issues/300)...  I'd definitely like to see SubSupText deprecated.  There are 44 occurrences of var SubSupText, so replacing existing uses would be a bit of work, but I'd probably do that for my sims in any case.    So... Let's wait and see.  Assuming that SubSupText is deprecated, I'm fine with leaving the existing workaround as is.

Replaced with RichText, closing.


Updates for Stacks Wallet v3

Modifying emphasis >
Style updates to em and code
Adding wallet security page
Updated the glossary with security terms

The example needs to be updated currently the wallet displays this message for fees and requires 0.00035076

BTW, my understanding is the fee for any transaction is market driven. None of my screencaps in terms of amounts will ever be an exact match. Users won't expect them to.  I believe that is what you were pointing out with this comment.

Ok that makes sense if the number of BTC is not an issue we can proceed as is.

Ok that makes sense if the number of BTC is not an issue we can proceed as is.
keyphrase.md doc has broken image icons, I know you said that you were still working on the images so this is probably already on your radar correct?

I am not seeing any project images.  What are you seeing?

@timstackblock @moxiegirl Are we looking good to release these changes by EOD today?

@markmhx I'm waiting for the installation DMGs to go live. Then I will push this live.


Aggregate state snapshots

Implement rolling snapshots for aggregate state. This uses the memento pattern to serialize an aggregate's state. The serialized state is stored in the Event Store as snapshot data.

As an example, assume the snapshot was taken after persisting an event for the aggregate at version 100. When the aggregate process is restarted we load and deserialize the snapshot data as the aggregate's state. Then we fetch and replay the aggregate's events from version 100.
This is a performance optimisation for aggregate's that have a long lifetime or raise a large number of events.

I've done this on my own. It is not hard, just tricky.
Yes, you need to callbacks on the aggregate:

save_to_memento
load_from_memento(memento)

These would in the same place as the apply method is right now.
For snapshot stream, I use AggName-snapshots-AggID. So for aggregate Foo with id 123 it would be Food-snapshots-123.
The process that does "loading" from snapshots and events I call the hydrator, and here is there relevant piece of code (I'm sure your implementation is much more elegant, but you get the gist):
    def do_hydrate_from_snapshot(%Hydrator{snapshot_stream_id: id}=state) do
       state2 = case EvStore.read_events_backward(id, -1, 1) do
         {:error, :NoStream, _} -> state
         {:ok, %{events: events}} ->
            [snapshot] = Adaptor.from_external(events)
            hydrate_from_snapshot(snapshot, state)
       end
       # Now start hydrating from events
       send self(), :hydrate_from_events
       {:noreply, state2}
    end

    def hydrate_from_snapshot(%Snapshot{memento: m, event_number: n}, %Hydrator{agg_mod: agg_mod, agg_pid: agg_pid}=state) do
       :ok = agg_mod.load_from_memento(agg_pid, m)
       %{state | last_event: n, last_snapshot_event: n}
    end

@drozzy Thanks for the feedback.


Cant find ReactNativeComponentTree file

"dependencies": {
"native-base": "^2.8.1",
"react": "16.5.0",
"react-native": "0.57.0",
"react-native-fs": "^2.11.15"
}
I can't find ReactNativeComponentTree this one.
If they deprecate this then please tell me the way to get current element or node from event.target or event.currentTarget

same issue here


Start moving example code from docs to runnable code

Move example code from documentation from pure markup to real code which is being verified during build.
See also: https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-literalinclude

@dropwizard/committers This is meant as a start to see if this approach is feasible. We can move the example code one by one in future PRs (or get some help from the community) if it makes sense.


Add the feature to EDIT the telework form due to high demand from users (managers).

I spoke to a manager on Tuesday March 26 via Teams who addressed that she and other managers are frustrated by the inability to edit the telework form.
Scenario:
A typical process flow would be for an employee to submit a telework agreement, hoping for 5 days a week at home (for example), when 2 to 3 days is the average allowed, or selecting days to work from home when a mandate is set for employees to be in the office on a specific day(s). This will require an edit, which would be easier to update from the managers point of view rather submitting a new form.

Edit before or After approval?
Edit existing agreement
Is there a record of what approval was previously granted
Recommend: before approval edit after NO, submit a new form

How long can you edit? Until after the supervisor approves?

Spoke with Sean at policy he gave employee draft/edit go ahead. no supervisor edits just approval/deny

Required to change estimation from 3 story points to 5.
In this ticket,

We will allow employees to edit the form before it is approved or denied by the supervisor.
The supervisor will only be able to approve or deny the form, but will not be able to edit the form data.
Incomplete submissions will be deleted 60 days after submission.

@fazil-ey @Stella-Archer @ayushdamani
In the telework, we cannot enable editing for older submissions, nor can we hide the edit button for those submissions. To address this issue, I have added a label to the form for older submissions. This label will display a message, as shown in the screenshot, at both the top and bottom of the form.

@Bhumin "This telework submission cannot be edited. However, new submissions can be edited before the supervisor submits a decision"

It is ready to test on DEV and TEST environment.
Note: The new message provided above for the old form will not be visible in the DEV or TEST environments. However, it will be implemented in the PROD environment next week.
Please test edit telework form and workflow in detail, and if you try to edit older form old message will be display for now.

Tested and confirmed working - thanks so much Bhumin!


Inlay hints don't work

Issue Description
I've enabled inlay hints using the following settings:
"csharp.inlayHints.parameters.enabled": true,
"csharp.inlayHints.types.enabled": true,
"csharp.inlayHints.types.forImplicitVariableTypes": true,
"csharp.inlayHints.parameters.forLiteralParameters": true,

but inlay hints don't work and there are number of repated messages in Omnisharp logs
Steps to Reproduce

Install .NET on ArchLinux using dotnet-install.sh
Create sample program like this:namespace Demo
{
    class Program
    {
        static int add(int a, int b)
        {
            return a+b;
        }
        static void Main(string[] args)
        {
            var a = 10;
            add(1, a);
        }
    }
}

See no inlay hints and errors in the OmniSharp logs

Expected Behavior
Inlay hints woking for both variable types and argument names
Actual Behavior
In inlay hints are shown
Logs
OmniSharp log

[fail]: OmniSharp.Stdio.Host
        ************  Response (49.7946ms) ************
{
  "Request_seq": 1427,
  "Command": "/inlayHint",
  "Running": true,
  "Success": false,
  "Message": "\"System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'index')\\n   at Microsoft.CodeAnalysis.Text.SourceText.LineInfo.get_Item(Int32 index)\\n   at OmniSharp.Extensions.TextExtensions.GetPositionFromLineAndOffset(SourceText text, Int32 lineNumber, Int32 offset) in /Users/runner/work/1/s/src/OmniSharp.Roslyn/Extensions/TextExtensions.cs:line 28\\n   at OmniSharp.Extensions.TextExtensions.GetSpanFromRange(SourceText text, Range range) in /Users/runner/work/1/s/src/OmniSharp.Roslyn/Extensions/TextExtensions.cs:line 55\\n   at OmniSharp.Roslyn.CSharp.Services.InlayHints.InlayHintService.Handle(InlayHintRequest request) in /Users/runner/work/1/s/src/OmniSharp.Roslyn.CSharp/Services/InlayHints/InlayHintService.cs:line 56\\n   at OmniSharp.Endpoint.EndpointHandler`2.GetFirstNotEmptyResponseFromHandlers(ExportHandler`2[] handlers, TRequest request) in /Users/runner/work/1/s/src/OmniSharp.Host/Endpoint/EndpointHandler.cs:line 218\\n   at OmniSharp.Endpoint.EndpointHandler`2.HandleRequestForLanguage(String language, TRequest request, RequestPacket packet) in /Users/runner/work/1/s/src/OmniSharp.Host/Endpoint/EndpointHandler.cs:line 234\\n   at OmniSharp.Endpoint.EndpointHandler`2.Process(RequestPacket packet, LanguageModel model, JToken requestObject) in /Users/runner/work/1/s/src/OmniSharp.Host/Endpoint/EndpointHandler.cs:line 143\\n   at OmniSharp.Stdio.Host.HandleRequest(String json, ILogger logger) in /Users/runner/work/1/s/src/OmniSharp.Stdio/Host.cs:line 258\"",
  "Body": null,
  "Seq": 134756,
  "Type": "response"
}

C# log

Environment information
VSCode version: 1.66.0
C# Extension: 1.24.3
Mono Information
        OmniSharp using built-in mono
Dotnet Information
 Version:   6.0.101
 Commit:    ef49f6213a
Runtime:
OS Name:     arch
OS Version:
OS Platform: Linux
RID:         arch-x64
Base Path:   /usr/share/dotnet/sdk/6.0.101/
Host (useful for support):
Version: 6.0.1
Commit:  3a25a7f1cc
.NET SDKs installed:
5.0.404 [/usr/share/dotnet/sdk]
6.0.101 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 5.0.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension
Author
Version

ansible
redhat
0.8.1

beautify
HookyQR
1.5.0

csharp
ms-dotnettools
1.24.3

git-graph
mhutchie
1.30.0

gitlab-workflow
GitLab
3.42.0

gitlens
eamodio
12.0.5

gitmoji-vscode
seatonjiang
1.1.2

hexeditor
ms-vscode
1.9.5

jupyter
ms-toolsai
2022.3.1000901801

jupyter-keymap
ms-toolsai
1.0.0

live-server
ms-vscode
0.2.12

material-icon-theme
PKief
4.15.0

material-product-icons
PKief
1.2.0

python
ms-python
2022.4.0

resxpress
PrateekMahendrakar
4.5.0

trailing-spaces
shardulm94
0.3.1

vscode-docker
ms-azuretools
1.21.0

vscode-eslint
dbaeumer
2.2.2

vscode-jest
Orta
4.2.1

vscode-npm-script
eg2
0.3.24

vscode-openapi
42Crunch
4.9.3

vscode-taskexplorer
spmeesseman
2.9.1

vscode-xml
redhat
0.20.0

vscode-yaml
redhat
1.6.0

vscord
LeonardSSH
4.5.0

These settings currently only enable inlay hints at the VS Code level, but not in OmniSharp server. You need to separately enable them in the server component. In the future they will be synchronized.
For now, the simplest way is to do one of the following:

create (or edit existing) omnisharp.json file located in %USERPROFILE%/.omnisharp/ (affects all projects globally)
create (or edit existing) omnisharp.json file located in the working directory which OmniSharp has been pointed at (affects current project only)

in this file, you can enable inlay hints by setting
{
    "inlayHintsOptions": {
        "enableForParameters": true,
        "forLiteralParameters": true,
        "forIndexerParameters": true,
        "forObjectCreationParameters": true,
        "forOtherParameters": true,
        "suppressForParametersThatDifferOnlyBySuffix": false,
        "suppressForParametersThatMatchMethodIntent": false,
        "suppressForParametersThatMatchArgumentName": false,
        "enableForTypes": true,
        "forImplicitVariableTypes": true,
        "forLambdaParameterTypes": true,
        "forImplicitObjectCreation": true
    }
  }
}

More on the server configuration options can be found here https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options

Thank you! After applying this settings everything works well.

Thanks for confirming

In the future they will be synchronized

May this issue should be stay opened to track that?