How to get info for specific culture formats when  true is used?

How to get info for specific culture formats when set InvariantGlobalization true is used?
.NET 5.0.100-preview.7.20366.6 WINDOWS
We need to parse dates and numbers from input strings that along specify the culture to parse in.
But we are running the API with  true  setting and we always get Invariant format example MM/dd/yyyy
for CultureInfo.CreateSpecificCulture("de-DE").DateTimeFormat.ShortDatePattern

As I understand it, you can't. The Globalization Invariant Mode is meant for the cases where you don't need to do culture-dependent operations. But you do, so you should disable that mode. For more details, have a look at the documentation.

@GrabYourPitchforks can you please help with this?

@svick's earlier comment is correct and provides links to more info. The solution is to disable the invariant globalization mode if the app requires access to culture-specific behavior. I'll close this issue for now, but if I missed something please feel free to reopen. Thanks!


Missing redirectUri param in reset password

When attempting to add a redirectUri from the ResetPasswordPage, it has been observed that there is currently no provision to pass the redirectUri parameter through the /auth/resetpassword API.
To enhance the /auth/resetpassword API functionality by introducing support for the redirectUri parameter, allowing for dynamic redirection after the password reset process.

Fixed with https://github.com/medplum/medplum/pull/3600
Thanks @ravindra-tc !


[vendor-change] dep init + prune changes for 0.8 + destination Name->Host (v1alpha3)

test PR for #4482

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: wattli
Assign the PR to them by writing /assign @wattli in a comment when ready.
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

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

matching vendor PR https://github.com/istio/vendor-istio/pull/45

@ldemailly: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
17a5e85c5cb35dc3a39ae691bd5df46e2cab649e
link
/test istio-unit-tests

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
17a5e85c5cb35dc3a39ae691bd5df46e2cab649e
link
/test istio-unit-tests

prow/istio-presubmit.sh
17a5e85c5cb35dc3a39ae691bd5df46e2cab649e
link
/test istio-presubmit

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
17a5e85c5cb35dc3a39ae691bd5df46e2cab649e
link
/test istio-presubmit

prow/istio-unit-tests.sh
b65fe42deefe42ca637cb107493804e59cf488c6
link
/test istio-unit-tests

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
b65fe42deefe42ca637cb107493804e59cf488c6
link
/test istio-unit-tests

prow/istio-presubmit.sh
b65fe42deefe42ca637cb107493804e59cf488c6
link
/test istio-presubmit

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
b65fe42deefe42ca637cb107493804e59cf488c6
link
/test istio-presubmit

prow/istio-unit-tests.sh
115515cac74ba95906a80e4170d041a5d891ed1b
link
/test istio-unit-tests

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
115515cac74ba95906a80e4170d041a5d891ed1b
link
/test istio-unit-tests

prow/istio-presubmit.sh
115515cac74ba95906a80e4170d041a5d891ed1b
link
/test istio-presubmit

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
115515cac74ba95906a80e4170d041a5d891ed1b
link
/test istio-presubmit

prow/istio-unit-tests.sh
0b19d496a62a3fe564381aefd66a8deb2d7deb1c
link
/test istio-unit-tests

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
0b19d496a62a3fe564381aefd66a8deb2d7deb1c
link
/test istio-unit-tests

prow/istio-presubmit.sh
0b19d496a62a3fe564381aefd66a8deb2d7deb1c
link
/test istio-presubmit

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

bin/gobuild.sh /Users/ldemailly/go/out/darwin_amd64/release/sidecar-injector istio.io/istio/pkg/version ./pilot/cmd/sidecar-injector
# istio.io/istio/vendor/k8s.io/kubernetes/pkg/util/parsers
vendor/k8s.io/kubernetes/pkg/util/parsers/parsers.go:36:16: undefined: reference.ParseNormalizedNamed

probably means I have the wrong github.com/docker/distribution/reference

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
0b19d496a62a3fe564381aefd66a8deb2d7deb1c
link
/test istio-presubmit

prow/istio-unit-tests.sh
748b908321bd7bae47eded16c0ccd3c09c2999f0
link
/test istio-unit-tests

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
748b908321bd7bae47eded16c0ccd3c09c2999f0
link
/test istio-unit-tests

prow/istio-presubmit.sh
748b908321bd7bae47eded16c0ccd3c09c2999f0
link
/test istio-presubmit

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
748b908321bd7bae47eded16c0ccd3c09c2999f0
link
/test istio-presubmit

prow/istio-unit-tests.sh
783e08101ba58b844afe170c6db6d98289cd03cb
link
/test istio-unit-tests

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

going to let someone from pilot fix this

@ldemailly: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
0c8a26e1c83bc385f3aea186429acc0b1d770d30
link
/test istio-presubmit

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

@ldemailly: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
0c8a26e1c83bc385f3aea186429acc0b1d770d30
link
/test istio-presubmit

prow/istio-unit-tests.sh
0c8a26e1c83bc385f3aea186429acc0b1d770d30
link
/test istio-unit-tests

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

/lgtm
/approve

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: kyessenov
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: wattli
Assign the PR to them by writing /assign @wattli in a comment when ready.
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

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

New changes are detected. LGTM label has been removed.

mixer failure is unrelated readiness issue
prow is overloaded
will merge

/lgtm
/approve

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: kyessenov
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: wattli
Assign the PR to them by writing /assign @wattli in a comment when ready.
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

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

@ldemailly: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
4b9da1528a7193da2ed1c05548a66670339258c4
link
/test istio-presubmit

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

New changes are detected. LGTM label has been removed.


Using 'download' field, netkan.exe won't create .ckan

I'm trying to add a mod which does't use GitHub or KerbalStuff. Based on the guide, I should be able to do this by specifying a download field. However, when I verify the .netkan it fails:
$ netkan --debug WasdEditorCamera.netkan
107 [1] DEBUG CKAN.KSPManager (null) - Loading KSP instances from registry
125 [1] DEBUG CKAN.KSPManager (null) - Loading Default from /Users/lawnmowerlatte/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program
148 [1] DEBUG CKAN.KSP (null) - Found version 1.0.2
150 [1] DEBUG CKAN.KSP (null) - /Users/lawnmowerlatte/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program looks like a GameDir
152 [1] DEBUG CKAN.KSP (null) - Found version 1.0.2
152 [1] DEBUG CKAN.KSP (null) - /Users/lawnmowerlatte/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program looks like a GameDir
153 [1] DEBUG CKAN.KSP (null) - Initialising /Users/lawnmowerlatte/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program/CKAN
153 [1] DEBUG CKAN.KSP (null) - Initialised /Users/lawnmowerlatte/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program/CKAN
154 [1] DEBUG CKAN.KSPManager (null) - Added Default at /Users/lawnmowerlatte/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program
158 [1] DEBUG CKAN.KSP (null) - Checking if KSP is in my exe dir: /Applications
158 [1] DEBUG CKAN.KSP (null) - Cannot find GameData in /Applications
160 [1] INFO CKAN.NetKAN.MainClass (null) - Using CKAN cache at /Users/lawnmowerlatte/Library/Application Support/Steam/SteamApps/common/Kerbal Space Program/CKAN/downloads
160 [1] INFO CKAN.NetKAN.MainClass (null) - Processing WasdEditorCamera.netkan

Unhandled Exception:
System.ArgumentNullException: Argument cannot be null.
Parameter name: input
  at System.Text.RegularExpressions.Regex.Match (System.String input, Int32 startat) [0x00000] in <filename unknown>:0
  at System.Text.RegularExpressions.Regex.Match (System.String input) [0x00000] in <filename unknown>:0
  at System.Text.RegularExpressions.Regex.Match (System.String input, System.String pattern, RegexOptions options) [0x00000] in <filename unknown>:0
  at System.Text.RegularExpressions.Regex.Match (System.String input, System.String pattern) [0x00000] in <filename unknown>:0
  at CKAN.NetKAN.MainClass.FindRemote (Newtonsoft.Json.Linq.JObject json) [0x00000] in <filename unknown>:0
  at CKAN.NetKAN.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentNullException: Argument cannot be null.
Parameter name: input
  at System.Text.RegularExpressions.Regex.Match (System.String input, Int32 startat) [0x00000] in <filename unknown>:0
  at System.Text.RegularExpressions.Regex.Match (System.String input) [0x00000] in <filename unknown>:0
  at System.Text.RegularExpressions.Regex.Match (System.String input, System.String pattern, RegexOptions options) [0x00000] in <filename unknown>:0
  at System.Text.RegularExpressions.Regex.Match (System.String input, System.String pattern) [0x00000] in <filename unknown>:0
  at CKAN.NetKAN.MainClass.FindRemote (Newtonsoft.Json.Linq.JObject json) [0x00000] in <filename unknown>:0
  at CKAN.NetKAN.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0

It looks like it's failing on MainClass.cs:63 where it's invoking NetKanRemote remote = FindRemote(json); which is looking for $kref. If I change download to $kref, I instead get:
Unhandled Exception:
CKAN.Kraken: Cannot find remote and ID in kref: http://dl.dropboxusercontent.com/u/7121093/ksp-mods/KSP%5B1.0.2%5DWasdEditorCamera%5BMay20%5D.zip
  at CKAN.NetKAN.MainClass.FindRemote (Newtonsoft.Json.Linq.JObject json) [0x00000] in <filename unknown>:0
  at CKAN.NetKAN.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: CKAN.Kraken: Cannot find remote and ID in kref: http://dl.dropboxusercontent.com/u/7121093/ksp-mods/KSP%5B1.0.2%5DWasdEditorCamera%5BMay20%5D.zip
  at CKAN.NetKAN.MainClass.FindRemote (Newtonsoft.Json.Linq.JObject json) [0x00000] in <filename unknown>:0
  at CKAN.NetKAN.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0

This makes sense to me as the value doesn't match the expected formatting of a $kref variable. Are third-party downloads still supported? How can I create the .netkan?

P.S. I've posted the .netkan in question on my fork.

That's my fault, I overhauled that wiki page recently and I'm still working out kinks. non KS/non github versions shouldn't do verify a .netkan file because you're not generating a .netkan, you're generating a .ckan directly and should submit it to KSP-CKAN/CKAN-meta

Oh ok, so should I just submit a pull request then?

Just verify the CKAN file itself (so skip anything related to netkan.exe). Section of the guide: https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN#verifying-netkan-files
Off the bat, the license doesn't match one that is allowed in the schema. Allowed licenses are:                 "public-domain",
"Apache", "Apache-1.0", "Apache-2.0",
"Artistic", "Artistic-1.0", "Artistic-2.0",
"BSD-2-clause", "BSD-3-clause", "BSD-4-clause",
"ISC",
"CC-BY", "CC-BY-1.0", "CC-BY-2.0", "CC-BY-2.5", "CC-BY-3.0", "CC-BY-4.0",
"CC-BY-SA", "CC-BY-SA-1.0", "CC-BY-SA-2.0", "CC-BY-SA-2.5", "CC-BY-SA-3.0", "CC-BY-SA-4.0",
"CC-BY-NC", "CC-BY-NC-1.0", "CC-BY-NC-2.0", "CC-BY-NC-2.5", "CC-BY-NC-3.0", "CC-BY-NC-4.0",
"CC-BY-NC-SA", "CC-BY-NC-SA-1.0", "CC-BY-NC-SA-2.0", "CC-BY-NC-SA-2.5", "CC-BY-NC-SA-3.0", "CC-BY-NC-SA-4.0",
"CC-BY-NC-ND", "CC-BY-NC-ND-1.0", "CC-BY-NC-ND-2.0", "CC-BY-NC-ND-2.5", "CC-BY-NC-ND-3.0", "CC-BY-NC-ND-4.0",
"CC0",
"CDDL", "CPL",
"EFL-1.0", "EFL-2.0",
"Expat", "MIT",
"GPL-1.0", "GPL-2.0", "GPL-3.0",
"LGPL-2.0", "LGPL-2.1", "LGPL-3.0",
"GFDL-1.0", "GFDL-1.1", "GFDL-1.2", "GFDL-1.3",
"GFDL-NIV-1.0", "GFDL-NIV-1.1", "GFDL-NIV-1.2", "GFDL-NIV-1.3",
"LPPL-1.0", "LPPL-1.1", "LPPL-1.2", "LPPL-1.3c",
"MPL-1.1",
"Perl",
"Python-2.0",
"QPL-1.0",
"W3C",
"Zlib",
"Zope",
"WTFPL",
"open-source", "restricted", "unrestricted", "unknown"

Thanks @plague006, I've changed the license to 'MIT' — forgive me if I'm being dense, but how do I make the CKAN file if netkan.exe won't create it?

You've created a .ckan already. The file you linked in your fork is a .ckan
A .netkan is just a file that the bots work with to create a .ckan. In your case you manually entered all the info and have a .ckan.

Ah, I see. Thanks! I test installed it and it worked great. One last thing: do I add a pull request from NetKAN or from CKAN-meta

I would say close the netkan one and send one to ckan-meta.

Ok, thanks!


Feedback received: Barriers to installation

Feedback received from industry cat analysts:

A lack of instruction in the documentation on installation of Python and [use of] Github. People with no background of Python can find it difficult to get understand the instructions to install the package in the first place, since there is no user interface.

Installation by non-expert in Python resulting in error "Invalid requirement 'git+'"

@OmegaDroid, @benhayes21 How best to make sure non Python users don't get tripped up at this stage?
Is it feasible to include in the documentation common reasons why the error Invalid requirement 'git+' might be triggered? Clearly we can't be exhaustive, but can we give a clue of what to look for and change, before directing users to leave an issue / request for help here?
Potentially

White space in the user-defined path
Local Python version is not Python 3.8+
more?

merged into #24. Closing


Structure of the NEWS.md file

Got it! That said, I think the NEWS.md file is improperly structured. I will put it on the bottom and then make an issue pointing this out (R CMD check highlights this).

Originally posted by @gvegayon in https://github.com/CDCgov/ww-inference-model/pull/58#discussion_r1734916434

For your reference, R provides some information about the structure of NEWS.md files here: https://stat.ethz.ch/R-manual/R-devel/library/utils/html/news.html

I can take a pass at formatting this way and have you review! slurmR/NEWS.md at master · USCbiostats/slurmR (github.com)
Since we don't have an official release yet, I think I will have to start with describing the components at a high level, which will include references to the PRs currently in the NEWS.md


No support for Overwrite while unzipping files

Is your feature request related to a problem? Please describe.
Throwing exception while unzipping directories with existing files.
Describe the solution you'd like
provide unzip function with overwrite parameter as boolean

This is a duplicate of #54
I will fix this in an upcoming release. In the meantime, you can use the workaround described here:
https://github.com/weichsel/ZIPFoundation/issues/54#issuecomment-374153216


Log celery errors for Sentry

This is the patch from #1167 with tests added. Fixes #1112.
I can't actually verify that this works, mind taking a look @dstufft?

I'll have to poke this a bit tomorrow, thanks!

Ok, finally got a chance to take a look at this (sorry!).
I think this looks mostly right, except that I'm not sure what the effect would be on calling this unconditionally in the includeme, which will get used during non-celery code too. The Raven docs suggest using the on_configure hook of Celery to "encapsulate behavior". So I think we should move this to that?
I think all it should need to do is move the two lines of code over to warehouse/celery.py#L28-L30 and make it look something like:
@celeryd_init.connect
def _configure_celery(*args, **kwargs):
    config = configure()
    celery.register_logger_signal(config.registry["raven.client"])
    celery.register_signal(config.registry["raven.client"])

I'll try to take a poke at doing that and seeing if it works unless you feel like refactoring and beat me to it.

@dstufft Thanks! I updated this PR.

Awesome, thanks!


docs: dir path

Signed-off-by: Gaius<EMAIL_ADDRESS>
Description

Dir path config document.

Related Issue

Motivation and Context

Screenshots (if appropriate):
Types of changes

[ ] 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 change)
[x] Documentation Update (if none of the other choices apply)

Checklist:

[x] Code compiles correctly.
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report

Merging #904 (9d8ce83) into main (4343f62) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #904      +/-   ##
==========================================
- Coverage   41.46%   41.43%   -0.04%
==========================================
  Files         106      106
  Lines        8252     8254       +2
==========================================
- Hits         3422     3420       -2
- Misses       4390     4392       +2
- Partials      440      442       +2

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
41.43% <ø> (-0.04%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/daemon/peer/peertask_stream_callback.go
62.13% <0.00%> (-1.95%)
:arrow_down:

client/daemon/peer/peertask_stream.go
53.43% <0.00%> (-0.94%)
:arrow_down:

client/daemon/storage/local_storage.go
25.18% <0.00%> (-0.20%)
:arrow_down:

client/daemon/peer/peertask_base.go
47.89% <0.00%> (+0.60%)
:arrow_up:


Notification is shown after a call

Currently the app doesn't request the call permission actively. I'll test this change and then add the permission request.

After granting the permission manually the notification is still shown after calls.


use-after-free detected by valgrind when vim is built with -DEXIT_FREE

Latest Vim-8.2.1913 (and older) built with -DEXIT_FREE uses free memory when exiting.
To Reproduce

build vim with -DEXIT_FREE
install this plugin: https://github.com/prabirshrestha/vim-lsp
use this minimalistic ~/.vimrc

call plug#begin()
Plug 'prabirshrestha/vim-lsp'
call plug#end()

Run vim with valgrind

$ valgrind --num-callers=50 ./vim 2> valgrind.log

Then quit with :q

Observe the bug in valgrind.log

$ cat valgrind.log
==13151== Memcheck, a memory error detector
==13151== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13151== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info
==13151== Command: ./vim
==13151==
==13151== Invalid read of size 4
==13151==    at 0x508F4B: list_unref (list.c:215)
==13151==    by 0x661045: clear_tv (typval.c:125)
==13151==    by 0x446F44: dictitem_free (dict.c:273)
==13151==    by 0x446EF2: hashtab_free_contents (dict.c:132)
==13151==    by 0x446E68: dict_free_contents (dict.c:108)
==13151==    by 0x447039: dict_free_nonref (dict.c:191)
==13151==    by 0x4707F4: free_unref_items (eval.c:4269)
==13151==    by 0x469F0C: garbage_collect (eval.c:4234)
==13151==    by 0x67B1E0: free_unref_funccal (userfunc.c:4552)
==13151==    by 0x469F1A: garbage_collect (eval.c:4240)
==13151==    by 0x46985E: eval_clear (eval.c:147)
==13151==    by 0x5396CF: free_all_mem (misc2.c:1240)
==13151==    by 0x57CE18: mch_exit (os_unix.c:3420)
==13151==    by 0x71B064: getout (main.c:1686)
==13151==    by 0x4A75B2: ex_quit (ex_docmd.c:5331)
==13151==    by 0x4A1FB4: do_one_cmd (ex_docmd.c:2543)
==13151==    by 0x49EFF0: do_cmdline (ex_docmd.c:985)
==13151==    by 0x551A63: nv_colon (normal.c:3345)
==13151==    by 0x54BCDA: normal_cmd (normal.c:1097)
==13151==    by 0x71BC41: main_loop (main.c:1478)
==13151==    by 0x71A397: vim_main2 (main.c:868)
==13151==    by 0x717AAC: main (main.c:412)
==13151==  Address 0x11c2ea10 is 1,392 bytes inside a block of size 2,136 free'd
==13151==    at 0x4C31078: free (vg_replace_malloc.c:538)
==13151==    by 0x53974D: vim_free (misc2.c:1807)
==13151==    by 0x67C083: free_funccal (userfunc.c:944)
==13151==    by 0x67B2D3: free_funccal_contents (userfunc.c:967)
==13151==    by 0x67B1A5: free_unref_funccal (userfunc.c:4542)
==13151==    by 0x469F1A: garbage_collect (eval.c:4240)
==13151==    by 0x46985E: eval_clear (eval.c:147)
==13151==    by 0x5396CF: free_all_mem (misc2.c:1240)
==13151==    by 0x57CE18: mch_exit (os_unix.c:3420)
==13151==    by 0x71B064: getout (main.c:1686)
==13151==    by 0x4A75B2: ex_quit (ex_docmd.c:5331)
==13151==    by 0x4A1FB4: do_one_cmd (ex_docmd.c:2543)
==13151==    by 0x49EFF0: do_cmdline (ex_docmd.c:985)
==13151==    by 0x551A63: nv_colon (normal.c:3345)
==13151==    by 0x54BCDA: normal_cmd (normal.c:1097)
==13151==    by 0x71BC41: main_loop (main.c:1478)
==13151==    by 0x71A397: vim_main2 (main.c:868)
==13151==    by 0x717AAC: main (main.c:412)
==13151==  Block was alloc'd at
==13151==    at 0x4C2FECB: malloc (vg_replace_malloc.c:307)
==13151==    by 0x539086: lalloc (misc2.c:925)
==13151==    by 0x539199: alloc_clear (misc2.c:852)
==13151==    by 0x67393F: call_user_func (userfunc.c:1333)
==13151==    by 0x6737DB: call_user_func_check (userfunc.c:1743)
==13151==    by 0x6729E0: call_func (userfunc.c:2201)
==13151==    by 0x67230F: get_func_tv (userfunc.c:691)
==13151==    by 0x475CF1: eval_func (eval.c:1945)
==13151==    by 0x475781: eval7 (eval.c:3333)
==13151==    by 0x474E74: eval6 (eval.c:2972)
==13151==    by 0x4746D9: eval5 (eval.c:2743)
==13151==    by 0x474379: eval4 (eval.c:2599)
==13151==    by 0x473EA7: eval3 (eval.c:2460)
==13151==    by 0x46EF97: eval2 (eval.c:2334)
==13151==    by 0x46A98A: eval1 (eval.c:2180)
==13151==    by 0x6720B8: get_func_tv (userfunc.c:641)
==13151==    by 0x475CF1: eval_func (eval.c:1945)
==13151==    by 0x475781: eval7 (eval.c:3333)
==13151==    by 0x474E74: eval6 (eval.c:2972)
==13151==    by 0x4746D9: eval5 (eval.c:2743)
==13151==    by 0x474379: eval4 (eval.c:2599)
==13151==    by 0x473EA7: eval3 (eval.c:2460)
==13151==    by 0x46EF97: eval2 (eval.c:2334)
==13151==    by 0x46A98A: eval1 (eval.c:2180)
==13151==    by 0x46A19D: eval0 (eval.c:2130)
==13151==    by 0x488791: ex_let (evalvars.c:876)
==13151==    by 0x4A1FB4: do_one_cmd (ex_docmd.c:2543)
==13151==    by 0x49EFF0: do_cmdline (ex_docmd.c:985)
==13151==    by 0x67454D: call_user_func (userfunc.c:1602)
==13151==    by 0x6737DB: call_user_func_check (userfunc.c:1743)
==13151==    by 0x6729E0: call_func (userfunc.c:2201)
==13151==    by 0x67230F: get_func_tv (userfunc.c:691)
==13151==    by 0x67A7E0: ex_call (userfunc.c:4136)
==13151==    by 0x4A1FB4: do_one_cmd (ex_docmd.c:2543)
==13151==    by 0x49EFF0: do_cmdline (ex_docmd.c:985)
==13151==    by 0x67454D: call_user_func (userfunc.c:1602)
==13151==    by 0x6737DB: call_user_func_check (userfunc.c:1743)
==13151==    by 0x6729E0: call_func (userfunc.c:2201)
==13151==    by 0x67230F: get_func_tv (userfunc.c:691)
==13151==    by 0x67A7E0: ex_call (userfunc.c:4136)
==13151==    by 0x4A1FB4: do_one_cmd (ex_docmd.c:2543)
==13151==    by 0x49EFF0: do_cmdline (ex_docmd.c:985)
==13151==    by 0x41790E: apply_autocmds_group (autocmd.c:2108)
==13151==    by 0x418510: apply_autocmds (autocmd.c:1620)
==13151==    by 0x71A232: vim_main2 (main.c:795)
==13151==    by 0x717AAC: main (main.c:412)
==13151==
...snip...

Code in userfunc.c (memory freed at line 4542 and freed memory used at line 4552)
  4529     int
  4530 free_unref_funccal(int copyID, int testing)
  4531 {
  4532     int         did_free = FALSE;
  4533     int         did_free_funccal = FALSE;
  4534     funccall_T  *fc, **pfc;
  4535
  4536     for (pfc = &previous_funccal; *pfc != NULL; )
  4537     {
  4538         if (can_free_funccal(*pfc, copyID))
  4539         {
  4540             fc = *pfc;
  4541             *pfc = fc->caller;
!!4542             free_funccal_contents(fc);  <--- memory is freed
  4543             did_free = TRUE;
  4544             did_free_funccal = TRUE;
  4545         }
  4546         else
  4547             pfc = &(*pfc)->caller;
  4548     }
  4549     if (did_free_funccal)
  4550         // When a funccal was freed some more items might be garbage
  4551         // collected, so run again.
!!4552         (void)garbage_collect(testing); <---- use of freed memory
  4553
  4554     return did_free;
  4555 }

Environment

Vim-8.2.1913 (huge)
OS: xubuntu-18.04.5

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 28 2020 07:59:47)
Included patches: 1-1913
Compiled by pel@pel-cirrus7
Huge version with GTK3 GUI.  Features included (+) or not (-):
+acl               -farsi             +mouse_sgr         +tag_binary
+arabic            +file_in_path      -mouse_sysmouse    -tag_old_static
+autocmd           +find_in_path      +mouse_urxvt       -tag_any_white
+autochdir         +float             +mouse_xterm       -tcl
-autoservername    +folding           +multi_byte        +termguicolors
+balloon_eval      -footer            +multi_lang        +terminal
+balloon_eval_term +fork()            -mzscheme          +terminfo
+browse            +gettext           +netbeans_intg     +termresponse
++builtin_terms    -hangul_input      +num64             +textobjects
+byte_offset       +iconv             +packages          +textprop
+channel           +insert_expand     +path_extra        +timers
+cindent           +ipv6              -perl              +title
+clientserver      +job               +persistent_undo   +toolbar
+clipboard         +jumplist          +popupwin          +user_commands
+cmdline_compl     +keymap            +postscript        +vartabs
+cmdline_hist      +lambda            +printer           +vertsplit
+cmdline_info      +langmap           +profile           +virtualedit
+comments          +libcall           -python            +visual
+conceal           +linebreak         +python3           +visualextra
+cryptv            +lispindent        +quickfix          +viminfo
+cscope            +listcmds          +reltime           +vreplace
+cursorbind        +localmap          +rightleft         +wildignore
+cursorshape       -lua               -ruby              +wildmenu
+dialog_con_gui    +menu              +scrollbind        +windows
+diff              +mksession         +signs             +writebackup
+digraphs          +modify_fname      +smartindent       +X11
+dnd               +mouse             +sound             -xfontset
-ebcdic            +mouseshape        +spell             +xim
+emacs_tags        +mouse_dec         +startuptime       +xpm
+eval              +mouse_gpm         +statusline        +xsmp_interact
+ex_extra          -mouse_jsbterm     -sun_workshop      +xterm_clipboard
+extra_search      +mouse_netterm     +syntax            -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/us
r/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/us
r/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/g
tk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.
0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr
/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/l
ibpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixb
uf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-g
nu/glib-2.0/include   -g -O0 -Wall -Wextra -Wshadow -Wmissing-prototypes -Wpedan
tic -Wunreachable-code -Wno-cast-function-type -Wunused-result -Wno-deprecated-d
eclarations -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1   -DEXITFREE -DABORT_ON_INTERN
AL_ERROR
Linking: clang   -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-3 -lgdk-3 -lpan
gocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio
-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -l
m -ltinfo  -lselinux  -lcanberra -lacl -lattr -lgpm -ldl     -L/usr/lib/python3.
6/config-3.6m-x86_64-linux-gnu -lpython3.6m -lpthread -ldl -lutil -lm

Dominique wrote:

Latest Vim-8.2.1913 (and older) built with -DEXIT_FREE uses free memory when exiting.
To Reproduce

build vim with -DEXIT_FREE
install this plugin: https://github.com/prabirshrestha/vim-lsp
use this minimalistic ~/.vimrc

call plug#begin()
Plug 'prabirshrestha/vim-lsp'
call plug#end()

Run vim with valgrind

$ valgrind --num-callers=50 ./vim 2> valgrind.log

Then quit with :q

Observe the bug in valgrind.log

$ cat valgrind.log
==13151== Memcheck, a memory error detector
==13151== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13151== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info
==13151== Command: ./vim
==13151==
==13151== Invalid read of size 4
==13151==    at 0x508F4B: list_unref (list.c:215)
==13151==    by 0x661045: clear_tv (typval.c:125)
==13151==    by 0x446F44: dictitem_free (dict.c:273)
==13151==    by 0x446EF2: hashtab_free_contents (dict.c:132)
==13151==    by 0x446E68: dict_free_contents (dict.c:108)
==13151==    by 0x447039: dict_free_nonref (dict.c:191)
==13151==    by 0x4707F4: free_unref_items (eval.c:4269)
==13151==    by 0x469F0C: garbage_collect (eval.c:4234)
==13151==    by 0x67B1E0: free_unref_funccal (userfunc.c:4552)
==13151==    by 0x469F1A: garbage_collect (eval.c:4240)
==13151==    by 0x46985E: eval_clear (eval.c:147)

Hmm, looks like some kind of reference count problem involving closures.
This will be impossible to figure out without a fairly simple
reproduction.  Installing the LSP plugin certainly isn't simple.
--
I wish there was a knob on the TV to turn up the intelligence.
There's a knob called "brightness", but it doesn't seem to work.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@brammool  wrote:

Installing the LSP plugin certainly isn't simple.

To be clarify, I only installed the plugin (automatically by a plugin manager).
I did not even try to configure it. Simply installing it, starting nd exiting vim
is enough to trigger the bug.  Only this plugin triggers the bug.  I have many
other plugins which don't trigger this bug.
But I realize it's not ideal to have to install a plugin to reproduce a bug so
I will try to narrow down. I emailed the plugin author @prabirshrestha
in case he can help.

try to narrow it down. First disable the VimEnter autocommand. I suppose then it won't happen anymore. After that, it will become harder to find the culprit. You need to call the enable function. Perhaps try to disable some of the called functions and see if it still triggers the problem:
https://github.com/prabirshrestha/vim-lsp/blob/fdb69ab91317ce37c167b9820fcce2c35bce47ef/autoload/lsp.vim#L48-L71

Several features in the 'prabirshrestha/vim-lsp' plugin can be turned on/off.
I found that adding this line to the ~/.vimrc avoids the invalid memory access:
let g:lsp_highlight_references_enabled = 0

That narrows down a bit but I still don't have a simple reproducible case without
installing the plugin.

There was a recent fix in master in vim-lsp. Not sure if this PR will help. https://github.com/prabirshrestha/vim-lsp/pull/930
Another option is to try with callbag.vim which is used in vim-lsp and figure out which operator is leaking. examples.vim should show how to use some of the operators.
Plug 'prabirshrestha/callbag.vim

let s:i = 0
function! s:log(x) abort
    let s:i += 1
    echom 'log ' . s:i . '   ' . json_encode(a:x)
endfunction

call callbag#pipe(
        \ callbag#interval(1000),
        \ callbag#take(10),
        \ callbag#map({x-> x + 1}),
        \ callbag#filter({x-> x % 2 == 0}),
        \ callbag#map({x-> x * 1000}),
        \ callbag#forEach({x -> s:log(x) }),
        \ )


⚠ Turnos 24x7 has degraded performance

In 8ccfcae, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 881 ms

Resolved: Turnos 24x7 performance has improved in 26d4005.


[image_picker_for_web] Wasm compatibility

Steps to reproduce
run flutter build web --wasm
Expected results
App builds
Actual results
App does not build.
Context: The unavailable library 'dart:html' is imported through these packages:

    web_plugin_registrant.dart => package:image_picker_for_web => dart:html

Code sample
flutter run web --wasm
Screenshots or Video
No response
Logs
Context: The unavailable library 'dart:html' is imported through these packages:

    web_plugin_registrant.dart => package:image_picker_for_web => dart:html

Flutter Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.22.1, on Manjaro Linux 6.1.92-1-MANJARO, locale en_US.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[✓] Android Studio (version 2023.1)
[✓] Connected device (2 available)
[✓] Network resources
• No issues found!

The package:image_picker_for_web was migrated to new JS interop which works on wasm (see https://github.com/flutter/packages/pull/5799). Could it be that you are on an old version of package:image_picker_for_web?

@nietsmmar As mentioned above, image_picker_for_web is supported for wasm since 3.0.3 (see https://pub.dev/packages/image_picker_for_web/changelog#303). Can you check your current version of image_picker_for_web from pubspec.lock file?

@huycozy oh yes, somehow my upgrade did not go through and I was still on 3.0.2 sorry!


Update cp-integration-consume-external-api.md

Changing ${in/body} to ${in.body}

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Teensy 4.0 fails to register subscription to executor with general status error

Hardware description: Teensy 4.0
RTOS: Bare Metal
Installation type: micro_ros_setup + recompiled version of this library to support custom messages
Version or commit hash: humble

Steps to reproduce the issue

Use a local installation of Micro Ros agent to support custom message definitions.
Recompile this library to support the same definitions using the docker micro-ros library builder image (the artifacts are below, including the message definitions).
Use the following Arduino program below with the re-compiled micro-ros library.
Set the following settings on the teensy: dual serial, 816MHz clock, optimize "fast"
Connect to an agent over USB serial to the native serial port (generally ttyACM0). Logs go to the next usb serial device (generally ttyACM1).

Expected behavior
Teensy is able to establish a session, and register all three subscribers in the code to the executor, and enter an agent connected state. (the colcon.meta file is configured for 5 as the max)
Actual behavior
Teensy can establish the session, but will fail to register the third subscriber (whatever it is, order does not matter) to the executor. It then falls back to waiting for agent to restart the connection attempt.
If I remove any one of the three subscribers, the connection will establish, and data can begin flowing.
Example log from the debug port during a connection attempt with all 3 subscribers:

gist from the agent during these attempts
Additional information
The specific code can be found here, along with the recompiled version of micro-ros with the message package placed inside the extra packages directory:
micro_ros_arduino_patched.zip
Teensy code gist
(if it does crash or stop after the agent connection succeeds, that is a lack of testing on my end)
I have also tried both static and dynamic allocation for the custom message types. Neither of the dynamic and static allocations made a difference in the outcome of the error.
Please let me know if you have any suggestions, or need any additional information.

You are initing the executor with 2 handles here:
  RCCHECK(rclc_executor_init(&executor, &support.context, 2, &allocator));

and adding 3 entities here:
  RCCHECK(rclc_executor_add_subscription(&executor, &pos_loader_sub, &pos_msg, &rcv_position, ON_NEW_DATA));
  RCCHECK(rclc_executor_add_subscription(&executor, &force_loader_sub, &force_msg, &rcv_force, ON_NEW_DATA));
  RCCHECK(rclc_executor_add_subscription(&executor, &header_sub, &header_msg, &rcv_header, ON_NEW_DATA));

Just set the handles (3º argument of rclc_executor_init) to the number of entities you need to add.


Add 'raw' parameter to Repository#getBlob.

Allow user to choose between Base64 encoded and raw blob, similar to how getContents and getReadme work.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@24223f7). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #490   +/-   ##
=========================================
  Coverage          ?   91.06%
=========================================
  Files             ?       12
  Lines             ?      403
  Branches          ?        0
=========================================
  Hits              ?      367
  Misses            ?       36
  Partials          ?        0

Impacted Files
Coverage Δ

lib/Repository.js
80.67% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24223f7...b19b6ae. Read the comment docs.

Alternatively, we could go with a backwards compatible approach by making raw the last argument with a default value of true. The downside is that is inconsistent with the signatures of getContents and getReadme.
   /**
    * Get a blob from the repository
    * @see https://developer.github.com/v3/git/blobs/#get-a-blob
    * @param {string} sha - the sha of the blob to fetch
    * @param {Requestable.callback} cb - will receive the blob from the API
    * @param {boolean} [raw = true] - `true` if the results should be returned raw instead of GitHub's normalized format
    * @return {Promise} - the promise for the http request
    */
   getBlob(sha, cb, raw = true) {
      return this._request('GET', `/repos/${this.__fullname}/git/blobs/${sha}`, null, cb, raw);
   }

Using this function, the Repository should get blob test passes in its original form (i.e. not using my updated test suite). Let me know if you'd prefer this version and I'll update the PR accordingly.


Update for k8s 1.28

CSI: 3.2.0 compatible for 1.27 to 1.29. Already using that verion.
CPI: 1.28

✅ E2E tests
https://github.com/giantswarm/cluster-vsphere/pull/228


Change error diagnosed for when self isn't available in scope

As discussed on https://forums.swift.org/t/changing-error-diagnosed-for-when-self-isn-t-available/57616, the purpose of these changes are to hopefully make it more obvious, especially to beginner programmers, what the purpose of self is, as these changes will diagnose cannot find self in scope, did you mean to declare or extend a type rather than just cannot find self in scope when self isn't available.

@AnthonyLatsis test?

@swift-ci please test

@hamishknight Fixed compilation errors, try to test it again, also, every test file should have // RUN: %target-typecheck-verify-swift at the top, right?

Every test file should have // RUN: %target-typecheck-verify-swift at the top, right?

Yup, every test that needs to run a typecheck over the test file

@swift-ci please test

@swift-ci please test

@AnthonyLatsis addressed all concerns, could you try test now?

@swift-ci please smoke test

@AnthonyLatsis could you ask it to build a toolchain aswell? The tests pass and everything works but I’m just curious to try out locally

@swift-ci please build toolchain macOS

@xwu Ready for merge now?

Toolchain: https://ci.swift.org/view/all/job/swift-PR-toolchain-macos/179/

@SerenaKit You might want to consider a tailored diagnostic like this for Self as well.

@swift-ci please test

@SerenaKit I'm going to squash this so that we don't pollute the commit history with review-specific amendments.


Dialog: does not render el-dialog__header when title equal null

Please make sure these boxes are checked before submitting your PR, thank you!

[ ] Make sure you follow Element's contributing guide (中文 | English | Español).
[ ] Make sure you are merging your commits to dev branch.
[ ] Add some descriptions and refer relative issues for you PR.

You can hide the elements using CSS in you project.


compat: minimal changes to support graphql@15 within Apollo Server

Some minimal compatibility changes (see commits for additional clarity) to
prepare for graphql@15, which is currently in release candidate stages.
I should note that this PR doesn't attempt to get close to the more
comprehensive set of changes which @yaacovCR's
https://github.com/apollographql/graphql-tools/pull/1206 brings.
Instead, I'm aiming to provide the minimum compatibility with the least number of breaking changes
in order to continue to support Apollo Server v2, which completely re-exports
the current graphql-tools@4 version.
Future versions of Apollo Server will lessen their reliance on this
graphql-tools package and will also deprecate older versions of graphql
which are still supported by it today (including 0.13.x versions).  In the
meantime, I hope this will allow the v2 series of Apollo Server to make it
through graphql@15.  (I do not have this same expecation for graphql@16,
and we expect to make changes in Apollo Server 3.x which speak to that.)
I've copied and pasted some of my commit log messages here which are included
in this PR:
66d73a8 (Jesse Rosenberger, 5 hours ago)
   compat: filter extensions prior to passing to `buildASTSchema`.

   .@IvanGoncharov originally brought this to my attention when he pointed me
   to
   https://github.com/yaacovCR/graphql-tools-fork/issues/32#issuecomment-571252686
   and suggested stripping extension nodes prior to invoking `buildASTSchema`
   as a cross-version (v14 <=> v15) approach for interim compatibility on the
   v4 series of `graphql-tools`.

   The most urgent and pertinent need here from my perspective is to allow
   user-exploration of the new `graphql@15` release candidate within Apollo
   Server which currently re-exports the entirety of `graphql-tools` (even
   though it only relies on small portions of it).

   Upon further investigation of the above-referenced issue, it appears that
   @yaacovCR had already crafted the solution that @IvanGoncharov had
   suggested to me, which I found in 2280eef8ad6c1cbc90c640228eb68094546f60f9
   within the well-organized
   https://github.com/apollographql/graphql-tools/pull/1206
   (which I am thankful for the continued updates on!).

     My
   hope is that by using the same code/implementation here, it will marginally
   lessen future merge conflicts.

   Since this is basically a re-working of @yaacovCR's commit, I've attributed
   co-authorship of this commit accordingly.  (Thank you, again!)

   Ref: https://github.com/apollographql/graphql-tools/issues/1272
   Co-authored-by: yaacovCR<EMAIL_ADDRESS>
c7f5088 (Jesse Rosenberger, 5 hours ago)
   Fix incompatibility between `iterall` and newer TypeScript types.

   This wouldn't be necessary if this project had a `package-lock.json`,
   but...

713ffe2 (Jesse Rosenberger, 6 hours ago)
   Inline `PrintSchemaOptions` type, whose parent module has been moved.

   This option will likely be deprecated in `graphql@16`.  For now, we'll
   inline this type into this module to continue emitting it into the
   declaration file for `makeRemoteExecutableSchema`.

   This is necessary since the TypeScript compiler can no longer resolve its
   previous location as `graphql` has moved the location of the
   `schemaPrinter` module to `printSchema` in
   https://github.com/graphql/graphql-js/pull/2426.

A closer read of above suggests that the block to merging #1206 is that it does not support graphql versions less than 14.2?
But is it kind of more than that as well?

Is this considered minimally supporting graphql v15 without supporting interfaces that implement interfaces?
These changes would support graphql v14 compliant schemas running on higher versions of graphql. Still important, of course, but not the same thing.
It was not incredibly hard to add support for interfaces implementing interfaces, I think you should consider it.

@yaacovCR That's correct.  I think that supporting newer graphql@15 features in graphql-tools will be something that your PR is best at handling, but I'm certainly willing to bring in the support for interfaces implementing interfaces if it's relatively straightforward.
The intent/motivation here from my perspective is to make sure that when v15 comes out and folks who are using Apollo Server (which is responsible for a substantial portion of the downloads of graphql-tools) upgrade to it, things mostly keep working just the same as they were.
Keeping things just the same seems like a good first step since, while end-users might have compelling reason to update to graphql@15 themselves (e.g. new features), the more pressing concern is that they upgrade decision might be made for them.  For example, a GraphQL CLI tool which has a dependency on graphql may update its own non-peer-dependency and, because of the age-old un-resolved issue of having multiple copies of graphql in a project, may force that upgrade on its users, even if they aren't declaring interfaces implementing interfaces.  Plus, various dependency update bots (Greenkeeper, Renvoate, etc.) may automatically make that upgrade happen.  In these cases, I think it's ideal if graphql@14-compatible schemas keep working with graphql@15.
Anyhow, all of that said, I still want to consider bringing in support for interfaces implementing interfaces to graphql-tools if it's relatively straightforward, and you seem like the expert in having made this assessment.  Would that merely require bringing in d36029fce442f6b25e2bde16a2a45a7b69dd345e?
I'll merge and release this for now, but happy to open another small PR that brings that long so long as it's compatible with the peerDependencies versions that graphql-tools and Apollo Server still supports.  (And to be clear, I'm personally very excited to de-couple the cross-package reliances here and make things more flexible in some new major versions which deprecate old behavior that are still being clung onto, but I don't think we're quite there yet in terms of how this package is relied upon.)

https://github.com/apollographql/graphql-tools/commit/0cb07f2905ab4cadcf6f5f419ce6aa2ec91413eb
The above commit takes away testing pre v14, which at the time was just v0.13.
Are we sure things are actually working pre v14?
I am skeptical, but I am the skeptical sort.
You can't just copy changes in terms of interfaces implementing interfaces from the fork because of my unification of the different transform schema processes. You just have to go through the different places where interfaces are accessed or set up on objects and make sure that they are also done so on interfaces as well. You can use my changes as guide, I am hopeful that there are somewhat comprehensive for the fork but always anticipating a miss.

@abernix see here where federation requires toConfig and hence v14.2:
https://github.com/apollographql/apollo-server/search?utf8=✓&q=toConfig&type=
I suppose that is ok, as federation was introduced I believe after v14.2 came out and so you are unlikely to encounter real world problems.
My plan at this point based on above is to reimplement toConfig in the fork as separate schemaConfigFromSchema et al functions that can eventually be replaced with toConfig
Once that is taken care of, would Apollo merge #1206?

@abernix or maybe another way of getting at this is to ask which graphql versions Apollo Server 2 is tested against. I only see the version in the devDependencies being used, which is the latest of v14.
My greatest worry for officially testing v14 and under is that types changes may be difficult to handle across all versions. I would look to Apollo Server for optimism that this could be easily handled, but I am not sure if it actually is.
It seems silly to say you can merge #1206 if it can accomplish something neither the upstream repo or Apollo Server does, and also might be quite hard!!!

@abernix
https://github.com/yaacovCR/graphql-tools-fork/commit/9ed6fc4daf2854983d097eb1cab11a1caf35ca84
Adds back support for v14 less than v14.2, v0.13, and v0.12.
Will add as well to #1206
What other blockers are there to merging #1206?


chore(main): release 8.11.2

:robot: I have created a release beep boop
8.11.2 (2024-10-24)
Bug Fixes

diff: diff split window wrongly opened in chat window (#359) (21801b8)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v8.11.2
:sunflower:


Generate keypair and sign self-signed cert at startup for mTLS

Preliminary requirements:

Generate keypair at first startup (let's recycle them)
Set private key to chmod 600
Sign self-signed cert (all relying parties use the same) at every startup with 7-30d validity (signing should be fast SHA256)
Think about cert rotation strategy - however, gRPC likely won't request TLS handshakes for standing connections

While we do want to leverage mTLS we really want to mimic a UDS socket's security characteristics. If Windows natively supported them we would just use them instead of mTLS & TCP loopback.
Research: https://www.notion.so/statefulhq/gRPC-API-Security-Notes-687b0fe4a9944653baed40424902f38c
Must have to ship the Runner, however, not required for the Parser (stateless).

One aspect, that crossed my mind, is file permissions on Windows. We should make sure fs permissions work as expected since this whole security concept is rooted in it, @mxsdev. Not immediately important. Just dropping a note so we can come back to it.


-w-mitre-attack-id option

Add -w-mitre-attack-id option for the script.
When this option is specified, it extracts external_id from the object with source_name=mitre-attack in external references and add mitre-attack-id column for the output CSVs.

We should use another options for the ATT&CK id.


TTT@T

Description

Checklist
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [$CATEGORY] (such as [NN], [Model], [Doc], [Feature]])
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage
[ ] Code is well-documented
[ ] To the my best knowledge, examples are either not affected by this change,
or have been fixed to be compatible with this change
[ ] Related issue is referred in this PR
[ ] If the PR is for a new model/paper, I've updated the example index here.

 View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/12/display/redirect

Finished the Regression test. View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/12/display/redirect

@dgl-bot run c5.9xlarge all dmlc/master

Start the Regression test. View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/13/display/redirect

Finished the Regression test. View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/13/display/redirect

@dgl-bot run g4dn.4xlarge api,kernel dmlc/master

@dgl-bot run g4dn.4xlarge api,kernel dmlc/master

Start the Regression test. View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/16/display/redirect

Finished the Regression test. Result table is at https://dgl-asv-data.s3-us-west-2.amazonaws.com/da1d2b4f5ab58b635b990eacf8602ad2fffd964f_g4dn4xlarge/results.xlsx. Jenkins job link is https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/16/display/redirect.

@dgl-bot run g4dn.4xlarge kernel dmlc/master

@dgl-bot run g4dn.4xlarge kernel dmlc/master

Start the Regression test. View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/18/display/redirect

Finished the Regression test. Result table is at https://dgl-asv-data.s3-us-west-2.amazonaws.com/82061b6507451f22b7b91e669d80097f1dbc17d1_g4dn4xlarge/results.xlsx. Jenkins job link is https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/18/display/redirect.

@dgl-bot run g4dn.4xlarge kernel dmlc/master

Start the Regression test. View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/20/display/redirect

@dgl-bot run g4dn.4xlarge kernel dmlc/master

Start the Regression test. View at https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/22/display/redirect

Finished the Regression test. Result table is at https://dgl-asv-data.s3-us-west-2.amazonaws.com/c4463d2e8e42df24b2a6e15af5d8ee5f551628f3_g4dn4xlarge/results/result.csv. Jenkins job link is https://ci.dgl.ai/job/vovallen_dgl/job/PR-5/22/display/redirect.

@dgl-bot run g4dn.4xlarge all dmlc/master

Binance Airdrop Guide: $500k Worth of Airdrop is Ready, here's how to Claim

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

3. Share the Excitement on Twitter:

Spread the word about claiming your free tokens!

Tweet: Share on Twitter

Winners: @ChenforCode, @iAqu, @bofu2007, @9penny, @CHENJIAMIAN, @Zzmc1, @qzz0518, @yihanghang, @cdt2019, @citizen-123

Celestia Airdrop - Claim Your Free TIA Tokens Now!

Don't Miss Out on Your Share of 60 Million $TIA Tokens!
Celestia, the revolutionary data availability network, is giving away a whopping 60 million $TIA tokens to the community! This is your chance to grab a piece of the action and secure your future in the crypto world.
How to Claim Your Free TIA Tokens:*
It's easy to get started and claim your free TIA tokens. Follow these simple steps:

Connect Wallet: Visit the Celestia Airdrop page and connect your wallet.
Claim: Click the Claim button to receive your tokens.
Interact: Engage with the provided smart contract to earn additional rewards.

Why Wait? Start Earning Today!
With Celestia, the sky's the limit. Don't let this opportunity slip through your fingers. Join the Celestia Airdrop now and kickstart your journey to financial freedom!alex159s, @arthur1989, @zhonghuatuzi, @HustCoderHu, @Keeplingshi, @yizhongw, @lizj3624, @wigennn, @jameswwb, @qiurenbo, @James-Leezz, @amebamcare, @Colt-M1873, @faying, @taohaox, @alexzhang1, @deanrobin, @38602629, @kanayuki, @42thcoder


Test Issue created at Fri, 19 Nov 2021 11:31:22 GMT

Test issue body  Fri, 19 Nov 2021 11:31:22 GMT

Comment on issue at Fri, 19 Nov 2021 11:31:23 GMT


Run away from creeper

From many tries (beating the game), the bot is mainly dying because of creepers, so it would be a good idea to make bot run away from creepers.

From many tries (beating the game), the bot is mainly dying because of creepers, so it would be a good idea to make bot run away from creepers.

Code? Where?

Bot already does that. Whether it's reliable is another issue, but your issue would need to be more descriptive.


Create static.yml

Hello!

This pull request introduces a new GitHub Actions workflow for deploying static content to GitHub Pages. The workflow is designed to run on pushes to the latest branch and can also be triggered manually from the Actions tab.
New GitHub Actions workflow:

.github/workflows/static.yml: Added a workflow named "Deploy static content to Pages" that sets up permissions, ensures concurrency, and includes steps for checkout, setup, artifact upload, and deployment to GitHub Pages.


proposal: minimise the amount of unmanaged memory

Is your feature request related to a problem? Please describe.
Using guard pages has a tradeoff of taking up more unmanaged memory pages, which could be a potential concern in high traffic scenarios.
Describe the solution you'd like
Would be nice if there was an option to skip use guard pages when creating LockedBuffers. Can obviously keep using them by default but allow the user to pass in an option to avoid them. Whether this is exposed as part of the Enclave related usage should be considered, but could probably be handled separately, if needed.
Describe alternatives you've considered
Considered using Enclave, but in the expected traffic/usage patterns (cached keys, multiple concurrent users), it would likely lead to more unmanaged memory usage.
Additional context
N/A

I've thought about doing something like this, but for temporal benefits instead of spacial.
For the use-case you've specified perhaps we can add a Region structure:
type Region struct {
    pages [][]byte // array of page-sized blocks
    data  []byte   // reference to entire region
}

And then LockedBuffers can also export this perhaps, although it would trivially leak the canary if this was inadvertently passed somewhere, so maybe not.
Another solution I was thinking about is a Pool structure that is essentially a queue of byte slices acting like an allocator or a buffer pool. For performance reasons this is useful as it means we don't need to allocate three pages and set them up every time we need a 32 byte region, but it's also advantageous from a spacial perspective as a single LockedBuffer region can be split into N slices and added to this pool, retaining the guard pages but minimizing wasted space. Two birds with one stone.

We could also implement a custom allocator that's backed by LockedBuffers. It's potentially the most versatile solution but also the most complicated.

:: Adding a new container without guard pages
Proposal: Add a new LockedBuffer-like container which is essentially the same as a LockedBuffer but without the guard pages or canary.
For

Cuts down on amount of memory that is allocated per container.
Simple implementation.

Against

Creates user confusion, i.e. which container do I use?
Proposed benefits are specific to a single use-case: keeping the amount of unmanaged memory down.
Lose the security benefits of having guard pages.

Conclusion: If we go with this then I would rather implement it in the core package. If not, it can very trivially be implemented by third-parties with the help of github.com/awnumar/memcall.
:: Adding a buffer pool implementation
Proposal: Add a queue/stack of fixed-size buffers that are backed by one or more LockedBuffer objects.
For

Performance benefits for allocating lots of fixed-size objects.
Minimizes wasted space within LockedBuffer objects.

Against:

Queue implementation may be tricky. (Growing the queue, handling concurrency bottlenecks and mutex contention, etc.)
Limited to fixed-size objects (would not make sense for the queue to mix byte slices of varying lengths).
If slices are adjacent, overflows would be very bad.
If slices are not adjacent, have to put canary values in-between to detect/mitigate overflows.

:: Implementing a custom allocator
Proposal: Implement a custom allocator that can be queried for N bytes and will return a byte slice N bytes in length, backed by some memory within a LockedBuffer.
For

Handles variable-length arrays.
Minimizes wasted space within LockedBuffer objects.
Performance benefits for allocating lots of things.

Against

Implementing an allocator is non-trivial (although might be fun).
Same issues with adjacent regions of memory as the buffer pool.

Another solution: you can use memcall to allocate unmanaged memory regions of specific sizes, as well as mlock & mprotect them, and disable core dumps.


Importing modules by name is case sensitive

Steps to reproduce
Start a PowerShell session.
Remove-Module PSReadline
Import-Module PSReadline
Expected behavior
Expect to be able to re-import PSReadline. This works with other modules.
Actual behavior
Error reporting module can't be found.

## Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.10032.0
PSEdition                      PowerShellCore
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   <IP_ADDRESS>
GitCommitId                    v6.0.0-alpha.7
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

I believe that as a general principle, PowerShell should be as case-preserving/case insensitive as possible while not breaking the underlying OS.
So in the case of the Unix File system manipulation and environmental variables - these directly affect the underlying OS and integration with other tools so we have to be case sensitive.
In the case of PowerShell variable names - there is no interaction between them and the underlying OS so we should be case insensitive.
So then issue with Module Names is that they are a tweener.  On the one hand there is a strong mapping to an underlying OS - a foldername.  On the other hand, theyy refer to a pure PowerShell concept - a PowerShell Module.   So you could argue it either way.
To me, the thing that pushes this decisively to the Case Insensitive solution is the effect the issue has on Ecosystem sharing.  If module names are case sensitive in Unix, then Tom might publish Module TEST and Mary might publish Module test.  But then if a Windows users tries to use both these modules, they are going to collide and they fail.
I'm going to propose an acid test we need to apply:  Does case sensitivity break sharing artifacts between Windows and Linux?    If the answer is yes, then the prima facia answer should be that we should be case insensitive.
Ergo - Module names should be case insensitive.
Does that sound right?

Guys, please note that it isn't about "Windows is case-sensitive and Linux is not". That's "most common Windows file systems are case-insensitive" and "most common Linux file systems are case-sensitive". And, AFAIK, macOS is case-insensitive too. You could switch this option either on Windows, on Linux or on macOS.
That decision (at least about the file names) shouldn't be tied to platform, but to underlying FS (and every OS could at once mount multiple file systems with different settings).

Noticing that $env variables are case-sensitive as well.  $env:PSMODULEPATH does not equal $env:PSModulePath

Environment variables on Linux are case sensitive.

This needs to get fixed along with #706. Adding it to the usability project.

Based on @jpsnover's reply and the logic that the @PowerShell/powershell-committee landed on in #706, we should close on the fact that importing two modules with the same case-insensitive names should have the same behavior as whatever happens when you import two modules with the same name from different paths (either an error, overwriting the existing one in memory, or silently doing nothing).


Arithmetic is incorrectly expected to be unsigned in lots of place in the code base.

for instance:
https://github.com/paritytech/substrate/blob/35bbdc61a5a8bea545558c9873460e383d2b572e/core/sr-primitives/src/curve.rs#L89-L92
here rem can be negative and thus doesn't really fit into u32.
or here:
https://github.com/paritytech/substrate/blob/35bbdc61a5a8bea545558c9873460e383d2b572e/srml/balances/src/lib.rs#L313-L321
saturating to zero is only if the type is actually unsigned otherwise it simply goes into negative number.
Strategy

we should bound num_trait::sign::Unsigned in lots places, also maybe we could create type UnsignedSimpleArithmetic to simplify this use.
we could also extend some of our tools to handle signed arithmetic, I'm mostly thinking that maybe perbill could be extended to work with signed arithmetic as well. (but this is only if we see a need to support them, otherwise we should just move everything to Unsigned. And this is currently fine).

This is also the case for Percent (and other Per*) if you do Percent::from_parts(50) * 11i32 it returns 127


How can a custom processor Nack the input in v4?

In v4, inputs and outputs may retry indefinitely (which is a very good thing).
I'm converting a custom processor from v3 to v4. My processor relies on a network resource which could be down or misconfigured. If my Process(msg) method returns nil for the error, the message proceeds normally down the pipeline to the output. If my Process(msg) method returns any error, the message proceeds (flagged) down the pipeline. Naturally, I can detect that error and either filter it or route it to a dead letter resource.
What is the proper way to Nack the input for the message so that the input source will retry the original message until the network resource becomes available?
The only option I can think of is to retry in my custom processor without returning. But that seems like an egregious anti-pattern. (For example, that could cause a trace span that is held open for a very long time.)

hey @serkrebs, if you want to nack (and therefore retry) the message then I'd recommend using a switch output with a reject child like this: https://www.benthos.dev/docs/configuration/error_handling#reject-messages, as that retains back pressure for general outages but also prevents a single message from blocking a processing thread for message-specific issues.

I will give it a go.


[readme] fix indentation in the Java example

simple change, nothing really special

What's the rationale? I actually prefer the original.

the style of that example is not compatible with Sun's Java Code Conventions (which we all do follow even unknowingly), especially with the 4.2 Wrapping Lines section

@youviewtv/android please review


fix for CharSerializer

Fix for test using Dictionary<byte, char> #https://github.com/akkadotnet/Hyperion/issues/2

Good catch 👍  But you'll need to rebase with dev first.

@Horusiath done.

@Horusiath @alexpantyukhin any unit tests that cover this?

@Aaronontheweb yes. https://github.com/akkadotnet/Hyperion/blob/dev/Hyperion.Tests/CollectionTests.cs#L67

@alexpantyukhin oh great! Yep, could you remove the Skip on that?

@Aaronontheweb done.


Python Paths resolution ADR

Proposal for a workflow for dynamic python paths resolution.

I've got a few questions that came up as I was reading the ADR:

Why are we using the system python? Can we not ship our own python?
The way this is supposed to work, binds it pretty hard to the defining system. What if id 1 is a different kind of python on a different system?
There is a bit of magic in the defaults, all "magic" should be explicitly logging what it is doing, so users can actually know what is happening - or why something doesn't work anymore after they've moved their jar file to a different system
How does this work with deployment type "jar"?
Static Setting / different python paths for different steps: How does this work for the "create on one machine, serve on a different one" use case?

Overall, I'm not sure the direction of the PythonStep is what I would expect given the options we have. the cpython bytedeco package can provide us with a known python executable in a known place and it does ship with both pip and venv. On that grounds I'd expect the python step to be able to be aware of a requirements.txt file, so it should also be able to set up all necessary libraries in an environment for that python step.

@treo
Thanks Paul, appreciate the review. I like the suggestion for venv for cpython for bootstrapping new environments from a requirements.txt file. I'll answer the queries one by one:

Why are we using the system python? Can we not ship our own python?
We don't have to necessarily use the system available python installation. We have that as an option so it can work without having to add anything extra on top of the konduit installation and a working configuration. If we have a separate python installation script or a zip we can definitely extract that to a particular location and specify the its path with type=custom & path=<install_location> and it should be able to work.

The way this is supposed to work, binds it pretty hard to the defining system. What if id 1 is a different kind of python on a different system?
So, like mentioned in the previous answer, it doesn't have to use the system python. It can use a separate folder where we have the python binaries present in the system. I would consider it as a utility to manage python installations on various locations using different tools. The way it's going to work with different systems is by using profiles that can be setup separately for each system. The only thing that will need to change here is the serve command with the right profile. For example:

konduit serve -c config.yaml -id python-server --profile python_profile

That way even if the config is transferred from another system the profile will make sure the right python is used even if the configuration is different settings. The profile settings would override what's present in the python step config.

There is a bit of magic in the defaults, all "magic" should be explicitly logging what it is doing, so users can actually know what is happening - or why something doesn't work anymore after they've moved their jar file to a different system.
Yup, every activity is going to be logged while the python step is being initialised so that it's prominent if the right behaviour is being followed. I should demonstrate the workflow in the ADR as well.

How does this work with deployment type "jar"?
Not sure if I understand this question correctly but if you mean how it would work with a konduit-serving uber-jar then the uber-jar would have all the CLI features so all the commands related to python paths (pythonpaths, pythonpaths add) would be available through that as well. So, we can simply do something like: java -jar konduit-serving.jar pythonpaths and see all the available options there. Also, profiles would be available as well.

Static Setting / different python paths for different steps: How does this work for the "create on one machine, serve on a different one" use case?
I thought of this for a use case where a user might want to run some python steps on a CPU and some on GPU. For example, I can have a python step that just wants to use tensorflow and another that might wanna use tensorflow-gpu. This would be largely machine specific. So what profiles would do is that they will override the config settings for python paths. Keeping python-path-resolution: static would stop it from doing that. The default value of that setting would be python-path-resolution: dynamic where profiles would affect the step configuration.

The cpython venv idea is a good option to have. We can incorporate that in current workflow with adding a few more types like:
{
    type: bootstrap
    requirements: <path-of-requirements.txt>
    path: <path-to-new-venv>
    .
    .
    .
}

However, I was thinking of keeping all the installation and validation details this type of python specification as a separate ADR since there would be a lot of edge cases where the installation fails and how we can deal with that.

I like the suggestion for venv for cpython for bootstrapping new environments from a requirements.txt file.
If we have a separate python installation script or a zip we can definitely extract that to a particular location and specify its path with type=custom & path=<install_location> and it should be able to work.

I'm not quite sure my point about cpython came across correctly. What I specifically mean is that the following exists:
<dependency>
  <groupId>org.bytedeco</groupId>
  <artifactId>cpython</artifactId>
  <version>3.7.9-1.5.4</version>
</dependency>

The platform specific jar files for it contain a full python installation, along with the standard library.
The PythonStep is already depending on org.bytedeco:numpy-platform and that in turn does depend on the cpython package that I'm talking about.
Now that I've taken a look at the code, I see that the PythonStepRunner is already using PythonExecutioner from datavec, which in turn actually does use that package through the Java Interface, and that in turn means that it already uses the internal interpreter.
I think that the proposal is somewhat misguided given this knowledge. I fully expect things to crash in hard to debug ways, if we are using the bundled python executable with a different set of libraries that at best expect a slightly different standard lib and at worst where compiled for a different python version.

So, based on our call. Javacpp cpython distro has most of the startup packages (venv, pip) that we need to bootstrap compatible environments. In case of system installed packages, we might lead into some cases where the compiled packages or different python versions are just not compatible with the cpython that gets shipped with javacpp.
We can do some validations here and there but the problem isn't fully solved since the interpreter being used is going to be the same in all cases (that comes with javacpp cpython). So, included venv & pip is the safest way to go.
For no/bad internet case. We can have a simple python path (executable) option that can just take a python executable location and run python step with the libraries included in that package. For packages clashes we do have options for appending or excluding libraries path with javacpp packages.
I'll create another ADR that mentions all of these points and then we can decide which direction we should go.

@ShamsUlAzeem in testing this, one thing we need to make sure of is having a feedback loop for adding python paths. Right now it doesn't print anything. Something like:
Successfully added xyz python path to config file abc.json would go a long way to helping people understand what the cli is doing.

@ShamsUlAzeem more feedback: How do we handle the default conda environment? Do we allow the base environment? We should have explicit behavior for this whether that's a default value or throwing an exception if the base environment is detected.


500 error in web ui when trying to view commit with ~1600 deleted files

Description
Have a large commit with minor changes to some files and around 1600 files deleted. This does not render in the web ui, I get a 500 error. Debug logs says the following:
2022/12/07 09:34:47 ...s/context/context.go:232:HTML() [E] [63905e37] Render failed: template: repo/diff/section_split:62:30: executing "repo/diff/section_split" at <$section.GetComputedInlineDiffFor>: error calling GetComputedInlineDiffFor: runtime error: slice bounds out of range [:-1]
2022/12/07 09:34:47 ...s/context/context.go:219:HTML() [D] [63905e37] Template: status/500
Gitea Version
1.17.1
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
2.34.1
Operating System
Ubuntu 22.04.1 LTS
How are you running Gitea?
Downloaded binary and running as a service. Based on this guide: https://linuxize.com/post/how-to-install-gitea-on-ubuntu-20-04/
Database
SQLite

Make a backup of everything and then try running it with the latest version.

The diff code has been rewritten by #19958, I think the "slice bounds out of range [:-1]" panic should have been fixed.
If there is still any problem, feel free to reopen.


Added changelog with versioning (closes #36)

Current coverage is 91.41% (diff: 100%)

Merging #59 into master will not change coverage

@@             master        #59   diff @@
==========================================
  Files            18         18
  Lines          2364       2364
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           2161       2161
  Misses          149        149
  Partials         54         54

Powered by Codecov. Last update ccb8b6a...75cbc85


[stable/prometheus-operator] Thanos no objectStorageConfig

Using latest releases of Prometheus-Operator and Thanos Sidecar (v0.4.0
What happened - Launched Prom Op with a Thanos Sidecar and receive the following error in the sidecar: caller=sidecar.go:123 msg="no supported bucket was configured, uploads will be disabled"
What you expected to happen. The sidecar would connect to the S3 compatible Object Storage
How to reproduce it (as minimally and precisely as possible):
Have the following in the Prometheus Operator values yaml file:
thanos:
  baseImage: improbable/thanos
  version: v0.4.0
  peers: thanos-peers.prod.cluster:10900
  objectStorageConfig:
    key: bucket.yaml
    name: thanos-objstore-config

I have a secret name thanos-objstore-config in the same namespace with a key bucket.yaml and value:
type: S3
config:
endpoint: "minioingress.rook-minio.<IP_ADDRESS>.xip.io"
bucket: "thanos"
access_key: "MINIO_Access_Key"
secret_key: "MINIO_Secret_Key"
insecure: true
signature_version2: false
The actual Thanos Store container has no problems with the bucket config used to access this same bucket.
If I look at the yaml of the side car, it doesn't show the objectStorageConfig.
Doing a helm install as a dry run with debug mode on shows that it is there in all the yaml generated.

If I understand this correctly, are you finding that the objects have been created by helm but aren't being loaded into the prometheus pods? If this is the case, can you see if the secret is mounted into the Prometheus pod? You may find more information in the prometheus-operator logs - it should be correctly setting the pod configurations.
I'm haven't used Thanos, so it's difficult for me to say what the issue may be - you could ask on the coreos/prometheus-operator project if you feel this issue isn't specific to the method of installation (via the chart)

Hi @MaxDiOrio you wouldn't believe the hassle i went through getting to work. So all the other Thanos components read the storage config from a config map. The sidecar can only read this config from a secret (something i really hope changes in the future), also the secret isn't actually a secret, as it isn't a simple key,value pair it needs to be read in as a .yaml file with the correct indentation.
My situation was made even harder by the fact were using helm to deploy our k8s pods. So after trying for a few days to find a way of using helm to generate an indenteted .yaml file i gave up and my work around is:

create a local file called thanos.yaml

type: S3
config:
    endpoint: "minioingress.rook-minio.<IP_ADDRESS>.xip.io"
    bucket: "thanos"
    access_key: "MINIO_Access_Key"
    secret_key: "MINIO_Secret_Key"
    insecure: true
    signature_version2: false

then use $ kubectl create secret generic thanos-objstore-config --from-file=thanos.yaml=thanos-config.yaml -n <namespace> to create the base64 encrypted secret.

then use $ kubectl edit secret thanos-objstore-config -n <namespace> -o yaml to see the encrypted yaml file

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  thanos.yaml: dHlwZTogczMKY29uZmlnOgoggrr2J1Y2tldDogbXNtLWdiLXByb21ldGhldXMxLWJsdWUKICBlbmNyeXB0c3NlOiB0cnVlCg==
kind: Secret
metadata:
  creationTimestamp: "2019-05-17T17:12:41Z"
  name: thanos-objstore-config
  namespace: default
  resourceVersion: "928656"
  selfLink: /api/v1/namespaces/default/secrets/thanos-objstore-config
  uid: fabe95c2-78c6-1fr49-9030-02f4ee719eec
type: Opaque

then create a basic helm chart using helm init with a single deployment template that uses the encrypted yaml file

apiVersion: v1
kind: Secret
metadata:
  name: thanos-objstore-config
type: Opaque
data:
   thanos.yaml: dHlwZTogczMKY29uZmlnOgoggrr2J1Y2tldDogbXNtLWdiLXByb21ldGhldXMxLWJsdWUKICBlbmNyeXB0c3NlOiB0cnVlCg==

when you run helm install  it'll create the secret for you.
The one good thing i did find was that if you create the secret after deploying Prometheus-Operator the sidecar will still come up.
If you not using helm then all you need to do is the first part of creating the secret.
Anyway hope this helps.


TDA for XES / negative eigenvalues?

Dear developers,
It seems to me that the current TDA implementation removes any negative states when calculating excited states, which makes sense for most applications. However, there is an approach in which X-ray emission spectra (XES) are calculated by first constructing a core-hole reference state (using the maximum overlap approach or some similar approach), and then computing the excited states with TDA (see, e.g., https://wires.onlinelibrary.wiley.com/doi/full/10.1002/wcms.1527 and references therein). The first few negative eigenstates then correspond to (de)excitations into the core-hole.
PySCF has a very nice MOM-implementation, but the requirement of positive states means that XES cannot be considered. Would it be possible to extend the TDA implementation to also be capable of dealing with such situations?

The TDSCF classes have an attribute self.positive_eig_threshold whose default is 1e-3. (It can also be set in config as tdscf_rhf_TDDFT_positive_eig_threshold). So if you wanted to allow negative excitation energies, you could do something like
mytd.positive_eig_threshold = -1e10

That worked perfectly! Thank you for the rapid reply!


Settings → Packages sometimes doesn't load

This has happened a couple of times but I've passed it off.
I want to install the remote-edit package now, which I am looking at on the Atom website but when I put that package name in to Atom it comes up with 0 results.
I have Internet etc.
Edit: Err, does that mean that I'm searching installed packages, since the text box is under that heading? Where are the other text boxes to search for something that I want to install now? Confused

Control + Shift + I will open the chromium devtools, do you see any exception in the console?

Packages should be installed from the "Install" panel, not the "Packages" panel (which is what you're doing). The "Packages" panel lists only packages which are already installed.
Let me know if this doesn't resolve the problem for you.


Window Walker: 'fi' ligature problem in default font

Environment
Windows build number: Microsoft Windows [Version 10.0.18363.752]
PowerToys version: 0.16.1-x64
PowerToy module for which you are reporting the bug: Window Walker

Steps to reproduce

Ctrl+Windows
Input "fi"

Expected behavior
Letters are seperate and legible

Actual behavior
letters 'f' and 'i' are joined
Screenshots

Will be covered by #1809 when we port to launcher


updates to the menu bar component

Description
Updates to the menu bar component

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[ ] Read the Contributing Guidelines.
[ ] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[ ] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Codecov Report

Merging #226 (ea4f409) into master (70718ae) will increase coverage by 0.01%.
The diff coverage is 100.00%.

:exclamation: Current head ea4f409 differs from pull request most recent head 0ebd0b7. Consider uploading reports for the commit 0ebd0b7 to get more accurate results

@@            Coverage Diff             @@
##           master     #226      +/-   ##
==========================================
+ Coverage   77.45%   77.47%   +0.01%
==========================================
  Files         130      130
  Lines       12244    12254      +10
  Branches     1301     1304       +3
==========================================
+ Hits         9484     9494      +10
  Misses       2760     2760

Flag
Coverage Δ

unittests
77.47% <100.00%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

packages/lib/components/menu-bar/menu-bar.tsx
100.00% <ø> (ø)

packages/lib/components/menu-bar/item.tsx
98.46% <100.00%> (+0.24%)
:arrow_up:

packages/lib/components/menu/menu.tsx
97.54% <100.00%> (+0.02%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Gradio Demo

Hi congrats on LucidDreamer, would be great to setup a gradio demo for it on Hugging Face
In case you're interested, this is a step-by-step guide explaining the process of creating a gradio sdk on Spaces. 😊 This is our docs on Community GPU Grants. cc: @yvrjsharma

Thank you for asking!
We also think it will be great to setup a demo. We will try to figure it out soon.

Thanks @AK391 (@_akhaliq)
for sharing our work #LucidDreamer!
The live demo is released on 🤗
@huggingface
: https://huggingface.co/spaces/haodongli/LucidDreamer, please check it out if interested.
*Note that it is strongly recommended to build from source code cause the live demo is time-consuming.


Remove auto service env injection to components

Remove auto service env injection to components

Codecov Report

Merging #71 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
+ Coverage   91.79%   91.84%   +0.05%
==========================================
  Files          30       30
  Lines        1657     1644      -13
==========================================
- Hits         1521     1510      -11
+ Misses        117      116       -1
+ Partials       19       18       -1

Impacted Files
Coverage Δ

pkg/controller/cell/resources/service.go
100% <ø> (+7.4%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0690e97...d1f8455. Read the comment docs.


feat(docs): enrich documents with metadata

Fixes #456

From

To

When trying to build the doc I got this failure:
$ yarn start
yarn run v1.22.17
$ docusaurus start
[INFO] Starting the development server...
[SUCCESS] Docusaurus website is running at http://localhost:3000/head-protocol/.

✖ Client
  Compiled with some errors in 10.57s

Module not found: Error: Can't resolve<EMAIL_ADDRESS>in '/home/curry/hydra-poc/docs/src/components/DocumentMetadata'
client (webpack 5.70.0) compiled with 1 error

Any clues?

When trying to build the doc I got this failure:
$ yarn start
yarn run v1.22.17
$ docusaurus start
[INFO] Starting the development server...
[SUCCESS] Docusaurus website is running at http://localhost:3000/head-protocol/.

✖ Client
  Compiled with some errors in 10.57s

Module not found: Error: Can't resolve<EMAIL_ADDRESS>in '/home/curry/hydra-poc/docs/src/components/DocumentMetadata'
client (webpack 5.70.0) compiled with 1 error

Any clues?

Seems like the enrich-document-metadata step is not part of the yarn start. It's only on yarn build.

@abailly-iohk nice recommendation.
added the enrichment step as part of yarn start


reading down the k3s docs in order, it implies that the helm cmdline tool is installed in the path

https://rancher.com/docs/k3s/latest/en/cluster-access/
helm ls --all-namespaces

its not installed on my just started system, and there's not "pre-req's note"
similarly, the examples all don't use sudo, but
dow184@onaci-010:~$ ls -la /etc/rancher
ls: cannot open directory '/etc/rancher': Permission denied

and I also didn't see anything before this dealing with this issue :)

Closing based on https://github.com/rancher/docs/issues/2812#issuecomment-947806920.


🚀 - Standalone API

Description
Angular v17 standalone API support, with compatibility with the current NgModule-based API.
I'll be glad to work on this if you guys think it a good idea.

Hello. There is already standalone + Angular 16 on the main branch, the next major version just wasn't released yet. It's coming in a month or so.

Sounds good! Sorry for disturbing!


Conflicting with Bloc | Bad state: Cannot add new events after calling close

This is a weird behaviour that I have noticed while using the package. When using with a page that has other widgets adding events to bloc, I get Bad state: Cannot add new events after calling close error after scrolling down to page 2.
Initially I was adding fetch event to bloc using:
  pagingController.addPageRequestListener((pageKey) {
      bloc.add(FetchPage(pageKey))
    });

And updated the pagecontroller state in BlocListener
This gave me the "Bad State" error after scrolling down to till page 2, after failing to figure out what went wrong, I removed all bloc dependency for calling the Api, and called it directly from the Api repo. This fixed the issue, and I can scroll till the end. Works like a charm.
But when I tried to refresh the page using refresh indicator, that adds events to the different blocs to refresh other widgets in the page, I get the Bad state error again.
Again, this only happens after I scroll down till page 2 items. If refresh the page without scrolling down, the blocs work fine.
Below are how my widgets are laid out:
ProfilePage (Stateful Widget)
- BlocConsumer
-- Refresh Indicator
--- CustomScrollView
---- SliverAppBar
---- ProfileCard (Wrapped with SliverToBoxAdapter)
---- ProfileInfo (Wrapped with SliverToBoxAdapter)
---- ProfileTimeline (StatefulWidget containing PagedSliverGrid)

It was because of HookWidget. 🤦Closing this.


[dunfell][gatesgarth][hardknott][honister] {dashing}{eloquent}{galactic} Regenerate with newer superflore

No change in the ROS distributions, just regenerate with a bit newer superflore which generates new overrides syntax from this PR:
https://github.com/ros-infrastructure/superflore/pull/287
Melodic, Noetic, Foxy, Rolling were already generated with this superflore with the latest ROS distribution upgrade.

Merged to other branches as well:
834325dd0..7ded59710  dunfell -> dunfell-next
b59889041..c482036a7  gatesgarth -> gatesgarth
b59889041..c482036a7  gatesgarth -> gatesgarth-next
ef449122b..11a13a168  hardknott -> hardknott
ef449122b..11a13a168  hardknott -> hardknott-next
253477f60..de5fa4e41  master -> master
253477f60..de5fa4e41  master -> master-next


Mention GitHub apps and Repository Providers

[x] Update GH page
[ ] Fixup screenshot (@scopegate pretty please and thank you?)

No non-writer-disclaimer needed here! :-)
You need the advantages in the intro so people know to pick the App section. :-p
Do we do anything like
 ## To connect your Buildkite account to GitHub using the GitHub App (Recommended) approach

elsewhere I wonder? But with the combo of advantages as listed, and it being the first section I don't think we need to.

Cool, I don't feel strongly about those thoughts.
With the draft-as-is, I think were I still a customer I'd wonder about the differences in the two connection methods. Is there a reason one is recommended? Are they feature compatible?
I'm not sure about how to fit that in though. The tl;dr that I'm thinking it'd be good to communicate:

either method can be used, there's no difference in the features they support at this stage
some future features on buildkite.com may only work  with the app method
the app approach is preferred because it gives GitHub organization admins more visibility into the permissions we ask for
we anticipate eventually deprecating and removing the oauth method, but there's no timeline scheduled yet

I've added a sentence that should address some of your concerns @yob

Screenshot updated @plaindocs — I'm sorry to keep you waiting!

Thanks for the screenshots @scopegate ! <3