Chrysler ACC instant faults with latest master-ci build

Describe the bug
Can't enable ACC with Comma 3 device plugged in. Controls unresponsive on steering wheel until system ultimately faults. Works fine when comma device is unplugged.
Which car does this affect?
Chrysler Pacifica 2022
Provide a route where the issue occurs
4395faadf0a373f2|2022-06-19--15-41-19--0
openpilot version
0.8.15 Nightly (6/19/2022)
Additional info
No response

Thanks for reporting this! Looks like it was caused by 0f0b4cac893b41dd81288947158d3aa9cbbfc2fd, so I reverted it on master. @sshane why didn't any tests catch this?

The segment in test_processes is only available and engaged so flipping them has no effect. We should soon try to get more comprehensive routes, and test more things like doors, blinkers, gas, etc. For now I added a test in test_models


loss function  with mean or sum,which is better?

Hello, Brother! In your code categorical_crossentropy compute with mean,
https://github.com/qubvel/segmentation_models/blob/e9cac0d5bc2a7c0e1c6fa9050d988a6f9854313c/segmentation_models/base/functional.py#L251
but in keras code ,the return is
return - tf.reduce_sum(target * tf.log(output), axis)

https://github.com/keras-team/keras/blob/c10d24959b0ad615a21e671b180a1b2466d77a2b/keras/backend/tensorflow_backend.py#L3564
so which is better?

There are no difference, keras average them anyway

@qubvel This is a great library and we are using it extensively these days. Thanks. I also stumbled upon this exact same question asked here. Why do you think there are no difference between your implementation and keras? If I understand correctly in keras they do not count the number of classes in their mean calculation but in our case we do it. Though it should not affect the training, still what we calculate here is a scaled version of cross entrophy and the scaling depends on the number of classes. isn't it?


Update packages for release 2.6 and onwards

With release 2.6 having reached most users, I think it makes sense to rebuild our packages to use the 2.x toolchain. This will make Toltec work with updates 2.6 and onwards (fixes #322), at the price of breaking compatibility with system updates 2.5 and earlier.
Testing plan: Having update 2.7.1 installed, I went through basic checks for each package on rM2 to make sure that each app at least starts up and seems to react to user input.

The only issue I found for now is that @Eeems’s Oxide has some missing icons (top-left menu button and top-right power button). Other than that, the launcher works well.

The only issue I found for now is that @Eeems’s Oxide has some missing icons (top-left menu button and top-right power button). Other than that, the launcher works well.

I'm including a font to drive those. Are the files not being pulled in?

Added a patch for Oxide (taken from Eeems/oxide#195) that fixes the missing icons bug.

I can confirm the following applications work on 2.8 on rM1:

All parts of Oxide (except decay, not because it doesn't work, but because I don't use it)
ZShelf
Wikipedia
Yaft
nao
Plato

There have been several users who have used this branch on 2.6+, what is currently blocking this from merging?

To me this PR is clear for merging. @raisjn and you did mention the need for adding a check that the user is actually running version ⩾ 2.6 before upgrading. This can also be done in a separate PR, since this is going to testing and not to stable.


Organising flowcell data on Miarka

Codecov Report
Attention: Patch coverage is 0% with 59 lines in your changes missing coverage. Please review.

Please upload report for BASE (master@43b763b). Learn more about missing BASE report.

Files with missing lines
Patch %
Lines

taca/organise/flowcells.py
0.00%
32 Missing :warning:

taca/organise/organise.py
0.00%
18 Missing :warning:

taca/organise/cli.py
0.00%
9 Missing :warning:

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #444   +/-   ##
=========================================
  Coverage          ?   28.42%
=========================================
  Files             ?       34
  Lines             ?     5017
  Branches          ?        0
=========================================
  Hits              ?     1426
  Misses            ?     3591
  Partials          ?        0

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

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests


Tutorial/Social: Karma, accountability, and personal responsibility

From @yossigil on October 6, 2016 16:50
Buzzwords

Karma: This is how well you cooperate with others and with team work. (May be tied with your grade, if you are a student)
Accountability: There is an individual in charge of every piece of code
Personal responsibility: You identify your work as yours

Rules

You do not write code unless you deal with an open issue (open one if necessary)
All classes you write bear your name
You commit your work, and your work only
You do not override the work of others
You respond to TODOs assigned to you ( #394)
You check your GitHub notifications frequetly, i..e, this
You play nicely, cooppertively and politely

It is still OK to remove code commented out by others
It is still OK to revert commits in which there are classes with no @Author on them

Copied from original issue: SpartanRefactoring/Spartanizer#395

This issue was moved to TechnionYP5777/Info-Evaluation#2

This issue was moved to TechnionYP5777/SmartCity-Accessibility-A#2

This issue was moved to TechnionYP5777/SmartCity-Accessibility-B#2


Lockpick Roll Formula for Symbaroum for Lock & Key

Hi, can you help me with the roll formula for lockpicking and breaking locks for the Symbaroum system?  It's usually a cunning check for lockpicking and the strong ability to break the lock.  Thanks!

If I understand the system correctly these should be the formulas:
Pick lock<EMAIL_ADDRESS>Break<EMAIL_ADDRESS>The DC of a pickable/breakable door would then have to be set to 1

Thanks for your quick reply.  That works!

Happy to hear that


externalresources(engine): Miscellaneous changes required for implementing resource GC.

What problem does this PR solve?

Issue Number: ref #5513
What is changed and how it works?

Added required methods in pkg/orm (data accessing layer).
Adjusted interface definitions in pkg/externalresource/manager.
other related changes.

Check List
Tests

Unit test

Release note
None

/run-check-issue-triage-complete

Codecov Report

Merging #5514 (84d5cd2) into master (e62fbea) will decrease coverage by 0.1943%.
The diff coverage is n/a.

Flag
Coverage Δ

cdc
61.4386% <ø> (-0.0479%)
:arrow_down:

dm
51.9500% <ø> (-0.0164%)
:arrow_down:

engine
?

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #5514        +/-   ##
================================================
- Coverage   56.3160%   56.1216%   -0.1944%
================================================
  Files           675        530       -145
  Lines         78594      69916      -8678
================================================
- Hits          44261      39238      -5023
+ Misses        30143      26909      -3234
+ Partials       4190       3769       -421

/merge


add a list command

I can never remember the names of the profiles I have configured, so this command will list them for you.
Caveat: It assumes you only care about profiles that are assuming from another role; it only lists profiles that have a source_profile.

@dfuentes Is this a feature ya'll would like?

@logikal 	Yeah, I think it could be useful. Let me take a look.

Thanks, @nickatsegment! I've fixed up the feedback and updated from master, squashed it all up, and think it's ready to go now. 🎅


get colored images from my pretrained caffemodel

hello,thanks for your work.  I want to use the pre-trained caffemodel that training from my own dataset to output the colored images.First I find colorize.py( Test-Time Python Script) and replace default model(colorization_release_v2.caffemodel) with my caffemodel(e.g. colornet_iter_51000.caffemodel) , but I found my caffemodel's network structure is different from the default model's, so the output image seems to be wrong. what should I do?
If you have free time,please answer my question，thanks！

Hi, did you use the correct "prototxt" file? This file contains the architecture details

yes, I also replaced the pre-trained "prototxt" file with the training "prototxt" file, but another problem appeared，training pipeline can't output the colored images

I know. I had the same problem with demo_release.py (Pytorch version), but when I used this command:
python ./colorize.py -img_in ./demo/imgs/ILSVRC2012_val_00041580.JPEG -img_out ./out.png
and replaced the .caffemodel and .prototxt file inside the colorize.py, my problem solved.

I replaced the corresponding part in the  colorize.py with ./models/colorization_train_val_v2.prototxt and colornet_iter_135000.caffemodel(caffemodel saved in training process). but the output image is from net.blobs['class8_ab'].data in colorize.py. this 'class8_ab' blobs is not in the structure of caffemodel. Will the output result be correct?  Can you tell me which file you replaced？

I replaced the corresponding part in the colorize.py with ./models/colorization_train_val_v2.prototxt and colornet_iter_135000.caffemodel(caffemodel saved in training process). but the output image is from net.blobs['class8_ab'].data in colorize.py. this 'class8_ab' blobs is not in the structure of training caffemodel. Will the output result be correct? Can you tell me which file you replaced？

I use  "./models/colorization_deploy_v2.prototxt" for .prototxt file. I think this file contains the lastest architecture updates.
colorization_train_val_v2.prototxt is for training and validating not for testing. For testing the model on a single image you should use ./models/colorization_deploy_v2.prototxt file

so you use  "./models/colorization_deploy_v2.prototxt" and the model you train(not default='./models/colorization_release_v2.caffemodel')  and you get the right result？i just hope that the colored images I get are trained on the model with fine-tuned parameters based on my own dataset.

Yes, exactly. I also trained the model on another dataset. No worry!

I'm sorry to bother you again，I don't know if there was a problem with the pre-processing data in training process（I processed my images dataset into LMDB files，BGR images）,I ran the colorize.py as you said, the output image looks like a BGR picture, not a RGB image!  Can you tell me how you preprocessed your data?
This is the result i ran colorize.py：

I'm sorry to bother you again，I don't know if there was a problem with the pre-processing data in training process（I processed my images dataset into LMDB files，BGR images）,I ran the colorize.py as you did, the output image looks like a BGR picture, not a RGB image!  Can you tell me how you preprocessed your data?
This is the result i ran colorize.py：

No worry. It is interesting. No, I did not face this problem.
Here is the script I used to prepare the LMDB dataset.
img_list = sorted(glob.glob(read_path))
dataset = []
data_size = 0
for i, v in enumerate(img_list):
    img = cv2.imread(v, cv2.IMREAD_UNCHANGED)
    dataset.append(img)
    data_size += img.nbytes
    print("read {}".format(v))
print(len(img_list))
env = lmdb.open(save_path, map_size=data_size * 10)

with env.begin(write=True) as txn:
    # txn is a Transaction object
    for i, v in enumerate(img_list):
        base_name = os.path.splitext(os.path.basename(v))[0]
        key = base_name.encode('ascii')
        data = dataset[i].tobytes()
        if dataset[i].ndim == 2:
            H, W = dataset[i].shape
            C = 1
        else:
            H, W, C = dataset[i].shape
        datum = caffe.proto.caffe_pb2.Datum()
        datum.channels = C
        datum.height = H
        datum.width = W
        datum.data = data
        txn.put(key, datum.SerializeToString())

thanks，I read your script. it seems that you  did not preprocess the training data into BGR images，so this can directly get the correct result.

Your welcome. I used the BGR format. When you read an image using OpenCV, its channel order is BGR, not RGB; that means my LMDB contains images in BGR format.

oh! yes, thanks a lot！

Good luck!


Users should not be able to delete service if the database exists

Support for this was added as part of #1960. @parthp2107


[Feature suggestion] Synchronous version of the API?

Hello, and thanks for this awesome project!
Are there any plans for creating synchronous version of the API? As far as I understand, all the API offered, such as NewPageAsync(), WaitForExpressionAsync(), JsonValueAsync() etc. are asynchronous, which introduce some trouble working with them in synchronous context (e. g. interactive).

@kblok sorry, I should've clarified. By interactive I mean contexts like Jupyter/VSC notebooks or repl. We use this awesome engine for rendering pictures for notebooks, where we definitely don't need async.

Hey @WhiteBlackGoose no plans to support that.

I see. Alright... thanks for the response


Makefile improvements

Automatic GOPATH;
Separate test from coverage to avoid detection of false positive race conditions;
Minor Makefile improvements.

Coverage remained the same at 100.0% when pulling c1e8a7c7a0e106c311032ed4a6fdd365d6193da8 on makefile into b9eeb5f3b660b9c063fa31120609a6a211229cae on master.

Coverage remained the same at 100.0% when pulling 25d5dfa4e3d1479ce618727000b0c3965045b770 on makefile into b9eeb5f3b660b9c063fa31120609a6a211229cae on master.

LGTM.


Game keeps crashing while playing Blammed

Alright, so I compiled Psych Engine for Mac but when I get like halfway through Blammed it randomly crashes. Idk what to do lol

Mac is not supported as i don't have one/have no insterest in buying one for myself.
I'm sorry but i can't help with that.


write the processors talked about in issue #93

Thanks! I pulled this into the new_processors branch in 6dd0d2272f1f00c47809eb15cc9208c2d1266e82. Two questions though:

Is there a reason for the Resize class? I think we should probably leave it out until we actually have an implementation.
I think the arguments for BasicCrop should probably be "x", "y", "width", and "height". The TRBL naming implies insets, I think (e.g. bottom=50 implies "50px from the bottom" instead of "50px from the top", which is what it's really doing, right?)

Resize should be a basic resize without any magic (aspect ration saving or nothing like that) just as BasicCrop. We could name it BasicResize for consistency.

It should be:
class BasicResize(object):
"""Resizes an image to the specified width and height.

"""
def __init__(self, width, height):
    self.width = width
    self.height = height

def process(self, img):
    img = img.resize((self.width, self.height), Image.ANTIALIAS))
    return img

I implemented it as closely to the way PIL does it as possible - thats why I named it Basic. It's the purest implementation. Others do magic. If needed we could change but if documented correctly then I think it is the purest most simple and raw implementation possible.

Taken from PIL source:
##
# Returns a rectangular region from this image. The box is a
# 4-tuple defining the left, upper, right, and lower pixel
# coordinate.
#
# @param The crop rectangle, as a (left, upper, right, lower)-tuple.
# @return An Image object.

def crop(self, box=None):
    "Crop region from image"

    self.load()
    if box is None:
        return self.copy()

    # lazy operation
    return _ImageCrop(self, box)

But you are right - it's still confusing. If not mirroring PIL then your proposal is better.

"x", "y", "width", and "height"

Alright, @madisvain, I think we're good! Check out #95 and let me know what you think.


OpsWorks-aware Janitor monkey

Optionally consider membership in an OpsWorks stack when evaluating the orphaned instance rule for termination.  When this option is enabled, membership in an OpsWorks stack prevents deletion just like ASG membership.
ie.

NetflixOSS » SimianArmy » SimianArmy-pull-requests #1 SUCCESS
This pull request looks good

SimianArmy-pull-requests #173 SUCCESS
This pull request looks good

Thanks for the PR.  I was wondering if you would be willing to generalize it a little bit so that there isn't special case code.  I was thinking you could have  a property with a list of tags to check existence of.  Or even more ambitious, tag/value pairs that you check.  That way anyone could set tags for things they want janitor monkey to ignore and your OpsWorks case would also be solved.  What do you think?

I thought about making the ASG and OpsWorks checks work that way, but some comments in the InstanceCrawlerJanitor gave me pause.  It doesn't just use the presence of the tag aws:autoscaling:groupName to determine if an instance has an ASG, it falls back to the "AutoScaling service" mapping of idToASGInstance (see InstanceJanitorCrawler.java):
// At most times the aws:autoscaling:groupName tag has the ASG name, but there are cases
// that the instance is not correctly tagged and we can find the ASG name from AutoScaling
// service.

If this is an older concern and we can support everything by just tag checks, I'm game to refactor a bit.

I like special casing OpsWorks because it is a special case :+1:


K8SPG-518: Fix WAL archiving on Openshift

CHANGE DESCRIPTION
Problem:
/pgwal/ is read-only on Openshift and that causes archive command to fail.
Solution:
Use /pgdata/ to store latest_commit_timestamp.txt
CHECKLIST
Jira

[x] Is the Jira ticket created and referenced properly?
[x] Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
[x] Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

[x] Is an E2E test/test case added for the new feature/change?
[x] Are unit tests added where appropriate?

Config/Logging/Testability

[x] Are all needed new/changed options added to default YAML files?
[x] Did we add proper logging messages for operator actions?
[x] Did we ensure compatibility with the previous version or cluster upgrade process?
[x] Does the change support oldest and newest supported PG version?
[x] Does the change support oldest and newest supported Kubernetes version?

Test name
Status

custom-extensions
passed

demand-backup
passed

init-deploy
passed

major-upgrade
passed

monitoring
passed

one-pod
passed

operator-self-healing
passed

pitr
passed

scaling
passed

scheduled-backup
passed

self-healing
passed

start-from-backup
passed

tablespaces
passed

telemetry-transfer
passed

upgrade-consistency
passed

upgrade-minor
passed

users
passed

We run 17 out of 17

commit: https://github.com/percona/percona-postgresql-operator/pull/823/commits/71dfb2611ebcc243799a6c1c1d420ecad8987d3e
image: perconalab/percona-postgresql-operator:PR-823-71dfb2611


Remove debugTrace from tracer configuration.

With the introduction of the io.l5d.tracelog telemeter, there is no longer
any need to support the debugTrace flag on tracers.  This flag was a bit of a
wart, behaving differently from all other configuration options by configuring
a global parameter.

:star: 🍔


[TR#147] Sensible file input styles

Task
TR #147
Why?
@zoopmaster noticed that inputs with type set to file were not being styled correctly. This remedies that!
What Changed

[X] Add sensible style for input of type file
[X] Add option to docs playground

Sanity Check

Have you updated any usage of changed tokens?
[X] Have you updated the docs with any component changes?
Have you updated the dependency graph with any component changes?

[X] Have you tried building the css?
[X] Have you tried building storybook?
Do you need to update the package version?

Screenshots
Before:

After:

 Form control of type file


Update HEADS logo with better-looking one

I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
This repository is managed using an auto merge action. Please ensure your PR has no deleted lines, and it will be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

Auto merge requirements
Your pull request will be automatically merged if the following conditions are met:

Your pull request only adds new tokens to the list. Any modification to existing
tokens will require manual review to prevent unwanted modifications.

Your pull request does not touch unrelated code. In particular, reformatting changes to unrelated
code will cause the auto merge to reject your PR.

Any asset files added correspond to the token address you are adding. Asset files
must be PNG, JPG or SVG files.

Your change is valid JSON and conforms to the schema. If your change failed validation,
read the error message carefully and update your PR accordingly.

No other tokens shares the same name, symbol or address.

For example, this change would be rejected due to unrelated changes:

The bot runs every 60 minutes and bulk-merges all open pull requests to prevent conflicts.
This means that you need to wait up to 60 minutes for your pull request to be merged or reprocessed.

@bartosz-lipinski @rmshea @oJshua would you mind pointing me where to read about how's the process to get token modifications like this PR accepted? I understand it can't be automerged, but in this case (and probably others) I'm updating a token I recently added myself. Thanks!

https://github.com/solana-labs/token-list/commit/c8a201281350b77bd93a12750232786efd282f06


🦙

😭 I wanted to approve of alphaca

Omg brutal @wwlorey. Nathan hasn't gotten to approve of alphaca like ever
It's like that switch game "Quick Draw"

Me rn


some travis builds fail after success due to c-dash

Some travis builds are failing with a cdash error, @bremond I thought at some point that we changed this to not be critical.  I think it would be great to decouple Travis from c-dash since we can see its progress independently anyways via build history.
https://travis-ci.org/siconos/siconos/jobs/445698225
100% tests passed, 0 tests failed out of 1175
Total Test time (real) =  64.34 sec
Submit files (using https)
   Using HTTP submit method
   Drop site:https://cdash-tripop.inrialpes.fr/submit.php?project=Siconos
   Error when uploading file: /docker-workdir/Testing/20181024-1439/Build.xml
   Error message was: The requested URL returned error: 500 Internal Server Error
   Problems when submitting via HTTP
CMake Warning at /home/travis/build/siconos/siconos/CI/machinery/CTestDriver.cmake:172 (message):
   *** submission failure ***
make[3]: *** [CMakeFiles/ubuntu-16-04-gcc-atlas-lapack-ctest] Error 255
make[2]: *** [CMakeFiles/ubuntu-16-04-gcc-atlas-lapack-ctest.dir/all] Error 2
make[1]: *** [CMakeFiles/docker-ctest.dir/rule] Error 2
make: *** [docker-ctest] Error 2
Command '['make', 'docker-ctest']' returned non-zero exit status 2.
return code 1

I am wondering if it is possible to return an exit code before submitting to cdash .

in ec3b57c64, I splitted the build phase and the submit phase in the ctest driver. The submit phase should only throw a warning if it fails. Let's see what it gives in the next commits. If we run into trouble again, I agree with the solution of @radarsat1 to definitively remove the submit phase from travis builds.

definitively remove the submit phase from travis builds.

not necessarily remove, just make it non-fatal. (ignore error code)

With 0ee534983, the builds are uploaded again. The second ctest_start was referring to another configure/build/test/ tag. This tag is made with the current time, I did not see it on a simple test with an HelloWorld compilation because it was the same, but for siconos they are different...
So we have now a submit phase with an ignored error code. For example:
https://travis-ci.org/siconos/siconos/jobs/446581723
Is is ok for you ?
The reasons Travis is failing now are 2 tests errors on opensuse 42.3 with sequential mumps:
The following tests FAILED:
427 - fc3d__NSN_AC_Tol_1e-5_Max_1000_inTol_0_inMax_0_IPARAM_1_Capsules-i100-1090 (Failed)
798 - fc3d__NSN_AC_Tol_1e-3_Max_1000_inTol_0_inMax_0_BoxesStack1-i100000-32.hdf5 (Failed)
and one test on ubuntu 16.04 with parallel mumps:
The following tests FAILED:
424 - fc3d__NSN_AC_Tol_1e-5_Max_1000_inTol_0_inMax_0_IPARAM_1_Capsules-i100-1090 (Failed)
CMake Error at /home/travis/build/siconos/siconos/CI/machinery/CTestDriver.cmake:174 (message):
*** test failure ***

Le 25 oct. 2018 à 08:46, Vincent Acary<EMAIL_ADDRESS>a écrit :
I am wondering if it is possible to return an exit code before submitting to cdash .

yes, it’s possible to test a return status of the different stages in ctest,
e.g. :
ctest_configure(CAPTURE_CMAKE_ERROR CONFIGURE_STATUS)
and then check this before ctest_submit
Concerning  the error
Submit files (using https)
Using HTTP submit method
Drop site:https://cdash-tripop.inrialpes.fr/submit.php?project=Siconos https://cdash-tripop.inrialpes.fr/submit.php?project=Siconos
Error when uploading file: /docker-workdir/Testing/20181024-1439/Build.xml
Error message was: The requested URL returned error: 500 Internal Server Error
Problems when submitting via HTTP
CMake Warning at /home/travis/build/siconos/siconos/CI/machinery/CTestDriver.cmake:172 (message):
*** submission failure ***
I have the same kind of problem when using gitlab-ci, for different jobs and in a random way
something goes wrong on cdash side, maybe when they are several submissions at the same time
for the same project?
Or because of files too large?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/siconos/siconos/issues/259#issuecomment-432934116, or mute the thread https://github.com/notifications/unsubscribe-auth/AHbsU_n8q1zKyy6B_VHVlkLVKNQ7GsVNks5uoV44gaJpZM4X4pKb.

ctest_configure(CAPTURE_CMAKE_ERROR CONFIGURE_STATUS)

I did not try this at the configure level, but only at the test level:
in CI/machinery/CTestDriver.cmake:
ctest_test(PARALLEL_LEVEL ${NP} RETURN_VALUE TEST_RETURN_VAL)
with then
if(NOT TEST_RETURN_VAL EQUAL 0)
message(FATAL_ERROR " *** test failure *** ")
endif()
endif()
and at the submit level:
ctest_submit(FILES ${SUBMIT_FILES} RETURN_VALUE SUBMIT_RETURN_VAL)
with
if(NOT SUBMIT_RETURN_VAL EQUAL 0)
message(WARNING " *** submission failure *** ")
endif()
the problem is that it never worked for the submit phases (a submission
failure always leads to a ctest exit error, even with the WARNING flag
in the message call, whereas a test failure does not if you replace the
FATAL_ERROR by WARNING...)
So, in 0ee5349, I skipped this ctest mistery, and it is working now with
2 stages for ctest.
In more details, from the tasks.py we have now:
targets={'.': ['docker-build', 'docker-ctest', 'docker-submit']})
docker-submit just executes ctest with SUBMIT=ON, (only the submit part
in CTestDriver) and the error exit code can be ignored at the ctest call
level.
This also provides the possibility to have ci jobs without cdash
submission (this maybe interesting to preserve our CDash server)
The remaining errors on travis are no longer submission errors, they are
only 2 tests failing when mumps sequential is on, and one failure with mumps
parrallel
Is it ok so we can close the issue ?

It seems that everybody is ok.


Prepare release 1.3.2

See diff. It is quite large but there are no real code changes.

Thank you for the review


Py3 messagebus

Current coverage is 67.63% (diff: 71.42%)

Merging #196 into master will increase coverage by 0.03%

@@             master       #196   diff @@
==========================================
  Files            70         70
  Lines          4478       4480     +2
  Methods           0          0
  Messages          0          0
  Branches        531        581    +50
==========================================
+ Hits           3027       3030     +3
  Misses         1316       1316
+ Partials        135        134     -1

Powered by Codecov. Last update 27ab13d...fac257d

Awesome!!! All checks are passed !!!


Update for .s2i from .sti

when using .sti/ folder, a deprecation warning is thrown during assembly.
if you put your files in .s2i then no warning.
Docs should be updated accordingly, 2.7, 3.3, and 3.4
I can make a PR if preferred

Hi @jfmatth! I found a couple of outdated references in the latest official docs and one occurrence in the project's README in this repo.
Did you spot any usage of the deprecated name anywhere else? Thanks!

@rhcarvalho you didn't fix the 3.3 and 3.4 readmes

(and yes i merged it w/o checking if the other files needed updating, so my bad :) )

@bparees following up in https://github.com/openshift/sti-python/pull/111, because I was working on something else just a while ago, I was exceptionally in the context of a single image (the 2.7 subdir)...

thanks for catching it after the fact ;)


BITOP-4128: Docker compose plugin doesn't have '-v' option

Description of PR
https://issues.apache.org/jira/browse/BIGTOP-4128
How was this patch tested?
$./docker-hadoop.sh -dcp -c 3
Environment check...
Check docker:Environment check...
Check docker:
Docker version 26.1.3, build b72abbb
Check docker-compose:
Docker Compose version v2.27.0
Check ruby:
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux-gnu]
...

@iwasakims
Thanks for the comment.
I fixed tabs and align indent.


Plus signs in file and folder names

The behavior of plus signs (+) in file and folder names is unpredictable. We read in the documentation (https://github.com/OneDrive/onedrive-api-docs/blob/master/misc/addressing.md):

according to 'OneDrive reserved characters', the plus sign is not reserved
'URI path characters' lists the plus sign under the characters that don't have to be encoded

This happens when we try to create a file 'One+Two.txt':

request ...root:/Documents/One+Two.txt:/content creates a file named 'One Two.txt'
...root:/Documents/One%2BTwo.txt:/content creates the same 'One Two.txt'
...root:/Documents/One%252BTwo.txt:/content creates 'One%2BTwo.txt'

Any attempt to access a folder with trailing + results in an 'invalidRequest' error with message 'Path (...) contains invalid trailing character.'

Comparing with the OneDrive API: On both, the OneDrive API and the Graph API it is possible to create a folder with a trailing '+'. Using the OneDrive API a file file can be added to this folder if the plus in the path is percent encoded (...root:/Documents/Folder%2B/Testfile.txt:/content). The Graph API answers with the error message mentioned above. On the OneDrive API too it is impossible to create a file with a '+' in the name.

My apologies for the delay, I didn't spot this issue getting assigned to me :).
I want to make sure I have this correct, as unfortunately there are numerous endpoints that could be factoring in to URL issues. Here's what I see:
OneDrive Business
PUT ...root:/Documents/One+Two.txt:/content creates a file named One+Two.txt
PUT ...root:/Documents/One%2BTwo.txt:/content creates a file named One+Two.txt
OneDrive Consumer
PUT ...root:/Documents/One+Two.txt:/content creates a file named One Two.txt
^ We actually have a fix for this rolling out soon
PUT ...root:/Documents/One%2BTwo.txt:/content creates a file named One+Two.txt
Graph targeting OneDrive Business
PUT ...root:/Documents/One+Two.txt:/content creates a file named One+Two.txt
PUT ...root:/Documents/One%2BTwo.txt:/content creates a file named One+Two.txt
Graph targeting OneDrive Consumer
PUT ...root:/Documents/One+Two.txt:/content creates a file named One Two.txt
PUT ...root:/Documents/One%2BTwo.txt:/content creates a file named One Two.txt
^ Both of these are the result of the OneDrive Consumer issue that I mentioned we fixed above - graph appears to translate the %2B to + when it sends the request to us which is why it behaves differently
I'm going to take note to update this issue when that fix gets resolved, and then we can take another look and see if there's any other strange behavior.

This fix has rolled out, hasn't it? From my point of view everything works as expected now.

Yup, it looks like the deployment finished this morning :)

Hi
I'm using OneDrive connector in a Logic App and found the same issue, as of Oct. 2020. The + sign in a filename is replaced by a single space when trying to get the content. However, the filenames are well picked up when listing the folder content. See pictures attached.
logic app overview:

list files actions output (correct):

get content action (incorrect path):

Thank you
Fernando


How to update Tabbar ?

I add a red dot on Tabbar to indicate has new message, blew is the code,

The red dot default is hide, I don't know how to update Tabbar make it display , can any body help me?

I see you have showDot={false} and one without showDot - in both cases, this.props.showDot will be false-y.

@cridenour Yes, I only want the Message scene have dot.

Then you'll need to change showDot to {true} for one of them

Already tried Actions.refresh({showDot: true}) 、Actions.Tabbar({showDot: true}) 、Actions.Message({showDot: true}) ，nothing happen...

The props showDot is undefined in the TabIcon, no? It is defined in the component 'MessageConintainer'...not?
Can you use console.log to display the status of this.props.showDot?

showDot will pass to TabIcon.
The problem is I cann't find a way to reload TabBar after it rendered.

You are looking for this https://facebook.github.io/react/docs/component-specs.html

@sarovin Thanks.
Need find a way in these Router,Scene,Actions pattern...

I don't think you should be using this library to pass that information down. You should still use a custom TabIcon but you should be using a Flux implementation like Redux or Alt to actually store the information of whether to show the dot - and have the TabIcon have a property of whether to connect to the store or not.
So I would use showDot={true} and in your componentDidMount of TabIcon, if (this.props.showDot) DotStore.listen(this._handleDot) ... etc.

Thanks @cridenour
Finally, I solve this problem as you say.
Declare a new TabIcon component, map dot state as its props.


New Twitter Logo

Hey folks, the Twitter logo changed from the Bird to an X.
Could you please change it?

Enter: https://react-xeet.vercel.app/

Enter: https://react-xeet.vercel.app/

It's also a parody and should not be used too seriously.

i would really appreciate to get this change in this repo here.


Assignability type annotations

Suggestion

🔍 Search Terms

type annotation, match types, assignability, type inferrence
✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
Add a way to declare a variable and have its type be inferred from its initial value but check that it is assignable to a given type annotation.
I don't have any great ideas for what the syntax of this would be but here are a few suggestions:

Using a new matches type operator that is only allowed at the beginning of a type annotation:
const x: matches { [key: string]: string } = { ... };

Using a new operator to replace the : type annotation operator. I don't have a great suggestion for what that operator should be, so I'm using % as a placeholder here:
const x% { [key: string]: string } = { ... };

📃 Motivating Example
Suppose I'm declaring an object with arbitrary keys whose values are supposed to be of the form ${string}.v${number}. For example:
const PageSections = {
    HEADER: "header.v1",
    BODY: "body.v1",
};

I want to be able to interact with the members of this easily by referencing PageSections.HEADER. However, there's nothing enforcing the contract on the values currently. If I tried to do this I would have to write this declaration as:
const PageSections: { [key: string]: `${string}.v${number}` } = {
    HEADER: "header.v1",
    BODY: "body.v1",
};

This works to check that I wrote each value correctly (e.g. if I wrote HEADER: "header-v1", I would get a compile error as I would hope). However, this erases the information about the keys and lets me index into this arbitrarily, e.g. PageSections.FOOTER is not defined but compiles just fine.
There are a few workarounds that would work here but they're not ideal.
Workaround 1
Add a separate keys type union or enum:
type PageSectionKeys = "HEADER" | "BODY";

const PageSections: Record<PageSectionKeys, `${string}.v${number}`> = {
    HEADER: "header.v1",
    BODY: "body.v1",
} as const;

This works but feels unnecessarily duplicative and if we wanted to maintain type information about the values (if we cast via as const) then that is still lost:
type PageSectionValues = typeof PageSections[PageSectionKeys];
// Resolves to `${string}.v${number}` instead of "header.v1" | "body.v1"

Workaround 2
Add a separate variable which checks for the assignability:
const PageSections = {
    HEADER: "header.v1",
    BODY: "body.v1",
} as const;

const pageSectionsTest: { [key: string]: `${string}.v${number}` }  = PageSections;

This comes with a few downsides:

I have to create a separate variable which goes unused and TS will complain about if I'm using noUnusedLocals. I could export this but that's a hacky workaround and exposes and unnecessary variable in the API.
The error that I get from this isn't where the error actually occurred. In order to fix this issue, I need to decipher an error message and trace it back to a particular error

💻 Use Cases
If this feature were to be adopted, then we could write the example above as:
const PageSections: matches { [key: string]: `${string}.v${number}` } = {
    HEADER: "header.v1",
    BODY: "body.v1",
};

In this case if I make a mistake and type "header.v1" instead as "header-v1" I get an error at the place I expect. But I also will have the keys be strongly typed so typing PageSections.HEADR will read as an error. Additionally if I add as const to the end of this I can strongly type the values as:
type PageSections = typeof PageSections[keyof typeof PageSections];

You could write the example as:
Playground
const PageSections = {
    HEADER: "header.v1",
    BODY: "body.v1",
} satisfies { [key: string]: `${string}.v${number}` }

if https://github.com/microsoft/TypeScript/pull/46827 is merged.

Treating as duplicate of #47920


Commands: only /start available to pass argument?

Could I pass arguments to different command?
If it is not possible, how can I authenticate user and authorize him at 3rd party service via oAuth2?
For example, check out: Youtube bot or Github.
I also noticed that they redirect to https://integrations.telegram.me, but I still can't understand how exactly they authenticate user as far as oAuth2 doesn't contain any info about user who grants permission
I need to authorize user at 3rd party services. For example, Google calendar.
So, I decided to create simple URI that redirects to Service Sign In and redirect URL to my server with token\authCode.
As far as oauth does not authenticate user, I still need somehow identify who exactly granted access to his resources.
So my next logical step was to hash received token and send it back to user via https://telegram.me/BOT?code=xxx
I was convinced that if there is commandHandler for /code and /code is in the bot commands list I would be able to open conversation with my bot and sent this hashed code via webhook back to my server in order to detect who exactly it was at access grant step.
I was shocked when I found that my plan was ruined at the last step: as far as I can see there is only /start command could be triggerred.
My question is: can you confirm that only /start command could query parameters via URL? if so, could you give me some advise about the right way of authorizing and authenticationg user?

Well, I don't fully understand your situation. What I can say is:

There is nothing that stops the user from typing /code param1 param2, so there is a way to pass parameters, even though it requires the user actively typing. Downside is you can't just tap on the command.

Have you looked into deep linking?

@nickoala
Yes, I've looked into provided examples and here is what I found:
case described in your example is about situation when you want want to identify user in Telegram, so it means you already have user base with credentials.
My case is about user identification from Telegram
which means that I do not have user in my data base yet, but I really want to have him.
So, I inspired by example and explanation about unique hash for user created sequence of actions that allows me to get information about user from 3rd party services via oAuth authorisation.
The biggest problem in this scheme is to identify who exactly granted permission to access his data.
There were 2 main approaches to do that:
first one was about creating dynamic authorization with unique redirection URL fragment, but it in the end I found that I'd missed explanation that redirect URI has to be unique(no fragments, no relative paths)
the second one was about to make redirection to my bot with custom command which would query hashed authorization result. After hashed authorization result passes through webhook back to my server I could identify user with real authorization result.
So, as you can see it is not possible to implement oauth authorization like it done with https://telegram.me/youtube
It seems that the only way to use oauth with telegram is /start command with further parameter parsing, but from the end-user perspective it is quite weird to press "start" button in the middle of the conversation

Cool. I am happy you found a solution to your problem!

http://stackoverflow.com/questions/37264827/telegram-bot-oauth-authorization/39563083#39563083


[opentelemetry-demo] Add test workflow and scenario for demo

This PR adds a new test workflow and default test scenario for the opentelemetry-demo chart.
Closes #287
@dmitryax I agree that it is annoying to have to add a new workflow for a new chart after https://github.com/open-telemetry/opentelemetry-helm-charts/pull/181 😆

I agree that it is annoying to have to add a new workflow for a new chart after https://github.com/open-telemetry/opentelemetry-helm-charts/pull/181 😆

I don't think we'll have any other charts any time soon :)


[Bug]: listening port chosen by kernel is printed to the console instead of being logged

zot version
v2.0.0-rc3
Describe the bug
The port selected automatically by the kernel in issue https://github.com/project-zot/zot/issues/717 is printed to the console instead of the logs. See https://github.com/project-zot/zot/pull/1260.
To reproduce
See implementation of https://github.com/project-zot/zot/issues/717 in https://github.com/project-zot/zot/pull/770.
Expected behavior
Instead of printing to the console, this information should be shown in the zot logs.
Preferably as part of the config json shown when zot starts. If that is not possible, it should be shown in a separate log message.
Screenshots
No response
Additional context
No response

It’s also printed to the console if you configured your logger properly.

Fixed in https://github.com/project-zot/zot/pull/1339


[3.x] Fix zero scale in particle shader

Fixes the lower bounding of scale when given zero input.
The previous bug was due to sign returning 0 with 0.0 input, rather than 1.
Fixes #80863
Notes

Regression introduced in #53852
There are also proposals to introduce special abs_sign function to deal with this (https://github.com/godotengine/godot-proposals/issues/6854) but I've just fixed in place for now
There might be some slightly more efficient way of doing this to avoid the branch

Thanks!


machinetype to machine-type

One simple error that will cause a interrupt in deployment process.

Coverage remained the same at 50.491% when pulling 6c70d48ef40ac7bfde151393e99d161c75006094 on lifubang:master into d5132e0e5de651227ca244389082d157bd9600f6 on Microsoft:master.


Changed to explicit imports for cocoapy

import * can be problematic, especially when we want to update this library.
The new version (PyCocoa) has classes like Screen, which conflict with pyglet
classes. More explicit imports can also highlight what's missing in a newer
version, without having to run the affected code (Import will fail).

@benmoran56 Thanks for the review. I actually thought that would re-evaluate the module, but apparently not:
olehermanse@OHMBP ~ $ cat > module.py
def a():
  pass

def b():
  pass

print("Module evaluated")
olehermanse@OHMBP ~ $ cat > use.py
import sys
sys.path.insert(0, ".")

from module import a
from module import b
olehermanse@OHMBP ~ $ python3 use.py
Module evaluated
olehermanse@OHMBP ~ $ python use.py
Module evaluated
olehermanse@OHMBP ~ $ python3
Python 3.7.4 (default, Jul  9 2019, 18:13:23)
[Clang 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.insert(0, ".")
>>> import module
Module evaluated
>>> import module
>>>

I'll try that later today.

@benmoran56 Split all the imports into multiple statements. Should be ready now.

Thanks, and sorry to nitpick!


OSGI bundle error

I occasionally get the following error when trying to use cfml-spreadsheet.  I don't know what causes it, but it requires a service restart to clear.

Did you upload the right screenshot? Not seeing any OSGi bundle error there or anything to do with the library??

If you are getting OSGi errors with the library, particularly after upgrading, try calling this method:
spreadsheet.flushOsgiBundle()

Bah - no, this is the correct one.  I wonder if that could go in a try/catch in the library itself?

Possibly. Let me give it some thought.

OK, that's done. I'm not sure why it happens as when a new bundle version is requested it should just be loaded alongside the previous one. But I have seen that error myself when upgrading, hence the flushing method.
The condition should be caught now. Difficult to auto-test, but I did a dummy bundle version upgrade and tested manually and it no longer errored.


Introduce safe page allocation abstractions + add dynamic GHCB borrow checking

Introduce a PageBox<T> type. It works like Box<T>, releasing memory on drop, but it only has a subset of the functionality and uses memory obtained directly from the page allocator. This is useful for some types that need to reside on a page of their own.
Introduce a VmsaPage abstraction based on the PageBox type.
Introduce a HVDoorbellPage abstraction based on the PageBox type.
Introduce a GhcbPage abstraction based on the PageBox type.
Add dynamic borrow checking on top of the GhcbPage abstraction.
Minor cleanups

Is your change compatible with gdbstub?  The gdb support requires borrowing the GHCB in order to step in the debugger, but the debugger may be stepping through code that already has the GHCB borrowed, which would cause debugger actions to panic.  I'm also concerned about the possibility that somebody tries to add logging to code that has an active GHCB borrow, which would cause a similar panic because the console code will attempt to use the GHCB in order to communicate with the console.  While this is safe, it is not exactly desirable to make logging impossible in certain code paths.
I started (but did not complete) a nested GHCB borrow design in which GHCB borrowing had a "level" concept, in which each borrow of the GHCB declared an intended nesting level.  Three levels were defined: normal, console, and debugger.  The premise was that recursive borrows were illegal at a level that was the same or lower than any current borrow, but a recursive borrow was legal at a higher level.  The reference tracker (equivalent of Ref or RefMut) would contain a separate copy of the GHCB, populated at the time of the recursive borrow, and copied back to the GHCB page at the time the nested borrow is dropped.  This creates a safe recursive borrow for the console and debugger cases described above.
As I said, I never finished that work because it seemed like a lower priority than other core logic, but I could pick it up and try to finish it if necessary.  But I would be really concerned about any intermediate change that breaks debugger/console functionality in the pursuit of borrow safety.

Is your change compatible with gdbstub? The gdb support requires borrowing the GHCB in order to step in the debugger, but the debugger may be stepping through code that already has the GHCB borrowed, which would cause debugger actions to panic. I'm also concerned about the possibility that somebody tries to add logging to code that has an active GHCB borrow, which would cause a similar panic because the console code will attempt to use the GHCB in order to communicate with the console. While this is safe, it is not exactly desirable to make logging impossible in certain code paths.

I have not tested this, but it looks like it would interfere, yes.

I started (but did not complete) a nested GHCB borrow design in which GHCB borrowing had a "level" concept, in which each borrow of the GHCB declared an intended nesting level. Three levels were defined: normal, console, and debugger. The premise was that recursive borrows were illegal at a level that was the same or lower than any current borrow, but a recursive borrow was legal at a higher level. The reference tracker (equivalent of Ref or RefMut) would contain a separate copy of the GHCB, populated at the time of the recursive borrow, and copied back to the GHCB page at the time the nested borrow is dropped. This creates a safe recursive borrow for the console and debugger cases described above.

I'm not sure I understand how this would work. If the contents are only copied on drop, then what will we pass to the GHCB method that performs the VMGEXIT? All of these methods (e.g. GHCB::wrmsr()) take a &mut self, but that cannot be done if the reference is dropped. Hope I'm not completely missing the point.
I would have assumed that the new RefMut-like type would need to register its GHCB copy via the GHCB MSR on acquisition. Then the VMGEXIT would work on the new copy, and the MSR could be restored on drop (avoiding the need to copy the GHCB page contents back).

As I said, I never finished that work because it seemed like a lower priority than other core logic, but I could pick it up and try to finish it if necessary. But I would be really concerned about any intermediate change that breaks debugger/console functionality in the pursuit of borrow safety.

I can try to implement something like that if you want.

It just dawned on me that you perhaps meant that the new RefMut-like type would still operate on the original GHCB page, but it would use its copy as a snapshot. I think that could work, but if I understand correctly, this opens a window for the following:
ref1 = ghcb_mut(Level::Normal);    // Takes snapshot 0
ref2 = ghcb_mut(Level::Debugger);  // Takes snapshot 1

ref1.some_field = some_value;      // Some modification to the GHCB

drop(ref2);                        // Restores to snapshot 1

ref1.some_call()                   // GHCB has unexpected state, ref1 modification is lost

I'm not claiming this is necessarily a very common pattern, but one that may happen, making the abstraction somewhat unsafe.

It just dawned on me that you perhaps meant that the new RefMut-like type would still operate on the original GHCB page, but it would use its copy as a snapshot. I think that could work, but if I understand correctly, this opens a window for the following
...

It would also have some usability issues. If the new RefMut-like type implements DerefMut<GHCB>, nothing is stopping us from doing the following, which is unsound:
let ghcb = ghcb_mut()?;
let some_ref: &mut GHCB = ghcb.deref_mut();
log::info() {
    // call some GHCB method that takes `&mut self`
    ghcb_mut()?.some_call();
}
some_ref.some_call()?;

On the other hand, if the new type does not implement DerefMut there is no straightforward way to call GHCB methods. We would have to do something like the following to scope the lifetime of the mutable reference:
let ghcb = ghcb_mut()?;
ghcb.with_mut(|ghcb| ghcb.some_call())?;

For now I'm tempted to drop the last commit on this PR so this can be merged straight away.

It just dawned on me that you perhaps meant that the new RefMut-like type would still operate on the original GHCB page, but it would use its copy as a snapshot. I think that could work, but if I understand correctly, this opens a window for the following:
...
I'm not claiming this is necessarily a very common pattern, but one that may happen, making the abstraction somewhat unsafe.

I take your point, and I don't have any alternative suggestions.  I suspect this is a case where consumers of the GHCB will almost certainly do the right thing and we can accept the risk, because the pattern you are concerned about is one that looks like it is deliberately trying to do something very strange, and therefore is not one we should ever expect to see.  Yes, it's unfortunate if the compiler can't stop this pattern from occurring, but I think we can be OK with that.

It would also have some usability issues. If the new RefMut-like type implements DerefMut<GHCB>, nothing is stopping us from doing the following, which is unsound:
let ghcb = ghcb_mut(Level::Normal)?;
let some_ref: &mut GHCB = ghcb.deref_mut();
log::info() {
    // call some GHCB method that takes `&mut self`
    ghcb_mut(Level::Console)?.some_call();
}
some_ref.some_call()?;

But that's exactly the pattern we need to support: some outer block acquires a mutable reference to the GHCB and some inner block temporarily acquires a nested reference.  In your example, the inner block will drop the nested reference before the outer block attempts to reuse its reference, so the nesting should be accomplished successfully - meaning that the inner block will make a temporary copy in its local RefMut, then the drop will put that data back into the GHCB page, and the outer block will continue based on the data that it holds.  What is about this that is unsound?  It should certainly be the case that any contents of the GHCB page will be identical both before and after the inner block so the outer block won't be able to observe that any temporary copies were made.

For now I'm tempted to drop the last commit on this PR so this can be merged straight away.

That's very reasonable, but now I want to raise a separate concern.  The HV doorbell page contains no mutable data, and thus no mutable reference can ever be acquired (we don't enforce that today, but we should).  If no mutable reference can ever be acquired, then there are no constraints on the number of shared references that can be acquired.  Since there is no constraint, it seems like we would not want to implement any dynamic logic to enforce borrow checking because it can never fail (by construction) and the borrow checking would be wasted effort.  Wouldn't it be better if we just introduced a function that returns &'static HVDoorbell and avoid the need for borrow checking?

I take your point, and I don't have any alternative suggestions. I suspect this is a case where consumers of the GHCB will almost certainly do the right thing and we can accept the risk, because the pattern you are concerned about is one that looks like it is deliberately trying to do something very strange

Not necessarily. This could happen by attaching and detaching with the debugger IIUC.

and therefore is not one we should ever expect to see. Yes, it's unfortunate if the compiler can't stop this pattern from occurring, but I think we can be OK with that.

I think we can enforce this at the compiler level by making any subsequent reference's lifetime depend on the previous one (e.g. something like let r2 = r1.borrow()). I have implemented a small PoC of this but I have to test it properly, plus it's hard to add into the SVSM because the PerCpu cannot store the GHCB and something that references the GHCB (the RefMut-like type), since it makes the PerCpu self-referential (I think). Perhaps this can be done with the Pin type, but I haven't gotten around to trying it.

It would also have some usability issues. If the new RefMut-like type implements DerefMut<GHCB>, nothing is stopping us from doing the following, which is unsound:
let ghcb = ghcb_mut(Level::Normal)?;
let some_ref: &mut GHCB = ghcb.deref_mut();
log::info() {
    // call some GHCB method that takes `&mut self`
    ghcb_mut(Level::Console)?.some_call();
}
some_ref.some_call()?;

But that's exactly the pattern we need to support: some outer block acquires a mutable reference to the GHCB and some inner block temporarily acquires a nested reference. In your example, the inner block will drop the nested reference before the outer block attempts to reuse its reference, so the nesting should be accomplished successfully - meaning that the inner block will make a temporary copy in its local RefMut, then the drop will put that data back into the GHCB page, and the outer block will continue based on the data that it holds. What is about this that is unsound? It should certainly be the case that any contents of the GHCB page will be identical both before and after the inner block so the outer block won't be able to observe that any temporary copies were made.

It is still technically undefined behavior as far as I understand. I don't think in practice it would cause much of a problem in the current state of the compiler, but then again I'm not a compiler expert and it's still not allowed. The following snippet won't build for example:
fn main() {
    let mut v = 5u32;

    let r1 = &mut v;
    *r1 += 1;
    {
        let r2 = &mut v;
    }
    println!("{}", *r1);
}

error[E0499]: cannot borrow `v` as mutable more than once at a time
 --> src/main.rs:7:18
  |
4 |     let r1 = &mut v;
  |              ------ first mutable borrow occurs here
...
7 |         let r2 = &mut v;
  |                  ^^^^^^ second mutable borrow occurs here
8 |     }
9 |     println!("{}", *r1);
  |                    --- first borrow later used here

If you try going around the compiler with something like an UnsafeCell and run the program with Miri you'll see it spills an error as well.

For now I'm tempted to drop the last commit on this PR so this can be merged straight away.

That's very reasonable, but now I want to raise a separate concern. The HV doorbell page contains no mutable data, and thus no mutable reference can ever be acquired (we don't enforce that today, but we should). If no mutable reference can ever be acquired, then there are no constraints on the number of shared references that can be acquired. Since there is no constraint, it seems like we would not want to implement any dynamic logic to enforce borrow checking because it can never fail (by construction) and the borrow checking would be wasted effort. Wouldn't it be better if we just introduced a function that returns &'static HVDoorbell and avoid the need for borrow checking?

Yes, that makes sense, I will change hv_doorbell_unsafe() so that it returns an immutable reference and I'll update the function name.

But that's exactly the pattern we need to support: some outer block acquires a mutable reference to the GHCB and some inner block temporarily acquires a nested reference. In your example, the inner block will drop the nested reference before the outer block attempts to reuse its reference, so the nesting should be accomplished successfully - meaning that the inner block will make a temporary copy in its local RefMut, then the drop will put that data back into the GHCB page, and the outer block will continue based on the data that it holds. What is about this that is unsound? It should certainly be the case that any contents of the GHCB page will be identical both before and after the inner block so the outer block won't be able to observe that any temporary copies were made.

It is still technically undefined behavior as far as I understand. I don't think in practice it would cause much of a problem in the current state of the compiler, but then again I'm not a compiler expert and it's still not allowed. The following snippet won't build for example:

Thinking through this further, I cannot prove that the compiler cannot introduce badly timed spills which upset the nesting design. This makes me wonder whether a better approach would be to reimplement the GHCB object so that all attempts to operate on it use shared references, and the reference to the underlying data is managed internally as an unsafe mutable pointer.

This could also be done by replacing GHCB fields with Cells, since they all implement Copy (I think) and Cell<T> is guaranteed to have the same layout as T.
This would eliminate any possibility that a GHCB might be borrowed while any mutable reference is outstanding. It would mean that the GHCB implementation would have to track its own nesting state (which likely would require that all calls specify a nesting level to ensure that the requested operation is safe to attempt). Internal state could be stored as atomics for ergonomics, and access to the mutable pointers could be gated on whether the atomic accesses that push/pop nesting state can permit the operation to proceed. This seems to me like it would require fewer contortions.
Yes, or Cell could be used too instead of atomics. It's what I used in my PoC.

We continued the nested reference discussion via email. I think all review comments are addressed, so this should be good to go.

This seems to fail booting in debug mode, I'll take a look. Please don't merge yet.

So this is very messy. As-is, the SVSM works with this PR. The thing is, once I introduce the nested protection the SVSM panics early. This is because the new NestedRef type keeps a reference on the PerCpu, which itself is also reentrant and uses a RefCell, which causes it to panic when a mutable borrow is attempted. So this will require a greater rework.

Added some extra documentation in the latest version of the PR. I will merge this by the end of the day if nobody has any objections.


I got issues, but you got 'em too

I got issues, but you got 'em too...


Update Tracing plugin in Java

[ ] Update Tracing plugin in Java to comply to the Tracing guidelines/specs.
[ ] Update Tracing plugin to use open telemetry instead of opencensus.
[ ] Update Readme
[ ] Add testing
[ ] Update Open telemetry Http Policy to add the traces in the service headers.

[x] Update Tracing plugin in Java to comply with the Tracing guidelines/specs.
[ ] Update Tracing plugin to use open telemetry instead of opencensus. - Waiting for Open telemetry package to be available for use.
[x] Update Readme
[ ] Add testing - https://github.com/Azure/azure-sdk-for-java/issues/5156
[x] Update Open telemetry Http Policy to add the traces in the service headers.


Fog not showing - tutorial

Hello. After I have everything set according to "How To Setup Your Own Fog Of War" no fog is showing. Could someone give me advice or some "tutorial" steps? :)
Thank you! :-)

I am having this very same problem. Turning on various debugs show grids that look right but no fog ever shows up anywhere.

I have the same issue. Would be great to have video example of setting this up.


Error hint formatting in settings hard to parse

Testing #34769
I noticed that the hover error for the enum accepted in a setting is pretty hard to read - it's accurate for sure but could we format it better for a long list like this one?  Even something as simple as not wrapping mid values could help.
This is a low priority issue and can be closed if its just too tricky.

Sean

It's a long list so stretching it (e.g having each item on it's own line) would this a very long hover, probably even more impractical.
I'll remove the '[', and file an issue against to hover to not wrap in the middle of a word.

Closing.