fix: CPK has-many has-one associatedFields

Issue #

Table of contents

Library Changes data-dev-preview https://github.com/aws-amplify/amplify-swift/pull/2730
Library Changes v1 - https://github.com/aws-amplify/amplify-swift/pull/2734
Library Changes main - https://github.com/aws-amplify/amplify-swift/pull/2735 (You are here)
Codegen Changes has-many - https://github.com/aws-amplify/amplify-codegen/pull/538
Codegen Changes has-one - https://github.com/aws-amplify/amplify-codegen/pull/541

Description

This PR does not attempt to fix the uni-directional has-many lazy loading list issue, see https://github.com/aws-amplify/amplify-swift/pull/2730  for more details and the fix. Since the CPK codegen changes (https://github.com/aws-amplify/amplify-codegen/pull/538 ) are available in main, this PR introduces that parameter to make sure newly generated types continue to compile with the added associatedWithFields argument to hasMany model fields. When we are ready to move forward the lazy loading feature branch https://github.com/aws-amplify/amplify-swift/pull/2658 , the fix will be included as well
We are also fixing uni-directional has-one CPK use case by extending has-one with associatedFields. Corresponding codegen changes are in https://github.com/aws-amplify/amplify-codegen/pull/541
General Checklist

[ ] Added new tests to cover change, if needed
[ ] Build succeeds with all target using Swift Package Manager
[ ] All unit tests pass
[ ] All integration tests pass
[ ] Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)
[ ] Documentation update for the change if required
[ ] PR title conforms to conventional commit style
[ ] New or updated tests include Given When Then inline code documentation and are named accordingly testThing_condition_expectation()
[ ] If breaking change, documentation/changelog update with migration instructions

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

We will not move foward with this PR as the necessary changes are in data-dev-preview and will be merged to main soon


Enhancement: Expose a global IKernelConnection to output renderers

Right now we generate a global WidgetManager  and a proxy kernel  for ipywidgets to work.
For customers that don't want to write ipywidgets but still need kernel communication (one such one is Synapse) they really only need the IKernelConnection.
We should expose this as a global in our preloads for when a kernel runs.
Additionally, we should check what Jupyter classic did to expose this before. It would be nice to follow the same API pattern (exactly if possible) with the intent to make it easier to port jupyter extensions to VS code/AZNB

An add on to this would be to expose this same IKernelConnection on the extension host side with an api like:
getKernel(uri: Document): Promise<IKernelConnection | undefined>

Is there any plan to implement this at some point ?

It's not in our near future plans (no milestone set) but it's needed by a partner team so it's likely it will get implemented at some point.

@duburcqa
What's your user case for this feature?

@DonJayamanne I'm developing a robotic simulator using a webgl viewer based on treejs. In ipython i can instantiate a iframe, that is opening a connection with the kernel in javascript so that the viewer and the main python thread can communicate back and forth. Currently, I can create the iframe in VSCode and used python to communication with the viewer, but not the other way around. I really need it to handle basic events such as waiting for the meshes to load before capturing the frame programmatically.

@duburcqa We've created some API that exposes the Kernels and their API to external extensions.
This is still a work in progress and we don't have any samples for for communicating with the kernel from webviews and using widgets (it will require quite a bit of work).
Please feel free to have a look at the API exposed by the extension.

@DonJayamanne Interesting ! Is there any documentation somewhere ?  I'm relying on one javascript method in particular:
window.parent.Jupyter.notebook.kernel.comm_manager.new_comm

window.parent.Jupyter.notebook.kernel.comm_manager.new_comm

We do not expose this anywhere. Currently there are no plans to expose this, as this could pose a security risk (allowing any extension to access the kernel and execute code - an issue when dealing with remote jupyter kernels)

Ok i see. I was expecting this. No problem. Thank you anyway !

I'll see what can be done, I think we can use the same model we have today (exposing 3rd party API) to expose these kernels in output renderers.

@duburcqa Do you have a VS Code extension that ships the code running in the renderers?

@DonJayamanne No, it is a python package to install via pip:
pip install jiminy_py

Then, a basic jupyter noteboox example can be found here. Running it will embedded the renderer in a cell using a HTML iframe, and the latter while try to open a connection with the kernel through javascript in order to send simple information such as acknowledgements. Here is the embedded HTML code I'm referring to. Note that this approach is not working for jupyterlab for a similar security concern. I'm open to developing a proper extension module but I have zero knowledge on this and I don't know where to start.
Thank you for paying attention to my problem!

After digging a little bit in other issues, I'm facing the issue than here: https://github.com/microsoft/vscode-jupyter/issues/1477

I'm facing the issue than here: #1477

Not following you, is iminy_py also opening up sockets and communicating with the kernel via its own sockets?
It not, then its not the same as #1477

It is partially the same. I'm not communicating with the kernel via my own sockets, but they are relying on IPython.notebook.kernel.comm_manager just like me.

From what I can tell, Jupyter lab renderers cannot access the kernel unless the renderers are Jupyter Lab specific renderers.
Such as the following https://github.com/jupyterlab/jupyterlab/tree/master/packages/vdom
I.e. the widget gets the Kernel as a ctor argument.

hum. I tried to look a bit but my knowledge in javascript and jupyter is too limited to build something similar.

I want it to be compatible with cloud notebook providers such as colab, kaggle or deepnote. So developping a widget is not an option.

So developping a widget is not an option

We try to support compatibility with Jupyter lab and classic Jupyter notebook.
From what you're saying you aren't willing to create a Jupyter notebook/lab widget.
I'd recommend you consider that as it's already an industry standard, and as mentioned earlier, exposing kennels another way could lose security issues, basically any J's code from other extensions could execute code on local and remote machines.
Then again theres the whole security issue.

I see your point. I will think about it. Yet, for you to know, recently I managed to get it to work in VSCose and Jupyter by connecting to the kernel websocket manually. So the current implementation of VSCose notebooks is not preventing this at all.

Closing this issue as we expose an API for users to access the kernel connection. If users which to access the kernel, they could, send messages back to the extension host from the webview .

@duburcqa I'm having the same issue. Do you have an example of how to connect to the kernel without creating a custom widget ?
My use-case is to run IPython.notebook.kernel.execute for bidirectional Python communication.


Rework search params in ScopusSearch

This PR allows the user to pass count and max_entries to ScopusSearch(), closing #84. A few misc notes:

I've kept the max_entries param and allowed the user to set it to None if they don't want to perform the check.
I chose to use max_entries=None as the default in ScopusSearch(), as that would be the value that most scopus subscribers would want to use and you mentioned that subscribers are the primary users of the package. AuthorSearch and AffiliationSearch keep their defaults of 5000 because that limit still exists for both subscribers and non-subscribers of the Author Search and Affiliation Search APIs.
The default value for count is 25 in ScopusSearch(), as view defaults to "COMPLETE" and thus count should conform to this default view.

Thanks for this!  I don't understand some of the changes in scopus/scopus_search.py: What is the rational for not setting count to the maximum that the view allows?  Non-Subscribers need to set it to 25, but subscribers can have 200 or 25 results, depending on the view.

The default view for ScopusSearch is "COMPLETE," and the max count for that view is 25. Non-subscribers don't have access to the COMPLETE view, FYI. https://dev.elsevier.com/api_key_settings.html

Consider this: A subscriber wants to access the STANDARD view, so she writes view="STANDARD".  With your solution she also should set count=200, while before the view was set by scopus - why making it more difficult for subscribers?  I understand your approach, namely making it easier for non-subscribers.  I fully accept that, unless it makes it harder for subscribers.
I would say we set count according to the maximum value that the view provides, but users (that is, non-subscriber) can still set their own count.

Another point: I think we should rather perform the testing for valid views on the level of high-level classes (i.e. ScopusSearch(), AuthorSearch(), AffiliationSearch()) and not delegate everything to the Search() class.  That's because the Author Search and Affiliation Search APIs have but one view (STANDARD).

My solution is geared towards subscribers. The default view that ScopusSearch uses is COMPLETE. This view has a max count of 25 (non-subscribers can't even access the COMPLETE view, mind you), hence the default value of count is 25. We can't have a default view of COMPLETE with a default count of 200- that would error b/c it's not allowed by the API. If a subscriber wants to use a STANDARD view, then they can up the count to 200 if they want, or they can just leave it as 25. Similarly, non-subscribers will have to change the default view to STANDARD (which comes with a 25 max count for them) if they want to download results.

Another point: I think we should rather perform the testing for valid views on the level of high-level classes (i.e. ScopusSearch(), AuthorSearch(), AffiliationSearch()) and not delegate everything to the Search() class. That's because the Author Search and Affiliation Search APIs have but one view (STANDARD).

Agreed, this is a better approach

Sorry, I could only get back to this today.
Am I correct assuming that the check for allowed views should go back into scopus/scopus_search.py, based on your last statement?
Re the count variable:
If I am a subscriber, and want to see the Standard view, then in your solution I have to set two parameters: count=200 and view="STANDARD". Before, it was sufficient to set just one parameter: view="STANDARD". Count would adjust accordingly.
So for subscribers the situation has become worse. This is the price we have to pay to make non-subscribers be able to use this class too, because their count has to be equal to 25 for the Standard view.
However, there is cursor=True to the rescue. Non-subscribers have to set this to False anyways, don't they? So in order to automatically determine whether the user is a subscriber (and thus raise count to 200), we can use cursor:
if cursor and view == "STANDARD":
    count = 200

This way, I think, we don't even need to specify count as a parameter, do we?
count = 25
if cursor and view == "STANDARD":  # Subscriber using Standard view
    count = 200

Probably, we could set max_entries = 5000 in the same go because we know that if cursor is False, we need this variable anyways. However, that's something we can set elsewhere, I guess, and thus do it in another PR.

Am I correct assuming that the check for allowed views should go back into scopus/scopus_search.py, based on your last statement?

Yeah, I'll do this

If I am a subscriber, and want to see the Standard view, then in your solution I have to set two parameters: count=200 and view="STANDARD"...So for subscribers the situation has become worse.

I would imagine that subscribers will normally want the COMPLETE view, and hence will want to use count of 25, both of which are the defaults. Yes, if they want to use the STANDARD view, they have to change that param (they don't necessarily have to change count, though....count of 25 would work too and would just result in a slower download). I don't see a problem with subscribers having to alter a param or two if they want to use a simpler view.

However, there is cursor=True to the rescue. Non-subscribers have to set this to False anyways, don't they?

Yes

So in order to automatically determine whether the user is a subscriber (and thus raise count to 200), we can use cursor:

This feels wrong to me. I don't think there should be an override on a param that the user has access to like this. It feels like something that would result in confusion.

This feels wrong to me. I don't think there should be an override on a param that the user has access to like this. It feels like something that would result in confusion.

Hence not making count a parameter at all. If we can derive the value if count from other parameters, under the reasonable assumption, that users would not want to deviate from the maximum value, than we should do that.

IMHO if you think the package should be setting these kinds of values/params for the user based whether they're a subscriber or not, it'd be best to be transparent about it and just add a parameter for whether the user is a subscriber (e.g., subscriber=True). Then you could remove the cursor and count params and make it clear to the user in the docs for subscriber that cursor and count are set based on this value. This would also allow you to add assertions that non-subscribers aren't trying to access an API or API view that they don't have access to.

Yes, that would certainly be the most transparent solution. One parameter for the user that sets the optimal parameters under the hood.  Let's do this ASAP.

I can finish this tomorrow by pushing to your branch and then accepting it, if you can't finish it soon.

I don’t have subscriber access to APIs anymore, so probably won’t be
working on this PR/other issues I opened.
On Mon, Apr 15, 2019 at 2:14 AM Michael E. Rose<EMAIL_ADDRESS>wrote:

I can finish this tomorrow by pushing to your branch and then accepting
it, if you can't finish it soon.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/scopus-api/scopus/pull/95#issuecomment-483120754, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKs3OUvCEqsUzwW2ssTEQyV1YSnw9a6Hks5vhBjGgaJpZM4cRLg9
.

Alright, I finished the PR.  Thanks a lot for all the work and your ideas!


feat: CleverTap Inbox Notifications

Description
CleverTap Inbox Messages will be rendered along with other notifications in Notification Center.
List of currently supported CleverTap properties
Notes

New messages DO NOT appear within current user session. Unfortunately, CleverTap Inbox is updated only once: when the app starts. Quoting their support:

You will have to close the application and re-open it in order to get the new app-inbox messages they will not get updated if the application is already open.

CleverTap Inbox Messages are stored in global state:

similar approach is used for remote notifications from Admin Dashboard
ensures the messages are already fetched when user opens Notification Center

Any message in Notification Center can now have an optional header:

Test plan

Tested manually on Android Emulator
Updated unit tests

Related issues

Fixes RET-943

Backwards compatibility
Y

notifications will not be received in real time, if a new notification is published in Clevertap during the user's session

@kathaypacific
generally yes, but there are 2 situations I'm aware of when it is updated in the real time:

when user dismisses the notification. we call CleverTap.deleteInboxMessageForId() which in turn fires CleverTap.CleverTapInboxMessagesDidUpdate providing us with the messages without deleted one (but sadly without new ones). and yes, that could be mirrored with a single fetch.

when we use "Preview & Test" functionality in CleverTap. in this case the message is delivered within user session after user taps on push notification on their phone.


Allowing optional JVM parameters to be set

We have a need to set some custom JVM parameters on the Chronos process (for logging configuration, etc.), so it would be nice to be able to set these in the init script rather than having to patch the /usr/bin/chronos script.

+1

How about duplicating what https://github.com/mesosphere/marathon/blob/master/bin/marathon-framework does with JAVA_OPTS? It seems the two scripts once had the same codebase but only marathon-framework evolved.
I would prefer JAVA_OPTS as it's the standard way of adding jvm args via the environment.
I also recommend looking at https://github.com/mesosphere/marathon-pkg/blob/master/marathon.service where we introduced EnvironmentFile=-/etc/sysconfig/marathon. This essentially allows us to change JVM parameters at startup and is the RedHat recommended way of doing so (http://fedoraproject.org/wiki/Packaging%3ASystemd#EnvironmentFiles_and_support_for_.2Fetc.2Fsysconfig_files).

I think your suggestion looks promising.
We should keep framework package and configuration standardized.

On 11 May 2015, at 18:52, Lukas Lösche<EMAIL_ADDRESS>wrote:
How about duplicating what https://github.com/mesosphere/marathon/blob/master/bin/marathon-framework does with JAVA_OPTS? It seems the two scripts once had the same codebase but only marathon-framework evolved.
I would prefer JAVA_OPTS as it's the standard way of adding jvm args via the environment.
I also recommend looking at https://github.com/mesosphere/marathon-pkg/blob/master/marathon.service where we introduced EnvironmentFile=-/etc/sysconfig/marathon. This essentially allows us to change JVM parameters at startup and is the RedHat recommended way of doing so (http://fedoraproject.org/wiki/Packaging%3ASystemd#EnvironmentFiles_and_support_for_.2Fetc.2Fsysconfig_files).
—
Reply to this email directly or view it on GitHub.

@sdwr98 do you want to update the PR? If you currently don't have the time I can create one. Let me know.

@lloesche Done - thanks for the suggestions

LGTM 👍


spec: tweak pod definition

remove mount namespace requirement and instead switch to "shared
volumes" language. As raised previously elsewhere 1 2, this
is somewhat moot since applications start chrooted into their
respective filesystems anyway.
Add illustrative explanation of the significance of the namespaces

Fixes #318

I spent a bit of time agnosing over wording here before deciding that I couldn't really improve on what I went with in https://github.com/GoogleCloudPlatform/kubernetes/pull/4701, so this is cribbed liberally from there.
/cc @thockin

oops, I thought this landed already. @thockin ?


configure ztunnel logs for all pods with one command

Please provide a description of this PR:
works for --selector and ds/ztunnel command formats
also fixes a bug with detecting unknown log levels
To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

[ X ] Ambient
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@GregHanson: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio_exp
71b10f3d3812e6dd3146bda06d3d93ab80ab1011
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Sorry my issue wasn't more clear, IMO this should be the behavior for everything with logs, not just ztunnel. There is no reason to want to set the logs of 1 random pod in a deployment I would think

Agree - and if there was a need for that, presumably you could just specify a unique selector that targeted that pod.

Sorry my issue wasn't more clear, IMO this should be the behavior for everything with logs, not just ztunnel. There is no reason to want to set the logs of 1 random pod in a deployment I would think

I'm ok with adding that functionality for all pods when using the pc log command.  My original thought was most beginners may not know which ztunnel will log their request since it depends on nodes in the request path - so ztunnel being special in this case made sense from a UX standpoint.
@howardjohn my only concern with that approach is just the massive difference in generated logs between a ztunnel instance and an envoy instance - and what the impact may be for a deployment of multiple replicas and all of them getting set to trace at once.  I don't feel strongly about it - but just wanted to make sure it was raised

Agree - and if there was a need for that, presumably you could just specify a unique selector that targeted that pod.

@bleggett an exact pod name (vs --selector or deploy/xxx format) can always be used to target a specific pod

/retest

putting hold on this one while waiting for review on the one in master branch: https://github.com/istio/istio/pull/43083

/cherry-pick release-1.17

@GregHanson: once the present PR merges, I will cherry-pick it on top of release-1.17 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.17

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

new output:
istioctl pc log ds/ztunnel -n istio-system --level debug
ztunnel-bpwmt.istio-system:
current log level is debug

ztunnel-h82gs.istio-system:
current log level is debug

ztunnel-w49bc.istio-system:
current log level is debug

PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@GregHanson: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio_exp
d596eeeaf6fe67c9b60e50ef5b2899c57bf58432
link
true
/test lint

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn what should the default log level be for ztunnels during reset?  The reset level for envoy proxies is warning.  Ztunnel however is hardcoded to go to info.  Assuming ztunnel and envoy should behave the same here - unless there is a design decision behind this?

ztunnel has an explicit reset flag in the API so we don't need to guess levels for reset. But the reason for info vs warn is ztunnel logs are made for Istio users, envoy ones are not so they are spammy to istio users.


[Feat] Suggestion to add cards

Adding these browsing cards would be great!

Please assign me this issue and label it hacktoberfest-accepted.

Please assign me this issue and label it hacktoberfest-accepted.

I've worked upon this issue, please merge my PR if I've done everything right.😊
https://github.com/Biplab-313/hacktoberfest-2024.github.io/pull/8

@Biplab-313 Can you suggest me an changes? If there is any.


AIX nodes System zlib not setup ?

Not sure this fails every time, but about 50% of the time:
https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-aix-ppc64-hotspot/854/console
18:20:45  checking for which libpng to use... bundled
18:20:45  checking for compress in -lz... yes
18:20:45  checking for which zlib to use... system
18:20:46  checking for system zlib functionality... configure: error: System zlib not working correctly
18:20:46  not ok
18:20:46  configure exiting with result code 1
18:20:46  Error: No configurations found for /home/jenkins/workspace/build-scripts/jobs/jdk11u/jdk11u-aix-ppc64-hotspot/workspace/build/src.
18:20:46  Please run 'bash configure' to create a configuration.

This is what is being run: https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/ceb64c0bc6bb3ceef1bec3892c9ce93bf2b74955/make/autoconf/lib-bundled.m4#L193
maybe zlib.h not being found?

I can't see zlib.h in /usr/include ?

I think the ansible playbooks are missing zlib install ?

zlib is one of those strange things. AIX provides libz.a via rpm.rte, but not libz.h - and that created regular issues with installing the RPM packaging libz and libz-devel.
Historically, the RPM packaging of libz was just different enough that it broke things expecting the IBM libz (taht was still using the member name libz(shr.o) or libz(libz.so.1) - and the RPM had libz(libz.so.2) - all from memory.
The AIX toolbox packages libz.a better, i.e., it extracts and inserts the archive members in /usr/lib/libz.a into /opt/freeware/lib/libz.a.
Just had a thought, I think rpm.rte that provides libz.a - does it by having /usr/lib/libz.a point - as a symbolic link - to /opt/freeware/lib/libz.a. If that is the case, then an update of libz.a - e.g., as an update of rpm.rte - may break whatever was there before.
And. lastly, what version of libz is installed. Historically, AIX has been way behind.
Note: the whole yum dependency tree often installs a new rpm.rte - but it might not need to update the RPM libz - and the library is in an unknown state.
Anyway - fixable - but, imho, inherent on having two package managers updating the same file.

This is the situation on build-osuosl-aix71...-{1,2}:
# rpm -qa | grep zlib
zlib-1.2.11-2.ppc
zlib-devel-1.2.11-2.ppc
# find /usr /opt -name zlib.h
/opt/freeware/include/zlib.h

On a system installed later (test-osuosl-aix71-ppc64-1 I see this:
root@p9-aix1-ojdk05:[/root]rpm -qa | grep zlib
zlib-1.2.11-1.ppc
zlib-devel-1.2.11-1.ppc
root@p9-aix1-ojdk05:[/root]find /opt /usr -name zlib.h
/opt/freeware/include/zlib.h
/usr/include/zlib.h
root@p9-aix1-ojdk05:[/root]find /opt /usr -name zlib.h -ls
21833   94 -rw-r--r--  1 root      system       96239 Feb 14  2017 /opt/freeware/include/zlib.h
14203    1 lrwxrwxrwx  1 root      system          33 Sep  4 15:21 /usr/include/zlib.h -> ../../opt/freeware/include/zlib.h

So, I expect the current playbooks handle this properly - OR - the recent update (note the later RPM packaging label on the build servers (zlib-1.2.11-1.ppc versus zlib-1.2.11-2.ppc) - they were, iirc, recently updated using yum update - removed the link. (?)
I propose to manually add/restore the symbolic links.

OK - additional proposal (for PR) - just looked at test-osuosl-aix72-ppc64-{1,2} and they are also missing the symbolic link.
Needed: an update to the playbooks to ensure there is a symbolic link /usr/include/zlib.h when it does not exist as a file AND /opt/freeware/lib/zlib.h exists. AND - what is also needed - from experience - zconf.h must also be included. Configure, iirc, only checks for existence of zlib.h

@aixtools above changes sound good to me, thanks

@andrew-m-leonard Hmmm it is a bit of a fudge - I wonder if we can make the build process pick it up from the expected location instead?

jdk17 hotspot succeeds - zlib bundled: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk/job/jdk-aix-ppc64-hotspot/392/
jdk17 openj9 fails - zlib system https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk/job/jdk-aix-ppc64-openj9/358/

So there is a variance of Bundled vs System across jdk versions and variant's and platforms:
ZLib AIX "defaults":
Hotspot:

jdk8: Bundled
jdk11: System, if not found default to Bundled. If System found does compile check.
jdk16: Bundled
jdk17: Bundled
OpenJ9:
jdk8: System, if not found default to Bundled. If System found no compile check.
jdk11: System, if not found default to Bundled. If System found does compile check.
jdk16: System, if not found default to Bundled. If System found does compile check.
jdk17: System, if not found default to Bundled. If System found does compile check.

Nodes:
test-ibm-aix71-ppc64-1 : Failure
build-osuosl-aix71-ppc64-1 : Success
build-osuosl-aix71-ppc64-2 : Success
So only test-ibm-aix71-ppc64-1 needs fixing
@aixtools

@andrew-m-leonard Hmmm it is a bit of a fudge - I wonder if we can make the build process pick it up from the expected location instead?

OpenJDK make files do not have a way of specifying zlib system location

@Haroon-Khel can we try running the latest playbooks on test-ibm-aix71-ppc64-1 ?

@Haroon-Khel can we try running the latest playbooks on test-ibm-aix71-ppc64-1 ?

Ill give it a go

@andrew-m-leonard The playbook ran fine on the machine

@Haroon-Khel thanks, looks like it didn't resolve it though. I guess we need to fix up the paths manually

Made the zlib symlink as above
lrwxrwxrwx 1 root system 28 Feb 22 08:16 /usr/include/zlib.h -> /opt/freeware/include/zlib.h
Rerunning the job
https://ci.adoptopenjdk.net/view/Failing Builds/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-aix-ppc64-openj9/919/

Job still failed
13:27:01  checking for which zlib to use... system
13:27:02  checking for system zlib functionality... configure: error: System zlib not working correctly

I just saw above that @aixtools suggests making the zconf.h link, so ive now done that.
p159a01:/ # ls -la /usr/include/zconf.h
lrwxrwxrwx 1 root system 29 Feb 22 08:43 /usr/include/zconf.h -> /opt/freeware/include/zconf.

Rerunning the jdk11 openj9 job on test-ibm-aix71-ppc64-1
https://ci.adoptopenjdk.net/view/Failing Builds/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-aix-ppc64-openj9/920/

That fixed the zlib issue
13:53:29  checking for which zlib to use... system
13:53:29  checking for system zlib functionality... ok

But now cmake isnt loading
13:56:15  Could not load program cmake:
13:56:15  Symbol resolution failed for cmake because:
13:56:15  	Symbol _ZTINSt6thread6_StateE (number 358) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZTVNSt6thread6_StateE (number 359) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt6thread4joinEv (number 379) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt18condition_variableD1Ev (number 399) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt18condition_variableC1Ev (number 400) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE (number 443) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt18condition_variable10notify_oneEv (number 444) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt18condition_variable10notify_allEv (number 445) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt6thread6_StateD2Ev (number 457) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  	Symbol _ZNSt6thread15_M_start_threadESt10unique_ptrINS_6_StateESt14default_deleteIS1_EEPFvvE (number 458) is not exported from dependent
13:56:15  	  module /opt/freeware/lib/libstdc++.a[libstdc++.so.6].
13:56:15  Examine .loader section symbols with the 'dump -Tv' command.

@Haroon-Khel I raised the cmake issue with openj9, maybe a different problem: https://github.com/eclipse/openj9/issues/12018

cmake --version appears to run ok on both of the IBM systems

While I'd be happier with somehow convincing the build system to pick it up from elsewhere I'm happy with the symlink for the two zlib headers being put in place via the playbooks

p159a01:/ # ldd `which cmake`
/opt/freeware/bin/cmake needs:
         /usr/lib/libc.a(shr_64.o)
         /usr/lib/libpthreads.a(shr_xpg5_64.o)
         /opt/freeware/lib/pthread/ppc64/libstdc++.a(libstdc++.so.6)

Ive temporarily made /opt/freeware/lib/libstdc++.a to point to /opt/freeware/lib/pthread/ppc64/libstdc++.a to see if this fixes the problem (and to see what else breaks!)
Rerunning at https://ci.adoptopenjdk.net/view/Failing Builds/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-aix-ppc64-openj9/921/console

While I'd be happier with somehow convincing the build system to pick it up from elsewhere I'm happy with the symlink for the two zlib headers being put in place via the playbooks

Can this issue be closed since https://github.com/AdoptOpenJDK/openjdk-build/pull/2489 was merged? Or do we want to keep this open to investigate into how to make the build scripts look for zlib in the appropriate place?

This issue again: https://ci.adoptopenjdk.net/view/Failing Builds/job/build-scripts/job/jobs/job/jdk16u/job/jdk16u-aix-ppc64-openj9/4/console
23:35:55  checking for which zlib to use... system
23:35:55  checking for system zlib functionality... not ok
23:35:55  configure: error: System zlib not working correctly
23:35:55  configure exiting with result code 1

Node: test-ibm-aix71-ppc64-2

Looking...

The links
/usr/include/zlib.h
/usr/include/zconf.h
are not setup on the machine. Im fixing that now

Also cmake is v3.16.0 and not 3.14.3

Was just going to mention the links are missing - but @Haroon-Khel beats me to it!
ibm...2:
p159a02:/ # find /opt /usr -name zlib.h -ls
26370   94 -rw-r--r--  1 root      system       96239 Dec 17 10:29 /opt/freeware/include/zlib.h
p159a02:/ # find /opt /usr -name zconf.h -ls
26395   16 -rw-r--r--  1 root      system       16262 Dec 17 10:29 /opt/freeware/include/zconf.h

WIth the links now in place, ive kicked off a jdk 16 openj9 build on the machine
https://ci.adoptopenjdk.net/view/Failing Builds/job/build-scripts/job/jobs/job/jdk16u/job/jdk16u-aix-ppc64-openj9/5/console

The job hit an expected cmake error. Ive downgraded cmake on the machine to 3.14.3. Rerunning the build job
https://ci.adoptopenjdk.net/view/Failing Builds/job/build-scripts/job/jobs/job/jdk16u/job/jdk16u-aix-ppc64-openj9/6/console

The job passed. Hopefully this shouldnt be a problem on this machine anymore

Looks like we need to rinse and repeat the current status of the playbooks on our 'ansible-test' node (ojdk06) using different OS levels - and when happy with that - make a backup of ojdk01 (e.g., clone) and run the playbooks on that node - and see if it cleans, or makes a mess.
My simple soul says it should be safe to reapply the playbooks at anytime. But simple souls sometimes face surprises! :wink:

@Haroon-Khel If this is resolved can you self-assign and close please

Closing


Update deploy.yml

Sorry, accidental PR to upstream! Trying to fix an issue with deployment.
mkdir: cannot create directory ‘/usr/local/tmp’: Permission denied


Custom Step No Longer Working After Switch to .json

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
- Continue: 0.7.4 Pre-Release  2023-11-16T20:39:15.993Z

Description
After updating to the latest version and transitioning to .json, my custom slash command (/commit) has stopped functioning. The error log indicates that CommitMessageStep is not recognized as a valid subclass of Step and it's not included in the list of permitted steps.
I also tested tit with the exact same code as outlined in the documentation slash-commands.md#custom-slash-commands. This was functioning properly prior to the update.
I'm aware that the switch to .json is still a work in progress, and this issue might already be known internally. However, I wanted to properly report it to ensure it won't be forgotten.
To reproduce

Write a custom step in your ~/.continue/config.py, e.g. CommitMessageStep

"""
Continue Code Configuration
"""

import subprocess
from continuedev.core.config import SlashCommand, ContinueConfig
from continuedev.core.main import ContinueCustomException, SetStep, Step
from continuedev.core.sdk import ContinueSDK

class CommitMessageStep(Step):
    async def run(self, sdk: ContinueSDK):
        # Get the root directory of the workspace
        dir = sdk.ide.workspace_directory

        # Run git diff in that directory
        diff = subprocess.check_output(
            ["git", "diff", "--staged"], cwd=dir).decode("utf-8")

        # Only run the command if diff is not empty
        if diff.strip():
            resp = await sdk.models.default.complete(
                f"{diff}\n\nPlease write a concise, specific commit message (less than 50 characters) about the changes above, following the Conventional Commits syntax in the format '<scope>: <message>'. Always include a scope. If the file changes consist only of markdown files, use 'docs' as the scope. If it's unclear, use 'chore' as the scope.")
            resp = resp.replace('\"', '').replace('\'', '').replace('`', '')
            await sdk.ide.runCommand(rf"git commit --message '{resp}'")
        else:
            raise ContinueCustomException(
                title="nothing to commit",
                message="If you want to commit, you need to add the changes to the staging area."
            )

def modify_config(config: ContinueConfig) -> ContinueConfig:
    config.slash_commands.append(
        SlashCommand(
            name="commit",
            description="Generate a commit message for the current changes",
            step=CommitMessageStep,
        )
    )
    return config

Open VSCode and View Continue Server Logs
Notice the error in the log messages

Log output
[2023-11-17 00:50:26] [WARNING] Failed to modify config: 2 validation errors for SlashCommand
step
  subclass of Step expected (type=type_error.subclass; expected_class=Step)
step
  unexpected value; permitted: 'AnswerQuestionChroma', 'GenerateShellCommandStep', 'EditHighlightedCodeStep', 'ShareSessionStep', 'CommentCodeStep', 'ClearHistoryStep', 'StackOverflowStep', 'OpenConfigStep' (type=value_error.const; given=CommitMessageStep; permitted=('AnswerQuestionChroma', 'GenerateShellCommandStep', 'EditHighlightedCodeStep', 'ShareSessionStep', 'CommentCodeStep', 'ClearHistoryStep', 'StackOverflowStep', 'OpenConfigStep'))
[2023-11-17 00:50:26] [DEBUG] ------ Begin Logs ------
[2023-11-17 00:50:27] [INFO] Meilisearch started at http://localhost:7700
[2023-11-17 00:50:28] [WARNING] Failed to modify config: 2 validation errors for SlashCommand
step
  subclass of Step expected (type=type_error.subclass; expected_class=Step)
step
  unexpected value; permitted: 'AnswerQuestionChroma', 'GenerateShellCommandStep', 'EditHighlightedCodeStep', 'ShareSessionStep', 'CommentCodeStep', 'ClearHistoryStep', 'StackOverflowStep', 'OpenConfigStep' (type=value_error.const; given=CommitMessageStep; permitted=('AnswerQuestionChroma', 'GenerateShellCommandStep', 'EditHighlightedCodeStep', 'ShareSessionStep', 'CommentCodeStep', 'ClearHistoryStep', 'StackOverflowStep', 'OpenConfigStep'))
[2023-11-17 00:50:29] [INFO] There are 1 sessions currently open

Thank you for sharing this! Will be solving in the next pre-release. (via Union[StepName, str] instead of just StepName in pydantic model)
Aiming to fix all migration errors before moving .json changes to main, so keep the feedback coming if you find new things!

@LangLangBart thanks for the report. Keep feedback coming! I'll have this solved in the next version, but want to be sure we get things right before making this migration available in the main version of the extension

The specific issue outlined here appears to have been resolved in 0.7.5 Pre-Release   2023-11-19T19:50:48.103Z ✹ 19/Nov/23

The custom slash command now appears in the GUI dropdown.

The issue was addressed with commit: c1c289fc.

git log --oneline --since=2023-11-16T20:39:15.993Z --until=2023-11-19T19:50:48.103Z -L :'class SlashCommand(BaseModel)':server/continuedev/core/config.py

--- a/server/continuedev/core/config.py
+++ b/server/continuedev/core/config.py
@@ -41,23 +41,23 @@
 class SlashCommand(BaseModel):
     name: str
     description: str
-    step: Union[Type[Step], StepName]
+    step: Union[Type[Step], StepName, str]
     params: Optional[Dict] = {}

     # Allow step class for the migration
     @validator("step", pre=True, always=True)
     def step_is_string(cls, v):
         if isinstance(v, str):
             return v
         elif isinstance(v, object) and v.__class__.__name__ == "ModelMetaclass":
             return str(v).split(".")[-1].split("'")[0]
         else:
             return v

     def slash_command_description(self) -> SlashCommandDescription:
         return SlashCommandDescription(
             name=self.name,
             description=self.description,
         )

[!WARNING]
However, when the custom slash command is executed, it does not perform the
programmed steps defined in my ~/.continue/config.py. Instead, it simply takes the entire slash
command literally and does not resolve it to its defined function. Would you like me to start a
new bug report, or should we keep this one open, @sestinj?

@LangLangBart I found the issue and tested with your exact config.py to make sure it works. Already published in v0.7.22 and on the way for v0.6.8

Everything is now working correctly. Commit f1acf952 must have contained the necessary fixes.


Proposal: fetch elements within shadow root with shadow$ and shadow$$

There are various issues on missing support for fetching elements within the shadow DOM of elements. Some related issues are:

https://github.com/puppeteer/puppeteer/issues/6217
https://github.com/puppeteer/puppeteer/issues/5405
https://github.com/puppeteer/puppeteer/issues/4171

Also for Puppeteer embedder projects like WebdriverIO:

https://github.com/webdriverio/webdriverio/issues/4484

This PR proposes shadow$ and shadow$$ to allow query an element through element shadow roots. Given the following DOM structure:

    #shadow-root
    <customA></customA>
    <customA>
      #shadow-root
      <subCustomB>
        #shadow-root

      </subCustomB>
    </customA>

Given someone would fetch the root of an shadow element:
const elem = await page.$('#elem')

The following queries would give following results:

elem.shadow$(['customA', 'subCustomB', '.container'])

would return null because we would always pick the first element being found

const customAs = await elem.shadow$$(['customA'])
return customAs[1].shadow$(['subCustomB', '.container'])

would return div.container

One idea could be to always use Element.querySelectorAll and iterate through all nodes. This could be potentially a very expensive operation though and would only make sense for shadow$$.
WDYAT?

👍 I think this is a great step for testing web components. Always picking the first instance found is fine here I think.
One concern I have with this is that it makes tests very brittle, and tightly coupled to private APIs of web components. In traditional webpages, people are used to being able to select elements by just using some landmarks such as ids, element names or data attributes. With shadow dom this used by possible with the /deep/ selector but this was removed from the spec.
I think something like this is necessary to have, but it doesn't fully address all the use cases. So I wouldn't close all the related issues. There should also be a way to query elements deeply, such as implemented by libraries like https://github.com/Georgegriff/query-selector-shadow-dom

Pinging @mathiasbynens @johanbay @paullewis on this as they've worked on the query handler parts more than me 👍

Thanks for kicking off this discussion, @christian-bromann! As a general note, building on top of the existing custom query handler infrastructure makes a lot of sense 👍
This PR lets you select across a single shadow root by explicitly referencing it. That's indeed better than anything we support out of the box right now.
But, I think where we want to go eventually is a little different: as a user, I want to either select using the default magic (querySelector{All}), or select across all shadow roots (without having to reference any of them in particular). This patch only lets me pierce a single shadow root, by explicitly referencing it.
WDYT?

What can we do to move forward with this?

@LarsDenBakker I haven't been able to follow up on this but will take some time this week to address @mathiasbynens comment.

@mathiasbynens is this PR still useful? Or is the work than @johanbay has been doing now going to enable this more easily?

With the changes to the query handler infrastructure, we can do something like this https://github.com/puppeteer/puppeteer/pull/6509 to support querying elements inside shadow roots.
So in the examples above one would do page.$('pierce/.container').
Does that work for you @LarsDenBakker and @christian-bromann?

Yep that works for me.

Sounds good to me too? Shall we close this PR then?

Yes it sounds like we can close this one and merge https://github.com/puppeteer/puppeteer/pull/6509. Thanks!


Cannot open a zip file directly into Files V2 without extracting it.

Description
This is what happens:

Steps To Reproduce
Set Files V2 as Default Explorer
Open any .zip file
Choose Files V2 as Always
You will get the error.
Expected behavior
This should open in Files correctly.
Files Version
<IP_ADDRESS>
Windows Version
Windows 11 22H2 22621.232
Relevant Assets/Logs
None

Merging with #7680


Sachin  add privkey module

add private key module in secp256k1
add basic testing for private key.
fix typo in math.ex

TODO

add signature serialization
add more testing for private key and signing

I'm not familiar with testing practices, so I've only added a few tests for each function. More thorough test cases are required.

I'm not familiar with testing practices, so I've only added a few tests for each function. More thorough test cases are required.


iceoryx does not set the SOVERSION

Required information
Operating system:
POSIX
Compiler version:
all
Observed result or behaviour:
A library build with iceoryx 1.0 could dynamically link to iceoryx 2.0 shared libs
Expected result or behaviour:
Linking should not be possible
Further information*
objdump -p build/iceoryx_examples/icedelivery/iox-cpp-publisher

produces the following output
...
Dynamic Section:
  NEEDED               libiceoryx_posh.so
  NEEDED               libiceoryx_hoofs.so
  NEEDED               libiceoryx_platform.so
  NEEDED               librt.so.1
  NEEDED               libpthread.so.0
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
...

It should actually be libiceoryx_posh.so.2, etc.
To fix this, the cmake targets needs to set VERSION and SOVERSION. It is not sufficient to set the version at the project scope.
This can be done by this call, which creates a libiceoryx_posh.so.2.0.0 and a libiceoryx_posh.so.2 symlink.
set_target_properties(iceoryx_posh PROPERTIES
    VERSION ${PROJECT_VERSION}
    SOVERSION ${PROJECT_VERSION_MAJOR}
)

The binary then links to a specific version.
...
Dynamic Section:
  NEEDED               libiceoryx_posh.so.2
  NEEDED               libiceoryx_hoofs.so
  NEEDED               libiceoryx_platform.so
  NEEDED               librt.so.1
  NEEDED               libpthread.so.0
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
...

@dkroenke this might also be interesting for you


GG: /.. reported as invalid IRI

Requesting the address gemini://localhost/../ returns the error gg: invalid IRI: illegal path, even though it should be a valid IRI
gemini://localhost/./...../ (arbitrarily many . at the end) works, and will return the index of localhost, if requested on a gmid server

good catch, I haven't thought about that case.
gg uses the same IRI code that gmid use, and so it performs some cleanups that are needed server-side but not on the client.
I had in mind to improve the IRI handling and separate the parsing and cleanup phases, now I have a strong reason to do that :)

If you don't mind, I'd keep this open.  While it's not a top-priority, I still like to to eventually fix it ^^"

No problem! just went through my old stuff and removed the inactive-seeming ones

Took a while to fix this, oops :)
When I wrote the parser I was a bit paranoic and decided to reject altogether paths that tried to "escape" the root.  However, RFC 3986 § 5.2.4 in the algorithm "remove_dot_segments" explicitly allows for it.


Cumulative case numbers GE compromised

Update COVID19-Fallzahlen_Kanton_GE_total.csv by simgraworldwide-patch-2 on May 15, 16:49 removed all cumulative test numbers from the dataset for canton Geneve from April 1st onwards and replaced them by wrong numbers that add only the number of confirmed positive tests per day.

Thanks @gjeschke, while GE yesterday changed the format of its data publication retrospectively starting from April 1st onwards, we have unfortunately slipped one column in our latest update. We will correct it immediately and report as soon as it is done.

Resolved: https://github.com/openZH/covid_19/pull/736#issue-418950055


Allow publishing Original Version of a versioned API

In Azure Portal, you can remove the version for the API, which defaults the backend management API call to pass an empty string for the version  value.  This results in the portal displaying "original version", and a version is not required to be specified.  This PR is to mimic that functionality (in v3, and v4), as a version is not required to be specified by APIM.

@stephaneey Any thoughts on this PR?

Hello @calebsmith411 ,
If you don't want to use a versioned API, just use the ad-hoc task "Create or Update API".

Hello @calebsmith411 ,
If you don't want to use a versioned API, just use the ad-hoc task "Create or Update API".

Hi @stephaneey
I do want to use versions, but I want the first version to be "Original Version" and not /v1.  Which is do-able from the api portal itself.

Hello,
Thanks for your contribution. I have merged the PR.
Best Regards

Is this feature in production?
@stephaneey @calebsmith411


on-search-change not working ?

Hello,
I have the following multi select definition :
<div
                        isteven-multi-select
                        input-model="input"
                        output-model="output"
                        button-label="name"
                        item-label="name"
                        tick-property="ticked"
                        helper-elements="filter"
                        orientation="vertical"
                        translation="translateMultiselect"
                        tabindex="1"
                        selection-mode="single"
                        on-search-change="filterSearch(data)"
                    >
                    </div>

My controller method looks like:
 $scope.filterSearch = function (query) {
        console.log(query.keyword);
  };

But in console nothing is logged ... what have I done wrong ?
I have recognized an error in the console:
TypeError: Cannot read property 'getElementsByTagName' of undefined at h.link.$scope.getFormElements (isteven-multi-select.js:235)
Maybe that is the reason ?
Thanks in advance

Hi @oliver13 ,
Yeah it's a problem I'm trying to fix. Related with issue #201.


[#1056] Expose the type descriptions at .typesDescriptions

I also did some small refactorings.
openspending/openspending#1056

Coverage increased (+0.02%) to 97.154% when pulling 3dbfc7e157140515a588c8b0a67cdf946dd26123 on feature/1056-implement-design-datatype-picker into ef2151f8f01706aa6e7fd4118c2e91fd516840bc on master.

Coverage increased (+0.02%) to 97.154% when pulling 3dbfc7e157140515a588c8b0a67cdf946dd26123 on feature/1056-implement-design-datatype-picker into ef2151f8f01706aa6e7fd4118c2e91fd516840bc on master.


Error in configuration example when run from a clean devcontainer

Expected Behavior
Followed steps here:
https://github.com/dapr/python-sdk#developing
Except that after step 1 I used code . to open the checkout in VSCode and then when prompted, opened in a devcontainer before proceeding to step 2.
When I ran step 7, tox -e examples, I expected a clean example to pass as did all the prior steps.
Actual Behavior
Instead I see the following error:
examples run-test: commands[0] | ./validate.sh configuration
Home: /root
Running shell 'bash -c' with command: `docker exec dapr_redis redis-cli SET orderId "100||1"
docker exec dapr_redis redis-cli SET orderId1 "200||2"`
Running shell 'bash -c' with command: `dapr run --app-id configexample --components-path components/ -- python3 configuration.py`
Running shell 'bash -c' with command: `docker exec dapr_redis redis-cli SET orderId "200||2"`
Step: Set configuration value
        command: `docker exec dapr_redis redis-cli SET orderId "100||1"
docker exec dapr_redis redis-cli SET orderId1 "200||2"`
        return_code: 0
        duration_seconds: 0.311
        Expected stdout (output_match_mode: exact):
                OK
        Actual stdout:
                OK
                OK

        Expected stderr (output_match_mode: exact):
        Actual stderr:

Step: Run get configuration example
        command: `dapr run --app-id configexample --components-path components/ -- python3 configuration.py`
        return_code: 1
        duration_seconds: 0.0344
        command: `docker exec dapr_redis redis-cli SET orderId "200||2"`
        return_code: 0
        duration_seconds: 0.145
        Expected stdout (output_match_mode: exact):
                == APP == Got key=orderId value=100 version=1 metadata={}
                == APP == Got key=orderId1 value=200 version=2 metadata={}
                == APP == Subscribe key=orderId value=200 version=2 metadata={}
                == APP == Unsubscribed successfully? True
                == APP == configurationstore configuration watcher for keys ['orderId', 'orderId1'] stopped.
        Actual stdout:
                ℹ  Starting Dapr with id configexample.  True
                == APP == configurationstore configuration watcher for keys ['orderId', 'orderId1'] stopped.
        Expected stderr (output_match_mode: exact):
        Actual stderr:
                ❌  fork/exec /root/.dapr/bin/daprd: no such file or directory

External link validation:
        https://docs.dapr.io/getting-started Status: 200
        https://www.python.org/downloads/ Status: 200

ERROR: InvocationError for command /workspaces/dapr-python-sdk/examples/validate.sh configuration (exited with code 1)
____________________________________________________________ summary _____________________________________________________________
ERROR:   examples: commands failed

Steps to Reproduce the Problem
Followed steps here for developing:
https://github.com/dapr/python-sdk#developing
Except that after step 1 use code . to open the checkout in VSCode. When prompted, opened in a devcontainer before proceeding to step 2.
Release Note

RELEASE NOTE: FIX Error in configuration example when run from a clean devcontainer.

@bbrandt working as intended.
You first need to run dapr init, then try again. We intentionally don't ship Dapr installed (just the CLI itself) so that we don't provide outdated Dapr versions.


Multi-project configuration

I develop embedded software for Zephyr RTOS as well.  The compile_commands.json works great for the project directory.  However, it doesn't work so well for the underlying RTOS directory.  I get errors such as:
"i2c_sam0.c" not found in "/Users/.../build/compile_commands.json". 'includePath' from c_cpp_properties.json will be used for this file instead.

This particular file (i2c_sam0.c) is a Zephyr driver and not part of the application.  When working with your application, it is often helpful to view the drivers used by the application (and other components of the RTOS such as kernel, sub systems, etc) and to have intellisense properly parse these files when you open them.  Moreover, I debug these drivers and it is essential to be able to properly parse them.
Originally posted by @sslupsky in https://github.com/microsoft/vscode-cmake-tools/issues/915#issuecomment-599125576

How is your workspace set up in vscode?  Are there two folders with code in them?  (e.g. one for the drive and one for the application).  I'm wondering if using VS Code's multiple folder support + configuring with cpptools' Configuration Provider API will work better than compile_commands.json for you.

I do have VSCode setup with multiple folders using my own workspace.  I added my application folder and the Zephyr folder to the workspace.
One folder contains the Zephyr source from here:
https://github.com/zephyrproject-rtos/zephyr
And the other is the application project folder that contains the source for the application.  For example, the blinky sample copied to a separate folder from here:
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/basic/blinky
The way Zephyr works is the kernel is compiled and linked with the application into one binary.  This helps to eliminate redundant and unused code that would be an issue for constrained devices.  The Zephyr project uses West to generate a number of intermediate files that are used to build the binary including kernel configuration options and device tree options.  The generated files are contained in the application build folder.
I stumbled across the "Configuration Provider API" yesterday with respect to the CMake Tools extension.  That did not seem to make a difference for me yet as I could not figure out a way to tell CMake Tools about multiple directories.  Though, as mentioned above, my workspace does include both folders.
If I inform CMake to export the compile commands by adding the following line to the CMakeLists.txt at the root of the application folder:
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

CMake exports the compile commands for the application targets but does not include the Zephyr library targets.  The Zephyr library targets (driver libs, kernel lib, sub system libs, etc) are not included in the compile commands.
Earlier today I determined a way to inform the Zephyr build process to export the additional compile commands by manually editing the CMakeList.txt files in each of the sub folders that contain the code that is compiled to the Zephyr libs.  For my build environment these folders include:
arch/arm
boards
drivers
kernel
soc
subsys
When I inspected the compile_commands.json after these changes, there was additional build information for the components compiled into the Zephyr libs.
This configuration works better and generally I do not have squiggles with my includes that are part of the compile commands.  However, there still appears to be a problem.
Here is a copy of my compile_commands.json:
(This isn't the entire file, just a snippet from the beginning.)
[
{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/fs/littlefs -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o CMakeFiles/app.dir/src/main.c.obj   -c /Users/stevenslupsky/Documents/source/blinky/src/main.c",
  "file": "/Users/stevenslupsky/Documents/source/blinky/src/main.c"
},

{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/fs/littlefs -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o CMakeFiles/app.dir/src/led.c.obj   -c /Users/stevenslupsky/Documents/source/blinky/src/led.c",
  "file": "/Users/stevenslupsky/Documents/source/blinky/src/led.c"
},

{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/kernel/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/arm/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o zephyr/arch/common/CMakeFiles/arch__common.dir/isr_tables.c.obj   -c /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/isr_tables.c",
  "file": "/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/isr_tables.c"
},

{
  "directory": "/Users/stevenslupsky/Documents/source/blinky/build",
  "command": "/usr/local/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.1.0-rc1-182-gb54ee41160d6 -DKERNEL -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/kernel/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/arm/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/drivers -Izephyr/include/generated -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/drivers -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/soc/arm/atmel_sam0/common/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/lib/fnmatch/. -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/ext/hal/cmsis/Core/Include -I/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/subsys/usb -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/hal/atmel/asf/sam0/include/samd21 -I/Users/stevenslupsky/Documents/source/zephyrproject/modules/debug/segger/rtt -isystem /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/lib/libc/minimal/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include -isystem /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/8.2.1/include-fixed    -Og -imacros/Users/stevenslupsky/Documents/source/blinky/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mthumb -mcpu=cortex-m0plus -imacros/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/blinky=CMAKE_SOURCE_DIR -fmacro-prefix-map=/Users/stevenslupsky/Documents/source/zephyrproject/zephyr=ZEPHYR_BASE -ffunction-sections -fdata-sections -mabi=aapcs -march=armv6s-m -std=c99 -nostdinc -o zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj   -c /Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/sw_isr_common.c",
  "file": "/Users/stevenslupsky/Documents/source/zephyrproject/zephyr/arch/common/sw_isr_common.c"
},

For some reason I am getting multiple file matches for some of the Zephyr includes.  For instance, <soc.h>.  That is, if I #include <soc.h> in my main.c (or in one of the Zephyr source files) and then right click and select 'Go To Definition', I will get a list of 76 soc.h files.  When this happens it quite often causes undesirable issues with the linting (reports errors incorrectly) because it more often than not picks the wrong file.
So for some reason the compile commands are not sufficient to resolve the path to the correct version of soc.h and I have not been able to determine why.  Other includes are affected as well (for example errno.h, device.h, init.h) though not the degree that soc.h is.

Sorry for the delay on this.  I ran into some problems trying to get the workspace configured (Zephyr's walkthrough didn't work for me), and I haven't had time to dig in deep and troubleshoot it yet.

Np, it took me a little time to get Zephyr up and running.  I am not sure I fully understand it yet but I am learning.
I did a little more digging but haven't been able to figure out what the problem is.  I did not have this problem when I was using manually specified the includes, forced includes and defines in c_cpp_properties.json.

When I manually include the CMAKE_EXPORT_COMPILE_COMMANDS in the CMakeLists.txt files in the Zephyr tree as mentioned above, most of them appear in the compile_commands.json file.  However, there are still a few that are not being included.
For instance, I compile for the samd21 mcu and configure to use the rtc as the timer and the watchdog.  For some reason, the targets for these (sam0_rtc_timer.c and wdt_sam0.c) do not appear in the compile_commands.json file.  So, there are a small number of Zephyr files that have intellisense errors.  This is a CMake issue though and I've posted an issue on the Zephyr GitHub page to try to resolve how to propagate the setting properly to the entire build.
I still have not determined the cause of the multiple file matches described earlier, so that is still outstanding.

My problem is that I was unable to get CMake to successfully configure the sample project yet.  This is the error I get with blinky.  Maybe you can help.  I set some variables in cmake.environment to get some stuff to work ($ZEPHYR_BASE, $BOARD, etc), but I don't know what a dtc is or how to update it.
-- Application: /home/bob/git/zephyr/samples/basic/blinky
[cmake] -- Zephyr version: 2.2.99
[cmake] -- Board: stm32f0_disco
[cmake] CMake Error at /home/bob/git/zephyr/cmake/extensions.cmake:1457 (message):
[cmake]   Assertion failed: The detected dtc version is unsupported.
[cmake]
[cmake]       The version was found to be 1.4.5
[cmake]       But the minimum supported version is 1.4.6
[cmake]       See https://docs.zephyrproject.org/latest/getting_started/
[cmake]       for how to use the SDK's dtc alongside a custom toolchain.
[cmake] Call Stack (most recent call first):
[cmake]   /home/bob/git/zephyr/cmake/host-tools.cmake:69 (assert)
[cmake]   /home/bob/git/zephyr/cmake/app/boilerplate.cmake:445 (include)
[cmake]   CMakeLists.txt:4 (include)
[cmake]

I round this discussion that might help resolve the dec version issue:
https://github.com/zephyrproject-rtos/zephyr/issues/17543
From the discuss there I think you might need to verify that the ZEPHYR_SDK_INSTALL_DIR environment variable is properly set.  Also, delete the build directory so that anything cached from a previous build with the incorrect sdk path is deleted.
I can confirm that setting the CMAKE_EXPORT_COMPILE_COMMANDS from the command line works better than using the setting in the CMakeLists.txt file(s).  Now all the zephyr components are included in the compile_commands.json file.  I did so by adding a define to the west build command:
west build -b <board> <app directory> -- -DCMAKE_EXPORT_COMPILE_COMMANDS=1

I believe I have made progress on this issue.  I believe intellisense is falling back to a default configuration.  I am using a multi root workspace.  It appears that the c_cpp_properties for each folder in the multi root workspace must be configured individually.  The configuration selected for the zephyr tree folder specified a compile_commands.json file instead of the configurationProvider.  For some reason, I was not getting an error message about a missing file.  I switched the configuration to use the CMake-Tools configurationProvider.  Now, intellisense linting is working.
I am uncertain if the problem was resolved because I specified the CMAKE_EXPORT_COMPILE_COMMANDS build option on the command line or if it was because of a typo the in the compile_commands.json line of the selected configuration.
After fixing the problem with the CMAKE_EXPORT_COMPILE_COMMANDS and restarting VSCode, an error message came up indicating a missing compile_commands.json file which prompted me to switch the configuration.
Note that "Go to Definition" for soc.h still shows 76 definitions.  So the include resolution still appears to not work correctly.  However, the linting appears to be ok now as I have no errors reported and all the Zephyr defines in my sam0_rtc_timer.c file appear to be resolved.
I have simplified my c_cpp_properties files for the app project and the zephyr folders as follows:
{
	"configurations": [
		{
			"name": "Mac",
			"includePath": [],
			"forcedInclude": [],
			"defines": [],
			"compilerPath": "/usr/local/bin/arm-none-eabi-gcc",
			"cStandard": "c11",
			"cppStandard": "c++17",
			"intelliSenseMode": "gcc-x64"
		},
		{
			"name": "CMake-Tools",
			"configurationProvider": "vector-of-bool.cmake-tools",
			"forcedInclude": [
				"${workspaceFolder}/.vscode/c_cpp_undef.h"
			]
		}
	],
	"version": 4
}

One observation is that the error message that indicates an error with the configuration would benefit with additional information about what exactly it is referring to.  Here is a screen shot:

What is not clear is which configuration it is referring to.  Does the message refer to the configuration in the .code-workspace file or one of the configurations in the c_cpp_properties.json file?
I copied a project directory and renamed it.  I have opened the copy and I get the message in the screen shot above.  I'm trying to run down where the problem is and it is not obvious.

Mysteriously the copied project is linting now.  I do not know why.  I reloaded the window a couple times and now the configurationProvider is working.

I vaguely recall reading something a while ago about the CMake-Tools extension and the configurationProvider ... that sometimes there can take a while before CMake-Tools informs c_cpp that it is providing a configuration.  I do not recall exactly where I saw it though.  I believe it was in the CMake-Tools issues.
... ahh, I found it here:
https://github.com/microsoft/vscode-cmake-tools/issues/928#issuecomment-555643669
What did you mean by "sometimes this takes a while"?

I mean that the "Configure" step can take a while depending on the project.  And CMake Tools doesn't register itself as a provider until a successful configure happens.  There is a setting to tell CMake Tools to immediately configure when the extension activates.  I recommend setting it if you use the configuration provider.
"cmake.configureOnOpen": true,

Ok, thanks.  I will set that.  Just to confirm, this setting goes into the settings section of the .code-workspace file?

Yes, or put it in the "User" settings so that it applies to all of your projects.

I think I have a better understanding of what is going on.
Resolving the location of a header file can result in multiple paths. I have noticed this happens when there are headers that have no corresponding ".c" target in compile_commands.json. For instance, #include <kernel.h> in main.c.
I think perhaps the c/cpp extension appears to be attempting to find a "kernel.c" target. Since "kernel.c" is not a target in compile_commands.json, the c/cpp extension defaults to another search process (default include paths) and comes up with multiple paths.
It seems to me that c/cpp should have used the "main.c" target in compile_commands.json?

I do not think the configurationProvider setting is working.  I simplified my .code-workspace multi root workspace file and stripped out the default includes, forced includes and defines.
Here is what it looks like:
{
	"folders": [
		{
			"path": "dock1500",
			"name": "app"
		},
		{
			"path": "zephyrproject/zephyr/boards/arm/scanimetrics_witap_isb",
			"name": "board"
		},
		{
			"path": "zephyrproject/zephyr",
			"name": "zephyr"
		},
		{
			"path": "zephyrproject/modules",
			"name": "modules"
		}
	],
	"settings": {
		"C_Cpp.default.compilerPath": "/usr/local/bin/arm-none-eabi-gcc",
		"C_Cpp.default.cStandard": "c11",
		"C_Cpp.default.cppStandard": "c++17",
		"C_Cpp.default.intelliSenseMode": "gcc-x64",
		"files.associations": {
			"zephyr.h": "c",
			"kernel.h": "c",
			"kernel_includes.h": "c",
			"log.h": "c",
			"printk.h": "c",
			"littlefs.h": "c",
			"i2c.h": "c",
			"usb_device.h": "c",
			"soc.h": "c",
			"samd21g18a.h": "c",
			"power.h": "c",
			"watchdog.h": "c",
			"i2c_ll_stm32.h": "c",
			"init.h": "c",
			"device.h": "c",
			"cpu.h": "c",
			"generated_dts_board.h": "c",
			"system_timer.h": "c",
			"clock_control.h": "c",
			"sys_clock.h": "c",
			"dma.h": "c",
			"hwinfo.h": "c",
			"gpio.h": "c",
			"errno.h": "c",
			"stdio.h": "c",
			"version.h": "c",
			"spi.h": "c",
			"*.overlay": "dts",
			"sam0_eic.h": "c",
			"gpio_utils.h": "c",
			"led.h": "c"
		},
		"terminal.integrated.env.osx": {
			"ZEPHYR_BASE": "${workspaceFolder:zephyr}",
			"ZEPHYR_TOOLCHAIN_VARIANT": "gnuarmemb",
			"GNUARMEMB_TOOLCHAIN_PATH": "/usr/local/",
			"PATH": "$ZEPHYR_BASE/scripts:${env:PATH}"
		},
		"cmake.configureOnOpen": true,
		"editor.tabSize": 8,
		"editor.insertSpaces": false
	}
}

Here is the c/cpp log diagnostics output:
-------- Diagnostics - 3/22/2020, 2:58:52 PM
Version: 0.27.0-insiders3
Current Configuration:
{
    "name": "CMake-Tools",
    "configurationProvider": "vector-of-bool.cmake-tools",
    "compilerPath": "/usr/local/bin/arm-none-eabi-gcc",
    "cStandard": "c11",
    "cppStandard": "c++17",
    "intelliSenseMode": "gcc-x64",
    "compilerArgs": [],
    "browse": {
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ /Users/stevenslupsky/Documents/source/dock1500/src/main.c ]:
    /Users/stevenslupsky/Documents/source/dock1500/src/main.c
Translation Unit Configurations:
[ /Users/stevenslupsky/Documents/source/dock1500/src/main.c ]:
    Process ID: 16822
    Memory Usage: 14 MB
    Compiler Path: /usr/local/bin/arm-none-eabi-gcc
    Includes:
        /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/lib/gcc/arm-none-eabi/8.2.1/include
        /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/lib/gcc/arm-none-eabi/8.2.1/include-fixed
        /usr/local/Cellar/arm-none-eabi-gcc/8-2018-q4-major/gcc/arm-none-eabi/include
    Standard Version: c11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=80201
Total Memory Usage: 14 MB

As you can see, there are no include paths provided to the translation units by the CMake-Tools extension.
So, I think the earlier work I did was picking up a compile_commands.json file because there was a default setting in the .code-workspace file.  I incorrectly assumed that default setting was being ignored and the configurationProvider setting was providing the relevant information.
My understanding is that the configurationProvider setting enables CMake-Tools to provide the include paths, defines, and other compiler information to the c/cpp extension?  So, shouldn't that information appear in the output of the c/cpp Log Diagnostics?

I posted a comment here https://github.com/microsoft/vscode-cpptools/issues/5160#issuecomment-602279281
It appears like I am almost there.  I think only the Go to Definition on #includes is not working as described here https://github.com/microsoft/vscode-cpptools/issues/2564.
I still do not understand why the configurationProvider setting is not working but the default compile_commands.json setting in the .code-workspace file configures the workspace properly.
Thanks for the pointers.  My configuration is not perfect but I have made some improvement.

@sslupsky, regarding the CMake Tools extension, is there anything else that is not working properly and you'd like us to investigate? If not, we would like to close this issue.

@andreeis I believe the outstanding issue is that the CMake Tools extension is not providing the configuration.  Or, it is and c-cpp is ignoring it.  I do not know how to tell which.
The only way I could get my configurations to work was to set the default "compile_commands.json" property in my multi root .code-workspace file.

@andreeis @bobbrow The other thing that comes to mind is to check with Bob regarding the zephyr integration.  It is a rather complicated CMake setup.  The zephyr team created a meta tool called "west" written in python that provides a user friendly build command.  I am not sure if CMake Tools is or can be made compatible with this workflow.  It would be great if it could.  I think Bob was looking a bit more into zephyr but had some problems with the install.  I am not clear if he resolved those issue or not.


Provide a security.txt

I propose implementing RFC 9116 and providing a security.txt. We would add one file per Opencast install. We could have a look at how Moodle does it. They point to a central security.txt on their servers. See https://tuwel.tuwien.ac.at/security.txt for example.
It would need a regular update with every release to set a new Expires date.
# Moodle HQ security submission form
Contact: https://moodle.org/security/report/

# Moodle LMS security publications and acknowledgements page
Acknowledgments: https://moodle.org/security/

# Submission preferred languages
Preferred-Languages: en

# Moodle HQ canonical security.txt file
Canonical: https://moodle.org/.well-known/security.txt

# Moodle LMS Security Procedures document, including Responsible Disclosure Policy
Policy: https://moodledev.io/general/development/process/security

# Expiry date of this document
# This information is considered current and up to date until 3 weeks after the next major Moodle LMS release
Expires: 2025-05-05T01:00:00.000Z

Wait so the idea is to have one security.txt that is the same for every Opencast instance? Why? The Opencast project does solve issues in the Opencast code base but we don't fix issues with specific instances. So I would expect to have instance-specific security.txt responses.

Yep, not sure I'm understanding here.  So this would be like the Terms of Use thing for the admin UI where the adopter needs to set this file up and remember to keep it updated?

We could provide a default security.txt file, which we update with every release. This can be automated and templated in GH actions. We can set the expiration date to a time frame in which we expect the next but one version. Each adopter can edit and adjust the file to meet his own needs. But if they do not edit it, there is at least a security.txt, and we can get notified if someone finds a vulnerability. I'm sure most incidents will be code-based and not configuration-based.
Every Moodle installation has a default security.txt pointing to the Moodle HQ.

I feel very uneasy about this default security.txt. To me, it feels like we are saying the Opencast project takes responsibility for the security of every Opencast installation in a direct sense. And on the other side as an admin, I don't want people to always tell the Opencast project about security issues if they might be related to my configuration.


KINDLY COMMUNICATE WITH COMMUNITY PLEASE ( dear developer) you are making us loose hope

Please, we are pleading with you, developer, to engage in conversation with the community. Your actions are leading us to feel a sense of despair and hopelessness.

https://github.com/Aniketkhote/refreshed

Maybe the author gave it up

So sad, the author should have given a reply.. to all these messages
Atleast.
He could ask for donations as well if needed.
On Wed, Apr 3, 2024, 7:09 AM laterdayi @.***> wrote:

Maybe the author gave it up
—
Reply to this email directly, view it on GitHub
https://github.com/jonataslaw/getx/issues/3068#issuecomment-2033406911,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIRXJSCIQWBWKXW26HHNUR3Y3NQFTAVCNFSM6AAAAABFOXDUBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZTGQYDMOJRGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

I tried it...but it breaks so many things in the project
On Wed, Apr 3, 2024, 7:09 AM laterdayi @.***> wrote:

https://github.com/Aniketkhote/refreshed
—
Reply to this email directly, view it on GitHub
https://github.com/jonataslaw/getx/issues/3068#issuecomment-2033406559,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIRXJSHGK5RCNDVIDODT7WLY3NQD3AVCNFSM6AAAAABFOXDUBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZTGQYDMNJVHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

I'm new to git collaboration but very dependant on getx. Could johnny borges just delegate to the community the future development of getx? Or is there anything that halts him from doing that? Just to be clear, look at /Bitcoin. Nakamoto disappeared 13 years ago but the development is hotter than ever.

Last activity 5 days ago

I understand your feelings, but it's not like there's no activity on the project.
I wish I had more time to engage with the community because it's amazing, but I have to time every second I spend.
I'm polishing some features in separate libs to integrate with GetX, like parse_route, I feel like the only thing that isn't good enough in version 5 is the nested routes, and I'd like to resolve that first.
However, I promise that in a few weeks I will dedicate 1 hour of my day to get this done.

Thanks so much, for replying to us.
This gives us hope, Because we were worried about the future of Getx.
And we don't want to move to cubit bloc
On Thu, Apr 4, 2024, 12:20 PM Jonny Borges @.***> wrote:

I understand your feelings, but it's not like there's no activity on the
project.
I wish I had more time to engage with the community because it's amazing,
but I have to time every second I spend.
I'm polishing some features in separate libs to integrate with GetX, like
parse_route, I feel like the only thing that isn't good enough in version 5
is the nested routes, and I'd like to resolve that first.
However, I promise that in a few weeks I will dedicate 1 hour of my day to
get this done.
—
Reply to this email directly, view it on GitHub
https://github.com/jonataslaw/getx/issues/3068#issuecomment-2036378352,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIRXJSFNTRE4YZE7VZXOGZ3Y3T5NNAVCNFSM6AAAAABFOXDUBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZWGM3TQMZVGI
.
You are receiving this because you authored the thread.Message ID:
@.***>


There is no way to provide a custom SSL certificat for HTTPS

Hi there,
I'm trying to use raven using an HTTPS DSN with a self signed certificate. So, I'm getting a SELF_SIGNED_CERT_IN_CHAIN error when I try to emit messages to sentry.
Is there a way to add ca field to requests options ? http://nodejs.org/api/https.html#https_https_request_options_callback
I can try to make a PR but not sure about how to correctly give the arguments to the transport.send() method
Thanks !

Hmm, if you wanna take a stab, I'm ok with that, if not I'll look into this later in the week and see how I can do this.

Fixed with #110

Thanks :)


Adding the french support

Hello,
Could you insert the French folder in order to add this (beautiful?!? ;) ) language to supported ones by this mod? In that way, I could start translate it as fast as I can!
Thanks a lot!

Hi, Firerazer.
I work for the copyright owner. You can work through the links below.
plz, here :)
https://github.com/sore68/Angelsaddons-locale

Hello!
Thanks a lot! I will start next week the translation job I think
Firerazer
Le 8 mars 2018 à 13:20, Xagros <notifications<EMAIL_ADDRESS>a écrit :
Hi, Firerazer.
I work for the copyright owner. You can work through the links below.
plz, here :)
https://github.com/sore68/Angelsaddons-localehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsore68%2FAngelsaddons-locale&data=02|01||e3f048582d02496bdffa08d584ef07cd|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636561084513252141&sdata=AgB4fwWsgVwBkfwyqv7CQV5EC9r1ueZX6HelaAcT86Y%3D&reserved=0
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsore68%2FAngelsaddons-locale%2Fissues%2F14%23issuecomment-371471663&data=02|01||e3f048582d02496bdffa08d584ef07cd|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636561084513252141&sdata=vTfkkNDedPL75a4Y0HPojKg%2FytwAvxz3fBQFVRdHwNA%3D&reserved=0, or mute the threadhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAifUpAg53lRsUutrVDqG-7LCRS5xYFonks5tcSIggaJpZM4SGzT5&data=02|01||e3f048582d02496bdffa08d584ef07cd|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636561084513408391&sdata=Z%2FGgWowHNMAUCaTZUi8keFg4hLkqd2G09xNc70hcnaI%3D&reserved=0.


Use pinia to manage app state

ref #367

This is still very much broken. Just opening a PR so that I can write down notes.

Some of the MIDI stuff couples too tightly with everything and resists clean separation.

Breaks Analysis -> Interval indexing

Looked through the changes, did more testing and fixed couple of bugs I found. We need pinia to address #529 so I'm merging this one.


Fix st7735 colors, inverted and set orientation cleanup; add default for LVGL_SPRINTF_CUSTOM

I thought boolean symbols are set to n by default.

Thanks for the fixes @an-erd , I will work on adding the LVGL widgets on the menuconfig.


INCBIN command implemented with the file name as a parameter.

Hello, I implemented the NASM's INCBIN command, I tried to implement something simple based on the code style I saw in the files.
Syntax:
incbin "filename"
Origin:
https://nasm.us/doc/nasmdoc3.html

Thanks for your contributions!


Roll Flutter Engine from 0e4f588279be to 46c28aaa46d2 (1 revision)

https://github.com/flutter/engine/compare/0e4f588279be...46c28aaa46d2
2024-10-16<EMAIL_ADDRESS>Roll Skia from 09cdacf52bad to 1b0702f842d4 (2 revisions) (flutter/engine#55900)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jonahwilliams<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Remove Non-Multiplier gas Meter

Describe your changes and provide context

Relies on https://github.com/sei-protocol/sei-wasmd/pull/46
Relies on https://github.com/sei-protocol/sei-wasmd/pull/46
Removes non multiplier gas meter

Testing performed to validate your change

Testing on local chain

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

Project coverage is 61.22%. Comparing base (3dd9e13) to head (1e5bb8e).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1600      +/-   ##
==========================================
- Coverage   61.27%   61.22%   -0.05%
==========================================
  Files         366      365       -1
  Lines       26106    26099       -7
==========================================
- Hits        15996    15980      -16
- Misses       9105     9114       +9
  Partials     1005     1005

Files
Coverage Δ

app/antedecorators/gas.go
100.00% <100.00%> (+25.00%)
:arrow_up:

precompiles/ibc/ibc.go
46.62% <100.00%> (ø)

precompiles/wasmd/wasmd.go
61.21% <100.00%> (ø)

x/dex/keeper/contract.go
74.86% <100.00%> (ø)

x/evm/ante/gas.go
72.72% <100.00%> (ø)

x/evm/ante/preprocess.go
77.69% <100.00%> (ø)

x/evm/keeper/evm.go
52.48% <100.00%> (ø)

x/evm/keeper/msg_server.go
78.82% <100.00%> (ø)

x/dex/contract/abci.go
7.35% <0.00%> (ø)

x/evm/keeper/grpc_query.go
49.38% <0.00%> (ø)

... and 5 files with indirect coverage changes


Remove Lines

Remove links that do not works.

@thiagoaugusto Sorry for delay, I recognized that EOL is still working both site and source code, I'll re-add that. Thanks for your contribution!


Parameterize factory methods with s3 configs

Implements #593

Updated. This can be merged.

@selitvin how do I make the erroneous Codecov errors go away?

I think it's about codecov configuration file. Did not have time to fix this - I am just looking at the actual numbers and if they make sense, then force land it.