Version Catalog + Extensions

Extension (@aar, @jar) are not idiomatic to use with the new Version Catalog format.
Current Behavior or error
Say I have a coordinate com.fullstory:instrumentation-full:1.2.3@aar.
I can add everything except the extension to my TOML file (and probably settings.gradle.kts, but I haven't tried that):
[versions]
fullstory = "1.2.3"

[libraries]
fullstory = { module = "com.fullstory:instrumentation-full", version.ref = "fullstory" }

Then, when I actually use the artifact, I have to do this:
implementation(libs.fullstory) {
    artifact {
        name = "instrumentation-full"
        type = "aar"
    }
}

Although this technically works (thanks to @melix for the syntax help), it does mean that there's additional code I must now copy-paste everywhere that I want to use libs.fullstory. Also this is clearly not an optimal solution, since I have to duplicate the artifact name (instrumentation-full) everywhere.
My Suggestions
I understand that the catalog ought not have any knowledge of name/type/classifier/excludes, but I really do think this would be the easiest "fix" for most naive users:
# TOML suggestion
fullstory = { module = "com.fullstory:instrumentation-full", version.ref = "fullstory", type = "aar" }

My other suggestion is to add some sort of overload to DependencyHandler that allows the user to specify the type/extension/classifier as part of the implementation:
# Kotlin suggestion
implementation(libs.fullstory, type = "aar")

Long story short: this is intentional and very unlikely to change.
A version catalog talks about dependency coordinates. The type, name, classifier or even excludes are not part of the coordinates: they belong to the dependency declaration site: for the same GAV coordinates, different consumers may use different "variants" of the same thing, or not exclude the same things.
The type or classifier correspond to a variant selector, and that's why you have to use them at the declaration site:
dependencies {
    implementation(libs.fullstory) {
        artifact {
            type = "aar"
        }
    }
}

However, the name that you had to use shouldn't be required in this case, this looks like a bug. So in practice, I can only agree on declaration site DSL improvements.
Note that wrt to the @aar notation, this is just an "artifact" (pun not intended) of the way aar libraries are published today using the "pom format". With proper Gradle module metadata, you wouldn't have to declare @aar at all because Gradle would figure out automatically what variant to use. This makes it even clearer that the type="aar" doesn't belong to the catalog.

My 2c: classifier-like files in Maven lack their own metadata (e.g. you can't determine third-party dependencies for -tests.jar artifact :( ), so I agree embracing proper project modelling (e.g. standalone artifacts with their own pom or variants via Gradle Metadata) at cost of having to repeat type=.. for non-idiomatic cases makes sense.

Same complaint here. I have a module with multiple artifacts (e.g. classifier=native, ext=zip and classifier=programs, ext=zip), so I want tp be able to use something, like,
    native64(libs.nativefoo) {
        // 'name' is required and leaks catalog implementation details
        // name = 'native-bar'
        classifier = 'native'
        type =  'zip'
    }
    programs(libs.nativefoo) {
        // 'name' is required and leaks catalog implementation details
        // name = 'native-bar'
        classifier = 'programs'
        type =  'zip'
    }

But since it requires name I have to know something about what nativefoo is an alias for, which  in turn means if the artifact name changes I have to change it in all my projects, and not just the catalog. That defeats an advantage of catalogs if details leaked into multiple builds and have to be maintained.
I probably won't use the catalog for custom classifiers and types just yet,  until I have a way to do that without leaking details of the catalog into builds (i.e. the name thing is fixed). Otherwise, this looks to be a very cool and useful feature.
I am OK with using this syntax:
    native64(libs.nativefoo) {
        classifier = 'native'
        type =  'zip'
    }
    programs(libs.nativefoo) {
        classifier = 'programs'
        type =  'zip'
    }

But it would be nice if something like this worked too:
native64("${libs.nativefoo}:native:zip")

That's a different complain actually.
You just seem to miss wrapping your type and classifier in artifact { ... }.

That's a different complain actually.
You just seem to miss wrapping your type and classifier in artifact { ... }.

Is there some other way for me to use catalogs to resolve artifacts with custom classifiers/types or should I open a separate issue for this?

I don't understand what you're asking for. You should be able to write:
native64(libs.nativefoo) {
      artifact {
        classifier = 'native'
        type =  'zip'
    }
}

@melix
That construct is perfectly suitable, but without name it fails with the error,
Could not resolve all dependencies for configuration ':compileClasspath'.
Artifact name must not be null!

I don't want to use name because that exposes a hidden detail of the catalog definition, and if that changes every build that uses that artifact has to change too. For now -- and I'm using 7.0-r2-2 -- I am forced to use
native64(libs.nativefoo) {
    artifact {
        name = 'native-bar' // this is a hidden implementation detail of the catalog :(
        classifier = 'native'
        type =  'zip'
    }
}

In my comment above I mistakenly omitted the artifact closure. I meant to have it there. Nevertheless, it won't work without name.

The fact the name is mandatory sounds like a bug, as I said before (I'm saying sounds like, because there are often edge cases we don't think about with this kind of dependency management bugs). Please open an issue for this.

Done, see #16768

[versions]
fullstory = "1.2.3@aar"

[libraries]
fullstory = { module = "com.fullstory:instrumentation-full", version.ref = "fullstory" }

is this technically workable? appending the extension to the version.ref?

is this technically workable? appending the extension to the version.ref?

@kenshin171 good idea! Unfortunately that doesn't work because Gradle appends the @aar when constructing the maven repo URL, like so:
https://maven.fullstory.com/com/fullstory/instrumentation-full/1.16.2<EMAIL_ADDRESS>

I still wish the catalog feature would add support for something like (given a native64 configuration) native64("${libs.foo}:native@zip") so we can resolve artifacts with specific classifiers irrespective of the jar (i.e. unclassified) artifact. Without that support it's rather kludgy to manage classified artifacts with regard to version catalogs, and defeats the reason for using one.

I tried to use this artifact {} syntax in a Kotlin Multiplatform project, and was shot down because the method apparently doesn't exist. So add me to the list of people who want a decent way to do this. :(

What did you try? Which method is not available?

kotlin {
    sourceSets {
        val jvmMain by getting {
            dependencies {
                implementation(libs.lwjgl)
                runtimeOnly(variantOf(libs.lwjgl) { // <- Unresolved reference: variantOf
                    classifier("natives-windows")
                })

If the KGP API does not support it, don't use its syntax sugar and use the normal Gradle API. ;-)
For example:
kotlin {
    jvm()
}
val jvmMainRuntimeOnly by configurations
dependencies {
    jvmMainRuntimeOnly(libs.lwjgl) {
        artifact {
            classifier = "natives-windows"
        }
    }
}

or:
kotlin {
    jvm()
    sourceSets {
        val jvmMain by getting {
            dependencies {
                runtimeOnly(libs.lwjgl.map {
                    project.dependencies.create(it, closureOf<ExternalModuleDependency> {
                        artifact {
                            classifier = "natives-windows"
                        }
                    })
                })
            }
        }
    }
}


Profiling tool: Remove gettingResultTime from stages & jobs aggregation

This fixes https://github.com/NVIDIA/spark-rapids/issues/5099
As mentioned in the issue, gettingResultTime from TaskInfo is The time when the task started remotely getting the result which is not a value can be summed. Removed it from JobStageAggTaskMetricsProfileResult and SQLTaskAggMetricsProfileResult case classes and updated the docs and test results.

build

markdown failure is just 22.04 jar link that isn't published yet.


Bumped the sass loader version

Since sass-loader was sitting on an old version (4.0.0) I thought it prudent to update it since I ran into a bunch of issues with the older version.

Coverage remained the same at 95.283% when pulling ed8ebadfae332d042719d334489ed0cff39b0a97 on ryannealmes:up-sass-loader-version into 98aed8b888dce23a85841e3b3aa54fbfb8901ffb on coryhouse:master.

Thanks! 👍


Documentation: Add docs for debugging nuxt.js

What problem does this feature solve?
Developer experience, also might reduce the number of issues reported if devs knew how to step through the code when required.
What does the proposed changes look like?
Add simple debugging examples using
VS Code
WebStorm
Chrome

This feature request is available on Nuxt community (#c164)

Related:
https://github.com/nuxt/nuxt.js/issues/2781
https://github.com/nuxt/nuxt.js/issues/2528
https://github.com/nuxt/nuxt.js/issues/433
https://github.com/nuxt/nuxt.js/issues/2622
https://github.com/nuxt/nuxt.js/issues/2734
https://github.com/nuxt/nuxt.js/issues/1971
https://github.com/nuxt/nuxt.js/issues/2341
https://github.com/nuxt/nuxt.js/issues/1577
https://github.com/nuxt/nuxt.js/issues/365
https://github.com/nuxt/nuxt.js/issues/2080
https://github.com/nuxt/nuxt.js/issues/373
& more.

From https://github.com/nuxt/docs/issues/1139

Moved to
https://github.com/nuxt/nuxtjs.org/issues/479


Change footer to standard template

The footer should be redesigned according to the standard Code for Romania footer as displayed here
https://code4.ro/ro/

Fixed here: https://github.com/code4romania/monitorizare-vot-votanti-client/pull/52 One small update still needed. Final list of links is: Legal, Codul de conduita, Implica-te si Doneaza, the first two should be removed.


Is there a way to turn autocomplete back on without creating a new wrapper element around the input?

I can't seem to find an easy way to simply turn the autocomplete functionality back on after the autocomplete object has been uninitialized (unInit()).
The init() core function seems like a solution, but it's also responsible for creating wrapper element and moving the selected input inside it, as it's stated in the docs. After a few clicks back & forth (uninit() & then init() again, for instance) we are looking at something like this:

I know there's always a way to solve this by changing my design, or am I missing something here as well?

You can set wrapper: false in the root of your autoComplete.js config to prevent creation of the wrapper element. That said, this should probably be fixed properly.

@folknor thank you, somehow missed this one.

wrapper: false just fixed the symptom of The OP's issue. The issue is not being able to fresh re-intialize autoCompletejs instance. The unInit function just removes all event handlers but not replace the whole process.
Ability to re-initialize a fresh instance with all previous instances (of configured input selector) removed will also give benefit of dynamic configuration. As I understand currently we can't do thing like changing keys dynamically based on query.


financial reporting

double check if this is wanted with sharon, it might not be.

select criteria, days since rental, amount due, etc.
recurring report generation (ex first of every month) and email to user

Spoke to Jon, said he doesn't think we need it.  Closing this ticket.


refactor: update method name

fixes #208
The author of the issue might be too busy/have forgotten so I've taken the liberty to apply his suggested change.

Pull Request Test Coverage Report for Build 320

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 58.773%

Totals

Change from base Build 319:
0.0%

Covered Lines:
345

Relevant Lines:
587

💛  - Coveralls

Forgot this should probably be backwards compatible.. will make the change and reopen.

Actually, it seems that ff-find-the-other-file has existed at least since Emacs 24.1, which according to Melpa is the minimum requirement for cmake-ide. Reopening!


Create static private final Comparator for HostAndPort

Based upon suggestion in code review, created a static privae final
Comparator field to be used within the HostAndPort compareTo method
rather than constructing a new comparator each time.

@jmark99 I don't think you ever answered my question at https://github.com/apache/accumulo/pull/2551#discussion_r822894763 or when I made the same observation earlier at https://github.com/apache/accumulo/pull/2551#discussion_r821784698
There are still no test cases where null is used as the host, and I'm not sure if this comparator will handle that case very nicely.


Beginners ask for help

Hello, great gods, my previous script used asyncio.Queue and list to achieve asynchronous tasks, accidentally brushed to the saq,web function attracted me, to be able to check the progress of the task in real time, which is good.
But I do not know how to change my script to use saq to achieve, I am not bug, and I do not know who to communicate, I take the liberty of sending it to issues inside is OK?

you can join my slack channel and ask questions tobikodata.com/slack


Run update-core as a shell function instead of its own shell

This is the second part of https://github.com/Alexpux/MSYS2-pacman/pull/20
It fixes a crash that happens if $PS1 runs a subcommand.

I haven't thought carefully about whether all the stuff defined in update-core will be visible in the user's shell and cause problems for them in the case where update-core returns without updating anything.

You can run something in a sub shell by just enclosing in parentheses:
TEST=world; (TEST=hello; echo $TEST); echo $TEST
.. so I'd just do (/usr/bin/update-core) instead

Unfortunately, TEST=world; (export TEST=hello; echo $TEST); echo $TEST prints "hello" and "world" so I think the parentheses would defeat the point of this pull request.

Ah right, I didn't read it carefully enough. Can you fix the typo then "modif" -> "modify"? Yeah, I'm being pedantic at this stage.

The namespace pollution really bothers me; update-core defines a lot of shell functions with generic names.  I'll do some tests and see if it is sufficient to just have a while-loop at the end of update-core that asks the user to close the window if any packages were updated.


[WIP] Measurement error mitigation for expectation values

Summary
Add measurement error mitigation experiments for readout error mitigation of expectation value computations.
Three methods are supported

[x] Full A-matrix inversion mitigation
[x] Single-qubit tensor product A-matrix inversion mitigation
[x] CPTMP mitigation

Details and comments
TODO:

[x] Add CTMP method (@georgesbarron)
[ ] Fixup fitter classes
[ ] Add documentation
[ ] Add wrapper class that can use the three different mitigation methods as a method
[ ] Add tests

Could you please elaborate. In particular, isn't expectation value done on the device using standard-base measurements.

Does it mean that current API that appear in qiskit textbook and tutorials will be deprecated?
(e.g. complete_meas_cal, tensored_meas_cal, CompleteMeasFitter, TensoredMeasFitter)

@yaelbh This PR is to create an error mitigator object that can be calibrated and used to estimate a mitigated expectation value of a diagonal observable from a counts dictionary (essentially Eq (2)  in this paper). The main goal is to implement the CTMP method from the paper, but we are also re-implementing the original full and tensored A-matrix methods in this expval framework.
@ShellyGarion we may eventually deprecate the old methods, but this is a little different as its applying mitigation only to a diagonal expectation value estimate from a counts dictionary, not to the probability values the counts represent.

In the current code in master, the tensored case runs only two circuits to create the matrix, exploiting the knowledge that the error is local to single qubits: one circuit with label all zeros and one circuit with label all ones (could be any pair of labels whose xor is all ones). Instead of n circuits of the complete case. Is the reduction in the number of circuits preserved by this pull request?  @chriseclectic

The notebook imports TensoredMeasMitigator, which is never used. Is there automatic style and linting to notebooks?

Regarding the question that I raised in https://github.com/Qiskit/qiskit-ignis/pull/457#issuecomment-665710234, I checked and the answer is yes.

I've finished adding/cleaning up all the tests in the PR to this branch: https://github.com/chriseclectic/qiskit-ignis/pull/3/

Replace by #500


Adding Whitespace to Compiled JS

This afternoon I pushed a patch that adds linebreaks to our generated JavaScript..

Between expressions at the top level.

Between expressions in a class body.

Those two rules cover a large number of cases, which you can see by taking a peek at the self-compiled source:
https://github.com/jashkenas/coffee-script/blob/master/lib/coffee-script/scope.js
Any better ideas / patches for where and when to insert linebreaks?
Here's the diff:
https://github.com/jashkenas/coffee-script/commit/d2b040418899d80f7b40502f85dd0981fb60c595

I'm way late to this discussion, but I'm baffled by the change. Why insert extra whitespace only at the top level? I could buy "add a newline after each top-level function," which would enhance the readability of code like
_.each = -> ...
_.map = -> ...

but the change looks odd to me when my code is more like
console.log x
console.log y
console.log z

and I get
  console.log(x);

  console.log(y);

  console.log(z);

@trevorburnham: I think it's a little weird at times, too, but can you come up with a better heuristic? Or do you think we should just revert it entirely?
Re-opening for a little bit to encourage discussion. And because there was no logical end of discussion when this was closed.

Both @showell and @devongovett suggested preserving whitespace from CoffeeScript, which would certainly be a more sophisticated approach to the problem than any heuristic we could devise.
But if we must adopt a heuristic, the best I can think of is "Add an extra newline after each function declaration that comes at the end of an expression." So, a newline after
x = ->

and
foo: ->

and
app.get '/', ->

but not after
setTimeout (-> console.log 'foo'), 100

That's it? Just function literals? How about after any other syntax that introduces a block, such as if, while, for (when not used as a comprehension), class?

@michaelficarra Why not just preserve the newlines from the original CoffeeScript file?  This is what I would expect.  Different people like to format their code in different ways, and I think this should be preserved.

@devongovett: I am just offering alternatives because I don't think preserving whitespace would be easy.

I'm still +1 on preserving whitespace from the original source, and I'm still +0.5 on the patch.  Kudos to Jeremy for opening this up to discussion and kudos to @michaelficarra  for re-opening the ticket.  I think the patch is a step forward, and further discussion can lead to an even better solution.

@michaelficarra huh, why not?  I haven't really delved into the CoffeeScript compiler myself, but I would assume that files are processed linearly, which would tell me that it would know where the empty lines are.  Right?  Couldn't it just insert an empty line when it reaches one in the original source file?

@devongovett Files are parsed into a syntax tree which doesn't convey knowledge of empty lines.
Seems like it might be possible to include them as metadata in the tree? Not sure.

It would be also nice to preserve comments in compiled JS.
Many people still use JS and usually You provide both CS and compiled JS versions of the library files. And when they start to examine those files (to learn of find bugs) having the comments there would be nice.
In most cases, when the size matters You anyway run all those files via compressor that cut all the fat including comments.


Add SchemaConverter for Halogen

The most important converter was missing plus other misc fixes. Also this made me realize that many of Halogen's classes are dynamically created, which is painful.

Build failes, because of:
./openapi_builder/converters/halogen.py:95:16: F821 undefined name 'Reference'
        return Reference.from_schema(schema_name=schema_name)
               ^
     F821 undefined name 'Reference'

Error: Process completed with exit code 1.


More flexible calendar implementation [clean]

My PR #523 became a bit unwieldy so I decided to make a new PR from a fresh branch.
@ehebert, @twiecki, @jfkirk

This PR looks good - we are now going to run it through our internal validation gamut and let you know when we are ready to merge.

Good to hear, thanks!

@warren-oneill I added some notes for backwards compatibility. This will satisfy our internal requirements.

Coverage decreased (-0.01%) to 86.96% when pulling 663089cef064d09d0ab67a815aebaef728f6231e on warren-oneill:cal-clean into 208bdd3e45c6def910db6095813fdbb80a4212a2 on quantopian:master.

@jfkirk @ehebert what's the status on this?  I think I'm about to re-write a bunch of tradingcalendar.py to do ~a second's worth of work at import time, since that's having a substantial user-facing impact in the research environment.

@ssanderson I believe this is pending a run of the internal algo test harness.

@ssanderson @ehebert James put it through the internal test harness yesterday. I just need to rebase off master and then I think its ready to be merged.

I ran Scrutinizer from my fork and it was green. Is it possible to rerun it?

Closing this PR in deference to this: https://github.com/quantopian/zipline/pull/560


Create chungil-m

https://school.cbe.go.kr/chungil-m

@repryty lib/domains/kr/go/cbe/chungil-m: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@philipto I'm registering it in this format because my school uses a subdomain for email only. The school site address is "school.cbe.go.kr/chungil-m", but for the email address, it's registered as<EMAIL_ADDRESS>

@repryty lib/domains/kr/go/cbe/chungil-m: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.


Time estimates

I think attendees and MCTs need time estimates for each lab. The labs have varying levels of complexity and time requirements. Both groups of stakeholders need to know those time requirements for effective scheduling.
Please see https://github.com/MicrosoftLearning/PL-300-Microsoft-Power-BI-Data-Analyst/blob/Main/Instructions/01-prepare-data-with-power-query-in-power-bi-desktop.md for an example of timing information in another MOC course.
It's just a matter of Microsoft estimating the timing and publishing it within the lab instructions. An alternative would be to publish them in the MCT Trainer Prep Guide. I think having timing details included in lab instructions would be better because they would be accessible to attendees and be easier to change based on community feedback.

MOC Labs Review confirms this issue.

Great suggestion Vitaly. We unfortunately don't have this data from our side for all the labs in this course but as you mentioned, it will be even better if its coming from the community with averages/ranges across diverse audiences. Would you be willing to share your timings in MCT central to start?

I am closing this for now. Please share your timing if you feel comfortable doing so.


Bug/fault injection tests

As detailed in the commit message for constituent commits:

We're making the parsing more robust w.r.t. parsing percentage of packet loss
We've fixed the semantics of the new CommandSender::SendCommand -- much like all other functions of the Send* form, the function MUST consume the buffer passed in.  This implies both a fix to the test and to the function.

Codecov Report

Merging #550 into master will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master     #550   +/-   ##
=======================================
  Coverage   54.18%   54.18%
=======================================
  Files         331      331
  Lines       57623    57625    +2
=======================================
+ Hits        31223    31225    +2
  Misses      26400    26400

Impacted Files
Coverage Δ

...profiles/data-management/Current/CommandSender.cpp
10.15% <0.00%> (-0.11%)
:arrow_down:

src/lib/profiles/security/WeaveCert.cpp
88.96% <0.00%> (+0.45%)
: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 5b5e708...86a18f0. Read the comment docs.


Running Trafilatura in Browser?

I am wondering if you tried running Trafilatura in browser as a replacement for readability.js? This could be done with something like https://pyodide.org

Thanks for the suggestion, I'll think about it.

Hi @vprelovac, I just learned that Python is moving towards running in the browser, so I'll close this thread and hope that future versions allow for the code to run without modification :crossed_fingers:


PR for M3 r1.1

Fixed some link syntax
What type of PR is this?
Add one of the following kinds:

documentation : fixed some link syntax in CHANGELOG

What this PR does / why we need it:
PR for r1.1 - rc
Which issue(s) this PR fixes:

Meets release scope per #63
Special notes for reviewers:
This is the proposed PR for the M3 release

Please could Release Management kindly review this PR to allow merge to main / release with tag r1.1

Thanks @Kevsy ... I have created https://github.com/camaraproject/ReleaseManagement/issues/74 for the review which I will take next week.
I see that the CHANGELOG is already partly updated in advance, and also the version within in the YAML files are already set (should have happen in the release PR, but ok).
Few points which you can already address here in the PR:

the update of the README within the section Release Information (it has to be done in the Release PR as it is otherwise not part of the release tag)
add in the Changelog the section for the application-profile API
add the links to the .feature files in the API Readiness Checklist

Have a nice weekend!

Thanks @hdamker , changes to address your points now committed.

@Kevsy please delete the tag r1.1 which you created four days ago. It points to the merge commit of #66 which is NOT the approved release candidate. The correct process is described step by step here: https://github.com/camaraproject/ReleaseManagement/blob/main/documentation/API_Release_Guidelines.md#releasing-an-api-step-by-step.

Please find my review comments on connectivity-insights.yaml:
There are some critical deviations from the API Design Guidelines:

/network-quality/insights:

I don't understand the use of the of path element network-quality ... it would need to be a resource, but it isn't one.

If you think that this API is about network quality insights, why not calling the API network-quality-insights and the endpoint just /check or similar (it must be a verb, see below)?
if you are fine with the API name connectivity-insights, why not just use a verb here for this endpoint? check-network-quality might be an option, avoiding the second level

the operation is actually not creating a resource, the description is mentioning an insightId but that is not returned. If it would create a resource, there must be read and delete operations in the API.
it seems to be a "GET insights" using a POST operation due to the sensible information in the body, in which case the following guideline applies (cf. https://github.com/camaraproject/Commonalities/blob/r0.4.0-rc.2/documentation/API-design-guidelines.md#post-or-get-for-transferring-sensitive-or-complex-data):

When the POST method is used, the resource in the path must be a verb (e.g. retrieve-location and not location) to differentiate from an actual resource creation.

subscriptions endpoints don't follow the guidelines in https://github.com/camaraproject/Commonalities/blob/r0.4.0-rc.2/documentation/API-design-guidelines.md#resource-based-explicit-subscription

/network-quality/insights/subscriptions does not work
a proposal could be to call the separate API network-quality-insights-subscriptions, the endpoint would be then just /subscriptions

To ensure consistency across Camara subprojects, it is necessary that explicit subscriptions are handled within separate API/s. It is mandatory to append the keyword "subscriptions" at the end of the API name. For e.g. device-roaming-subscriptions.yaml

Further less critical comments:

scope name for the network quality insight connectivity_insights:network_quality_insight:write does not follow https://github.com/camaraproject/Commonalities/blob/r0.4.0-rc.2/documentation/API-design-guidelines.md#1161-scope-naming, with defines the structure as api-name:[resource:]action

the api-name is connectivity-insights, not connectivity_insights
there is no resource involved, see above
For POST operations with a verb, the action will be a verb, not a CRUD operation.

info.description - Authorization and Authentication: replace lines 62+63 with the updated text from ICM r0.2.0-rc.2 (link to main replaced). This can be done here in the PR or as an issue after the r1.1.

info.version: 0.4.0-rc.1 instead of "0.4.0-rc.1" (cf API-design-guidelines.md#info-object)

info.contact is optional and and may be added by API Providers documenting their APIs

responses:

CreateSubscriptionBadRequest400: "OUT_OF_RANGE" missing
Generic400: not aligned with https://github.com/camaraproject/Commonalities/blob/r0.4.0-rc.2/artifacts/CAMARA_common.yaml, "OUT_OF_RANGE" missing
CreateSubscription403: not aligned with https://github.com/camaraproject/Commonalities/blob/r0.4.0-rc.2/artifacts/camara-cloudevents/event-subscription-template.yaml, e.g. "INVALID_TOKEN_CONTEXT" missing, typo in line 1143 "SUSBCRIPTION_MISMATCH"
Device related error responses as defined in https://github.com/camaraproject/Commonalities/blob/r0.4.0-rc.2/documentation/API-design-guidelines.md#62-error-responses---device-object seem to be missing, e.g. in 422.
... please check all error responses for alignment

@Kevsy @maheshc01 Please see my comments above - I've stopped after the review of the connectivity-insights.yaml. How do you want to proceed? One option could be to first finish the connectivity-insights with one endpoint, and postpone the subscription API to a later release.

@hdamker Many thanks for the thorough review, and fully noted. Release tag has been deleted. Regarding the YAML we will confirm following the COI call later today.
Below my preferences based on the helpful advice above,:

if you are fine with the API name connectivity-insights, why not just use a verb here for this endpoint? check-network-quality might be an option, avoiding the second level

my preference /connectivity-insights/{version}/check-network-quality

the operation is actually not creating a resource, the description is mentioning an insightId but that is not returned.

I think we should not create a resource, rather the following point applies here:

it seems to be a "GET insights" using a POST operation due to the sensible information in the body, in which case the following guideline applies

...hence we should refactor according to the guideline

So those are the critical points for connectivity-insights.yaml , and the others will be addressed too.

One option could be to first finish the connectivity-insights with one endpoint, and postpone the subscription API to a later release.

@Mahesh, we can deicide this on the call later

@Kevsy thanks for the response. Regarding application-profiles there are also some comments and questions, but less severe. Should I add them here in similar way as above or would you prefer to have them in an issue?

Should I add them here in similar way as above or would you prefer to have them in an issue?

Thanks @hdamker - please add them here for now, and then we can break them all out in separate issues to make sure they are all covered. We can do this after the call today.

Please find my review comments on application-profiles.yaml:

L9 - info.description: the description is quite short and less concrete then the tag description in line 28/29. Might make sense to mention that there are future extensions planned. The mandatory text about Authorization and Authentication from ICM is missing
L36 - scope naming: connectivity_insights:policy:write -> application-profiles:write (resource is optional according to https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#1161-scope-naming, otherwise it would be application-profiles:application-profiles:write)
L48 - Why "*/*"? The API Design Guidelines mandate application/json (comment applies also to connectivity-insights.yaml)
L50 - Consider to define a schema like CreateApplicationProfile which contains today only NetworkQualityThresholds but can be extended with further optional fields (see also below).
L53 - response should be 201 (Created), not 200
L58 - Why returning only the ApplicationProfileId and not the full representation of the resource object? (that is inconsistent with updateApplicationProfile where the complete resource object is returned)
L65 - 404 is not an expected response, as the resource will be just created
L67 - 409 - which kind of "CONFLICT" do you expect here? How would a test case look like to generate this error message ?
L75 - Consider "PUT" vs "PATCH".

"PUT" will replace the complete resource object. It would also require some more definition what happens if

a) the applicationProfileId in the path does not yet exist (PUT would allow to create it, but I don't think that's what you want here, as the ids are generated on the server side) and
b) if the applicationProfileId in the path and the applicationProfileIdin the requestBody do not match (that should be an error response)

both topics can be avoided by using "PATCH" and in the requestBody NetworkQualityThresholds (or some UpdateApplicationProfile structure). That would be consistent with createProfile and with the description: "Update the network quality thresholds for an application ...". In this case you need to define that the NetworkQualityThresholds are replaced as a whole.

L78 - scope name: connectivity_insights:application_profile:write -> application-profile:write (cf. L36)
L82 - "Update the network quality thresholds for an application ..." -> "Update the network quality thresholds of an  application profile ..." (the profile can be used by multiple applications). Also the semantic of the PUT or PATCH should be defined, see comment on L75
L88 - typo
L97 - this description does not fit to "PUT" as PUT updates the entire resource with data that is passed in the body payload.
L99 - see comment on line 48
L129 - scope name, see above
L159 - see comment on L67
L169 - scope name, see above
L195 - see comment on L67
L313 ApplicationProfile definition:

shouldn't the applicationProfileId be required?
would an (optional) name (freely chosen by the API user) make sense?

L358ff - responses: consider to copy the used responses from https://github.com/camaraproject/Commonalities/blob/main/artifacts/CAMARA_common.yaml for consistency (but most responses do not apply for this API)

L359 in Generic400 ... "OUT_OF_RANGE" is missing from CAMARA_common.yaml

On the CHANGELOG.md:
There wasn't any previous release (at least not within CAMARA and in this CHANGELOG), so both APIs are new and have there first release here. If you want to compare to some previous version, please mention it (and where it can be found).

L21/22: template proposed here API-name1 vx.y.z (with version number)
L31: suggestion: ** 0.4.0-rc.1 is the first release-candidate version for the Connectivity-Insights 0.4.0**
L34: headline "Main changes" is not needed here, line 35 can follow directly after line 31.
L35: should be mentioned that his is the first release of the API

Same for application-profiles.

Thanks @hdamker - issues already created for the connectivity-insights.yaml changes noted above and PR incoming for approval by COI team. Once approved we will re-issue the 0.4.0-rc.1 PR for Release Management approval.
application-profiles issues/PR will follow.

New commit made to connectivity-insights.yaml per review feedback, fixes:

camaraproject/ConnectivityInsights/issues/68
camaraproject/ConnectivityInsights/issues/69
camaraproject/ConnectivityInsights/issues/70
camaraproject/ConnectivityInsights/issues/71
camaraproject/ConnectivityInsights/issues/72
camaraproject/ConnectivityInsights/issues/73

@hdamker with the latest commit. all the issues identified have been fixed with respective commits.
I understand it will be a lot to review each commit but could go over the spec at a high level and confirm if everything looks good?
@Kevsy for additional review and feedback.

I understand it will be a lot to review each commit but could go over the spec at a high level and confirm if everything looks good?

@maheshc01 yes, I can confirm on a high level view that the spec now looks good to me - but thanks for the understanding that I can't check the details and consistency.
Looking on the points relevant for Release Management I would ask you to reconsider the content of the CHANGELOG.md. As this is the first release of all three APIs - at least in CAMARA - and the first entry within the CHANGELOG.md some of the listed changes aren't relevant for the reader. E.g. I would change the lines

This version is primarily to align with the changes to Commonalities 0.4-rc.1 and Identity and Consent Management v0.2.0-rc.1.
This is the first release of the API.

Into something like:
This is the first release of the API. The version is aligned with Commonalities 0.4.0-rc.2 and Identity and Consent Management v0.2.0-rc.2.
(the second sentence is even not needed as it is already noted on the top of the release note)
and maybe list under "Added" the main functionality of the API (or even nothing ... as all is new).

I understand it will be a lot to review each commit but could go over the spec at a high level and confirm if everything looks good?

@maheshc01 yes, I can confirm on a high level view that the spec now looks good to me - but thanks for the understanding that I can't check the details and consistency.
Looking on the points relevant for Release Management I would ask you to reconsider the content of the CHANGELOG.md. As this is the first release of all three APIs - at least in CAMARA - and the first entry within the CHANGELOG.md, some of the listed changes aren't relevant for the reader. E.g. I would change the lines

This version is primarily to align with the changes to Commonalities 0.4-rc.1 and Identity and Consent Management v0.2.0-rc.1.
This is the first release of the API.

Into something like:
This is the first release of the API. The version is aligned with Commonalities 0.4.0-rc.2 and Identity and Consent Management v0.2.0-rc.2.
(the second sentence is even not needed as it is already noted on the top of the release note)
and maybe list under "Added" the main functionality of the API (or even nothing ... as all is new).

@hdamker
I will go ahead with the recommended the changes as per this comment- "This version is primarily to align with the changes to Commonalities 0.4-rc.1 and Identity and Consent Management v0.2.0-rc.1."
I need further clarification on content for "Added" and "Changed" sections. The current content in the 2 sections reflect the scope identified for the FALL meta release which is again part of the release management process.
Hence even though this is the first version of the API, there was a scope identified based on the initial contribution and what is required by the commonalities group.
From that perspective that content in Added and Changed is still valid.
I am good with either way, but with this additional context could you share your recommendation on what the change log should contain.

@maheshc01 I have also no strong opinion about the content of the CHANGELOG for the first release (and it will be same for the public release which will follow already next week). There is just no release to which you compare, so everything is new, nothing changed, nothing added.
Regarding the approval from Release Management: we discussed today within the Release Management call that @rartych will take over the last review run across the APIs, focussed on Release Management topics, so he is now assigned to https://github.com/camaraproject/ReleaseManagement/issues/74. It would be great if we can get this done within tomorrow's business day, including the Codeowner approval by @Kevsy, the merge and the creation of the release, so that we have a clear state for the TSC on Thursday.

@maheshc01 I have also no strong opinion about the content of the CHANGELOG for the first release (and it will be same for the public release which will follow already next week). There is just no release to which you compare, so everything is new, nothing changed, nothing added.
Regarding the approval from Release Management: we discussed today within the Release Management call that @rartych will take over the last review run across the APIs, focussed on Release Management topics, so he is now assigned to camaraproject/ReleaseManagement#74. It would be great if we can get this done within tomorrow's business day, including the Codeowner approval by @Kevsy, the merge and the creation of the release, so that we have a clear state for the TSC on Thursday.

Thanks for the feedback @hdamker.
in that case i will leave the content of Added and Changed as is in the changelog as it reflects the changes done as defined in the scope of the fall meta release.
@Kevsy could you approve and merge the change and help me with creating the release.

@Kevsy Just wait shortly for the final review by @rartych - he will do the approval on behalf of @camaraproject/release-management_maintainers as @tanjadegroot is still on vacation.

@Kevsy Small typo correction: in application-profiles-API-Readiness-Checklist.md line 3:
Checklist for application-profiles v0.3.0-rc.1
API name is application-profiles - plural

The  # Authorization and Authentication section in info.description needs to be updated to the latest version of the template defined in ICM  in all .yaml files - see the explanation in https://github.com/camaraproject/IdentityAndConsentManagement/issues/185
The template: https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#mandatory-template-for-infodescription-in-camara-api-specs

hi @rartych ,
thank you for the review comments. Have accepted all of your commit suggestions and commits additional changes against issues created based on your review comments.
Please take a closer look at issue #95 . Need your inputs on that in case i missed something.
Thank you!

Hi @Kevsy i see @rartych  has approved the PR. Could you approve the changes, merge and advice on the next step of release mgmt.

@Kevsy will you also create the r1.1 release or should I take that for you?

@herbert @mahesh I  can do it now :)

@hdamker r1.1 released :white_check_mark:
@mahesh you can now proceed with the PR for M4

@maheshc01 @Kevsy Would be good if you could correct the following within the CHANGELOG for r1.1  in course of the M4 release PR (versions should all have -rc.1 as appendix). There is always something which makes it through the reviews :-)

r1.1 - rc
Release Notes
This release contains the definition and documentation of
Connectivity Insights API v0.4.0
Connectivity Insights Subscriptions API v0.4.0
Application Profiles API v0.3.0

Within the GitHub release description I have already edited it.
Release tracker pages updated with the release tag r1.1


Integrate all required ontology processing into ontology preparation

Context
The cellxgene-schema CLI downloads and processes pinned ontologies to address the schema requirements.
There is separate (distributed in the code base) ontology processing occurring for filter by metadata, filter with ontology awareness, gene expresssion, and cell census.
We should investigate integrating all required ontology processing into the ontology preparation step for the cellxgene-schema CLI  to eliminate duplication of code and ensure that all features are based on the pinned versions of the ontologies.
See Proposal: Standardization of ontology-derived process and assets of CELLxGENE Discover.

@atolopko-czi also writes:
I've attempted to capture the currently ad hoc, manual Schema Upgrade Process. This can serve as requirements for what processes and configuration updates need to be automated and simplified in order to address this story.

I've attempted to capture the currently ad hoc, manual Schema Upgrade Process. This can serve as requirements for what processes and configuration updates need to be automated and simplified in order to address this story.

Issue moved to chanzuckerberg/single-cell #446 via Zenhub


Can't display on Internet Explorer

Following up on this issue I saw myself adding @angular/elements to my project, which worked great, except on Internet Explorer, where custom elements don't seem to be supported.
Even after trying out multiple polyfills and such I'm unable to load the report, is there no alternative for this?
'customElements' is not defined
angular unable to get property 'defineProperties' of null or undefined

Facing same issue here, any update on the fix please?

Could you please provide the solution to show the SSRS in Internet Explorer

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Is the ngx-ssrs-reportviewer is working in the Internet Explorer ? . It is not working for me

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Is the ngx-ssrs-reportviewer is working in the Internet Explorer ? . It is not working for me

Yes it works for me fine on IE11.

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Is the ngx-ssrs-reportviewer is working in the Internet Explorer ? . It is not working for me

Yes it works for me fine on IE11.

If you don't mind ,Could  you please provide me steps to work in IE 11

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Is the ngx-ssrs-reportviewer is working in the Internet Explorer ? . It is not working for me

Yes it works for me fine on IE11.

If you don't mind ,Could you please provide me steps to work in IE 11

The steps are there in the link I have shared, under the section "Missing Polyfills for Legacy Browsers (IE11)"..Have you done all those installs?
what is the error you get? add some screen shots or details around issue you are facing.

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Is the ngx-ssrs-reportviewer is working in the Internet Explorer ? . It is not working for me

Yes it works for me fine on IE11.

If you don't mind ,Could you please provide me steps to work in IE 11

The steps are there in the link I have shared, under the section "Missing Polyfills for Legacy Browsers (IE11)"..Have you done all those installs?
what is the error you get? add some screen shots or details around issue you are facing.
First time when we run the application blank page is Showing. After refreshing the same page we are the error CustomElem is undefing. PFA of Screenshot

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Is the ngx-ssrs-reportviewer is working in the Internet Explorer ? . It is not working for me

Yes it works for me fine on IE11.

If you don't mind ,Could you please provide me steps to work in IE 11

The steps are there in the link I have shared, under the section "Missing Polyfills for Legacy Browsers (IE11)"..Have you done all those installs?
what is the error you get? add some screen shots or details around issue you are facing.
First time when we run the application blank page is Showing. After refreshing the same page we are the error CustomElem is undefing. PFA of Screenshot

I had the same issue, I just did 2 changes as mentioned in the doc, I have these screenshot of polyfill.ts and tsconfig screen grab, this worked for me, hope this helps..

Could you please provide the solution to show the SSRS in Internet Explorer

I installed all the recommended imports in the polyfill.ts and also in the tsconfig changed the lib to es2018
"lib": [
"es2018",
"dom"
]
Link helped me, https://medium.com/better-programming/how-to-fix-your-angular-app-when-its-not-working-in-ie11-eb24cb6d9920, it works fine for me now on IE as well.

Is the ngx-ssrs-reportviewer is working in the Internet Explorer ? . It is not working for me

Yes it works for me fine on IE11.

If you don't mind ,Could you please provide me steps to work in IE 11

The steps are there in the link I have shared, under the section "Missing Polyfills for Legacy Browsers (IE11)"..Have you done all those installs?
what is the error you get? add some screen shots or details around issue you are facing.
First time when we run the application blank page is Showing. After refreshing the same page we are the error CustomElem is undefing. PFA of Screenshot

I had the same issue, I just did 2 changes as mentioned in the doc, I have these screenshot of polyfill.ts and tsconfig screen grab, this worked for me, hope this helps..

I am facing the below issue . Cant resolve

Marking as resolved with @karthiktanj  comments.  Let me know if running into issues with IE11 in latest version and I can add specifics to the docs.  😄


request feeder file

I wrote some wrapper code around this gem to take in a file that contains all the necessary request data
Example:
vra_blueprint_requests:
  - oracle_test_vm1:
      catalog_item_id: a9cd6148-6e0b-4a80-ac47-f5255c52b43d
      catalog_item_name: 'Oracle_system'  # in case the ids change per environment
      properties:
        cpus: 2
        memory: 4096
        requested_for<EMAIL_ADDRESS>        lease_days: 3
      parameters:
        my_parameter:
          type: 'string'
          value: 'my value'

Snippet of wrapper code
def create_request(name, request_data)
  logger.info("Creating request for #{name}")
  # convert keys to symbols
  properties = Hash[request_data['properties'].map{|(k,v)| [k.to_sym,v]}]
  parameters = request_data['parameters']
  item_id = request_data['catalog_item_id']
  catalog_request = vra.catalog.request(item_id, properties)
  # need to further set the properties
  parameters.each do | p_name, p_values |
    catalog_request.set_parameter(p_name, p_values['type'], p_values['value'])
  end
  request = catalog_request.submit
end

# creates requests based on a request file that is fed into this script
def create_requests(properties_file)
  request_data = YAML.load_file(properties_file)
  request_data['vra_blueprint_requests'].map do | data |
    item_name = data.keys.first
    item_data = data.values.first
    create_request(item_name, item_data)
  end
end

create_requests(properties_file)

If this is useful to anyone I can make a PR.

Hi, @logicminds! This is a really neat idea, and I'm glad to see you using this gem. I don't think this feature belongs in the gem itself, freeing up the gem to be strictly an API client gem. However, I'd like to encourage you to create a new gem that relies on this one to implement your feature. Others may find it very useful as well.
~Adam


DEC-1156: Create audio video models

This adds the Audio and Video models. I ended up making our own version of enum that works with store_accessors now that we have 3 different entities each with their own state system. It works just like rails enum, except you can pass a store accessor so that the enum value will be stored in that store instead of on the base of the model.

Coverage increased (+0.002%) to 95.531% when pulling d329227b2b9664f46cb5a9824adb394904ec73c1 on DEC-1156-Create-AV-Models into 04af9a389bcb5d580b1263acdc22bf8d5bb38eaa on master.

Coverage decreased (-57.4%) to 38.167% when pulling 796941a547b7e3765e62394c932d0c4b104b1218 on DEC-1156-Create-AV-Models into 04af9a389bcb5d580b1263acdc22bf8d5bb38eaa on master.

Coverage increased (+0.002%) to 95.531% when pulling 20f86cc58d1e5eba2b53a15fd59dce2d3aefbff3 on DEC-1156-Create-AV-Models into 04af9a389bcb5d580b1263acdc22bf8d5bb38eaa on master.

Please ignore the hound issues on the store enum file. This was mostly a copy/paste of rails enum and I'd rather not drift too far from the original just to fix style guide issues.

I didn't see that the enum code was a copy/paste from rails. I was suggesting we bring that up to our code standards if we're adopting that code into our base - most are pretty easy fixes. Apart from that, after the other Hound issues are fixed than 👍

👍


Issue 1.caceres.initial merge to master

Initial beta version ready.  Merge to master.

Issue number: #1


TypeError checks for libraries that don't support type annotations.

This PR is follow up to #125. This PR includes type checks for modules using trio_websocket and cobs.  Type checks for modules using serial is not added yet.

For records-keeping:

This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? Yes
Were any of these contributions also part of work you did for an employer or a client? No
Does this work include, or is it based on, any third-party work which you did not create? No


SDL 2.0.5 and gamecontrollerdb.txt

I'm trying to load the current file and do look-ups on it for testing.  I'm running on WIndows 10.  Code looks like this:
int nmaps = SDL_GameControllerAddMappingsFromFile("gamecontrollerdb.txt");

SDL_JoystickGUID guid = SDL_JoystickGetGUIDFromString("341a3608000000000000504944564944");
char gu[51];
SDL_JoystickGetGUIDString(guid, gu, 50);
char *tst = SDL_GameControllerMappingForGUID(guid);
if (tst)
	printf("   %s", tst);
else
	printf("   lookup FAILED: %s", SDL_GetError());

nmaps is 31... however, there appear to be 46 mappings for Windows DINPUT devices in the file... so I'm not sure why they aren't all loaded.
tst is NULL ... there is no error reported by SDL_GetError().

As it turns out, v2.0.5 uses the new format for the GUIDs but doesn't have the backwards compatibility fix.


Onboading Interop testing on Openshift CI

What type of PR is this?
/kind enhancement
What does this PR do / why we need it:
This PR adds a new script for onboarding interop testing on Openshift CI
Have you updated the necessary documentation?

[ ] Documentation update is required by this PR.
[ ] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes #?
Test acceptance criteria:

[ ] Unit Test
[ ] E2E Test

How to test changes / Special notes to the reviewer:

/test all

/test v4.10-kuttl-sequential

/test v4.9-e2e

/lgtm
/approve


Syntactically invalid block when missing blocks from Hare output

If a miner is missing a block that is part of the Hare output set and in the following layer it produces a block, it will produce a syntactically invalid block, since it will vote on a block (from the output set) that it does not have.
The miner should either fetch the block that it misses when the Hare terminates, or not vote on that block.

The correct thing to do is to make sure, when building a block, that votes is a subset of view.
Would be good to start a fetch sync of the missing blocks when the Hare terminates.


Provide keyboard input

It's really freaking hard to read the state of the keyboard without calling curses.initscr().getch(). Let's make it easier on people; I've had 2 requests about it. Here's one implementation, from http://love-python.blogspot.com/2010/03/getch-in-python-get-single-character.html:
import sys
import termios
import fcntl

def myGetch():
    fd = sys.stdin.fileno()

    oldterm = termios.tcgetattr(fd)
    newattr = termios.tcgetattr(fd)
    newattr[3] = newattr[3] & ~termios.ICANON & ~termios.ECHO
    termios.tcsetattr(fd, termios.TCSANOW, newattr)

    oldflags = fcntl.fcntl(fd, fcntl.F_GETFL)
    fcntl.fcntl(fd, fcntl.F_SETFL, oldflags | os.O_NONBLOCK)

    try:
        while 1:
            try:
                c = sys.stdin.read(1)
                break
            except IOError: pass
    finally:
        termios.tcsetattr(fd, termios.TCSAFLUSH, oldterm)
        fcntl.fcntl(fd, fcntl.F_SETFL, oldflags)

As you can deduce from the above, you can do it with echo or without, async or blocking (see curses docs for that latter bit).

This is resolved in 'blessed-integration' branch.

The fork blessed contains full keyboard (even with windows!), with plenty of fun examples and successful use in downstream 3rd party apps, please enjoy.
https://blessed.readthedocs.io/en/latest/keyboard.html


samv7: add support for 1 wire over UART/USART

Summary
SAMv7 does not have dedicated 1 wire driver but this can be emulated with UART/USART peripheral and some external HW (TX/RX connection etc). This adds support for 1 wire on SAMv7.
Impact
New SAMv7 driver.
Testing
Tested on SAMv7 MCU and DS2401 one wire device.

@michallenc please include an entry 1-Wire in the supported devices listing: https://nuttx.apache.org/docs/12.2.1/platforms/arm/samv7/index.html

@michallenc please include an entry 1-Wire in the supported devices listing: https://nuttx.apache.org/docs/12.2.1/platforms/arm/samv7/index.html

Good point, done @acassis.


how to trigger validation in a single step

how to validate all the fields? let say I am in a form wizard and I want to validate all the input when user clicks next step., how to do that?

Validation happens automatically when you try to read it state. Simply check $v.$invalid in your method before redirecting to the next step.

ok, what about custom error message based on type of validation failed.
Thanks & Regards,

Rifaudeen
Sent from Mobile
On 24 Jun 2017 15:27, "Paweł Grabarz"<EMAIL_ADDRESS>wrote:

Validation happens automatically when you try to read it state. Simply
check $v.$invalid in your method before redirecting to the next step.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/monterail/vuelidate/issues/162#issuecomment-310833112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEfI1fxFxiX7HW5aPr3ov3v2oEOzYhA0ks5sHPKlgaJpZM4OES80
.

Use any translation lib and use $params key as it's input.


Empty Clauses

Modified pigosat.AddClauses so that empty clauses are no longer ignored and make the formula unsatisfiable; modified tests consequently.

Please amend the docstrings for AddClauses and for type Clause to say that "Empty clauses are no ignored and make a formula unsatisfiable."

Ref #14

@sacado My goal is to merge this PR once #12 is merged. Would you mind hitting Edit on the PR and click "Allow edits from maintainers"? This will allow me to change some minor things without having to send a PR to your branch first.


Update features-activation-map

I have added info about colorRebeccapurple in caniuse (v 1.0.30000652).
https://caniuse.com/#feat=css-rebeccapurple

We should probably add the correct caniuse version as peerdeps, that will solve #357.
Can you take care of this?

Done

@MoOx There's also a PR for that here: https://github.com/MoOx/postcss-cssnext/pull/359


DevToolsDriver generating its own karateRequestId, and karate-netty project update to include it in logback

Description
DevToolsDriver generating its own karateRequestId, and karate-netty project update to include it in logback

Relevant Issues : (compulsory)
Relevant PRs : (optional)
Type of change :

[x] New feature
[x] Bug fix for existing feature
[ ] Code quality improvement
[ ] Addition or Improvement of tests
[ ] Addition or Improvement of documentation

@ptrthomas
Interesting that the source branch build is fine, but merge build broke - might be worth clearing TravisCI cache to see if that fixes it?
I've also made a possible fix playground/see-what-fixes-travisci-build-issues.
Take a look and let me know what you think. Might even worth be merging into non-develop branch just to see if problem is TravisCI cache of branch build.
Summary of the changes

Connection pool ActiveMQ, which would help re-use sessions
Timeout on createSession, not wait indefinately (10 seconds)
Schedule queue send instead of waiting, similar to Netty - unblocks publisher

@michaelpro1 I'm desperate :) please go ahead with all the changes except the travis cache - that is only for the maven repo afaik

Could you make a branch off develop to test it out? That will avoid polluting develop with random changes. If it doesnt work you can rollback that branch to be back to develop, while also testing out the theory of bad cache in TravisCI


Sudo access not working because of hard coded value

It looks like there’s a logic bug in the PEM SSH orchestrator:
I noticed that on https://github.com/Keyfactor/pem-pkcs12-remote-orchestrator/blob/main/PEMStoreSSH/RemoteHandlers/SSHHandler.cs
line 192, sudo is hard coded to be disabled when the orchestrator tries to create the certificate files.
      public override void CreateEmptyStoreFile(string path)
        {
            RunCommand($"touch {path}", null, false, null);
            //using sudo will create as root. set useSudo to false
            //to ensure ownership is with the credentials configued in the platform
        }

However, this means that the user performing the sudo commands might not be able to create the file
as it doesn’t have access to that path:
[user@server ~]$ touch /etc/ssl/certs/certificate.crt
touch: cannot touch ‘/etc/ssl/certs/certificate.crt’: Permission denied
[user@server ~]$

An idea (not necessarily the best one) if we want to maintain the original owner is to store the acting user
in a variable and modify the permissions after file creation, or create the file using another function or command
which allows specifying the user.

Thanks for creating this issue @daydr3am3r - I am fixing this with a patch release in both this repository (for the KF 9 Universal Orchestrator) and will get a patch out for the original Windows Orchestrator repo (versions < 2 of this project) now found @ https://github.com/Keyfactor/pem-pkcs12-remote-windowsorchestrator


Verify CSSRule#selectorText setter works in chrome

It doesn't work in all other browsers and style.innerHTML is also not updated after setter is used. The question is whether it worked as a setter and the new selector does actually work. Then its not a big deal if style.innerHTML getter returns the old version.

Ok verified it works, however innerHTML of style node is not updated.


refactor(ast, ast_codegen): use generate_derive for implementing GetSpan and GetSpanMut traits.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#4735  👈
#4732
#4731
#4728
#4730
#4729
#4726
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rzvxa and the rest of your teammates on  Graphite

@Boshen I saw your comment on using #[generate_derive(GetSpan)] a tad bit late. Do you want me to refactor it?


4.1.0 publish breaks when publishing an integer

This was working fine up until 4.0.6 but starting in version 4.1.0, publishing integers throws the following error.
/node_modules/@redis/client/dist/lib/client/RESP2/encoder.js:20
            throw new TypeError('Invalid argument type');
                  ^

TypeError: Invalid argument type
    at encodeCommand (/node_modules/@redis/client/dist/lib/client/RESP2/encoder.js:20:19)
    at RedisCommandsQueue.getCommandToSend (/node_modules/@redis/client/dist/lib/client/commands-queue.js:187:45)
    at Commander._RedisClient_tick (/node_modules/@redis/client/dist/lib/client/index.js:429:76)
    at Commander._RedisClient_sendCommand (/node_modules/@redis/client/dist/lib/client/index.js:413:82)
    at Commander.commandsExecutor (/node_modules/@redis/client/dist/lib/client/index.js:167:154)
    at Commander.BaseClass.<computed> [as publish] (/node_modules/@redis/client/dist/lib/commander.js:8:29)

Environment:

Node.js Version: 16
Redis Server Version: 4
Node Redis Version: 4.1.0
Platform: Ubuntu

@a-koka @byron70 in previous versions (4.0.0-4.0.6) some values were incorrectly converted into strings, which could cause unexpected behaviors (see #1898 for example).

I am currently on 4.1.0 and facing the same issue @leibale

I'm not sure if I follow this thoroughly. Publishing integer values has worked for the longest time until 4.1.0. Are we saying that publishing integers is no longer supported?
redisPubClient.publish('channel', 1) used to work but now has to be written as redisPubClient.publish('channel', '1')

@leibale this is definitely a regression, the addCommand is also now broken with integer/boolean values. If https://github.com/redis/node-redis/issues/1898 complains about converting undefined, null to emtpy strings, shouldn't that particular error be fixed instead of completely stop conversion of any non-buffer, non-string arguments?

import * as redis from 'redis';
import session from 'express-session';
import connectRedis from 'connect-redis';

const RedisStore = connectRedis(session);
const redisClient = redis.createClient();
await redisClient.connect();

app.use(
        session({
            name: 'qid',
            store: new RedisStore({
                client: redisClient as any,
                disableTouch: true,
            }),
            cookie: {
                maxAge:<PHONE_NUMBER>0,
                sameSite: "lax",
                secure: false
            },
            saveUninitialized: false,
            secret: "test",
            resave: false
        })
)

I am not sure if I am doing this right, but something similar has worked for me before. So now should I be making maxAge a string? @leibale

In this version 4.1.0, Date values are not working anymore too . Before, they worked fine.

Hi, some solution for this issue?

hi facing the same issue solution yet

It works for me adding createClient option(legecyMode: true) and connect without await.
import connectRedis from "connect-redis";
...
    const redisClient = createClient({
        legacyMode: true,
    });
   redisClient.connect();

I got the same error. It works for me adding createClient option(legecyMode: true) and connect() together.
import connectRedis from "connect-redis";
...
    const redisClient = createClient({
        legacyMode: true,
    });
   await redisClient.connect();

For me, this workaround it's not working... I use many resources from v4.

please help my production is broken because of this update

please help my production is broken because of this update

@dragonlobster for while, convert to string every value on or before command db.set... when you to execute command get, convert do correct datatype from string...

@a-koka i am using redis 7 and node 16 having same problem but it work sometime and give above error What to do ?

Make sure to convert the channel and message into strings or buffers

I found the same issue while trying to upgrade Node ACL2 to Redis 4.3.0.
sAdd stopped working with integers as well.
Stack trace:
 Uncaught TypeError: Invalid argument type
      at encodeCommand (node_modules\@redis\client\dist\lib\client\RESP2\encoder.js:17:19)
      at RedisCommandsQueue.getCommandToSend (node_modules\@redis\client\dist\lib\client\commands-queue.js:187:45)
      at Commander._RedisClient_tick (node_modules\@redis\client\dist\lib\client\index.js:440:76)
      at Commander.multiExecutor (node_modules\@redis\client\dist\lib\client\index.js:246:86)
      at Commander.exec (node_modules\@redis\client\dist\lib\client\multi-command.js:84:175)
      at RedisBackend.end (lib\redis-backend.js:36:46)
      at RedisBackend.tryCatcher (node_modules\bluebird\js\release\util.js:16:23)
      at RedisBackend.ret [as endAsync] (eval at makeNodePromisifiedEval (node_modules\bluebird\js\release\promisify.js:184:12), <anonymous>:13:39)
      at Acl.allow (lib\acl.js:337:29)
      at C:\Users\jose.lucena\Downloads\node_acl-master\node_acl-master\lib\acl.js:766:59
      at tryCatcher (node_modules\bluebird\js\release\util.js:16:23)
      at Object.gotValue (node_modules\bluebird\js\release\reduce.js:168:18)
      at Object.gotAccum (node_modules\bluebird\js\release\reduce.js:155:25)
      at Object.tryCatcher (node_modules\bluebird\js\release\util.js:16:23)
      at Promise._settlePromiseFromHandler (node_modules\bluebird\js\release\promise.js:547:31)
      at Promise._settlePromise (node_modules\bluebird\js\release\promise.js:604:18)
      at Promise._settlePromise0 (node_modules\bluebird\js\release\promise.js:649:10)
      at Promise._settlePromises (node_modules\bluebird\js\release\promise.js:729:18)
      at Promise._fulfill (node_modules\bluebird\js\release\promise.js:673:18)
      at C:\Users\jose.lucena\Downloads\node_acl-master\node_acl-master\node_modules\bluebird\js\release\nodeback.js:42:21
      at RedisBackend.end (lib\redis-backend.js:37:13)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

I found the same issue while trying to upgrade Node ACL2 to Redis 4.3.0.
sAdd stopped working with integers as well.
Stack trace:
 Uncaught TypeError: Invalid argument type
      at encodeCommand (node_modules\@redis\client\dist\lib\client\RESP2\encoder.js:17:19)
      at RedisCommandsQueue.getCommandToSend (node_modules\@redis\client\dist\lib\client\commands-queue.js:187:45)
      at Commander._RedisClient_tick (node_modules\@redis\client\dist\lib\client\index.js:440:76)
      at Commander.multiExecutor (node_modules\@redis\client\dist\lib\client\index.js:246:86)
      at Commander.exec (node_modules\@redis\client\dist\lib\client\multi-command.js:84:175)
      at RedisBackend.end (lib\redis-backend.js:36:46)
      at RedisBackend.tryCatcher (node_modules\bluebird\js\release\util.js:16:23)
      at RedisBackend.ret [as endAsync] (eval at makeNodePromisifiedEval (node_modules\bluebird\js\release\promisify.js:184:12), <anonymous>:13:39)
      at Acl.allow (lib\acl.js:337:29)
      at C:\Users\jose.lucena\Downloads\node_acl-master\node_acl-master\lib\acl.js:766:59
      at tryCatcher (node_modules\bluebird\js\release\util.js:16:23)
      at Object.gotValue (node_modules\bluebird\js\release\reduce.js:168:18)
      at Object.gotAccum (node_modules\bluebird\js\release\reduce.js:155:25)
      at Object.tryCatcher (node_modules\bluebird\js\release\util.js:16:23)
      at Promise._settlePromiseFromHandler (node_modules\bluebird\js\release\promise.js:547:31)
      at Promise._settlePromise (node_modules\bluebird\js\release\promise.js:604:18)
      at Promise._settlePromise0 (node_modules\bluebird\js\release\promise.js:649:10)
      at Promise._settlePromises (node_modules\bluebird\js\release\promise.js:729:18)
      at Promise._fulfill (node_modules\bluebird\js\release\promise.js:673:18)
      at C:\Users\jose.lucena\Downloads\node_acl-master\node_acl-master\node_modules\bluebird\js\release\nodeback.js:42:21
      at RedisBackend.end (lib\redis-backend.js:37:13)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

Convert to string before send to redis client, reconvert to datatype after get from redis. It's the solution, for while.

I got the same error. It works for me adding createClient option(legecyMode: true) and connect() together.
import connectRedis from "connect-redis";
...
    const redisClient = createClient({
        legacyMode: true,
    });
   await redisClient.connect();

Thank you !!! and this should be the fix and connect-redis did not support redis@v4 completely.
https://github.com/tj/connect-redis
Known compatible and tested clients:

[redis](https://github.com/NodeRedis/node-redis) (v3, v4 with legacyMode: true)
[ioredis](https://github.com/luin/ioredis)
[redis-mock](https://github.com/yeahoffline/redis-mock) for testing.

It would be great if this is specified in migration guide ~

This is a serious error :(


Simplify travis

Simplify travis

Coverage remained the same at 97.44% when pulling d915ed2925bf685c547cd5b2f389e6b32cadc9a6 on lowks:master into 71b1b23869d24216d4f294697341d0c8a3523128 on sugar-framework:master.


External heading support for AttitudeEstimatorQ (Vision/Mocap)

This is the WIP for using external heading in the quaternion estimator. This is a heavily requested feature, so I would appreciate inputs from the motion capture community on testing and keeping this maintained.
I have added 3 modes to use the heading :

Mode 0 : Ignore external heading.
Mode 1 : Just use the external heading and do not perform magnetometer corrections. (Current implementation does this ; Use where mag is completely useless)
Mode 2: Use both external heading and magnetometer. Useful for having a correct global yaw for use cases like mine. This still needs much work, and I will remove it from this PR if it holds up the primary integration.

Regarding mode 2, I would like some inputs from @DrTon. Basically we have the magnetometer and "fake" triaxial yaw readings from vision/mocap. What I would like to do is use both sources concurrently such that there is an accurate global heading (I need this) but also prevent bad mag readings indoors from throwing off the estimate by using the vision yaw. Maybe implement some dynamic weighting for the sources depending on RMS error or similar. I'd appreciate your comments and how we can best do this.
Currently I'm testing this with a AR marker setup. Currently my vehicle is down, but will be flying soon again. Again, I would like some other testers on this, especially those who've be working with indoor motion capture, and occasionally pop up on the mailing list...
@LorenzMeier @TSC21 @blackcoder

That's good @mhkabir , I've been hard coding the usage of internal heading only (Mode 0) in the firmware so far. The Mocap heading can be horrible sometimes !
I will test it soon. I assume you can select attitude_estimator_q through QGroundControl and select the mode ?

@blackcoder, You just need to set the parameter ATT_EXT_HDG_M to 0 or 1 depending on what you want :)
The estimator is enabled by default on all builds now.
Please be careful and do a lot of bench testing first! :+1:

Tomorrow (Thursday) and Friday I will to some tests with the old mocap-heading integration, but I also set up a second copter with your integration.
I look forward to test it. =)
A question about the modes:
Mode 0: Mocap data is just ignored and just compass etc. is used?
Mode 1: What happens when no mocap data is available? Will the estimator behave like in Mode 0 then?
In the enviroment I fly the mag data is completely useless, so I will only test Mode 1.

@moskytoo If mocap times out in mode 1, it falls back to the mag only (mode 0), but be prepared for a wild yaw change as the heading reference resets to magnetometer.

ok, here is the logged data by PX4 and by my vicon2mav application and the respective videos
data from vicon2mav:
https://www.dropbox.com/sh/i0nbvz683te6c62/AABF8ghIWlZlxQBtj_BuKmOwa?dl=0
about my vicon2mav:
vicon2mav receives mocap data with 40Hz, puts a lowpass filter with a threshhold of 10Hz on it, does the coordinate transformation (vicon -> NED) and then sends the mavlink message with 40Hz to the Pixhawk.
The "sent_Data_via_MavLink_Heading" data is calculated by Matlab from the sent quaternions.
about the copter:
Flight 1: S5R1 - ALTCTL was tested
http://dash.oznet.ch/view/j6ze6bV9hriH8ssAKrrLKH
https://vimeo.com/136442244

take off and landing in manual mode
the copter was sinking slowly
we had problems disarming the copter, as it didn't recognized the landing in the end and it wasn't even possible in manual mode

Flight 2: S5R2 - POSCTL was tested
http://dash.oznet.ch/view/a87Drr9NuthaJjeLXizxyS
https://vimeo.com/136442243

take off and landing in manual mode
the fast movement at around 0:40 was not commanded (Vicon was good, I suspect that somwhere between the Vicon Data Stream and PX4 some data were dropped)
the circle at 1:09 - 1:20 was not commanded, I havn't experienced behaviour like this with the attitude_estimator_ekf (yet)
in the end you see, that we had problems disarming the copters again

I think that should be it about the WIP - External heading support for AttitudeEstimatorQ (Vision/Mocap). As my project comes to an end I didn't plan to do any test flights, but if there's something of major importance I missed: tomorrow (monday) is the last day I would have the chance to test it.
about disarming the copters:
https://pixhawk.org/users/system_modes#arming_via_remote_control
Here it says that it's possible to disarm in manual mode even when no landing is detected, this is not what I think I've experienced. I was watching qgc while disarming for incoming messages about the Flight Mode and Landing/Takeoff detected.
Sometimes qgc didn't detected the change in Fligth mode of a Landing. I don't know whether it was just qgc or also the PX4, but it wasn't possible to desarm, so I guess it was also the PX4.

@mhkabir Could you comment on the test results?

We have tested it as well using Optitrack and a Pixhawk for Velocity setpoints. My workmate ran the software, so I don't have logs yet, but next test-run I'll gather logs and post them.
Initially it did not work smoothly but after some fixes in frame-conversions it worked.  (it started stable, but movements under a yaw rotation were not over a straight line)
It seems that ENU --> NED conversions are not correct in Mavros (UAS::transform_frame) .
Basically it seems to transform ENU --> ESD. We fixed the chain of conversions specifically for the mocap input in both Mavros and PX4. (If you want I can upload the exact changed lines, but we did not test it any further yet.)
After this it flew stable and smooth. We used an external PD position controller i.c.w. velocity setpoints, and we noticed that it was not reaching the correct setpoints. (not by far, 60 cm off on a distance of 120 cm). After a long debugging session, we came down to these lines:
https://github.com/PX4/Firmware/blob/abc74323ac9ecf9534d7ac7139f8aef3911a3edb/src/modules/mc_pos_control/mc_pos_control_main.cpp#L1144-L1152
Something seems to be wrong here. The vel_err_d should be in m/s^2 but actually (assuming pos_p to not have a unit) it consists of a part m/s and a part m/s^2. We changed this to:
math::Vector<3> vel_err_d =  (     (_sp_move_rate - _vel).emult(_params.pos_p) - (_vel - _vel_prev)    )    / dt;
and set _params.pos_p to be around 0.04 in QGC.  This solved our problem of not reaching positions using velocity setpoints, but we do need to test more extensively why our problem is solved.
If tomorrow the flight-arena is available (there are intros here), I'll run some logs. Otherwise I hope to get back on this next monday.

It seems that ENU --> NED conversions are not correct in Mavros (UAS::transform_frame) .

You will need to prove this cause there was already flight tests by @blackcoder with applied conversions on a similar mocap system. What I don't understand is this:

We fixed the chain of conversions specifically for the mocap input in both Mavros and PX4. (If you want I can upload the exact changed lines, but we did not test it any further yet.)

If you have fixed it, why don't you propose the changes in the mavros/PX4 issue tracking list? That's not the way open-source works! If you are benefiting from a community work, if you find out or in your opinion, if something is wrong, you should report it (not asking if we want you to upload the changes or not). But, in any case, frames conversions were a long discussion topic subject in mavros issue tracking list and you should check it out first.

After a long debugging session, we came down to these lines:

https://github.com/PX4/Firmware/blob/abc74323ac9ecf9534d7ac7139f8aef3911a3edb/src/modules/mc_pos_control/mc_pos_control_main.cpp#L1144-L1152

Something seems to be wrong here. The vel_err_d should be in m/s^2 but actually (assuming pos_p to not have a unit) it consists of a part m/s and a part m/s^2. We changed this to:

math::Vector<3> vel_err_d = ( (_sp_move_rate - _vel).emult(_params.pos_p) - (_vel - _vel_prev) ) / dt;

and set _params.pos_p to be around 0.04 in QGC. This solved our problem of not reaching positions using velocity setpoints, but we do need to test more extensively why our problem is solved.

This is out-of-scope of this topic and once again you should present it on the issue tracking from the projects. And I ask you to please do it, as it is of interest to all.

Hi.. My apologies, I'm relatively new to open-source and I don't want to create a mess. I'll try to improve it.
We were apparently using an older mavros version (last changelog 1-july), perhaps that's why we were having the problems. We didn't have to change anything in the PX4 PR itself.
I will retry using the latest Mavros version and see if this works without adaptation. (with some logs)
I'll open an issue for the last topic, as you are right that it's a different issue. I removed the part of text from the previous message.

@DrTon I would be glad to have some inputs from you on "Mode 2" and how to implement it.

Hi,
I  managed to do altitude hold using mocap(Optitrack) data as feedback.
I am receiving mocap data in Matlab, then I do the NEC conversion before sending the data to Pixhawk. I use the RC to switch to AlTCTL and climb to some altitude and hold it there and it works fine.
Now, I am facing a little problem when I switch to position control. The quad start to oscillat around the position. What could be the problem?
Should I modify some parameters?
Thanks

When looking at the code the variable _ext_hdg_good can only be updated within the if(vision_updated) or if(mocap_updated) statement. If I'm correct when a timeout occurs it stops updating on the topic but since vision_updated is false, _ext_hdg_good will not become false and the filter will keep updating using it's last known value.
Also when using the external heading it is forced to use both vision and mocap and both with the same weight (_w_ext_hdg). Why not separate the vision and mocap with its own weights?

@TjarkP Consider this essentially untested code (it says WIP in the first sentence). It would be great if you could put some work into testing and send a pull request with your fixes.

@TjarkP I fixed the timeout bug. Testing/code review would be appreciated.

@mhkabir Compilation fails, please fix. It would be great if you could keep track of the build status, thanks!

@LorenzMeier Fixed.
Any reason why Hans-CI isn't testing this? I thought closing/reopening would trigger it, but no go. Also, any way to get Travis to email me on builds?

You probably need to rebase on master to trigger Hans

Yeah it's already rebased to master.
On 30/10/2015 6:19 pm, "Lorenz Meier"<EMAIL_ADDRESS>wrote:

You probably need to rebase on master to trigger Hans
—
Reply to this email directly or view it on GitHub
https://github.com/PX4/Firmware/pull/2667#issuecomment-152514968.

Just tested this in a mocap arena using Mode 1 and it works well.
Here's a plot of attitude tracking comparing three different estimation sources.  Vicon, offboard EKF using lidar and IMU, and the PX4 attitude estimate.  The Pronto estimate is being fed into the PX4 as an external measurement.  Vicon is just there for ground truth.

Thanks for this! :+1:

Thanks @psiorx!
@LorenzMeier this has seen sufficient testing now I think. 4-5 people have successfully flown in VICON rooms.
It would be great to get this merged now. This has been sitting for ever. Dev guide and wiki will need to be modified to let people know that they need to change a parameter to enable the support.
I will do this myself once this is in.

Lets get the docs up first on http://dev.px4.io - that should be quick, and I need to be more diligent about documentation. We want to offer developers a solution, not just the code.
Great job Kabir! Rock on!

@LorenzMeier Implementation updated to allow people to independently use the heading sources. Setting the param to 1 enables vision, 2 enables mocap.
Sending PR for docs as soon as I get gitbook working here.

Worst case you can skip the Gitbook preview locally and just use Github to preview the .md files. Not the same, but it will get you close.

Great work guys! Sorry I didn't have time to contribute more.

@mhkabir @LorenzMeier Can you guys give us any more details about this vector?
math::Vector<3> v(1.0f, 0.0f, 0.4f);

@csorice147 Its simply a synthetic mag vector with inclination that has the same direction as a real magnetic field.

Can the external position estimation MAVLink messages also be used without providing any roll, pitch, yaw?
That is in the case of the external positioning system only being capable of providing position information (x, y, z)?
If so, what to do with the attitude quaternion in http://mavlink.org/messages/common#ATT_POS_MOCAP or Roll, pitch, yaw in http://mavlink.org/messages/common#VICON_POSITION_ESTIMATE

@mindThomas I'm Interested to know as well. Can I just leave ATT_EXT_HDG_M to 0?

@broody Yes, you can do so. By leaving the ATT_EXT_HDG_M to 0 none of the attitude information will be used why you can just set them all to 0 within the ATT_POS_MOCAP message.
However you have to be aware of the magnetometer direction within your Mocap environment as the magnetometer will be used for orientation when the external heading is disabled.
Your Mocap frame (coordinate system) has to be aligned with true North, measured by the magnetometer.


SAA-1628 this change replaces the first of two prisoner domain events. The events we currently use are delayed by 45 mins, the new ones are not delayed.

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

Project coverage is 86.87%. Comparing base (e27dff8) to head (60dda0f).

Files
Patch %
Lines

...itiesmanagementapi/service/events/InboundEvents.kt
77.77%
2 Missing :warning:

...ce/events/handlers/PrisonerReceivedEventHandler.kt
88.88%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #817      +/-   ##
============================================
- Coverage     86.88%   86.87%   -0.01%
  Complexity     3553     3553
============================================
  Files           368      368
  Lines         12440    12447       +7
  Branches       1024     1024
============================================
+ Hits          10808    10813       +5
- Misses         1161     1163       +2
  Partials        471      471

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


Remove gitlab host

How to remove GitLab host? Where are hosts written?
Thank you!

Hi @juref , do you mean after you add the gitlab host in vscode would like to find a way to remove it?

Yes, I have added a host witch I am not using anymore. It is from a former employer. Thx!

Undertand, currently the functionality is there but not exposed to user. Are you interested in contributing a PR?

Yes, I am, but I would need some help since I am new to PR and hactoberfest.

Sure I can help.
Since this is new feature, so I'd like to suggest 2 possible options:

Add a remove host command in vscode command platette, and just list out all the available ones for selection and remove
In the snippet tree view, there's a explore snippets panel, and the root level is the list of added hosts, may consider add a x button on the right to trigger the removal

Hi Jennie,
I'm sorry but I think this is just too much for me. I was able to get the "remove host" command to vscode command palette and I think I was able to select a host to delete, but I don't have enough knowledge to delete a host from listManager.

@juref got it no worries, if you have anything already, can give me a PR and I'll finish the rest :)

@juref just published new version. If after upgrade your side still got problem pls let me know.


support trailing arguments, as default values

hledger add has a fairly significant feature that hledger-iadd doesn't; the support for arguments trailing the "add" command, that are then made available as defaults in the interactive sequence.
It's easier to demonstrate than to describe, try the command:
hledger add today this\ is\ ususally\ payee expenses:test 100

and see how those trailing values are used as defaults in the prompts.
In this way, hledger add can be used with scripted output, and can even (iirc) take input piped from a file. This feature request is for hledger-iadd to support the same sort of thing.

I never understood this feature for interactive use, but I didn't consider scripting. That would make a lot of sense and fit an actual use case of mine.
I don't see anything about input from files in the documentation, but this can be implemented of course.
@simonmichael is there any documentation on the semantics of this feature in hledger add?

Just the mention at http://hledger.org/hledger.html#add I think. It's pretty simple, any arguments are just used as answers for the first N input prompts.

There are two possible ways to use the arguments as input: As default for the prompt (hitting Ret would use exactly what was passed as argument) or as pre-inserted text in the entry field (hitting Ret would use the first completion for this input, with the possibility to change it and cycle between completions).
So when invoking hledger-iadd with the arguments "today foo bar 3 baz -3", the former option would (when repeatedly hitting Ret) generate the transaction
2017/02/10 foo
  bar      3€
  baz     -3€

while the latter would generate
2017/02/10 Food
  Expenses:Barber      3€
  Assets:Bazinga      -3€

I imagine the former would be more useful for machine generated inputs and the latter for human input. What would be your use case @linuxcaffe? Maybe we could even implement both ways (selectable by another command line option).

My usecase would be something like this;
Let's say I have a (taskwarrior) task to "pay Union Gas".
When marking that done, I'll have a hook script extract the data from the task (Union Gas, proj:home.utils, 87.14)
and composer an hledger add (or iadd) script. So marking the "pay something xyz" task done immediately results in an interactive add, with as much of the defaults put in as possible.
As to your question, the first way or the second way, I can see reasons to use both, and I assume some hledger assertions can be added to the list, like converting project to the correct account:subaccount.


Opt.Output='separate' is ambiguous

For crystals, Opt.Output = 'separate' is ambiguous. It could mean separate site spectra, or separate transition spectra. Opt.Output = 'separate' is ambiguous for isotopologue mixtures as well: Does it mean separate all transitions, or just separate the spectra of the various isotopologues?
We need to generalize the Opt.Output interface to disambiguate.
Proposal:
Opt.Output = 'summed' or '' - add up all spectra (default)
Opt.Output = 'transitions' - separate spectra for all transitions (for monoisotopologue spectra)
Opt.Output = 'sites' - separate spectra for all sites (for crystals only?)  (for monoisotopologue spectra)
Opt.Output = 'orientations' - separate spectra for all orientations (for crystals only!)  (for monoisotopologue spectra)
Opt.Output = 'isotopologues' - separate spectra for all isotopologues (for isotopologue mixtures; single component)
Opt.Output = 'components' - separate spectra for all components (for multi-component samples)
Maybe use abbreviated keywords.

Opt.Output = 'separate' is ambiguous for isotopologue mixtures as well: Does it mean separate all transitions, or just separate the spectra of the various isotopologues?

The summation hierarchy is components, isotopologues, sites, transitions, orientations. Formally, the only continuous integral is over orientations (for powders), all others are discrete sums.
Opt.Output instructs EasySpin not to perform one of these sums. For this to work generally, the outer sums to the left must each contain only one term.

See also #65

The order of nested loops is:

components
isotopologues
orientations
sites
transitions

Proposal:
Opt.Output = 'summed';   % as before

Opt.Output = 'components';  % for powders and crystals
  % separate components AND isotopologues
  % sum over orientations, sites, transitions

Opt.Output = 'transitions';  % only for powders
  % separate components AND isotopologues
  % separate transitions
  % sum over orientations
  % (sites ignored)

Opt.Output = 'orientations';   % only for crystals
  % separate components AND isotopologues
  % separate orientations AND sites
  % (transitions are always summed)

Opt.Output = 'separate' % for backwards compatibility
  % powders: corresponds to Opt.Output = 'transitions'
  % crystals: corresponds to Opt.Output = 'orientations'

The third output of pepper etc. (see #299) should provide information about which spectrum in the output is from which component/isotopologue/transition/orientation/site.

Rename to Opt.separate