Reduce memory allocation in rules and utils

Hello!
eslint-plugin-react is an amazing plugin - it catches so many problems that I consider it indispensable :)
Recently on a large-ish project I noticed some of the rules running relatively slowly, so I decided to see if I could speed them up.
In the end I was able to find quite a few opportunities to do less work, mainly by avoiding memory allocations.
I'd really appreciate any feedback on better ways to benchmark the plugin, and how safe these optimisations are.
They pass all the tests, though I appreciate it's not always possible to be 100% confident changes are correct, especially given the large number of changes here - luckily most of them are relatively localised.
I've tried to avoid changing the existing logic as much as possible, though sometimes speed has been picked over readability - I'd appreciate any thoughts on that too.
I've tried to make sure the changes will work on node 4, but that probably needs more thorough testing.
There's a list of the changes summarised at the bottom of this message. Thanks!

Benchmark results:
The project I benchmarked this against using cloc registers as about 550 files, with about 50k lines of code in .tsx files all containing React components.
The changes knock off about 70 - 100ms off the slowest rules, roughly 30% faster, with a sample result here:
Rule                                       | Time (ms) | Relative
:------------------------------------------|----------:|--------:
react/jsx-indent                           |   365.723 |     5.8%
react/no-deprecated                        |   296.861 |     4.7%
react/boolean-prop-naming                  |   286.611 |     4.6%
react/destructuring-assignment             |   283.235 |     4.5%
react/no-unstable-nested-components        |   172.198 |     2.7%
react/no-access-state-in-setstate          |   169.871 |     2.7%
react/jsx-no-bind                          |   161.568 |     2.6%
react/no-direct-mutation-state             |   155.857 |     2.5%
react/prefer-stateless-function            |   150.361 |     2.4%
react/display-name                         |   147.024 |     2.3%
react/no-string-refs                       |   144.832 |     2.3%
react/jsx-sort-props                       |   142.020 |     2.3%
react/no-typos                             |   141.018 |     2.2%
react/default-props-match-prop-types       |   140.545 |     2.2%
react/void-dom-elements-no-children        |   139.404 |     2.2%

to
Rule                                       | Time (ms) | Relative
:------------------------------------------|----------:|--------:
react/jsx-indent                           |   264.386 |     6.4%
react/boolean-prop-naming                  |   176.753 |     4.3%
react/destructuring-assignment             |   146.563 |     3.6%
react/jsx-sort-props                       |   142.513 |     3.5%
react/no-access-state-in-setstate          |   117.366 |     2.8%
react/no-deprecated                        |   109.879 |     2.7%
react/no-direct-mutation-state             |   107.110 |     2.6%
react/void-dom-elements-no-children        |    98.467 |     2.4%
react/display-name                         |    97.823 |     2.4%
react/no-unstable-nested-components        |    95.287 |     2.3%
react/jsx-no-bind                          |    94.966 |     2.3%
react/default-props-match-prop-types       |    92.893 |     2.3%
react/sort-comp                            |    91.416 |     2.2%
react/prefer-stateless-function            |    86.666 |     2.1%
react/no-typos                             |    84.784 |     2.1%

I used the following .eslintrc.js:
module.exports = {
  root: true,
  parser: "@typescript-eslint/parser",
  settings: {
    react: {
      pragma: "React",
      fragment: "Fragment",
      version: "detect",
    },
  },
  extends: ["plugin:react/all"],
}

with the versions:
    "eslint": "^7.25.0",
    "eslint-plugin-react": "^7.23.2",
    "@typescript-eslint/eslint-plugin": "^4.22.0",
    "@typescript-eslint/parser": "^4.22.0",

across the .tsx files in the project, 200 times by running:
$ script timings
$ for i in {1..200}; do TIMING=100 npx eslint . --ext tsx -o eslintlog; done

for both 7.23.2 and then with the lib directory swapped in from this branch.
I then averaged all 200 runs in this google sheet:
https://docs.google.com/spreadsheets/d/1Y5QZ_tsAyXrzgw5Rre21Gmzl95jT9irZmxfwSeF1oI0/edit?usp=sharing

Optimisations:

Avoid allocating empty objects or arrays when possible
Combine filter -> forEach chains
Replace Object.keys with values/entries where possible
Extract deeply nested functions to avoid reallocation
Push expensive operations below guards / early returns
Promote shared or mostly-constant conditionals
Swap compound boolean expressions to proriotise cheap short circuiting
Avoid dynamically generating RegExps when possible
Lazily initialise and cache complex objects and necessarily dynamic RegExps
Move expensive and shared calculations to higher scopes
Replace string splits and trims with RegExps
Avoid redundant array concatenations
Split expensive conditional checks across multiple guards
Move expensive booleans into conditional expressions to exploit short circuiting
Swap out filters for finds where possible
Turn arrays into objects/map/dictionary lookups where possible
Swap array function orders where safe and efficient
Cache string transformations

Codecov Report

Merging #2976 (249f085) into master (1185b37) will increase coverage by 0.00%.
The diff coverage is 98.63%.

@@           Coverage Diff           @@
##           master    #2976   +/-   ##
=======================================
  Coverage   97.59%   97.59%
=======================================
  Files         110      110
  Lines        7269     7365   +96
  Branches     2651     2693   +42
=======================================
+ Hits         7094     7188   +94
- Misses        175      177    +2

Impacted Files
Coverage Δ

lib/rules/jsx-indent.js
97.29% <87.50%> (-0.04%)
:arrow_down:

lib/rules/void-dom-elements-no-children.js
95.65% <90.00%> (+0.19%)
:arrow_up:

lib/rules/no-unknown-property.js
96.49% <90.90%> (-0.07%)
:arrow_down:

lib/rules/no-unused-prop-types.js
95.83% <94.44%> (+2.08%)
:arrow_up:

lib/util/version.js
96.96% <96.00%> (-0.79%)
:arrow_down:

lib/util/Components.js
98.55% <98.57%> (-0.32%)
:arrow_down:

lib/rules/boolean-prop-naming.js
99.28% <100.00%> (+0.01%)
:arrow_up:

lib/rules/default-props-match-prop-types.js
100.00% <100.00%> (ø)

lib/rules/destructuring-assignment.js
98.86% <100.00%> (ø)

lib/rules/display-name.js
98.16% <100.00%> (+0.05%)
:arrow_up:

... and 36 more

Continue to review full report at Codecov.

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

It might be easier to review if this was split up into a separate commit for each conceptual kind of change - since some of them are no-brainers (like the Object.keys -> values) and others are more of a tradeoff between clarity and performance.

Thanks for suggesting this - I've now split this PR into 12 commits, roughly across the kinds of changes made, or, if hard to disentangle, across the individual modules that have been modified.

@willheslam are you interested in continuing this effort? It seems like there's a number of comments to address, and a few potential PRs to land separately, plus this needs a rebase.

@ljharb Sorry for disappearing on this, work + life got in the way and I ran out of time.
Yeah - I've got some time this week so I'll take a look at the changes I've made to address the comments, changes pending, and what the rebase will entail.
I appreciate your following up on this!


When the url is undefined and the path parameter is present, the following error is reported

buildUrl(undefined, {
  path: "/api"
})

TypeError: Cannot read properties of undefined (reading 'length')

  49 |   lowerCase?: boolean
  50 | ) {
> 51 |   if (builtUrl[builtUrl.length - 1] === "/") {
     |                         ^
  52 |     builtUrl = builtUrl.slice(0, -1);
  53 |   }

fixed #209


bug: can't make the plugin work with a basic gradle project

Did you check docs and existing issues?

[X] I have read all the plugin docs
[X] I have searched the existing issues
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
0.10.1
Operating system/version
MacOS sonoma
Describe the bug
I can't make this work with a basic gradle project. I created the project running gradle init, then when i went to open the file in neovim i get the following

here's my lua config
return {
    {
        "nvim-java/nvim-java",
        config = false,
        dependencies = {
            "neovim/nvim-lspconfig",
            'nvim-java/lua-async-await',
            'nvim-java/nvim-java-core',
            'nvim-java/nvim-java-test',
            'nvim-java/nvim-java-dap',
            'MunifTanjim/nui.nvim',
        },
    },

    {
        "VonHeikemen/lsp-zero.nvim",
        ...
        config = function()
            ...
            require("mason").setup({})
            require('java').setup({
                root_markers = {
                    "settings.gradle",
                    "settings.gradle.kts",
                    "pom.xml",
                    "build.gradle",
                    "mvnw",
                    "gradlew",
                    "build.gradle",
                    "build.gradle.kts",
                },
            })
            require("mason-lspconfig").setup({
                handlers = {
                    lsp_zero.default_setup,
                },
            })
            require('lspconfig').lua_ls.setup({
                ...
            })
            require('lspconfig').jdtls.setup({
                # I already tried without this section, same result
                settings = {
                    java = {
                        configuration = {
                            runtimes = {
                                {
                                    name = "JavaSE-21",
                                    path = "/opt/homebrew/opt/openjdk@21",
                                    default = true,
                                }
                            }
                        }
                    }
                }

            })
            require('lspconfig').gopls.setup({
                ...
            })
        end,
    },
    ...
}

Surely something is misconfigured on my end, but can't figure it out :) the project itself can run via gradlew run.
Steps To Reproduce

mkdir test
cd test
gradle init and create an application
nvim app/src/main/ava/org/example/App.java

Expected Behavior
lsp ready to go, no errors, able to build the project and enter debugger.

Basic gradle project doesn't work for me either, but the error is different:
RPC[Error] code_name = MethodNotFound, message = "No delegateCommandHandler for vscode.java.resolveMainClass"

Looks like your mason configuration is not compatible with the expected. Those String cannot be resolved to a type errors are usually when the JDKs you have in the configuration does not match any required by the gradle project. For instance, if the gradle project require JDK 23 but in the configuration, you only have 21.
https://github.com/nvim-java/nvim-java/wiki/Q-&-A#no_entry-cannot-find-package-xxxxx
You can reopen if this is not fixed.


[NodeJS] EntityRecognizer.resolveTime() doesn't handle all LUIS placeholder dates & times

LUIS will return a date entity with a XXXX-06-27 when the user says something like "lets meet on june 27th". This indicates that they don't know the year and ultimately we want the EntityRecognizer.resolveTime() to convert this to 2016-06-27. Right now it just ignores the date when this happens. I need to add support to resolveTime() to deal with all of the various placeholder formats (there are a bunch) and write unit tests to test them all.
The tricky bit is for an utterance like "lets meet on june 27th" its obvious that the year should be 2016. But for an utterance like "I did that on june 27th" it's probably referring to 2015. LUIS has no clue which to do in this case otherwise it would do it. That's why it leaves it ambiguous in the first place. I'm leaning towards adding a flag that lets the developer control the resolving with "future", "past", "nearest", or "none". Open to suggestions.

There is another issue with datetime recognition. When LUIS return the following response e.g
"entities": [
{
"entity": "20 may 2016",
"type": "builtin.datetime",
"startIndex": 28,
"endIndex": 38,
"resolution": {
"date": "2016-05-20"
}
},
{
"entity": "22 may 2016",
"type": "builtin.datetime",
"startIndex": 45,
"endIndex": 55,
"resolution": {
"date": "2016-05-22"
}
},
{
"entity": "paris",
"type": "builtin.geography",
"startIndex": 17,
"endIndex": 21,
"score": 0.968967259
}
]
The type is 'builtin.datetime' and EntityRecognizer doesn't resolve the time. I assume that it expects 'builtin.datetime.date' type.

What do you get back in this case? I would have expected it to find the first one but not the second.

Line 105
  switch (entity.resolution.resolution_type || entity.type) {                     case 'builtin.datetime.date':                     case 'builtin.datetime.time':
If type is 'builtin.datetime' like in my case, then it would not be resolved.

I see... Have you tried adding an additional case statement directly to the JS of the module? Just curious if that fixes things. They may have changed the entity titles on us. I can look into this too but it may be a bit.

I've checked in a fix for this. Will be in the next release of the SDK coming out shortly.

Closing this issue.  Please open a new issue for further discussion if necessary.  Thanks!


Enhancement: Trim spaces from cluster token field

🔖 Feature description
When pasting the cluster bearer token the extra spaces should get trimmed automatically.
🎤 Pitch / Usecases
Due to extra spaces it throws an unauthorized error.
🔄 Alternative
No response
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

AB#9936

Fixed with attached PR


inner mapping options not respected

See the following jsfiddle for an example of this problem.
http://jsfiddle.net/jamesfoster/HwGgH/
If I have the following object:
function Record(data) {
    var self = this;

    ko.mapping.fromJS(data, {
        copy: ['id']
    }, self);
}

when calling ko.mapping.toJSON(record) everything works as expected, but when the object is wrapped in some other context the id propery is missing
var viewModel = { record: new Record(...) };

ko.mapping.toJSON(viewModel) // id property is missing
ko.mapping.toJSON(viewModel.record) // works

That's definitely odd. I'll take a look.

my solution was to add the following code inside ko.mapping.visitModel:
		visitPropertiesOrArrayEntries(unwrappedRootObject, function (indexer) {
			var currentOptions = options;

			var mappingObject = unwrappedRootObject[mappingProperty];
			if(mappingObject) {
				currentOptions = ko.utils.extend({}, options); // clone
				currentOptions = ko.utils.extend(currentOptions, mappingObject);
			}

then use currentOptions instead of options. This way, if the object was mapped with fromJS, the options passed in will used when unmapping.
I'm unsure about the clone tho... Should it just use the original options?

That looks good, but I have one question: Why are you merging the currentOptions with the original options instead of just taking them directly from mappingObject?

That was my question at the end there. Merging seemed in keeping with how it works currently. I would actually prefer it to take the options directly from the mapping object!

I'm sorry, I thought you were explicitly asking about why you needed to clone. Merging of options is currently only used when you provide options to ko.mapping.fromJS with an already mapped object. Doing a ko.mapping.toJS shouldn't merge any options, I don't think.
Can you maybe elaborate a bit on why you thought this was the case? Perhaps I'm overlooking something.

Would you be willing to create a pull request with the changes to knockout.mapping.js and make sure all the unit tests still pass?

Of course, I'll get this done today.

Thanks a lot :)

I'm still very new to the knockout.mapping codebase so even if it
passes test cases it might be a good idea to give it a once over,
doesn't look very complicated though.
On Tue, Feb 14, 2012 at 11:18 AM, Roy Jacobs
<EMAIL_ADDRESS>wrote:

Thanks a lot :)

Reply to this email directly or view it on GitHub:
https://github.com/SteveSanderson/knockout.mapping/issues/45#issuecomment-3964048

It seems fine, as far as I can tell. @jamesfoster can you confirm?

No. This solution is not correct! The inner options should cascade down.
I apologise for not replying earlier. Been rather busy.
So... change this line to pass in currentOptions
https://github.com/bryansquared/knockout.mapping/blob/ba783435d322276ab91b2cbcef60512bef11ddbc/knockout.mapping.js#L646
Also, from the discussion above I would also change this line ...
https://github.com/bryansquared/knockout.mapping/blob/ba783435d322276ab91b2cbcef60512bef11ddbc/knockout.mapping.js#L621
... to currentOptions = fillOptions(mappingObject); so that we aren't merging options from the parent context!
Here's a test to prove cascading.
test('inner mapping options should cascade down', function() {
  var obj = {
    name: "Lorem ipsum",
    items: [{name: 'soup', type:{name: 'food'}},{name: 'rock', type:{name: 'mineral'}}]
  };

  var mapping = {
    ignore: ['name'],
    items: {
      create: function(options) {
        return ko.mapping.fromJS(options.data, {copy: ['name']});
      }
    }
  }

  a = ko.mapping.fromJS(obj, mapping);
  b = ko.mapping.toJS(a);

  equal(a.name, undefined);
  equal(a.items()[0].name,'soup');
  equal(a.items()[0].type().name,'food');
  equal(a.items()[1].name,'rock');
  equal(a.items()[1].type().name,'mineral');
  equal(b.items[0].name,'soup');
  equal(b.items[0].type.name,'food');
  equal(b.items[1].name,'rock');
  equal(b.items[1].type.name,'mineral');
});

Currently, assertion 7 and 9 will fail because it will be ignoring the name property on grandchildren.

Excellent, I'll make these changes now and submit another pull request
On Tue, Feb 14, 2012 at 6:25 PM, James Foster
<EMAIL_ADDRESS>wrote:

No. This solution is not correct! The inner options should cascade down.
I apologise for not replying earlier. Been rather busy.
So... change this line to pass in currentOptions
https://github.com/bryansquared/knockout.mapping/blob/ba783435d322276ab91b2cbcef60512bef11ddbc/knockout.mapping.js#L646
Also, from the discussion above I would also change this line ...
https://github.com/bryansquared/knockout.mapping/blob/ba783435d322276ab91b2cbcef60512bef11ddbc/knockout.mapping.js#L621
... to currentOptions = fillOptions(mappingObject); so that we aren't merging options from the parent context!
Here's a test to prove cascading.
test('inner mapping options should cascade down', function() {
 var obj = {
   name: "Lorem ipsum",
   items: [{name: 'soup', type:{name: 'food'}},{name: 'rock', type:{name: 'mineral'}}]
 };

 var mapping = {
   ignore: ['name'],
   items: {
     create: function(options) {
       return ko.mapping.fromJS(options.data, {copy: ['name']});
     }
   }
 }

 a = ko.mapping.fromJS(obj, mapping);
 b = ko.mapping.toJS(a);

 equal(a.name, undefined);
 equal(a.items()[0].name,'soup');
 equal(a.items()[0].type().name,'food');
 equal(a.items()[1].name,'rock');
 equal(a.items()[1].type().name,'mineral');
 equal(b.items[0].name,'soup');
 equal(b.items[0].type.name,'food');
 equal(b.items[1].name,'rock');
 equal(b.items[1].type.name,'mineral');
});

Currently, assertion 7 and 9 will fail because it will be ignoring the name property on grandchildren.

Reply to this email directly or view it on GitHub:
https://github.com/SteveSanderson/knockout.mapping/issues/45#issuecomment-3971905

Implementing these changes had a few unintended consequences:
Mapping: ko.mapping.fromJS should copy specified single property, also when going back .toJS, except when overridden
Mapping: ko.mapping.toJS should include specified single property
Mapping: ko.mapping.toJS should merge the default includes
Mapping: ko.mapping.toJS should merge the default ignores
If you would please advise, I will try to finish the changes.

Ok. this is due to not copying the options from the parent. Which I believe is the correct approach, do you agree @RoyJacobs?
The way to solve this is to pass the overridding options into visitModel and apply them at every level of the hierarchy
Line 131:
		// Merge in the options used in fromJS
		options = fillOptions(options, rootObject[mappingProperty]);

		// We just unwrap everything at every level in the object graph
		return ko.mapping.visitModel(rootObject, function (x) {
			return ko.utils.unwrapObservable(x)
		}, options);

		// Clone the options used in fromJS
		var newOptions = fillOptions({}, rootObject[mappingProperty]);

		// We just unwrap everything at every level in the object graph
		return ko.mapping.visitModel(rootObject, function (x) {
			return ko.utils.unwrapObservable(x)
		}, newOptions, options);

Line 596:
	ko.mapping.visitModel = function (rootObject, callback, options) {

	ko.mapping.visitModel = function (rootObject, callback, options, overridingOptions) {

Line 620:
			if (mappingObject) {
				currentOptions = fillOptions(mappingObject,options);
			}

			if (mappingObject) {
				currentOptions = ko.utils.extend({}, overridingOptions);
				currentOptions = fillOptions(currentOptions, mappingObject);
			}

The clone here is necessary to ensure overridingOptions is unchanged. Note that fillOptions will alter the first argument.
Hopefully this solves the issue.

The options that are specified at the root level should be passed along, yes. @bryansquared is James' explanation sufficient for you?


S3:get_object() - Simple BucketPolicy validation

Ideally we extend this to all actions (Get/Put/Etc), and move validation to a single place - for now we'll just validate GetObject to verify it works as expected.
Fixes #2892

Codecov Report

Merging #5476 (f0cc059) into master (bb540f6) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Current head f0cc059 differs from pull request most recent head f6bf1c8. Consider uploading reports for the commit f6bf1c8 to get more accurate results

@@           Coverage Diff           @@
##           master    #5476   +/-   ##
=======================================
  Coverage   96.10%   96.10%
=======================================
  Files         724      724
  Lines       72000    72059   +59
=======================================
+ Hits        69192    69252   +60
+ Misses       2808     2807    -1

Flag
Coverage Δ

servertests
37.10% <90.00%> (+0.23%)
:arrow_up:

unittests
96.04% <100.00%> (+<0.01%)
:arrow_up:

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

Impacted Files
Coverage Δ

moto/iam/access_control.py
97.56% <100.00%> (+<0.01%)
:arrow_up:

moto/moto_server/threaded_moto_server.py
100.00% <100.00%> (ø)

moto/s3/models.py
96.18% <100.00%> (+0.02%)
:arrow_up:

moto/s3/responses.py
95.63% <100.00%> (+0.01%)
:arrow_up:

moto/ec2/utils.py
93.63% <0.00%> (ø)

moto/rds/models.py
94.00% <0.00%> (ø)

moto/apigatewayv2/responses.py
100.00% <0.00%> (ø)

moto/ec2/models/launch_templates.py
100.00% <0.00%> (ø)

moto/apigatewayv2/models.py
98.17% <0.00%> (+<0.01%)
:arrow_up:

moto/cognitoidp/models.py
95.43% <0.00%> (+<0.01%)
:arrow_up:

... and 2 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Jetstream will be supported in v4.

          Jetstream will be supported in v4.

Originally posted by @stancl in https://github.com/archtechx/tenancy/issues/549#issuecomment-1359967385
Hello @stancl, has there been any improvement in integrating jetstream with the library, I have an existing project that am trying to add tenancy but I cant be able to login in tenant roots.
Kindly assist.

@stancl is there any way I can be able to go around the auth process? I am unable to log in and also I am not able to utilize the auth facade in Laravel.
Members any solution around this?

Use the right channels for support questions. Updates about v4 are posted on Discord.


Updating README files and fixing minor issues in MB module

This p/r is to:

update README files to disable kubernets proxy port in default yaml file
fixing minor issues in MB module

Thanks! This is merged now.


Wrong image loaded

We have been using the library for some time, and we occasionally get reports from users where they get stuck in a state where avatars are displayed for incorrect users. The issue is persisted across app and phone restarts as well. AFAIK, we are doing nothing out of the ordinary.

My somewhat educated guess is that this sounds like UUID collision. Do you have a sample app that demonstrates the problem?

I had exactly the same problem, and it was UUID collision. I copied the proper UUID generation code from the demo app and it fixed the problem.


Remove TODOs from README

Could probably use some more :heart:, but for now, this removes the TODOs.

LGTM.


Feature/dev 5286a

Briefly describe your changes
Added vertical sort legend option for Bars & Map
Checklist before requesting a review

[x] My pull request was branched from and targets the test branch
[x] I have performed a self-review of my code
[x] I have manually tested all packages affected (bonus points for automations)
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have checked to ensure there aren't other open pull requests for the same change

Did you test your feature in the following environments?

[x] Standalone Component
[x] Standalone Full Editor
[ ] CDC Internal Checks

Cherry picked commits to base off of integration here:
https://github.com/CDCgov/cdc-open-viz/pull/827


Invoking "make -j12 -l12" failed

Describe the bug
A clear and concise description of what the bug is.
I cannot catkin_make. There is an error. How can I fix this?
To Reproduce
Steps to reproduce the behavior:
I git cloned using SSH and added --recursive  option ofcourse.
But when I do "catkin_make -DCMAKE_BUILD_TYPE=Release", Invoking "make -j12 -l12" failed
will be showed.
Expected behavior
Succecfully catkin_make.
Screenshots

System specs (please complete the following information):
Please look at screeshots
Additional context
Add any other context about the problem here.
[ 46%] Built target darknet_ros_msgs_generate_messages
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
In file included from /usr/include/cuda_runtime.h:83,
from :
/usr/include/crt/host_config.h:138:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
138 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
|  ^~~~~
CMake Error at darknet_ros_lib_generated_blas_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/__/darknet/src/./darknet_ros_lib_generated_blas_kernels.cu.o
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:105: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_blas_kernels.cu.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CMake Error at darknet_ros_lib_generated_crop_layer_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/./darknet_ros_lib_generated_crop_layer_kernels.cu.o
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:84: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_crop_layer_kernels.cu.o] Error 1
CMake Error at darknet_ros_lib_generated_im2col_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/./darknet_ros_lib_generated_im2col_kernels.cu.o
CMake Error at darknet_ros_lib_generated_maxpool_layer_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/__/darknet/src/./darknet_ros_lib_generated_maxpool_layer_kernels.cu.o
CMake Error at darknet_ros_lib_generated_activation_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/__/darknet/src/./darknet_ros_lib_generated_activation_kernels.cu.o
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:126: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_im2col_kernels.cu.o] Error 1
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:140: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_maxpool_layer_kernels.cu.o] Error 1
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:77: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_activation_kernels.cu.o] Error 1
CMake Error at darknet_ros_lib_generated_dropout_layer_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/./darknet_ros_lib_generated_dropout_layer_kernels.cu.o
CMake Error at darknet_ros_lib_generated_deconvolutional_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/__/darknet/src/./darknet_ros_lib_generated_deconvolutional_kernels.cu.o
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:98: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_deconvolutional_kernels.cu.o] Error 1
CMake Error at darknet_ros_lib_generated_col2im_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/./darknet_ros_lib_generated_col2im_kernels.cu.o
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:112: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_dropout_layer_kernels.cu.o] Error 1
CMake Error at darknet_ros_lib_generated_convolutional_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/./darknet_ros_lib_generated_convolutional_kernels.cu.o
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:119: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_col2im_kernels.cu.o] Error 1
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:133: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir//darknet/src/darknet_ros_lib_generated_convolutional_kernels.cu.o] Error 1
CMake Error at darknet_ros_lib_generated_avgpool_layer_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/__/darknet/src/./darknet_ros_lib_generated_avgpool_layer_kernels.cu.o
make[2]: *** [darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/build.make:91: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/__/darknet/src/darknet_ros_lib_generated_avgpool_layer_kernels.cu.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2505: darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
Invoking "make -j12 -l12" failed

Does anyone know how to fix this?

Did you clone recursively the latest release?
Did CMake output any errors?
What's your CMake version cmake --version.

Yes of course I did git clone recursively with the latest one.

The CMake errors are mainly 2 kinds.
①
#error -- unsupported GNU version! gcc versions later than 8 are not supported!
②
「CMake Error at darknet_ros_lib_generated_avgpool_layer_kernels.cu.o.Release.cmake:220 (message):
Error generating
/home/konno/catkin_ws/build/darknet_ros/darknet_ros/CMakeFiles/darknet_ros_lib.dir/__/darknet/src/./darknet_ros_lib_generated_avgpool_layer_kernels.cu.o」

Also I tried this command and tried to install all of the dependencies but I could not install it.

sudo rosdep install -yr --from-paths

I installed cuda 11.3 but still cannot catkin_make.
I could not 10.2 on Ubuntu20.04 because it was not available. There were no options for 20.04. Only for 18.04 and 16.04.

Actually I have already downloaded darknet from the original site and it is located right next to my catkin_ws in home directory as you can see the screenshot. Is this causing conflicts with your darknet on ROS?

If these directories are not actually in your workspace you should be fine.
If your workspace is catkin_ws, then the workspace source is in catkin_ws/src.
This is strange. Looks like it has to do with your CUDA setup.
You might want to retry in a Docker container so that you have a clean and clear starting point.

您是否递归克隆了最新版本？ CMake 是否输出任何错误？ 你的 CMake 版本是什么cmake --version。

Base path: /home/yangq871/catkin_ws
Source space: /home/yangq871/catkin_ws/src
Build space: /home/yangq871/catkin_ws/build
Devel space: /home/yangq871/catkin_ws/devel
Install space: /home/yangq871/catkin_ws/install

Running command: "make cmake_check_build_system" in "/home/yangq871/catkin_ws/build"

Running command: "make -j12 -l12" in "/home/yangq871/catkin_ws/build"

[  0%] Built target std_msgs_generate_messages_cpp
[  0%] Built target actionlib_msgs_generate_messages_cpp
[  0%] Built target sensor_msgs_generate_messages_cpp
[  0%] Built target geometry_msgs_generate_messages_cpp
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsFeedback
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_ObjectCount
[  0%] Built target std_msgs_generate_messages_py
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionResult
[  0%] Built target actionlib_msgs_generate_messages_py
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBox
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsAction
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBoxes
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionFeedback
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsGoal
[  0%] Built target sensor_msgs_generate_messages_py
[  0%] Built target actionlib_msgs_generate_messages_nodejs
[  0%] Built target geometry_msgs_generate_messages_py
[  0%] Built target std_msgs_generate_messages_nodejs
[  0%] Built target geometry_msgs_generate_messages_nodejs
[  0%] Built target sensor_msgs_generate_messages_nodejs
[  0%] Built target geometry_msgs_generate_messages_lisp
[  0%] Built target actionlib_msgs_generate_messages_lisp
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionGoal
[  0%] Built target sensor_msgs_generate_messages_lisp
[  0%] Built target std_msgs_generate_messages_lisp
[  0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsResult
[  0%] Built target geometry_msgs_generate_messages_eus
[  0%] Built target sensor_msgs_generate_messages_eus
[  0%] Built target std_msgs_generate_messages_eus
[  0%] Built target actionlib_msgs_generate_messages_eus
[ 24%] Built target darknet_ros_msgs_generate_messages_lisp
[ 24%] Built target darknet_ros_msgs_generate_messages_cpp
[ 24%] Built target darknet_ros_msgs_generate_messages_py
[ 32%] Built target darknet_ros_msgs_generate_messages_nodejs
[ 40%] Built target darknet_ros_msgs_generate_messages_eus
[ 40%] Built target darknet_ros_msgs_generate_messages
[ 97%] Built target darknet_ros_lib
[100%] Built target darknet_ros_nodelet
[100%] Linking CXX executable /home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros
/usr/bin/x86_64-linux-gnu-ld: CMakeFiles/darknet_ros.dir/src/yolo_object_detector_node.cpp.o: relocation R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: 最后的链结失败: 输出不可表示的节
collect2: error: ld returned 1 exit status
darknet/darknet_ros/CMakeFiles/darknet_ros.dir/build.make:192: recipe for target '/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros' failed
make[2]: *** [/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros] Error 1
CMakeFiles/Makefile2:2975: recipe for target 'darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all' failed
make[1]: *** [darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j12 -l12" failed
please help me，Thank you
why  catkin_make 100% does  have error?
g++-6.5，gcc-6.5  ，opencv-4.0，

您是否递归克隆了最新版本？ CMake 是否输出任何错误？ 你的 CMake 版本是什么cmake --version。

Base path: /home/yangq871/catkin_ws Source space: /home/yangq871/catkin_ws/src Build space: /home/yangq871/catkin_ws/build Devel space: /home/yangq871/catkin_ws/devel Install space: /home/yangq871/catkin_ws/install
Running command: "make cmake_check_build_system" in "/home/yangq871/catkin_ws/build"
Running command: "make -j12 -l12" in "/home/yangq871/catkin_ws/build"
[ 0%] Built target std_msgs_generate_messages_cpp [ 0%] Built target actionlib_msgs_generate_messages_cpp [ 0%] Built target sensor_msgs_generate_messages_cpp [ 0%] Built target geometry_msgs_generate_messages_cpp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsFeedback [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_ObjectCount [ 0%] Built target std_msgs_generate_messages_py [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionResult [ 0%] Built target actionlib_msgs_generate_messages_py [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBox [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsAction [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBoxes [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionFeedback [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsGoal [ 0%] Built target sensor_msgs_generate_messages_py [ 0%] Built target actionlib_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_py [ 0%] Built target std_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_nodejs [ 0%] Built target sensor_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_lisp [ 0%] Built target actionlib_msgs_generate_messages_lisp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionGoal [ 0%] Built target sensor_msgs_generate_messages_lisp [ 0%] Built target std_msgs_generate_messages_lisp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsResult [ 0%] Built target geometry_msgs_generate_messages_eus [ 0%] Built target sensor_msgs_generate_messages_eus [ 0%] Built target std_msgs_generate_messages_eus [ 0%] Built target actionlib_msgs_generate_messages_eus [ 24%] Built target darknet_ros_msgs_generate_messages_lisp [ 24%] Built target darknet_ros_msgs_generate_messages_cpp [ 24%] Built target darknet_ros_msgs_generate_messages_py [ 32%] Built target darknet_ros_msgs_generate_messages_nodejs [ 40%] Built target darknet_ros_msgs_generate_messages_eus [ 40%] Built target darknet_ros_msgs_generate_messages [ 97%] Built target darknet_ros_lib [100%] Built target darknet_ros_nodelet [100%] Linking CXX executable /home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros /usr/bin/x86_64-linux-gnu-ld: CMakeFiles/darknet_ros.dir/src/yolo_object_detector_node.cpp.o: relocation R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: 最后的链结失败: 输出不可表示的节 collect2: error: ld returned 1 exit status darknet/darknet_ros/CMakeFiles/darknet_ros.dir/build.make:192: recipe for target '/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros' failed make[2]: *** [/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros] Error 1 CMakeFiles/Makefile2:2975: recipe for target 'darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all' failed make[1]: *** [darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2 Invoking "make -j12 -l12" failed
please help me，Thank you why catkin_make 100% does have error? g++-6.5，gcc-6.5 ，opencv-4.0，

were you able to solve it?

I  have dealed with  this problem
---Original---
From: "Hamdy @.>
Date: Sun, Oct 29, 2023 14:07 PM
To: @.>;
Cc<EMAIL_ADDRESS>Subject: Re: [leggedrobotics/darknet_ros] Invoking "make -j12 -l12" failed(#326)
您是否递归克隆了最新版本？ CMake 是否输出任何错误？ 你的 CMake 版本是什么cmake --version。
Base path: /home/yangq871/catkin_ws Source space: /home/yangq871/catkin_ws/src Build space: /home/yangq871/catkin_ws/build Devel space: /home/yangq871/catkin_ws/devel Install space: /home/yangq871/catkin_ws/install
Running command: "make cmake_check_build_system" in "/home/yangq871/catkin_ws/build"
Running command: "make -j12 -l12" in "/home/yangq871/catkin_ws/build"
[ 0%] Built target std_msgs_generate_messages_cpp [ 0%] Built target actionlib_msgs_generate_messages_cpp [ 0%] Built target sensor_msgs_generate_messages_cpp [ 0%] Built target geometry_msgs_generate_messages_cpp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsFeedback [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_ObjectCount [ 0%] Built target std_msgs_generate_messages_py [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionResult [ 0%] Built target actionlib_msgs_generate_messages_py [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBox [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsAction [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBoxes [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionFeedback [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsGoal [ 0%] Built target sensor_msgs_generate_messages_py [ 0%] Built target actionlib_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_py [ 0%] Built target std_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_nodejs [ 0%] Built target sensor_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_lisp [ 0%] Built target actionlib_msgs_generate_messages_lisp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionGoal [ 0%] Built target sensor_msgs_generate_messages_lisp [ 0%] Built target std_msgs_generate_messages_lisp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsResult [ 0%] Built target geometry_msgs_generate_messages_eus [ 0%] Built target sensor_msgs_generate_messages_eus [ 0%] Built target std_msgs_generate_messages_eus [ 0%] Built target actionlib_msgs_generate_messages_eus [ 24%] Built target darknet_ros_msgs_generate_messages_lisp [ 24%] Built target darknet_ros_msgs_generate_messages_cpp [ 24%] Built target darknet_ros_msgs_generate_messages_py [ 32%] Built target darknet_ros_msgs_generate_messages_nodejs [ 40%] Built target darknet_ros_msgs_generate_messages_eus [ 40%] Built target darknet_ros_msgs_generate_messages [ 97%] Built target darknet_ros_lib [100%] Built target darknet_ros_nodelet [100%] Linking CXX executable /home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros /usr/bin/x86_64-linux-gnu-ld: CMakeFiles/darknet_ros.dir/src/yolo_object_detector_node.cpp.o: relocation R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: 最后的链结失败: 输出不可表示的节 collect2: error: ld returned 1 exit status darknet/darknet_ros/CMakeFiles/darknet_ros.dir/build.make:192: recipe for target '/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros' failed make[2]: *** [/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros] Error 1 CMakeFiles/Makefile2:2975: recipe for target 'darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all' failed make[1]: *** [darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2 Invoking "make -j12 -l12" failed
please help me，Thank you why catkin_make 100% does have error? g++-6.5，gcc-6.5 ，opencv-4.0，
were you able to solve it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

thank you for your response
---Original---
From: "Hamdy @.>
Date: Sun, Oct 29, 2023 14:07 PM
To: @.>;
Cc<EMAIL_ADDRESS>Subject: Re: [leggedrobotics/darknet_ros] Invoking "make -j12 -l12" failed(#326)
您是否递归克隆了最新版本？ CMake 是否输出任何错误？ 你的 CMake 版本是什么cmake --version。
Base path: /home/yangq871/catkin_ws Source space: /home/yangq871/catkin_ws/src Build space: /home/yangq871/catkin_ws/build Devel space: /home/yangq871/catkin_ws/devel Install space: /home/yangq871/catkin_ws/install
Running command: "make cmake_check_build_system" in "/home/yangq871/catkin_ws/build"
Running command: "make -j12 -l12" in "/home/yangq871/catkin_ws/build"
[ 0%] Built target std_msgs_generate_messages_cpp [ 0%] Built target actionlib_msgs_generate_messages_cpp [ 0%] Built target sensor_msgs_generate_messages_cpp [ 0%] Built target geometry_msgs_generate_messages_cpp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsFeedback [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_ObjectCount [ 0%] Built target std_msgs_generate_messages_py [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionResult [ 0%] Built target actionlib_msgs_generate_messages_py [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBox [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsAction [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_BoundingBoxes [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionFeedback [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsGoal [ 0%] Built target sensor_msgs_generate_messages_py [ 0%] Built target actionlib_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_py [ 0%] Built target std_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_nodejs [ 0%] Built target sensor_msgs_generate_messages_nodejs [ 0%] Built target geometry_msgs_generate_messages_lisp [ 0%] Built target actionlib_msgs_generate_messages_lisp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsActionGoal [ 0%] Built target sensor_msgs_generate_messages_lisp [ 0%] Built target std_msgs_generate_messages_lisp [ 0%] Built target _darknet_ros_msgs_generate_messages_check_deps_CheckForObjectsResult [ 0%] Built target geometry_msgs_generate_messages_eus [ 0%] Built target sensor_msgs_generate_messages_eus [ 0%] Built target std_msgs_generate_messages_eus [ 0%] Built target actionlib_msgs_generate_messages_eus [ 24%] Built target darknet_ros_msgs_generate_messages_lisp [ 24%] Built target darknet_ros_msgs_generate_messages_cpp [ 24%] Built target darknet_ros_msgs_generate_messages_py [ 32%] Built target darknet_ros_msgs_generate_messages_nodejs [ 40%] Built target darknet_ros_msgs_generate_messages_eus [ 40%] Built target darknet_ros_msgs_generate_messages [ 97%] Built target darknet_ros_lib [100%] Built target darknet_ros_nodelet [100%] Linking CXX executable /home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros /usr/bin/x86_64-linux-gnu-ld: CMakeFiles/darknet_ros.dir/src/yolo_object_detector_node.cpp.o: relocation R_X86_64_32 against symbol `__pthread_key_create@@GLIBC_2.2.5' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: 最后的链结失败: 输出不可表示的节 collect2: error: ld returned 1 exit status darknet/darknet_ros/CMakeFiles/darknet_ros.dir/build.make:192: recipe for target '/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros' failed make[2]: *** [/home/yangq871/catkin_ws/devel/lib/darknet_ros/darknet_ros] Error 1 CMakeFiles/Makefile2:2975: recipe for target 'darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all' failed make[1]: *** [darknet/darknet_ros/CMakeFiles/darknet_ros.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2 Invoking "make -j12 -l12" failed
please help me，Thank you why catkin_make 100% does have error? g++-6.5，gcc-6.5 ，opencv-4.0，
were you able to solve it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>


More fixes around special values in graphs.

Theabove patch still doesn't quite work for the console. This fixes it: http://pastie.org/10035734

@leonerd Thanks, done! Now I see that everywhere else, the code gets around the this problem in functions by binding it via .bind(this) or .bind(this, ...). I think all those other sites should also be changed to use self, but I don't want to make such a large change in this PR now, because I'm afraid I might break things.

(see also https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)


How is the vehicle driving automatically?

Hi，
How is the vehicle driving automatically?How to use the XODR file generated from the Roadrunner software, I want to find the relevant function, thank you.

I am stealing this answer that @marcgpuig gave on Discord:
"[the autonomous model in server side] is a really simple one and it's generated from an opendrive file. On the start of each (opendrive) road, we place a trigger box that contains an array of positions along the road. When a car hits one of these trigger boxes, it starts following these points in order, until it collides with another trigger box. For the traffic lights and stops, we have more triggers that just stop the car until something in the world changes the state of the trigger box, then the car can continue. All the cars have a set of raycast pointing the direction that they are going, these will tell the car if it has another vehicle in front (for cars stopping because other cars are stopped by, for instance, a traffic light)."

Your information is very useful, then I try to find out where trigger boxes are, thank you.

Your information is very useful, then I try to find out where trigger boxes are, thank you.


Build error

Hi Shubham,
I got the following error while trying to build the code by running " ./Build_all.sh"
./Build_all.sh: line 8: cd: Scripts_main: No such file or directory
chmod: cannot access 'Requirements_install.sh': No such file or directory
sudo: ./requirements_install.sh: command not found
script_edit_6: Pulling from saddie/confuzzius
Digest: sha256:a96a004069833ae2b3bcecde2061f039f76031ffb95298f006307065e6509418
Status: Image is up to date for saddie/confuzzius:script_edit_6
docker.io/saddie/confuzzius:script_edit_6
script_edit_6: Pulling from saddie/ilf
Digest: sha256:19826784b4e2fb5a9c25079b7b52b5760f451caab7683f022d18a59280d90ee9
Status: Image is up to date for saddie/ilf:script_edit_6
docker.io/saddie/ilf:script_edit_6
invalid reference format: repository name must be lowercase
Could you please take a look? I tested the command on Ubuntu 18.04.
Thanks.

Hi Thuan, I have fixed the issue from my side and have tested it on a fresh installation of Ubuntu 18.04. Please have a look.
Thanks

The build is successful now but I get this error while running "./exec_file.sh $PFBENCH Confuzzius 3"
CONFUZZIUS: Fuzzing in progress ...
CONFUZZIUS: Waiting for the following containers to stop:  7a53b2e38263 c2c82d30d4bf ae753ac0cfd2Collecting results and performing necessary operations ..... Traceback (most recent call last):
File "/home/ubuntu/Smart_contract_fuzzing/Scripts_main/Result_present.py", line 223, in
plt.show()
File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 254, in show
return _show(*args, **kw)
File "/usr/lib/python3/dist-packages/matplotlib/backend_bases.py", line 218, in show
cls.mainloop()
File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py", line 1078, in mainloop
Tk.mainloop()
File "/usr/lib/python3.6/tkinter/init.py", line 560, in mainloop
_default_root.tk.mainloop(n)
KeyboardInterrupt
Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe


nearest neighbor :queen no longer goes out of bounds

What the pull request does
Explain in a few words what the pull request does.
Type of change
Please indicate the relevant option(s)

[x] :bug: Bug fix (non-breaking change which fixes an issue)
[ ] :sparkle: New feature (non-breaking change which adds functionality)
[ ] :boom: Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] :book: This change requires a documentation update

Checklist

[ ] The changes are documented

[ ] The docstrings of the different functions describe the arguments, purpose, and behavior
[ ] There are examples in the documentation website

[ ] The changes are tested
[ ] The changes do not modify the behavior of the previously existing functions

If they do, please explain why and how in the introduction paragraph

[ ] For new contributors - my name and information are added to .zenodo.json
[ ] The Project.toml field version has been updated

Change the last number for a v0.0.x series release, a bug fix, or a performance improvement
Change the middle number for additional features that do not break the current test suite (unless you fix a bug in the test suite)
Change the first number for changes that break the current test suite

Codecov Report

Merging #54 (b126fbb) into main (8b84f18) will increase coverage by 1.39%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #54      +/-   ##
==========================================
+ Coverage   61.56%   62.96%   +1.39%
==========================================
  Files          14       14
  Lines         268      297      +29
==========================================
+ Hits          165      187      +22
- Misses        103      110       +7

Flag
Coverage Δ

unittests
62.96% <0.00%> (+1.39%)
:arrow_up:

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

Impacted Files
Coverage Δ

src/classify.jl
0.00% <0.00%> (ø)

src/algorithms/wavesurface.jl
100.00% <0.00%> (ø)

src/algorithms/edgegradient.jl
100.00% <0.00%> (ø)

src/algorithms/diamondsquare.jl
100.00% <0.00%> (ø)

src/algorithms/planargradient.jl
100.00% <0.00%> (ø)

src/algorithms/rectangularcluster.jl
100.00% <0.00%> (ø)

src/algorithms/nnelement.jl
95.00% <0.00%> (+0.55%)
:arrow_up:

src/algorithms/perlinnoise.jl
90.32% <0.00%> (+0.66%)
:arrow_up:

src/landscape.jl
93.33% <0.00%> (+2.42%)
:arrow_up:

Continue to review full report at Codecov.

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

@gottacatchenall I've updated the release number, you can merge when all the tests pass - do you know how to tag the new release using the bot?

do i just make a new release? doesn't look like i can run the tagbot workflow


feat: implement xpack security user api

Implements:

Create/Update User
Delete User
Get User
Disable User
Enable User

refs #1113

Looking great. Thank you! Will merge in 7.0.8.

I changed a few things like aligning strongly to the REST API Spec, keeping names the same everywhere (e.g. Username), and adding missing common options.

@olivere would you accept a PR backporting this to v6?


Traffic Portal doesn't restart using systemctl

If you restart using systemctl, the process spawns a new daemon but never kills the old one, resulting in multiple process running and logs filing up with EADDRINUSE.
It also doesn't stop/start using systemctl. Which causes problem on a Centos 7 and the Ansible "service" module.

I guess I always do it like:
sudo service traffic_portal start/stop/restart/status


subctl: globalnet support for join

Check for Overlapping CIDRs only if globalnet not enabled
Allocate globalCIDR to cluster if available
Update the spec with globalCIDR
Add Makefile and e2e flags to support globalnet
e2e: GlobalCIDR validations if globalnet enabled.

@vthapar I think this PR can be closed right as the changes were merged as part of a different PR.


User Insert ID not retrievable if  create method ($activation = true)

When using the create/register method if the activation parameter = true then the activation hash is returned and the insert_id of the user can no longer be retrieved.
sentry/user.php line 224
if ($activation)
{
    return ($rows_affected > 0) ? base64_encode($user[$this->login_column]).'/'.$hash : false;
}

This just needs to be removed leaving:
return ($rows_affected > 0) ? (int) $insert_id : false;

and then using the get method method to retrieve the activation hash field if required

Michealdim: Using the get method alone, to retrieve the activation hash will not work, because a salt is added to the activation hash when it is returned using create/register.
If you need the user, you can use the email address to retrieve the user....
// select a user by login column
$user = Sentry::user('john.doe@domain.com');
```php

dberry37388, yeh you are right. Probably could do being cleared on the docs as the methods just states it returns the user id.

If you use the create method it will return the user id, but no activation... I had the same issue and yeah i agree the docs could be a little more specific with that.  The examples are a little misleading...

Sorry, we had fixed this ddoc issue before and it came up again. The docs are still a work in progress in some areas and we will continue to improve upon them. Also, I will work on improving the creation process and allow it to return both the user I'd and activation hash in the future.
Sorry for the inconvenience.

man it's no inconvenience at all... Had I done a better job of looking through the code rather than just delving in blind I would have known. Awesome job on this and keep up the great work!  I was working on my own auth packages, but now I really don't see the need to since there is sentry.

if it helps here is an example of using the methods in sentry : https://github.com/DregondRahl/fuelmod-users/blob/develop/classes/controller/auth.php


Restructure API and module

I would restructure the module around the concept of platform: where a platform (or any other name you like better) is a possible deployment environment represented by an object with two methods and a name property:
{
    name: 'someplatform',

    detect: function () {
        if (/* correct environment detected */)
            return true;
        else
            return false;
    },

    serve: function (app) {
        // ...
    }
}

The API
The module API should be composed of two main functions: detect and serve.
The former detects the current environment and returns a platform object; the latter calls detect, then delegates to the serve method of the platform object.
function serve(app) {
    return detect().serve(app);
}

The serve function should also be assigned to module.exports so one can require the module and call the returned object, just like it is now.
The module should export an object named platforms (or the like) containing all available platform objects.
var ad = require('http-autodetect');

if (ad.platforms.fastcgi.detect())
    ad.platforms.fastcgi.serve(app);

There should be a register or use method to allow loading extensions:
// autodetect-myserver
module.exports = {
    name: 'myserver',
    detect: function () { /* ... */ },
    serve: function (app) { /* ... */ }
};

// app.js
var ad = require('http-autodetect'),
    myserver = require('autodetect-myserver');

ad.use(myserver);
// ...
ad(app);

The name property of platform objects is used to avoid duplicates.
Finally, a choice should be made about currently available platforms:

keep all implementations in this module
move all platforms to separate modules, keeping only http as a fallback, and leave choice to the user
move platforms to separate modules, but add the most common ones (FastCGI, CGI, Passenger maybe?) as dependencies and load them automatically by default. Http is still kept as fallback

detect method implementation
The detect method should iterate over available platforms and call their detect function to select the correct one. This approach however creates a problem: which is the correct testing order? What if two or more platforms give a positive result?
I think a good solution - and the one I would adopt - would be to call detect on all platforms and throw an exception if more than one signals detection. The http platform's detect method should always return false, and http is only used as fallback if no other platform is detected.
function detect() {
    return Object.keys(platforms).reduce(function (detected, key) {
        var platform = platforms[key];
        if (platform.detect()) {
            if (detected !== platforms.http)
                throw /* exception: more than one platform detected */;
            return platform;
        } else {
            return detected;
        }
    }, platforms.http);
}

A good effect of this change is that people could directly maintain platform modules for their own solutions. For example, I could maintain an autodetect-fastcgi module and keep it up-to-date with future developments in node-fastcgi without having to write you every time.

This makes a lot of sense and should be done. Some parts are concrete enough to start working on now, even, but I would like to deliberate on some aspects:
Platform Overlap Resolution
A generalization of your resolution for when multiple platforms match would be to let platforms be weighted. The default weight could be 0, platforms could specify lower weights to be preferred and higher ones to be ordered later/as fallbacks. The platforms would be grouped by weight. The search would go group by group. The first group with any matches would throw if that group contains multiple matches, succeed if that group contains one match (and stop the search there), or continue on to the next group if there are no matches in that group. It’s just a small extension to what you suggest and would even allow you to, e.g., prefer your custom platforms over stock ones.
Dependency Injection
It would be nice to allow injection of custom platforms to have an official well-supported way to specify additional platforms without needing the code to be involved. I.e., instead of needing to call autoserve.register(myCustomPlatform), if serve() could look for some deployment-generated dotfile and automatically load platforms listed there. Well, after thinking this through, I think I’ve realized that this isn’t the way to go because you could instead have your hosting environment/deployment script just generate a module on the fly which mounts your app in an autoserve environment. Actually, maybe this requires a “nested autoserve” platform?
Say you have a deployment script to support a ridiculous hosting environment that requires the custom-ridiculous-autoserve-platform. You want to deploy autoserve-compatible app app. The deployment script could generate the following script:
#!/usr/bin/env node
const autoserve = require('autoserve');
autoserve.register(require('custom-ridiculous-autoserve-platform'));
const app = require('app');
// Grr, I can’t figure out how to reconcile things that this point.
// Depending on what require('app') returns, or maybe we need
// to require the user to pass `module` and detect if we’re the
// main script or just being required() and the autoserve-nesting
// platform would just write to `modules.exports` in that case?
autoserve(module, app);

Actually, I got stuck. There are two issues. require('app') would run something which calls autoserve(app); (or would/should it?), which means it would do its own platform discovery and not export something mountable. The second issue is that even if require('app') did return something mountable, how would I indicate to the mountable thing the right version of autoserve.getBaseUrl()? I know that if I could assume things were Express apps (which supports its own baseUrl tracking when mounting with app.use('/path', subApp)) I could do the following:
#!/usr/bin/env node
const expressAutoserve = require('express-autoserve');
expressAutoserve.register(require('custom-ridiculous-autoserve-platform'));
expressAutoserve(require('app'));

So currently the only thing I can think of is this sort of solution, and I’m back to using deployment-script-generated dotfiles:

Deployment script runs npm install app in some directory then moves node_modules/app to the deployment directory.
Deployment script runs npm install in the deployment directory.
Deployment script runs npm install custom-ridiculous-autoserve-platform in the deployment directory.
Deployment script writes ["custom-ridiculous-autoserve-platform"] to a file named .autoserve-deploy-platforms in the deployment directory.
Deployment script does platform-specific things (e.g., emitting .htaccess or calling something to register the deployment with ths hosting system).

Then, if autoserve() is modified to look for the dotfile and automatically registers all listed platforms in there, a generic app which merely calls autoserve(handler); can be deployed to any hosting environment, assuming the platform module supports all of the used features.
If you understand the deployment-time dependency injection issue I describe and have any opinions, please comment ;-).

Weighting platforms makes sense to me, of course with a default. Maybe all platforms should have 0 as default (except maybe the http fallback) and we should have an API to change the weight, something like autoserve.[weight|prefer|sort](platform_id, weight). This in turn could be very useful for dependency injection, as I'm going to detail below.
Dependency injection
If I understand correctly, you want a way to inject additional platforms without changing the main application file. The wrapper script approach is just going to work. Modules are loaded only once and garbage-collected, otherwise global variables would not work correctly.
Let's say we have a typical application file that imports autoserve and starts serving. All you need to do is to register some platforms before that file is run by the interpreter. Thus this code:
#!/usr/bin/env node
const autoserve = require('autoserve');
autoserve.register(require('custom-ridiculous-autoserve-platform'));
require('app');

will be just enough.
This is where configurable weights get really useful, because one could keep the defaults in the application file and change them in the deployment script.

Ah, I see. That should work. Thanks very much for the guidance!
So, to reiterate the proposed with the above discussion:
{
    name: 'platform',

    detect: function () {
        if (supportedEnvironment) {
            return true;
        } else {
            return false;
        }
    },

    serve: function (app) {
        // …
    },

    // Lower means platform is considered before others.
    // If multiple platforms with same weight have detect()
    // return true, that is an error. Leave unspecified to default
    // to 0. This property should be writeable so deployment
    // scripts can alter the default search order.
    weight: 0,

    getBaseUrl: function (req) {
        // req is an object that serve() passed to app(req, res).
        // The platform must produce the baseUrl. Leave unspecified
        // to use default implementation which returns '/'.
    }
}

The object exported by the module will be like:
const autoserve = function () {
    // implementation that calls autoserve.detect().serve().
};
Object.assign(autoserve, {
    serve: autoserve,
    detect: function () {
        // Returns the detected platform object according to weight rules.
    },
    platforms: {
        // built-in node http module implementation
        http: {},
    },
    // I think I like the name register because it’s unlike express’s/connect’s use().
    register: function (platform) {
        autoserve.platforms[platform.name] = platform;
    },
});

Some core platforms will be included right in the autoserve module including ones that either require almost no implementation or do not require external modules or that are adequately popular (I guess node-fastcgi ;-) ). But the option to register() and the possibility to support being deployed to something arbitrary would be documented and people can publish other modules as they see fit.
I’ll go and do this.

Ok, the only thing missing in my opinion is an API entry to set platform weights - you don't want random people changing properties of platform objects, do you? :wink:
About core platforms, I would move everything except http to separate modules and make autoserve depend on them and register them by default. This is for philosophical reasons (do one thing and do it well) and also because I hope to become a maintainer of the would-be autoserve-fastcgi module. :grin:
Also I hope I can propose a last minute change (please don't hate me :cold_sweat:). The current implementation of the http platform looks for a property named port on the app object or for the PORT environment variable. I think it would be better not to impose such behavior on the user: you could extend the autoserve function to have the signature autoserve(app [, options]), where the optional second argument should be an object containing platform names as keys and option objects as values (e.g. { http: { port: 80 } }). The autoserve function would then become:
function autoserve(app, options) {
    options = options || {};
    const platform = autoserve.detect();
    platform.serve(app, options[platform.name]);
}

Of course each platform would define sane defaults, e.g. http would host by default on port 3000. The serve method on interested platforms should also accept an additional argument for the options object.

I forgot one last thing: lower weight should mean platform is considered after, not before others. The most common action in a deployment script would certainly be to prioritize some platform over others, and this should not require using negative numbers.

Ok, the only thing missing in my opinion is an API entry to set platform weights - you don't want random people changing properties of platform objects, do you? :wink:

My thought on that was that platform modules could leave their properties mutable but the registration would make an immutable copy of the PODs. So to change a pre-registered platform’s priority, you would have to make a copy with your specified weight and then just reregister it. E.g.:
const autoserve = require('autoserve');
// Force the 'http' platform for fun.
autoserve.register(Object.assign({}, autoserve.platforms.http, {
    weight: -1000,
});

Because registrations are keyed by name, this would remove the existing 'http' platform and replace it with the overridden one. But setting the version stored in the registry as an immutable shallow copy of the platform would allow the register() function to perform some amount of validation and avoid having the platform be modified after it passes validation—to a point. The hope is that this allows the full required flexibility while keeping you from shooting yourself in the foot as a user.

I would move everything except http to separate modules and make autoserve depend on them and register them by default.

Sounds good.

The current implementation of the http platform looks for a property named port on the app object or for the PORT environment variable.

The reason I did that was because I thought it seemed to be a generally held convention. But I can’t actually find where I got the get('port') code from. So I’ll need to remove that and add the optional options argument in a future commit.

I forgot one last thing: lower weight should mean platform is considered after, not before others.

When I think of “weights”/ordering, I think of it as just an ascending rank describing the order in which to search for a match. It seems like it’s arbitrary which way you choose to go. I’ll just make my decision clear in the documentation, or if you’re convicted of this (find any node framework precedents?) I can rename it from weight to priority and invert the order ;-).
Please keep the comments coming, hopefully I’ll commit a bit of progress soon :-).

you could extend the autoserve function to have the signature autoserve(app [, options])

Actually, with my (imaginary, I guess xD) deployment script use case, I don’t think this would work quite right. If the app itself calls autoserve(app, options), how does the deployment script get any say? I think instead that each platform should have a public mutable options property which it can read. The register() function would generate it. With that, you could host an application with platform-specific options like:
const autoserve = require('autoserve');
autoserve.register(require('custom-autoserve-platform'), {
    // Could specify options here when registering for convenience.
});
// Or mutate them after the fact:
autoserve.platforms['custom-autoserve-platform'].options.debug = true;
// And then launch the wrapped autoserve application.
require('app');

Then the implementation of platform.serve() can access these in this.options and handle them however it wants.
Thoughts?

My thought on that was that platform modules could leave their properties mutable but the registration would make an immutable copy of the PODs. So to change a pre-registered platform’s priority, you would have to make a copy with your specified weight and then just reregister it.

That's not a bad idea, yet I advocate the addition of an API to automate that copy-modify-register process. Three lines of code and all that Object.assign cruft are too much just to change a weight, and they don't express intent well. You have two problems here: API ergonomics (for the developer) and readability (for the maintainer).

I can rename it from weight to priority and invert the order

When I think of weight or priority, I think of the same concept (higher weight/priority comes first, like in "high priority"); when lower values come first, I would call that order/ordering. It's just a naming issue, but my point was - again - more about ergonomics: using negative numbers to prioritize things feels strange to me. The only precedent I can think of is process priority on linux (where indices range from -20 to 19 with -20 being the highest priority) and again this feels very weird. But maybe it's just me. :smile:

Actually, with my (imaginary, I guess xD) deployment script use case, I don’t think this would work quite right.

You're right. But I'm worried that the apps would end up reregistering platforms just to change options, thus overriding settings made by the deployment script, including weight. Maybe you could support both the argument on the autoserve function and an override method for dependency injection?

Thinking about it, one could add an API entry like this:
autoserve.options = function(platform, options) {
    var originalServe = platforms[platform].serve;
    autoserve.register(Object.assign({}, platforms[platform], {
        serve: {
            value: function (app, opts) {
                originalServe.call(this, app, Object.assign({}, opts, options));
            }
        }
    }));
}

This would allow overriding options passed to the autoserve function call without needing additional properties on the platform object.

Or maybe you could just add a single method, called override or the like, which only automates the copy-modify-register part. This would allow to change both options and weight, but it would put some more burden on deployment script authors.
autoserve.override = function(platform, obj) {
    autoserve.register(Object.assign({}, platforms[platform], obj));
}

// Usage in deployment script:
autoserve.override('fastcgi', { weight: -10 });
var originalServe = autoserve.platforms.http.serve;
autoserve.override('http', { serve: function(app, opts) {
    return originalServe.call(this, app, Object.assign({}, opts, { port: 2000 }));
});

I don't really know which way would be better. Anyway, I'm very against using platform object properties to set options because this puts on platform module developers the burden of getting the logic right.

Sorry for posting so many comments. Maybe the option logic could stay entirely out of platform objects: you could have a global property of the module, named options, which would override the option argument passed to autoserve:
module.exports = function (app, options) {
    options = Object.assign({}, options || {}, module.exports.options);
    var platform = module.exports.detect();
    platform.serve(app, options[platform.name]);
}

module.exports.options = {};

And in the deployment script you would write autoserve.options.http = { port: 2345 }

Making options a module property sounds like a proper way to go. Then autoserve will make sure the platform’s specific options are passed to platform.serve(app, options). That is much more obvious/maintainable than requiring the platform code to look for this.options.
With your request to reverse weight, now I’m more confounded on what to do :-p. I still for some reason thing that if it’s called weight it should go in the order it is right now. I guess I’ll rename it to priority and then reverse it.
Regarding the override() idea, I guess providing override(platformName, obj) as convenience would be helpful. But it seems like I shouldn’t have to do that. In C# I’d implement that as an extension method generalized to IRegistry (I don’t like JavaScript’s alternative of prototype injection, it’s totally different). But I should just stop complaining and do it ;-).


Move issue to community repo bot

Summary
This adds a bot for when the label "Resolution: Community Repo" is applied. References the list of maintainers for the issuer to find the appropriate repo to file their issue.
Note: The label "Resolution: Community Repo" does not exist. It must be created by someone who has access.

Changelog

[Internal] [Added] - Added bot for Resolution: Community Repo label
Test Plan

Closing as I believe we don't need this label anymore


When Yubikey token is written down, the page keeps loading until timeout (token is not verified)

Expected Behavior
This happens when I set the 2FA. I should get something like: "congratulations your yubikey is set" but the page keeps loading forever until timeout
Current Behavior
Immediately after filling the token by pressing my yubikey, page loads but doesn't move to the next step
Possible Solution
It worked in my localhost, but failed in a real server with SSL
Anybody has the same issue? Thanks

Could you provide the following:

Browser and version
Python version
Django version
django-otp version
django-two-factor-auth version

Browser and version: Chrome, Firefox, different versions (e.g., chrome v 990.4844.74, firefox v91)
Python version: 3.9.2
Django version : 4.0.3
django-otp version: 1.1.3
django-two-factor-auth version : 1.13.2
Im using the default service,
and my remoteyoubikey_device table stores the hex code but multiple times for the same user (likely because I try several times and the page loads without moving to the next step)
id | name | confirmed | public_id | service_id | user_id
1   default       1             ccc5262        1               1
2   default       1             ccc5262        1               1
3   default       1             ccc5262        1               1
4   default       1             ccc5262        1               1
It should appear only once,

The log file shows:
[wsgi:error] [pid xxxx:tid xxxxxxxxxxxxxx] [client xxx.xxx.xxx.x:xxxx] Timeout when reading response headers from daemon process....
Any help?

Also checking the Inno DB Status I get in transactions:
7 lock struct(s), heap size 1136, 2 row lock(s)
and the processlist of the yubikey falls asleep

Dear all, you can close this.
It has been resolved with the latest update. Not sure what was the cause but it is fixed.
regards


RDKDEV-286 : Added LinearPlaybackControl plugin for streamfs_fcc project

Added plugin implementation for controlling streamfs_fcc. See also https://jira.rdkcentral.com/jira/browse/RDKDEV-286

Internal JIRA for tracking : https://ccp.sys.comcast.net/browse/RDKCOM-3055

Replaced by https://github.com/rdkcentral/rdkservices/pull/2734 for sprint/2206


Add ability to specify which countries to show in the dropdown

This is to handle feature requests #43.
A valid use case where the app is not available in all countries and the developer wants to restrict the list of countries to only the supported ones.

Merged by mistake, if you want this to be added, make another pr with nullsafe support

Updated for null safety and submitted another PR.
Please accept when you get a moment.


Upgrade to Python v3.12 and Poetry v1.6.1

Upgrade dependencies and upgrade to Python v3.12 and Poetry v1.6.1.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
107

Relevant Lines:
109

💛  - Coveralls


Fixed reference URLs on delivery service (DNS, HTTP) pages

What does this PR (Pull Request) do?

[x] This PR fixes reference URLs on Delivery Service Page, specifically for type: HTTP and DNS

Which Traffic Control components are affected by this PR?

Traffic Portal

What is the best way to verify this PR?

Go to traffic_portal's create a delivery service page.
Select either HTTP, or DNS type
Go to section Cache Configuration Settings, and hover over every field in that section and click on the links present in help tool tip.
No link should show a page does not exists yet error.

If this is a bug fix, what versions of Traffic Control are affected?

master (d809e9a)
The following criteria are ALL met by this PR

[x] I have explained why tests are unnecessary
[x] I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Additional Information

The PR doesn't need documentation or tests since it only updates the Reference URL path in Traffic Portal. No logic has been implemented.

This looks like it works for what it changes - however, HTTP and DNS Delivery Service pages in TP still have two broken references. The first is in the "Deep Caching" field's tooltip, where it should probably be https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_router.html#deep-caching to link to the correct anchor. The other is in the tooltip for "Geo Limit Redirect URL" and to be honest I'm not sure where that's supposed to take you.
Neither of these land on 404 pages, they're just non-existent anchors on an existent page. So you don't need to fix that if you don't want to, but I thought I'd bring it up.

I updated both these reference urls.


[Admin. Orders] Missing of the option "Без менеджера/логіста/штурмана/водія" in the relevant filters

Environment: macOS Monterey Version 12.3.1, Chrome 101.0.4951.54
Reproducible: always
Build found: 27.05.2022
Preconditions
Go to https://ita-social-projects.github.io/GreenCityClient/#/ubs
Sign in as admin
Steps to reproduce

Click the 'UBS-admin' button in pop-up window
Click the button "Замовлення"
Click on the button "Фільтри"
Expand the next filters:

Менеджер обдзвону
Логіст
Водій
Штурман

Actual result
There is no option "Без менеджера/логіста/штурмана/водія" in the appropriate filters available.

Expected result
The option "Без менеджера/логіста/штурмана/водія" in the appropriate filters should be present.

User story and test case links
User story #3300
Mock-up: https://www.figma.com/file/JvDAu4MHnh1Vxc5FaokyiA/ITA-UBS-styles?node-id=18582%3A52286

To implement on back-end:
Endpoint: https://greencity-ubs.testgreencity.ga/ubs/management/bigOrderTable
Add an option to match all the records without caller/driver/logistician/navigator to query params:
responsibleCallerId, responsibleDriverId, responsibleLogicManId, responsibleNavigatorId.
I suggest using -1 , e.g.
GET on https://greencity-ubs.testgreencity.ga/ubs/management/bigOrderTable?responsibleDriverId=-1 should return records with no driver assigned.


Declaration merging when using rootDirs?

I have tsconfig in src/postgres with rootDirs set:
{
        "rootDirs": [
            "../core",
            "../common-rdbms",
            "."
        ]
}

Now, common-rdbms has column/ColumnOptions.ts with ColumnOptions interface inside.
What I want is to have postgres/column/ColumnOptions.ts with ColumnOptions interface inside with another properties. What I expect is when I use ColumnOptions inside "postgres" project, it will have properties from both ColumnOptions from common-rdbms and postgres package.

can you please make a small repro project to demonstrate the problem to make sure that root cause of the issue is addressed?

here you are. See error in ./src/postgres/index.ts


jakttest: Parallelize Jakttest

Rewrote Jakttest so it accepts all the test files and runs them through a process scheduler to be able to run the tests in parallel. The binary gets a clean temporary directory where it places one temporary directory per job. It uses that to store both C++ temporaries from Jakt compiler's output and stderr/stdout results, which it will read once it knows the job has finished with the directory. Doesn't use any locks since it makes sure to only run one job per directory.
Most of the "changes" here are just removing unneeded files (mainly the 900loc from lexer/parser) since I wrote a custom Expect section parser that runs through each file to know what to expect from its output. This new parser does not care about the Jakt language; instead it only looks for the expect section, reducing the possibility of having a Jakt lexer bug propagate into Jakttest.

It currently has some issues at the moment, namely that the lockfiles seem to not be enough to ensure jobs don't step over each other, which is currently making the result counts variable.

It might be easier to coordinate threads if jakttest itself gathered up and ran all the tests instead of a shell script. Not sure if Jakt has good enough multithreading support for that though.

I might be able to hack in some C++ code using std::thread or fork()&exec()s, but Jakt doesn't have support for anything besides prelude stuff (File, Array, Optional...)

The reason behind using "locks" is to correctly map jobs that are freed to their directory. I'm thinking of having a sort of associative array with processID+directory name. Although I'm not comfortable with Bash arrays, so this will take me a while to think through.

I'm going to do this as a single commit; trying to do multiple incremental commits breaks the tests since I'm modifying the test runner.

It seems like it's leaving everything empty... I'm pretty curious on why though

Hmm, looks like selfhost is trying to use build/output as its temporary build object instead of using/reusing its own temporary directory. I'll add a flag so build output is customizable through an argument.

Welp, I managed to fit in some multiprocessing support for Jakt :)

Wait, this seems to be producing false negatives:

I tried running the tests on the mac, and seeing:
     Running `/Users/jt/Source/jakt/target/debug/jakt -o build --emit-cpp-source-only jakttest.jakt`
[2/3] sed -e '1a#include "../process.h...ttest.cpp > build/jakttest-patched.cpp
FAILED: build/jakttest-patched.cpp
sed -e '1a#include "../process.h"' build/jakttest.cpp > build/jakttest-patched.cpp
sed: 1: "1a#include "../process.h"
": command a expects \ followed by text
ninja: build stopped: subcommand failed.

Hmmm, different sed versions I see... Welp, I'll just make a quick python patch script then :)


[Toast] Active toast info to global action

[x] Active toast when action is done
[x] Text for success Action "The action has been completed"
[x] Text for failed Action "..."

See #958


Revert model to use censorship timeseries

Revert model to use censorship timeseries: Revert to Commit - 2226f2a

done by PR #241


fix: 🐛 Better tooling compatability in package.json

Checklist (for the issue creator)

[ x] I have verified the bug exists in the latest version of @synergy-design-system/components (e.g. via pnpm install @synergy-design-system/components).
[ ] I can provide a simple, reproducible example of the issue (e.g. via code-sandbox or sample code, ...).   --> Since this is about tooling, unfortunately not so simple 😳
[ ] I would be willing to provide a PR for this issue.

Version
The bug occurred with the following version of the component library: 2.4.3
Component
The issue arises when using the following component(s):
package.json
Environment
When building a depending application with eslint
Description
Eslint uses thenexports field of any packages to find declarations that an app may have imported and reports findings as a violation to the import/no-unresolved rule.
Unfortunatelly (at least in our version of eslint which is 8.22.0) it seems that eslint is not able to follow the exports/importfield as defined in the synergy components package:
  "exports": {
    ".": {
      "types": "./dist/synergy.d.ts",
      "import": "./dist/synergy.js"
    },
    "./custom-elements.json": "./dist/custom-elements.json",
    "./synergy.js": "./dist/synergy.js",
    "./synergy-autoloader.js": "./dist/synergy-autoloader.js",
    "./components/*": "./dist/components/*",
    "./utilities/*": "./dist/utilities/*",
    "./styles/*": "./dist/styles/*",
    "./themes/utility.css": "./dist/styles/utility.css",
    "./themes/*": "./dist/themes/*",
    "./translations/*": "./dist/translations/*",
    "./index.css": "./dist/styles/index.css"
  },

I already tried playing with this locally and it seems that it would be save to simply have a duplicate of your import field as default without breaking never tooling. This would allowed for older tooling to still find the correct exports:
"exports": {
    ".": {
      "types": "./dist/synergy.d.ts",
      "import": "./dist/synergy.js",
      "default": "./dist/synergy.js"
    },

Is this possible?
Acceptance criteria

[ ] The package.json of the exported @synergy-design-system/components package contains an exports/./default field that is a copy of the exports/./import field

See https://github.com/import-js/eslint-plugin-import/issues/2495 for a reason for the problem. @kirchsuSICKAG: I think we could savely add this, should not have any side effects


Please add 1.20.1 Support!

There's no good backpack mod that works with 1.20.1, and I want to use yours!

I'm currently re-writing the mod so that you can play on forge and add your own backpacks using Json. I don't really know how to backport, and I don't know where to start. So once the re-write's finished, backporting will be the first priority. Glad to see you're excited though!

btw I added 1.20.1 support. :)


Typed keys

Cheers for the good work you're doing for the community Marc!
I wrote a thin wrapper around this lib in order to have TypeScript enforce a set of keys, and as it would be a breaking change for the library I figured I'd post it here in case you or anyone else want to use the solution.
Do as you wish, let me know if you'd rather have it as a PR.
import {MMKV} from 'react-native-mmkv';

export interface TypedMMKVInterface<StringKeysT, NumberKeysT, BoolKeysT> {
  /**
   * Set a value for the given `key`.
   */
  set: (key: StringKeysT | NumberKeysT | BoolKeysT, value: boolean | string | number) => void;

  /**
   * Get a boolean value for the given `key`.
   *
   * @default false
   */
  getBoolean: (key: BoolKeysT) => boolean;
  /**
   * Get a string value for the given `key`.
   *
   * @default undefined
   */
  getString: (key: StringKeysT) => string | undefined;
  /**
   * Get a number value for the given `key`.
   *
   * @default 0
   */
  getNumber: (key: NumberKeysT) => number;
  /**
   * Delete the given `key`.
   */
  delete: (key: StringKeysT | NumberKeysT | BoolKeysT) => void;
  /**
   * Get all keys.
   *
   * @default []
   */
  getAllKeys: () => Array<StringKeysT | NumberKeysT | BoolKeysT>;
  /**
   * Delete all keys.
   */
  clearAll: () => void;
}

export function createKeyStore<
  StringKeysT extends string = never,
  NumberKeysT extends string = never,
  BoolKeysT extends string = never,
>(id: string): TypedMMKVInterface<StringKeysT, NumberKeysT, BoolKeysT> {
  const _keyStore = new MMKV({id});

  return {
    set: (key, value) => _keyStore.set(key, value),

    getBoolean: key => _keyStore.getBoolean(key),

    getString: key => _keyStore.getString(key),

    getNumber: key => _keyStore.getNumber(key),

    delete: key => _keyStore.delete(key),

    getAllKeys: () => _keyStore.getAllKeys() as Array<StringKeysT | NumberKeysT | BoolKeysT>,

    clearAll: () => _keyStore.clearAll(),
  };
}

Cool! I've played around with something similar in one of my apps before.

@sseppola revisiting this - how do you think should we proceed? I don't think this should be part of MMKV but rather a user's abstraction, do you disagree?

Looking at how I use it:
const store = createKeyStore<'user', never, never>({
  id: `mmkv_user_store`,
});

where createKeyStore is the fn shared above. My wrapper basically wraps the whole interface of MMKV 1:1 in order to provide the types, which seems unnecessary.
Would you consider a PR that doesn't introduce any breaking changes, but makes this typing opt-in?
I need to tinker with your source code, but I think by changing the defaults from never to string could achieve this.

After a lot of consideration I'd say we leave this out of the library's core code. If you want, you can provide this abstraction as a separate library, but I'd like to avoid the code duplication here and keep MMKV as lean and lightweight as possible :)


Allow kiali to consume DaemonSets

needs https://github.com/kiali/kiali/pull/3764

@aljesusg @lucasponce should we merge the operator one too, since this one is merged? I don't fully know what happens if you have helm-charts and operator files not fully-syncronized.

On this case it's harmless, but we should avoid to merge operator/helm PRs until the backend/frontend work is ready and discussions resolved.
(This changes will simply be not used until the backend changes in workloads are consolidated).


Password input field placeholder turns into dots

https://github.com/elad2412/the-new-css-reset/blob/main/css/reset.css#L53
/* reset default text opacity of input placeholder */
::placeholder {
    all: unset;
}

This makes the placeholder text in password fields turn into dots. Without the reset it should display as plain text.
It has something to do with the -webkit-text-security css property...

Thanks for this important update, it happens in Chrome and Safari (not in Firefox).
I update the style of ::placeholder that it will affect only on text color.
/* reset default text opacity of input placeholder */
::placeholder {
    color: unset;
}

Instead of:
/* reset default text opacity of input placeholder */
::placeholder {
    all: unset;
}

Updated in the last version of 1.5.0.
I
(Closed Issue)