exception when session stale causing location file for web stopped being updated

Expected Behavior
location-[account name].json get updated while the bot is running
Actual Behavior
the file stop getting updates after re-logging in (session stale) due to an exception
Your FULL config.json (remove your username, password, gmapkey and any other private info)
{
    "auth_service": "google",
    "username": "",
    "password": "",
    "location": "",
    "favorite_locations":[

    ],
    "gmapkey": "",
    "encrypt_location": "",
    "websocket_server": false,
    "heartbeat_threshold": 10,
    "enable_social": true,
    "live_config_update": {
      "enabled": true,
      "tasks_only": true
    },
    "tasks": [
      {
        "//NOTE: This task MUST be placed on the top of task list": {},
        "type": "RandomAlivePause",
        "config": {
          "enabled": false,
          "min_duration": "00:00:10",
          "max_duration": "00:10:00",
          "min_interval": "00:05:00",
          "max_interval": "01:30:00"
        }
      },
      {
        "type": "HandleSoftBan"
      },
      {
        "type": "CollectLevelUpReward",
        "config": {
          "collect_reward": true,
          "level_limit": -1
        }
      },
      {
        "type": "IncubateEggs",
        "config": {
          "enabled": true,
          "longer_eggs_first": true,
          "min_interval": 120,
         "infinite": [2,5,10],
         "breakable": [2,5,10]
        }
      },
      {
        "type": "UpdateLiveStats",
        "config": {
          "enabled": true,
          "min_interval": 600,
          "stats": ["uptime", "km_walked", "stops_visited", "xp_earned", "pokemon_stats", "most_perfect_pokemon"],
          "terminal_log": true,
          "terminal_title": true
        }
      },
      {
        "type": "TransferPokemon",
        "config": {
          "enabled": true,
          "min_free_slot": 9900,
          "transfer_wait_min": 5,
          "transfer_wait_max": 10
        }
      },
      {
        "type": "EvolvePokemon",
        "config": {
            "enabled": false,
            "evolve_all": "none",
            "evolve_iv_min": 0.8,

            "first_evolve_by": "iv",
            "evolve_above_cp": 0,
            "evolve_above_iv": 0.8,
            "logic": "and",
            "min_evolve_speed": 20,
            "max_evolve_speed": 30,
            "use_lucky_egg": false
        }
      },
      {
        "type": "NicknamePokemon",
        "config": {
          "enabled": true,
          "nickname_above_iv": 0,
          "dont_nickname_favorite": true,
          "nickname_template": "{name:.10s}{iv_pct2}"
        }
      },
      {
        "type": "RecycleItems",
        "config": {
          "min_empty_space": 15,
          "max_balls_keep": 150,
          "max_potions_keep": 50,
          "max_berries_keep": 70,
          "max_revives_keep": 70,
          "item_filter": {
            "Pokeball":       { "keep" : 60 },
            "Potion":         { "keep" : 5 },
            "Super Potion":   { "keep" : 15 },
            "Hyper Potion":   { "keep" : 20 },
            "Revive":         { "keep" : 20 },
            "Razz Berry":     { "keep" : 70 },
            "Greatball":      { "keep" : 60 },
            "Ultraball":      { "keep" : 60 }
          },
          "recycle_wait_min": 1,
          "recycle_wait_max": 4,
          "recycle_force": false,
          "recycle_force_min": "00:01:00",
          "recycle_force_max": "00:05:00"
        }
      },
      {
        "type": "CatchPokemon",
        "config": {
          "daily_catch_limit": 800,
          "treat_unseen_as_vip": true,
          "catch_visible_pokemon": true,
          "catch_lured_pokemon": true,
          "min_ultraball_to_keep": 5,
          "berry_threshold": 0.35,
          "vip_berry_threshold": 0.9,
          "catch_throw_parameters": {
            "excellent_rate": 0.1,
            "great_rate": 0.5,
            "nice_rate": 0.3,
            "normal_rate": 0.1,
            "spin_success_rate" : 0.6,
            "hit_rate": 0.8
          },
          "catch_simulation": {
            "flee_count": 3,
            "flee_duration": 2,
            "catch_wait_min": 2,
            "catch_wait_max": 6,
            "berry_wait_min": 2,
            "berry_wait_max": 3,
            "changeball_wait_min": 2,
            "changeball_wait_max": 3,
            "newtodex_wait_min": 20,
            "newtodex_wait_max": 30
          }
        }
      },
      {
        "type": "SpinFort",
        "config": {
          "enabled": true,
          "spin_wait_min": 2,
          "spin_wait_max": 5
        }
      },
      { "type": "UpdateWebInventory",
        "config": {
          "enabled": true
        }
      },
      {
        "type": "FollowPath",
        "config": {
          "enabled": true,
          "walker": "PolylineWalker",
          "path_mode": "loop",
          "path_start_mode": "first",
          "path_file": "configs/path.q1.json",
          "number_lap": 10,
          "timer_restart_min": "00:10:00",
          "timer_restart_max": "00:20:00",
          "log_interval": 5
        }
      },
      {
        "type": "MoveToFort",
        "config": {
          "enabled": true,
          "lure_attraction": true,
          "lure_max_distance": 2000,
          "walker": "PolylineWalker"
        }
      }
    ],

    "map_object_cache_time": 5,
    "pokemon_bag": {
      "show_at_start": true,
      "show_count": true,
      "show_candies": true,
      "pokemon_info": ["cp", "ivcp", "level"]
    },
    "forts": {
      "avoid_circles": true,
      "max_circle_size": 40,
      "cache_recent_forts": true
    },
    "walk_max": 3.5,
    "walk_min": 1.8,
    "alt_min": 500,
    "alt_max": 1000,
    "gps_default_altitude": 8.0,
    "replicate_gps_xy_noise": false,
    "replicate_gps_z_noise": false,
    "gps_xy_noise_range": 0.000125,
    "gps_z_noise_range": 12.5,
    "walker_limit_output": true,
    "action_wait_min": 1,
    "action_wait_max": 4,
    "debug": false,
    "test": false,
    "health_record": false,
    "location_cache": false,
    "distance_unit": "km",
    "reconnecting_timeout": 20,
    "logging_color": true,

    "catch": {
      "any": {"catch_above_cp": 0, "catch_above_iv": 0, "logic": "or"}
    },

    "release": {
      "Mewtwo": {"release_below_iv": 0},
      "Dragonite": {"release_below_iv": 0},
      "Mew": {"release_below_iv": 0},
      "Moltres": {"release_below_iv": 0},
      "Snorlax": {"release_below_iv": 0},
      "Zapdos": {"release_below_iv": 0},
      "Lapras": {"release_below_iv": 0},
      "Articuno": {"release_below_iv": 0},
      "Arcanine": {"release_below_iv": 0},
      "Vaporeon": {"release_below_iv": 0},
      "Exeggutor": {"release_below_iv": 0},
      "Gyarados": {"release_below_iv": 0.6},
      "Flareon": {"release_below_iv": 0.6},
      "Muk": {"release_below_iv": 0.6},
      "Slowbro": {"release_below_iv": 0.6},
      "Machamp": {"release_below_iv": 0.6},
      "Venusaur": {"release_below_iv": 0.6},
      "Charizard": {"release_below_iv": 0.6},
      "Victreebel": {"release_below_iv": 0.6},
      "Pollwrath": {"release_below_iv": 0.7},
      "Blastoise": {"release_below_iv": 0.7},
      "Nidoking": {"release_below_iv": 0.7},
      "Nidoqueen": {"release_below_iv": 0.7},
      "Vileplume": {"release_below_iv": 0.7},

      "any": {"release_below_cp": 0, "release_below_iv": 0.9, "logic": "or", "keep_best_iv":1}
    },

    "vips" : {
         "Any pokemon put here directly force to use Berry & Best Ball to capture, to secure the capture rate!": {},
        "any": {"catch_above_cp": 1500, "catch_above_iv": 0.9, "logic": "or" },

        "Mewtwo": {},
        "Dragonite": {},
        "Mew": {},
        "Moltres": {},
        "Snorlax": {},
        "Zapdos": {},
        "Lapras": {},
        "Articuno": {},
        "Arcanine": {},
        "Vaporeon": {},
        "Exeggutor": {},
        "Gyarados": {},
        "Flareon": {},
        "Muk": {},
        "Slowbro": {},
        "Machamp": {},
        "Venusaur": {},
        "Charizard": {},
        "Victreebel": {},
        "Pollwrath": {},
        "Blastoise": {},
        "Nidoking": {},
        "Nidoqueen": {},
        "Vileplume": {}
    }
}

Output when issue occurred
2016-08-27 19:43:19,746 [PokemonGoBot] [INFO] [api_error] Session stale, re-logging in.
2016-08-27 19:43:19,756 [PokemonGoBot] [INFO] [login_started] Login procedure started.
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/namle/Downloads/PokemonGo-Bot/pokemongo_bot/__init__.py", line 1245, in update_web_location_worker
    self.update_web_location()
  File "/Users/namle/Downloads/PokemonGo-Bot/pokemongo_bot/__init__.py", line 690, in update_web_location
    cells = self.find_close_cells(*location)
  File "/Users/namle/Downloads/PokemonGo-Bot/pokemongo_bot/__init__.py", line 726, in find_close_cells
    response_dict = self.get_map_objects(lat, lng, timestamp, cellid)
  File "/Users/namle/Downloads/PokemonGo-Bot/pokemongo_bot/__init__.py", line 1300, in get_map_objects
    cell_id=cellid
  File "/Users/namle/Downloads/PokemonGo-Bot/src/pgoapi/pgoapi/pgoapi.py", line 137, in function
    return request.call()
  File "/Users/namle/Downloads/PokemonGo-Bot/src/pgoapi/pgoapi/pgoapi.py", line 219, in call
    raise NotLoggedInException()
NotLoggedInException

2016-08-27 19:43:22,452 [PokemonGoBot] [INFO] [login_successful] Login successful.

Steps to Reproduce
randomly when session stale
Other Information
OS:
OSx 10.11.6
Branch:
master
Git Commit:
ed095936e8fb2bdb7442c9966630664f0cb739ea
Python Version:
2.7.10

maybe the bot should start the walker thread again after relogging in.

Walker isn't going to help much if the API wasn't able to log you back in

Log back in just fine. It's the thread/worker (sorry not walker) for updating location file has not been restarted after the exception.

@Gobberwart Is this the same as #4841?

@mjmadsen It's a bit different, but again has to do with reading/writing json files. Not sure what's going on but will add it to my list to look at.

Thanks bud. :+1:

Maybe as a bandaid we try reading the file, if it fails we delete and recreate it? At least we can avoid people crashing entirely (but will teleport to their start location).

Heh, we're on exactly the same wavelength. I was looking at something like the following as a temporary fix/workaround for the items:
``
try:
with open(web_inventory, "r") as infile:
json_inventory = json.load(infile)
except ValueError:
# Unable to read json from web inventory
# File may be corrupt. Create a new one.
json_inventory = []

And then continue to build the data from an empty list before dumping to the json file

Why would you build the inventory json object from the web file, instead of using the api output inventory file to overwrite it each time?

Closing #4811


⚠ Bofrost.at has degraded performance

In 8851950, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1206 ms

Resolved: Bofrost.at performance has improved in 39869c9.


Swap print for logging

While it is nice to have some debug output when my requests are retrying, I find it to be a bit verbose. It would be nice if these print statements were adjustable via log level by using logging.
Really useful library, thank you!

Duplicate, please discuss in https://github.com/plamere/spotipy/issues/172


src: make a couple of minor style changes

These are pretty minor nits, but I came across them as I was working on the logging output.

Coverage decreased (-0.008%) to 95.222% when pulling 931155e9e2c8f564c2cf3247567495b4e3f3b9d1 on minor-style-changes into cdf064c32f178c26afb06fd35792decfff76db73 on master.


Fern Resource ID

Make an ID default to a FernResourceId which ought to be its own type that is along the lines of the id & a randomly generated UUID.

no longer a concept of ID


Support for Istio prometheusMerge

Description
Dynatrace metric integration is cumbersome with metrics as there is not the best fitting solution available. Either the user disabled istio mTLS for the metric ports and uses dynatrace annotations, or he uses the telemetry module to push data via OTLP to Dynatrace, but hear so many conversion is needed that it is troublefull as well, also see https://kyma-project.io/#/telemetry-manager/user/integration/dynatrace/README?id=ingest-metrics
It turned out that there is another alternative to the direct Dynatrace integration scenario which does not require an explicit disabling of the TLS mode for the whole port. By enabling the prometheusMerge feature of Istio, the envoys will expose a new port which serves the envoy metrics plus the business metrics (configured via prometheus pod annotation). With that, Dynatrace can scrape all the metrics directly without reducing the TLS setting on the original port. However, the metric data will be transported plain text.
While that solution sounds better then the current integration scenario, it will affect the current telemetry functionality heavily, as suddenly all pods will have prometheus annotations and will be detected by the telemetry prometheus input. And all this pods will mainly return envoy metrics.
Goal

Understand all the implications of the feature and propose a concept on if the istio feature should be enabled always/optional and if something should be adjusted in the telemetry functionality.
Perform necessary changes on telemetry side to not conflict with the istio feature
Enable merge flag in istio

Criterias

A new document is created in the internal docs folder which:

gives a clear proposal on if the istio feature should be enabled by default/optional
what kind of adjustments are needed on the telemetry functionality

Remove the conflicting scrape job for annotated pods running with istio
Verify documentation for correctness

After the concept is sorted out, we will re-use the ticket to realize the feature

Re-opening to include also the Istio changes in this story

Unfortunetaly, the istio change must be treated as a breaking change and cannot be rolled out without configuration option. So the config change got reverted and will be introduced properly with a flag which in the beginning will be disabled.
A dedicated ticket got created at https://github.com/kyma-project/istio/issues/1185


feat: payone sepa mandate

PR Type

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] CI-related changes
[ ] Documentation content changes
[ ] Application / infrastructure changes
[ ] Other:
What Is the Current Behavior?

Issue Number: Closes #
What Is the New Behavior?
Does this PR Introduce a Breaking Change?

[ ] Yes
[ ] No
Other Information

The branch was copied to https://github.com/intershop/intershop-pwa/tree/feature/payone-sepa-mandate to possibly be picked up later again.


consolidate config files

The number of config files is really large which makes it hard to make changes to the configuration. We should review them and only keep the ones that are strictly necessary, using overrides when wanting to customize them.

@ismael-mendoza What configuration files did you have in mind removing/merging?


[CARBONDATA-2217]fix drop partition for non existing partition and set FactTimeStamp during compaction for partition table

Problem:
1)when drop partition is fired for a column which does not exists , it throws null pointer exception
2)select * is not working when clean files operation is fired after second level of compaction, it throws exception sometimes
3)new segment is getting created for all the segments if any one partition is dropped
Solution:
1)have a null check , if column does not exists
2)give different timestamp for fact files during compaction to avoid deletion of files during clean files
3)for the partition which is dropped, only for that new segment file should be written and not for all the partition
4) This PR also contains fix for creating a pre aggregate table with same name which has already created in other database
Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[x] Any interfaces changed?
NA

[x] Any backward compatibility impacted?
NA

[x] Document update required?
NA

[x] Testing done
Added UTs
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[x] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.
NA

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/4001/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2757/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2759/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2769/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/4013/

LGTM

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/4032/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2787/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2790/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/4036/

LGTM

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/3749/


No 'ng-touched' on form items when running e2e on Travis CI

I noticed my tests were flaky when checked form validity (i.e., show error state hit when ng-touched && ng-invalid on form inputs) and it took me a while to figure out, but it appears that 'ng-touched' is never applied to any of my form fields when tabbing or clicking through, regardless of any input.
The protractor tests run fine locally, but when running on Travis CI (same browser and everything). We've tried alternatives such as timeouts, browser.actions rather than sendKeys and so on.
The only difference in environments I can see are OSX (local) vs Linux (Travis), the browser versions are the same (FF 39.0). Any ideas? Thanks in advance!

Sorry for the delay here @mrowles - do you have a reproducible test case we can take a look at?

Closing this as really out of date - please open a new issue if you are still seeing problems with the latest version of Protractor.


Add GraphQL implementations doc

This PR adds an implementations doc that lists popular implementations of graphql over HTTP both on server and client side. I've used GitHub stars as a measure of popularity and ordered them by their present number of GitHub stars. This gives a rough idea of popularity and should help us focus our efforts on most popular implementations.

Thanks @spawnia 🤗

PostGraphile has it's own server which technically can serve any GraphQL.js schema (though as far as I know it's only ever used for PostGraphile schemas); is it worth including? It works in a similar way to graphql-express but with a number of enhancements such as websockets, query batching, X-GraphQL-Event-Stream, etc.


Allow to send pictures from storage

Allow to send pictures from storage (gallery)

@M123-dev
I hope we are talking about the the images for product
Is the UI something like this gonna work?
https://user-images.githubusercontent.com/57723319/173873515-a73fb4e9-dbba-4e92-b3c7-0470ab20a582.mp4
or maybe


add patch for jupyterlab-codeeditor to be compatible with latest type…

…script and try jl3

Thanks, @wolfv!


Installation is not successful

Hi, I can't install both with the ps and directly through the package, I don't get any errors at all.  what could be the problem?

Thank you for your feedback! We've been working on major updates to FLARE VM over the last year.
The now revamped FLARE VM has just been released and will make the project more open and maintainable.
Please check out our blog post at https://www.mandiant.com/resources/blog/flarevm-open-to-public and give the new installation a try.
If this problem still persists with the new installation, please report:

new tools or tool-related issues at https://github.com/mandiant/VM-Packages/issues
ideas and issues related to the installer script and configuration at https://github.com/mandiant/flare-vm/issues

Please note that we use this message to close all legacy issues in this repository. We look forward to your feedback and support for the next generation of FLARE VM.


Wrong syntax for image width in FAQs

Where to find the issue

https://www.coronawarn.app/en/faq/results/#interoperability_countries
https://www.coronawarn.app/de/faq/results/#interoperability_countries
https://www.coronawarn.app/en/faq/results/#rat_what_if_positive_result
https://www.coronawarn.app/de/faq/results/#rat_what_if_positive_result

Describe the issue
Some  img tags specify the width including the dimension px. This is not legal HTML syntax. Pixels are implicit and should not be literally specified (see Reference below).
Steps to reproduce
Search for regex width=\s*\d+px in FAQ source inside img tags
Suggestion
Remove the px (pixel) unit from the width attribute inside img tags.
Reference
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-width
"width
The intrinsic width of the image in pixels. Must be an integer without a unit."

PR https://github.com/corona-warn-app/cwa-website/pull/3218 submitted to resolve this issue

Leaving this issue open as of now, because additional work is required
https://github.com/corona-warn-app/cwa-website/pull/3218#issuecomment-1318717079
It might be a good idea to create a new issue for the instances outside the FAQ - but I need time to check if there even are more.

@brianebeling

Leaving this issue open as of now, because additional work is required
https://github.com/corona-warn-app/cwa-website/pull/3218#issuecomment-1318717079
It might be a good idea to create a new issue for the instances outside the FAQ - but I need time to check if there even are that many more.

This issue was only for the FAQ, since this is what I am concentrating on at the moment.

Nevertheless I have submitted PR https://github.com/corona-warn-app/cwa-website/pull/3219 which resolves the only other incorrect instances of img tags with px in the width attribute outside of the FAQs.

The FAQ issue described here is resolved.


[BUG] compiling failed with nvcc+gcc using custom cc_toolchain with platform, with default cc_toolchain success.

brief
NOTE: in the default platform, which is x86_64(k8) toolchain , the compile works.
I wonder if it's a bug or just a misconfiguration in the toolchain_config?
environment
bazel: version7.0.2
cctoolchain: //bazel/toolchains/v5l (a custom cc toolchain for cross compile in aarch64, like https://github.com/f0rmiga/gcc-toolchain/blob/main/toolchain/cc_toolchain_config.bzl)
├── toolchains
│   └── v5l
│       ├── BUILD
│       ├── v5l.BUILD
│       └── v5l_cc_toolchain_config.bzl

repro steps
simply compile the basic example with cu_library and report the following errors.
NOTE: in the default platform, which is x86_64(k8) toolchain , the compile works.
(09:38:08) ERROR: /gw_demo/modules/team_demo/module_demo/BUILD:46:13: Compiling modules/team_demo/module_demo/src/module_demo/module_cuda.cu failed: (Exit 1): nvcc failed: error executing CudaCompile command (from target //modules/team_demo/module_demo:module_cuda)
  (cd /home/zs/.cache/bazel/_bazel_zs/2c098eac6c684e1fabebb74f5f4483bd/execroot/gaos && \
  exec env - \
    PATH=bazel/toolchains/v5l \
  /usr/local/cuda/bin/nvcc -x cu -gencode 'arch=compute_86,code=compute_86' -gencode 'arch=compute_86,code=sm_86' -Xcompiler -fPIC -ccbin bazel/toolchains/v5l/gcc -I . -I bazel-out/aarch64-dbg/bin -I external/local_cuda -I bazel-out/aarch64-dbg/bin/external/local_cuda -isystem modules/team_demo/module_demo/include -isystem bazel-out/aarch64-dbg/bin/modules/team_demo/module_demo/include -isystem external/local_cuda/cuda/include -isystem bazel-out/aarch64-dbg/bin/external/local_cuda/cuda/include -Xcompiler '--cbin /hhh' -O0 -g -c modules/team_demo/module_demo/src/module_demo/module_cuda.cu -o bazel-out/aarch64-dbg/bin/modules/team_demo/module_demo/_objs/module_cuda/module_cuda.pic.o --expt-relaxed-constexpr --extended-lambda)
# Configuration: 8d031e595766517cd77a614587e21bb1501021be933a2e40e13d75f49ba5eaf0
# Execution platform: @@local_config_platform//:host
bazel/toolchains/v5l/gcc: No such file or directory
nvcc fatal   : Failed to preprocess host compiler properties.
(09:38:08) INFO: Elapsed time: 0.480s, Critical Path: 0.03s
(09:38:08) INFO: 5 processes: 5 internal.
(09:38:08) ERROR: Build did NOT complete successfully

considerations
-ccbin parameter is in https://github.com/bazel-contrib/rules_cuda/blob/13a6f1379ec128093edf8dc1f70ae5e5601f31f4/cuda/private/toolchain_configs/nvcc.bzl#L66-L78
which is created from host_compiler, in https://github.com/bazel-contrib/rules_cuda/blob/13a6f1379ec128093edf8dc1f70ae5e5601f31f4/cuda/private/actions/compile.bzl#L25-L37
originaly created from https://github.com/bazel-contrib/rules_cuda/blob/13a6f1379ec128093edf8dc1f70ae5e5601f31f4/cuda/private/rules/cuda_library.bzl#L9-L18
related info
there is an issue https://github.com/bazelbuild/bazel/issues/22561 , which describes the *_executable variable empty, but I think this issue is not related here, because the variable compiler_executable is wrong with bazel/toolchains/v5l, the gcc toolchain and some other tools are linked under the wrong directory. actually the gcc is in /drive/toolchains/aarch64--glibc--stable-2022.03-1/bin/aarch64-linux-gcc
https://github.com/bazelbuild/bazel/issues/7105 this issue describes the cc_toolchain.compiler_executable() usage.
https://bazel.build/rules/lib/providers/CcToolchainInfo#compiler_executable and https://bazel.build/configure/integrate-cpp are the bazel official doc about this topic.
the official example about this variable is here https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl
I wonder if it's a bug or just a misconfiguration in the toolchain_config?
workaround(failed)
I tried to set some soft links to the toolchain crosstool, but failing with more compiling errors.
ln -s /drive/toolchains/aarch64--glibc--stable-2022.03-1/bin/aarch64-linux-gcc /gw_demo/bazel/toolchains/v5l/gcc
ln -s /drive/toolchains/aarch64--glibc--stable-2022.03-1/bin/aarch64-linux-gcc.br_real /gw_demo/bazel/toolchains/bin/gcc.br_real

Seems to be a hermatic issue on first glance (gcc executable is not correctly brought into the building sandbox). The ccbin is just taken from the cc toolchain in use and then passthrough, since cc_toolchain is an implicit dep, then all related files claimed by the cc toolchain config should be brought into the sandbox automatically. You might need to inspect into the bazel-<your_repo>/external/local_config_cc for the cc toolchain configuration.
Before dive deep, it is worth to first try to use --spawn_strategy=local with bazel build to see how it goes.

BTW, is there any plan of the project give an example to use custom/crosscompile cc_toolchain?

After add tool_paths in cc_toolchain_config_info, the variable gets available.
tool_paths = [
        tool_path(
            name = "ld",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-ld.gold",
        ),
        tool_path(
            name = "cpp",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-cpp",
        ),
        tool_path(
            name = "dwp",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-dwp",
        ),
        tool_path(
            name = "gcov",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-gcov",
        ),
        tool_path(
            name = "nm",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-nm",
        ),
        tool_path(
            name = "objcopy",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-objcopy",
        ),
        tool_path(
            name = "objdump",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-objdump",
        ),
        tool_path(
            name = "strip",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-strip",
        ),
        tool_path(
            name = "gcc",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-gcc",
        ),
        tool_path(
            name = "ar",
            path = DRIVE_SDK_V5L_TOOLCHAIN_ROOT + "/bin/aarch64-buildroot-linux-gnu-ar",
        ),
    ]

If it can help anyone finding this issue in the future: facing a similar issue using https://github.com/bazelbuild/rules_cc to declare my cc_toolchain. It seems that it does not correctly set whatever is returned by cc_toolchain.compiler_executable.

Digging a bit deeper, found that cc_toolchain.compiler_executable is on its way out. This means that the issue should be fixed here by using get_tool_for_action instead. I'll try to create a pull request.


How can i get users list by name ?


Add section to README explaining why I made this tool

There are other Changelog automation techniques, and most people probably don't automate their Changelog, so writing up a small section on why this tool exists would be useful.
I think I'm going to in the future write a longer blog post on this, but having something more compact in the repo would be useful

There is a section already added, but I think before 1.0 release it should make it much more clear the kind of automation this tool makes possible


failure when / used in args of dist funs in gamma/exp/exp_nimble

nf <- nimbleFunction(

 run = function(q = double(0)) {

     returnType(double(0))

     foo = 1

out <- pexp_nimble(2, scale = 1/4)
return(out)
})

cnf <- compileNimble(nf)
Error in parse(text = paste0("1/", code$scale)) :
:1:3: unexpected '/'
1: 1//
^

Need to look at the scale/rate processing we do in keyword processing.
Other stuff like
scale = foo + 4
scale = 2 + 3
seem to work fine

Fixed on devel. Note we may want to consider a different way to handle these arguments in the future.
Also the copy and paste from R into Issues turned the "+"s into Markdown bullet points.


Add Dawin - RTL editor -

Hi, I added a new tool Dawin, which is Right to Left (RTL) Markdown editor (for Arabic, Persian lang ..etc).
Thank you so much @mattcone  ✌.

This is awesome, @imAbdelhadi! Thanks for submitting this pull request, and good luck with Dawin!


Feature request: Autoregister webhooks

Just to write down a nice feature idea: To make this resource autoregister the webhook in the github repository.
This can be configured by adding a register_webhook: true in the params, and doing the registration either in the get or by using a explicit put operation.
That would speed up the process of configuring new pipelines, even completely automate it

Agreed, this would make the setup a lot easier and generally be a useful feature 👍
This would require two things from the user:

The webhook_token would have to be passed to the source configuration.
The access token needs to include POST /repos/:owner/:repo/hooks permissions to create a webhook.

With that information we could probably construct the URL for the webhook from the metadata which is passed to tasks. However, I think it would make more sense if this was a separate resource in order to manage the lifecycle of the webhook, but then the metadata passed to the task would not be correct 🤔

It does not need to be a separated resource.
You can set a custom option in the  put, so you can add a simple task to configure the endpoint as needed, something like:
 - name: add-web-hook
  plan:
  - put: pull-request
    params:
      register_webhook: true

I'll close this issue. It would be a great feature to have, but I just don't see it being viable in a good way.


chore: remove webpki

Problem
webpki is unmaintained
Closes https://github.com/neondatabase/neon/security/dependabot/33
Summary of changes
Update all dependents of webpki.
TODO: update sentry when https://github.com/getsentry/sentry-rust/pull/593 gets released
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

IMO it should be fine to use sentry from git for a while until the release is out.

Good to merge.


Zabbix publishes packages.  We should use them.

Our source build for zabbix is crude and time consuming. Zabbix publishes packages for Ubuntu 14.04, that seems like the path of least resistance.
http://repo.zabbix.com/zabbix/2.4/ubuntu/pool/main/z/zabbix/

I ended up overtaking myself and implementing this in https://github.com/bloomberg/chef-bach/pull/636
There was no easier way to get correct precise AND trusty packages.


Faq needs baby triangle

To indicate that you can click it for some drop down funsies!

I don't see this fixed though?


Upgrade version of test and sdk version

Status
READY
Breaking Changes
NO
Description
Fixes #152 by updating test dependcy and increasing min sdk version.
Might be a good fit with #150 as well
Type of Change

[x] ✨ New feature (non-breaking change which adds functionality)
[x] 🛠 Bug fix (non-breaking change which fixes an issue)
[ ] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[x] 🧹 Code refactor
[ ] ✅ Build configuration change
[ ] 📝 Documentation
[x] 🗑 Chore

Closing based on the discussion in #152


Build failure for target "riscv32imc-unknown-none-elf" when manually set --cfg target_has_atomic="..."

When I was developing for my ESP-C3 chip, I used the "static_cell" crate, which uses "portable-atomic" for atomic support starting from version "1.3.0". Starting from this version, my project gets the following error when compiling:
error[E0433]: failed to resolve: could not find `AtomicU8` in `imp`
   --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:659:14
    |
659 |         imp::AtomicU8::is_lock_free()
    |              ^^^^^^^^ could not find `AtomicU8` in `imp`
    |
help: a struct with a similar name exists
    |
659 |         imp::AtomicU128::is_lock_free()
    |              ~~~~~~~~~~
help: consider importing this struct
    |
472 + use core::sync::atomic::AtomicU8;
    |
help: if you import `AtomicU8`, refer to it directly
    |
659 -         imp::AtomicU8::is_lock_free()
659 +         AtomicU8::is_lock_free()
    |

error[E0433]: failed to resolve: could not find `AtomicU8` in `imp`
   --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:681:14
    |
681 |         imp::AtomicU8::is_always_lock_free()
    |              ^^^^^^^^ could not find `AtomicU8` in `imp`
    |
help: a struct with a similar name exists
    |
681 |         imp::AtomicU128::is_always_lock_free()
    |              ~~~~~~~~~~
help: consider importing this struct
    |
472 + use core::sync::atomic::AtomicU8;
    |
help: if you import `AtomicU8`, refer to it directly
    |
681 -         imp::AtomicU8::is_always_lock_free()
681 +         AtomicU8::is_always_lock_free()
    |

error[E0412]: cannot find type `AtomicU8` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1384:37
     |
1384 |     fn as_atomic_u8(&self) -> &imp::AtomicU8 {
     |                                     ^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicU128` defined here
     |
help: a struct with a similar name exists
     |
1384 |     fn as_atomic_u8(&self) -> &imp::AtomicU128 {
     |                                     ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicU8;
     |
help: if you import `AtomicU8`, refer to it directly
     |
1384 -     fn as_atomic_u8(&self) -> &imp::AtomicU8 {
1384 +     fn as_atomic_u8(&self) -> &AtomicU8 {
     |

error[E0412]: cannot find type `AtomicU8` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1387:56
     |
1387 |         unsafe { &*(self as *const Self as *const imp::AtomicU8) }
     |                                                        ^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicU128` defined here
     |
help: a struct with a similar name exists
     |
1387 |         unsafe { &*(self as *const Self as *const imp::AtomicU128) }
     |                                                        ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicU8;
     |
help: if you import `AtomicU8`, refer to it directly
     |
1387 -         unsafe { &*(self as *const Self as *const imp::AtomicU8) }
1387 +         unsafe { &*(self as *const Self as *const AtomicU8) }
     |

error[E0412]: cannot find type `AtomicPtr` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1409:17
     |
1409 |     inner: imp::AtomicPtr<T>,
     |                 ^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicI64` defined here
     |
note: found an item that was configured out
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/mod.rs:269:60
     |
269  | pub(crate) use self::core_atomic::{AtomicI64, AtomicIsize, AtomicPtr, AtomicU64, AtomicUsize};
     |                                                            ^^^^^^^^^
help: a struct with a similar name exists
     |
1409 |     inner: imp::AtomicI64<T>,
     |                 ~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicPtr;
     |
help: if you import `AtomicPtr`, refer to it directly
     |
1409 -     inner: imp::AtomicPtr<T>,
1409 +     inner: AtomicPtr<T>,
     |

error[E0433]: failed to resolve: could not find `AtomicPtr` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1464:28
     |
1464 |         Self { inner: imp::AtomicPtr::new(p) }
     |                            ^^^^^^^^^ could not find `AtomicPtr` in `imp`
     |
help: a struct with a similar name exists
     |
1464 |         Self { inner: imp::AtomicI64::new(p) }
     |                            ~~~~~~~~~
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicPtr;
     |
472  + use crate::AtomicPtr;
     |
help: if you import `AtomicPtr`, refer to it directly
     |
1464 -         Self { inner: imp::AtomicPtr::new(p) }
1464 +         Self { inner: AtomicPtr::new(p) }
     |

error[E0412]: cannot find type `AtomicPtr` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1516:15
     |
1516 |         <imp::AtomicPtr<T>>::is_lock_free()
     |               ^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicI64` defined here
     |
note: found an item that was configured out
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/mod.rs:269:60
     |
269  | pub(crate) use self::core_atomic::{AtomicI64, AtomicIsize, AtomicPtr, AtomicU64, AtomicUsize};
     |                                                            ^^^^^^^^^
help: a struct with a similar name exists
     |
1516 |         <imp::AtomicI64<T>>::is_lock_free()
     |               ~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicPtr;
     |
help: if you import `AtomicPtr`, refer to it directly
     |
1516 -         <imp::AtomicPtr<T>>::is_lock_free()
1516 +         <AtomicPtr<T>>::is_lock_free()
     |

error[E0412]: cannot find type `AtomicPtr` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1538:15
     |
1538 |         <imp::AtomicPtr<T>>::is_always_lock_free()
     |               ^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicI64` defined here
     |
note: found an item that was configured out
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/mod.rs:269:60
     |
269  | pub(crate) use self::core_atomic::{AtomicI64, AtomicIsize, AtomicPtr, AtomicU64, AtomicUsize};
     |                                                            ^^^^^^^^^
help: a struct with a similar name exists
     |
1538 |         <imp::AtomicI64<T>>::is_always_lock_free()
     |               ~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicPtr;
     |
help: if you import `AtomicPtr`, refer to it directly
     |
1538 -         <imp::AtomicPtr<T>>::is_always_lock_free()
1538 +         <AtomicPtr<T>>::is_always_lock_free()
     |

error[E0412]: cannot find type `AtomicIsize` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3953:17
     |
3953 |     atomic_int!(AtomicIsize, isize, 4);
     |                 ^^^^^^^^^^^ not found in `imp`
     |
note: found an item that was configured out
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/mod.rs:269:47
     |
269  | pub(crate) use self::core_atomic::{AtomicI64, AtomicIsize, AtomicPtr, AtomicU64, AtomicUsize};
     |                                               ^^^^^^^^^^^
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicIsize;
     |

error[E0433]: failed to resolve: could not find `AtomicIsize` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3953:17
     |
3953 |     atomic_int!(AtomicIsize, isize, 4);
     |                 ^^^^^^^^^^^ could not find `AtomicIsize` in `imp`
     |
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicIsize;
     |
472  + use crate::AtomicIsize;
     |

error[E0412]: cannot find type `AtomicUsize` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3955:17
     |
3955 |     atomic_int!(AtomicUsize, usize, 4);
     |                 ^^^^^^^^^^^ not found in `imp`
     |
note: found an item that was configured out
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/mod.rs:269:82
     |
269  | pub(crate) use self::core_atomic::{AtomicI64, AtomicIsize, AtomicPtr, AtomicU64, AtomicUsize};
     |                                                                                ^^^^^^^^^^^
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicUsize;
     |

error[E0433]: failed to resolve: could not find `AtomicUsize` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3955:17
     |
3955 |     atomic_int!(AtomicUsize, usize, 4);
     |                 ^^^^^^^^^^^ could not find `AtomicUsize` in `imp`
     |
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicUsize;
     |
472  + use crate::AtomicUsize;
     |

error[E0412]: cannot find type `AtomicI8` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3967:17
     |
3967 |     atomic_int!(AtomicI8, i8, 1);
     |                 ^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicI128` defined here
     |
help: a struct with a similar name exists
     |
3967 |     atomic_int!(AtomicI128, i8, 1);
     |                 ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicI8;
     |

error[E0433]: failed to resolve: could not find `AtomicI8` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3967:17
     |
3967 |     atomic_int!(AtomicI8, i8, 1);
     |                 ^^^^^^^^ could not find `AtomicI8` in `imp`
     |
help: a struct with a similar name exists
     |
3967 |     atomic_int!(AtomicI128, i8, 1);
     |                 ~~~~~~~~~~
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicI8;
     |
472  + use crate::AtomicI8;
     |

error[E0412]: cannot find type `AtomicU8` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3968:17
     |
3968 |     atomic_int!(AtomicU8, u8, 1);
     |                 ^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicU128` defined here
     |
help: a struct with a similar name exists
     |
3968 |     atomic_int!(AtomicU128, u8, 1);
     |                 ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicU8;
     |

error[E0433]: failed to resolve: could not find `AtomicU8` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3968:17
     |
3968 |     atomic_int!(AtomicU8, u8, 1);
     |                 ^^^^^^^^ could not find `AtomicU8` in `imp`
     |
help: a struct with a similar name exists
     |
3968 |     atomic_int!(AtomicU128, u8, 1);
     |                 ~~~~~~~~~~
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicU8;
     |
472  + use crate::AtomicU8;
     |

error[E0412]: cannot find type `AtomicI16` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3971:17
     |
3971 |     atomic_int!(AtomicI16, i16, 2);
     |                 ^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicI128` defined here
     |
help: a struct with a similar name exists
     |
3971 |     atomic_int!(AtomicI128, i16, 2);
     |                 ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicI16;
     |

error[E0433]: failed to resolve: could not find `AtomicI16` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3971:17
     |
3971 |     atomic_int!(AtomicI16, i16, 2);
     |                 ^^^^^^^^^ could not find `AtomicI16` in `imp`
     |
help: a struct with a similar name exists
     |
3971 |     atomic_int!(AtomicI128, i16, 2);
     |                 ~~~~~~~~~~
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicI16;
     |
472  + use crate::AtomicI16;
     |

error[E0412]: cannot find type `AtomicU16` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3972:17
     |
3972 |     atomic_int!(AtomicU16, u16, 2);
     |                 ^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicU128` defined here
     |
help: a struct with a similar name exists
     |
3972 |     atomic_int!(AtomicU128, u16, 2);
     |                 ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicU16;
     |

error[E0433]: failed to resolve: could not find `AtomicU16` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3972:17
     |
3972 |     atomic_int!(AtomicU16, u16, 2);
     |                 ^^^^^^^^^ could not find `AtomicU16` in `imp`
     |
help: a struct with a similar name exists
     |
3972 |     atomic_int!(AtomicU128, u16, 2);
     |                 ~~~~~~~~~~
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicU16;
     |
472  + use crate::AtomicU16;
     |

error[E0412]: cannot find type `AtomicI32` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3975:17
     |
3975 |     atomic_int!(AtomicI32, i32, 4);
     |                 ^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicI128` defined here
     |
help: a struct with a similar name exists
     |
3975 |     atomic_int!(AtomicI128, i32, 4);
     |                 ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicI32;
     |

error[E0433]: failed to resolve: could not find `AtomicI32` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3975:17
     |
3975 |     atomic_int!(AtomicI32, i32, 4);
     |                 ^^^^^^^^^ could not find `AtomicI32` in `imp`
     |
help: a struct with a similar name exists
     |
3975 |     atomic_int!(AtomicI128, i32, 4);
     |                 ~~~~~~~~~~
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicI32;
     |
472  + use crate::AtomicI32;
     |

error[E0412]: cannot find type `AtomicU32` in module `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2373:26
     |
2373 |         atomic_int!(int, AtomicU32, $int_type, $align);
     |                          ^^^^^^^^^
...
3976 |     atomic_int!(AtomicU32, u32, 4);
     |     ------------------------------ in this macro invocation
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/imp/fallback/mod.rs:111:9
     |
111  |         pub(crate) struct $atomic_type {
     |         ------------------------------ similarly named struct `AtomicU128` defined here
     |
     = note: this error originates in the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)
help: a struct with a similar name exists
     |
2373 |         atomic_int!(int, AtomicU128, $int_type, $align);
     |                          ~~~~~~~~~~
help: consider importing this struct
     |
472  + use core::sync::atomic::AtomicU32;
     |

error[E0433]: failed to resolve: could not find `AtomicU32` in `imp`
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2373:26
     |
2373 |         atomic_int!(int, AtomicU32, $int_type, $align);
     |                          ^^^^^^^^^ could not find `AtomicU32` in `imp`
...
3976 |     atomic_int!(AtomicU32, u32, 4);
     |     ------------------------------ in this macro invocation
     |
     = note: this error originates in the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)
help: a struct with a similar name exists
     |
2373 |         atomic_int!(int, AtomicU128, $int_type, $align);
     |                          ~~~~~~~~~~
help: consider importing one of these items
     |
472  + use core::sync::atomic::AtomicU32;
     |
472  + use crate::AtomicU32;
     |

   Compiling rand_core v0.6.4
   Compiling linked_list_allocator v0.10.5
error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1431:26
     |
1431 |         fmt::Debug::fmt(&self.load(Ordering::Relaxed), f)
     |                          ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1439:28
     |
1439 |         fmt::Pointer::fmt(&self.load(Ordering::Relaxed), f)
     |                            ^^^^ cannot infer type for type parameter `T`

error: constant expression depends on a generic parameter
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:23
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1463:9
     |
1463 |         static_assert_layout!(AtomicPtr<()>, *mut ());
     |         --------------------------------------------- in this macro invocation
     |
     = note: this may fail depending on what value the parameter takes
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `static_assert_layout` (in Nightly builds, run with -Z macro-backtrace for more info)

error: constant expression depends on a generic parameter
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:18
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1463:9
     |
1463 |         static_assert_layout!(AtomicPtr<()>, *mut ());
     |         --------------------------------------------- in this macro invocation
     |
     = note: this may fail depending on what value the parameter takes
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `static_assert_layout` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1463:9
     |
1463 |         static_assert_layout!(AtomicPtr<()>, *mut ());
     |         --------------------------------------------- in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `static_assert_layout` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:1974:13
     |
1974 |             self.as_atomic_usize().fetch_add(val, order) as *mut T
     |             ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2018:13
     |
2018 |             self.as_atomic_usize().fetch_sub(val, order) as *mut T
     |             ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2077:13
     |
2077 |             self.as_atomic_usize().fetch_or(val, order) as *mut T
     |             ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2134:13
     |
2134 |             self.as_atomic_usize().fetch_and(val, order) as *mut T
     |             ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2190:13
     |
2190 |             self.as_atomic_usize().fetch_xor(val, order) as *mut T
     |             ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2238:13
     |
2238 |             self.as_atomic_usize().bit_set(bit, order)
     |             ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2283:13
     |
2283 |             self.as_atomic_usize().bit_clear(bit, order)
     |             ^^^^ cannot infer type for type parameter `T`

error[E0282]: type annotations needed
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2328:13
     |
2328 |             self.as_atomic_usize().bit_toggle(bit, order)
     |             ^^^^ cannot infer type for type parameter `T`

error: constant expression depends on a generic parameter
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:23
     |
13   |           let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2335:9
     |
2335 | /         static_assert!(
2336 | |             core::mem::size_of::<AtomicPtr<()>>() == core::mem::size_of::<AtomicUsize>()
2337 | |         );
     | |_________- in this macro invocation
     |
     = note: this may fail depending on what value the parameter takes
     = note: this error originates in the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error: constant expression depends on a generic parameter
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:18
     |
13   |           let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2335:9
     |
2335 | /         static_assert!(
2336 | |             core::mem::size_of::<AtomicPtr<()>>() == core::mem::size_of::<AtomicUsize>()
2337 | |         );
     | |_________- in this macro invocation
     |
     = note: this may fail depending on what value the parameter takes
     = note: this error originates in the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |           let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |               ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2335:9
     |
2335 | /         static_assert!(
2336 | |             core::mem::size_of::<AtomicPtr<()>>() == core::mem::size_of::<AtomicUsize>()
2337 | |         );
     | |_________- in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error: constant expression depends on a generic parameter
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:23
     |
13   |           let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2338:9
     |
2338 | /         static_assert!(
2339 | |             core::mem::align_of::<AtomicPtr<()>>() == core::mem::align_of::<AtomicUsize>()
2340 | |         );
     | |_________- in this macro invocation
     |
     = note: this may fail depending on what value the parameter takes
     = note: this error originates in the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error: constant expression depends on a generic parameter
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:18
     |
13   |           let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2338:9
     |
2338 | /         static_assert!(
2339 | |             core::mem::align_of::<AtomicPtr<()>>() == core::mem::align_of::<AtomicUsize>()
2340 | |         );
     | |_________- in this macro invocation
     |
     = note: this may fail depending on what value the parameter takes
     = note: this error originates in the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |           let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |               ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:2338:9
     |
2338 | /         static_assert!(
2339 | |             core::mem::align_of::<AtomicPtr<()>>() == core::mem::align_of::<AtomicUsize>()
2340 | |         );
     | |_________- in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3953:5
     |
3953 |     atomic_int!(AtomicIsize, isize, 4);
     |     ---------------------------------- in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3955:5
     |
3955 |     atomic_int!(AtomicUsize, usize, 4);
     |     ---------------------------------- in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3967:5
     |
3967 |     atomic_int!(AtomicI8, i8, 1);
     |     ---------------------------- in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3968:5
     |
3968 |     atomic_int!(AtomicU8, u8, 1);
     |     ---------------------------- in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3971:5
     |
3971 |     atomic_int!(AtomicI16, i16, 2);
     |     ------------------------------ in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3972:5
     |
3972 |     atomic_int!(AtomicU16, u16, 2);
     |     ------------------------------ in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3975:5
     |
3975 |     atomic_int!(AtomicI32, i32, 4);
     |     ------------------------------ in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
    --> /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/utils.rs:13:13
     |
13   |         let [] = [(); true as usize - $crate::utils::_assert_is_bool($cond) as usize];
     |             ^^ expected `0`, found `true as usize - $crate::utils::_assert_is_bool($cond) as usize`
     |
    ::: /Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.5.1/src/lib.rs:3976:5
     |
3976 |     atomic_int!(AtomicU32, u32, 4);
     |     ------------------------------ in this macro invocation
     |
     = note: expected array `[(); 0]`
                found array `[(); true as usize - $crate::utils::_assert_is_bool($cond) as usize]`
     = note: this error originates in the macro `static_assert` which comes from the expansion of the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0282, E0308, E0412, E0433.
For more information about an error, try `rustc --explain E0282`.
error: could not compile `portable-atomic` (lib) due to 62 previous errors
warning: build failed, waiting for other jobs to finish...

My "rustflags" configuration is as follows:
rustflags = [
  "-C", "link-arg=-Tlinkall.x",

  # Required to obtain backtraces (e.g. when using the "esp-backtrace" crate.)
  # NOTE: May negatively impact performance of produced code
  "-C", "force-frame-pointers",

  # comment the cfgs below if you do _not_ wish to emulate atomics.
  # enable the atomic codegen option for RISCV
  "-C", "target-feature=+a",
  # tell the core library have atomics even though it's not specified in the target definition
  "--cfg", "target_has_atomic_load_store",
  "--cfg", 'target_has_atomic_load_store="8"',
  "--cfg", 'target_has_atomic_load_store="16"',
  "--cfg", 'target_has_atomic_load_store="32"',
  "--cfg", 'target_has_atomic_load_store="ptr"',
  # enable cas
  "--cfg", "target_has_atomic",
  "--cfg", 'target_has_atomic="8"',
  "--cfg", 'target_has_atomic="16"',
  "--cfg", 'target_has_atomic="32"',
  "--cfg", 'target_has_atomic="ptr"',
]

The compilation tool chain of the "nightly" channel is used.

riscv32imc-unknown-none-elf itself builds with no problems, but the manually set --cfg target_has_atomic="..." seems to be causing problems.
The real problem is shown in the first error, which indicates that the standard library does not provide compare_exchange.
$ cargo build --target riscv32imc-unknown-none-elf -vv
   Compiling portable-atomic v1.5.1 (/Users/taiki/projects/sources/taiki-e/portable-atomic)
     Running `CARGO=/Users/taiki/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/cargo CARGO_CRATE_NAME=portable_atomic CARGO_MANIFEST_DIR=/Users/taiki/projects/sources/taiki-e/portable-atomic CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='Portable atomic types including support for 128-bit atomics, atomic float, etc.
' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='Apache-2.0 OR MIT' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=portable-atomic CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/taiki-e/portable-atomic' CARGO_PKG_RUST_VERSION=1.34 CARGO_PKG_VERSION=1.5.1 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=5 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 CARGO_RUSTC_CURRENT_DIR=/Users/taiki/projects/sources/taiki-e/portable-atomic DYLD_FALLBACK_LIBRARY_PATH='/Users/taiki/projects/sources/taiki-e/portable-atomic/target/debug/deps:/Users/taiki/.rustup/toolchains/nightly-aarch64-apple-darwin/lib:/Users/taiki/.rustup/toolchains/nightly-aarch64-apple-darwin/lib:/Users/taiki/lib:/usr/local/lib:/usr/lib' OUT_DIR=/Users/taiki/projects/sources/taiki-e/portable-atomic/target/riscv32imc-unknown-none-elf/debug/build/portable-atomic-91823339a39f91aa/out /Users/taiki/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/rustc --crate-name portable_atomic --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --warn=unreachable_pub '--warn=clippy::undocumented_unsafe_blocks' '--warn=clippy::transmute_undefined_repr' '--warn=clippy::trailing_empty_array' --warn=single_use_lifetimes --warn=rust_2018_idioms '--warn=clippy::pedantic' --warn=non_ascii_idents '--warn=clippy::inline_asm_x86_att_syntax' --warn=improper_ctypes_definitions --warn=improper_ctypes '--warn=clippy::default_union_representation' '--warn=clippy::as_ptr_cast_mut' '--warn=clippy::all' '--allow=clippy::type_complexity' '--allow=clippy::too_many_lines' '--allow=clippy::too_many_arguments' '--allow=clippy::struct_excessive_bools' '--allow=clippy::single_match_else' '--allow=clippy::single_match' '--allow=clippy::similar_names' '--allow=clippy::module_name_repetitions' '--allow=clippy::missing_errors_doc' '--allow=clippy::manual_range_contains' '--allow=clippy::manual_assert' '--allow=clippy::float_cmp' '--allow=clippy::doc_markdown' '--allow=clippy::borrow_as_ptr' --cfg 'feature="default"' --cfg 'feature="fallback"' -C metadata=f5fd3c4b0d0fa7e3 -C extra-filename=-f5fd3c4b0d0fa7e3 --out-dir /Users/taiki/projects/sources/taiki-e/portable-atomic/target/riscv32imc-unknown-none-elf/debug/deps --target riscv32imc-unknown-none-elf -L dependency=/Users/taiki/projects/sources/taiki-e/portable-atomic/target/riscv32imc-unknown-none-elf/debug/deps -L dependency=/Users/taiki/projects/sources/taiki-e/portable-atomic/target/debug/deps -C target-feature=+a --cfg target_has_atomic_load_store --cfg 'target_has_atomic_load_store="8"' --cfg 'target_has_atomic_load_store="16"' --cfg 'target_has_atomic_load_store="32"' --cfg 'target_has_atomic_load_store="ptr"' --cfg target_has_atomic --cfg 'target_has_atomic="8"' --cfg 'target_has_atomic="16"' --cfg 'target_has_atomic="32"' --cfg 'target_has_atomic="ptr"' --cfg portable_atomic_llvm_16`
error[E0599]: no method named `compare_exchange` found for struct `core::sync::atomic::AtomicPtr` in the current scope
  --> src/imp/core_atomic.rs:97:20
   |
97 |         self.inner.compare_exchange(current, new, success, failure)
   |                    ^^^^^^^^^^^^^^^^ method not found in `AtomicPtr<T>`

This is because it is linked to prebuilt core built without --cfg target_has_atomic="..." applied. So it can be resolved by re-building the core.
$ cargo build --target riscv32imc-unknown-none-elf -vv -Z build-std=core

I don't think anything can be done on our part about this, since the problem here is not with the portable-atomic, but with the situation (and the user who created that situation) where --cfg target_has_atomic="..." is set but core is not actually providing it.

$ cargo build --target riscv32imc-unknown-none-elf -Z build-std=core

I noticed that this works in the main branch but not in 1.5.1. I have released 1.6.0, so it should work with it.

I tested version 1.6.0 and found that this problem no longer exists. Thank you for your help!


SIGSEGV: invalid memory reference in tests, but only when running them simultanously

I'm facing an issue similar to #1257 but it only fails when I run multiple tests together, when running them one by one it's all good. I didn't open this PR as a bug report because I don't have the time right now to create a repro, once I'll have it I'll put it in the comments.
To make sure that it's not a happy little accident I ran the tests one by one a thousand times (5x1k runs, 0 failures) and I also ran all tests together (1k runs, 232 failures) so I can confidently say it's the tests running simultaneously that fails.
I also copied together my tests into a single one and run that as well which also produced no failures.
I also did a little experiment by just deleting/duplicating tests. When I only have 3 tests the error ratio is down to 6.2%, but when I have 15 tests there isn't a single one that ran successfully.
Another check I did was to add the serial_test library and annotate all tests with the #[serial] attribute which causes all tests but the first one fail with the following error: called `append_to_inittab` but a Python interpreter is already running which I don't really understand, my assumption would be that one executor stops before the other one starts, but I guess I'm wrong about this. I also tried running the tests with --jobs 1 but that also didn't help.
Basically all tests are the same, the only difference is that I'm loading different Python files:
#[test]
fn some_test() {
    let source = include_str!("tests/some_test.py");

    let data = load_some_data();

    pyo3::append_to_inittab!(my_library);

    Python::with_gil(|py| {
        let globals = vec![("data", Py::new(py, data).unwrap())];

        Python::run_bound(
            py,
            source,
            Some(&globals.into_py_dict_bound(py)),
            None,
        )
    })
    .unwrap();
}

As a final clue, if I run multiple tests but comment out the pyo3::append_to_inittab!(my_library); line from all but a single test and cargo runs that test first then it's always green (I didn't do the 1k tests with it but run it manually ~20 times).
I cannot share the library I'm using as it's not open source, but based on these results I'm quite confident that the issue is not with the library itself. Sadly I don't have time right now to set up a minimal example with some 3rd party library.
Operating system and version: Ubuntu 22.04 (Linux Mint 21.3)
Python version: 3.10.12 (OS version)
Rust version: 1.78.0 (latest stable)
PyO3 version: originally faced the issue with 0.21, I updated to 0.22 but it's still present.

As a final clue, if I run multiple tests but comment out the pyo3::append_to_inittab!(my_library); line from all but a single test and cargo runs that test first then it's always green (I didn't do the 1k tests with it but run it manually ~20 times).

I think this is the key insight indeed. I think it's quite likely there's a race when calling append_to_inittab!  multiple times in parallel. Further investigation would be needed to confirm whether it's racing with itself (and maybe PyO3 can try to mitigate it) or it's a time-of-check vs time-of-use issue with the check we already have against the interpreter already being up.


The label value in outlined overlaps the border

[x ] This is not a v0.x issue.
[x ] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

Current Behavior 😯

Steps to Reproduce 🕹
https://codesandbox.io/s/7m8vm8yxm6

Link:

Context 🔦
There are a lot of tabs that need to be display on and off,I'm not sure if it's my problem or bug

Your Environment 🌎

Tech
Version

Material-UI
3.9.2

React
yes

Browser

TypeScript

etc.

@Andrew-Zn This is a visibility issue. We are measuring the label dimension to display the right gap. We have 3 class of solutions available:

Remount the component every time it's displayed. For instance, this can be achieved with a key:

          <TextField
+           key={this.state.flag}
            id="one"
            label="No.1"
            value="This is one" //这里是函数 如果有存在传入值。就是传入值的效果，还有默认效果
            fullWidth
            margin="normal"
            variant="outlined"
          />

          <TextField
+           key={this.state.flag}
            id="two"
            label="No.2"
            value="This is two" //这里是函数 如果有存在传入值。就是传入值的效果，还有默认效果
            fullWidth
            margin="normal"
            variant="outlined"
          />

Use a background white color like Google is doing with it's official signin inputs:

import React, { Component } from "react";
import ReactDOM from "react-dom";
import { withStyles } from "@material-ui/core/styles";
import TextField from "@material-ui/core/TextField";
import Button from "@material-ui/core/Button";

import "./styles.css";

const styles = theme => ({
  root: {
    display: "flex",
    textAlign: "center",
    width: 300,
    marginLeft: 100,
    marginTop: 200
  },
  hidden: {
    display: "none"
  },
  button: {
    background: "green"
  },
+ label: {
+   backgroundColor: "white"
+  }
});

class App extends Component {
  state = {
    flag: true
  };
  handle = () => {
    this.setState({
      flag: !this.state.flag
    });
  };
  render() {
    const { classes } = this.props;
    return (

          <TextField
+           InputLabelProps={{
+             classes: {
+               root: classes.label
+             }
+            }}
            id="one"
            label="No.1"
            value="This is one" //这里是函数 如果有存在传入值。就是传入值的效果，还有默认效果
            fullWidth
            margin="normal"
            variant="outlined"
          />

          <TextField
+           InputLabelProps={{
+             classes: {
+               root: classes.label
+             }
+            }}
            id="two"
            label="No.2"
            value="This is two" //这里是函数 如果有存在传入值。就是传入值的效果，还有默认效果
            fullWidth
            margin="normal"
            variant="outlined"
          />

        <Button className={classes.button} onClick={this.handle}>
          Change
        </Button>

    );
  }
}

Use the intersection Observer API internally, but requires a polyfill 👎

What do you think of 1. It's probably good enough for now.

Thank you very much for your solutions. The second solution is most helpful for my question, so I take this suggestion.  Thanks again. Best wishes!

Still same problem with material-ui 4.4.0.

Do you have a reproduction?

const styles = theme => ({
});
function TabContainer(props) {
const { children, value, index, ...other } = props;
return (
<Typography
component="div"
role="tabpanel"
hidden={value !== index}
id={full-width-tabpanel-${index}}
aria-labelledby={full-width-tab-${index}}
{...other}
>

{children}

);
}
class CheckoutPage extends Component {
constructor(props) {
super(props);
this.state = {
openDrawer: false,
name: '',
street: '',
value: 0,
};
}
handleChange = index => {
this.setState({ value: index, activeStep: index });
};
onChangeName = event => {
this.setState({ name: event.target.value });
};
onChangeStreet = event => {
this.setState({ street: event.target.value });
};
render() {
const { theme } = this.props;
const { name, street,  value } = this.state;
return (

        <TabContainer
          value={value}
          index={0}
          dir={theme.direction}
        >
          <TextField
            id="outlined-name"
            label="Vor- und Nachname"
            value={name}
            onChange={this.onChangeName}
            margin="normal"
            variant="outlined"
            fullWidth
            type="email"
            style={{ marginBottom: 20, marginTop: 20 }}
          />

            <Button
              variant="contained"
              onClick={event => {this.handleChange(value + 1); }}>
              Next
            </Button>

        </TabContainer>
        <TabContainer
          value={value}
          index={1}
          dir={theme.direction}
        >
          <TextField
            inputRef={el => {
              this.street = el;
            }}
            id="street"
            label="Straße und Hausnr."
            value={street}
            onChange={this.onChangeStreet}
            variant="outlined"
            fullWidth
            style={{ marginBottom: 20, marginTop: 20 }}
          />

        </TabContainer>

);

}
}
export default withStyles(styles, { withTheme: true })(CheckoutPage);
`

@kamami Thanks for sharing, at this point, the solution 3. in https://github.com/mui-org/material-ui/issues/16465#issuecomment-508080692 could be a great long term approach. Today, you could add a key={activeStep} prop on the TextField element. We could imagine the following fix:
diff --git a/packages/material-ui/src/TextField/TextField.js b/packages/material-ui/src/TextField/TextField.js
index a8f3cadaea..fe8e39103c 100644
--- a/packages/material-ui/src/TextField/TextField.js
+++ b/packages/material-ui/src/TextField/TextField.js
@@ -94,13 +94,14 @@ const TextField = React.forwardRef(function TextField(props, ref) {

   const [labelWidth, setLabelWidth] = React.useState(0);
   const labelRef = React.useRef(null);
+  // eslint-disable-next-line react-hooks/exhaustive-deps
   React.useEffect(() => {
     if (variant === 'outlined') {
       // #StrictMode ready
       const labelNode = ReactDOM.findDOMNode(labelRef.current);
       setLabelWidth(labelNode != null ? labelNode.offsetWidth : 0);
     }
-  }, [variant, required, label]);
+  });

   warning(

cc @eps1lon

@oliviertassinari This works fine.
Unfortunatly it breaks my autofocus method...
I added    ```
inputRef={el => {
this.street = el;
}}
to my textfield. My button triggers then `textfield.focus();` This does not work, when I give Textfield the key={activeStep}.

@kamami Please open a separate issue. A codesandbox to reproduce the issue would help a lot.

Same issue in Vue's version of Material - https://github.com/vuetifyjs/vuetify/issues/7470

There is an good first issue open to update the logic to compute the label width at each render.

@oliviertassinari
Noticed this is closed, but i'm having this issue with 4.4.3 on a . Using the solution above to set the background color to white for now, but seems like a hack. I'm not sure i'm understanding the root cause of the issue, because in other projects i've definitely used outlined inputs without the background color solution  and it's worked fine. Does it have anything to do with long/slow renders?

@aleccaputo Do you have a reproduction we can have a look at?

import React, {useState} from 'react';
import {makeStyles} from '@material-ui/core';
import FormControl from '@material-ui/core/FormControl';
import InputLabel from '@material-ui/core/InputLabel';
import Select from '@material-ui/core/Select';
import MenuItem from '@material-ui/core/MenuItem';

const useStyles = makeStyles(() => ({
    select: {
        minWidth: 250
    }
}));

const Home = () => {
    const classes = useStyles();
    const [myThing, setMyThing] = useState('');
    const stuff = ['foo', 'bar', 'baz'];
    return (
        <FormControl
            className={classes.select}
            variant={'outlined'}
            style={{marginTop: '100px'}}
        >
            <InputLabel>
                {'My Stuff!'}
            </InputLabel>
            <Select
                onChange={e => setMyThing(e.target.value)}
                value={myThing}
                variant={'outlined'}
            >
                {
                    stuff.map(thing => (
                        <MenuItem value={thing}>
                            {thing}
                        </MenuItem>
                    ))
                }
            </Select>
        </FormControl>
    );
};

export default Home;

theme:
import error from '@material-ui/core/colors/red';

export const defaultTheme = {
    themeName: 'default',
    typography: {
        fontSize: 16,
        htmlFontSize: 16,
        fontFamily: '"proxima-nova"'
    },
    palette: {
        type: 'light',
        primary: {
            main: '#0C66C6'
        },
        secondary: {
            main: '#09919D'
        },
        error: {
            main: error['500']
        },
        background: {
            default: '#F0F3F5'
        }
    }
};

@aleccaputo It's expected, you need to manually measure the label width in this configuration. #17680 might rely 100% on CSS.

@oliviertassinari interesting, is it because i'm mapping over an array?

@aleccaputo No, it's because you need to measure the label width a provide this value to the select component, you can find an example in the demos, only the TextField does it for you.
If the effort in #17680 fail, we should push the documentation solution forward: https://github.com/mui-org/material-ui/issues/17305#issuecomment-527836886.

@oliviertassinari ahhhh got it, that makes sense. Thank you!

Option 2 really saved my day.

I had to explicitly set the label on the <Select> in addition to using the <InputLabel>
<FormControl variant="outlined">
  <InputLabel id="demo-simple-select-outlined-label">Age</InputLabel>
  <Select
    labelId="demo-simple-select-outlined-label"
    id="demo-simple-select-outlined"
    value=""
    onChange={() => {}}
    label="Age"    /* <==== Adding this fixed the issue for me */
  >
    <MenuItem value={10}>Ten</MenuItem>
    <MenuItem value={20}>Twenty</MenuItem>
    <MenuItem value={30}>Thirty</MenuItem>
  </Select>
</FormControl>

I had to explicitly set the label on the <Select> in addition to using the <InputLabel>
<FormControl variant="outlined">
  <InputLabel id="demo-simple-select-outlined-label">Age</InputLabel>
  <Select
    labelId="demo-simple-select-outlined-label"
    id="demo-simple-select-outlined"
    value=""
    onChange={() => {}}
    label="Age"    /* <==== Adding this fixed the issue for me */
  >
    <MenuItem value={10}>Ten</MenuItem>
    <MenuItem value={20}>Twenty</MenuItem>
    <MenuItem value={30}>Thirty</MenuItem>
  </Select>
</FormControl>

This is similar to the example in react material ui select example code. But it fails to work for me.
"@material-ui/core": "^4.12.3"


Unable to download stories by location id

When I combine %location id with --stories just download the recent posts from %location id but not stories.
Steps to reproduce the behavior:
instaloader --login *************** --password ***************  --stories  %locationID
instaloader --version
4.2.9

Duplicate of #367.
This is not a bug, it's just not implemented yet.


no output even with -debug option

I run below command in my repo:
 go-callvis -focus ./ -limit ./ -nostd -debug ./

But there were no output. I've already built this repo. Is this because that the repo is too large?
go-callvis has the highest cpu usage:

How long does it run like this? Does it ever finish? Try setting -focus=main.

The environment on my machine has been reset. I cannot reproduce it. Thanks for your reply.


rc.board_sensors: probe for external qmc5883

@copterspace can you test this please?
fixes https://github.com/PX4/Firmware/issues/11736

@copterspace can you test this please?
fixes #11736

I tested boards/px4/fmu-v4/init/rc.board_sensors  - because I have Pixracer and build px4_fmu-v4_default.
It starts, calibrates and flies OK.
Other boards - I do not have this hardware for test, but changes in code are the same, looks like it should work same good for other boards.
And perhaps also same line
qmc5883 -X start
should be added to https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v2/init/rc.board_sensors , because it has autostart for hmc5883, and does not yet have autostart for qmc5883

@dlwalter Hey, here is new PR about QMC5883. Is there anything you think need to add to this driver recently.
Thanks for your work!

It should probably be added to any board with external I2C.

airmind_mindpx-v2
auav_x21
av_x-v1
emlid_navio2
nxp_fmuk66-v3
omnibus_f4sd ?

Or we could look at centralizing startup for all the optional external peripherals.

Tested on Pixhawk v2 Cube:

Armed form QGC.
Took-off on mission plan mode
Note that commands were sent form QGC (Armed and takeoff)
Once all waypoint completed vehicle switched to RTL and landed as expected.
NOTE:Note: The vehicle, approximately half of a mission, left its trajectory and then resumed.

https://review.px4.io/plot_app?log=3db2eb24-bc22-40a1-a8a5-712e8b7577c0
Tested on PixRacer

Modes Tested
Position Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint see landing behavior.
Good flight in general.

https://review.px4.io/plot_app?log=acc6ce69-9182-4fd0-be56-2da1ed7cf310

Testing onPixhawk 4 v5   fail , successful upload firmware  not telemetry and USB connection not arming
https://youtu.be/sas88oGGJHg

@dannyfpv Your motor sounds pretty cool!

@Tony3dr I ran into a lot of issues with the v5 and an external compass where the whole system would lockup (looked like some kind of i2c collision between the external mag and the rgb_led).
For those having "PRIMARY COMPASS NOT FOUND" is the compass successfully starting up at boot? Can you try manually starting it with "qmc5883 -X start" over the Mavlink console?

@dlwalter, we loaded the PR then tried to enter the command "qmc5883-X start" on Mavlink console but it was unsuccessful, then we proceded to load Master and followed same steps on Mavlink console, the screenshot attached is from the response the console gave on Master.

@dannyfpv I just saw your video - doesn't that Holybro NEO GPS module have an IST8310 compass in it?  The qmc5883 -X start command wouldn't work in that case.

Yes, pixhawk4's GPS is using ist8310

Thanks for testing.

NOTE: It did not arm and a pop-up message that said PRIMARY COMPASS NOT FOUND.

@jorge789 I cannot reproduce. I have a cube with an external ist8310, which works. Can you attach the console and share the boot output? Also the output of sensors status? Which GPS and external mag are you using?
I rebased, can you try again?

Tested on Pixhawk2 Cube v3:
Modes Tested
Takeoff: Good
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.
Pre-flight Procedure:
Flash firmware through QGC ✓
Arm vehicle ✓
Calibrations ✓
Parameter check ✓
Flight Test:
Arm and Take off in position mode ✓
Throttle Test ✓
Pitch, Roll, Yaw ✓
Mode Switch ✓
RTL ✓
Notes:
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint turn off RC to trigger Failsafe RTL and see landing behavior.
NOTE:No Primary Comppas error found.
https://review.px4.io/plot_app?log=c76a2380-bb51-40bc-b9d3-ac8bb19c8851
Tested on Pixhawk 2 Cube v3
Modes Tested
Takeoff: Good
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.
Pre-flight Procedure:
Flash firmware through QGC ✓
Arm vehicle ✓
Calibrations ✓
Parameter check ✓
Flight Test:
Arm and Take off in position mode ✓
Throttle Test ✓
Pitch, Roll, Yaw ✓
Mode Switch ✓
RTL ✓
Notes:
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint turn off RC to trigger Failsafe RTL and see landing behavior.
NOTE:
Vehicle was tested previously 3 times and there was no issue, but once the 4th flight started, we had the following issues: During Failsafe RTL vehicle started descending in pauses, then once it hit the ground started jumping until disarmed form QGC.
https://review.px4.io/plot_app?log=e978fd57-594c-4b41-b8bb-7e8f6b178b51

During Failsafe RTL vehicle started descending in pauses, then once it hit the ground started jumping until disarmed form QGC.

@jorge789 these are in-air ground-contact detections. Can you set MPC_THR_HOVER correctly, and maybe increase MPC_Z_VEL_I (to something like 0.08)?
Merging, as the issue is unrelated.

then once it hit the ground started jumping until disarmed form QGC.

@jorge789 I've run into this issue when the autopilot isn't sufficiently isolated from wind/prop wash.  The prop wash near the ground causes the autopilot to not detect landing correctly - you can see the pressure change the barometer plots.
Often times you can get around this by setting EKF2_HGT_MODE to 1 (GPS) if you have a good GPS coverage.