Prevent session file deletions on app delete

If the application is delete, all our logs, such as session data as well as app logs themselves get deleted. To mitigate this, we need to create a folder elsewhere in the OS to ensure that the folder does not get deleted.
Most likely needs to change the directory we use: https://github.com/itinance/react-native-fs#constants

This requires requesting permissions to write to external storage - please see https://reactnative.dev/docs/permissionsandroid#request.
We will need to update logic to abstract out our logging mechanism to only run once the folders have been created via promises or async/await

Leaving app logs where they are for now, will create new issue if it is ever worked on.


method for adding embedings to hidden layers while training

is there a way to add input embeddings to BLSTM hidden layers.

in the tensorflow framework, this should be very easy. in the c++ framework, i don't think there is an easy way to do this.


added Footer to Model, AboutUs, DemoSection pages

All links are responsive and the color is quite matching.

Please mention the issue number that it resolves


add node-red output

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area config

/area outputs

/area tests

What this PR does / why we need it:
Add Node-RED as output
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 16e0cf8bf0ff50206c614f0aa37a356162cf7f76

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fjogeleit, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif,fjogeleit]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Type 'string' is not assignable to type '"UnexpectedEof"'.

Installing vno with the latest version of deno v1.13.0, this error occurs:

Seems to be isolated to deno v1.13.0. Working with deno v1.13.1+.


How to load data in Simple training pipeline example!!

What kind of data we need to put.
When I load list of images using cv2.imread() function.
Its gives Error!!

I was also interested in getting some sort of example running but was also having issues figuring out the proper format for the input images


How to play first song when AudioListsChange

Description
After I clear the AudioList and set a new AudioList. This doesn't automatically play the first song. Is there a way to do it? Thank you.

You can try this
<ReactJkMusicPlayer autoPlayInitLoadPlayList  clearPriorAudioLists />


Prepare FOLIO for larger data loads during data migration

@jwfuller looking at Jason Root's checklist that he shared on the slack kubernetes channel. Think there's a lot of useful stuff here. Beefing up the inventory modules makes sense and argues for more headroom in the cluster. Seems relevant in light of #60.

These are the container settings we are using in Honeysuckle environments to support data import loads of 5000 records. Note that as of Honeysuckle, my understanding is that data import files any larger than that are not supported, and in fact I think the recommendation from the development team was more like 3000 records in a file -- but we found we could push it to 5000 with these settings.
Our approach is, I think, much more conservative than Jason's "just triple it all"
(not to say that's not valid!)
mod-inventory: 3 replicas, memory limit of<PHONE_NUMBER> (default is 715827883)
mod-inventory-storage: 3 replicas
mod-pubsub: memory limit of<PHONE_NUMBER> (default is<PHONE_NUMBER>)
mod-source-record-manager: 3 replicas
mod-source-record-storage: 3 replicas, memory limit of<PHONE_NUMBER> (default is 603725575)
For all other modules, we are running with 1 replica and the default memory allocation. We do not have CPU limits set (and have so far not seen modules run away with CPU) -- in our experience memory consumption is the primary driver for needing to increase the size of our worker node pool, not compute.
You may ask, "why just one replica as a rule?" I think that's a reasonable question. Our experience is that when a module "goes down," it more often than not hangs rather than dying, and so does not get restarted. If the module is clustered, that can make diagnosis of a problem harder, as the unresponsive module instance may be masked by the other live instances. Of course you can change the behavior of the container orchestration system to institute API-specific liveness probes and restart a module instance when it becomes unresponsive, but our current strategy is to prioritize capturing a module in an unresponsive state in order to troubleshoot and file a bug over just keeping the system up and running. I expect as FOLIO matures we will change that priority.

All the things to be sure are set and done before we migrate:
1.) All modules and DBs spun down
2.) Okapi DB cleared, okapi_modules DB cleared, Kafka DB cleared
3.) DBs spun up
4.) Edit Folio DB postgresql.conf to increase max worker processes, effective cache size and max wal size
5.) All modules and Okapi spun up except mod-data-migration, mod-ldp, LDP crons, and mod-spine-o-matic
6.) Tamu and Diku tenants created
7.) Tamu and Diku module deployment for tenants
8.) tamu_admin, backup_admin and diku_admin superusers created
9.) Tenant admin passwords changed
10.) System Admin user groups created and tenant admin users assigned
11.) Diku tenant locations/institutions and etc removed from Tamu instance
12.) All Permissions set created with all perms visible and hidden (except SYS and most Okapi perms) and assigned to tenant admin users
13.) Usernames, emails, patron group assignments, removal of service points - all updated for tenant admin users and Folio "system users"
14.) Set tenant timezone and plugins
15.) mod-circulation-notimers enabled for Tamu tenant
16.) Backup Folio modules DB for easy roll-back
17.) Okapi and Folio modules scaled out to 5 for those APIs being heavily utilized during the migration
Post Migration:
1.) Set back DB max wal size and timeout to 4GB and 5min respectively, set work/temp/maint mem levels back to 128MB
2.) Create the edge user - assign migrated edgeuser perm set
3.) Create the vufind user - assign migrated vufind perm set
4.) Deploy K8s Job to create tenant configs for Folio email system and self-checkout
5.) Re-enable mod-circulation with timers
6.) Spin back up mod-spine-o-matic
7.) Un-suspend Divit import users, LDP data update and age-to-lost K8s crons
8.) Check and set tenant timezone and plugin settings
9.) Enable SSO for tamu tenant
10.) Scale backend modules to normal levels
11.) Create and re-index Elastic Search for the mod-search instances
12.) Run https://github.com/folio-org/mod-inventory-storage/blob/master/src/main/resources/templates/db_scripts/populatePublicationPeriod.sql from within DB

See also https://github.com/culibraries/folio/issues/2#issuecomment-963518678

See this as well: https://wiki.folio.org/pages/viewpage.action?pageId=79471347

Looking at the current https://lib-rancher.colorado.edu/ instance, this is the module pod instance count:

mod-inventory 1
mod-inventory-storage 2
mod-source-record-storage 2
mod-source-record-manager 2

I think we where running 3 inventory pods but scaled down to one to try and diagnosis the issue with searching.

Closing out with #161. @jwfuller note that I am currently scaling pods manually with kubectl scale deployment <DEPLOYMENT NAME> --replicas=<#PODS> until we have a better feel for what kind of scaling params we want. Maybe we should always do it this way. It's painless and appears to survive pulumi redeploying the containers. In any case it is analogous to what we were doing with rancher without the rancher hassle.


View Spot and View Code Viewers

Green borders in these viewers are not working well.

Reilly suggests green borders on the predicted round/channel for that dye, with thickness indicating the expected intensity. Like you say, for dyes that are spread a lot between channels, we may have more than 1 green border within a round.


Adding extra check for Centos 6.10 for cmake version

Just use cmake for everything. Don't bother with cmake3. We are forcing people to install a newer cmake.

Okay. I'll edit the PR


[GSSoC'23] Space News AI Model using PYTHON

Aim

What is the objective of the Script

To learn about solar system
To get update about the research of different organization like NASA, ISRO, etc.
Even not the children, we all will boost our knowledge and get update with these dataset.

Details

What the features will your script have

To get detailed knowledge of solar bodies like mass, diameter, speed, etc.
To learn different moments of asteroids, stars, etc.
To see the picture captured by space ships
Get detailed knowledge of research photos, papers, etc done by space scientist.

Do I want to work on this:

[x]  Yes

@omazoz @avinashkranjan @vanshitaverma please assign this project to me to work under GSSoC'23 open source program


Close TCP connections at disconnect

Also set GOMAXPROCS to runtime CPU count.
Signed-off-by: Dong Chen<EMAIL_ADDRESS>

This is part of fix for #1838.

FYI, in Go >1.5 GOMAXPROCS is set to number of CPU cores by default: https://golang.org/doc/go1.5#runtime

LGTM

LGTM

Btw this test is failing across several PRs (including this one), not sure why:
not ok 155 mesos - docker build
# (from function `retry' in file mesos/api/../../helpers.bash, line 80,
#  from function `discovery_check_swarm_info' in file mesos/api/../../helpers.bash, line 95,
#  from function `swarm_manage' in file mesos/api/../../helpers.bash, line 110,
#  in test file mesos/api/build.bats, line 15)
#   `swarm_manage --cluster-driver mesos-experimental <IP_ADDRESS>:$MESOS_MASTER_PORT' failed
# Unable to find image 'dockerswarm/mesos:0.26.0' locally
# 0.26.0: Pulling from dockerswarm/mesos
# efb8479c8773: Pulling fs layer
# ac4e6f37f1e0: Pulling fs layer
# 9bb3720f3761: Pulling fs layer

Cannot reproduce it locally. I'll monitor it.


feat: include secrets manager and certificate generation

Description
Include modules for automatic generation of private certificate for vpn :

module_secrets_manager_group
module_secrets_manager_private_certificate
module_private_secret_engine

Release required?

[ ] No release
[ ] Patch release (x.x.X)
[x] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 5.1.0 :tada:
The release is available on:

GitHub release
v5.1.0

Your semantic-release bot :package::rocket:


[AUTOMATIC] Contribute: content/openpr

🐧 Ubunchuu Contribute Request

❓ What type of PR is this? (check all applicable)

[ ] 📝 Content - Documentation Update
[ ] 📝 Content - Blog Update
[ ] 🎨 Style (UI/UX)
[ ] 🍕 Feature
[ ] 🪲 Bug Fix
[ ] 🤖 DevOps
[ ] 🧑💻 Code Refactor

📝 Description for my changes

Please clear this section and include a very short summary of the change (3 lines maximum)

📌 Related Issues

❗MANDATORY❗

Please clear this section and note that any changes to the codebase should have a related issue to provide context for the changes.

🖥 Mobile/Desktop Screenshots (optinal)

If applicable, add screenshots to help explain your changes.

Please clear this whole section if not applicable.

Test server functionality passed ✅ with total CI time: 98 seconds


crossbeam-channel deadlock when used in separate dlls

Waiting on the receive of a channel in a dynamically loaded library deadlocks.
Minimum reproducible example: git repo
Things I have confirmed:

park/unpark work correctly between dll's
send/recv work correctly within the process (without the external dll)
the standard channel (std::sync::mspc) works correctly
this deadlock occurs in both the latest release (0.3.9) as well as the master

Do your library / dll use future or async features? I've heard of several reports where using crossbeam-beam's channel in poll will cause deadlock.

It doesn't use those features directly.
This is the entire dll code
#[no_mangle]
pub fn start(receiver: crossbeam_channel::Receiver<i32>) -> std::thread::JoinHandle<()> {
    std::thread::spawn(move || {
        println!("{:?}", receiver.recv());
    })
}

I simply load the dll using libloading, and call the start function passing it a channel to listen to.

@Visic Do you think this could have something to do with the initialization of TLS when the DLL is loaded?

It doesn't seem to be the TLS, I tried hacking away at the crossbeam channel code to remove it all and the deadlock still occurred. I may have broken some logic in the process and introduced a look-a-like bug, but it doesn't seem like it.
After a bit of debugging, it seems like it is getting stuck in the context.rs file, specifically "thread::park()" on line 175. Commenting that out just causes an infinite loop because the "Selected" on line 156 is always "Waiting".


fix(message-input): DLT-1714 limit file type on image picker

fix(message-input): DLT-1714 limit file type on image picker

Obligatory GIF (super important!)

:hammer_and_wrench: Type Of Change

These types will increment the version number on release:

[x] Fix

:book: Jira Ticket
https://dialpad.atlassian.net/browse/DLT-1714

:book: Description
This pr adds accept parameter for the input on the message_input component so we can limit the file types the file input should accept. Documentation: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file#accept
:bulb: Context
Currently, on Dialpad app we only allow sending images and videos, no PDFs or other file types. Also as the icon is an Image I think is correct to limit it to only allow images and videos.

:pencil: Checklist

For all PRs:

[x] I have ensured no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
[x] I have reviewed my changes.
[x] I have added all relevant documentation.
[x] I have considered the performance impact of my change.

I guess you will still need to do a validation product-side to avoid the files being added, as this only sets the default options but that can be changed, I don't know if there's a way to limit that on this component, anyways the behavior on multiple operating systems would differ, so this will still need to be done product-side.
On this component
https://github.com/dialpad/dialtone/assets/87546543/39aa1cdd-de8c-4ccc-8b9e-0c960c199378
Currently on product
https://github.com/dialpad/dialtone/assets/87546543/aa9225f6-3392-4b6c-be3d-f5b55fdf6552

Yes, good catch. We have a function that makes that work: https://github.com/dialpad/firespotter/blob/64185a62eaeb56cf645f8bc66c6fd404c1b56b84/ubervoice/static/js/vue_mixins/files_mixin.js#L32-L36
Thank you!


[libflac] update to 1.4.2

Library name: libflac
New version number: 1.4.2
Current version is 1.3.4. Here are the release notes of the last releases:
https://github.com/xiph/flac/releases

The libflac version has been updated to 1.4.2. See https://github.com/microsoft/vcpkg/pull/29584 for details


Support read_parquet for data with overlapping partition columns and file columns

As discussed in #7512, some systems may generate partitioned parquet datasets with the partitioned column also included in the file.  This PR adds support for this situation, as long as all partitioned-on columns are included in the file.
Please feel free to raise concerns if there are real use cases where an "all-or-nothing" approach will fail (the alternative is doable, but requires a bit more work).

E   AssertionError: DataFrame.iloc[:, 1] (column name="a") are different
E
E   DataFrame.iloc[:, 1] (column name="a") values are different (5.0 %)
E   [index]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99]
E   [left]:  [A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D]
E   [right]: [A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, D, D, A, B, D, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, None, D, A, B, None, D, A, B, None, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D, A, B, C, D]

pandas/_libs/testing.pyx:182: AssertionError

Ah I see it passed CI now. Merging (but let's keep an eye out in case that test_create_metadata_file is a flaky test).

Thanks Julia!  I agree that we should keep an eye on that tests.  I have seen it fail recently in another PR :/


panda query engine regex

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of Change
Please delete options that are not relevant.

[X] 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)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Added new unit/integration tests
[ ] Added new notebook (that tests end-to-end)
[X] I stared at the code and made sure it makes sense

Suggested Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I ran make format; make lint to appease the lint gods

@bogdanalexandrutreica apologies, with v0.10.0 the project structure has changed slightly
I can take a stab at porting this PR in a bit, if you don't get to it first :) (in addition to any improvements the others have mentioned)

Going to close this one out for now, its quite outdated at this point
If its still an issue, please raise an updated PR
Sorry for letting this one sit for so long!


fix: upgrade Grafana stack

Upgrade the following charts:
loki-distributed
Current version: 0.69.16
New version: 0.79.4
promtail
Current version: 6.11.2
New version: 6.16.6
tempo-distributed
Current version: 1.4.2
New version: 1.18.5
Bug fixes

Istio Sidecar for team observability (Grafana and Alertmanager)

Checklist

[ ] Architecture Design Records have been added as adr/*.md and appended to list in adr/_index.md, if applicable.
[ ] The values-schema.yaml file and test/** fixtures have been updated to reflect code changes, if applicable.
[ ] The OpenApi Schema from redkubes/otomi-api project is compatible with definitions from values-schema.yaml file, if applicable.
[ ] Helm releases are meeting otomi's baseline security policies, if applicable.
[x] Helm chart and helmfile changes are tested against upgrade scenario, if applicable.

Not sure what it is yet, but I am getting a 503 on the team Grafana instance.


Only trigger MyFox alarm when it is armed

Fixes #258

Confirmed working by @PoVPoV29, good to merge now.


No Documentation about unsupported Triggers in API Pages

There is no documentation which Triggers are not supported on Pages with "PageType = API".

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: df0e36d7-395e-ed94-2e77-f7edb74e7757
Version Independent ID: 1f838a73-fefc-8fbd-bcb9-cc9ad899dbdd
Content: Page and Action Triggers - Business Central
Content Source: dev-itpro/developer/triggers/devenv-page-and-action-triggers.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: solsen

Thanks for the feedback. We have, since you filed this issue, been able to auto-generate the triggers from source code that are available in AL. These are grouped by object that they support. We do not have a more granular description than this. For the overview, please see https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/triggers-auto/devenv-triggers. I suggest that for pages of the API type, you use IntelliSense to look up which ones are available.


[stable/prometheus-operator] Introduce crds directory for compatibility with Helm v3

What this PR does / why we need it:

This adds crds directory which has all 5 CRDs
As files from crds directory needs to be plain YAMLs, keeps app: prometheus-operator label and removes all the templating
With this change .Values.prometheusOperator.createCustomResource will be ignored by Helm v3 as it handles the CRDs differently. Which means, if the CRDs already present in the cluster then it won't touch them at all
Helm v3 ignores the CustomResourceDefinition objects which are present in templates directory. (At least I wasn't able to find any CRD YAML when I ran helm install ... --debug)
Update the README.md
Update the chart version

Special notes for your reviewer:

This PR does not do the complete migration of this chart to v2 apiVersion of Chart.yaml. This adds changes which ensure that the current chart is installable with Helm v3 as well.

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

I wonder if we can just load the files from the directory and apply them using a list.
Not sure if that would break the CRD install hooks checking for CRDs being established in Helm 2 or break upgrading the chart. Would you be interested in checking this out?

Yeah, that's an interesting idea. Thanks, let me try that out.

I deleted the crd-*.yaml files from templates/prometheus-operator and created a crds.yaml in same directory. Also added crd-install hook to files from crds directory. Helm v3 does not take any special action on the YAML if we have the crd-install annotation.

With List approach: (creating the List object out of files from crds directory at top level)# templates/prometheus-operator/crds.yaml
apiVersion: v1
kind: List
items:
{{- range $path, $bytes := .Files.Glob "crds/*.yaml" }}
- {{ $.Files.Get $path | nindent 2 }}
{{- end }}

Helm v2: fails to install as well upgrade existing chart. Basically it does not consider the crd-install hook from items: section of List object.
Helm v3: fails with the error that the CRDs already exist. Reason is same as above. Does not consider the hook which prevents it from ignoring those objects.

With separate document approach: (creating one file with all the CRD objects separated by ---)# templates/prometheus-operator/crds.yaml
{{- range $path, $bytes := .Files.Glob "crds/*.yaml" }}
{{ $.Files.Get $path }}
---
{{- end }}

Helm v2: new installation works, CRDs are installed first. Upgrade from previous installation works as well.
Helm v3: install as well as upgrade works just fine. Objects from crds.yaml are ingored as they have crd-install hook in them.

@vsliouniaev what do you think, should we go with the second approach?

@bhavin192 thanks for checking this one out. I think that option #2 sounds like it should be the best option.

@vsliouniaev I made the changes according to the second option, please take a look whenever you are around :)

/lgtm
Looks like it's working!


The get_template() example doesn't seem to match the API

See https://jinja.palletsprojects.com/en/3.1.x/templates/#template-objects This example doesn't seem to align with https://jinja.palletsprojects.com/en/3.1.x/api/#jinja2.Environment.get_template.
I think the example needs to be fixed to properly reflect the API.
Environment:

Python version: 3.10.4
Jinja version: 3.1.2

Ah, I wrote get_template instead of render_template on the last line.


add blogs

Signed-off-by: Bill Mulligan<EMAIL_ADDRESS>

@xmulligan could you add an image for the delve one? At least the preview is not showing one.