Merge updates

Coverage increased (+0.01%) to 97.632% when pulling 98296142a4a5d26cb32f60a49ca2ae8c827e9c73 on James-Tobin:newBranch into d4a4e1f810d182d1e75effdbbe4a47f0ffb40fe4 on mitre-cyber-academy:master.

Coverage increased (+0.01%) to 97.632% when pulling 493f712de3c49b9e819a09b28ffd204791ea0fdf on James-Tobin:newBranch into d4a4e1f810d182d1e75effdbbe4a47f0ffb40fe4 on mitre-cyber-academy:master.

Coverage increased (+0.01%) to 97.632% when pulling 1c271a18d9b960510cc50e42bcb605cd49ff571e on James-Tobin:newBranch into d4a4e1f810d182d1e75effdbbe4a47f0ffb40fe4 on mitre-cyber-academy:master.

Coverage increased (+0.01%) to 97.632% when pulling 5906c1ea7ab9907c201f91893a2fa2be32da2618 on James-Tobin:newBranch into d4a4e1f810d182d1e75effdbbe4a47f0ffb40fe4 on mitre-cyber-academy:master.

Can we get a description for this pr?

Coverage increased (+0.01%) to 97.632% when pulling 7f4f08d66e95891ff4ea9e49c60b61f831abcc28 on James-Tobin:newBranch into d4a4e1f810d182d1e75effdbbe4a47f0ffb40fe4 on mitre-cyber-academy:master.

Coverage increased (+0.01%) to 97.632% when pulling 25779827c92319d55f668387a4ff633f877dc68c on James-Tobin:newBranch into d4a4e1f810d182d1e75effdbbe4a47f0ffb40fe4 on mitre-cyber-academy:master.

Can you add a test to check that teams NOT in the top 10 can update their team? I know we have this but I want to be explicit and have a test

Where game is closed and updates are allowed (which I think is what I linked above)
Game is open and top 10 is locked and
Game is open and not in top 10 is not locked.

@Bialogs If I understand how rails testing works (which there is a good chance I don't), your link is actually for 3 since in fixtures the game is set to be currently happening.  I should be able to make a test for 1 though.

Coverage increased (+0.03%) to 97.655% when pulling c91d15a9d7a0529c82d523b66091a0df08dcde94 on James-Tobin:newBranch into d4a4e1f810d182d1e75effdbbe4a47f0ffb40fe4 on mitre-cyber-academy:master.

Coverage increased (+0.03%) to 97.671% when pulling fbb9d788e3bf59d82bf97e402b3a651a483a4652 on James-Tobin:newBranch into 04245c34dc572f1debf3760652aeab142d643132 on mitre-cyber-academy:master.

Coverage increased (+0.03%) to 97.671% when pulling<PHONE_NUMBER>6bc64180bd8b4471c3999da35930b5 on James-Tobin:newBranch into 04245c34dc572f1debf3760652aeab142d643132 on mitre-cyber-academy:master.

Coverage increased (+0.03%) to 97.671% when pulling<PHONE_NUMBER>6bc64180bd8b4471c3999da35930b5 on James-Tobin:newBranch into 04245c34dc572f1debf3760652aeab142d643132 on mitre-cyber-academy:master.


[CNVS Upgrade] Introduce new PageHeader components

This PR introduces the NewPage* components (to be renamed to NewPage* later).
In the new modularized UI, the container components will determine which data is available to each PageHeader component. Until then, this will not be implemented to avoid unnecessarily reworking our previous components.
Here's how I'm proposing PageHeader's API will look:
<PageHeader
  actions={[
    {
      className: 'button-primary',
      clickHandler: () => console.log('hi'),
      label: 'Open Service'
    },
    {
      className: 'button-stroke',
      clickHandler: () => console.log('hello'),
      label: 'Scale'
    }
  ]}
  breadcrumbs={[
    {
      iconID: 'services',
      label: 'Services',
      submenu: [
        {
          iconID: 'services',
          label: 'Services',
          routeName: 'services-overview'
        },
        {
          label: 'Deployments',
          routeName: 'services-deployments'
        }
      ]
    },
    {
      label: 'Cassandra',
      suffix:  (Running)
    },
    {
      label: 'Something Else!'
    }
  ]}
  tabs={[
    {
      label: 'Services',
      isActive: true,
      routeName: 'services-overview'
    },
    {
      label: 'Deployments',
      isActive: false,
      routeName: 'services-deployments'
    }
  ]} />

Which produces the following:

Conflicts!

Thanks for your patience on this review. Conflicts aside, looks great :)


Add ConfFriends by @vpeschenkov

[x] Project URL: https://github.com/ay8s/ConfFriends
[x] Update contents.json instead of README
[x] One project per pull request
[x] Screenshot included
[x] Avoid iOS or open-source in description as it is assumed
[x] Use this commit title format if applicable: Add app-name by @github-username
[x] Use approved format for your entry

#261

Hi @vpeschenkov - the by attribution is meant to be for the author of the app: here should have been
Add ConFriends by @a8ys
Let me know if you have questions
Sent with GitHawk

@dkhamsing Yes, I know. I didn't pay my attention to that mistake. And, when I noticed that mistake, it was too late to fix.


Feat/generator render widgets

Related to #426

Description
Created a new field in the generator.html to select whether it will render a paybutton or a paybutton-widget.
This change will help testing, before generator only rendered buttons now it can be used to widgets too.
Test plan
Run yarn dev access http://localhost:10001/paybutton-generator.html test generating widgets/buttons.

One thing to notice: this branch has commits from #435, but not all of them (is out-of-date)
When including changes from another branch in the PR branch, try to use the Depends on in the PR description template. This way is easier for reviewers to know which changes to ignore, or which branch to diff it against, or even for you to remember to merge that branch back into this in case that changes (as happened now)


Add a machine readable output format

How about a --json flag to export the out of a run in a machine readable json format. I could then use jsonpath to easily extract information I need.

@schwa Do you want output from the --scan option in JSON format, the media attributes I've parsed and cataloged myself or maybe the .log file that way?

@schwa The HandBrake development team has added a feature like this recently via their new --json option. I should be able to leverage this eventually, but only after I no longer have to support current and older versions of HandBrakeCLI.


Provide adapter infrastructure

Tracking issue:
Mixer should provide a complete end-to-end story for adding adapters to the codebase and using them in a live system.
 There is some refactoring and a bit of config-related work that needs to be done.

This includes the discussed multiple execution phases, etc. @geeknoid, I think your work on fork-join attribute semantics is part of this, so I'm assigning you for now.

Why is this closed?  We still do not have multiple execution phases in the mixer.

We closed it 'cause I think the general theme here has been addressed. I opened #475 and #476 to track the more specific work items.


kudo cli: add uninstall command

What would you like to be added:
Right now we can install the operators using the kudo cli. And to uninstall the instance we can use the kubectl delete instances <instance-name>
And to delete the CRDs for the operatorversion and operator its not a clear path and not documented.
I think instead of using kudo cli to install and kubectl for uninstalling the instances and CRDs, we should have a consistent experience for the lifecycle of the operator.
Something like that:
kubectl kudo uninstall --instance=kafka /Users/zain/go/src/github.com/kudobuilder/operators/repository/kafka/operator/
Why is this needed:

To have a better UX for installing/updating/deleting operators
Make kudo cli a single point of entry to manage the lifecycle of the operators

I totally agree :) we had this discussion here #226
and in the end the decision was to document it and don't add the command.
I guess we need to reopen that discussion again
cc. @gkleiman

my two cents:
Having it in CLI is I think the best kind of documentation because you run install from CLI so it's very easy to figure out how to uninstall as well.
It's very nice feature for newcomers - you just install kudo and want to install package and then remove it from the cluster. I think this flow should be as straightforward as possible to improve the first comer experience.
Also ... HELM does it! :D https://github.com/helm/helm/blob/69002eeb9002dadf8b73379a88534f8f5a576ad6/cmd/helm/installer/uninstall.go#L33

regarding kudo uninstall....

in my mental model... when we install we need the infrastructure (O/OV) and an instance.   I like the separation... and I like that install makes it easy not forcing installing one thing to install the instance.   I see install to indicate... create an instance... upon finding no O/OV it is installed.   If we have a new OV...  we identify that O exists and that a new OV is to be added.... in order to "install an instance".
IMO uninstall by default (no flags) should only remove the instance.   which begs the question @gerred brings up... why do a thing that is really just a kubectl delete.   I do agree with @alenkacz that there is value in have a redundant command under kudo which makes it intuitive.
AND it also allows for additional flags of choice... walking through dependencies... walking through CRD infra

things to be considered

uninstall dependencies (zk)
uninstall infra (O and OV which are separate considerations)
purge volumes

Additionally, there is likely value in having the Operator CLI have a uninstall hook us it can do stuff.
kubectl kudo uninstall should make some call to the operator ("kafka" for instance).   Perhaps the operator "kafka" should have right to decline the uninstall for rules that are in the operator cli/operator logic.
To be clear... I am for kudo uninstall

I'm weakly against this, as discussed, but support the decision and the external need for this. I would like as part of this to keep clear documentation of differences between kubectl delete instance <x> and kubectl kudo delete <x> so that we can make sure the semantics between the two are understood.
Basically, I'm against this because I think there's a risk of us creating a command that alters existing Kubernetes semantics significantly without attempting to upstream them or following existing models.
If this is not avoidable, I believe we should take a Babel/Typescript-ish approach: shim features that are under consideration, and can't be done now, but aim to make this part of the CRD featureset in the future and try to shepherd this upstream. Ultimately, though, this isn't a core focus of what we're working on, rather than a required feature, and I'd rather the feature in and of itself be upstreamed if it doesn't align with what kubectl delete can do today with existing ownership features.
That said, we can keep the alias even once all of the above is covered, as long as we clearly document it as an alias.

I am fine with alias and clearly documenting it as alias 👍

I think we simply need to have an uninstall option in the kudo CLI.
It can be an alias or just tell the user what kubectl command to execute, but without it, the feeling of the user will be that kudo can deploy operators but then can't uninstall them. And the user will think he will have to run multiple kubectl commands to clean everything, even if it's not the case.

If we implement kudo uninstall we can take advantage of the kudo cli by adding some flag to delete all resources and by default just disable it and only delete instances.
with all resources, it would be for pvc operator operatorversion
it would help operators developers using it for testing and development

Having tried KUDO for the first time and already being in the need to tear down a borked KUDO instance, I was searching for kubectl kudo uninstall. I agree that there should be a kubectl kudo uninstall - even if it is just an alias to kubectl delete instances in the beginning.
Later the actual tear down process might incorporate more complex processes.
Anyway, I would always expect to use kubectl kudo to interact with anything KUDO and not directly touch the underlying created resources.

Looking at it from a perspective of abstraction, if we have kubectl kudo install we also need kubectl kudo uninstall.
kubectl kudo install package abstract away how a package will be installed. As a user it interests that the package has been installed. The same should be true for uninstalling packages.


Enable "Remember me" by default

I think it would be beneficial for all users to have "remember me" checkbox set to "Enabled" all the time, this should be the most used functionality.
Currently it requires extra click during every login which is inconvenient.

Re-submitted in frontend repo https://github.com/Couchers-org/web-frontend/issues/209


Ownerinformation class update

Add the ability to toggle on and off the security login settings. This will come in hardly for the app and the u it tests

This was taken care of in the unit test


Update dependency email-ext to v2.91

This PR contains the following updates:

Package
Update
Change

email-ext
minor
2.89 -> 2.91

Release Notes

jenkinsci/email-ext-plugin
v2.91
Compare Source
v2.90
Compare Source
💥 Breaking changes

Migrate to Jakarta Mail (#337, #336) @basil

Related plugin releases
The following plugins must be upgraded in lockstep:

Mailer 435.v79ef3972b_5c7
Pipeline: Basic Steps 980.v82219a_ed188e
Email Extension 2.90
Mail Watcher 1.17

Failure to upgrade all three plugins in lockstep will result in linkage errors.
Jakarta imports
Email Extension 2.90 is the first release with the package namespace changed from javax.mail to jakarta.mail.
If you use a Pre-send Script, Post-send Script, Script - Before Build trigger, or Script - After Build trigger, you must change any imports of javax.mail.* to instead import jakarta.mail.*.
📦 Dependency updates

Bump jsoup from 1.15.1 to 1.15.2 (#377) @dependabot
Bump plugin parent POM from 4.40 to 4.43.1 (#380, #376, #373) @dependabot
Bump plugin BOM from 1409.v7659b_c072f18 to 1478.v81d3dc4f9a_43 (#379, #378, #375, #374, #372) @dependabot

v2.89.1
Compare Source

Configuration
📅 Schedule: "after 5:00 am before 11:00 am" in timezone utc.
🚦 Automerge: Disabled due to failing status checks.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

Branch automerge failure
This PR was configured for branch automerge, however this is not possible so it has been raised as a PR instead.

Branch has one or more failed status checks


Trim kubevirt environment

We cannot use volsync with ramen yet, and the kubevirt environment is
already too big. Without volsync we can remove the volumesnapshot addon
and submariner, which does not handle well suspending of the machine
running the minikube VMs.
With this change we should be able to start an environment, suspend the
laptop, and resume it in an environment with unreliable network or no
network access. This will be useful for live demo in conferences.
Keep volsync enabled in regional-dr and regional-dr-hubless to keep
the submariner and volsync addons functional.
Notes:

Based on #1153 for testing
Contain temporary change to use local git repo for testing, need to remove when done or integrate this in a better way (maybe new local config)

Replaced by #1213


Custom actionsheet does not lock on landscape view

Opening the custom actionsheet on landscape view does not lock on landscape. (Switches the view to portrait)

@angelalagao PR welcome :)


make CMake-only build the default build, make Conan-mode optional

In CMake build system properly distinguish between Conan mode and non-Conan build. Conan-mode was always enabled.

Hi,
did you try something like set(CONAN OFF) ?
before using the cmakelists (as a subproject for example)
Regards,

OK. I tried setting -DCONAN:BOOL=OFF on CMake commandline and I end up in non-Conan mode. So we could keep the code as is.
But that means that Conan-mode is supposed to be the default build environment.
I'd rather suggest to make plain CMake the default build environment because this is what a user would expect.
I still need to change the condition to 'if (DEFINED CONAN AND CONAN)' because now with my PR one can give -DCONAN:BOOL=OFF and it would still enter Conan-mode.

I renamed the PR because original title did now tell correctly what is the result of this PR.
Now after you told me how to disable Conan-mode this PR reduces to a change of default behaviour.
Since it is a matter of taste now you might just close PR if you like Conan-mode to stay default build environment.

Cool if it works now.
yes, I prefer to not change the default behavor and using Conan by default, else it will break previous CI/CD that expect this behavior.
Did you use any other package manager ?
May be I will change my mind if lot of people complains about the default (already made Meson build, Makefile only build, ...)
May be I will add the section in the documentation on how to build without conan...

I use plain CMake when a library offers CMake builds. CMake works great when providing library dependencies as commandline arguments. E.g. in case of Beauty I give:
-DBUILD_SHARED_LIBS:BOOL=ON
-DCONAN:BOOL=OFF
-DBEAUTY_ENABLE_OPENSSL:BOOL=ON
-DBOOST_ROOT:PATH=...
-DBoost_USE_STATIC_LIBS:BOOL=OFF
-DBoost_USE_STATIC_RUNTIME:BOOL=OFF
-DOPENSSL_ROOT_DIR:PATH=...
No package manager needed.

Ok, why not, if it enough for your usage.
Thanks.


Common classes for collectors

InventoryCollection storage for add_collection() and collections.<collection>.build
Collector and Parser's base.

For using  these features, include
require "topological_inventory-ingress_api-client/collector" to your collector. (require "topological_inventory-ingress_api-client" cannot be used because it's generated file).

cc @Ladas

@agrare ^ looks like we can just put it in a separate dir and the generator ignores it

@slemrmartin nice! like this a lot better than in another gem


feat: remove dependency on package.json

When calling generate with a provided url there is still a dependency on the presence of a package json.
This PR removes that dependency

Duplicates https://github.com/lob/generate-changelog/pull/69 ?


std.algorithm.iteration: Add permutations

https://issues.dlang.org/show_bug.cgi?id=13596
A range which lazily computes all permutations of its input using Heap's algorithm.
Not sure if this is the best module for it though.

I swear I've seen it somewhere. nextPermutation or so

Yep, but that's not a range.
Forgot to add See_Also though, fair remark

Wouldn't it make sense to implement this in terms of nextPermutation?

nextPermutation does a lot more work because it does a different thing (next lexicographical permutation).

Please add "fix issue 13596" to commit message and let's merge it.

Done

Auto-merge toggled on


Collect data from ros topic

Is it possible to get video stream from ROS topics?
https://github.com/dusty-nv/jetson-inference/blob/master/docs/pytorch-collect.md
One use would be to get simulated video data from Gazebo or left/right videos from stereo cameras.

Hi @martinerk0, please see https://github.com/dusty-nv/ros_deep_learning
It is ROS nodes for the jetson-inference components like imageNet, detectNet, and segNet (in addition to videoSource and videoOutput nodes)


Debugger stopped working

Issue Type
Bug: debugger suddenly stopped working
Description
Cannot connect to runtime process, timeout after 10000 ms - (reason: Got a response from the target app, but no target pages found).
The launch.json is below
{
    "version": "0.2.0",

	"configurations": [
		{
  "name": "Localhost Launch",
		   "type": "chrome",
		   "request": "launch",
		   "url": "http://localhost:4200",//Change to whatever you homepage is
		    "runtimeArgs": [
			"--new-window", //Open in new window
			"--user-data-dir=${workspaceRoot}/user", //Can be any directory. Makes chrome load in a different directory so that it opens in a new instance.
                        "--remote-debugging-port=9222" //Open in port 9222 (standard chrome debug port)
			],
		    "webRoot": "${workspaceRoot}/src/", //The directory that contains js, ts and map files
		    "sourceMaps": true

		}
	]
}

VS Code Info
VS Code version: Code 1.20.1 (f88bbf9137d24d36d968ea6b2911786bfe103002, 2018-02-13T15:34:36.336Z)
OS version: Windows_NT x64 6.1.7601

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (8 x 3591)

Memory (System)
15.89GB (4.72GB free)

Process Argv
C:\Program Files\Microsoft VS Code\Code.exe

Screen Reader
no

VM
0%

Extensions (4)

Extension
Author (truncated)
Version

vscode-eslint
dba
1.4.6

beautify
Hoo
1.3.0

csharp
ms-
1.14.0

debugger-for-chrome
msj
4.1.0

Reproduces only with extensions

Sorry for the slow response, this issue somehow fell under our radar.
Can you still reproduce this issue with latest vscode update?


Redesign

Redesign the app to follow the following wireframe

the plus could use Bootstrap's 4 modal when triggered on material + https://getbootstrap.com/docs/4.0/components/modal/


FBX camera placement is incorrect

Describe the bug
Opening a FBX file containing a camera do not position the camera at the right location
To Reproduce
Steps to reproduce the behavior:

run blender, default scene, delete light, export to glb, fbx, dae

./bin/f3d ~/untitled.glb --verbose --camera-index=0 --output=glb.png

./bin/f3d ~/untitled.dae --verbose --camera-index=0 --output=dae.png

./bin/f3d ~/untitled.fbx --verbose --camera-index=0 --output=fbx.png

Expected behavior
All images should be similar, fbx is not even pointed to the right location
Additional context
Add any other context about the problem here: may or may not be related to #445

Should be tested again

fixed in 3c90b2e04a1c83148ad69b3a650a1bcab0bfe623


Is there a way to implement this perspective transform functionality for image? Refer to the below video

This cool and awesome library has everything that I am looking for. But, I am not able to see if this functionality is also provided. I do really need it. So, is it possible that I can have this feature along with all the other features that this library provide?
https://user-images.githubusercontent.com/78017969/194506179-126d8742-28aa-4d5f-b15d-11d660713dbb.mp4

@nnha19
The image-editor does not provide this function. Sorry.


Fixed bug in reestablish_connection.

Thanks @fastgeert! We are going to close this pull, since we incorporated your changes in https://github.com/AppScale/appscale/pull/1671.


added basic crawler functionality

now it doesnt return links :(

ok, fixed all issues. @sayamkanwar please review. thanks :)

@pranavgade20 the code here is for a basic crawler but you have submitted the fully-featured crawler task. Please submit the correct task :)

I'm sorry but I have the advanced crawler in another branch with another PR but I think I submitted the wrong link. Anyways, here is the correct link: https://github.com/XINO-DPSR/open-source-marathon/pull/87

Also, could you please review/approve this PR @PalashTanejaPro
Thanks :)


Provide CLI script

The recommended way to use the Importer/Exporter in CLI mode is to invoke the impexp-client.jar using the java tool. From the doc:
$ java -jar lib/impexp-client-{version}.jar [-options]

This is neither intuitive nor handy and it also faces disadvantages. For example, you cannot easily put this command on your PATH and the {version} part of the command must be adapted with every new release. In theory, you could use the provided start script 3DCityDB-Importer-Exporter(.bat) to run the Importer/Exporter in CLI mode. But at least for Windows, the start script uses "start /min cmd /c" to execute the tool. This is OK and makes sense for launching the graphical user interface but suppresses all output when invoking the script from a shell.
This PR proposes to have an explicit CLI script impexp(.bat) in addition to the start script. The CLI script is located in the bin subfolder. This makes using the Importer/Exporter in CLI mode really simple. For example, the following command shows the help message and all available options:
$ impexp -help

This way, the CLI script can be put in the PATH and is independent of the release version. And the start script can be re-implemented such that it just invokes the CLI script with the option to launch the GUI.

Discussed offline with @yaozhihang. Merging.


Android: Remove permissions that have been removed from Android API

Addresses part 1 of https://github.com/godotengine/godot-proposals/discussions/9492
Removal of permissions not existing in Android API
Looking at the diffs between Android API levels, we can see that some permissions have been removed. Since not present in the API anymore, they likely don't have a use case for most apps, and are tech debt, so we can remove them too. If there's a rare use case anyway, they can be added in the Custom Permissions array.
API 23:

API 24

API 29

HOW TO TEST

build the engine
go to Export for Android
see that the removed permissions are gone from the list

I think that all of the permissions supported by Android 6.0 (API 23) and above should be kept, since Android 6.0 is listed as a minimum requirement. Docs can just say that the permission is deprected in the newer versions

I think that all of the permissions not deprecated in Android 6.0 (API 23) should be kept, since Android 6.0 is listed as a minimum requirement. Docs can just say that the permission is deprecated in the newer versions

Agree! Our minimum version is actually lower (i.e: minSdk = 21), so all permissions from that api should be kept, just marked as deprecated if they have been removed in newer versions.

Going the extra mile, you could hide permissions based on the selected minSdk when using gradle build.
The get_export_option_visibility(...) can be used to hide permissions preferences by checking the gradle_build/use_gradle_build and the gradle_build/min_sdk (or gradle_build/target_sdk) preferences.
To simplify the process, the permission entry can be stored into a struct that specified the permission's min and max api level, so you can iterate over the permissions list and automatically hide / show.

I think that all of the permissions not deprecated in Android 6.0 (API 23) should be kept, since Android 6.0 is listed as a minimum requirement. Docs can just say that the permission is deprecated in the newer versions

Agree! Our minimum version is actually lower (i.e: minSdk = 21), so all permissions from that api should be kept, just marked as deprecated if they have been removed in newer versions.

Thanks both!
Here's my rationale - there are permissions marked as deprecated (but still present) in the API/docs - I'd keep them.
The ones that were removed from the Android API (majority in API 23) - I don't see a pressing practical need to keep them, for a few reasons: they are available only in API 21/22 (for the sake of argument I'm ignoring the 4 other ones removed in 24&29) that Godot still supports, and they've been removed 9 years ago, so in my view the cost of keeping them in the codebase is slightly bigger (not that it's big anyway, but still...) than the perhaps inconvenience of adding them in the Custom Permissions array, should the developer want them (looking at those permissions, I'm presuming these would be more experienced devs who would want to use them via Custom Permissions array, but for majority it would be a clutter?). Otherwise, we'd keep all the other removed, obsolete, non-existent code long after its expiration date so to speak. I don't believe it makes sense in this case.
Happy to drop this of course, maybe I'm missing the bigger picture in Godot?

Going the extra mile, you could hide permissions based on the selected minSdk when using gradle build.
The get_export_option_visibility(...) can be used to hide permissions preferences by checking the gradle_build/use_gradle_build and the gradle_build/min_sdk (or gradle_build/target_sdk) preferences.
To simplify the process, the permission entry can be stored into a struct that specifies the permission's min and max api level, so you can iterate over the permissions list and automatically hide / show.

Good idea. I've also been thinking about showing the deprecated, "Not for use by third-party applications."/the ones with protection level signature etc. in a separate section in the export dialog for clarity, eg.

Permissions
Permissions - deprecated
Permissions - Not to be used by 3rd party

maybe even on a separate Android permissions tab. Would that be useful?

I think that all of the permissions not deprecated in Android 6.0 (API 23) should be kept, since Android 6.0 is listed as a minimum requirement. Docs can just say that the permission is deprecated in the newer versions

Agree! Our minimum version is actually lower (i.e: minSdk = 21), so all permissions from that api should be kept, just marked as deprecated if they have been removed in newer versions.

Thanks both!
Here's my rationale - there are permissions marked as deprecated (but still present) in the API/docs - I'd keep them.
The ones that were removed from the Android API (majority in API 23) - I don't see a pressing practical need to keep them, for a few reasons: they are available only in API 21/22 (for the sake of argument I'm ignoring the 4 other ones removed in 24&29) that Godot still supports, and they've been removed 9 years ago, so in my view the cost of keeping them in the codebase is slightly bigger (not that it's big anyway, but still...) than the perhaps inconvenience of adding them in the Custom Permissions array, should the developer want them (looking at those permissions, I'm presuming these would be more experienced devs who would want to use them via Custom Permissions array, but for majority it would be a clutter?). Otherwise, we'd keep all the other removed, obsolete, non-existent code long after its expiration date so to speak. I don't believe it makes sense in this case.
Happy to drop this of course, maybe I'm missing the bigger picture in Godot?

@melquiadess Thanks for describing your rationale! From your comment I can identify two stated points; I can address them below:

Cost of keeping the deprecated permissions in the codebase: Here I would take the opposite perspective; our official min sdk is 21 so we should support (as much as possible) all permissions from that api level UNLESS the cost of support is high. Based on previous experiences, I'm not seeing a high cost of keeping those permissions in the codebase.

This approach aligns with one of Godot's goals which is to prioritize the user experience. Here this means providing the necessary capabilities for developers choosing to target devices running api 21. An additional perspective here is that in many parts of the world, people have devices running old versions of Android. This chart shows ~1% difference in cumulative usage between api 23 and api 21, which at the scale that Android runs is equivalent to ~20 millions devices.

Removing clutter from the UI: This can be addressed by the suggestion I made above of hiding the permissions based on their min / max api levels!

Going the extra mile, you could hide permissions based on the selected minSdk when using gradle build.
The get_export_option_visibility(...) can be used to hide permissions preferences by checking the gradle_build/use_gradle_build and the gradle_build/min_sdk (or gradle_build/target_sdk) preferences.
To simplify the process, the permission entry can be stored into a struct that specifies the permission's min and max api level, so you can iterate over the permissions list and automatically hide / show.

Good idea. I've also been thinking about showing the deprecated, "Not for use by third-party applications."/the ones with protection level signature etc. in a separate section in the export dialog for clarity, eg.

Permissions
Permissions - deprecated
Permissions - Not to be used by 3rd party

I don't think a separate section is needed since we can provide that information in the permission tooltip (shows when hovering over the permissions).
Deprecated permissions (based on the target sdk level) can also been hidden using my earlier suggestion.
For the permissions that fall under Not to be used by 3rd party, we can hide them by default and only show them when Advanced Options is enabled.

maybe even on a separate Android permissions tab. Would that be useful?

A separate permissions tab would be really useful in cleaning up the clutter that permissions (even supported ones) add. However that may depart from the current style used in the export window, so that option would need to also scale to other export platform.
An alternative to reduce the visual clutter could be to add the ability to collapse sections in the export window.

Fair enough!
Thanks @m4gr3d for taking the time to provide context and the additional information, I appreciate it.
To summarize:

we keep all permissions that were/are in the APIs supported by Godot, which as of now, is minSdk=21
we could show/hide certain permissions based on minSdkVersion, maxSdkVersion and targetSdkVersion
we could show 3rd party/special permissions only when Advanced mode is enabled
we could show extra information about a permission in the tooltip


Update security-trusted-workspace-access.md

Adding an update to accommodate recent changes to shortcuts
Thank you for contributing to Microsoft Fabric documentation
Fill out these items before submitting your pull request:
If you are working internally at Microsoft:
Provide a link to an Azure DevOps Boards work item that tracks this feature/update.

Who is your primary Skilling team contact? @mention them individually tag them and let them review the PR before signing off.

For internal Microsoft contributors, check off these quality control items as you go

[ ] 1. Check the Acrolinx report: Make sure your Acrolinx Total score is above 80 minimum (higher is better) and with no spelling issues. Acrolinx ensures we are providing consistent terminology and using an appropriate voice and tone, and helps with localization.

[ ] 2. Successful build with no warnings or suggestions: Review the build status to make sure all files are green (Succeeded).

[ ] 3. Preview the pages:: Click each Preview URL link to view the rendered HTML pages on the review.learn.microsoft.com site to check the formatting and alignment of the page. Scan the page for overall formatting, and look at the parts you edited in detail.

[ ] 4. Check the Table of Contents: If you are adding a new markdown file, make sure it is linked from the table of contents.

[ ] 5. #sign-off to request PR review and merge: Once the pull request is finalized and ready to be merged, indicate so by typing #sign-off in a new comment in the Pull Request. If you need to cancel that sign-off, type #hold-off instead. Signing off means the document can be published at any time. Note, this is a formatting and standards review, not a technical review.

Merge and publish

After you #sign-off, there is a separate PR Review team that will review the PR and describe any necessary feedback before merging.
The review team will use the comments section in the PR to provide feedback if changes are needed. Address any blocking issues and sign off again to request another review.
Once all feedback is resolved, you can #sign-off again. The PR Review team reviews and merges the pull request into the specified branch (usually the main branch or a release- branch).
From the main branch, the change is merged into the live branch several times a day to publish it to the public learn.microsoft.com site.

Dear PR reviewers. I have a question for the contributor pending with them. Will sign off once they respond.

#please-close
Taken care of through PR: https://github.com/MicrosoftDocs/fabric-docs-pr/pull/6691


LICENSE.txt missing in tarball on pypi.org

Hi! I'm packaging hsluv for Arch Linux.
To be able to distribute the package, I require the license file, that is contained in this repository.
Unfortunately it is not contained in the source tarball on pypi.org

The text is standard MIT license text. I'm packaging downstream myself, for Gentoo in my case. Why do you need the file in packaging?
On the technical part, it seems that file MANIFEST.in is out of sync, and maybe should be deleted altogether.

The MIT license is specific to each project, as it states the person/entity holding the copyright.
These license files need to be present when distributing software in source or binary form. For other licenses (e.g. GPL) it is sufficient to have one copy of the license file on the system, as the license file is not unique per project (does not state the entity holding the copyright). This is at least according to our current packaging guidelines on Arch Linux.

On the technical part, it seems that file MANIFEST.in is out of sync, and maybe should be deleted altogether.

Yes, amending that file would fix this and #29.

The MIT license is specific to each project, as it states the person/entity holding the copyright.
These license files need to be present when distributing software in source or binary form. For other licenses (e.g. GPL) it is sufficient to have one copy of the license file on the system, as the license file is not unique per project (does not state the entity holding the copyright). This is at least according to our current packaging guidelines on Arch Linux.

I follow your explanation but that seems way out of proportion, even with me caring about licensing in general. For comparison, there is a single MIT license in Gentoo :
# head -n1 /usr/portage/licenses/MIT
Copyright (c) <year> <copyright holders>

I would normally ask for a reference/source on that statement with regard to Arch but since we have a bug in MANIFEST.in here anyway, I'll take that as-is and open a pull request. Give me a few minutes.


[Windows] Remove header guard from generated key map

The generated file is a .cc file that does not need header guards.
No tests as this is a refactoring with no semantic changes.
The engine will be updated by https://github.com/flutter/engine/pull/48993

Yes, we should remove this, but as this is a generated file, we should also remove it here too:
https://github.com/flutter/flutter/blob/main/dev/tools/gen_keycodes/data/windows_flutter_key_map_cc.tmpl#L5

You should also update the engine side too: https://github.com/gspencergoog/engine/blob/main/shell/platform/windows/flutter_key_map.g.cc#L5


[feature request] ng-selected attribute for a  tag without using an embedded  tag

Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.
Do you want to request a feature or report a bug?
feature
What is the current behavior?
there is no ng-selected-type attribute for a select element using ng-options.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).
What is the expected behavior?
There will be an ng-select-like attribute for a select tag without the need to do an <option ng-repeat="item in items">-like construct within the select element.
What is the motivation / use case for changing the behavior?
This should reduce the size of users' code bases, in addition to increased performance as noted here under "Choosing between ngRepeat and ngOptions".
Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
all versions, all browsers
Other information (e.g. stacktraces, related issues, suggestions how to fix)

I don't understand what you want, tbh. You are you saying you want ng-selected for ng-options. But with ng-options, you are using ng-model to set the selected value. Same with select + repeated options. You use ng-model to set the value.

I want to be able to do lines 17-19 here in one select tag, as opposed to having to do an <option> tag within a <select> tag or having to set the selected item in the controller.

If we were to implement something like this, it had to go into the ngOptions DSL. And I think complicating the ngOptions DSL further is one step too far. The "Angular way" is to set the value in the model (not the view) anyway, so working around that will only bring confusion.
Note that if you insist on having that kind of logic in your HTML (something that I would strongly recommend against), you can use ngInit:
<select
    ng-model="data.model"
    ng-options="o.id as o.name for o in data.availableOptions"
    ng-init="data.model = data.availableOptions[2].id"
</select>

Closing as won't fix.


Vue HotColumn not reactive immediate

Description
In the demo, when use columns instead of hot-column, it's no problem.
When use hot-column, and renderer will not display immediate, if I update the state and save some times, it will render more than 1 columns which not defined with hot-column
Demo
https://codesandbox.io/s/handsontable-vue-hot-column-implementation-742-411-cquo1?file=/src/App.vue
Your environment

Vue wrapper version: 4.1.1
Handsontable version: 7.4.2
vuex: 3.5.1

Hi @muei

and renderer will not display immediate

I do not see any use of a custom renderer in your demo. Is that the latest version of the demo?


Added 2016 build for DDConvextHull

pretty new to the whole building in c++, I believe everything should be working fine as I've tested it on my windows system. But who knows...

I dont have 2016 to test it with, but am going to just assume it works and merge it in.


docs/podman.1: Link to hook documentation

Collecting the Podman/libpod specifics in one place allows us to make the hooks README more generic.
I think this is a prereq to adding a Podman/libpod extended stage using the API from #758.
I've currently used a Markdown link here, although links aren't really a man-page thing.  The link will work on GitHub, but we may want some pre-processing to replace the link (and our other existing links?) when building for installation.  Maybe that means translating the current hooks README into a man page as well.  oci-hooks.5?

I've pushed 57a1651 -> 0f0954a, converting the hooks docs to oci-hooks.5.  The new series builds on #774, so review that first.
https://github.com/projectatomic/libpod/pull/772#discussion_r188341120

@wking Needs rebase.

Rebased onto master with d2b931a -> 40a97ac (no conflicts).

@wking This needs a rebase


Math formulas in rows after a list are not displayed correctly

For example
1. $A^{\prime}$ is linear;
2. $A^{\prime}(Jv)=iA^{\prime}(v)$

Is this the same issue as #34?

I feel like nobody reads the docs :\
It works fine: https://share.note.sx/zndza5vy#f/tnKKfrB5p4bWxu7D2ryhEfPC31pLqc+TBJd0Uo5f0
Please read the docs. Here are the docs: https://docs.note.sx/notes/latex

I believe this will be long resolved, but for reference it works fine and the solution is in the docs:
https://docs.note.sx/notes/latex
Example working fine: https://share.note.sx/zndza5vy#f/tnKKfrB5p4bWxu7D2ryhEfPC31pLqc+TBJd0Uo5f0


Update font-jaapokki to 1.0

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Merged as 53bfd48135409b78fe748c457b256cbd47f5b43d.


path is not right

Hi, I found your add-on and I see it so interesting because I'm working with some videos for a kind of Xmas carol and I want to remove some backgrounds. I had problems with final step, I installed all the requirements but I'm not into python,  I can't achieve the right path for python and PROJECT_DIR and I don't know who to do it. It gives me error because the path code isn't well written. Could you show some me example from your installation? I guess it could help.
Congrats for your job. Thank you for your help.
Cheers!
Joan B.

The setup is quite complicated and can definitely be improved in the future.
Can you show me how you added the path in automask.py#L7-10
Did you install the dependencies in a separate python? And can you show me the error you get?

Hi, this is the error in my Blender Info Log

you have to replace PYTHON_PATH with your path.
paths = [
    '/Users/joan/Library/Python/2.7/lib/site-packages
    '/Users/joan/AutoMask-master'
]

Also you need python 3.7 and the path needs to point to the directory site-packages.

ok. thanks.


RunSettings file not used in TFS VsTest task

Environment
TFS On Prem, Version 16.131.27701.1
Agent - Windows Server 2012R2, agent version 2.131.0
Issue Description
While running the vstest task, the .runsettings file I've provided is being ignored and replaced by an autogenerated version, causing the coverage report to include assemblies I don't want. These are what I believe to be the relevant settings, let me know if you need anything more.

Error logs
These are what I believe to be the relevant logs, let me know if you need anything more.
2018-08-17T15:49:03.0063756Z ==============================================================================
2018-08-17T15:49:03.8104045Z Run the tests locally using vstest.console.exe
2018-08-17T15:49:03.8104260Z ========================================================
2018-08-17T15:49:03.8104856Z Test selector : Test assemblies
2018-08-17T15:49:03.8105068Z Test assemblies : **\*Tests.dll,!**\*TestAdapter.dll,!**\obj\**
2018-08-17T15:49:03.8105262Z Test filter criteria : null
2018-08-17T15:49:03.8105432Z Search folder : C:\agent\_work\181\s
2018-08-17T15:49:03.8105609Z Run settings file : C:\agent\_work\181\s\CodeCoverage.runsettings
^^^^^^ Using my settings file
2018-08-17T15:49:03.8105859Z Run in parallel : false
2018-08-17T15:49:03.8106037Z Run in isolation : false
2018-08-17T15:49:03.8106977Z Path to custom adapters : null
2018-08-17T15:49:03.8107159Z Other console options : null
2018-08-17T15:49:03.8107319Z Code coverage enabled : true
2018-08-17T15:49:03.8107664Z Rerun failed tests: false
2018-08-17T15:49:03.9133771Z VisualStudio version selected for test execution : toolsInstaller
2018-08-17T15:49:04.1860621Z ========================================================
2018-08-17T15:49:04.4973145Z [command]C:\agent\_work\_tool\VsTest\15.9.0-preview-20180807-05\x64\tools\net451\Common7\IDE\Extensions\TestPlatform\vstest.console.exe @C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\11251751-a235-11e8-8719-85a908d74f4f.txt
2018-08-17T15:49:04.7074312Z Microsoft (R) Test Execution Command Line Tool Version 15.9.0-preview-20180807-05
2018-08-17T15:49:04.7074631Z Copyright (c) Microsoft Corporation.  All rights reserved.
2018-08-17T15:49:04.7074717Z
2018-08-17T15:49:04.7074811Z vstest.console.exe
2018-08-17T15:49:04.7074939Z "C:\agent\_work\181\s\MyProjectName\bin\Release\MyProjectName.Tests.dll"
2018-08-17T15:49:04.7075151Z /Settings:"C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\11441100-a235-11e8-8719-85a908d74f4f.runsettings"
^^^^^^ Not using my settings file
2018-08-17T15:49:04.7075274Z /logger:"trx"
2018-08-17T15:49:04.7075379Z /TestAdapterPath:"C:\agent\_work\181\s"
2018-08-17T15:49:04.8381749Z Starting test execution, please wait...

Initially while reviewing those logs, I assumed that the temp file it was creating may just be a copy of my coverage file, which is as follows:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
        <Configuration>
          <CodeCoverage>
            <ModulePaths>
              <Include>
                <ModulePath>.*\\MyProjectName.*\.dll$</ModulePath>
              </Include>
              <Exclude>
                <ModulePath>.*Tests.dll$</ModulePath>
              </Exclude>
            </ModulePaths>
          </CodeCoverage>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

However, I was able to catch one of the generated .runsetting files it's creating, which is effectively empty:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
        <Configuration>
          <CodeCoverage>
            <UseVerifiableInstrumentation>False</UseVerifiableInstrumentation>
          </CodeCoverage>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

As a final side note (and this may make sense to make as a separate issue) the test cleanup deletes the .runsetting file it creates in the temp directory, but leaves a .txt file containing the path to the test dll, settings file location, logger, and test adapter path. It seems likely this is intended to be cleaned up as well, but was missed.

@shortstuffsushi I see that you have also checked Code Coverage Enabled checkbox. Can you un check and try again. Saying this because you already have enabled Code coverage in your runsettings and you don't need to use this task option.
Regarding cleanup, with recent changes in our task (that will flow in vsts) we are cleaning up all generated files. so this should be fixed.

Hey @acesiddhu, I had thought you may ask that, but chose to not include those results because they seem like probably an unrelated thing. Unfortunately, running without that checked is even worse, as it results in all tests failing with the following:
Failed   MyTestMethod
Error Message:
 Test method MyTestMethod threw exception:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.CodeCoverage.Shim, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Stack Trace:
   at MyClass..ctor(...)
   at MyTestMethod() in C:\...\MyTestFIle.cs:line 40

@shortstuffsushi this was surely a bug on our side which we have fixed @prawalagarwal can you confirm. in the mean time you can change your run settings to include in your code coverage configuration node.

False

I'm not sure what you're asking me to include. Do you want me to put the text false inside one of the nodes? Could you give a more complete example of what you're asking for?

Sorry GH ate my comment because it an xml
here is the runsetting u can use
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
        <Configuration>
          <CodeCoverage>
           <UseVerifiableInstrumentation>False</UseVerifiableInstrumentation>
            <ModulePaths>
              <Include>
                <ModulePath>.*\\MyProjectName.*\.dll$</ModulePath>
              </Include>
              <Exclude>
                <ModulePath>.*Tests.dll$</ModulePath>
              </Exclude>
            </ModulePaths>
          </CodeCoverage>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

Ok, adding the UseVerifiableInstrumentation = False seems to have worked, could you explain why?

you are using visual studio test tools installer task in your definition. in case that task is used useverifiable property needs to be set to false because in xcopy mode we don't GAC the above dll 'Microsoft.VisualStudio.CodeCoverage.Shim (this is a dependency which needs to be loaded when useverifiable is set to true)
marking this property false ensures it doesn't use this particular dll.

Hi @shortstuffsushi I am closing the issue. Thanks

@acesiddhu I count three open issues here.

Use Code Coverage Enabled ignores user .runsettings files
.txt generated files aren't being cleaned up
Disabling Code Coverage Enabled causes errors because Microsoft.VisualStudio.CodeCoverage.Shim is unavailable

I'm at a point where I can work around these, but ideally they'd be fixed right? Are you tracking them internally or something? It seems like this issue isn't resolved.

Hi @shortstuffsushi sorry for not replying to this before. I tested all the scenario with our latest code and here are the findings

This seems to be fixed in latest code base. if I provide .runsettings files with Code coverage on, I see it is honoring the runsettings I provide

The txt files are getting cleaned up.

this is also fixed in latest code base.

Let me know if you any other issues

Is there a way for me to check this out on my end / on our local TFS instance? Will the updates you mentioned be part of an upcoming release?

there is no way to test the changes in ur local tfs because vstest task might be incompatible with your current tfs version. the fixes will be in upcoming Azuredevops server release.


ZBuffer problems

I'm having problems when mixing ImGui and ZBuffer
I've modified your sample (just removed the extra docked dialogs, only 'demo' and 'debug' panels appear) and added a rotating cube:
https://pastebin.com/0nq0inat
When pressing the mouse left button, ImGui initializes and ZBuffer is somehow lost. Do you know if I need a special flag to pass to ImGui in order to conserve ZBuffer?
note:
explicitely clearing the zbuffer before myRender doesn't work either. ( i.e. GraphicsDevice.Clear (ClearOptions.Target | ClearOptions.DepthBuffer | ClearOptions.Stencil, Color.Red,1,0);  )

Commit ce2ad83a1661b48cb702365cfc99d87926323cd6 should fix this.
 With viewports set up correctly (just set one up for you to use in myRender()):

Not closing as fixed just yet, I don't think the viewport hassle should actually be there.

Closing this as fixed now.
This case, as well as the reverse where you render your scene first and then draw the ImGui, should be fully functional.
You might have to fiddle your GraphicsDevice Clear calls around and setup viewports, but that should be all. The ImGuiCli side now no longer does any clearing of the backbuffer, which is probably what forced you to use the render ordering you're using.

FYI: If you don't intend to use the docking you don't need to use the RootDock function. You can just create windows via ImGuiCli.Begin(...) and ImGuiCli.End().
Docking makes more sense to use if you intend to do your MonoGame rendering into render-targets that you draw with ImGuiCli.Image(myRenderTarget)

Thanks a lot, it's working now both drawing before and after.
Yes, the order was reversed because I was experimenting trying to get around the bug and afterwards I forgot to notify the problem. The RootDock is a mixture between experimentation and lack of knowledge :)


HAPI FHIR with Elasticsearch does not support date/time before the epoch (1970)

Describe the bug
Elasticsearch based deployment failed to load observation resources with effectiveDateTime earlier than 1970.
The issue may apply to other date/dateTime fields that are indexed in Elasticsearch.
To Reproduce
Steps to reproduce the behavior:
Try load this example resource to https://lforms-fhir.nlm.nih.gov/baseR5 and you will get back the Elasticsearch date parse error:
{
"resourceType": "Observation",
"id": "obs-pre-1970",
"status": "final",
"effectiveDateTime": "1969-01-01",
"code": {
"coding": [
{
"code": "1234",
"display": "who cares"
}
]
}
}
Expected behavior
Dates oder than 1970 should work.
Environment (please complete the following information):

HAPI FHIR Version: 6.2.2 (also reproduced with version 6.8.3)
The issue probably only applies to deployments that use Elasticsearch
OS: Ubuntu

Looks like this has been fixed in later releases, e.g., it works fine for version 7.2


While running command like  "react-native init AwesomeProject" am getting following error please tell me how to solve it  ?

Installing react-native package from npm...
/Users/vasavi/dev/CLOUDSEED_APP/AwesomeProject/node_modules/react-native/local-cli/init.js:7
class CreateSuppressingTerminalAdapter extends TerminalAdapter {
^^^^^
SyntaxError: Unexpected reserved word
at exports.runInThisContext (vm.js:73:16)
at Module._compile (module.js:443:25)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object. (/Users/vasavi/dev/CLOUDSEED_APP/AwesomeProject/node_modules/react-native/local-cli/cli.js:11:12)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)

+1, I encountered the same issue.

Make sure you have Node 4+ as explained in the setup instructions.

Have the same issue im using 4.0.0 but still exists

Thanks for the followup @sriharrsha!

Thanks

Thanks

@sriharrsha Thanks a lot man !

@sriharrsha You saved my day !

ln: /usr/bin/node: Operation not permitted

Same problem while running Node 5.2 Is there a new fix?

Run nvm install node && nvm alias default node

@petervavro for me nvm didn't work, tried all the workarounds for it  and  finally used n package manager and it worked.

+1, I encountered the same issue.

thanks

thanks it Worked 👍

use node version 4.4.4


How to deploy my app in stores for ios and android?

Instructions here: https://docs.getexponent.com/versions/v10.0.0/guides/building-standalone-apps.html


fatal error: 'seal/seal.h' file not found

I have installed SEAL 3.2.0 on macOS Catalina version 10.15.7 and it works fine (Unit tests passed and examples works).
Having issues running SealPIR.
devharsh@Devharshs-MBP SealPIR-master % sudo LDFLAGS="-L/usr/local/lib/" CFLAGS="-I/usr/local/include/" make
[ 16%] Building CXX object CMakeFiles/sealpir.dir/pir.cpp.o
In file included from /Users/devharsh/Downloads/SealPIR-master/pir.cpp:1:
/Users/devharsh/Downloads/SealPIR-master/pir.hpp:3:10: fatal error: 'seal/seal.h' file not found
#include "seal/seal.h"
^~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/sealpir.dir/pir.cpp.o] Error 1
make[1]: *** [CMakeFiles/sealpir.dir/all] Error 2
make: *** [all] Error 2

It seems the compiler cannot find seal.h. Did you compile SEAL 3.2 with ``sudo make install''?

yes I did install SEAL globally
devharsh@Devharshs-MBP src % sudo make install
[100%] Built target seal
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/lib/libseal.a
-- Up-to-date: /usr/local/lib/cmake/SEAL/SEALTargets.cmake
-- Installing: /usr/local/lib/cmake/SEAL/SEALTargets-release.cmake
-- Up-to-date: /usr/local/lib/cmake/SEAL/SEALConfig.cmake
-- Up-to-date: /usr/local/lib/cmake/SEAL/SEALConfigVersion.cmake
-- Up-to-date: /usr/local/include/seal/batchencoder.h
...
I also tried prefixing path in cmake:
devharsh@Devharshs-MBP SealPIR-master % sudo cmake . -DCMAKE_PREFIX_PATH=/usr/local/include/
Password:
-- Microsoft SEAL -> Version 3.2.0 detected
-- Microsoft SEAL -> Library build type: Static_PIC
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_PREFIX_PATH

-- Build files have been written to: /Users/devharsh/Downloads/SealPIR-master

Also, there is another error, If I fix seal/seal.h path error (by providing absolute path in the header file or by copying SEAL-3.2.0/native/src folder) I get this error for biguint.h:
devharsh@Devharshs-MBP SealPIR-master % make
[ 16%] Building CXX object CMakeFiles/sealpir.dir/pir.cpp.o
In file included from /Users/devharsh/Downloads/SealPIR-master/pir.cpp:1:
In file included from /Users/devharsh/Downloads/SealPIR-master/pir.hpp:3:
/Users/devharsh/Downloads/SealPIR-master/seal/seal.h:6:10: fatal error: 'seal/biguint.h' file not found
#include "seal/biguint.h"
^~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/sealpir.dir/pir.cpp.o] Error 1
make[1]: *** [CMakeFiles/sealpir.dir/all] Error 2
make: *** [all] Error 2

Had to edit CMakeLists.txt:
include_directories("/usr/local/include")


Y-axis inverted in image-mode

Just trying the latest version.

When plotting with the default image mode the y-axis is inverted

Switching to the colormesh plot fixes this:

interesting :)
it looks like this is because you're measuring by sweeping down the voltage which is a case i probably overlooked :P
will take a look today.

@GitJaap should be fixed now - works fine in my tests. LMK if you agree.

thanks! i agree


Example project and updated .gitignore

Description

Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Documentation update

Checklist

[ ] Tests have been added/updated to cover new functionality.
[ ] Documentation has been updated for all new changes (e.g., usage examples, API documentation).

Simple example project with a few common usages, eg. reading tiles, properties, tilesets. Example includes both quick and easy way to load, and manually.
Also updated .gitignore to ignore .idea directory created by JetBrains Rider.

Godot 4.3 supports full .NET 8 capabilities, so unless there's a bug, DotTiled will work.

Godot 4.3 supports full .NET 8 capabilities, so unless there's a bug, DotTiled will work. I'll try later, and if it works, I'll put Godot example with this PR

Interesting! I was not aware of that, let me know if it works out :)

Done, working on Godot example now. Once I get it working, I'll push it to this PR.

Godot example done, PR can be merged.


chore: replace _ with .. in field extracting

replace the not used fields with .. which were extracted in the struct extracting

actually, I prefer named placeholders because these allow us to catch new fields


Fix application container margin / padding issue

Adds margin and padding back in to where is was before.
Not a long term solution as these pages will be replaced, just putting back in like for like.

Thanks @ldodds, I'll get it merged


Add helm hooks for admission controller deplolyment

I've tested the following fix for the further issue described in Issue 25 at it works as expected. I don't think there are any likely issues to appear due to this change.

@mlladb Thanks for the PR. We want to reject DNSClass object if the validation fails. If we do this, we would skip that process.
I think we should add a DNSClass template inside the existing template and applying it with a hook so that it gets applied last. Would you be interested in contributing a commit for this feature?

I've add the dnsclass templating. It seems to work as expected for me.
I can add my own custom config with the flowing values.yaml file.
kubedns-shepherd:
  certmanager:
    enabled: false
  dnsclass:
    allowedNamespaces:
      - default
      - kubedns-shepherd
    disabledNamespaces:
      - kube-system
    allowedDNSPolicies:
      - None
      - ClusterFirst
      - ClusterFirstWithHostNet
    dnsPolicy: None
    dnsConfig:
      nameservers:
        - <IP_ADDRESS>
      searches:
        - "{{ .podNamespace }}.svc.cluster.local"
        - "svc.cluster.local"
        - "cluster.local"
      options:
        - name: ndots
          value: "3"
        - name: edns0

I also realized that your changes would work for Argo but when Helm applies the changes it will fail because it requires to wait the pods to be ready. I will include your changes and improve it. Thanks for your support.


added on-change callback

Add on Change callback, will be executed when date is selected (same as ng-change).

@logbon72, why did you close it?

Close was accidental, will review soon.

Will have to leave closed, this has been addressed in previous requests. See #34


Update securesyslib dependency to 0.16.0

Fixes issue #: None
Description of the changes being introduced by the pull request:
Updating securesyslib dependency to 0.16.0 is needed for some of the open prs.
Please verify and check that the pull request fulfills the following
requirements:

[ ] The code follows the Code Style Guidelines
[ ] Tests have been added for the bug fix or new feature
[ ] Docs have been added for the bug fix or new feature

I merged the dependabot sslib dependency update in #1107. Let's add the setup.py change in a PR which introduces changes that require the newer sslib.


Recovery Re-Sync logic ignores Token Categories

It seems the tokenMatcher function is not used which means
the token categories are not handled properly.
Example:

https://github.com/SAP/chevrotain/blob/c001c1a8f94f0d00de03a10be701bcb28a5e34be/packages/chevrotain/src/parse/parser/traits/recoverable.ts#L278-L291

Possibly also affects this:

https://github.com/SAP/chevrotain/blob/c001c1a8f94f0d00de03a10be701bcb28a5e34be/packages/chevrotain/src/parse/parser/traits/recoverable.ts#L269-L276

This may cause the Parser to re-sync (throw out) more input than needed to recover.

Just ran into this. I'm writing a parser that takes both symbol and non-symbol operators, so they are distinct token types (since the word operators must use longer_alt but not the symbol ones), but the operators have a category to be able to consume them since MANY_SEP won't take rules, unfortunately using it leads to this issue.
The following workaround works but is very wordy since DEF must be written twice.
// $.MANY_SEP({ SEP: OPERATOR_AND, DEF })
$.OR([
	{
		GATE: () => $.LA(1).tokenType === SYM_AND,
		ALT: () => $.MANY_SEP({ SEP: SYM_AND, DEF }),
	},
	{
		GATE: () => $.LA(1).tokenType !== SYM_AND,
		ALT: () => $.MANY_SEP2({ SEP: WORD_AND, DEF2 })
	},
])

Is there any danger in just using js control flows like this if it seems to work?
if ($.LA(1).tokenType === SYM_AND) {
	$.MANY_SEP({ SEP: SYM_AND, DEF })
} else {
	$.MANY_SEP({ SEP: WORD_AND, DEF })
}

Just ran into this. I'm writing a parser that takes both symbol and non-symbol operators, so they are distinct token types (since the word operators must use longer_alt but not the symbol ones), but the operators have a category to be able to consume them since MANY_SEP won't take rules, unfortunately using it leads to this issue.
The following workaround works but is very wordy since DEF must be written twice.
// $.MANY_SEP({ SEP: OPERATOR_AND, DEF })
$.OR([
	{
		GATE: () => $.LA(1).tokenType === SYM_AND,
		ALT: () => $.MANY_SEP({ SEP: SYM_AND, DEF }),
	},
	{
		GATE: () => $.LA(1).tokenType !== SYM_AND,
		ALT: () => $.MANY_SEP2({ SEP: WORD_AND, DEF2 })
	},
])

Is there any danger in just using js control flows like this if it seems to work?
if ($.LA(1).tokenType === SYM_AND) {
	$.MANY_SEP({ SEP: SYM_AND, DEF })
} else {
	$.MANY_SEP({ SEP: WORD_AND, DEF })
}

I am writing an XML-like parser where I need some recovery for something like <  <Foo />. I had a hard time, as I could not get the re-sync to work. Then I found a hint to this issue in the xml-tools repository. It seems I could fix this with overwriting findReSyncTokenType, too. But it feels more like a hack as it is not even a public API (no type definitions). I wonder a bit if more of those recovery APIs should be public and with type definitions (especially as I already hat the problem with #1753). What do you think?

it seems very easy to fix it upstream in Chevrotain. Is there a reason why it is not fixed yet?

Priorities / not affecting my use cases so much / leaving some easy to fix items for contributors / ...

I also wonder a bit if more of those recovery APIs should be public and with type definitions

Yeah, that sounds like an improvement for one of the big (and somewhat unique) features of fault tolerance.

I will see where I can contribute.

Awesome 👍


Add kivy support

Hello,
Are you still interested in maintain this project? If so i would like to add support for the new async def and await keywords. If not, would you be able to mention on the readme / pypi about the fork?
Thanks for the nice library/docs/tests :)
Kind Regards,
Tim

Hello,
Thanks for adding Kivy support!
I'm not sure if adding async def/await can be done with cross support for 2.7/3.5? This library was made mainly for Python 2.7, but I don't know what version do users have.


[GOBBLIN-571] Rename staging file name with record count before movin…

…g to task output directory
Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[ ] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-571] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-571

Description

[ ] Here are some details about my PR, including screenshots (if applicable):

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:
Renaming /tmp/gobblin-kafka-streaming-vbohra/kafka-streaming-on-yarn/task-staging/KafkaHdfsStreamingTrackingOrcTest/job_KafkaHdfsStreamingTrackingOrcTest_1616125750983/PageViewEvent/GobblinYarnTaskRunner_380/hourly/2021/03/17/21/part.task_KafkaHdfsStreamingTrackingOrcTest_1616125750983_221_1616125834250_1.orc to /tmp/gobblin-kafka-streaming-vbohra/kafka-streaming-on-yarn/task-staging/KafkaHdfsStreamingTrackingOrcTest/job_KafkaHdfsStreamingTrackingOrcTest_1616125750983/PageViewEvent/GobblinYarnTaskRunner_380/hourly/2021/03/17/21/part.task_KafkaHdfsStreamingTrackingOrcTest_1616125750983_221_1616125834250_1.1552921.orc
Moving data from /tmp/gobblin-kafka-streaming-vbohra/kafka-streaming-on-yarn/task-staging/KafkaHdfsStreamingTrackingOrcTest/job_KafkaHdfsStreamingTrackingOrcTest_1616125750983/PageViewEvent/GobblinYarnTaskRunner_380/hourly/2021/03/17/21/part.task_KafkaHdfsStreamingTrackingOrcTest_1616125750983_221_1616125834250_1.1552921.orc to /tmp/gobblin-kafka-streaming-vbohra/kafka-streaming-on-yarn/task-output/KafkaHdfsStreamingTrackingOrcTest/job_KafkaHdfsStreamingTrackingOrcTest_1616125750983/221/PageViewEvent/hourly/2021/03/17/21/part.task_KafkaHdfsStreamingTrackingOrcTest_1616125750983_221_1616125834250_1.1552921.orc

Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Seems like it's linked to a wrong ticket?

Duplicate of https://github.com/apache/gobblin/pull/3251


nom: 2.4.0 -> 2.5.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/guyfedwards/nom/releases.
meta.description for nom is: RSS reader for the terminal
meta.homepage for nom is: https://github.com/guyfedwards/nom
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.5.0 in filename of file in /nix/store/vi5i2s84v1368qhcnmbccmmf81y2hi21-nom-2.5.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

nom

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vi5i2s84v1368qhcnmbccmmf81y2hi21-nom-2.5.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nom https://github.com/r-ryantm/nixpkgs/archive/900ad98d98ef554734d9c7d8afb3c2822e515e1d.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/900ad98d98ef554734d9c7d8afb3c2822e515e1d#nom

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vi5i2s84v1368qhcnmbccmmf81y2hi21-nom-2.5.0
ls -la /nix/store/vi5i2s84v1368qhcnmbccmmf81y2hi21-nom-2.5.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

nom

Maintainer pings
cc @nadir-ishiguro for testing.


Default to HTML comment when outside of Nunjucks snippets in Markdown files

When the extension is installed, hitting Ctrl + / will use {%%} for comment everywhere in an .md file. Ideally this should only happen inside a Nunjucks snippet.

@sghuang19 could you explain your use case a little more?  PR #18 changed the default behavior to what it is currently.
If you want HTML comments, you can always use Emmet to do this (which is the workaround)
I set this with the keyboard shortcut option+ctrl+/ you could set it to ctrl+/

Hi @edheltzel, thanks for getting back!

Emmet toggle comment only works in html files for me. Doesn't work in Markdown ( why ?)
I'm using your extension to have syntax highlighting for tags in blog posts I wrote using Hexo engine. It looks something like this:

Markdown goes here.

<!-- comments here in texts should look like this -->
{# but actually they look like this #}

{% note primary no-icon %}
A callout here
{% endnote %}

Markdown goes here

So ideally when commenting outside of a tag, HTML comment should be used.
More about my use cases:

https://theme-next.js.org/docs/tag-plugins/
https://hexo.io/docs/tag-plugins

I use Eleventy a lot, which is the whole reason this extension even exists – I'm not versed in Hexo, but I'll dig into it to make sure they aren't doing something that is missing or could add value.
As for the NJK comments verse, the HTML comments - Nunjucks will not render the comment in the final output. If that is not what you want, then HTML comments are the way to go by using Emmet. One of the main issues here is how Nunjucks doesn't have a different syntax for multiline comments... initially, Better Nunjucks used snippets to create NJK comments, but adding the support from PR #18 makes more sense going forward.
I do have it on my roadmap to include some VSCode setting options to enable this behavior by default or not, but don't hold your breath 😅

* Emmet toggle comment _only works in `html` files_ for me. Doesn't work in Markdown ( why ?)

Try adding this to your VSCode settings (also inside of the readme, closer to the bottom):
	"emmet.includeLanguages": {
		"markdown": "html",
		"nunjucks": "html",
	},
	"emmet.syntaxProfiles": {
		"markdown": "html",
		"nunjucks": "html",
	},


refactor location abstractions

motivation: reduce dependency on string location information, in support of registry based dependencies
changes:

add location information to PackageReference::Kind
seperare out sourceControl dependencies to local and remote, where remote carries AbsolutePath and rmeote carries URL
adjust call sites
adjust tests and test utilities

rdar://82954076

@mattt this is the second PR designed to help with landing SE-0292, I think I prefer to take this one even before #3698
wdyt?

@abertelrud @neonichu @elsh @yim-lee this PR includes refactoring we discussed several times with regards to how location is managed, and that is required to land SE-0292. its actually a pretty small change in the model itself but it has huge impact on call sites, especially in tests. given the large number of the lines changed, please focus on the core model changes which are highlighted in comments

@swift-ci please smoke test

@swift-ci please smoke test

What's the difference between fileSystem and localSourceControl? Do we do anything to ensure remoteSourceControl is indeed remote (e.g., what if URL scheme is file://?), or it doesn't matter?

this is exactly one of the goals of this PR, fileSystem is a local dependency that is not necessarily a git repo, while localSourceControl must be a git repo. with this distinction the downstream code is much safe. we do not validate the prefix for URLs put into remoteSourceControl, that is a good idea to add

@swift-ci please smoke test

@swift-ci please test package compatibility

@mattt this is the second PR designed to help with landing SE-0292, I think I prefer to take this one even before #3698. wdyt?

If #3698 is ready to go, I think it'd be great to lock in our gains with that. But you're closer to the source material and, so I defer to you on the best order of operations.


Add account to client API

@MrWildanMD thanks for your contribution! We have released this in v1.0.22


Trim trailing and preceding whitespace, and multiple spaces within card, list and board titles

Removing emoji will leave these.

Completing in #9


Issue using opsgenie-go-sdk with URL parameters.

The SDK uses a function to translate the request struct to URL Parameters, but those parameters are not aligned with the caps that the API requires.
For example the url parameter apiKey will become APIKey(which is based on the naming of the struct and not the naming of the JSON) - the result for that will be a request cannot have an empty apiKey value.

On get and delete requests, you need to use url key instead of json. Because those parameters should be added to url instead of json content.
APIKey field should be like the example below for get and delete requests:
APIKey string url:"apiKey,omitempty"``
I made the fixes on requests and client objects before merging your pull request. It works as expected now.


Improve README / documentation

Sorry for being a lame DAU but I followed your instructions to install shellcheck and your plugin into vscode. I also read about configuration options. But now? How to make actually use of your plugin? I open a bash script and nothing happens, no options for shellcheck in context menu and no warnings, just nothing.
Some screenshot how to use your plugin (at least if it actually does something) would be great.

I ran into the same issue after having installed both shellcheck and code via Ubuntu snap packages. Something about the snap confinement design prevents this extension from working in that configuration. Removing the code snap and installing as a regular system package fixed the issue.
It seems very similar/identical to this issue detailed in the snapcraft forums, for anyone else experiencing this. The explanation about the confinement context being the culprit is here.

@hohwille I agree.  Did you actually find how to invoke this extension on a shell script ?

I have the same issue. The only bash extension I have on vscode is this one, and I can't get it to work at all.

I'll add to the documentation:


Add a way to display multiple APIs together

Hello,
I would like to know if there is a way to display the docusaurus left sidebar.
Currently, using your plugin, I have a full page displaying the swagger doc :

But since I have a lot of microservices, I would like my user be able to access the left sidebar to choose the microservice he wants to view the API.

Overall, I'm looking an integration of redoc with the versionning and the page system of docusaurus.
I've seen that if I create an empty page that has the same URL than what I specified in the docusaurus.config.js file, redocusaurus has an higher priority than the empty page. So if I'm not wrong, I can simulate the versionning of the API using an empty page.
In the screenshot above, the link Processing > API > Overview is the empty page that has the same URL than what is in my conf. It works great so far.
Any help would be appreciated.

This seems like it would be difficult (or impossible to do). As the API docs are rendered as a single React component. We don't have the content of the sidebar to integrate with the Docusaurus sidebar.
You could create your own React component that wraps the @theme/Redoc component and add custom header navigation elements maybe? I think it will be difficult to merge complex sidebars

If you want to version your API then just have multiple YAML files, each for each version of your API

I have no idea how React component are rendered by docusaurus.
Maybe the page itself should have everything related to redoc so it renders the sidebar then as the main content it renders the redoc in the center of the page. Currently from the docusaurus.config.js file it's pretty impossible to do it
Yes, for versonned API I think the "fake page" is good enough, but I didn't try it

Maybe the page itself should have everything related to redoc so it renders the sidebar then as the main content it renders the redoc in the center of the page. Currently from the docusaurus.config.js file it's pretty impossible to do it

I don't think that would look good, but I'll keep the issue open if anyone wants to give this a try or to see if there is demand for this.

How would you display 10 microservices API, if you don't have a sidebar ?
If there is another way, I'm open to that. :)

How would you display 10 microservices API, if you don't have a sidebar ?

Sidebar is a good idea, but not a nested sidebar because redoc would have it's own sidebar. Maybe a dropdown would look better, below the header?

Either a dropdown or a line bar with all microservice API next to each other

Have there been any progress on this? Looking to document 8 different microservices each with their own endpoint.

How about just adding a dropdown to the navbar (navbar-dropdowns) and grouping all the docs there?

Really nice example I like that. The way I had it working right now was:

Create a file with x-tagGroups and then (https://redoc.ly/docs/api-reference-docs/specification-extensions/x-tag-groups/)
Merge all files with  https://www.npmjs.com/package/openapi-merge

But I like your example solution more. Will do that instead

Your solution does not fit on my layout. I have already too much content on the navbar...

Will try to develop something appropriate when I get some spare time. (with versionning, which matters for us)

I've created a new React component that I use to display the documentation with double sidebars :

Ok, on small screens it would be hard to use. Maybe I can tweak the theme, when #129 is deployed, to make it more attractive, as the center does not have much space on 22" screens.
As I'm using mdx file to run redoc and not the specs parameter inside docusaurus.config.js file, my API is versionned :tada: .

As I'm using mdx file to run redoc and not the specs parameter inside docusaurus.config.js file, my API is versionned 🎉 .

That is genius!! 🎉

Ok, on small screens it would be hard to use.

You can modify the breakpoints in the theme to keep the view always single pane? That sounds like a good compromise

That is genius!! :tada:

Thanks !

You can modify the breakpoints in the theme to keep the view always single pane?

Which property are you talking about ?
I'm going to make two more PR : the component that I use to make it possible, as it can be stored on your theme package
And add https://github.com/RegardsOss/RegardsOss.github.io as user of your lib

You can modify the breakpoints in the theme to keep the view always single pane?

Which property are you talking about ?

https://github.com/Redocly/redoc#redoc-theme-object -> breakpoints

breakpoints # breakpoints for switching three/two and mobile view layouts
small: '50rem'
medium: '85rem'
large: '105rem'

We can force the 2 pane view with this I think (moves examples/code-samples below schema).

And add RegardsOss/RegardsOss.github.io as user of your lib

Would be great!

We can force the 2 pane view with this I think (moves examples/code-samples below schema).

It works great ! Thanks

This is now possible to do with a new ApiDocMdx component in v1.1.0. See the new doc here: https://redocusaurus.vercel.app/docs/guides/multiple-apis
And example here: https://redocusaurus.vercel.app/docs/nested/nested-1

This was done thanks to the ideas from the community! Pretty cool to see all the different usages in the wild.
Thanks to @serut for the initial request and work. And this MDX example with existing components by @TheCatLady here: https://github.com/someengineering/resoto.com/blob/7494b135d87533e54372e2f632f570dab3d06d6d/docs/reference/api.md


Honor HTML links in popups

This is an enhancement request to support HTML links in the popup description. The use case is: I want to use AuGeo to find an asset, and then launch Survey123 to log an activity or inspection for that asset. Ideally, I would like to use Survey123's custom URL Scheme as described here: https://community.esri.com/groups/survey123/blog/2016/07/30/understanding-survey123s-custom-url-scheme
Stakeholder: Clive Reece (Esri). Dakota DOT.

Internal issue opened: https://devtopia.esri.com/Melbourne/Horizon/issues/191


[0.0.100] SPA routing where both current and navigated route have use-client-effect results in error

Qwik Version
0.0.100
Operating System (or Browser)
Fedora 37, Firefox 103
Node Version (if applicable)
16.14.0
Which component is affected?
Qwik Runtime
Expected Behaviour
Routing from page A which uses useClientEffect$ to page B which also uses useClientEffect$ should work without issues.
 TypeError: Failed to execute 'observe' on 'IntersectionObserver': parameter 1 is not of type 'Element'.
    at useClientEffectQrl (http://localhost:5173/node_modules/@builder.io/qwik/core.mjs?v=dabcc8fd:3382:23)
    at routes_component_buH6QBbKJm4 (http://localhost:5173/src/routes_component_buh6qbbkjm4.js?t=1660834678176:10:5)
    at useInvoke (http://localhost:5173/node_modules/@builder.io/qwik/core.mjs?v=dabcc8fd:137:26)
    at http://localhost:5173/node_modules/@builder.io/qwik/core.mjs?v=dabcc8fd:4664:28
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at async renderMarked (http://localhost:5173/node_modules/@builder.io/qwik/core.mjs?v=dabcc8fd:2239:17)

Additional Information
Occurs only in SPA routing using Link component.

Seems like it. Somehow search didn't yield that issue.


isolating validation module

We need to separate the validation module and sdx-lc from the docker container.

Validation module is a Python module working separately from Kytos Napp. Changes are merged with pull request #29.


fix coveralls

Coverage remained the same at 92.843% when pulling 8f153be07d03f5af9ae99533d32e7fdf6d96227f on coveralls into 09f5f7d37fa30c7f491a4199fb3201e6e6679f2f on master.


feat: Add Cl.parse Clarity value parser

This PR was published to npm with the version 6.15.0
e.g. npm install<EMAIL_ADDRESS>--save-exact

Adds Cl.parse, which allows us to parse clarity syntax as JS representation ClarityValue.
Renames prettyPrint to stringify (matching JSON. more closely in naming) got feedback from users that they were expecting prettyPrint to console.log and they were confused that there wasn't any output.

Examples
Cl.parse(`"my string"`);
Cl.parse('-4');
Cl.parse('u5');
Cl.parse('false');
Cl.parse('{ a: 3 }');
Cl.parse('(list 1 2 3)');

I tried it and found this use case that throws a parse error:
{ a: 0x68656c6c6f21 }

@hugocaillard  Good catch, noticed that nested values will be tricky with overlaps. I thought the entire combinator solved this, but that's not used for the nested values.. 🙃 -- updated the order to fix this case, there might be more though..
In this case it was detecting the 0x.. as 0 matches an int, and will continue instead of trying other cl-values.


Add sed rule for export keyword

I think your patch is too complicated, but I get your point.

yes surely too complicated.
sed it's not my best friend but still usefull ^^

Is https://github.com/Anvil/bash-doxygen/commit/cc13845afb847d087199b3c4cc7495403aff0310 okay with you ?

Yes

Ack ! Thank you. Good day !


NIFI-5900 Added StreamingJsonReader.

Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically master)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

@markap14 @mattyb149 @ijokarumawak @zenfenan @ottobackwards
We got a file format that looks roughly like this:
{
   "something": "something",
   "massive_list": [ 9GB later... ]
}

Tested this on a 25GB JSON file, and ConvertRecord was able to stream through it and make a 16GB Avro file.

I don't see how you avoid reading that all into memory because you have to return a Record instance from the reader with all that data in it.

Our use case has someone throwing a 10GB file with that structure, so JsonTreeReader would have to have a schema reference to the massive array and load it all at once. What this does it uses a streaing JsonPath parser to go directly to the array and pull each element one by one and expose them to the reader.
As I understand it, JsonTreeReader can only handle such a large file if it contains only an array of elements or the elements stacked on each other. If the NiFi user has to drill into the document at all, they're out of luck.

@MikeThomsen are you saying that your 25GB JSON file got an OOM (or some error) when using ConvertRecord with JsonTreeReader?

Yeah, in fact I got it with this processor when I used $.massive_list and not $.massive_list[*] hence the check to make sure that the result evaluated to an "object" node :-D

Thanks for clarifying, I originally missed how json path was being used here and I can now see how this is different. Both of the existing json readers are going node by node from the top level, where as this lets you directly target something nested and start iterating from there as if it was the top-level.

So, the issue is the jsonPath, not the tree node reader.  As we have discussed in NIFI-3126.  I didn't do the POC on jsonSurfer because the work around seemed to be what we wanted at the time.
I think this is a good idea like, although it has to be clear what it's use case is.
The first question I have after a quick glance is how much of this code for producing the record from json is common between our json readers?   If we have multiple readers with copies of the same json->record code, we should consolidate them into a single code path.
Also, should the documentation of the existing readers be updated to point people with the use case in the right direction?
Can you confirm which reader you had the issue with?  Was it the JsonPathReader?

This also feels like we are sticking our fingers in the dyke a little.
The SplitJSON processor -> has this issue
The JsonPathReader -> has this issue
The JsonTreeReader -> ???  Is this pr about this reader?
We might want to think about fixing this consistently across the processors and readers we have.

@ottobackwards we definitely should refactor the readers at some point to use common code. Problem I ran into is that the existing ones are using Jackson 1.9.X and JsonSurfer uses 2.9.X. So it was a lot of renaming in Jackson that made it impossible for me to do that while avoiding scope creep for the ticket.

@MikeThomsen what reader were you using when you had the issue?

Maybe you can open a ticket for the Jackson upgrade

I was vaguely tracking the SplitJson issue, so I knew about the issue before even starting on the work.

I do agree that we should refactor such that we don't have so much duplication in the conversion from JsonNode to Record. I also think that we need to be careful on naming. StreamingJsonReader may be accurate, but the Json Tree Reader and the Json Path Reader are also both streaming readers - they stream in only a single Record at a time. We should also highlight the difference more, IMO. Perhaps provide an additionalDetails.html that discusses when to use this Reader vs. Json Path Reader or Json Tree Reader

@markap14 agreed, also, this reader, as @MikeThomsen  points out has a somewhat specialized use case, and cases where you wouldn't want to use it.  It may need a more specific name.

@markap14 I can rename it to StreamingJsonPathReader. Does that work?

Have you looked at changing the jsonpath record reader to use jsonSurfer?  is there a backwards compatible way to switch to the iterator?

I don't think there is because the Jayway jsonpath library reads the entire InputStream into memory before doing anything with it. JsonSurfer uses an InputStream here and scans start to finish.

I mean can the JsonSurfer replace the Jayway in that class?

@markap14 @bbende would you rather I refactor the JsonTreeReader to use the JsonSurfer library or keep this one separate?


Different numbers of # Epoch in output files

Dear developers,
I found the epoch numbers in the output files are different in one training loop.

Is that normal and why does this happen ?
Thanks.
Sean

Hi @seanwong16 ,
Those epoch numbers are strange... can you elaborate on what you mean by "different in one training loop", and on what your setup us here?

This looks like a filesystem issue with things writing at different times? Can you repro?

Closing.


Add support for VNC specific passwords

Any thoughts on adding support for a separate VNC specific password?
I ran into an issue where my AMT password did not meet the RFBPassword / VNC password requirements because it was > 8 characters.
Maybe prompt the user when enabling KVM/VNC and update hosts.cfg?
Let me know if this sounds reasonable and I'll submit a PR to add this functionality.

A separate password for VNC would be great.
How about add a flag to the enable vnc sub command that will trigger the prompt, so it's optional.

A separate password for VNC would be great.

Cool, I'll take a stab at this.

How about add a flag to the enable vnc sub command that will trigger the prompt, so it's optional.

Parsing an additional flag for a possible VNC password might get a little bit awkward because the "op" (on|off|reboot|pxeboot|status|vnc|vncstatus) is not a sub-command.
Do you mind if I get a separate PR going to modify the argparse config to include sub-commands?
Also, thanks for writing amt! I just got a vPRO enabled NUC and this utility is a life saver.


nvidiaLegacy390 Needed

Issue description
Looks my graphics card (Nvidia GeForce GTX 560 Ti) has been moved to legacy status. However, the 390.xx legacy drivers are not available on NixOS yet:

Steps to reproduce
Technical details

system: "x86_64-linux"
host os: Linux 4.19.0, NixOS, 19.03pre156996.c70ad805d21 (Koi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.1.3
channels(root): "nixos-19.03pre156996.c70ad805d21"
channels(bill): ""
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

I have the same Problem as described in this issue, but simply adding
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.stable_390;

to my configuration.nix  yields following error:
error: The option `hardware.nvidia.package' defined in `/etc/nixos/configuration.nix' does not exist.

I need more Information to set this up correctly. Can anybody help me?

Mind trying #51294 using nvidiaLegacy390 in videoDrivers though FRidh's solution should work.

I haven't done any development on nixos before, how would I test this?

You can build packages from the repository by using the -I parameter:
$ cd nixpkgs
$ nix-build -I nixpkgs=$(realpath .) -A linuxPackages.nvidia_x11_legacy304
$ sudo nixos-rebuild switch -I nixpkgs=$(realpath .)

For more ad-hoc questions, you can also join IRC.

According to the manual the following would load other nvidia packages:
services.xserver.videoDrivers = [ "nvidiaLegacy340" ];
services.xserver.videoDrivers = [ "nvidiaLegacy304" ];

https://nixos.org/nixos/manual/#sec-x11-graphics-cards-nvidia

@Mic92 Thank you for your help!
I have successfully built the package, installed, and loaded nvidiaLegacy390 via configuration.nix, and can confirm that #51294 do indeed solve my problem.