JSON-LD structural requirements have issues

The current specification text reads:

When serializing the Notification Subscription Metadata Resource as JSON-LD, the @contextfield [sic] MUST be an array containing the value https://www.w3.org/ns/solid/notification/v1.

It is unclear whether this was done for developer accessibility, security, and/or other reasons.
However, there are some issues—regardless of whether or not mandating a specific context is a desired solution. I am expanding on this argument also because it can help us inform how other specification documents are written for Solid.
Assuming that mandating a specific context is desired

The contract is not explicit in HTTP, as the  context assumption exists as an out-of-band decision.
So clients cannot specifically say they want "the Notifications kind of JSON-LD", and servers cannot indicate that they have responded with it. In other words, the media type underspecifies the contents. And while clients could identify the requirement by inspecting the body, such content sniffing is not recommended and causes overhead. A solution here is to explicitly indicate the profile of the content (and possibly to negotiate) it.

The fact that a certain context is present, does not provide any other structural guarantees.
I am assuming here that the requirement for a specific context was to make the JSON-LD more "developer-friendly", by adding predictability to the JSON structure. However, mandating a specific context does not achieve that, and as such is thus not meaningful by itself. It's easy to think of dozens of different structures to have a JSON-LD document that contains the same triples as the example in the specification, with the same context. So developers cannot usefully derive anything from the context being mandated. A solution here is to require a specific JSON-LD frame instead.

The type field requirement is ambiguous.
Given the previous point, the MUST materialize a type field also has a wide variety of ways to be expressed. The solution is a frame.

Mandating a specific context, and only that context, hinders extensibility.
Plus, apart from the structural points above, specifying a context does not mandate its usage for abbreviation. So instead of writing "subscription", I can still write "https://www.w3.org/ns/solid/notification/v1#subscription" (or whatever its expansion) and have a JSON-LD document that conforms to the Notifications spec.

JSON-LD framing is expensive for the server.
This does not hold for this specific case, for which shortcuts can be taken, but setting an expectation that Solid servers can perform arbitrary JSON-LD shaping sets a bad precedent. Generating triples is faster and can be done in a streaming way.

Assuming that mandating a specific context is not desired
Even if the approach is fixed to achieve a predictable JSON structure, we should question whether it is desired to have—and mandate (!)—this in the Solid ecosystem in general.
In principle, it is harmful to train developers to rely on a specific JSON structure, because we have no such guarantees elsewhere in Solid.
If the JSON-LD consideration was developer accessibility (as opposed to security), not only are we not reaching those goals yet with the text as currently written, it sets a difficult precedent. It also seems highly unlikely that developers will interact with the notifications directly; they should use libraries, which will likely work with triples instead, because they have better performance than JSON-LD framing. However, it can still be useful for debugability reasons.

Above was an attempt at an objective analysis; this current comment summarizes my personal opinion and conclusion based on the arguments above.

I think no Solid document should mandate a specific JSON-LD context. That is meaningless by itself.
Security concerns should be dealt with in general; we need (for the entire Solid ecosystem, but Linked Data in general) a separate document on security considerations surrounding RDF documents on the Web. The Notifications document could list contexts that clients can consider safe to dereference, but its responsibility stops there.
We could consider supporting specific JSON-LD frames, explicitly in the HTTP protocol with profiles, but then we need a Solid-wide strategy. However, we should be careful about teaching developers to make certain assumptions; they already are inclined to make more assumptions than the protocol allows them to.

So my preferences are, in order:

To not mandate a specific JSON-LD frame or context (and to maybe not mandate JSON-LD then, as it is not meaningful in that case)
To mandate a specific JSON-LD frame, explicitly specified with a profile

Also acceptable to me is:

To have a security remark about a trusted JSON-LD context

Not acceptable to me are:

Mandating a specific JSON-LD context
Not being explicit about additional syntactical constraints of representations

(Note that this contrasts with Solid-OIDC, where a context is added retroactively to interpret an existing already constrained JSON structure as RDF, which is the other way round.)

In principle, it is harmful to train developers to rely on a specific JSON structure, because we have no such guarantees elsewhere in Solid.

I agree with this in general. IMO the consumer should be responsible for providing @context and frame for JSON-LD if they indeed using it as plain JSON.
While in very simple cases, where all the statements have the same IRI as subject or object (and leverage JSON-LD @reverse) I think one could get by without JSON-LD Framing. This is clearly not the case here.

So my preferences are, in order:

To not mandate a specific JSON-LD frame or context (and to maybe not mandate JSON-LD then, as it is not meaningful in that case)

I think we should aim for that. I think we can still mandate text/turtle and application/ld+json but without putting any additional requirements on JSON-LD.

without putting any additional requirements on JSON-LD

But that might defeat the purpose of having JSON-LD altogether; it's all about developer-friendliness and predictability. Without requirements, the structure is arbitrary.

I was thinking of just following LDP and Solid Protocol support for both text/turtle and application/ld+json. This way client just needs one of those parsers to get handle all the data.
As I understand Solid storage doesn't guarantee that a specific JSON-LD structure gets preserved. For example in a quad store-backed CSS, creating a resource with a specific JSON-LD payload wouldn't guarantee the same structure when requesting that resource with application/ld+json ?
I'm afraid that if we start relying on specific context and frame, solid storage will be unfit for storing that data. I will probably raise this issue again for Solid-OIDC, since it seems that apps can't publish their Client ID Documents to solid storage in a reliable way.

I was thinking of just following LDP and Solid Protocol support for both text/turtle and application/ld+json.

This is quite orthogonal though.
The goal of the Solid storage system is to store all different kinds of original data (in whatever way).
Here, we're talking about a notifications protocol with a strict data shape.

This way client just needs one of those parsers to get handle all the data.

The only reason you'd need a parser for JSON-LD, is if you will treat it as triples rather than JSON.
But then JSON-LD is a very suboptimal format for triple-based communication, as it comes with significant serialization and de-serialization overhead, as well as security risks (contexts).
The entire point of including JSON-LD is likely to tap into JSON support (and if that's the case, then JSON-LD is not enough, but we do need a specific frame).

I'm afraid that if we start relying on specific context and frame, solid storage will be unfit for storing that data.

While I don't agree with that statement, it is an orthogonal issue. We're not talking about the very flexible kinds of data we are storing; we're talking about a very specific protocol that has very different requirements from the storage system.

Summarizing: we must to understand the underlying needs for choosing JSON-LD, and see if those needs are actually satisfied (which I doubt), and whether JSON-LD is the best way to address those needs.

There has been some updates to the spec that's formerly known as the "Notification Subscription Metadata Resource". It is currently known as the "Notification Channel Resource". The section on discovery clarifies the requirements: https://solid.github.io/notifications/protocol#notification-channel-discovery but the concerns on JSON-LD as per this issue still stands.
I agree that the spec needs a revisit pertaining to JSON-LD. I do not think we need to revisit serializations in general. I'd however be in favour of making sure things are uniform as much as possible for the notification channel resource, subscription request and response, and notification.
The following needs to be revisited:

https://solid.github.io/notifications/protocol#server-notification-channel-resource-accept
https://solid.github.io/notifications/protocol#server-notification-channel-resource-jsonld-context
https://solid.github.io/notifications/protocol#server-subscription-request-accept
https://solid.github.io/notifications/protocol#server-subscription-request-content-type
https://solid.github.io/notifications/protocol#server-subscription-request-response
https://solid.github.io/notifications/protocol#notification-data-model

I'm on board with some of the possibilities mentioned in earlier comments. Here is my take/suggestion:
The JSON-LD compacted document form ( https://www.w3.org/TR/json-ld11/#compacted-document-form , https://www.w3.org/TR/json-ld11/#application-ld-json ) should be sufficient to keep things RDF based and friendly-enough (for plain JSON consumers, if they so wish).
Essentially Accept and Content-Type headers including application/ld+json; profile="http://www.w3.org/ns/json-ld#compacted" would be something clients and servers acknowledge. If they wish to negotiate/agree on other possibilities, great. If the client uses a media-type value without the profile parameter, server responds with compacted JSON-LD.
We may also want to describe profile in the core Notification Data Model, especially considering that it currently employs AS2. We can work that out once we wrap-up the core, and describe how to extend with Notification Profiles ( https://github.com/solid/notifications/issues/101 ).

Thinking more on this. I think one of our goals for this spec should be to remain compatible with the Solid Protocol. So, if the Notification Channel Resource, Subscription Resource, and Notifications (for some Subscription Types) is on a Solid server (and I think we somewhat expect that but the spec may not explicitly mandate that), the server shouldn't have to do additional work.
Regarding a specific JSON-LD serialization, I suppose while a Solid server may accept a particular JSON-LD document form (like compacted) but it may never actually use the same form in a response payload. In that case, if the Notifications Protocol requires compacted JSON-LD for example, we are asking the Solid server to do a bit more. I think it may be preferable to not ask that additional work. It should work out of the box. And so the Notifications Protocol should only say that JSON-LD is required and leave it at that.
The Notifications Protocol, or at least the core Notification Data Model must be RDF-based - I don't expect anyone objecting that, I hope - and if anything, be JSON-LD friendly. There are a couple of specs that make use of JSON-LD that can work with the Notifications Protocol. Minimal interop is already in place in some cases. I worry that if we say something other than JSON-LD, we may be complicating things for both servers and clients.
(I say this without being a fan of JSON-LD... hey, ask me what my fave is :) but trying to make the best of aligning specs.)

(Note that this contrasts with Solid-OIDC, where a context is added retroactively to interpret an existing already constrained JSON structure as RDF, which is the other way round.)

I re-raised Solid-OIDC Client ID Document requirements in https://github.com/solid/solid-oidc/issues/95

I documented the need for a cross-spec serialization strategy in https://github.com/solid/specification/issues/454, so that we can address the JSON-LD (and other) format issues consistently across all documents.

Considerations/decisions elsewhere that can be useful input:

https://github.com/w3c/vc-data-model/issues/929
https://w3c.github.io/wot-discovery/
...


use sdk v2.0.0

This PR cuts over to using the GA SDK.
fwiw, I do not intend to continue upgrading the SDK every time there is a Brigade release. Now that we're at least using a stable/GA SDK, I will limit further upgrades of this nature to cases where there is true impetus such as a remediated bug a or a new feature we are in need of leveraging.

/brig run


ja: Make docs/reference/kubectl/overview.md follow v1.19 of the original text

This is a Feature Request

What would you like to be added
Update docs/reference/kubectl/overview.md to follow v1.19 of the original (English) text.
Why is this needed
content/ja/docs/reference/kubectl/overview.md is outdated.
Comments
/language ja
/good-first-issue
File to update
https://github.com/kubernetes/website/tree/dev-1.19-ja.2/content/ja/docs/reference/kubectl/overview.md
Original
https://github.com/kubernetes/website/tree/release-1.19/content/en/docs/reference/kubectl/overview.md
diff between translated and v1.19
https://gist.github.com/0499482755eb258c29cd8363b29fed8a
Note
Currently, we use dev-1.19-ja.2 branch. Please open a PR targeting the branch.
ref
https://kubernetes.io/ja/docs/contribute/localization/
If you have a question, feel free to ask us at slack.k8s.io #kubernetes-docs-ja channel

/triage accepted

/assign

/assign

/close


taxid of E. albertii in chromosomes.tsv does not match taxid in 'dmp' files

The taxid of Escherichia. albertii in chromosomes.tsv (208961) does not match taxid in names.dmp and names.reduced.dmp files

Thank you for seeing this.  I think I fixed this issue with #14


433 MHz tx?

Did anyone build a 433 MHz TX project on this? E.g. to remote control cheap 433 MHz outlets via HomeKit?

why this was closed would be cool to have such option

It might indeed be cool, but.. I do not plan to implement this and I'm not aware if anybody else plans to, so what's the point of having it hanging in list of open issues?

is implementing this harder then other samples?

I do not know and why does it matter?


⚠ Mobitopup has degraded performance

In bcd2fdb, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 11067 ms

Resolved: Mobitopup performance has improved in f8576d3 after 423 days, 18 hours, 25 minutes.


Write an easy to understand guide for the practical implementation of your concepts

I would suggest to include a bare bone basic pipeline of your code. The current layout of the code is every difficult to understand with a lot of boilerplate useless coding in-between (which makes sense in API's) but is not really required to understand the concept.

Yeah I would request for the same. It would be really helpful for us to have a guide. The currect readme is still hard for us to interpret

Even, it is difficult to run the code. Getting lots of errors.

If someone has own data: Can you please explain step by step what someone needs to prepare so that your algorithm can process someone's data?

The author could include this approach as a synthesizer in SDV.
SDV is very simple to install and use, has excellent documentation, and has a large community.


managed vault

WIP https://github.com/FortressFinance/issues/issues/77

Format your code sir.
yarn lint:fix


Club page

Added a list of clubs. Can search though.

Edit the components that fetch the list of clubs from publish integration to use SSR - this is the script type="module" and passing the props to the component on load.
This improves performance and removes the need to await getting the clubs on page load.


Philips Hue SSL Handshake Fail

[x] I confirm that this is an issue rather than a question.

Bug report
I'm trying to connect my Philips Hue bridge to Hyperion and it keeps waiting for the bridge button press.
In the logs, I get the following:
2024-06-21T19:48:57.599Z [LEDDEVICE] (ERROR) 'Trust on first use' - Certificate received does not match pinned certificate
2024-06-21T19:48:57.599Z [LEDDEVICE] (WARNING) philipshue generation of authorization/client key failed with error: 'SSL handshake failed'

Steps to reproduce
Manually type the IP of the bridge and open the wizard.
What is expected?
A user and key need to be created
What is actually happening?
Nothing
System
Hyperion Server:

Build:             (HEAD detached at a93d79b) (Paulchen-Panther-cb85d2d/a93d79b-1705568419)
Build time:        Jan 28 2024 10:21:55
Git Remote:        https://github.com/hyperion-project/hyperion.ng
Version:           2.0.16
UI Lang:           en (BrowserLang: en-US)
UI Access:         default
Avail Screen Cap.: framebuffer,x11,xcb,qt
Avail Video  Cap.: v4l2
Avail Audio  Cap.: audio
Avail Services:    boblight,cec,effectengine,forwarder,flatbuffer,protobuffer,mDNS,SSDP,borderdetection
Config path:       /root/.hyperion
Database:          read/write
Mode:              Non-GUI

Hyperion Server OS:

Distribution:      Debian GNU/Linux 10 (buster)
Architecture:      x86_64
CPU Model:         AMD Ryzen 9 5950X 16-Core Processor
CPU Type:          33
Kernel:            linux (6.1.74-production+truenas (WS: 64))
Root/Admin:        true
Qt Version:        5.11.3
Python Version:    3.7.3
Browser:           Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0

@ShiniGandhi
Background to the behaviour...
Old Hue Briges and DIYHue use a self-signed certificate.
In order to maintain security, the default behaviour is to "pin" the
certificate on the first connection. On the other hand, every connections are then checked to ensure that no other self-signed certificates are presented from the site.
I assume that you have probably reinstalled DIYHue several times and created new certificates, so the certificate you pinned does not match the current one from the bridge (you can see the errors in the log).
To continue, check for .pem files here:
~/.local/share/Hyperion/certificates
If you find any, remove them with
\rm -rf ~/.local/share/Hyperion/certificates/*.pem
As you running Hyperion under root, the files might sit at a different location.
check /root/.local/share/Hyperion/certificates

would have been nice to add that info to the error log itself. would have save me some time, anger and search <3


[WIP] Add JEI support to EnderIO

Description
Add JEI crafting categories for the Alloy Smelter, SAG Mill, Slice n Splice, Enchanter and Fire Crafting.
Fixes issue(s): # (issue)
Todo

[ ] Figure out how to get loot tables on the client
[ ] Figure out why FireCraftingCategory isn't alternating the blocks properly
[ ] Add anything else that might need to be added

Checklist:

[ ] My code follows the style guidelines of this project (.editorconfig, most IDEs will use this for you)
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation

I hate to say but this work has already been completed, I'd recommend discussion with us in Discord as we don't want to waste anyones time! I'll try get the branch that has these things published soon!

Yeah, should've probably look harder and joined the discord earlier. Well I leave this alone for now.

Superseded by #115, again you were Co Authored, so you have received credit for your work also! I essentially moved the soul vial integration from my implementation into another JEI plugin in base, then added the start of your fire crafting. Leaving this PR open for reference though as there's more work to do however it is blocked by some upstream changes.
Thanks again for your work!

I left this open in case I needed something, but I can't remember what that something is. For sake of clutter I will close this PR again - I want to thank you again for your work on this :)


Update instructions with dashboard link

Instructions have been updated with dashboard link: https://docs.google.com/document/d/1orEDTwMr3WjJUP0b33KQOSjrgzJa7sEpErKapJ17c7Q/edit


feat(sdk): trust registry api.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (cca10e1) 89.10% compared to head (7a54189) 89.15%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #704      +/-   ##
==========================================
+ Coverage   89.10%   89.15%   +0.04%
==========================================
  Files         105      105
  Lines        4314     4314
==========================================
+ Hits         3844     3846       +2
+ Misses        317      315       -2
  Partials      153      153

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


vimPlugins: update

Motivation for this change
To include 5366671 from vim-airline into nixpkgs. This fixes a warning when running neovim v0.5. I generated this change by running ./pkgs/misc/vim-plugins/update.py.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Verifying that 536667191d5bdc0afa3a18d7df229731e778815e is included.

I see this was already covered in https://github.com/NixOS/nixpkgs/commit/1c1b18ba71bfd8f381bc5695a48762e061f38a81.


Fix Refresh Data Viewer command palette capitalization and enablement

For https://github.com/microsoft/vscode-jupyter/issues/5752

Codecov Report

Merging #5750 (5f2d36e) into main (f14c5a3) will decrease coverage by 0%.
The diff coverage is n/a.

@@          Coverage Diff           @@
##            main   #5750    +/-   ##
======================================
- Coverage     72%     72%    -1%
======================================
  Files        403     403
  Lines      26865   26932    +67
  Branches    3914    3926    +12
======================================
- Hits       19564   19482    -82
- Misses      5653    5810   +157
+ Partials    1648    1640     -8

Impacted Files
Coverage Δ

src/client/common/errors/errorUtils.ts
34% <0%> (-38%)
:arrow_down:

...t/datascience/jupyter/jupyterInvalidKernelError.ts
66% <0%> (-34%)
:arrow_down:

src/client/datascience/kernel-launcher/types.ts
56% <0%> (-24%)
:arrow_down:

src/client/common/errors/types.ts
35% <0%> (-18%)
:arrow_down:

src/client/datascience/jupyter/jupyterSession.ts
75% <0%> (-8%)
:arrow_down:

src/client/common/errors/index.ts
72% <0%> (-8%)
:arrow_down:

...lient/datascience/telemetry/interpreterPackages.ts
77% <0%> (-7%)
:arrow_down:

src/client/common/installer/productInstaller.ts
47% <0%> (-7%)
:arrow_down:

src/client/api/pythonApi.ts
57% <0%> (-7%)
:arrow_down:

...rc/client/datascience/errorHandler/errorHandler.ts
81% <0%> (-6%)
:arrow_down:

... and 29 more


[flake] macos cmake-super build timed out due to slow compile.

seen once on 2020-07-31
hard to say much about this, some snippets from the log are below showing the duration of various stages:
~5 min git clone
~31 min "update or install dependencies"
~2hr 26 minutes spent compiling before the job timed out
[10:17:41] Build #576 enqueued, logging initialized.

[10:19:18] git clone https://github.com/googleapis/google-cloud-cpp.git /tmpfs/src/github/google-cloud-cpp
[...]
[10:24:05] Updating files: 100% (1498/1498), done.

2020-07-31T17:28:41Z: Update or install dependencies.
[...]
2020-07-31T17:59:31Z: ccache stats

2020-07-31T17:59:32Z: Configure CMake.
2020-07-31T18:02:06Z: Compiling with 4 cpus.
[...]
[ 71%] Performing install step for 'abseil-cpp-project'
-- abseil-cpp-project install command succeeded.  See also /Volumes/BuildData/tmpfs/src/github/google-cloud-cpp/cmake-out/macos/external/abseil_cpp/src/abseil-cpp-project-stamp/abseil-cpp-project-install-*.log
[ 72%] Completed 'abseil-cpp-project'
[ 72%] Built target abseil-cpp-project
-- curl-project configure command succeeded.  See also /Volumes/BuildData/tmpfs/src/github/google-cloud-cpp/cmake-out/macos/external/curl/src/curl-project-stamp/curl-project-configure-*.log
[ 74%] Performing build step for 'curl-project'

ERROR: Aborting VM command due to timeout of 10800 seconds
[...]
[13:28:12] Collecting build artifacts from build VM
Build script failed with exit code: 1
[13:41:37] Running blaze commands.
[13:41:41] Finished running blaze commands.
[13:41:44] /tmp/workspace/workspace/cloud-cpp/github/google-cloud-cpp/master/macos/cmake-super/artifacts/custom_sponge_config.csv does not exist in the workspace, no custom config value to log
[13:41:54] Sending email notification
	TO List<EMAIL_ADDRESS>	CC List: []
[13:41:56] Updating SpongeV2 invocation.
[13:42:01] Updating ResultStore invocation.

Another instance of the same issue:
https://source.cloud.google.com/results/invocations/562d2705-4e59-4a85-a144-0beb44fa96a1

I think this bug is just a dup of #3645 I am closing this in favor of the bug with more history.


Script creates incorrect link files in ./lib/STLinkedResources on Windows (VSCode)

When using VSCode on Windows, the <setup_cubemx_env_auto.py> script creates orphan links in ./lib/STLinkedResources folder because STM32CubeMX add a project-based relative path for locationURI dependencies.
Error in VSCode:

Explorer results:

In the generated .project file, all locationURI start with the PARENT-xx-PROJECT_LOC string which is the project based relative path where xx indicates the number of levels up to the project path.

STM32CubeMX generates .project file in which you can find <locationURI>PARENT-4-PROJECT_LOC/Users/Olivier/STM32Cube/Repository/STM32Cube_FW_F1_V1.8.3/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal.c</locationURI>
The project is located in D:/CloudStation/GitLab/modbus-remote_BB/modbus-remote_BB_FW,
So, 4 levels of the project path have to be removed which gives D: as path to be used to replace the PARENT-4-PROJECT_LOC string (without trailing '/' and without the 'D:/Users/Olivier' the script adds).
This gives <locationURI>D:/Users/Olivier/STM32Cube/Repository/STM32Cube_FW_F1_V1.8.3/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal.c</locationURI> which is correct:

If you need more information, feel free to ask.
Thank you.
Here is a .ioc and a .project files: STLinkedResources issue.zip

Did you set the option  „Add necessary files as reference in the toolchain project configuration file" in CubeMX? The relative paths are a problem if you do not do this.
If you did, the next question is which version of STM32CubeIDE you use? I‘m still on 1.5.1, so maybe they have introduced some changes in the newest version.

Did you set the option „Add necessary files as reference in the toolchain project configuration file" in CubeMX? The relative paths are a problem if you do not do this.

It took me time to find this option, but yes, I did.

If you did, the next question is which version of STM32CubeIDE you use? I‘m still on 1.5.1, so maybe they have introduced some changes in the newest version.

Sorry to forget to mention it. As I've just installed STM32CubeMX and STM32CubeIDE, it should be the latest version:

STM32CubeMX: 6.2.1
[STM32CubeIDE: 1.6.1 but I don't use it]

Ok, if you set this and the problem still persists, then it might have to do with the newer version and I have to check that. First of all I have to install these versions which might need a few days...

I have a similar problem for STM32CubeMX: 6.2.1

@leech001 your approach was a good first solution, but a remaining problem is that the exact name (more precisely the digit) changes.
I have now added a slightly different solution, added the inclusion of additional folders that are referenced inside the project (e.g. the middleware folders that you can add) and did some tests.
Please check this version and if everything works, I'll close this issue.

Hi @jbaumann,
Thank you for this release but, unfortunately, there is a new error line 142:

As I found a new specific case which is not taken in account (virtual folder), so I've treated it.
I've also fully treated the relative path based on project folder (PARENT-x-PROJECT_LOC).
Feel free to integrate these modifications (setup_cubemx_env_auto.zip) in your code, but, as I don't know RegEx, I'm not able to correct your new error. Please apologize.

That is an interesting error, and I hope I have fixed it. Could you test the newest version? I tried to add your virtual folder support.

Hi Joachim,
Good news, the modification line 146 is working well.
But there are some new errors 😉:

line 75: do you mean continue instead of next?
lines 76-78: removing the relative path pattern PARENT-x-PROJECT_LOC seems to be not enough because it leaves some old path behind, which creates an incorrect symbolic link:

Relative path (extract): PARENT-4-PROJECT_LOC/Users/Olivier/STM32Cube/Repository/STM32Cube_FW_F1_V1.8.3/...
repository_location = D:\Users\Olivier which is always different from /Users/Olivier (startswith)
Symbolic link target (extract): D:\Users\Olivier/Users/Olivier/STM32Cube/Repository/STM32Cube_FW_F1_V1.8.3/...

line 190: one tab seems to be missing
lines 73 to 75: it seems you are incorrectly managing the virtual folder by adding the virtual:/virtual string to the virtual_dirs list for each virtual folder encountered... which is not the virtual folder name.

So I've merged your corrections to my solution to manage the virtual folders correctly.
As in my previous version, I've also managed the relative (to project) path, because a project may reference many relative paths levels. Here are some example extracted from the project I've attached in my previous comment:

PARENT-1-PROJECT_LOC/CycloneTCP_SSL_SSH_CRYPTO_Open_2_0_4/...
PARENT-4-PROJECT_LOC/Users/Olivier/STM32Cube/Repository...

Please find the merge of our 2 solutions which works fine... (except some errors on my project side, not the script).
setup_cubemx_env_auto.zip
PS: my name is olivierov not olierov 😁

Note to self: Do not try to rush software out while focusing on your day job at the same time…
You are absolutely right, and I will never understand the way Windows, even after all this time, works with paths. I will try to find a way to unify Unix-like paths and Windows paths, but in the worst case I will simply write different cases for these two, using your code in the Windows case.
And I‘m very sorry that I wrote you name wrong, my apologies.

First step: Corrected the virtual folder functionality, added a few comments. Next step is to correct the patch functionality based on your code.

@olivierov Could you test the new version? It now works on my system and hopefully on yours as well.

Hi Joachim, virtual folders and project-based relative paths are working well, thank you.
I still have an error around line 207 of the new script. Error log extract:
PACKAGES:
 - framework-stm32cubef1 1.8.3
 - tool-ldscripts-ststm32 0.1.0
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 1 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <STLinkedResources>
Building in release mode
Compiling .pio\build\eval_f107vc\src\Core\Src\crc.o
arm-none-eabi-gcc: error: unrecognized command line option '-mruntimelibrary_c=standard_c'
Compiling .pio\build\eval_f107vc\src\Core\Src\freertos.o
Compiling .pio\build\eval_f107vc\src\Core\Src\gpio.o
Compiling .pio\build\eval_f107vc\src\Core\Src\main.o
Compiling .pio\build\eval_f107vc\src\Core\Src\stm32f1xx_hal_msp.o
arm-none-eabi-gcc: error: unrecognized command line option '-mruntimelibrary_c=standard_c'
Compiling .pio\build\eval_f107vc\src\Core\Src\stm32f1xx_hal_timebase_tim.o
arm-none-eabi-gcc: error: unrecognized command line option '-mruntimelibrary_c=standard_c'
...

If I change the Runtime library in STM32CubeIDE from Standard C to Reduced C (1) , the error change to:
Building in release mode
Compiling .pio\build\eval_f107vc\src\Core\Src\crc.o
arm-none-eabi-gcc: error: unrecognized command line option '-mruntimelibrary_c=nano_c'
...

Thank you again for your work, you are close to provide us a perfect cross-platform script.
Olivier.
(1)

I haven't seen this problem, and I'm using "Reduced C", but I'm working with an STM32F4 instead of an STM32F1.
PlatformIO uses a different approach to this, by setting additional values for the compiler you can choose the exact functionality you want. See this link: https://docs.platformio.org/en/latest/platforms/ststm32.html#stm32duino-configuration-system
In the first step, I have simply removed this option and the script should print a message for every removed option. Since by default PIO selects the Nano-Spec, this should work already.
The next step would be to decide whether the selection should be explicit in the platformio.ini file or automatic. The first gives you more control, the second guarantees that both STM32CubeIDE are more in sync. The second argument is weak, since we use different compilers...

Hi Joachim,
Except one typo (mflag instead of m_flag), all works well. I'm now able to compile, transfer and debug on my board.
Thank you so much.
I'm also happy to have learnt a bite of Python by looking at your efficient code.
> Executing task: D:\Users\Olivier\.platformio\penv\Scripts\platformio.exe debug <

Processing eval_f107vc (platform: ststm32; board: eval_f107vc; framework: stm32cube)
----------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
SETUP_CUBEMX: Using the following source directories: 'Core, USB_DEVICE, Drivers, Core/Startup, Middlewares'
Removing runtimelibrary_c=standard_c
SETUP_CUBEMX: Adding the following build flags: '-mthumb, -mcpu=cortex-m3'
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/eval_f107vc.html
PLATFORM: ST STM32 (14.0.0) > STM3210C-EVAL
HARDWARE: STM32F107VCT6 72MHz, 64KB RAM, 256KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
 - framework-stm32cubef1 1.8.3
 - tool-ldscripts-ststm32 0.1.0
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 1 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <STLinkedResources>
Building in debug mode
Compiling .pio\build\eval_f107vc\src\Core\Src\crc.o
Compiling .pio\build\eval_f107vc\src\Core\Src\freertos.o
...
Compiling .pio\build\eval_f107vc\lib7de\STLinkedResources\usbd_ioreq.o
Archiving .pio\build\eval_f107vc\lib7de\libSTLinkedResources.a
Linking .pio\build\eval_f107vc\firmware.elf
Checking size .pio\build\eval_f107vc\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==========]  95.3% (used 62448 bytes from 65536 bytes)
Flash: [====      ]  40.6% (used 106520 bytes from 262144 bytes)
Building .pio\build\eval_f107vc\firmware.bin
=========================================================== [SUCCESS] Took 18.00 seconds

Hi Olivier,
thank you very much, and thanks for all the help you provided.
And I'm looking forward to the next bug you find.
Cheers, Joachim


Using @Search context provider yields an ENOENT error executing ripgrep

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS:Ubuntu 22.04.1 on VMWare Workstation 17.5.2 build-23775571
- Continue:0.9.197 and 0.8.46
- IDE:Visual Studio Code 1.92.1
- Model:
- config.json:

{
  "models": [
    {
      "title": "Codestral 22b",
      "provider": "ollama",
      "model": "codestral:22b-v0.1-q8_0",
      "apiBase": "http://sv-llm.c1.mydomain.net:11434/",
      "contextLength": 28672,
      "completionOptions": {
        "maxTokens": 4096
      }
    },
    {
      "title": "Llama 3.1 405B Q4_K_M",
      "provider": "llama.cpp",
      "model": "Llama 3.1 405B Q4_K_M",
      "apiBase": "http://sv-aichan.c1.mydomain.net:8080/",
      "contextLength": 122882,
      "completionOptions": {
        "maxTokens": 8192
      }
    },
    {
      "title": "DeepSeek Coder V2 236B Q8_0",
      "provider": "llama.cpp",
      "model": "DeepSeek Coder V2 236B Q8_0",
      "apiBase": "http://sv-aichan.c1.mydomain.net:8082/",
      "contextLength": 122882,
      "completionOptions": {
        "maxTokens": 8192
      }
    },
    {
      "title": "Mistral Large 123B 2407 Q8_0",
      "provider": "llama.cpp",
      "model": "Mistral Large 123B 2407 Q8_0",
      "apiBase": "http://sv-aichan.c1.mydomain.net:8081/",
      "contextLength": 122882,
      "completionOptions": {
        "maxTokens": 8192
      }
    }
  ],
  "customCommands": [
    {
      "name": "test",
      "prompt": "{{{ input }}}\n\nWrite a comprehensive set of unit tests for the selected code. It should setup, run tests that check for correctness including important edge cases, and teardown. Ensure that the tests are complete and sophisticated. Give the tests just as chat output, don't edit any file.",
      "description": "Write unit tests for highlighted code"
    }
  ],
  "tabAutocompleteModel": {
    "title": "CodeStral 22b",
    "provider": "ollama",
    "model": "codestral:22b-v0.1-q8_0",
    "apiBase": "http://sv-llm.c1.mydomain.net:11434/",
    "contextLength": 28672,
    "completionOptions": {
      "maxTokens": 2048
    }
  },
  "allowAnonymousTelemetry": true,
  "contextProviders": [
    {
      "name": "code",
      "params": {}
    },
    {
      "name": "codebase",
      "params": {
        "nRetrieve": 1000,
        "nFinal": 50,
        "useReranking": false
      }
    },
    {
      "name": "folder"
    },
    {
      "name": "terminal"
    },
    {
      "name": "folder"
    },
    {
      "name": "search"
    },
    {
      "name": "docs",
      "params": {}
    }
  ],
  "embeddingsProvider": {
    "provider": "ollama",
    "model": "nomic-embed-text:latest",
    "apiBase": "http://sv-llm.c1.mydomain.net:11434/"
  }
}

Description
Attempting to use @Search and I always receive a popup with an identical error message than this one from the developer logs:
Error getting context items from search: Error: spawn /home/user/.vscode/extensions/continue.continue-0.9.197-linux-x64/out/node_modules/@vscode/ripgrep/bin/rg ENOENT
c	@	notificationsAlerts.ts:42
This happens with the latest release version as well as the latest pre-release version. Other context providers such as codebase are working.
The "rg" binary is at the specified path and can be executed.
To reproduce

Go to the chat window.
Type @Search.
Fill in the search term, e.g. "mixin"
Submit the chat request.
A popup with the described error appears.

Log output
Error getting context items from search: Error: spawn /home/user/.vscode/extensions/continue.continue-0.9.197-linux-x64/out/node_modules/@vscode/ripgrep/bin/rg ENOENT
c	@	notificationsAlerts.ts:42

I have only used the release and pre-release versions from the VSCode extension store.

Removed .continue, removed Continue extension, reinstalled, reconfigured. Same issue. Made sure to add it do devcontainer.json and nothing.
I suspect this is because I'm using Dev Containers.

It appears that rg is executed in the context of the container which is why there the rg executable can not be located.


MPPC Creative

|New feature?    |  yes?                               |
Solution Details
Solution requires premium license                         | no                              |
What's in this Pull Request?
A MPCC SIC test

As this PR was to practice PRs, I will not merge it but close the PR. Have a great day, you rock!


Revert "RAP-4323 build fails with Gradle 3.3 "

Reverts RapturePlatform/Rapture#458

test this please


Regenerate array with closest sum

Feature ✅
Find minimum value to be assigned to the elements so that sum becomes greater than initial sum.
Input: 4 2 1 10 6
Output: 5
Sum of original array = 4+2+1+10+6 = 23
Sum of modified array = 5+5+5+5+5 = 25

Hi @pratik-choudhari  , I can handle this one.

@Raksha25 Great let me know the language.

@Raksha25 Great let me know the language.

Java

@pratik-choudhari
I would like to take this up in C++.

hey @pratik-choudhari  can I take this one in C?


Gboard autocomplete causes double cursor

First of all, thank you for all the effort you've put in, I can't stress enough how much more readable the codes are! While playing around with the example, for Android devices that use Gboard (probably the most popular keyboard for Android), if you autocomplete the last word of the line and hit enter, the cursor on the last line won't hide correctly, and it causes double cursor. For other keyboard such as Microsoft SwiftKey, this problem does not exist.
FYI, this problem also exists in flutter_quill, so it isn't due to refactoring.
https://user-images.githubusercontent.com/53685306/187080896-80b9f660-36b0-434a-856e-0a9fc513ba80.mp4

I found out  the cause, turns out GBoard insert a space after every word it autocompletes. If the last word of the line is auto complete, when user press the enter button, it replace spalce (32) to line feed (10) directly. For Microsoft Swift Board, it just inserts line feed after space.

First of all, thank you for all the effort you've put in, I can't stress enough how much more readable the codes are!
Thank you for the feedback. I'm really happy to hear my efforts are helping. I'm still digging deeply in the library to add more features and the more I dig the more I document. So in time it will be even better.

FYI, this problem also exists in flutter_quill, so it isn't due to refactoring.
Good to know this particular detail.

So, is this problem still affecting you? Did you manage to find a fix? At the moment I don't have a clear explanation of what could it be. Also I'm having a hard time to slice out time. There's a huge backlog of far bigger issues that I'm consuming. Can't promise a fast resolution. I'll label this issue as open for contributions. For sure sooner or later it will have to be fixed. If not by the community, I'll find myself time or someone from my team once we go closer to our go live deadline. I'm interested to fix all such issues. In the end my goal is to have a flawless editor. It will take some time but we will get there.


added via upload

This is a document map in .png format which shows how docs in this repo are linked together. Reference only.

Wow, didn't realise there were that many markdown files ;)

If #245 is merged first, then this file could also move into the new subdir doc/images/, although as it's a standalone image, it could be argued that it makes sense for it to remain in doc/


Upgrade maven-assembly plugin from 3.1.1 to 3.3.0

Pull Request Description
This pull request closes #1877
Acceptance Test

[ ] Building the code with mvn clean install -Dintegration.tests still works.
[ ] Running mvn spring-boot:run in the strongbox-web-core still starts up the application correctly.
[ ] Building the code and running the strongbox-distribution from a zip or tar.gz still works.
[ ] The tests in the strongbox-web-integration-tests still run properly.

Questions

Does this pull request break backward compatibility?

[ ] Yes
[ ] No

Does this pull request require other pull requests to be merged first?

[ ] Yes, please see strongbox/strongbox-parent#81
[ ] No

Does this require an update of the documentation?

[ ] Yes, please see strongbox/strongbox-docs#{PR_NUMBER}
[ ] No

Update: This is now being build in Jenkins with our complete build pipeline here.

Hi @hirva10  ,
Thank you, the tests have passed and I will be closing this pull request as it proves it works!


Create CallGraphCodemod

I'll not merge this into fastapi-responses. I'll create another package, and then use it here
The idea is to first map all function definitions and calls that are inside of those.

Will it make the package depends on libcst?

No. The idea here is a bit different than what it current does.
I'd like to transfer the runtime behavior into a tooling that can automatically add the exceptions information into the FastAPI endpoint decorator.


WIP: Update travis settings

@cheungpat, thanks for your PR! By analyzing the annotation information on this pull request, we identified @rickmak to be a potential reviewer

superseded by #173


HDDS-5909. EC: Onboard EC into upgrade framework

What changes were proposed in this pull request?
The change introduces the OM and HDDS LayoutFeature for EC. In order for EC to work, there are no upgrade actions necessary so none are defined, EC does work based on the normal facilities, and solves the erasure coded storage of data solely on the client side. The server side just gets knowledge about the fact that data inside an object is erasure coded with the ReplicationConfig.
The change also introduces a new ClientVersion to mark that the client side supports erasure coded storage, also fixes a few APIDoc typos where ClientVersion remained ClientVersions during the rename of the class.
The change also adds request and response validation to ensure the following backward compatibility and upgrade related questions:

During an upgrade until the cluster is finalized, there aren't any way to create a key/bucket/container/pipeline with ECReplicationConfig.
After an upgrade a client is not served with any type of object that has an ECReplicationconfig that the old client would not understand.
The change affects SCM and OM, so that SCM Admin and SCM Container Location requests are also disabled alongside with any requests that the OM ClientProtocol provides.

What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-5909
How was this patch tested?
As the logic added is so simple, I did not added new tests for the request/response validation so far, current tests should work without any modification, while in order to add compatibility tests for the client and server side I believe we need a bigger effort to extend what we already have for compatibility alongside with the development related to HDDS-6390

Thank you for the reviews both of you @errose28 @kerneltime
I tried to address most of the concerns.
I see three things we need to get to a conclusion with before we might close out this PR.

how exactly the proto layer fails if there is an unused ECReplicationConfig in the result
we either need to agree that discrepancies of the fw are solved later on during the planned refactoring and extension to SCM and possibly to the client layer as well, or we add at least the version check of the client here.
How we want to solve the listing related question (fail, or filter), as I used an assumption about the client side failure (I had to admit it to myself as well first :D ), this can be decided after we know the answer for 1.

Based on this I will go forward, and add some minimal tests to the xcompat tests, and check how things exactly work within that environment. Based on which we will know the answer for 1, and we can decide on 3 while we will have some tests as well (I will do my best to cover all the normal fs client side changes, but I won't bother much with the admin client side if that turns out to be too complicated and if you don't mind.
I will update here about 1. later today.

There was a question open from before:

how exactly the proto layer fails if there is an unused ECReplicationConfig in the result

This was answered in the docker environment, and tests are also written around this part of the code, so now we know and test the behaviour.
Based on that, bucket listing is not disabled, as there the DefaultReplicationConfig field is added as optional, so old clients does not look for it, and it may or may not present, but this is fine... With that old clients can show bucket data at listing and at info calls.
Key listing has to be disabled on the other hand, as there the ReplicationFactor field is required in old clients, but it is not sent by the new server, causing a failure if a KeyInfo arrives with ECReplicationConfig...
An option would be to use ReplicationFactor.ZERO, but that was introduced with EC, so old clients would not understand that either.

Thanks a lot @fapifta for your hard work here and thank you @errose28, @adoroszlai, @kerneltime for your reviews.


Optimize flow unit tests

The flow unit tests take ~20 seconds to run. Profile these tests, and look into speeding them up.
Exported from RIPD-1408

reported by @seelabs - is this still worth doing?

Right now we're testing 4 sets of features. We can probably stop testing with flow cross off and speed things up by a factor of 2. I'll do that.


Series Changes Getter Bug

Issue #: /bcgov/entity###
Description of changes:

Quick fix for a getter bug that wasn't evaluating beyond the first Share Class

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

PS Too bad there wasn't a unit test for this :P

PS Too bad there wasn't a unit test for this :P

haha i can do that!


"Format Document" not present

Version of VSCode: 1.11.1
Version of the extension: 0.3.11
OS: Fedora 26 TwentySix
Description:
"Format Document" not present after right click on document.

Same after upgrading to 0.3.11.
Shortcut doesn't work too.
And its only when using rls, in legacy mod everything is working.

Try https://github.com/jonathandturner/rls_vscode if Format Document doesn't present there, then it's RLS problem.

I can only get auto format if rls is turned on.

@jaysonsantos,
Try https://github.com/jonathandturner/rls_vscode
If it doesn't work either, it is a problem of RLS.

@KalitaAlexey it won't work with rls_vscode too. But do you use it's implementation or you talk to the protocol directly?

@KalitaAlexey creating the rls.toml with unstable_features = true made it work

I meant that rls_vscode may have some changes which the extension doesn't have.

It's now toggled by unstable_features. Since #174 already corrected the docs, we can safely close this.

@Doaxan @Object905,
Have you still experience this issue?

I resolved the same problem with the unstable_features, why it is needed?

@jonathandturner,
Could you say why it is needed?
Is that needed or do I have a bug?

@KalitaAlexey  I think it is related to this

Thank you.

As per the comment, I am closing the issue since the documentation contains what to do.


Testing Lidar 3D Obstacle perception algorithm offline individually

System information

Linux Ubuntu 16.04
Apollo installed from binary (docker)
Apollo version 3.0

I wanted to run the LIDAR perception module offline (similar to how we test end-to-end deep learning models) to benchmark its performance using metrics for object detection on the demo data from the Apollo Open Data Platform. Can somebody tell me how to go about doing that?
Navigating through the scripts is pretty confusing & there is no mention of how to test this in the documentation. A prompt response will be highly appreciated.
Thanks in advance!

It took us a long while, but we eventually got this to work.
However, we don't have much of a visualizer, we did manage to pipe the data output from the lidar recognition component into a message queue, then have a separate ROS node receive those messages and publish in Rviz...  but it was quite the hassle and we are exploring alternatives.
There appears to be a lidar offline visualizer here:
apollo/modules/perception/lidar/tools/
But it wasn't working initially, I forget why, but we plan to come back and try it again.

@snuffysasa - I appreciate your quick response. Could you elaborate on how you ran the pipeline for the Lidar obstacle perception offline to get the data output?

Wait, I wasn't clear.
I have not gotten this file/module to work correctly:
apollo/modules/perception/lidar/tools/offline_lidar_obstacle_perception.cc
But I have managed to run the regular perception module, and disabling all components, except for lidar segmentation component and lidar recognition component...
Then I can use cyber_recorder play to play some recorded Lidar data, and the running perception module will process it. and there will be data output on "/perception/inner/PrefusedObjects"
Is this what you are trying to do?

Apologies for my naivety but which is the file that needs to be modified & how do I disable the other components? Or does it have to be done in Dreamview?

@sbanga16k
So you will want to launch perception from
/modules/perception/production/perception.launch, you will want to examine that file which will point to a DAG file/files.
Then open those DAG files and you will see a list of components, you can remove what you don't need.
the dag will point to several other config files, you will want to examine each of these, and child config files that those point to.
After that, there may have been a few other things that still caused us issues before we were able to run the Lidar module.
Oh make sure to disable HD map roi  if you don't have an hd map.
It's very confusing at this point, hopefully there will be more documentation soon.   If you get this far, and are still getting some errors.   you can post back, and maybe I'll remember how we fixed those errors.

@snuffysasa - I was trying to run the perception.launch files first without changing any of the components in the referenced DAG files but ran into these errors in sensor_manager.cc (see attached)
sensor_manager.cc:78 [mainboard] Failed to load camera intrinsic.
sensor_manager.cc:92 [mainboard] Failed to add sensor_info: front_6mm
sensor_manager.cc: 36 Check failed: this->Init() == true (0 vs. 1)
I was trying to debug this but realized I don't have access to the folder:
apollo/modules/perception/data which is where the camera intrinsics are stored.
Did you encounter this error? If so, how did you go about resolving this?

@sbanga16k The testdata directory under modules/perception has those files that SensorManager is looking for.
You should be able to symlink ln -s the modules/perception/testdata/camera/app/data/perception/camera to modules/perception/production/data/perception/camera and resolve those errors.
But I have also come across new errors in that module that are WIP still.  It's definitely not easy without very much documentation

@aboarya I copied the contents of modules/perception/testdata/camera/lib/traffic_light/preprocessor/data/multi_projection/ to modules/perception/data/ like you said. But that didn't do anything to resolve the errors.
I even tried removing the "perception_camera" module from the perception.launch to see if it would work without it but it gave me the same error. I was trying to print out the attributes of the sensors for debugging in the sensor_manager.cc file but that did not print out anything. I'm at a loss in terms of understanding which function is invoking calls to retrieve the camera intrinsics parameters.

@sbanga16k  My apologies, I wrote my answer last night from memory. Here is a detailed explanation.
Looking at your original screen shot where the error is:
Failed to load camera intrinsics.
That error is coming from SensorManager.cc line 78.
That exception is caused because
if (!LoadBrownCameraIntrinsic(IntrinsicPath(sensor_info.frame_id),
                                    distort_model.get())) {

is returning false.
The IntrinsicPath line 69 function in SensorManager.h assembles together the path of the yaml file as follows
FLAGS_obs_sensor_intrinsic_path + "/" + frame_id + "_intrinsics.yaml";
The obs_sensor_intrinsic_path is a variable in the perception_commong.flag file and is defined as follows
--obs_sensor_intrinsic_path=/apollo/modules/perception/data/params

In summary, there are three parts to the path of the file:

obs_sensor_intrinsic_path=/apollo/modules/perception/data/params
frame_id is equal to camera_name defined in the fusion_camera_detection_component.pb.txt and is
2.1. front_6mm
2.2. front_12mm
_intrinsics.yaml

Put together you get:
1. /apollo/modules/perception/production/data/perception/camera/params/front_6mm_intrinsics.yaml
2. /apollo/modules/perception/production/data/perception/camera/params/front_12mm_intrinsics.yaml

But wait
You're done yet! Because those  the LoadBrownCameraIntrinsic function in io_util.cc line 58 parses those yaml files AND WILL throw a YAML parse exception because it tried to cast the width and height defined below from integer to double
height: 1080
width: 1920

For some very odd reason, the cast does not work, so I had to change the values to
height: 1080.0
width: 1920.0

So my suggestion is copy the files from the test data directory to /apollo/modules/perception/production/data/perception/camera/params/ and change the values to doubles to avoid the parse error and let me know how that works.  I don't recall the next error I had to solve after that, so if you do come across another, please update here

Looking at your second screenshot, the one that lists the files in the params directory, the front_6mm_intrinsics.yaml is missing, just as it was for me.  I was able to find it under the production/data directory as I linked above.  https://github.com/ApolloAuto/apollo/tree/master/modules/perception/production/data/perception/camera/params .

@aboarya apologies for the delay in responding. You could use any document from the "how to" section (example) as a reference to create the document, we will review it once you have made a PR. Let me know if you have any questions!


Feature/12175 UI changes for non tappable areas

Description
Brings some UI Changes for the day cells of the contact journal:

The new non-clickable areas have not a different background color then the clickable parts.
All cells and the container itself have now border lines

To achieve this, i had to change a lot in the ui creation.
Link to Jira
Main story: https://jira-ibs.wbs.net.sap/browse/EXPOSUREAPP-12006
Subtask: https://jira-ibs.wbs.net.sap/browse/EXPOSUREAPP-12175
Screenshots

UI Looks very good to me, clickable parts can clearly be distinguished from non clickable ones.
Nice work!

The new non-clickable areas have not a different background color then the clickable parts.

In the screenshots it looks like they actually have, or?

The new non-clickable areas have not a different background color then the clickable parts.

In the screenshots it looks like they actually have, or?

There was a 'not' too much in the description 😅

Uploaded videos instead of images to show every case.


2019-12-12 All Test Cases - Setting FLGEXSDE to 1 for all records causes computation error

Error
As of 472f88c043 when FLGEXSDE is set to 1 for all records the following computation error occurs. This happens for every test case currently on the OneDrive (excluding tc103 M3SS which does not run due to #82).
Error in `[<-.data.frame`(`*tmp*`, computation_df[, "FLGACCEPTKEL"] !=  :
  missing values are not allowed in subscripted assignments of data frames
5. stop("missing values are not allowed in subscripted assignments of data frames")
4. `[<-.data.frame`(`*tmp*`, computation_df[, "FLGACCEPTKEL"] !=
    1, , value = structure(list(SDEID = c(NA_integer_, NA_integer_,
NA_integer_, NA_integer_, NA_integer_, NA_integer_, NA_integer_,
NA_integer_, NA_integer_, NA_integer_, NA_integer_, NA_integer_,  ... at run_M2_SS_computation.R#2640
3. `[<-`(`*tmp*`, computation_df[, "FLGACCEPTKEL"] != 1, , value = structure(list(
    SDEID = c(NA_integer_, NA_integer_, NA_integer_, NA_integer_,
    NA_integer_, NA_integer_, NA_integer_, NA_integer_, NA_integer_,
    NA_integer_, NA_integer_, NA_integer_, NA_integer_, NA_integer_,  ... at run_M2_SS_computation.R#2640
2. run_M2_SS_computation(data = merged_data, map = map_data, method = method,
    model_regex = model_regex, parameter_list = parameter_list,
    return_list = return_list) at run_computation.R#2366
1. run_computation(data = d, map = mct, flag = flags, parameterset = parameterset)

This issue no longer occurs as of 00cdcd3.


Hit api

What?
I created the wireframe for a book store app using react. I also added the components and pages for this app.
Why?
This is to help users keep track of books they have read with detailed information on attributes of the book.
How?

I created the app using react
I started with the mobile first approach
I created a hamburger icon for the mobile menu
I created the components of the app
I created pages inside the components
I routed every link to their respective pages
I moved all styles into one folder in the src directory
I installed redux and redux toolkit
I added a redux folder in the src folder
I created a configureStore file in the redux folder
I created a books and categories folder in the redux folder. These individual folders contain their respective JavaScript files which contain their respective reducers.
I added some placeholder books through react-redux functionality
I used PropTypes for prop validation
I wrapped my app in Provider in index.js
I used useDispatch for adding a new book
I added 'remove' functionality to 'remove' button
I used useDispatch to display 'under construction'
I created a new book id inside the book.
I refactored add and remove books actions.
I added the API calls using AXIOS library.
I added a new Slicer to the reducer.
I added an Object.keys and a map function to receive the correct data from the books.

@Kamba56 Thank you for reviewing my project once again. I have resolved the bug but I did it but increasing the setTimeOut duration to allow the UI update

@emmiiorji Thank you for reviewing my project


589 derive vars dtm ignore sec

The R CMD check workflow fails because the documentation is out of sync with the code. Please run devtools::document() and comit the chanend .Rd file in the man folder. There are also a couple fo lintr annotation that have to be addressed.

Hi all,
I'm having trouble with RMD Check.    When I Run Tests within the test-derive_vars_dtm.R file everything goes smoothly.

But when I run the RMD Check it crashes.  Maybe my logic is bad within the functions that I updated.  Is it possible for you all to look over and provide any advice @thomas-neitmann @bundfussr @kabis-ops ?
The First Error is within the example - which works fine on its own

The Second Error
Is when I'm invoking my ignore_seconds_flag = TRUE.
I'm guessing the issue lies within my logic and using two booleans?? https://github.com/r-lib/devtools/issues/2032

Hi @bms63 - this seems to be due to compute_tmf and the condition on row 455 (see https://github.com/r-lib/testthat/issues/1176). If you change it to
 if (ignore_seconds_flag)  {
    if (n_chr >= 17)
      {abort("Seconds detected in data while ignore_seconds_flag is invoked")
    }
    else {
      case_when(
        (!is_na & n_chr >= 19 & valid_dtc) | is_na | !valid_dtc ~ NA_character_,
        n_chr == 13 ~ "M",
        n_chr == 10 | (n_chr > 0 & n_chr < 10) ~ "H"
      )}
   }
  else {
    ...
}

this should pass the CMD check.

@kabis-ops  Thank you for the suggestion but it still doesn't seem to be working once passed up to RMD Checks.  I looked through other code and can this being done - either two conditions in an if statement or a nested if statement like you suggested.
Feel like there is some other issue that I'm not seeing that is causing the problem.  Maybe the case_when function??

or how the compute_tmf is being used downstream??

Just a shot in the dark: You could try to remove !! in line 786. Maybe that's confusing dplyr.

No luck there!  Very strange error with the if/else statements as both nested if/else statements as well as if statements with multiple statements are used throughout this script.
I'm starting to think it has to do with how compute_tmf is used in the mutate() function later on in the script.

Maybe if (n_chr >= 17) is causing the issue because it results in a logical vector. You could try if (any(n_chr >= 17)).

Okay - lord have mercy.  Now we can actually start the review.  Many apologies for the mess and thank you for all the support.


doesn't work with repeat '.'

it doesn't work well with repeat, when you move to another indented text, it doesn't re-calculate. is it expected behavior?

I know this issue is ancient, but I have implemented than in my fork: https://github.com/urxvtcd/vim-indent-object


Support of jsonschema2pojo configuration

Proposition to fix issue #45

Hi!
Thanks for taking the time to write this enhancement - just a couple of minor changes before i can merge the PR.

Kindly fix version to 0.6.0 (we have not yet started using the SNAPSHOT convention :))
Kindly change license of added files to the Apache Software Foundation license
Please pull changes from master into your branch and merge

Thanks again!
Kurt

Done :)

Thanks, i'll look into it asap :D

Merged, thanks!


 @Manishearth
This is everything in #19 other than a better Arbitrary for String implementation, which I'm not super confident about implementing in a smart way. @Manishearth would you be up for doing that? Or outlining how you think that should be done?
Fixes #18
Fixes #10

That works
On Fri, Dec 27, 2019, 10:39 AM Nick Fitzgerald<EMAIL_ADDRESS>wrote:

@fitzgen commented on this pull request.
In src/unstructured.rs
https://github.com/rust-fuzz/rust_arbitrary/pull/20#discussion_r361722669
:

   if self.offset >= self.buffer.len() {

       Err(Error::NotEnoughData)

   } else {

       let offset = self.offset;

       self.offset = self.buffer.len();

       Ok(TakeRest {

           inner: self.buffer[offset..].iter().cloned(),

       })

   }

}
+}

+/// An iterator of the remaining bytes returned by
+/// Unstructured::take_rest.
+pub struct TakeRest<'a> {

inner: iter::Cloned<slice::Iter<'a, u8>>,

I think I will actually remove TakeRest and just return the rest of the
slice directly -- sound good?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-fuzz/rust_arbitrary/pull/20?email_source=notifications&email_token=AAMK6SCZ3NFRQMVA36GZAI3Q2ZDUVA5CNFSM4J7SEPSKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQJ5CLY#discussion_r361722669,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMK6SAV5PXDH7C7R6NBHFTQ2ZDUVANCNFSM4J7SEPSA
.


Is vcpkg required for building Azure SDK?

Query/Question
We are moving from azure-storage-cpplite to azure-sdk-for-cpp as the prior is marked as deprecating. After experimenting around the build instruction, it appears that vcpkg is implicitly used to install other dependencies (including Azure SDK with CMake ExternalProject_Add). As I noticed that vcpkg will pull dependencies that already used in other part of my project, is it possible to compile the Azure SDK in pure CMake, in this way, I can make sure the same depending libraries are used without looking further into how to integrate with vcpkg?
Why is this not a Bug or a feature Request?
This is general question regarding the build system.
Setup (please complete the following information if applicable):

OS: Ubuntu 20.04
IDE : N/A
Version of the Library used: azure-storage-blobs_12.7.0

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Query Added
[x] Setup information Added

Hi @RickWinter , although the customer is trying to build storage sdk, but I assume this could be a more general question: can C++ SDK be added as a CMake dependency and built without vcpkg?
I was checking our code base and I found AZURE_SDK_DISABLE_AUTO_VCPKG and FETCH_SOURCE_DEPS macros, so I assume the answer could be yes.
I created a CMake project for testing with below content as CMakeLists.txt and built with command AZURE_SDK_DISABLE_AUTO_VCPKG=ON cmake -DFETCH_SOURCE_DEPS=ON -B build
cmake_minimum_required(VERSION 3.11)
set(CMAKE_CXX_STANDARD 14)

project(azure-storage-test-proj)

find_package(Git REQUIRED)
include(FetchContent)

FetchContent_Declare(
  azure-storage-blobs
  GIT_REPOSITORY https://github.com/Azure/azure-sdk-for-cpp.git
  GIT_TAG azure-storage-blobs_12.7.0)

FetchContent_GetProperties(azure-storage-blobs)
if(NOT azure-storage-blobs_POPULATED)
  FetchContent_Populate(azure-storage-blobs)
  add_subdirectory(
    ${azure-storage-blobs_SOURCE_DIR}/sdk/storage/azure-storage-blobs
    ${azure-storage-blobs_BINARY_DIR})
endif()

add_executable(az-test src/test.cc)

if(WIN32)
  target_compile_definitions(az-test PRIVATE NOMINMAX)
endif()

if(MSVC)
  target_compile_options(az-test PUBLIC /W4 /WX /MP)
elseif(CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL
                                                "GNU")
  target_compile_options(az-test PUBLIC -Wall -Wextra -Werror -pedantic)
  target_compile_options(az-test PRIVATE -O3)
endif()

find_package(azure-storage-blobs-cpp CONFIG REQUIRED)
target_link_libraries(
  az-test
  Azure::azure-storage-blobs)

it failed with below error message
Vcpkg integrate step.
CMAKE_TOOLCHAIN_FILE is not defined. Define it for the user.
No transport adapter was selected, using libcurl as the default option for POSIX.
setting up compile options for STORAGE_BLOBS
project found STORAGE_BLOBS
FLAG VALUE : ON
Downloading version 1.8.0 of azure-core
Downloading version 12.3.1 of azure-storage-common
add folder build/sdk/core
CMake Error at build/_deps/azure-storage-blobs-src/sdk/storage/azure-storage-blobs/CMakeLists.txt:32 (add_subdirectory):
  add_subdirectory given source "build/sdk/core" which is not an existing
  directory.

add folder build/sdk/storage/azure-storage-common
CMake Error at build/_deps/azure-storage-blobs-src/sdk/storage/azure-storage-blobs/CMakeLists.txt:32 (add_subdirectory):
  add_subdirectory given source "build/sdk/storage/azure-storage-common"
  which is not an existing directory.

-- Retrieving version from /home/jamis/test/build/_deps/azure-storage-blobs-src/sdk/storage/azure-storage-blobs/src/private/package_version.hpp
-- VERSION_MAJOR 12
-- VERSION_MINOR 7
-- VERSION_PATCH 0
-- VERSION_PRERELEASE
-- AZ_LIBRARY_VERSION
CMake Error at /usr/local/share/cmake-3.26/Modules/CMakeFindDependencyMacro.cmake:76 (find_package):
  By not providing "Findazure-storage-common-cpp.cmake" in CMAKE_MODULE_PATH
  this project has asked CMake to find a package configuration file provided
  by "azure-storage-common-cpp", but CMake did not find one.

  Could not find a package configuration file provided by
  "azure-storage-common-cpp" (requested version 12.3.1) with any of the
  following names:

    azure-storage-common-cppConfig.cmake
    azure-storage-common-cpp-config.cmake

  Add the installation prefix of "azure-storage-common-cpp" to
  CMAKE_PREFIX_PATH or set "azure-storage-common-cpp_DIR" to a directory
  containing one of the above files.  If "azure-storage-common-cpp" provides
  a separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  build/_deps/azure-storage-blobs-build/azure-storage-blobs-cppConfig.cmake:31 (find_dependency)
  CMakeLists.txt:36 (find_package)

-- Configuring incomplete, errors occurred!

I couldn't figure out the problem, can your team take a look?
cc @LarryOsterman @gearama @antkmsft @ahsonkhan

As of today, vcpkg is required for installing the Azure SDK (more accurately: the only scenarios the team tests require the use of vcpkg).
I have a commitment for the next milestone to investigate alternate acquisition mechanisms, including using FetchContent from github directly.

@LarryOsterman Thanks for your response. I take it to mean that installing without vcpkg is not supported as of now.

@LarryOsterman Thanks for your response. I take it to mean that installing without vcpkg is not supported as of now.

Correct, It can be made to work with customizations by the user.  We do NOT support it out of the box at this time.  We are looking into it and may add support in the future.


Fix Release 0.5.0 with Reverts

I'm opening this just so that I can run PostCommit hooks on Jenkins. Sorry for the inconvenience.

Can you open it against master? The build breakage is just the usual release branch issue.

Nevermind, I see that the postcommits suffice.

Closed in favour of a more surgical approach


Add Alerting Kibana IT with no security

Issue #, if available:
https://github.com/opendistro-for-elasticsearch/opendistro-build/issues/600
Description of changes:

Adding integration test in distribution workflow for alerting kibana
Since cypress is unavailable for ARM64, adding only to X64 workflows. Also integration test with security has some issue and has been informed to the team
Minor edits to keep consistency in workflow (eg: Update ubuntu-16.04 to ubuntu 18.04)

Test Results:

TAR: https://github.com/opendistro-for-elasticsearch/opendistro-build/runs/1931625359?check_suite_focus=true
DEB:https://github.com/opendistro-for-elasticsearch/opendistro-build/actions/runs/579592736
RPM: https://github.com/opendistro-for-elasticsearch/opendistro-build/runs/1931401563?check_suite_focus=true
Windows: https://github.com/opendistro-for-elasticsearch/opendistro-build/runs/1931772240?check_suite_focus=true
Docker: https://github.com/opendistro-for-elasticsearch/opendistro-build/runs/1931889878?check_suite_focus=true

By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

These are only x64 tests, where are the ARM64 test?
If you plan to send it in another PR please rename the PR name to reflect this.
Thanks.

No cypress present for ARM64. I have mentioned in the PR description.

These are only x64 tests, where are the ARM64 test?
If you plan to send it in another PR please rename the PR name to reflect this.
Thanks.

No cypress present for ARM64. I have mentioned in the PR description.

I see. Thanks.


fix: Correct data and schema paths in error handler

Provide an extra error value so that client code have more data to form proper error message

Pull request is somehow related to the following issues #54 and #67.
I tried to keep the paths as close to the originals as possible aligning these to have almost the same format.
The paths are not fully correct in terms of JSON pointers (according to https://github.com/epoberezkin/ajv#validation-errors) since these are not starting with . nor / and schema path is has preceding #.
I can still update it to make the format compatible with AJV.

It seems that error handler has more bugs than the above fixes.
I'll sniff a bit more and once I'll have more things addressed I'll make a new pull request.


How to make jar file

Hi.
How to make jar file?

For debian:
apt install openjdk-11-jre-headless

For CentOS:
yum install java-11-openjdk-devel

Download gradle and unzip and install
https://gradle.org/install/#manually
cd /opt/gradle-7.5/bin
./gradle

Build
git clone https://github.com/aiven/opensearch-connector-for-apache-kafka.git
cd opensearch-connector-for-apache-kafka
/opt/gradle-7.5/bin/./gradle build
...
  BUILD SUCCESSFUL in 1m 12s
ls /opt/opensearch-connector-for-apache-kafka/build/libs
opensearch-connector-for-apache-kafka-2.0.2-SNAPSHOT.jar


Ignore 'accepted' msg when the client already accepted the call.

Still fails on incoming calls because CallInProgress.equals() returns false. The reason for false is that CallInProgress.mSeq is 0. It is 0 because CallInProgress.setCallActive() is not called yet. I suppose a simple solution is to move setCallActive() to some place earlier in the flow.


Howto create a fragment with nested fragments from a json string

Hi,
is there an easy way to create new fragments with nested fragments from a json string, without parsing the json string by myself an call createFragment for every nested fragment?
When the ember data object is initially created from the REST call the fragments are created automatically. How can i use this mechanism?
Best regards
Michael

TL;DR is no, not right now.
I assume that you already have normalized data for the fragment, and want to do something like:
someModel.set('things', {
  foo: 'bar',
  baz: {
    quuz: 'bang'
  }
});

Where `baz` is a nested fragment (if this is not what you're trying to do, please clarify). Unfortunately setting fragment properties with normalized JSON is not currently supported, but I've heard enough requests for it that it's on my TODO list.

Yes, and further, quuz can also be a nested fragment.

@cyphercrack Does this do the job for you?
var data = { foo: 'bar', child: { bar: 'baz' } };
var fragment = MyModel.createFragment();
fragment.setupData(data);

@slindberg is correct that the JSON must be denormalized as if it came from the server.

@cyphercrack Be careful using setupData; after thinking about this a little more, I think this won't copy sub fragments, but instead overwrite their data. Also keep in mind that it's a private method and subject to change.

Support added in #144, released in v0.4.2


LinkedList solutions in Python

Hey, I'd love to work on this one. Could you assign this to me

sure @NikhitaBarat

hey maam please asign this to me


Importing http URLs in Node mode fails at runtime

When I try to import a module with an http URL in Node mode:
import * as path from<EMAIL_ADDRESS>
export default async function (req: Request): Promise<Response> {
    return path.join("etc", "passwd");
}

I get this error
could not import endpoint code into the runtime

Caused by:
    TypeError: chiseld cannot load module<EMAIL_ADDRESS>at runtime (referrer: file:///dev/endpoints/hello)

(the exact error message might be different before #1556 is merged)
The problem is that chisel apply creates a bundle using esbuild, but esbuild keeps HTTP imports intact, so they will stay in the code that is sent to chiseld.

The issue is demonstrated in the test cli/tests/lit/http-import.node from #1556.

Not sure this is a bug, @honzasp . As far as I understand, node wouldn't be able to import those modules with that syntax, so we shouldn't expect to be able to do this in node mode.
I know this is in the context of us importing deno-std. The solution for that has to be us importing those things automatically and transparently, so the url style imports are only seen by core chiselstrike.


Enhancement: FuelScoop

Hi CmdrMcDonald,
The player journal has a FuelScoop even which calculates the amount of fuel scooped from a star and the total fuel after the scoop disengages. Can you add this information and associated variables for use in EDDI? This is useful for general traveling around the galaxy. Thanks!

This functionality is already in EDDI.  Here's the event script I use for refuelling:-
{_ Context}
{SetState('eddi_context_last_subject', 'refuelling')}
{SetState('eddi_context_last_action', 'complete')}
{SetState('eddi_context_fuel_remaining', event.total)}

{set fueltotal to ship.fueltanktotalcapacity}

{if event.source = "Market":
   {Occasionally(2,"{OneOf('{ShipName()}','Ship')}")}
   {OneOf("re-fuelled","fuel tanks topped up","tanks re-filled")}
   {Occasionally(3,"by {Humanise(event.amount)} tonnes")}
|else:
   {set total to (100/fueltotal)*event.total}
   {set amount to round((100/fueltotal)*event.amount,1)}
   {OneOf("{amount}% refuelled",
          "Refuelled by {OneOf('{amount}%','{Humanise(event.amount)} tonnes')}",
          "{OneOf('{amount}%','{Humanise(event.amount)} tonnes')} taken on board")}.
   {if total = 100:
      {Occasionally(2,"Main")}
      {Occasionally(2,"Fuel")}
      tanks at {OneOf("Maximum","100%")}
      {Occasionally(2,"capacity")}
   |else: {F("JumpFuel")}
   }
   {Occasionally(3,"{F('Honorific')}")}
}
.

Note: JumpFuel is a function I use to calculate the number of max range jumps available at the current fuel level.

Hi Darkcyde13,
Thank you for your quick response! I understand what your codes does, even though I don't understand the proper format for writing Cottle code. However, I can use this to adapt some VA code to the Ship refulled event which will do essentially the same thing.  Thanks again!


fix: DeclarativeCommentsFormat README

The title and links were all incorrect.

@eosrei thanks your contribution. 💯


Fix issue #843

replaced some nice, but unparseable unit strings
fixed wrong conversion ratios
added test

The old data files do not need an update if the scaling works.

The unit conversion replaces the old scaling. Currently they are scaled twice and thus wrongly.
Old files might not work due to unparseable units, but they will not work regardless of this change.


cmake: modules: west: Add function to verify blobs

Add a cmake helper function to verify if blobs have a valid checksum.

@tejlmand thanks for the review, see my comments below:

Not blocking because of feature itself, but because west is an optional tool.
The ability to use west to fetch binary blobs is a great help / convenience to users, but users are also allowed to download such blobs manually (or using a custom tool).

I agree, but users aren't forced to call this function, it CAN be used if west is known to be the build tool.

Therefore we should not rely on west for verifying a blob's SHA, also current implementation proposal does not present how callers of this function will invoke it.

I've added examples in the function description? It can be used in CMakelists.txt:
# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(hello_world)

include(west)

west_blobs_verify()

target_sources(app PRIVATE src/main.c)

Another minor observation, it seems to me that PR will make it harder to locally develop a bin-blob and test it with Zephyr before releasing it the public, as the west_blobs_verify() will fail the build.

I don't see why this should be the case? A local file can either be omitted from the module.yml file entirely or the sha256 checksum can be calculated locally and updated in module.yml.

@tejlmand I've added a check if WEST wasn't set to WEST-NOTFOUND and print a warning.

I agree, but users aren't forced to call this function, it CAN be used if west is known to be the build tool.

which was exactly the reason for my question.
Because if called from a (downstream) sample's CMakeLists.txt file. then correct other assumptions can be made by sample author.
But someone could also call those functions elsewhere, as example from a Zephyr module and thus suddenly enforce west as a tool, which is mostly my concern.

A local file can either be omitted from the module.yml file entirely or the sha256 checksum can be calculated locally and updated in module.yml.

Of course users can, just like they can comment out logic inside west_blobs_verify() functions.
But should really be possible to just touch code in question, just like when modifying a source file.

I agree, but users aren't forced to call this function, it CAN be used if west is known to be the build tool.

which was exactly the reason for my question. Because if called from a (downstream) sample's CMakeLists.txt file. then correct other assumptions can be made by sample author.
But someone could also call those functions elsewhere, as example from a Zephyr module and thus suddenly enforce west as a tool, which is mostly my concern.

I see, is the latest addition, where WEST-NOTFOUND is checked, sufficient to cover this case?

A local file can either be omitted from the module.yml file entirely or the sha256 checksum can be calculated locally and updated in module.yml.

Of course users can, just like they can comment out logic inside west_blobs_verify() functions. But should really be possible to just touch code in question, just like when modifying a source file.

I don't really follow here, what would you like to see changed?

I don't really follow here, what would you like to see changed?

it was more a comment that users testing locally may just omit the file from module.yml or update its SHA.
I just tried to exemplify why such comment was really not useful to users working with the bin-blobs, as users can do anything (such as modify code) to get around build failures, but they shouldn't really have to resort to such kind of things.
Users should be able to replace a local blob with a version of their choice (for example for debug purposes) without doing extra modification to the workspace, just like users can make local modification to source files.

I see, is the latest addition, where WEST-NOTFOUND is checked, sufficient to cover this case?

Now that the general principle of west being optional, let me take a look at the code itself.

Thanks @tejlmand for the suggestions, I've updated the PR.
The current implementation allows you to specify paths for binary blobs, but if omitted simply verifies all the blobs. The MODULE argument can limit that to a single module.

@tejlmand I've made the MODULE argument a required one, I think that is closer to what is expected?

Marking as DNM until I have been able to test the module name.

@tejlmand thanks for the effort, I've updated the PR
As per the suggestions I feel that the MODULE argument should be required, it is now possible to pass ${ZEPHYR_CURRENT_MODULE_NAME} anyway.

I would also like to add a test case, but I'm not sure where to add this.

Hi, the CI failure has been fixed upstream, if you rebase it should pass.

@carlescufi you mind taking a look at this PR, as you've introduced the blobs infrastructure? Thanks


Add a short threshold before the keyboard is shown on app foreground

I am probably skipping a few steps with this patch, which is why I marked it as a draft. I am submitting this because it fixes a small itch that I had. If you are interesting in picking this up then I'd love to get it into a state that makes sense for the product. I've been running this in my local build.

This patch introduces a time interval that is used to determine whether the keyboard should be shown on App Foreground when the Show Keyboard on App Launch setting is enabled.
I like that feature, because it is what I want when I open the browser for first time. Or after not using it for a long time.
However in my day to day use I often am in the situation where I switch back and forth between the browser and another app in a very short time interval and in those cases I do not want the keyboard to show up. My intent then is mostly is to continue browsing the same site or reading the page I already had open in the current tab - and not to visit a new page.
I settled on a pretty low threshold of 45 seconds. This works for me but may not be representative in general. I'm not sure if this application has telemetry events, but those could be used to look at user behaviour to determine if this is a change that makes sense for a bigger audience or to determine a better threshold.
No proper testing has been done - I've only used this on an iPhone X running iOS 14.1.
TODO

Task/Issue URL:
Tech Design URL:
CC:
Description:
Steps to test this PR:
1.
1.

Copy Testing:

[ ] Use of correct apostrophes in new copy, ie ’ rather than '

Orientation Testing:

[ ] Portrait
[ ] Landscape

Device Testing:

[ ] iPhone SE (1st Gen)
[ ] iPhone 8
[ ] iPhone X
[ ] iPad

OS Testing:

[ ] iOS 11
[ ] iOS 12
[ ] iOS 13
[ ] iOS 14

Theme Testing:

[ ] Light theme
[ ] Dark theme

Internal references:
Software Engineering Expectations
Technical Design Template

Thanks for this and thanks for making it a draft.
Generally we prefer issues first, as per our contributions guidelines.
But let me run this past the product review team this week, I think it's a good change.

Would you like me to write a story in an issue?

No, that's ok this time, thanks :)
I've submitted the change for feedback and we're tracking it internally at: https://app.asana.com/0/392891325557410/1198923366005691

Hi! Thanks for your patience. :)
I took this through the product review process and we like the change in general but think a better threshold would be 20 seconds.  Would you be OK with that?
Thanks.

Awesome. I think a lower delay is fine.

Hi @st3fan - do you want to push a commit with that change, then we can get this reviewed and merged this week.  Thanks in advance!


Add flag to skip SSL validation with InfluxDB

Hi
I've added a flag insecuressl=[true|false] to InfluxDB sink to skip validation of SSL certificates. Similar flag already exists for Kubernetes source.
Thanks and best regards,

Ashley

This change is

I signed it!

@CallMeFoxie please squash commits before merge

@piosz Commits squashed

LGTM


Fix potential System.NullReferenceException in the ToString() methods

Also enable nullable reference types that helps catching these kind of bugs.

I have exactly this problem after updating to the latest version a moment ago.
When I use the library in this way it throws an error:
this.Logger.LogInformation($"File size: {ByteSize.FromBits(fileInfo.Length)}");

While waiting for a new version you can workaround this issue by explicitly specifying a format string, for example:
this.Logger.LogInformation($"File size: {ByteSize.FromBits(fileInfo.Length):0.0}");


Add an optional parameter to the print method for the ending character

A handy feature in Python (doc) is to be able to customize the ending character when printing. Why not implement this in Dart?
The implementation looks like:
void print(Object object, [Object end = '\n']) {
  String content = '$object$end';

  if (printToZone == null) {
    printToConsole(content);
  } else {
    printToZone(content);
  }
}

This is basically a request to make print not necessarily add a line terminator.
You can use it to print two strings as print("foo", "bar"), but that's unnecessarily complicated.
It's a problematic change because print doesn't have to print a newline. When logging to a browser console, it would be better to log the object directly, than a string and a newline.
The newline is what is used to delimit outputs when printing to a text terminal.
If you want to control your text output in more detail, you can use dart:io's stdout, which has both a write and a writeln.

@lrhn I agree with your comment, but I have another use case,
print write directly to fd's stdout which sounds ok (1) but automatically add a new line later and do not give an option to disable it.
stdout.write wrap fd's stdout in a stream, with an encoder and open the fd as a file. (2)
On my particular use case, the problem that stdout generates (with all the wrapping), is that it don't honor the console setup done using termcap database codes. For example:
...
   nc.setFgPalindex(12); // setup term FG using `setaf` termcap definition
   nc.setBgPalindex(23); // setup term BG using `setab` termcap definition
   stdout.write('test');
...

Using print instead of stdout.write all works ok, the color setup is honored, but a new line is added :(.
Having a method to write to the console without all the wrapping that stdout does, but with a bit more of options, will be great!
(1) https://github.com/dart-lang/sdk/blob/d9b88111affb1d13dc052a8c58f11f1a5e6e2742/runtime/bin/builtin_natives.cc#L95
(2) https://github.com/dart-lang/sdk/blob/main/sdk/lib/io/io_sink.dart#L18


Innogy: Fehler "charger ...: dial tcp ...: connect: connection refused" nach Upgrade auf 0.126.2

Describe the bug
Seit dem Upgrade von 0.125.0 zu 0.126.2 bekomme ich ständig Fehler (rotes Warndreieck im UI) angezeigt.  Ich vermute es hängt mit folgender Änderung zusammen:
https://github.com/evcc-io/evcc/commit/da4af01d736503b77901648d8a03f45516a99591
Das dort eingeführte Register 307 (igyRegEnergy) gibt es laut Modbus Doku (https://www.eon.de/content/dam/eon/eon-de-zwei/documents/Privatkunden/emobility/ModbusTCP_eBox_manual_v1.pdf) für meine Wallbox (Innogy / e.on / Compleo eBox Professional) nicht.
Steps to reproduce

Upgrade von 0.125.0 zu 0.126.2

Configuration details
# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc.local # .local suffix announces the hostname on MDNS
  port: 7070

log: debug
levels:
  cache: error

# database configuration for persisting charge sessions and settings
database:
  type: sqlite
  dsn: /var/lib/evcc/evcc.db

# unique installation id
plant: 1b9b8f3f9d85af13394be13964816b05ec8f08f52b4d2674f5853bda089d6caf

interval: 15s # control cycle interval

sponsortoken: ...

# sponsors can set telemetry: true to enable anonymous data aggregation
# see https://github.com/evcc-io/evcc/discussions/4554
telemetry: false

meters:
- type: template
  template: solax
  id: 2
  host: <IP_ADDRESS>
  port: 502
  usage: grid
  modbus: tcpip
  name: grid1
- type: template
  template: solax
  id: 2
  host: <IP_ADDRESS>
  port: 502
  usage: pv
  modbus: tcpip
  name: pv2
- type: template
  template: solax
  id: 2
  host: <IP_ADDRESS>
  port: 502
  usage: battery
  modbus: tcpip
  name: battery3

chargers:
- type: template
  template: innogy-ebox
  id: 1
  host: <IP_ADDRESS>
  port: 5555
  modbus: tcpip
  name: wallbox4

loadpoints:
- title: Garage
  charger: wallbox4
  mode: pv

site:
  title: evcc
  meters:
    grid: grid1
    pv:
    - pv2
    battery:
    - battery3
  residualPower: 100

vehicles:
  - name: EQV
    title: EQV 300
    type: mercedes
    account: ... # Mercedes Me Nutzer-Id (email)
    region: EMEA # MB me Region (EMEA, APAC, NORAM)
    vin: ...
Linux
Version
0.126.2

das ist nach dem Release 0.126.2. wieder zurückgenommen worden. Ist aktuell nur im Nightly verfügbar.

Siehe #13771

Ok, vielen Dank für den Hinweis. Sorry, hatten den anderen Issue wohl übersehen.


chore: update circular progress tests to use fixtures

i remember we were moving tests towards this structure so figured i'd do a few more.
i've updated the circular progress bar and the four colour one, too. now we cover the defaults and also the behaviour of setting out of bounds progress percentages.
let me know if this is fine & still the way you're writing them
cc @e111077

hmm IE tests fail the set aria-label test on the initialization check. Investigating

seems to be, no matter how long I await, the attribute ariaLabel is not being turned into a prop. I went ahead and fixed it on my end by changing ariaLabel=${propsInit.ariaLabel ?? ''} to .ariaLabel=${propsInit.ariaLabel ?? ''}
This is an issue for further investigation later

specifically in IE? I wonder if they reserve arialabel or something. could try setting it on a div in IE and see if it lets you (I don't have IE 😬 )
good idea on the fix anyhow, thanks for merging :)

I fixed it internally which a bot merges in a separate CL with my change which then merges this CL because they share the same hash, so already fixed in master

@e111077 FYI i did try it in IE and it does not let you name an attribute arialabel. explains a lot

Oof do you mind filing a bug


feat(examples): add docker

Docker example including a Next.js app which makes API requests to an Express API.
Can be built individually or via docker-compose (see README.md)
Addresses https://github.com/vercel/turborepo/issues/215

Hi, @tknickman. does your example work with yarn v2/v3?

Hey @xiaoyu-tamu, no - this example targets yarn v1 specifically. But we are always open to new examples!