Support the Junit 5 TestEngine API

Feature Request
TestNG Version

Note: only the latest version is supported

Expected behavior

Supportes the Junit 5 TestEngine API

Actual behavior

Does not seem to support this API

Is the issue reproductible on runner?

[ ] Shell
[ ] Maven
[ ] Gradle
[ ] Ant
[ ] Eclipse
[ ] IntelliJ
[ ] NetBeans

Test case sample

Please, share the test case (as small as possible) which shows the issue

@cbeust @juherr - Just curious behind the use case of why TestNG supports JUnit executions. Traditionally I can understand that it was one of the ways of paving way for people to migrate or adopt TestNG without them having to do changes to their existing JUnit tests. But is that still the use-case here, especially after the fact that TestNG has already been out there for over 10 years and JUnit 5 (from what I understand) has similar features to what TestNG has.
@thejeff77 - Please feel free to chime in and add context. This is just to help me understand the context a bit better, as to when you would want to use TestNG to run JUnit5 tests. JUnit 5 is relatively new. So I am guessing that those scripts must be newly created as well. So why wasn't TestNG directly used, instead of having them written in JUnit5 and then needing TestNG to run them. What purpose does this execution model solve ?

In fact, the junit support allows mixed suite with JUnit and TestNG tests. It's not so often but I've already noticed issues on Maven Surefire where the user has such kind of suites.
The feature request here is just having a testng-engine as described on https://blog.codefx.org/design/architecture/junit-5-architecture/#Architecture
It will allow an easier maintenance for 3rd parties like build tools or IDE plugins because they will only have to manage one single api.
I've already tried an implementation months ago but the api and some concepts were not so easy to understand. BTW, it could be a fun project if you want to learn a lot about JUnit and TestNG.

@krmahadevan Thank you for your timely response. This is all about support and integration. Our company is looking at starting to write tests again, and all of our old tests are in Junit 4. TestNG looks awesome, but it is hard to make the case to use it if we'd have to convert all old tests to testng. As you may or may not know, Junit 5 is backwards compatible, and includes the Junit Vintage jar which is capable of running older versions of junit tests such as ours. If testng supported the TestEngine API, it would be a powerful factor in allowing companies such as ours to start writing tests in TestNG without the overhead of worrying about a full blown conversion. Especially since a major goal in JUnit 5 was creating the ability to integrate with other frameworks (TestEngine API), it would be a major case for the second most-used java test framework (TestNG) to allow seamless integration and simultaneous use alongside the most recognized name in java test frameworks (Junit 5). Currently, for anyone who used Junit in the past - using Junit 5 is a no-brainer due to its integration potential and backwards compatibility, and is likely why we'll use this one. As @juherr and others online have outlined - it is not as straightforward as desired to use the two in parallel, making it hard to justify the TestNG framework for a project that has previously written tests in Junit. The unknowns and potential time sink of dealing with issues running TestNG is a productivity risk for us to use this framework.

@thejeff77 Did you notice that TestNG supports JUnit 4 too? It means you will be able to write you new tests with the TestNG API and keep your previous tests with JUnit 4 without having to modify them.

@juherr - I went through the article and i liked the idea very much. Please let me know if there is any opportunity for collaboration.

@atulagrawal In fact, it depends on you first. Feel free to work on it because you need to understand the JUnit5 and TestNG api first and then find a way to link them.
If needed, we can help you on a dedicated issue on github.

Ok. Let me go through the APIs first. I don't have any experience with JUnit 5 so may be i will play around with it for a while to understand the concepts.

I'm also interested in helping to provide a TestNGine, i.e. an implementation of the JUnit Platform TestEngine interface that knows what TestNG tests are and how to execute TestNG tests.
I do understand the JUnit Platform API but only skimmed the TestNG API so far. So, perhaps, I'll start a spike and share the skeleton implementation here for fleshing it out.

@sormuras I'd love to help even if I don't have a lot of time. The skeleton will help because I didn't understand the API months ago.
BTW, I created a dedicated repository: https://github.com/testng-team/testng-junit5
I can give you write access if needed.

Sure. Let's get started over there.

Can we get this to start using JDK8 ?

Aye. Will finish the spike first, then get https://github.com/sormuras/junit-platform-maven-plugin compile to JDK 1.8 bytecode (mrjar), and then use --release 1.8 here as well.

Btw. the current spike is already consumable via JitPack:
Build Log: https://jitpack.io/com/github/testng-team/testng-junit5/master-SNAPSHOT/build.log
Coordinates:  https://jitpack.io/#testng-team/testng-junit5/master-SNAPSHOT

@sormuras - Thanks. TestNG has been publishing SNAPSHOTS into sonatype via travis. We could perhaps have the .travis integration sorted out.
We basically need to add the following

the deploy folder ( you can refer here for a sample )
the .travis.yml file ( please refer here for a sample)

Once that is done, I think @cbeust needs to embed the sonatype credentials into the travis project to get the builds to start publishing into Maven central snapshot repository.

@krmahadevan Feel free to improve the deployment process right away. I'll concentrate on classes in org.testng.junit5 for now.

@juherr @cbeust - Can you please help with the credentials part in Travis to get started with publishing ? I have pushed in the travis file enhancements and also the deploy script.

Using JDK 8 now. Done via https://github.com/testng-team/testng-junit5/issues/2
Now, the pom.xml needs some more love: https://travis-ci.com/testng-team/testng-junit5/jobs/142306674#L832
[ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy)
  on project testng-junit5-engine:
Deployment failed:
  repository element was not specified in the POM inside distributionManagement element
  or in -DaltDeploymentRepository=id::layout::url parameter -> [Help 1]

Just wondering, does https://github.com/junit-team/testng-engine implement the feature?

@vlsi Exactly


MMGeoIP: add ASN to package

Hi, @andyone.
First of all, I am appreciate your contribution to the opensource community and providing RPM packages for CentOS/RHEL distributions.
I am looking for your opinion to improve the MaxMind GeoIP base RPM package. I offer you include ASN (autonomous systems information) in CSV format to the MMGeoIP and MMGeoIP-IPV6 packages.
What do you think about this proposal?
I am also a bit confused with a MaxMind blog article. According to the text, it is mandatory to be a registered user to download databases. I do not know how to use the license key they assign to the user with RPMBuilder in the context of building RPM packages.
Do you have any ideas on how to bypass it?

Hi! Thanks for your kind words. 😊

I offer you include ASN (autonomous systems information) in CSV format to the MMGeoIP and MMGeoIP-IPV6 packages.

We can add them as sub-packages to keeping the size of packages within reasonable limits.

I do not know how to use the license key they assign to the user with RPMBuilder in the context of building RPM packages.

If I understand their post right, they provide direct links, but we should add the license key as a part of the URL. So we can use these links and add the license key macro to sources URLs, and define it on build stage through --define option. In this case, everyone could build these packages using their own license key.

So we can use these links and add the license key macro to sources URLs, and define it on build stage through --define option.

That's sounds great! Is there any help needed with this change?

Thanks, no help needed. I have done these changes (e390e07c0bbba3e11e6b769ec1f468bff66f96dd), but unfortunately, MaxMind URLs don't contain filenames and we can't use macros for the license key. So I created the script for downloading MaxMind data.
Also, since this version every type of data packed to separate package (IPv4/IPv6/ASN-IPv4/ASN-IPv6).


Add SURI validation logic

Something similar to https://github.com/polkadot-js/tools/blob/31375f26804f5e3658d55981ff4531d3e5d77517/packages/signer-cli/src/cmdSign.ts#L14-L31

Closed by #6


parse and infer constructors

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

Project coverage is 82.38%. Comparing base (a1e1cf1) to head (f130fbc).

Files
Patch %
Lines

src/Escalier.Parser/Parser.fs
95.23%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #177      +/-   ##
==========================================
+ Coverage   82.31%   82.38%   +0.07%
==========================================
  Files          21       21
  Lines        8062     8097      +35
  Branches     1197     1200       +3
==========================================
+ Hits         6636     6671      +35
  Misses       1426     1426

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


[Bug]: JSON Schema emitter mismatched $ref when using a Record type

Describe the bug
I am using Record<T> to describe a datastructure that allows for arbitrary keys of a certain type.
When using the @typespec/json-schema emitter on such a Model, the generated jsonschema file splits the Record type into an entry in $defs. That Record type is, however, accessed using a $ref pointing to a file called RecordString.json (which is not generated) instead of the correct subschema.
This issue causes any editor using the generated JSON Schema to complain and forgo validation and linting, so a quick fix would be appreciated.
Reproduction

Playground link

Annotated reproduction below:
// schema.tsp
import "@typespec/json-schema";
using TypeSpec.JsonSchema;

@jsonSchema()
model ModelName {
    array: Array<Record<string>>
}

// in YAML, this model could look like below:
//  array:
//     - anything-goes-here: "helo world :3"
//     - "custom key name": value

$ npx tsp compile ./schema.tsp
TypeSpec compiler v0.56.0

Compilation completed successfully.

# ModelName.yaml
# (actually generated as JSON, just using YAML for comment support)
{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$id": "ModelName.json",
    "type": "object",
    "properties": {
        "array": {
            "type": "array",
            "items": {
                "$ref": "RecordString.json"
				# this $ref does not exist, the correct way to reference the subschema below would be
				# "$ref": "#/$defs/RecordString"
            }
        }
    },
    "required": [
        "array"
    ],
    "$defs": {
        "RecordString": {
            "$schema": "https://json-schema.org/draft/2020-12/schema",
            "$id": "RecordString.json", # this ID being set does not help here
            "type": "object",
            "properties": {},
            "additionalProperties": {
                "type": "string"
            }
        }
    }
}

Checklist

[X] Follow our Code of Conduct
[X] Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion.
[X] The provided reproduction is a minimal reproducible example of the bug.

The ref is correct as per JSON Schema 2020-12, when referencing schemas with an id. Unfortunately, VSCode etc. do not yet understand the bundle format specified there. However, there was a recent fix (https://github.com/microsoft/typespec/pull/3430) to not create root schemas for non-Json Schema types, which would fix this particular case. This fix will be going out with the next release, and you can try it in our dev packages if you like. Note that you would still get the current schema referencing format when referencing JSON Schema types, which are either emitted to separate files or bundled when you pass --bundleId. For the former case, I've found tooling understands that fine.

Thanks for the speedy response! I'll try to test the dev package tomorrow. Pity that the tooling doesn't understand the full standard...
If this is already fixed, I guess the issue can be closed. I'll report back later whether switching to the dev package fixes it for me.

Feel free to close once you've checked it out. I think you should have permissions, but if not, just reply.

Switched to a v0.57.0 dev release, everything works now. Thanks!


RuntimeError when running multiprocessing example

face_recognition version: 1.2.3
Python version: 3.7
Operating System: Pop!_OS 19.04
CUDA + CuDNN version: 10.0

I'm trying to use the facerec_from_webcam_multiprocessing.py example with cuda support, but everytime I run it I get this error:
Width: 640, Height: 480, FPS: 30
Process Process-5:
Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "facerec_from_webcam_multiprocessing.py", line 78, in process
    face_locations = face_recognition.face_locations(rgb_frame, model="cnn")
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 116, in face_locations
    return [_trim_css_to_bounds(_rect_to_css(face.rect), img.shape) for face in _raw_face_locations(img, number_of_times_to_upsample, "cnn")]
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 100, in _raw_face_locations
    return cnn_face_detector(img, number_of_times_to_upsample)
RuntimeError: Error while calling cudaGetDevice(&the_device_id) in file /home/han/dlib-19.17/dlib/cuda/gpu_data.cpp:201. code: 3, reason: initialization error
Process Process-6:
Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "facerec_from_webcam_multiprocessing.py", line 78, in process
    face_locations = face_recognition.face_locations(rgb_frame, model="cnn")
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 116, in face_locations
    return [_trim_css_to_bounds(_rect_to_css(face.rect), img.shape) for face in _raw_face_locations(img, number_of_times_to_upsample, "cnn")]
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 100, in _raw_face_locations
    return cnn_face_detector(img, number_of_times_to_upsample)
RuntimeError: Error while calling cudaGetDevice(&the_device_id) in file /home/han/dlib-19.17/dlib/cuda/gpu_data.cpp:201. code: 3, reason: initialization error
Process Process-7:
Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "facerec_from_webcam_multiprocessing.py", line 78, in process
    face_locations = face_recognition.face_locations(rgb_frame, model="cnn")
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 116, in face_locations
    return [_trim_css_to_bounds(_rect_to_css(face.rect), img.shape) for face in _raw_face_locations(img, number_of_times_to_upsample, "cnn")]
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 100, in _raw_face_locations
    return cnn_face_detector(img, number_of_times_to_upsample)
RuntimeError: Error while calling cudaGetDevice(&the_device_id) in file /home/han/dlib-19.17/dlib/cuda/gpu_data.cpp:201. code: 3, reason: initialization error
Process Process-8:
Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "facerec_from_webcam_multiprocessing.py", line 78, in process
    face_locations = face_recognition.face_locations(rgb_frame, model="cnn")
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 116, in face_locations
    return [_trim_css_to_bounds(_rect_to_css(face.rect), img.shape) for face in _raw_face_locations(img, number_of_times_to_upsample, "cnn")]
  File "/usr/local/lib/python3.7/dist-packages/face_recognition/api.py", line 100, in _raw_face_locations
    return cnn_face_detector(img, number_of_times_to_upsample)
RuntimeError: Error while calling cudaGetDevice(&the_device_id) in file /home/han/dlib-19.17/dlib/cuda/gpu_data.cpp:201. code: 3, reason: initialization error

I looked at the multiprocessing documentation and made a few changes in the script without success. Could you give me a hint on how could I make it work? Thanks in advance.

I had that same issue working with Python 3.6 and fixed doing the import of face_recognition module inside the process function

I had that same issue with python 3.6 and fixed doing the import of face_recognition module inside the process function

Thank you for your answer! but that didn't work for me...
Anyone else?

@carratala17707 @angiglesias
Hi all,
I am facing the same issue in jetson nano board.
did you solve your pbm?
help appreciated.

@SaddamBInSyed
did you solve your pbm?
help me
I am alse facing the same issue in jetson nano
please help me!

@carratala17707 @angiglesias
Hi all,
I am facing the same issue in jetson nano board.
did you solve your pbm?
help appreciated.

i solved this pbm, use cpu when you install dilb. @SaddamBInSyed


Buttons on Product page

One button will link to the store locator. The other button will link to an image in a lightbox (of a nutrition label)

@rickyferrer what do you think about just showing the nutrition label below the button? like it slides in when you click the 'nutrition info' button? that would use less javascript and be simpler. lightboxes use more code that may slow down the site a bit, which may not be worth it for this one simple use case.

And there's the room. Good.
Sent from my iPhone

On Apr 28, 2016, at 9:01 PM, Christina Rees<EMAIL_ADDRESS>wrote:
@rickyferrer what do you think about just showing the nutrition label below the button? like it slides in when you click the 'nutrition info' button? that would use less javascript and be simpler. lightboxes use more code that may slow down the site a bit, which may not be worth it for this one simple use case.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub


Allow installation of specific Python version e.g. 2.7.x, 3.3.x, 3.4.x, 3.5.x, 3.6.x

As per a conversation in: #303.
It is necessary, when creating libraries for general distribution to test under multiple Python versions e.g. 2.7.x, 3.4.x, 3.5.x, 3.6.x.
The specific use case is creation of a Jenkins Docker image to be used as a CI server to test an open source library against all supported Python versions.  The Docker image should contain all current versions of Python in common use (2.6.x...3.6.x) with the Jenkins tests themselves deciding which versions to test against.
I'm not sure what mechanism is appropriate for switching out the specific version to be installed but it wouldn't seem to require duplicating the entire formula.  The main variant is the download url, and it may vary by a dependency or two.

Hi, Steve. I'm not inclined to add these many versions of Python to Linuxbrew itself. Your easiest path forward I think would be to create your own tap ssteinerx/homebrew-python-versions and create a formula for each version of Python, named<EMAIL_ADDRESS><EMAIL_ADDRESS>et c.

@sjackman Understood.  That's far beyond my ken at the moment but I may have to figure it out as I need the capability.


Bug fix for navigation to simple destination without any arguments

When tying to migrate to version 1.2.0 the following occurred. First, the project wouldn't build and the error
> Task :ui:sessions:compileDebugKotlin FAILED
e: Pre-release classes were found in dependencies. Remove them from the classpath, recompile with a release compiler or use '-Xskip-prerelease-check' to suppress errors
e: C:\Users\pap1\AndroidStudioProjects\Android-nRF-MeshSniffer\ui\sessions\src\main\java\no\nordicsemi\android\mesh\sniffer\ui\sessions\SessionsDestination.kt: (19, 42): Class 'no.nordicsemi.android.mesh.sniffer.ui.access.AccessDestinationKt' is compiled by a pre-release version of Kotlin and cannot be loaded by this version of the compiler

> Task :app:mergeExtDexDebug

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':ui:sessions:compileDebugKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
   > Compilation error. See log for more details

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 14s

Following up on the suggestion this was fixed by adding
kotlinOptions {
    freeCompilerArgs = freeCompilerArgs + "-Xskip-prerelease-check"
}

to build.gradle for the sessions module in Android-nRF-MeshSniffer. The current navigation structure of my project is
sessions ----onClick(scanSession)----> access
sessions ----onClick(Settings) ----> settings
access ---- onClick(Network) ----> network
Pressing back follows the above graph in reverse. What I find interesting is that the access module also performs navigation in between modules using simpleDestination, yet the compiler options were not required in this module's build file. The only difference between the sessions module and the access module is that the former has the compiler options modifying the arguments, whereas the latter has the language version set to 1.8. If we modify the sessions module to use the language version and remove the compiler arguments then the project builds correctly. Will use this solution.
The main issue of this pull request is however when simple navigation is performed without any arguments. For example
val Sessions = createSimpleDestination("sessions")

val SessionsDestination = defineDestination(Sessions) {

    val viewModel: SimpleNavigationViewModel = hiltViewModel()

    ScanSessionsScreen(
        onClick = { viewModel.navigateTo(Access, null) },
    )
}

Note that this is the only working way at the moment after performing the change in this pull request. Before, the args parameter was mandatory to be passed. Also, passing Unit resulted in an error. This is probably not the best fix but me and @sylwester-zielinski played with this yesterday and found out that this works.
@sylwester-zielinski the change in Kotlin-nRF-Mesh was not necessary as the main issue was with the compiler settings in my modules + the optional parameter being required.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Add an option to customize the "Select" text on SelectFilter filter.

Add selectText as a prop to filter prop.
An example:
<TableHeaderColumn ref='nameCol' dataField='quality' filterFormatted dataFormat={ enumFormatter }
formatExtraData={ qualityType } filter={ { type: 'SelectFilter', options: qualityType, selectText: 'Choose' } }>Product Quality

@eitansela, thank you :)  But It’s a pity that I release a new version at few minutes ago...  so this PR will be merged on next version.
Anyway, thanks your contribution. Great job 👍

Hello @AllenFang , When is the next version expected?
Thanks,

This weekend or next week :)

@eitansela, merged and released on v2.5.8

Thanks!


Using ValidationProblemDetails causes TS2612 in TypeScript Client

Hello!
We have several ASP.NET Core controllers with actions that look somewhat like this;
[HttpPost]
[ProducesResponseType(StatusCodes.Status201Created, Type = typeof(CreatedModel))]
[ProducesResponseType(StatusCodes.Status400BadRequest, Type = typeof(ValidationProblemDetails))]
public async Task<ActionResult<CreatedModel>> Create(
{
    // Do some work...
}

The usage of ValidationProblemDetails here seems to be causing issues in the TypeScript client that's being generated. It generates this code;
export class HttpValidationProblemDetails extends ProblemDetails implements IHttpValidationProblemDetails {
    errors!: { [key: string]: string[]; };

    [key: string]: any;

    /** Rest of the class removed for brevity */
}

export interface IHttpValidationProblemDetails extends IProblemDetails {
    errors: { [key: string]: string[]; };

    [key: string]: any;
}

export class ValidationProblemDetails extends HttpValidationProblemDetails implements IValidationProblemDetails {
    errors!: { [key: string]: string[]; }; /** <-- TS2612 occurs here */

    [key: string]: any;

    /** Rest of the class removed for brevity */
}

export interface IValidationProblemDetails extends IHttpValidationProblemDetails {
    errors: { [key: string]: string[]; };

    [key: string]: any;
}

This code then causes TS2612 in the ValidationProblemDetails class;
Property 'errors' will overwrite the base property in 'HttpValidationProblemDetails'. If this is intentional, add an initializer. Otherwise, add a 'declare' modifier or remove the redundant declaration.

From what I can tell, this happens because in ASP.NET Core, the ValidationProblemDetails class hides the Errors property it inherited from HttpValidationProblemDetails and replaces it with a new one. See ValidationProblemDetails.cs in the ASP.NET Core repo. Unfortunately I don't know enough about TypeScript or NSwag to suggest a solution here. I'm considering asking the ASP.NET Core team to remove the property since it looks pointless anyway, but I feel like NSwag should be able to handle this kind of situation somehow. I also found #4200 while researching this, which seems to describe a similar but not quite identical issue.
As a workaround, we've simply been removing the erroneous line manually whenever it shows up, but this obviously isn't ideal. We would really appreciate a more permanent solution.
We're using the NSwag.AspNetCore 13.8.2 and NSwag.MSBuild 13.8.2 packages on .NET 6. The TypeScript version we're using is 4.3. Let me know if more information is needed.

I have a similar situation using 13.19.0 and it can prevent switching to ES2022 as a TS target

Hi. I updated Swagger for the last version. The issue is reproduced. Is any news on this issue? This is the stopper for  ES2022.

I have a similar situation using package version  13.19.0. I also tried other versions but didn't work for me.
Did you found any solution for it?

i'm just staying with target: "ES2021" until this is fixed

I have a similar situation using package version 13.19.0. I also tried other versions but didn't work for me. Did you found any solution for it?

i'm just staying with target: "ES2021" until this is fixed

@lerich @mossykazemi @shtefanntz We ended up creating a workaround for this using a custom liquid template. It's a pretty simple change; we just added an extra check so that it no longer adds the Errors property for classes named ValidationProblemDetails like so;
{% for property in Properties -%}
{%   if ClassName != 'ValidationProblemDetails' and property.PropertyName != 'Errors' -%}
{%     if property.HasDescription -%}
    /** {{ property.Description }} */
{%     endif -%}
       {% if property.IsReadOnly %}readonly {% endif %}{{ property.PropertyName }}{% if property.IsOptional %}?{% elsif RequiresStrictPropertyInitialization %}!{% endif %}: {{ property.Type }}{{ property.TypePostfix }};
{%   endif -%}
{% endfor -%}

I've attached our full template below. This template also contains the workaround for #3580, including a small change that fixes the index signature for ValidationProblemDetails which the original workaround broke.
Class.liquid.zip

My work-around was to replace
[ProducesResponseType(StatusCodes.Status400BadRequest, Type = typeof(ValidationProblemDetails))]
by
[ProducesResponseType(StatusCodes.Status400BadRequest, Type = typeof(HttpValidationProblemDetails))]
as the typescript generated code is exactly the same, I don't foresee any issue


self-hosted-runner: false positive with static matrix

This is similar to #22, but with self-hosted-runner instead of template-injection.

Originally posted by @VorpalBlade in https://github.com/woodruffw/zizmor/issues/22#issuecomment-2453388681

To summarize what's happening here: we have some imprecision when looking at runs-on: ..., where ... is an expression (or a composite of expressions).
The most common kind of expression in that position is something like:
runs-on: ${{ matrix.os }}

i.e. one of the values of os in the expanded matrix.
In a case like that, what we want to do is (1) walk the possible expansions for matrix.os, and (2) only return a result here if any of them actually expand to self-hosted (or can't be fully solved, e.g. point to yet another expression).

#114.


Think on game rename

I think may be its a goo time to create own pixel art sprites for the game and as a result give it other name
Check name unique to:

Itch.io
Android maybe
iOS maybe
Steam (so windows, linux, macOS) maybe

TODO:

Change Game Name
Update repository name
Update Solution and Project names
Update Namespaces

Asteroids & Pixels

Name ideas:

Pixel Asteroids
Asteroids&Friends
Asteroids with Friends

asteroids overflow it is ❗


Fixing some versions for spring-data-cosmos release version

Fixing some versions for spring-data-cosmos release version

/azp run java - cosmos - ci


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_fb302f0d-6658-41ac-accd-dd45cb7e6cc2/pull/1 is merged into live branch.
Auto archive content to https://github.com/OPS-E2E-PPE/docs-archive-test-target_fb302f0d-6658-41ac-accd-dd45cb7e6cc2.git

Docs Build status updates of commit 8b9465f:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-10-09-16-22-25 has been deleted or has been force pushed: fatal: Couldn't find remote ref Archive_master_2019-10-09-16-22-25

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Recirculation always on

Describe The Bug:
My water heater seems to be perpetually in "recirculation" mode. In the Control-R app it always shows as "recirculating" and in Apple Home the device's status is always on.  The heater itself is not recirculating in this state, however when I power cycle the heater it immediately starts recirculating. It then will not recirculate again until the next power cycle.
It's entirely possible my heater is just in a weird state but it's strange that my attempts to turn off recirculation after power cycling are ignored.
Logs:
This is mean trying to toggle the heater off, those attempts are logged. I don't see anything else in the logs.
[06/10/2022, 16:42:14] [RinnaiControlR] setRecirculateActive to false for device null
[06/10/2022, 16:42:21] [RinnaiControlR] setRecirculateActive to true for device null
[06/10/2022, 16:42:26] [RinnaiControlR] setRecirculateActive to false for device null
[06/10/2022, 16:43:15] [RinnaiControlR] setRecirculateActive to false for device null

Plugin Config:
        {
            "username": "---",
            "password": "---",
            "recirculationDuration": 5,
            "temperatureUnits": "F",
            "minimumTemperature": 120,
            "maximumTemperature": 140,
            "platform": "RinnaiControlR"
        },

Environment:

Plugin Version: 1.0.16
Homebridge Version: 1.5.0
Node.js Version: v16.16.0
NPM Version: 8.11.0
Operating System: hb-service

Can you try cutting power to you Ctrl-R device for a few seconds, then restoring? I have noticed that mine occasionally goes unresponsive. In fact, I ended up putting my water heater on a smart plug, and creating an automation that cuts and restores power every day. Sad, I know.

I wasn't aware there was a way to cut the power only to the control-r unit, for me it's hooked up to my heater via a pair of wires...how do you do that?
I mentioned in the OP that I tried power cycling the whole heater (which includes the control-r unit), but that didn't work to get it out of its funky state.
I did seem to get it back into a working state by taking off the front cover of the heater and toggling the on/off button for the temperature controller. But that's super inconvenient as you might imagine...why they buried those buttons behind the front panel is beyond me.

If you cut the power to the entire unit for long enough (10 secs or so), the ctrl-r loses power as well. I know it's an inconvenient solution, but there's no way around the Rinnai firmware. Clearly their server-side stuff is plagued with similar problems.

Closing as issue appears to be resolved. Re-open if that's not the case.


Automated build test and release with github actions

Hi All,
I would like to see fully automated build, test, and release of gpufit with github actions. I think it could help make development easier and accelerate improvements to the project -- i.e. make the maintainers' lives easier :)
I've created a pull request >> #112 << for this addition to the project.
You can see an example build with windows binary artifacts here (on my fork's working branch).
I'm happy to help in any way I can, and am appreciative of all the great work the maintainers have put into this useful and powerful tool. This is the least I can do to say thanks to @superchromix, @adrianjp88, @jkfindeisen and others.
Kind Regards, Jim

Hi Jim,
This is a good idea, and thanks for the initiative.  I am not fully up to speed with Github actions, but I've done some reading and my current understanding is that automated builds can run on either Github-hosted servers or personal servers.  I would guess that Github servers wouldn't have GPUs installed, so this would require one or two dedicated test machines with the necessary hardware?  Can you outline your vision of how the automated build process would work for Gpufit in practice?
best,
Mark

Hi Mark,
I think you’re right that github hosted runners do not have GPUs.  Yet, the compilation and build process does not require GPUs — it just requires the cuda compiler.
Here is a possible vision — really, the sky is the limit, in terms of what can be automated.
Build on Push
The automated build process is run every time a push occurs. This gives immediate feedback to the person who pushed the code, as to whether the changes break the build or tests.
This also means that developers can work on the code (bugs can be fixed) without actually having to have the cooler compiler installed locally.
Build on Pull Request
The automated build process will also (optionally) run automatically for pull requests. This means that if a contributor works on the code, we will actually know immediately (before even merging the pull request) whether it breaks the build.
Build on Release Tag
We can use a tag format like “v2.0” to signal a release build. The action can detect this tag pattern and automatically create a new release and attach the artifacts.


File names with special characters not supported by Amazon handled

File name normalisation extended to replace all the unsafe characters by underscore.
The list of unsafe characters for file name as specified by Amazon is mentioned here:- http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html

Thanks 👍

Released v3.1.0 with this change.

:) 👍 Thanks!


Add dune build src/lib to unit test runner

This PR is a follow-on from #12098, fixing the remaining compilation errors when dune build src/lib is run in the repo.
This adds the command to the 'dev unit test' CI job, which will ensure that this compilation doesn't break again over time.
Mostly, this involves dune tricks to avoid building targets that we don't need in certain situations (e.g. not attempting to build a dynamic .so library from the rust code when compiling javascript tests).
Checklist:

[ ] Modified the current draft of release notes with details on what is completed or incomplete within this project
[ ] Document code purpose, how to use it

Mention expected invariants, implicit constraints

[ ] Tests were added for the new behavior

Document test purpose, significance of failures
Test names should reflect their purpose

[ ] All tests pass (CI will check this if you didn't)
[ ] Serialized types are in stable-versioned modules
[ ] Does this close issues? List them

!ci-build-me

Maybe put comments in the empty files indicating why they're there.

!ci-build-me


Logging shows no output from functions

Hey
i am using Microsoft.Azure.Functions.Worker.ApplicationInsights 1.0.0-pre3 and i can't see any output from my own logging inside the functions.
Currently my code looks like this:
var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(builder => builder.AddApplicationInsights().AddApplicationInsightsLogger())
    .ConfigureLogging(builder =>
    {
            builder.AddConsole();
            builder.Services.Configure<LoggerFilterOptions>(options => options.Rules.Clear());
    });

The last line was needed to get the logging towards Application Insights working. There was an issue mentioned by @brettsam
My function uses the ILogger from the DI, but i can't see anything on the console - Application Insights shows every log entry.

Duplicate of #1090 ?

@MO2k4 I am unable to reproduce this. Adding the console logger via .ConfigureLogging(builder => builder.AddConsole()) and logging from within a function outputs to console for me (using .LogInformation). I am also including the rule clearing call. Can you try again and see if you aren't adding filters later on in the startup?
Even without the .AddConsole I do see console logs show up. This is because we send logs over gRPC back to the host, which writes to the console for you. We will be removing this behavior eventually, and instead have the worker rely on .AddConsole only. Not sure when this will happen though.


Update docs

Link to new environment config files
reorder stakepool operations to a more logical sequence
rename mainnet-config.json and mainnet-topology-json to config.json and topology.json in line with file names in cardano-world
rename cold.counter to opcert.counter
rename node.cert to opcert.cert

bors +

bors r+


Undefined in generation.

https://github.com/themesberg/flowbite-svelte/blob/f3640e2c2342a563a8af29970c8f851d470f8d78/src/lib/buttons/Button.svelte#L80
if $$prop.class is not defined, this code generates undefined in the html.
as in...
"text-gray-900 hover:text-white border border-gray-800 hover:bg-gray-900 focus:ring-4 focus:ring-gray-300 font-medium rounded-lg text-xs py-2 px-3 text-center mr-2 mb-2 dark:border-gray-600 dark:text-gray-400 dark:hover:text-white dark:hover:bg-gray-600 dark:focus:ring-gray-800 items-center inline-flex undefined"
note the undefined at the end.

Thanks for the bug report. I just fixed changing it to:
{$$props.class ? $$props.class : ''}

v0.15.29

Close this for now. Please let me know if you find more bugs.


[gui][low prio] Saving patterns not intuitive

Saving pattern during game creation only possible by ticking a checkbox without any description (don't know if there are tooltips, at least not in Firefox),

tooltips added in #142


Youtube Ads

I want to know if the player works like Youtube player API and its show Youtube ads?
Thanks

Hi, the player works and is simpler to use than the YouTube player API. Also it's stable, the YouTube player API wasn't stable at all last time I used it.
For some reason the web based YouTube player doesn't play ads. Therefore no, this player doesn't play YouTube ads at the moment. That's beyond my control, since it's a limitation of the web based YouTube player.

Hi, the player works and is simpler to use than the YouTube player API. Also it's stable, the YouTube player API wasn't stable at all last time I used it.
For some reason the web based YouTube player doesn't play ads. Therefore no, this player doesn't play YouTube ads at the moment. That's beyond my control, since it's a limitation of the web based YouTube player.

I am planning to publish my app using this library. Can this be a reason for Play Store to reject the app?

@fouri no, this is the default behaviour of the web player, therefore it is not an issue.

@PierfrancescoSoffritti I don't have app:useWebUi=true as a parameter and ads are not shown. So it also uses the web player, right?

Yes, this player always uses the web player.


{humble} WIP: ros-image-world fixes for Humble Kirkstone

This is the latest revision to enable ignition and rviz2 to support building the turtlebot3 recipe on ROS Humble with
Yocto Kirkstone.
It requires meta-clang and meta-qt5. The following also needs to be added to local.conf:
DISTRO_FEATURES:append = " x11 opengl vulkan polkit"
PACKAGECONFIG:append:pn-clang = " libomp"
PACKAGECONFIG:append:pn-qtbase-native = " gui"
PACKAGECONFIG:append:pn-python3 = " tk"
Tested on Raspberry Pi 4 using the shell mode with this kas script found in the build branch of meta-ros:
oeros-kirkstone-humble-raspberrypi4-64.yml
Needs some work before I can merge this. I am just submitting this PR for additional feedback from people eager to support the Turtlebot3, rviz, or Ignition/Gazebo.

Tried out this PR and seeing these issues on my dev machine:
Ogre recipe is upgraded to 14.2.5 and the imgui issue is reolved. However, there show some warning about version mismatch:
WARNING: preferred version 1.12.12 of ogre not available (for item ogre)
WARNING: versions of ogre available: 14.2.5
WARNING: preferred version 1.12.12 of ogre not available (for item ogre)
WARNING: versions of ogre available: 14.2.5
WARNING: preferred version 1.12.12 of ogre not available (for item ogre-dev)
WARNING: versions of ogre available: 14.2.5

When trying to build rviz-rendering recipe, it throws a header missing error in an ogre related file. Not sure if this is related to the version mismatch above.
| /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/core2-64-robotpi-linux/rviz-rendering/11.2.12-1-r0/recipe-sysroot/usr/include/OGRE/RenderSystems/GL/OgreGLPrerequisites.h:60:10: fatal error: glad/glad.h: No such file or directory
|    60 | #include <glad/glad.h>
|       |          ^~~~~~~~~~~~~
| compilation terminated.

Besides, to build with meta-ros/meta-ros-humble, I still need these patches:

ignition-cmake2-vendor_%.bbappend
ROS_EXEC_DEPENDS:remove = "${ROS_UNRESOLVED_DEP-ignition-cmake2}"
slam-toolbox_%.bbappend
ROS_EXEC_DEPENDS:remove = "ceres-solver"
urdf_%.bbappend
ROS_EXEC_DEPENDS:append = " urdf-parser-plugin"

Hi @whni,
It's actually based on "kirkstone", however "kirkstone" and "kirkstone-next" both have the same commit at the moment, which is why both are listed under the "Signed-off-by" line on this page: https://github.com/ros/meta-ros/commit/9a857afebc18e0f426d87226bd085727ea9ce4ae
The -next branches contain commits that are pending being merged into their corresponding unsuffixed branches. The commit history on these branches may get rewritten as patches are tested and revised.  The -next branches are essentially a preview or a staging area for merging work where it can go through automated builds, etc before being merged in.   Once I merge into the main branches (eg. kirkstone) I do not rewrite commits or do anything that would stop a fast forward merge from happening if someone did "git pull".
The error you saw was related to me failing to submit the ogre recipe for 1.12.12.  I have added it to the PR: 602fa71c2409f2a749703105f957082ecb924a94
Hopefully that fixes the problem you saw.  Thanks for reporting it!
Regards,
Rob

Hi @robwoolley
Thanks for the quick fix!
Other than the ogre issue, I also need these patches to get the build correctly working on raspberry pi 4:

ignition-cmake2-vendor_%.bbappend
ROS_EXEC_DEPENDS:remove = "${ROS_UNRESOLVED_DEP-ignition-cmake2}"
slam-toolbox_%.bbappend
ROS_EXEC_DEPENDS:remove = "ceres-solver"
urdf_%.bbappend
ROS_EXEC_DEPENDS:append = " urdf-parser-plugin"

1 and 2 resolve errors during rootfs build step, while 3 resolves some runtime error such as:
[robot_state_publisher-1] terminate called after throwing an instance of 'pluginlib::ClassLoaderException'
[robot_state_publisher-1]   what():  package 'urdf_parser_plugin' not found, searching: [/usr]

Btw, did you ever test bitbake usb-cam?
I am seeing the error like this:
/src/ros2/usb_cam_node.cpp.o -c /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/usb-cam/0.8.0-1-r0/git/src/ros2/usb_cam_node.cpp
| In file included from /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/usb-cam/0.8.0-1-r0/git/include/usb_cam/usb_cam.hpp:50,
|                  from /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/usb-cam/0.8.0-1-r0/git/include/usb_cam/usb_cam_node.hpp:45,
|                  from /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/usb-cam/0.8.0-1-r0/git/src/ros2/usb_cam_node.cpp:34:
| /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/usb-cam/0.8.0-1-r0/git/include/usb_cam/formats/mjpeg.hpp: In constructor 'usb_cam::formats::MJPEG2RGB::MJPEG2RGB(const usb_cam::formats::format_arguments_t&)':
| /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/usb-cam/0.8.0-1-r0/git/include/usb_cam/formats/mjpeg.hpp:88:35: error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
|    88 |     m_avcodec(avcodec_find_decoder(AVCodecID::AV_CODEC_ID_MJPEG)),
|       |               ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|       |                                   |
|       |                                   const AVCodec*
| ninja: build stopped: subcommand failed.
| WARNING: exit code 1 from a shell command.

@whni I have made the changes you suggested.  Let me know if you would like me to give you credit for the fixes.  If so, please let me know what name and email address to use.

@whni I have made the changes you suggested. Let me know if you would like me to give you credit for the fixes. If so, please let me know what name and email address to use.

Hi @robwoolley it's fine. So glad that I can contribute to this project. Btw, we are planning a new project so hope we could cooperate in a long term :)

Hi @robwoolley
Reporting another issue when bitbake moveit package. Please see the attached moveit_build_fail.log
for full log
For the rosidl-adapter error, we can add it to build dependency of moveit-setup-framework recipe. However, I have no idea on the following errors. Thanks a lot if you could take a look
| -- rviz_ogre_vendor::RenderSystem_GL for IMPORTED_LOCATION_RELEASE: _render_system_gl_static_library_abs-NOTFOUND
| -- rviz_ogre_vendor::RenderSystem_GL for IMPORTED_LOCATION_DEBUG: _render_system_gl_static_library_abs-NOTFOUND
| CMake Warning at /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/lib/cmake/Qt5/Qt5Config.cmake:7 (message):
|   SkippingbecauseOE_QMAKE_PATH_EXTERNAL_HOST_BINSisnotdefined
| Call Stack (most recent call first):
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_common/cmake/rviz_common-extras.cmake:30 (find_package)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_common/cmake/rviz_commonConfig.cmake:41 (include)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/moveit_ros_visualization/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/moveit_ros_visualization/cmake/moveit_ros_visualizationConfig.cmake:41 (include)
|   CMakeLists.txt:13 (find_package)
|
|
| CMake Warning at /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/lib/cmake/Qt5/Qt5Config.cmake:7 (message):
|   SkippingbecauseOE_QMAKE_PATH_EXTERNAL_HOST_BINSisnotdefined
| Call Stack (most recent call first):
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_rendering/cmake/rviz_rendering-extras.cmake:30 (find_package)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_rendering/cmake/rviz_renderingConfig.cmake:41 (include)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_common/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_common/cmake/rviz_commonConfig.cmake:41 (include)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/moveit_ros_visualization/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/moveit_ros_visualization/cmake/moveit_ros_visualizationConfig.cmake:41 (include)
|   CMakeLists.txt:13 (find_package)
|
|
| CMake Warning at /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/lib/cmake/Qt5/Qt5Config.cmake:7 (message):
|   SkippingbecauseOE_QMAKE_PATH_EXTERNAL_HOST_BINSisnotdefined
| Call Stack (most recent call first):
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_default_plugins/cmake/rviz_default_plugins-extras.cmake:30 (find_package)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/rviz_default_plugins/cmake/rviz_default_pluginsConfig.cmake:41 (include)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/moveit_ros_visualization/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
|   /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/share/moveit_ros_visualization/cmake/moveit_ros_visualizationConfig.cmake:41 (include)
|   CMakeLists.txt:13 (find_package)
|
|
| CMake Warning at /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:6 (message):
|   SkippingbecauseOE_QMAKE_PATH_EXTERNAL_HOST_BINSisnotdefined
| Call Stack (most recent call first):
|   CMakeLists.txt:14 (find_package)
|
|
| CMake Warning at /home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/recipe-sysroot/usr/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:6 (message):
|   SkippingbecauseOE_QMAKE_PATH_EXTERNAL_HOST_BINSisnotdefined
| Call Stack (most recent call first):
|   CMakeLists.txt:15 (find_package)
|
|
| CMake Error at CMakeLists.txt:25 (qt5_wrap_cpp):
|   Unknown CMake command "qt5_wrap_cpp".
|
|
| -- Configuring incomplete, errors occurred!
| See also "/home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/build/CMakeFiles/CMakeOutput.log".
| WARNING: exit code 1 from a shell command.
ERROR: Task (/home/weihengni/Projects/robotpi/build/../layers/meta-ros/meta-ros2-humble/generated-recipes/moveit/moveit-setup-framework_2.5.5-1.bb:do_configure) failed with exit code '1'

For the moveit-setup-framework issue,
I can resolved by adding these:
ROS_BUILDTOOL_DEPENDS += " \
    rosidl-cmake-native \
"

EXTRA_OECMAKE += "-DOE_QMAKE_PATH_EXTERNAL_HOST_BINS='${OE_QMAKE_PATH_EXTERNAL_HOST_BINS}'"

inherit qmake5

However, inherit qmake5 has to be placed before inherit ros_${ROS_BUILD_TYPE} in the original recipe. Otherwise it will throw an error like
| ls: cannot access '/home/weihengni/Projects/robotpi/build/BUILD-robotpi-humble-kirkstone/work/cortexa72-robotpi-linux/moveit-setup-framework/2.5.5-1-r0/git/*.pro': No such file or directory

@robwoolley  do you know how to let inherit qmake5 take effect in the bbappend file before inherit ros_${ROS_BUILD_TYPE} in the original recipe? Otherwise, we may need you to directly patch the original recipe. Thank you so much!

I also see some build error about moveit-setup-srdf-plugins. You could try to build moveit package then can find all the errors

Hi @robwoolley will these fix been merged to kirkstone?

Hi @whni, yes I plan to merge the fixes to kirkstone after the work has been completed for rolling.  That work is nearly complete, you can check out the notes from the working group meeting for details: https://docs.google.com/document/d/1LqUjcu6vdlqVJO62SreCyjzddNDZhfO2n-7qYghY_cQ/edit#heading=h.3vrwbu9vio04

Checking in this topic? Any update?

@robwoolley Please let us know whenever this is merged. Thank you!

Hi @robwoolley could we know if this pull request will be merged soon? We need to decided if we can stick on humble. Thank you so much!

Looks like no one is looking at this pull request now? @robwoolley

Hi @whni,
I think this PR still needs work before it can be merged.  I haven't tried running anything on the hardware yet.  My focus has been on the Rolling and Styhead combo first since it is expected to be "unstable" then will backport any work to the "stable" Humble and Kirkstone combination.
I have been short on free time over the summer to make progress, but we have been making headway on getting CI/CD builds going for regression testing of all combinations.  (Check out the working group minutes for the latest status: https://docs.google.com/document/d/1LqUjcu6vdlqVJO62SreCyjzddNDZhfO2n-7qYghY_cQ/edit)
Have you been able to get graphics up and running on the Raspberry Pi hardware?   It would be a huge help to know that the existing recipes were working on the hardware.
Regards,
Rob

Hi @robwoolley
We didn't test all graphics components but just need those to be compiled successfully. On RPi 4, we are building our own image that includes ros-image-world. At least turtlebot bringup/cartographer are running good and rviz window is working

@robwoolley Hi, we are still waiting for this pull request on humble. Could we expect this to happen soon?


don't make table-cell font-size smaller

partly addresses #12806

hm I don't see this change reflected at https://deploy-preview-12807--kubernetes-io-master-staging.netlify.com/docs/concepts/extend-kubernetes/api-extension/custom-resources/
I see font-size: 0.85em in (compiled?) CSS. Maybe I need to regenerate those?

hm I don't see this change reflected at https://deploy-preview-12807--kubernetes-io-master-staging.netlify.com/docs/concepts/extend-kubernetes/api-extension/custom-resources/
I see font-size: 0.85em in (compiled?) CSS. Maybe I need to regenerate those?

Hello @ryan-williams. Currently you need to generate the CSS and commit these files to this PR.
What font size are you setting for the table cell text? Also, there are tables that have code markup.

This needs a rebase / merge conflicts fixing.
(Prow doesn't seem to have noticed).

hello! could we please resolve the conflicts or close this PR?

Hi @ryan-williams , are you still working on this? :)

I'll resurrect this this wknd, thanks


NEXT-23583: Fix Vatican City country name

1. Why is this change necessary?
The snippets for Vatican City are not correct.
Sprache - Aktuell - Sollte sein
de - Heiliger Stuhl - Staat Vatikanstadt (according to Wikipedia formal name in the German area)
en - Holy see - Vatican City
2. What does this change do, exactly?
Snippets are replaced  in database by migration and in installer.
4. Please link to the relevant issues (if any).
fix NEXT-23583
5. Checklist

[x] I have rebased my changes to remove merge conflicts
[x] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

I found another similar ticket: NEXT-23496 | Country naming convention
Should I include that in this PR?

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-23642
Please use this issue to track the state of your pull request.

Hey @fk-bitsandlikes thanks for your contribution, your changes are now merged! :tada: :blue_heart:


support changing auto_padding setting in CBC mode

This is to fix issue #29 .

Also, I've measured the performance using https://github.com/keepsimple1/libaes-utils . There is no visible performance changes.


[FEATURE REQUEST] Automatic creation of Columns

Describe the feature
As part of making the APIs easier, it might be a good idea to infer the type of data on the first assignment and create hangar columns if it doesn't exist. Few thoughts to make it a difficult decision:

The implicit creation of columns might make the user think that they could add data with different shape and different dtype
Inferring whether the columns should be variable_shaped might not be possible.

Thoughts?

The  variable_shape argument would be difficult to inter, but I think the bigger issue would be figuring out which column layout to use from data samples alone..
also does stockroom allow users to specify kwargs for the backend / backend_options parameters? hangars heuristics are really dumb... automatic methods to optimize this is part of hangar enterprise, but even with a reasonable set of options for a dataset, the final choice requires you to know a bit about the users environment and where they fall on the compression tradeoff (time vs space) scale. Neither hangar nor stockroom can handle this in full right now...
If you were able to infer basic info though, you'll need to consider how a user would correct a column definition if the heuristics were wrong?

No, if the user is expert enough to configure backend_options, he/she can rely on the hangar for that.
So the idea here, the user always has the choice to use hangar CLI to create the columns (and we'll make sure the user understand this through the document) but if they just need the stock to act as a dictionary and not worry about anything else, that's when heuristics are going to help. Does that sound reasonable to you?
About inferring the layout, I think the currently available layouts are inferrable. Isn't that true?. About the time series layout (and any future layouts), I am not sure.


Update glfw to v3.3 to align with pixel

and update mainthread to v2 and add v2 to glhf

Gonna wait on https://github.com/gopxl/mainthread/pull/2 to merge first, then I'll update this PR to have glhf point to mainthread/v2

Yep just need a review :D


Serious bug: Weird printout left in the code inserting debug info into data stream

We are helping a customer using the AT processor in a hardware product incorporating the ESP32-WROOM module. Things work BUT there is at least one or two serious bugs in the AT-processor.
One bug manifests itself with a printout appearing sometimes in the data stream coming from the AT processor when we use the IP server facility (using the ESP32 as an AP):
"id:%d,Len:%d,dp:%p"
Now... since unfortunately you do not have the source published (this is a perfect case where it would have helped us a LOT) I haven't been able to verify this is from your code until now - I simply realized I could scan the archive library, and I discovered the above in at_ipCmd.o.
Needless to say this royally messes up our communication! :)
There may also be a second issue because at some occasions I have also observed an actual AT command being in the data stream coming from the ESP32. That feels like a buffer bug of some kind.

Hi, sorry that we can not duplicate your problem, could you please provide more details about your test steps and AT logs?

"id:%d,Len:%d,dp:%p" is a debug log which will be print from UART0 when sending data through network, and AT commands/responses are going through UART1. They are using different hardware cables. Why the "id:%d,Len:%d,dp:%p" will bother you?

The problem is that we use UART0 for our AT commands, this is configurable using menuconfig!! So it definitely bothers us :)

Hi @gokr ，
You can output log via other uart or disable the log output.
Maybe you need configure it in menuconfig.
Component config ---> ESP32-specific ---> UART for console output

Thanks, we disabled the log output entirely and that removed it. Closing this one, but ... if I were you I would mention this as a potential "gotcha" in the README or something.


8.2 release breaks 8.1.x builds due to a bug in the Nativescript CLI

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

CLI: 8.1.5
Android Runtime: 8.1.1

Describe the bug
In current (8.1.x) versions of the nativescript CLI, a bug exists where the Gradle version is never actually pulled from the current platform (in this case @nativescript/android).  You can see this in the 8.1.5 tagged version of the nativescript-cli
The projectRuntimeVersion is looked up, but nothing is ever done with it to set runtimeGradleVersions, so it falls through to the next if block to look up the latest runtime.  It will then run the command npm view @nativescript/android@<whatever version> gradle --json to get the appropriate gradle info.  You can see that this behavior has been fixed in the master version of nativescript-cli, but has not been released.
However, in 8.2.0 of @nativescript/android, the gradle property was replaced with version-info breaking any builds that are using the current version of the nativescript cli.
To Reproduce
Create a project using Nativescript CLI 8.1.5.  Use @nativescript/android 8.1.x.  Try to build it.
Expected behavior
In the interim, the gradle propery should still exist as a fallback for 8.1.x CLI users

Update your CLI - should be backwards compatible and fix the issue.
See thread here: https://github.com/NativeScript/NativeScript/issues/9814#issuecomment-1062928925


Fix a ref-before-assign issue in tex tool

Trivial change to fix up an old omission. Also some formatting fiddles.
Fixes #2888
Signed-off-by: Mats Wichmann<EMAIL_ADDRESS>Contributor Checklist:

[ ] I have created a new test or updated the unit tests to cover the new/changed functionality.
[X] I have updated CHANGES.txt (and read the README.rst)
[ ] I have updated the appropriate documentation

Hrm.. can we test this one?

Well, of course... but then have to figure out how to craft a case that goes through the bad path.  There wasn't a repro included, just "I just hit this" in the issue. And it's TeX, which I basically don't know.