Speed up the jekyll build time for the website

With guides like this and plugins like jekyll-include-cache we should be able to dramatically improve the build time to generate the website.
The output of bundle exec jekyll build --profile is below and should be a guide for prioritizing the effort.
forsetisecurity.org-dev
Filename                                         | Count |      Bytes |   Time
-------------------------------------------------+-------+------------+-------
_layouts/docs.html                               |  3610 | 102740.58K | 64.133
_includes/site/layout/docs/category_nav.html     |  3515 |   7654.48K | 39.526
_includes/site/get_docs_for_category.liquid      |  3515 |      6.87K | 29.126
_includes/site/layout/docs/tabs.html             |  3610 |  10932.08K | 22.649
_layouts/base.html                               |  3623 | 132066.26K |  9.494
_includes/site/layout/base/footer.html           |  3623 |   6227.03K |  3.314
_includes/site/layout/base/footer/links.html     |  3623 |   3955.58K |  1.555
sitemap.xml                                      |     1 |    524.19K |  1.344
_includes/site/layout/base/scripts.html          |  3623 |  11994.11K |  1.028
_includes/site/layout/base/nav.html              |  3623 |   4401.38K |  0.809
_includes/site/zippy/item.html                   |    10 |    520.08K |  0.607
releases/index.md                                |     1 |     36.35K |  0.596
_includes/site/layout/base/stylesheets.html      |  3623 |   3435.48K |  0.538
_includes/site/layout/base/footer/copyright.html |  3623 |    583.78K |  0.415
_includes/site/faq/qa_item.html                  |    10 |    300.06K |  0.355
_layouts/default.html                            |  3622 | 102918.86K |  0.258
_docs/v2.6/setup/upgrade.md                      |     1 |     45.88K |  0.152
_docs/v2.8/setup/upgrade.md                      |     1 |     54.22K |  0.120
_docs/v2.7/setup/upgrade.md                      |     1 |     50.76K |  0.114
_docs/latest/setup/upgrade.md                    |     1 |     54.24K |  0.107
_docs/v2.5/setup/upgrade.md                      |     1 |     40.12K |  0.087
_docs/v2.4/setup/upgrade.md                      |     1 |     31.04K |  0.067
_includes/site/releases/version_item.html        |     1 |     36.24K |  0.065
_includes/site/markdown_snipify.liquid           |     1 |     15.82K |  0.055
_news/2018-11-27-visualize-gcp.md                |     1 |      1.21K |  0.049
_docs/latest/faq/index.md                        |     1 |     31.39K |  0.042
_docs/v2.4/faq/index.md                          |     1 |     31.39K |  0.042
_docs/v2.5/faq/index.md                          |     1 |     31.39K |  0.041
_docs/v2.1/faq/index.md                          |     1 |     31.39K |  0.040
_docs/v2.2/faq/index.md                          |     1 |     31.39K |  0.039
_docs/latest/concepts/service-accounts.md        |     1 |      4.04K |  0.038
_docs/v2.6/faq/index.md                          |     1 |     31.39K |  0.038
_docs/v2.8/concepts/service-accounts.md          |     1 |      4.04K |  0.038
_docs/v2.3/concepts/service-accounts.md          |     1 |      3.88K |  0.038
_docs/v2.0/faq/index.md                          |     1 |     31.39K |  0.038
_docs/v2.7/concepts/service-accounts.md          |     1 |      4.04K |  0.038
_docs/v2.1/concepts/service-accounts.md          |     1 |      3.88K |  0.037
_docs/v2.4/concepts/service-accounts.md          |     1 |      3.92K |  0.037
_docs/latest/concepts/architecture.md            |     1 |      2.48K |  0.037
_docs/v2.5/concepts/service-accounts.md          |     1 |      4.00K |  0.037
_docs/v2.0/concepts/service-accounts.md          |     1 |      3.88K |  0.037
_docs/v2.3/faq/index.md                          |     1 |     31.39K |  0.037
_docs/v2.8/develop/dev/inventory.md              |     1 |      6.32K |  0.037
_docs/v2.2/concepts/service-accounts.md          |     1 |      3.88K |  0.037
_docs/v2.6/concepts/service-accounts.md          |     1 |      4.04K |  0.037
_docs/v2.7/faq/index.md                          |     1 |     31.39K |  0.036
_docs/v2.8/faq/index.md                          |     1 |     31.39K |  0.036
_docs/v2.6/concepts/architecture.md              |     1 |      2.48K |  0.035
_docs/v2.7/develop/dev/inventory.md              |     1 |      6.32K |  0.034
_docs/v2.2/concepts/architecture.md              |     1 |      2.48K |  0.034

                    done in 352.348 seconds.

Work plan

[x] Speed up jekyll build by excluding more.
[x] Speed up jekyll build by leveraging jekyll-include-cache plugin where possible.
[ ] Audit liquid logic in includes and layouts for poor or extraneous loops.

[x] Speed up jekyll build by excluding more.
[x] Speed up jekyll build by leveraging jekyll-include-cache plugin where possible.
[ ] Audit liquid logic in includes and layouts for poor or extraneous loops.

In #2331 the build time is now
Filename                                  | Count |      Bytes |   Time
------------------------------------------+-------+------------+-------
_layouts/base.html                        |  3623 | 125913.65K | 19.401
sitemap.xml                               |     1 |    598.49K |  2.556
_layouts/docs.html                        |  3610 |  96513.67K |  1.478
releases/index.md                         |     1 |     36.35K |  0.699
_includes/site/zippy/item.html            |    10 |    520.08K |  0.520
_includes/site/faq/qa_item.html           |    10 |    300.06K |  0.327
_layouts/default.html                     |  3622 |  96691.95K |  0.217
_docs/v2.8/setup/upgrade.md               |     1 |     54.22K |  0.113
_docs/v2.7/setup/upgrade.md               |     1 |     50.76K |  0.103
_docs/latest/setup/upgrade.md             |     1 |     54.24K |  0.098
_docs/v2.6/setup/upgrade.md               |     1 |     45.88K |  0.092
_docs/v2.5/setup/upgrade.md               |     1 |     40.12K |  0.081
_docs/v2.4/setup/upgrade.md               |     1 |     31.04K |  0.064
_includes/site/releases/version_item.html |     1 |     36.24K |  0.048
_news/2018-11-27-visualize-gcp.md         |     1 |      1.21K |  0.048
_docs/latest/faq/index.md                 |     1 |     31.39K |  0.042
_includes/site/markdown_snipify.liquid    |     1 |     15.82K |  0.040
_docs/v2.5/concepts/service-accounts.md   |     1 |      4.00K |  0.039
_docs/v2.7/concepts/service-accounts.md   |     1 |      4.04K |  0.038
_docs/v2.2/concepts/service-accounts.md   |     1 |      3.88K |  0.037
_docs/v2.8/faq/index.md                   |     1 |     31.39K |  0.037
_docs/v2.1/concepts/service-accounts.md   |     1 |      3.88K |  0.037
_docs/v2.8/concepts/service-accounts.md   |     1 |      4.04K |  0.037
_docs/v2.4/concepts/service-accounts.md   |     1 |      3.92K |  0.037
_docs/v2.6/concepts/service-accounts.md   |     1 |      4.04K |  0.037
_docs/v2.3/concepts/service-accounts.md   |     1 |      3.88K |  0.036
_docs/v2.0/concepts/service-accounts.md   |     1 |      3.88K |  0.036
_docs/v2.4/faq/index.md                   |     1 |     31.39K |  0.036
_docs/latest/concepts/service-accounts.md |     1 |      4.04K |  0.035
_docs/v2.7/faq/index.md                   |     1 |     31.39K |  0.035
_docs/v2.5/faq/index.md                   |     1 |     31.39K |  0.035
_docs/v2.3/faq/index.md                   |     1 |     31.39K |  0.035
_docs/v2.0/faq/index.md                   |     1 |     31.39K |  0.035
_docs/latest/concepts/architecture.md     |     1 |      2.48K |  0.035
_docs/v2.5/concepts/architecture.md       |     1 |      2.48K |  0.035
_docs/v2.1/faq/index.md                   |     1 |     31.39K |  0.035
_docs/v2.6/faq/index.md                   |     1 |     31.39K |  0.034
_docs/v2.2/faq/index.md                   |     1 |     31.39K |  0.034
_docs/v2.1/concepts/architecture.md       |     1 |      2.48K |  0.034
_docs/v2.8/develop/dev/inventory.md       |     1 |      6.32K |  0.034
_docs/v2.7/develop/dev/inventory.md       |     1 |      6.32K |  0.033
_docs/v2.4/concepts/architecture.md       |     1 |      2.48K |  0.033
_docs/v2.0/concepts/architecture.md       |     1 |      2.48K |  0.033
_docs/v2.2/concepts/architecture.md       |     1 |      2.48K |  0.033
_docs/v2.7/concepts/architecture.md       |     1 |      2.48K |  0.033
_docs/v2.3/concepts/architecture.md       |     1 |      2.48K |  0.033
_docs/v2.8/concepts/architecture.md       |     1 |      2.48K |  0.033
_docs/v2.6/develop/dev/inventory.md       |     1 |      6.32K |  0.032
_docs/v2.6/concepts/architecture.md       |     1 |      2.48K |  0.032
_docs/v2.5/develop/dev/inventory.md       |     1 |      6.32K |  0.032

                    done in 291.813 seconds.

un-assigning myself as I won't be working on the last task.

Marking as dupe of #2581


[PROBLEM] C2027 and E0393

Hey,
this line return me 2 errors: c2027 and e0393 WHY? https://github.com/danielkrupinski/Osiris/blob/master/Osiris/Hooks.cpp#L136

Now the error should be gone as we include GlobalVars.h explicitly. (https://github.com/danielkrupinski/Osiris/blob/57550094e30111976fde8ab2f89732a0d2af24b1/Osiris/Hooks.cpp#L39)


how to replace some json file

how to exchange json_1 file to json_2 file?
json_1 :
{  "ff":"de",
   "receivers":[
        {
            "name":"1",
            "to":"jig<EMAIL_ADDRESS>        },
        {
            "name":"2",
            "to":"jin<EMAIL_ADDRESS>        }
    ]
}

json_2:
{  "ff":"new",
   "receivers":[
        {
            "name":"new1",
            "to":"new1<EMAIL_ADDRESS>        },
        {
            "name":"new2",
            "to":"new2<EMAIL_ADDRESS>        }
    ]
}

In this case patch will be same as json_2 file, so it looks like no reason to use jsonmerge for it.


Help message for -o not clear

When using -h to display the guides for the program. The -o optional feature guide can be a bit more detailed to clarify the order of the input and output paths.

Changed the wording to make the functionality of the option more apparent, thanks.


Make all Layout and Routing passes target aware

Summary
This commit updates all the layout and routing passes which leverage hardware constraints to have a new optional keyword argument, target, to specify a Target object for modelling the constraints of the target backend. This option will superscede any other specified arguments for backend constraints. For most of these passes the target argument is just internally leveraged to build a CouplingMap (and in 2 cases a BackendProperties) as most of the algorithms don't need more than the global connectivity graph and there is minimal overhead to convert from a target to a CouplingMap. The 2 passes which take backend properties should be refactored to work natively with the target because the conversion adds extra overhead which isn't needed, but in those cases the passes aren't enabled by default (or are slated to be moved out of tree as a plugin, see #8662) so the extra overhead isn't of particular concern.
This is part of the first step towards making all backend constraints for the transpiler used the Target internally (see #9256). Once all passes that take hardware constraints parameters as an input are updated to have a target we can start internally using the Target only for all preset pass manager construction and start the long process of deprecating the legacy interface in these passes.
Details and comments
Related to #9256

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

71 of 84 (84.52%)  changed or added relevant lines in 19 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.007%) to 84.591%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/transpiler/passes/layout/csp_layout.py
2
3
66.67%

qiskit/transpiler/passes/layout/layout_2q_distance.py
3
4
75.0%

qiskit/transpiler/passes/layout/noise_adaptive_layout.py
4
5
80.0%

qiskit/transpiler/passes/layout/trivial_layout.py
6
7
85.71%

qiskit/transpiler/passes/routing/basic_swap.py
3
4
75.0%

qiskit/transpiler/passes/routing/layout_transformation.py
5
6
83.33%

qiskit/transpiler/passes/routing/lookahead_swap.py
3
4
75.0%

qiskit/transpiler/passes/routing/bip_mapping.py
1
7
14.29%

Files with Coverage Reduction
New Missed Lines
%

src/results/marginalization.rs
1
88.51%

Totals

Change from base Build<PHONE_NUMBER>:
-0.007%

Covered Lines:
63189

Relevant Lines:
74699

💛  - Coveralls

Overall I'm good to start moving towards `Target being accepted everywhere. With this particular PR though, I'm a bit worried about a couple of things:
* we're claiming support for `Target`, but we don't really have it: the routing passes won't respect heterogeneous couplings of 2q gates; they'll happily output things the wrong way round even though the target can fully say that certain couplings are only valid for certain gates.

This has always been true. We've never guaranteed a single pass in isolation will follow all the constraints of a target (with or without the Target) object. For a routing pass the simplest example of this is swap is never guaranteed to be in the target basis (globally without a target, or locally with a target) or run sabre with a coupling map like CouplingMap.from_line(4, bidirectional=False). Sabre will ignore the edge direction in the coupling map and it relies on GateDirection to resolve this. (The bigger one for me is that none of these passes support >2q gates at all). I think it's fine for all of these passes if we only partially can conform to the constraints in a target at the pass level as long as those limitations are documented.

* the constructor API for each of these passes is getting a bit clumsy now, where there are a couple of cases where you now need to pass _everything_ by keyword argument, or include some explicit `None`s to continue passing things positionally.  I wonder if we ought to support passing `target` positionally in what is currently called `coupling_map`, and branch on the type of the passed object, potentially also moving to change the name of the positional-or-keyword parameter.

I'm fine with changing the type on coupling_map to accept CouplingMap or Target. I did it with an extra argument because I assumed it had less of an API impact to do it as a separate kwarg. Doing it as a combined argument prior to #9256 makes the preset pass manager construction a bit more involved because we'll have to do the logic to check what type of object we pass to each pass's constructor for each pass at the preset passmanager construction level. But I can update it if you think this results in a cleaner interface.

Ok, I've updated most of the passes to use a single positional argument for either a coupling map or a target. They're typically named coupling_map, we can look at deprecation/rename in a future PR. I left a couple of passes in place with the split where the logic looked like it was different.
I also expanded the test coverage, the two places I didn't add more testing were the NoiseAdaptiveLayout because it was kind of a headache to test that pass as it's not using a coupling map but backend properties directly. So translating that to a target by hand is kind of a pain. The other place was the preset pass managers because they'll be tested implicitly via the transpile() function and other test coverage we have built in for BackendV2 and manually passing a target.

Is the intention to rename the coupling_map kwarg to target later? I think it's a little confusing now that name is not indicative of the type. If we are going to make it target and remove coupling_map, then I think it's better to make the pass accept target now. I think this is more inline with how some of the other passes got updated previously as well.

It is, I was expecting to do the deprecation/rename after this merges. I don't have a strong opinion on the interface I just updated it based on @jakelishman's comments. I think his concern was that from a backwards compatibility pov a lot of the changes to do either coupling_map or target with 2 arguments ends up being a bit awkward. But if the consensus is to revert back to 2 arguments I can do that (it's basically just a revert of the recent commit).

fwiw this is the comment I originally mentioned the coupling_map/target thing in.  I don't feel super strongly about it, though as Matthew says, in the interests of backwards compatibility and assuming that we will eventually want to be able to pass the Target positionally, it would be nice to move in that direction straight away.
I think that when we're trying to support arguments being allowed to be passed either positionally or by name, there always end up being some incompatible calling conventions when trying to rename/remove a positional argument, and nothing's perfect.  My suggestion involves having a gross name for the main positional argument (would be less of an issue if we didn't have to support Python 3.7 - we could use positional-only arguments), whereas the current form ends up with the unpleasant thing of needing to pass explicit Nones.


Fix GitHub Releases deployment.

The addition of digital attestations in #2442 broke the GitHub Releases
release by moving from default permissions to more restrictive explicit
permission. Those permissions lacked the content write permission needed
to create the release and post its artifacts.

Ok, @benjyw that didn't quite do it. The fix in the 2.6.1 release is a nice-to-have and only really useful if you can't use --pip-version 24.1 (You run Python<=7). I'm away until July 2nd at which point I'll dig in to righting the release ship. If an emergency release is needed, I think just reverting this PR and the attestation PR makes sense as the stop gap.

Thanks @jsirois, I'll keep an eye out for any urgent release needs.

FWIW, looks like this issue was triggered, presumably by the upgrade of softprops/action-gh-release in #2374, and nothing to do with the attestations.


Move non-papi-specific hooks and utility functions to papi-components

User Story
As an extension developer, I want utilities and components to be in a public package that I can use anywhere so that I can use my code inside of or outside of Platform.Bible.
Description
Right now, all our hooks and a number of utility functions are provided to extension developers via the papi-frontend and papi-backend "libraries" which are really objects that we create inside Platform.Bible and pass down to them. These "libraries" are not separable from Platform.Bible, so code that uses these "libraries" will not function outside of our environment. However, many of these hooks and utilities are not really tied to Platform.Bible at all because they do not internally connect into the platform. This code should be moved to the papi-components package so code is more easily shared inside and outside of P.B:

[ ] Rename papi-components to platform-library
[ ] Move most or all of the functions in src/shared/utils/util.ts to platform-library/utils

[ ] Make a function in platform-library that sets up the logger to use throughout the library. Pass our logger service in from core using this new function so we don't have to directly get the logger to use in async-variable.ts and the other places that use it
[ ] Move async-variable.ts
[ ] Move unsubscriber-async-list.ts
[ ] Move everything in util.ts except the following:

newNonce

[ ] Move most or all of the functions in src/shared/papi-util.ts that aren't internally connected to the renderer code to platform-library

Move everything except the following things to platform-library/utils:

createSafeRegisterFn
Everything in the #region Request/Response types
REQUEST_TYPE_SEPARATOR
RequestType
SerializedRequestType
serializeRequestType
deserializeRequestType

[ ] Move these things that we did not move to platform-library into paranext-core/src/shared/utils/util.ts. Delete src/shared/papi-utils.ts and remove it from the papi

[ ] Move over PapiEvent, PapiEventHandler, and PapiEventAsync in papi-event.model.ts as well. Rename to PlatformEvent, PlatformEventHandler, and PlatformEventAsync. (put in platform-library/utils)
[ ] Move over papi-event-emitter.model.ts and rename to PlatformEventEmitter and platform-event-emitter.model.ts (put in platform-library/utils)
[ ] Move non-papi-specific hooks to platform-library/hooks

[ ] Move use-promise.hook.ts
[ ] Refactor use-event.hook.ts and use-event-async.hook.ts to remove the ability to pass a string in (which is the only thing this hook uses on the papi currently) - document that people need to use papi.network.getNetworkEvent to use a networked event with this hook. And move those hooks over

Attempt to use subexports to divide up these parts:

platform-library/components - React components
platform-library/hooks - React hooks
platform-library/utils - utility functions

Don't spend more than an hour or so on attempting subexports. #240 has info on subexports

In Discord, we discussed a few adjustments that I will list out in the issue. Don't worry about subexports; it probably isn't worth spending time on since we have a division between the react stuff and the utility stuff now.


App doesn't start on Windows 11

I both installed it and then tried without installation (zip file).
It doesn't start.
Edition	Windows 11 Pro
Version	23H2
OS build	22631.4317
Processor	13th Gen Intel(R) Core(TM) i9-13900K   3.00 GHz
Installed RAM	128 GB (128 GB usable)

I tried both v1.2.8 and v1.2.9 beta and they both worked for me when starting them from a .zip file.

What version of mrv2 are you trying and where are you downloading it from?
Can you fire it from the command-line (cmd.exe, Windows terminal, etc) and see if you get any errors?

Downloaded from here, github, both v1.2.8 and v1.2.9 beta
vie commandline it tells me:
ERROR: RtApiWasapi::getDeviceInfo: Unable to retrieve device mix format.

I am sorry to say, Chris, that this is one of the long standing bugs in mrv2.  It seems this is the same issue as that of #194.  So far you are the second person that reports it.  It seems to happen with some audio cards.  Unfortunately, I don't have a way to test it or debug it.
As a final test, please do this:

Update your audio drivers and see if that addresses it.
Make sure you don't have any applications that use audio running.
Start mrv2 again from the command-line and use the -log option to see what it prints out.  Report it back here.
Upload an image or description of your audio setup here to see if there's a correlation between your setup and that of #194.

It happened because usually I do not install the audio driver of my nvidia graphics card. Just the display driver.
My mainboard has it's own sound and I didn't want to have those additional audio interfaces showing up.
Apparently this caused the error. I just installed the newest version of nvidia studio driver with the audio driver and it starts without an issue.


rm: different output from gnu

with
https://github.com/coreutils/coreutils/blob/master/tests/rm/d-2.sh
GNU:
rm: cannot remove 'd': Directory not empty
us:
rm: error: cannot remove 'd': Directory not empty

Probably fixed by https://github.com/uutils/coreutils/pull/2277, right?

Yup, we can close this.


(slightly) relevant - .binFBX Format

hey hey! is this the same format used for Alan Wake 2 assets? would one (theoretically) be able to use this repository to help reverse engineer the binfbx format to help import/export meshes and assets for the sake of mods? please let me know if this does not belong here or if it violates some copyright laws or something; i wanted to contact Kristof personally but his linked twitter is inactive and has DMs off :(

Hi @riverence ,
We did not use this repository for Alan Wake 2 and I can unfortunately not disclose any details about .binfbx, apologies.


wip: evaluate resource RPC

functionally works, but still needs some refactoring and tests

forgot to open this as a draft, I don't think I can change it now though 🤷

Codecov Report

Merging #118 (39b6298) into main (0fc1a50) will decrease coverage by 5.03%.
The diff coverage is 57.29%.

@@            Coverage Diff             @@
##             main     #118      +/-   ##
==========================================
- Coverage   95.01%   89.98%   -5.04%
==========================================
  Files          12       13       +1
  Lines        1424     1537     +113
==========================================
+ Hits         1353     1383      +30
- Misses         56      137      +81
- Partials       15       17       +2

Impacted Files
Coverage Δ

pkg/evaluation/manager.go
42.75% <42.75%> (ø)

pkg/resource/manager.go
95.83% <89.47%> (-0.55%)
:arrow_down:

pkg/policy/manager.go
99.06% <96.42%> (-0.52%)
:arrow_down:

opa/opa.go
67.77% <100.00%> (ø)

server/server.go
88.01% <100.00%> (+0.28%)
: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 0fc1a50...39b6298. Read the comment docs.


Show Login with SSO button when Dex is enabled

Proposed changes
Fixes #4236

Types of changes
What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

[x] New feature (non-breaking change which adds functionality)
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] I have signed the commit for DCO to be passed.
[x] Lint and unit tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[x] I have added necessary documentation (if appropriate)

Dependency

Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer:

@DarthBenro008 Can you also review this PR?

@Saranya-jena, I'm just checking in. Would it be possible to have this change in the next release?


First version of zabbix alert

This alert send metric by hit to a pair zbx_host/zbx_item configured in the alert.
`alert:

zabbix.ZabbixAlerter:
output_file_path: "/tmp/alerts.log"
zbx_sender_host: zabbix-server
zbx_sender_port: 10051
zbx_host: host
zbx_key: item
`

Any news on when this will merged?
Cheers.

Happy to merge once commented code is removed and documentation added

Commented code removed, doc added and all checks have passed. :) Thanks @Qmando

@Qmando has the next release of elastalert date to be published?

@Qmando is the doc provided enough?


querybuilder UI thinks 'query' is an unknown request parameter

The native query parameter is not included in the drop list.

model.queryString is available at https://github.com/vespa-engine/vespa/tree/master/client/js/app
the query builder does not support aliases (as of today)


Can't install pgroonga on Ubuntu 24.04 / Zulip Server 9.0

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04 LTS
Release:	24.04
Codename:	noble

Zulip Server version 9.0
d**@zulip:~$ sudo -i
root@zulip:~# crudini --set /etc/zulip/zulip.conf machine pgroonga enabled
root@zulip:~# /home/zulip/deployments/current/scripts/zulip-puppet-apply
Notice: Compiled catalog for zulip.<h***>.internal in environment production in 5.67 seconds
Notice: /Stage[main]/Zulip::Profile::Redis/File[/run/redis]/mode: current_value '2755', should be '0755' (noop)
Notice: Class[Zulip::Profile::Redis]: Would have triggered 'refresh' from 1 event
Notice: /Stage[main]/Zulip::Postgresql_base/Package[postgresql-16-pgdg-pgroonga]/ensure: current_value 'purged', should be 'latest' (noop)
Notice: /Stage[main]/Zulip::Postgresql_base/Exec[pgroonga-config]/returns: current_value 'notrun', should be ['0'] (noop)
Notice: Class[Zulip::Postgresql_base]: Would have triggered 'refresh' from 2 events
Notice: Stage[main]: Would have triggered 'refresh' from 2 events
Notice: Applied catalog in 1.12 seconds
Apply changes? [y/N] y
Notice: Compiled catalog for zulip.ru-central1.internal in environment production in 5.56 seconds
Notice: /Stage[main]/Zulip::Profile::Redis/File[/run/redis]/mode: mode changed '2755' to '0755'
Error: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install postgresql-16-pgdg-pgroonga' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package postgresql-16-pgdg-pgroonga
Error: /Stage[main]/Zulip::Postgresql_base/Package[postgresql-16-pgdg-pgroonga]/ensure: change from 'purged' to 'latest' failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install postgresql-16-pgdg-pgroonga' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package postgresql-16-pgdg-pgroonga
Notice: /Stage[main]/Zulip::Postgresql_base/Exec[pgroonga-config]: Dependency Package[postgresql-16-pgdg-pgroonga] has failures: true
Warning: /Stage[main]/Zulip::Postgresql_base/Exec[pgroonga-config]: Skipping because of failed dependencies
Notice: Applied catalog in 1.37 seconds

Zulip Server and web app version:

[ ] Zulip Cloud (*.zulipchat.com)
[x] Zulip Server 9.x
[ ] Zulip Server 8.x
[ ] Zulip Server 7.x
[ ] Zulip Server 6.x or older
[ ] Other or not sure

@zulipbot  claim

@franchb  I would like to work on this issue

It looks like this might be a bug with the postgres repository upstream; https://apt.postgresql.org/pub/repos/apt/pool/ is missing a 16 directory.

No that upstream repository is fine and unrelated to this bug.

#31486


/usr/local/opt/fzf/install not exist!

Category

[x] fzf binary
[ ] fzf-tmux script
[ ] Key bindings
[ ] Completion
[ ] Vim
[ ] Neovim
[ ] Etc.

OS

[ ] Linux
[x] Mac OS X
[ ] Windows
[ ] Windows Subsystem for Linux
[ ] Etc.

Shell

[ ] bash
[x] zsh
[ ] fish

When I use brew install fzf, /usr/local/opt/fzf/install this file not exist.
So I cannot use key binding ctrl + r ctrl + t. Why?

Thanks for the report. It looks like the recent update of Homebrew formula mistakenly dropped the file.

Should be fixed when https://github.com/Homebrew/homebrew-core/pull/14410 is merged.


closure size: strongswan depends on GCC

Issue description
This bloats the closure of networkmanager-applet.
Technical details

System: 17.03.1203.58e227052d (Gorilla)
Nix version: nix-env (Nix) 1.11.8
Nixpkgs version: "17.03.1203.58e227052d"
Sandboxing enabled: true

Caused, by the looks of it, by 7777b4cdbd5980bc45cf884ee7667bcd583ee562 which was added to fix #4925.

-lgcc_s only adds ${gcc}.lib which is < 5 MB.

Alright, not that then. My bad!

dontPatchELF = true; leads to RPATHS not being shrinked, though I'm not sure how it gets stuff like ${gcc}/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0 into RPATH anyway.

Just for note, this is the cause of dontPatchELF: https://github.com/NixOS/patchelf/issues/45. Seems quite hard to fix in patchelf, most likely the package source should be checked if the export of the lib symbol is intentional, which I doubt it is.

Bah, there apparently is deliberately a global variable named lib in strongswan...

It seems OK now.
$ nix path-info -rf. strongswan | xargs du -sc | sort -n
...
2616    /nix/store/mdm7f4mka3dqdkvj1nz8gckzzad1hqqq-iptables-1.6.2
3516    /nix/store/10lh4y4japz71ilb0yidzc9s5krhadnw-db-4.8.30
3616    /nix/store/9kr8r78bwk12050ppywfbhg1vrsd6dp8-openssl-1.0.2p
4536    /nix/store/7kg61ssbxfnqws8smp81k87ld1ir9i71-strongswan-5.6.3
5636    /nix/store/zk5zj2307zxaq7dx585yia3dn5k4qlsl-gcc-7.3.0-lib
8496    /nix/store/gj5qw8c2ji9cpa600gf1yxwcf3k89v98-openssl-1.1.0i
10772   /nix/store/wm8va53fh5158ipi0ic9gir64hrvqv1z-coreutils-8.29
26428   /nix/store/fg4yq8i8wd08xg3fy58l6q73cjy8hjr2-glibc-2.27
84184   total


build: bump vuepress

Need help here, I am not sure why some lines in pwa plugin can not be type-narrowed correctly.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

12 of 12 (100.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 57.896%

Files with Coverage Reduction
New Missed Lines
%

tools/helper/lib/node/page/text.js
1
79.31%

Totals

Change from base Build<PHONE_NUMBER>4:
-0.01%

Covered Lines:
1173

Relevant Lines:
1821

💛  - Coveralls


Unable to create vertex when the case class has optional parameters

Whenever there is an Optional parameter in the case class, a property with key __gs is being added by gremlin-scala to the vertex properties. Since we have the disabled the automatic schema maker, JanusGraph does not allow the creation of the property __gs without explicitly defining the schema for it, which results in the error.
java.lang.IllegalArgumentException: Property Key with given name does not exist: __gs
	at org.janusgraph.graphdb.types.typemaker.DisableDefaultSchemaMaker.makePropertyKey(DisableDefaultSchemaMaker.java:47)
	at org.janusgraph.core.schema.DefaultSchemaMaker.makePropertyKey(DefaultSchemaMaker.java:73)
	at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.getOrCreatePropertyKey(StandardJanusGraphTx.java:995)
	at org.janusgraph.graphdb.vertices.AbstractVertex.property(AbstractVertex.java:152)
	at org.janusgraph.core.JanusGraphVertex.property(JanusGraphVertex.java:72)
	at org.janusgraph.graphdb.util.ElementHelper.attachProperties(ElementHelper.java:80)
	at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsTransaction.addVertex(JanusGraphBlueprintsTransaction.java:122)
	at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsGraph.addVertex(JanusGraphBlueprintsGraph.java:140)
	at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsGraph.addVertex(JanusGraphBlueprintsGraph.java:59)
	at org.apache.tinkerpop.gremlin.process.traversal.step.map.AddVertexStartStep.processNextStart(AddVertexStartStep.java:91)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
	at org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
	at org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:200)
	at gremlin.scala.ScalaGraph.addVertex(ScalaGraph.scala:36)
	at gremlin.scala.ScalaGraph.addVertex(ScalaGraph.scala:40)
	at gremlin.scala.ScalaGraph.addVertex(ScalaGraph.scala:51)
	at gremlin.scala.ScalaGraph.$plus(ScalaGraph.scala:54)

We are using JanusGraph 0.3.0 and gremlin-scala <IP_ADDRESS> . The automatic schema creation of Janusgraph is disabled. How to resolve this?

Please post a minimal, complete and verifiable example, including build setup with all dependencies (e.g. build.sbt), ideally in a git repo. Thanks!

Hi @mpollmeier,
Sorry for the insufficient information provided. I updated the above comment and also
please find the complete example as asked for here. This example reproduces the above error.

sorry about the delay, I'm having a busy time right now.
thanks for the repo - what am I supposed to run to reproduce your issue after starting janusgraph?

That's fine, no problem with the delay. After you start the JanusGraph, you need to initialize the schema and run the object named Crud in the project. The readme of the project has the instructions about the same.

Your sample project seems to have a problem:
gremlin> graph = JanusGraphFactory.open('conf/janusgraph-cassandra-es.properties')
==>standardjanusgraph[cassandrathrift:[<IP_ADDRESS>]]
gremlin> defineGraphSchema(graph)
Adding this property for key [~T$SchemaName] and value [rtname] violates a uniqueness constraint [SystemIndex#~T$SchemaName]
Type ':help' or ':h' for help.
Display stack trace? [yN]y
org.janusgraph.core.SchemaViolationException: Adding this property for key [~T$SchemaName] and value [rtname] violates a uniqueness constraint [SystemIndex#~T$SchemaName]
        at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.addProperty(StandardJanusGraphTx.java:817)

Anyway, I just had a look and removing the __gs property was a TODO anyway, so I've just done that in https://github.com/mpollmeier/gremlin-scala/commit/2ddd6d015cf51bafa9ab826cd7e91814bed4e8a0, which should automatically be part of <IP_ADDRESS>. Let me know if that works.

Hi @mpollmeier
I tested it with the version <IP_ADDRESS> and it works fine.
Thank you.


feature: Add document property to owner

Summary

I currently work on an application based on microfrontends (MFEs) architecture. We have several teams working on different parts of the application and we currently use React.
Our setup consists on having each MFE contained in its own shadow root, having its own style and dependencices.
All the MFEs also use a component library that is based on webcomponents. Since different versions of the library are going to be used by different teams, we can't use the default window.customElements registry to store webcomponents.
We current use this polyfill that allows us to attach custom element registries to the MFEs shadow roots. The polyfill also attaches other functions to the shadow root e.g. createElement, importNode, etc... so it can be used as if it as a Document instance.
We also use React to render custom elements from the shadowRoot rather than window.
This is possible because when rendering elements, react will use the ownerDocument of the element passed to createRoot, so we can easily set the element's ownerDocument to be the shadowRoot itself and the render phase will use the custom functions attached to the shadow root. (this is where react gets the ownerDocument, search for getOwnerDocumentFromRootContainer)
I have been trying to use Solid as an alternative to react in our application.
One thing that is preventing me from that is the fact that when rendering templates with custom elements, solid always uses document.importNode, there is no way to change it to use documents other than window.document.
So my idea was to make it possible to change the document that is used for rendering.
The idea consists on two small changes on this project (this PR), and on dom-expressions.
In this PR I added a new document property to owners when solid's createRoot and createComputation are called (not sure if it is needed on computations).
When child owners are created, I copy the document ref to make access easier.
One thing that concerns me is that the signal.js file there are no mentions to any DOM apis/types. So maybe that could be done in another way. In any way, the owner.document property is never used, just set.
In the dom-expressions PR I make two changes to the client.js file, one in the render function, it now always pass a owner to createRoot, that owner contains the document property set to the root element's ownerDocument.
And in the template function, instead of just calling document.importNode, it uses (getOwner().document || document).importNode.
How did you test this change?

This is my first PR in solid, I did not find much information on how to create a test build for both projects at once.
Since the amount of changes is very small, made the proposed changes directly to the solid dist files in my node_modules directory to verify that it works.
All existing tests on both projects also passed, I'm not sure if a test is necessary on this PR, it is just a new optional property on Owner. Maybe on the dom-extensions PR, but again, minor changes to render and template function, which I think are being tested already.

I have to think about this. The core library is agnostic. It isn't aware of the DOM. So patching owner doesn't feel right. But I'm not sure how else to get that in as I haven't thought about it.

Another implementation suggestion is to replace document in Owner by a reference to the root owner or any unique object/symbol that can be a index in a weakmap.
Then, on dom-expressions, a weakmap whose keys are the root owner (or symbol) and values the elements' ownerDocuments
setup in the render function, could be used to get the correct ownerDocument in the template function.
That makes signals.js platform agnostic again.
I can update this PR or create another one with the alternative implementation if you think it is more interesting.

This is better.. only thing I want to check now is that this doesn't tie our hands on the Solid 2.0 reactivity design. I don't know if we want to look roots through like this. It is probably harmless, but I don't want to depend on something that we may change.


JS/TS detect all syntax errors in RegExps.

VSCode detects some syntax errors in RegExps in JS (e.g. /[/ gets squiggles and a helpful message on hover), but it misses many others
As you know, in JS (And thus TS), Unicode regexps have a grammar that's incompatible with legacy, non-u ones, and it should be taken into account.
All of these are invalid, but are not marked as such:
/\b+/ // can't quantify assertions

/^+/ // can't quantify assertions

/$+/ // can't quantify assertions

/(?<=)+/ // can't quantify assertions

/(?=)+/u // can't quantify look ahead assertions in u mode

/]/u // syntax characters must be escaped in u mode

/{a}/u // syntax characters must be escaped in u mode

/\-/u // non-syntax characters must not be escaped in u mode

/\1/u // orphan back reference in u mode

/\k<OrphanNameRefWithUFlag>/u

As mentioned in https://github.com/microsoft/vscode/issues/148612, I'm working on a RegExp tokenizer that may be useful to implement this.


docs: fix the figure src

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

Project coverage is 92.08%. Comparing base (56dca26) to head (0d3a6a4).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #72      +/-   ##
==========================================
- Coverage   97.58%   92.08%   -5.51%
==========================================
  Files          11        4       -7
  Lines        1036      278     -758
==========================================
- Hits         1011      256     -755
+ Misses         16       13       -3
  Partials        9        9

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


Precheck cannot check In-app purchases with the App Store Connect API Key

New Issue Checklist

[X] Updated fastlane to the latest version
[X] I read the Contribution Guidelines
[X] I read docs.fastlane.tools
[X] I searched for existing GitHub issues

Issue Description

When releasing through Fastlane, i'd run into an error: fastlane_core/ui/interface.rb:141:in 'user_error!': [!] Precheck cannot check In-app purchases with the App Store Connect API Key (yet). Exclude In-app purchases from precheck or use Apple ID login (FastlaneCore::Interface::FastlaneError)
I immediately jumped into my AppStoreConnect console however was confused to find the app didn't support any In App Purchases (IAP).
I dug a little deeper and saw mention of in_app_purchases being checked in the precheck stage. Since the app itself it quite simple, I don't run any of these.
I was at a loss. But then I dug further and noticed the failing step was not pre-check, it was instead upload_to_app_store;

I then dug deeper and found out that by default the build step upload_to_app_store runs precheck for me, and by default checks for IAP.
This was causing my build to fail no matter what, regardless of if I supported it or not.
By parsing the option precheck_include_in_app_purchases: false to my upload step like so:
upload_to_app_store(
	precheck_include_in_app_purchases: false
)

I could now successfully release to the app store.


Remove publish target from artman and config

Remove (github and local) publishing artman configs, as these are not needed by ACTools or Yoshi team.
This reduces the size of the artman configs.
The old artman.tasks.publish.noop file is renamed as artman.tasks.emit_success, which more accurately describes that task.
In the CircleCI smoke tests, change all publish targets to generate.
Eventually, we would be able to remove the generate target because it's the only option, and it would be frivolous to specify it if there are no other options.

Waiting for smoke tests to pass before sending out for review.

PTAL

Because googleapis is synced from internal repos, wouldn't the changes get overridden by internal pushes?

Sure.

Of course - the change would need to be done in the internal files (I thought that was implied...)

Any changes made to the internal files would get overridden as soon as an API producer regenerates or bootstraps a config using a version of artman without this PR.

API producers won't regenerate artman files. In the case of config bootstraps, I think we can handle the 0-2 cases that might happen in the "gap" on a one-off basis.

Ok, made an internal PR for removing all instances of the publish_targets.
Also made an internal PR for deprecating g3artman.

I think you mean a PR to deprecate the publish feature in g3artman?

Ok, (1) and (2) are done!
PTAL


Add support for "low" option to Bar chart.

Currently bar.js has a hard coded referenceValue = 0 when creating the axis. This prevents positive "low" values from being specified and allowing you to zoom-in on the graph as the documentation suggests.
I have made changes to allow the referenceValue to be overriden by the "low" option if specified, thus allowing the value axis to start from values other than zero.

Hi there! Thanks for the PR. Can you tell me more about the usecase of this feature? I guess this has never been really working very well for the bar chart. However, your PR does not account all cases I think. The problem is also with the high option. If you specify a high value below zero you get the same issue. We should rather use Math.min and Math.max to ensure the reference value is always larger or equal than low and always smaller or equal than high. I've also noticed that the bars get drawn into the padding of the chart which should probably also be prevented during the drawing process of the bars.

Hi Gion, this is what we were trying to get working... when all the series values are close together, we wanted to be able to start the value axis a lot closer to the actual values, rather than zero.
var data = {
	labels: ['Audi A3', 'MINI Paceman (13 on)', 'BMW 1-Series', 'Volkswagen Golf'],
	series: [
		[325, 330, 330, 341]
	]
}

var options = {
	axisX: {
		labelOffset: {
				x: -10
		},
		labelInterpolationFnc: function (value) {
				return value + 'L';
		}
	},
	axisY: {
		offset: 100
	},
	horizontalBars: true,
	low: 315
};

new Chartist.Bar(chart[0], data, options);

If a low option isn't specified, I think the axis should work as it currently does and start from zero (even using AutoScaleAxis). I haven't encountered any problems using a high option yet, as long as it is greater than that actual values.
cheers
Rich

I've fixed some of this stuff in the context of making the bar chart axes dynamic. Can you test again with the dev branch?

Yep, works for me. Thanks!


Differences in jruby and mri json output

I often have the problem that there are minor differences between the output of an approval test in jruby and mri. We run our tests in both rubies so the approval test always fails for such cases in one of the rubies.
An example of this is that the following generates different approvals in jruby and mri:
verify(format: :json) { { weight: {} } }

In jruby:
weight: {

}

in mri:
weight: {
}

Is there any way to avoid this?
The problem seems to be jsons pretty_generate: https://github.com/kytrinyx/approvals/blob/master/lib/approvals/writers/json_writer.rb#L11
jruby:
JSON.pretty_generate({ weight: {} })
=> "{\n  \"weight\": {\n\n  }\n}"`

mri:
JSON.pretty_generate({ weight: {} })
=> "{\n  \"weight\": {\n  }\n}"

@Goltergaul I didn't realize there were differences between the two rubies.
I can see a few things we could do (there are likely other possible approaches as well).

don't use pretty-generate; minimize the whitespace as much as possible, so that we don't get problematic whitespace differences.
override pretty_generate in one environment to match the other
submit a patch to JRuby to make it behave the same as MRI

Of these I think maybe removing all the whitespace is the most reasonable approach, though that would be backwards incompatible, and would require a major version bump.
Having said that, we could add a flag/option so that the default is to use pretty generate, but if the flag is passed, then generate the JSON with no extra whitespace. That would be backwards compatible, and would still let you generate consistent (one hopes) output in both Rubies.
Thoughts?

@kytrinyx leaving out the pretty generate will it make too hard to spot differences in the approvals. Maybe we could use a pure ruby json serializer like https://github.com/flori/json ,this should yield the same json regardless on the platform. Might be a bit slower but this can probably be ignored for tests.
what do you think?

If it's just a few cases you could consider 'fixing' jruby's output. Maybe it's just stripping whitelines between braces?

leaving out the pretty generate will make it too hard to spot differences in the approvals.

You're absolutely right.

Maybe we could use a pure ruby json serializer

That could work, and I'd be fine with something that is a bit slower, if that lets the gem be more reliable.

If it's just a few cases you could consider 'fixing' jruby's output. Maybe it's just stripping whitelines between braces?

This is definitely worth trying—it might be a very small hack.
Another thing I realized could work (but I'm not particularly enamored with the idea) would be to do the serialization twice once with whitespace and once without it—verify on the one without it, but have the unminimized one to compare for humans. Wow, even just saying it out loud makes me like the idea even less :-)

If it's just a few cases you could consider 'fixing' jruby's output. Maybe it's just stripping whitelines between braces?

Might be. I'm not entirely sure what else is different or if there are other scenarios where this is different. Having the same serializer would be safest though. Unfortunately I could not really find a good one yet

Not sure if the non-pretty one could also have differences though.

Yeah, that's true. It could be worth a 30 minute experiment to find out.

what if we would not compare the json strings but the parsed version? If there is a difference we could show the diff of a pretty generated version of both the expected and actual hash?
So what i mean: verify(format: :json) { some_hash } would read the expected json string from the approval file, parse it and then compare it to JSON.parse(JSON.generate(some_hash)). If there is a difference then we can generate a pretty version of some_hash and the parsed version of the approval file and diff that one?

I'll try this one out and do a PR if that is alright @kytrinyx


Display Info Page

The display info page is still an option in the settings. Either the feature was removed or is no longer functioning as the info page does not come up before starting the game.

It is dependent on the theme you use...
I was strongly against that kind of implementation (NOT the info-page in general, but the way HOW it was implemented), but @Jay-Jay-OPL advised to implement it this way and I gave up the discussion back then, because I knew these kind of things would happen and I knew that the implementation probably would be changed according to my suggestions... Well... @ifcaro made the best out of it what was possible, based on the suggestion...
However... It is still that way and one reason, why it is not called 'OPL 1.0'...
Thank you for submitting that issue!

@TnA-Plastic
I see, so it just no longer appears in the default  theme? Can the info page just be mapped to L3 or R3? Just a suggestion. I haven't figured out how it works yet as I'm still to asleep to figure it out from looking at the code.

AFAIK, it didn't ever appear in ifcaro's repo, but only (possibly) on OPL-DB!
Yes, technically it could and that would be my approach/suggestion as well...
Info-page would not. Be dependent on a theme and it also would not force the user to see it, before a game starts! ;)

I posted the very same idea of implementation 8 years ago (or so...).
However... @Jay-Jay-OPL thought, his implementation would be better and (s)he did WANT TO understand the consequences...

Ok thank you @TnA-Plastic . Just a heads up my project has the potential to bring an influx of fanboys into the scene as it works and looks much better on real ps2 hardware than on an emulator. So if you see an increase in users it may be why but I can only hope so much.

Would you mind creating a Thread on a scene-board like psx-scene.com, assemblergames.com, Psx-place.com, etc.?
What is your project all about? ;)

@TnA-Plastic I will when the time comes. It is just a importation of a fan translation so there is also the potential that it goes entirely unnoticed.

Well then... Go for it! It's nice to have some new contributions to the PS2-Homebrew-Scene...;)


json_parse: NUMBER_ERROR: Problem while parsing a number

Bug description
TEST_F(JsonFunctionsTest, jsonParse) {
  const auto jsonParse = [&](std::optional<std::string> value) {
    return evaluateOnce<StringView>("json_parse(c0)", value);
  };

  auto x = jsonParse("[233897314173811950000]");
}

VeloxUserError
Error Source: USER
Error Code: INVALID_ARGUMENT
Reason: Problem while parsing a number
Retriable: False
Context: json_parse(c0)

presto> select json_parse('[233897314173811950000]');
          _col0
-------------------------
 [233897314173811950000]
(1 row)

Meta: 20231215_004903_00428_65rj9
CC: @kevinwilfong @amitkdutta @kagamiori @kgpai @bikramSingh91 @duanmeng @laithsakka
System information
n/a
Relevant logs
No response

CC: @Yuhta

Might be related: https://github.com/simdjson/simdjson/issues/167

In standard C++, we have 64-bit, 32-bit, 16-bit and 8-bit integers and well as 64-bit, 32-bit,  and  16-bit floating-point integers. None of them can represent the value provided.
We can try with a 64-bit integer (uint64_t). The number233897314173811950000 which is 0xcadfa3000000001b0, is much larger than what an unsigned 64-bit integer can store, which is 0xffffffffffffffff, so no luck there.  There are 128-bit integers as extension of some systems (e.g., GCC), but they are not standard (e.g., won't work with Visual Studio).
You can also parse it as a double (64-bit floating point integer):
#include "simdjson.h"
#include <iostream>

using namespace simdjson;

int main(void) {
  padded_string json = R"( [<PHONE_NUMBER>73811950000 ])"_padded;
  ondemand::parser parser;
  ondemand::document doc;
  if(auto error = parser.iterate(json).get(doc); error) { std::cout << error << std::endl; return EXIT_FAILURE; }
  double val;
  if(auto error = doc.at(0).get_double().get(val)) { std::cout << error << std::endl; return EXIT_FAILURE; }
  printf("%.0f\n", val);
  return EXIT_SUCCESS;
}

This will print<PHONE_NUMBER>73811949568 or 26591046*2**43.
From the string "233897314173811950000", you parse the integer<PHONE_NUMBER>73811949568. Is that what you wanted? The simdjson will do it for you if that's what you want, as demonstrated above...
You have to decide what you want to do with it. If you want to store it using your own type, then you can get access to the raw type and then provide your own parser (e.g., to MyDecimalType or to MyBigIntegerType). The simdjson library provides this functionality as well.
What the simdjson library does not provide is a custom big-integer or decimal type, because that's not standard. We do, however, make it easy for you to do your own parsing if you so desire. Please see the relevant section of our documentation.

@lemire Hi Daniel, thank you for detailed response. I understand what you are saying. This issue came up from a larger query, specifically, from this piece:
CAST(
    "json_parse"(logit) AS array(real)
)

Presto can execute this query successfully, Velox fails during json_parse because of the error above.
presto:di> select cast(json_parse('[233897314173811950000]') as array(real));
     _col0
----------------
 [2.3389731E20]
(1 row)

In the actual query 'logit' is a large array with mostly sane values. I trimmed it down to get a simple repro, hence, there is only one value in the repro and it looks kind of strange. ML users tend to be ok with some amount of garbage in the data and we would like to figure out a way to not fail queries like this. For context, we are trying to migrate existing workloads from Presto Java into Prestissimo and therefore cannot really afford failing existing queries.

@lemire Daniel, a side question, current error is not very informative: "Problem while parsing a number". Would it be possible to change it so it clarifies the problem and maybe includes the "wrong" number in the message? This would make troubleshooting a lot easier.

Would it be possible to change it so it clarifies the problem and maybe includes the "wrong" number in the message?
We are caching the error message so this will not be useful for us.  A better generic error message like "Number cannot be represented exactly" would be better

FYI folly JSON is also giving an overflow exception

@lemire Looks like ondemand is working in this case and won't giving error when parsing the top level document.  Unfortunately in our use case, we have to use the DOM parser for stricter validation, is there an option in DOM parser to ignore such errors first, and we will parse it second time using the ondemand parser when actually extracting the values?

ML users tend to be ok with some amount of garbage in the data and we would like to figure out a way to not fail queries like this.

You should probably parse it as a double (get_double()), right? I am not sure where the error occurs in your system, but I am going to guess that you are first trying to parse it as an integer, because that what it looks like... Normally, a system would serialize such a float value as something like '2.3389731417381195E+20'. Anyhow, it is written as an integer, but won't parse as such. It is hard to see how you can arrive at such a value, but a distinct possibility is that you had a decimal that got serialized. Or maybe it is meant to be a big integer?
https://github.com/facebookincubator/velox/blob/40557f810d011914f27f616b75bf59630b6e0d74/velox/functions/prestosql/SIMDJsonFunctions.h#L96
What you could do, if it looks like an integer, but it cannot be parsed as such (possibly because it overflows), is fallback and parse it as a double (thus losing precision but at least getting some value).
The simdjson library won't do that automatically for you... because that's unsafe in general... Consider:
> Double(UInt64(9223372036854775809)) ==<PHONE_NUMBER>854775808

So you have an identifier that you write as<PHONE_NUMBER>854775809. You parse it as a double, and serialize it back and get something that is equal to<PHONE_NUMBER>854775808. If<PHONE_NUMBER>854775809 was an identifier, you just accidentally changed its value. Think about ingesting JSON, and then outputting something that is accidentally different from the input !!!
If you know that is fine in your system, then you can parse it as a double... but the library cannot assume that it is.
This is should be an exceptional scenario: if this keeps happening, there it warrants further examination as there might be something more to it. But if it is exceptional, then the fix can be relatively expensive computationally without harm.

Would it be possible to change it so it clarifies the problem and maybe includes the "wrong" number in the message?

You can print the string content where the error occurred, see our documentation. You could also capture the raw_json() string_view and include it in the error message. It may be useful to indicate what you were trying to do at the time (error while parsing string X as a 64-bit signed integer). In fact, just reporting that the error occurred as you were trying to parse the number as an 64-bit signed integer (if that is what is happening here) would be illuminating.
If the string is just made of digits and you tried to parse an integer, then the only possible error is an overflow.  There are are few other rules, but they are quite limited. See section 6 of the RFC. Other errors include a leading zero (0123 is not allowed) or a leading + (+1232 is not allowed).

@Yuhta It is possible to build simdjson so that it will skip number parsing... SIMDJSON_SKIPNUMBERPARSING but that may not be what you want. We could create some macro that meets your needs... It is not very difficult engineering.
The failure comes around here...
https://github.com/simdjson/simdjson/blob/ebd09cb2a3ab421f04b404338c01b593ade5a08c/include/simdjson/generic/numberparsing.h#L591
We could add a VELOX-specific macro. Of course, it depends on what exactly you want to do.
(If you are using a single-header version of the library, you will find the same code... it just gets aggregated.)

We have handful of undocumented macros that fix specific problems in specific systems, adding one here would not be a problem.

@Yuhta Yep. That'd be fine.

@lemire Will you create the change?  Or I can submit a PR?

@Yuhta I'd prefer a PR because I am not sure exactly what you want to happen. If you make the changes, you can validate that it does what you want. I can help, but if you look at the code, you will agree, I think, that it should not be difficult.

@lemire Thanks I will create a PR then

Ping me if you want me to help!

@lemire I managed to solve this issue by using my own tree walker with ondemand parser, so the change in DOM parser is no longer needed


Log message : at fetchDataProviderValues when there are no test annotations for a speific class is vague

WARN  | 2022-06-06 08:09:54 | [main] phased.PhasedTestManager (PhasedTestManager.java:1158) - [Phased Testing]  The given phased test class does not have the Test annotation on it. Data Providers for Phased Tests can only be considered at that level.
Two problems exist:

The log does not say which class is the problem
We do not know if it is justified

The following test goes into the code:
com.adobe.campaign.tests.integro.phased.TestPhased_BEFORE_AFTER#testBEFORE_PHASE_onNonPhasedTest_failBeforePhase

If the method fetchDataProviderValues receives a non-phased test i should throw an excception


Count click of shared links

In my test with, the links were shared by WhatsApp and SMS, and it was counted as click, even though it was only the preview render of the shared link.
How can this be avoided? I can see no difference in $_SERVER['HTTP_USER_AGENT'] from normal click and the preview render.
Tks

It depends on the client. Some apps follow the URL to generate the thumbnail, hence it's the same behavior from YOURLS point of view as a "click"

No way to avoid this? The check statistics is wrong, and need the right count of clicks.

It depends on your use case. For instance if you share all links via Whatsapp and SMS, you could make a plugin that simply doesn't count the first 2 hits.


Implement support for SIM120

I am using Ruff 0.0.259.
I noticed that the rule SIM120 from flake8-simplify is not yet implemented. While this particular rule might become less relevant over time, I just today dealt with a legacy project which still had that issue.
I think this particular rule would lend itself to be automatically fixable too.
It would be great if it could be considered to implement this rule.

That's right -- we support it under pyupgrade, rather than under flake8-simplify.


Improve default max length logic for text generation

Make the following improvements in deriving the max length field for text generation.

Use model.config.max_length if it's not the default value
Else use tokenizer.model_max_length if available

This logic should be added

This logic should be revisited when transformers==5.0.0 is released.
How to derive model_max_length/max_length/max_new_tokens is an open discussion item and likely will lead to txtai changes with transformers V5.


About library volpy

Hi!
I am trying to use your library volren, but volpy is not included in the requirements.txt. After I installed volpy from (https://github.com/agu3rra/volpy/tree/master), an error turns out "module 'volpy' has no attribute 'vec3' ".
Could you provide more information about the volpy library you are using? Thanks in advance.

Hi!
Thanks for your interest in this work. This renderer is based on C++ instead of Python and "volpy" are Python bindings built with the renderer as a pybind embedded module, see https://github.com/nihofm/volren/blob/master/src/bindings.cpp#L63.
This means you can not run this like your standard Python library, but have to compile this program using CMake and pass the Python scripts to the C++ program at runtime, where it is used as a scripting language for automated datageneration for example, as in the README: https://github.com/nihofm/volren?tab=readme-ov-file#python-scripts

Thanks for your quick response! I have solved the Python binding.
By the way, do you know what the requirement is for Dicom images? For example, is there any normalization of the values?
In my case, the rendered result of dicom images is a cube... However, it should not have been like this.
Would you happen to have any idea about this, by chance?

I don't think there's a strict requirement for Dicom images, however I am not 100% sure since I am relying on the Imebra (now Dicomhero) library: https://imebra.com/wp-content/uploads/documentation/html/html/index.html. Before rendering, the range of values in the volume is re-normalized to [0, 1], which simplifies further usage and allows for compression.
I think it is likely you are visualizing the raw volume data without transfer function, which usually resolves to a cube. You can either pass 'data/lut.txt' as an additional argument to the viewer to use the provided example transfer function, or hit 'F1' to enable the debug menu in the renderer, where you can add and remove some example transfer functions and adjust the windowing.


Typos

Thanks for the corrections!

No problem, I'll take a look at some of your other task too :+1:


MySQL 5.7 bug for null value in timestamp column

Checklist:

[x] I've included the version.
[x] I've included reproduction steps.
[x] I've included the workflow YAML.
[x] I've included the logs.

What happened:
Installation of Argo fails while applying the MySQL YAML manifest for MySQL 5.7 version with error message.
Error 1067: Invalid default value for 'finishedat'
INFO[0000] applying database change
change="alter table argo_archived_workflows modify column finishedat timestamp not null"
changeSchemaVersion=16
2020/05/02 18:28:50
Session ID: 00001
Query: alter table argo_archived_workflows modify column finishedat timestamp not null
Error:  Error 1067: Invalid default value for 'finishedat'
Time taken: 0.00199s
Context: context.Background

What you expected to happen:
Expected the installation to succeed.
How to reproduce it (as minimally and precisely as possible):
1. Replace the version of mysql from 8 to 5.7 by changing the image in manifests/quick-start/mysql/mysql-deployment.yaml
2. make start

Anything else we need to know?:
Environment:

Argo version:

$ argo version
argo: v2.7.6+70facdb.dirty
BuildDate: 2020-04-28T17:09:06Z
GitCommit: 70facdb67207dbe115a9029e365f8e974e6156bc
GitTreeState: dirty
GitTag: v2.7.6
GoVersion: go1.13.4
Compiler: gc
Platform: darwin/amd64

Kubernetes version :

$ kubectl version -o yaml
clientVersion:
  buildDate: "2020-01-18T23:30:10Z"
  compiler: gc
  gitCommit: 59603c6e503c87169aea6106f57b9f242f64df89
  gitTreeState: clean  gitVersion: v1.17.2
  goVersion: go1.13.5
  major: "1"
  minor: "17"
  platform: darwin/amd64
serverVersion:
  buildDate: "2020-01-18T23:22:30Z"
  compiler: gc
  gitCommit: 59603c6e503c87169aea6106f57b9f242f64df89
  gitTreeState: clean
  gitVersion: v1.17.2
  goVersion: go1.13.5
  major: "1"
  minor: "17"
  platform: linux/amd64

Message from the maintainers:
If you are impacted by this bug please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

Fixed in #2933


Change "Check Password Health" to "Check Password Integrity"

Change "Check Password Health" to "Check Password Integrity" for asking AD about password expiration date.

Kept Check Password Health method with expiration date check on.


No space between sentences

I'm not sure if this is a feature or a bug. When the Bible reference appears, there are no spaces between sentences (e.g., This is Sentence One.This is Sentence Two). Is this a function of the API (Bolls)?
Thanks for a great plug-in,
Robert

Thanks for the feedback, it might be a bug, I will have a look, this wekk

this would be fixed in version 1.1.0


Improve CRD defaulting for HostedCluster and NodePool

This PR is part of an effort to improve the overall API defaulting for the HostedCluster and NodePool objects. The goal to begin transitioning defaulting logic that currently lives within the client tooling (hypershift/hcp) and make these same defaults function when someone is using the API directly.
This PR contains the following generic changes

HostedCluster Network CRD defaults
NodePool  NodePoolManagement, UpgradeType, and AutoRepair CRD defaults

and the following kubevirt platform specific changes

NodePool KubeVirt platform CRD defaults
NodePool mutating webhook initializes kubevirt platform spec when Kubevirt platform is in use in order for CRD defaults to be applied
HostedCluster mutating webhook initializes some dynamic kubevirt values related to the baseDomainPassthrough features and the generateID (which is used for external infra)

@enxebre would you be able to take a look at the _types.go changes in this file to make sure they align with how you all want to handle crd defaulting? The goal of this PR is to begin performing the same defaulting our client performs on the backend. This is part of an effort to make the NodePool and HostedCluster APIs easier to use directly.

/test e2e-aws


Printing state tree

I couldn't find any option to print the state tree , my state tree has gone too big,  would like to review and optimise it.
Sample of my state tree.

Go to chart > Export button on the redux dev tool doesn't work :(

import React from 'react';
import { createDevTools } from 'redux-devtools';
import LogMonitor from 'redux-devtools-log-monitor';
import ChartMonitor from 'redux-devtools-chart-monitor';
import SliderMonitor from 'redux-slider-monitor';
import DockMonitor from 'redux-devtools-dock-monitor';
const DevTools = createDevTools(

);
export default DevTools;

As far as you mention the Export button, you're using the extension. If so, just open a new window monitor (click one of the first buttons on the bottom) and then press Command (Control) + P, so you can print to PDF or whatever.

There's also a suggestion to export the graph view in a nicer format in case someone is willing to contribute on implementing that.

Yes, thats correct , using the extension. I would love to contribute, but i am an amateur in redux

I've implemented a print button:

The pr is here, will publish it soon, not sure it will land in the next version of the extension though.
Regarding https://github.com/zalmoxisus/redux-devtools-extension/issues/157, if you want to give it a try, there's no need to dig into Redux. Just get the state via store.getState and add a transformer to gnuplot or whatever else, then we can add it also in the extension.

Implemented in<EMAIL_ADDRESS>See the release notes.
It didn't work as expected when invoked from devpanel (hangs the browser under some circumstances). So, to have this feature, open the extension in a window (one of first buttons from the bottom).
Let me know whether it works for you.

Many thanks for the print button. It works fine for a small state tree. But doesn't work for mine. Mine is a enterprise application, and the print is failing to show the full chart at step 1.
Please find attached the JSON and PDF for review.
StateChart_Login_Step1.json.txt
StateChart_Login_Step1.pdf

Don't know why the svg is stripped. Will dig into it.
If you want to help to experiment with printing styling, just do npm i && npm start for remotedev-app . The styling is here.

Sure. Did the below.

removed my node modules
removed the redux devtools extension and
did npm instal
then npm start
5. strange the print button not appearing in chrome devtools now. (its v
<IP_ADDRESS>) I saw print button in 2.8.0 yesterday

attached my npm shrinkwrap
On Sat, Oct 15, 2016 at 5:48 AM, Mihail Diordiev<EMAIL_ADDRESS>wrote:

Don't know why the svg is stripped. Will dig into it.
If you want to help to experiment with printing styling, just do npm i &&
npm start for remotedev-app https://github.com/zalmoxisus/remotedev-app.
The styling is here
https://github.com/zalmoxisus/remotedev-app/blob/master/src/views/index.jade#L28-L48
.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/gaearon/redux-devtools/issues/318#issuecomment-253888652,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKObe5L5sZ2G7y6R9Nwfxjuh5noeB-mRks5qz86JgaJpZM4KSPtl
.

Hey @raaone7,
I already fixed that issue in https://github.com/zalmoxisus/remotedev-app/commit/5905d1753e5a5756f484094e034133585fb279c3, will publish a new release of the extension by tomorrow. Yes, I removed the button as it didn't work as expected.
Regarding  remotedev-app repo, it's a web version and the core lib of the extension. To use it as a standalone web app, you have to use remote-redux-devtools instead the extension for your store enhancer.

Published in<EMAIL_ADDRESS>Feel free to reopen the issue if something else goes wrong.

Thanks Again, It has progressed well.
Couple of issues found :-

Export button is broken, cant export JSON now
The pdf of A3 landscape (very decent size) is not fitting correctly. I thought it will resize and fit the screen.  (this is a little complex chart,but not the most complex one, i will try it once the fix is stable)

state-chart-little-complex.pdf
Not able share the JSON, since the export is broken.

Thanks for the details.
Yes, it's not resized and fitting now, which is on purpose to be able to align and change the size to be printed as you want. Though, you're right we could check if it is outside of the visible area and fit it explecitely in this case. Which better to address in a separate issue on the extension or remotedev-app repo. In case you want to submit a PR it should be what we did here, but I guess without changing scale and only when translate makes it to be outside.
Regarding the exporting, could you please open a separate issue about this on the extension repository so you can track it? It has a limit of the data equal to url length. So, the only solution would be to exclude intermediate states (in case we still want a downloadable link).

@raaone7, I have just published 2.8.2, where those issues should be fixed. Let me know whether it helps.

Fantastic work @zalmoxisus  Print is working as expected and so does the export.   This will help the broader community for sure.
Do i need to submit any more issues of tracking ? Apologies , i have been lazy in reporting and busy in developing ;)
state-chart-complex.zip
state-chart-complex.pdf
On a side note, kindly drop an email with your address. I would like to send you some cookies for your help as a token of thanks.

No probs :) If you have any other suggestions or troubles there, feel free to open issues on the extension's repo. BTW, your email is private, you can ping me at zalmoxisus at gmail dot com.

Not sure, if its possible to get a Radial Tidy Tree using D3. That will be very helpful, if we have both views.
http://bl.ocks.org/mbostock/4063550

Yes, it would be amazing indeed. We'll look into it, thanks for pointing out.

Ya, my state tree can't render.  Adding about 400 entries right there.  Is there a way to get around this issue?


HRR State machine update

Please note that while we are transitioning from travis-ci to AWS CodeBuld, some tests are run on each platform. Non-AWS contributors will temporarily be unable to see CodeBuild results. We apologize for the inconvenience.
Issue # (if available):
#964
Description of changes:

Modify the way we advance through the state machine when a HelloRetryRequest is needed.
Update self talk tests to expect handshake type changes. Integ tests still work as expected for the server.
Client side is manually tested because we don't have a finalized method to select curves for the client.

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

Codecov Report

Merging #1682 into test will increase coverage by 8.25%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##             test    #1682      +/-   ##
==========================================
+ Coverage   79.79%   88.05%   +8.25%
==========================================
  Files         217      148      -69
  Lines       16275    10335    -5940
==========================================
- Hits        12987     9100    -3887
+ Misses       3288     1235    -2053

Moving into #1696

These changes will be merged in #1696


Implement facebook metatags on marker bookmarks

We have static meta tags for the app now (see e.g. e1ba6649db8a213d3ff82d53c73d150252c5bdf9).
Now we need to make them dynamic: if the URL contains marker= and a marker ID, then the marker details need to be included in the meta fields.


/etc/cups/subscriptions.conf should live in /var

I have /etc under version control and this file is automatically changed by cups, which means, that it stores data rather than configurations.
Even the documentation says "This file is not intended to be edited or managed manually." because it is maintained by cupsd.
So I think, /etc is the wrong place to store such information. A better place would be /var (sic!)

This will not be changed for the current generation of CUPS. Only Linux follows the FHS and it is entirely in the distributions power to change the default.
Also see the discussion in the previous issues - at some point in the future we’ll likely change to a more efficient binary format for such things...

@jsmeix
The issue is not, how the configs are changed but what they contain.
cups/subscriptions.conf has a config called "ExpirationTime" or "NextEventId".
This looks to me like state and not like a configuration.

@michaelrsweet
But even BSD has /var/tmp
@jsmeix
The issue is not, how the files are changed but what they contain:
subscriptions.conf contains things like "ExpirationTime" and "NextEventId" etc.
This does not look like configurations which tell cupsd something about the environment it runs in but like state it maintains for itself. But /etc is absolutely the wrong place for maintaining state. Otherwise a database engine could also store its table files under /etc.

Just ran into this when I decided it's time to keep etc under version control. It's very annoying.
NextEventId 1117
is not configuration it's state and shouldn't be in a config file. I have one machine in my house where /etc/ is read-only and /var is a memdisk. It's that way to protect the (old) SSD from excessive wear. It's not running cups but if it was there would presumably be trouble.
It's fine have machine-generated and machine-maintained configs in /etc but that's a different thing.

I appreciate this, along with the numerous other reports of this as a problem, is a wontfix, and it's reassuring that the comment from @michaelrsweet at least leaves open the possibility of this changing in a future version of CUPS.
As notes for that future change, however, I'll highlight that this isn't about the FHS specifically, but about BSD, general/historical unix and specific macOS standards.  hier(7) on macOS says that /etc is for ‘system configuration files and scripts’, and the Apple Filesystem Programming Guide says that /etc ‘Contains host-specific configuration files.’  I do not agree that there is any reasonable definition of ‘configuration file’, on any unix flavour, which includes state information such as ExpirationTime and NextEventId, which are initiated by the daemon rather than the administrator.

I appreciate that there's some attraction to keeping this state information nearby the configuration information; that being attractive doesn't make this OK.
I appreciate there isn't a pre-ordained standard location for this, but /var is (according to hier(7)) for ‘multi-purpose log, temporary, transient, and spool files’, which seems to clearly indicate that this sort of state information should go somewhere under there (and /var/spool even says ‘misc. printer and mail system spooling directories’, so is a very obvious location for this).

If I instruct the daemon to change its configuration and as a result it rewrites a file in /etc, that's fine – that's my configuration change.  Bluntly, the daemon shouldn't be scribbling in my configuration files on its own initiative.


Fix very weird issue in xieite::math::stringify<>()

Sometimes gives very wrong results with floating-point numbers
Needs testing

hopefully I never have to touch this again


Bumping node version to node20

https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/

Could this also bump the recommended node versions to be consistent with node version 20 in:
https://github.com/endorlabs/github-action/blob/a8ac7b44747fcbe98d0e80ab2d4e91f7ab9028fa/package.json#L47-L48
https://github.com/endorlabs/github-action/blob/a8ac7b44747fcbe98d0e80ab2d4e91f7ab9028fa/CONTRIBUTING.md?plain=1#L22-L23


Adding and populating Reference section in main navigation

Reference section will contain: SDKs, Network->Futurenet, Releases

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Preview is available here:http://soroban-docs-pr284.previews.kube001.services.stellar-ops.com/

Preview is available here:http://soroban-docs-pr284.previews.kube001.services.stellar-ops.com/


feat: adding data analytics to demo

moved from: https://github.com/heyMP/rh-footer-demo/pull/3

Linking issue: https://github.com/RedHat-UX/red-hat-design-system/issues/393

@heyMP great. You might wanna archive that repo with a link to the official one


Add Scala 2.13 support, update dependencies

There are lots of different atomic commits here—I'd probably review them separately. A few of these could be separated out into different PRs if you prefer, but many of these are required to get the code to build and test against Scala 2.13 without deprecation warnings.
I would read the commits separately so it’s not too jumbled.
I'm happy to walk you through any of this if it'd be helpful. I've attempted to keep the code as similar to how it is today as possible (other than moving from a Build.scala to a build.sbt, as the former is a hindrance for a project like this one in SBT 1.x).

LGTM

lgtm 👍 thx


Support for inserting pyarrow list types in postgres

What feature or improvement would you like to see?
I would like to be able to insert arrow list type columns into postgres array type columns.

I think duplicate of #1882?

Ah yup, thanks. Closing.


Update README.md

The CC BY SA 4.0 is available on the readme.md for content and on the website.
please kindly review and feedback

The CC BY SA 4.0 is available on the readme.md for content and on the website. please kindly review and feedback

i have reverted the last commit and added the README.md changes to appear as content and on the website

It would be good to put that directly in the other Pull Request you opened

I can not see the changes in the README in the other Pull Request


Update platform_feature_flag_target_group.md

docs are wrong. this is the correct usage per the code and my testing
Describe your changes
Comment Triggers

PR Check triggers

Build: trigger build
Sub Category Field Check: trigger subcategoryfieldcheck
gitleaks: trigger gitleaks

 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.


Upgrade to libxml 2.9.7 and libxslt 1.1.32

Nokogiri 1.8.1 ships with libxml 2.9.5. However, libxml2 has shipped 2.9.6 and 2.9.7 since then:
http://xmlsoft.org/news.html
Consider upgrading for bugfixes noted in the changelogs.

PR #1689 merged into master and went green.


fix(frontend): do not show BTC text before onboard

Motivation
It was reported that the address loading modal was writing Bitcoin even if it is still not onboarded.

smarter! agreed! I will close this one and do a new one, to be cleaner


is possible to pass muti name for one category

It seems that the model will first find the names in label_names.txt to mask the original text.If the category name has never or rarely been in the train txt,small train materials will be used in the first step,so does it possible to add more words that are smililar to the category name to the label_names.txt.for example instead of post {0:"sports"},just post {0:"competion","players"},asuming that sports has never occured in the train materials

Hi @graceyangfan,
Thanks for the question. Yes, you can use multiple words as the label name of each category. In fact, there is not a strict definition of which words should be the "label name"--you can choose to use whatever words that can represent the category well and ideally frequently appear in the corpus. As mentioned in the README file, "if multiple words are used as the label name of a category, put them in the same line and separate them with whitespace characters". As an example, you could refer to DBPedia dataset where some categories have multiple words as the label name.
Let me know if you have any further questions!
Thanks,
Yu

@thanks for your replay, it really help me to understand the ideas in your paper


Define filters for git commits

We should come up with good filters to get rid of low quality commits. This could be done by going through a sample (e.g. 100) issues and working out patterns of low quality data.

I will take up this task.


Remove client dependency from faucet

closes #343
This PR removes almost all of the functionality implemented by the miden-client and replaces it with it's own implementation that doesn't depend on the crate. The new FaucetClient is stored in the state and wrapped with a mutex to allow concurrency (a feature that was removed in the previous version).
Some caveats:

We still have a small dependency. The InputNoteRecord type is needed in order to be serialized and imported by the user. We could change the miden-client to accept the Note type as it's import or move the InputNoteRecord to miden-base.
There's a small issue where if multiple transactions are sent at the same time, the node accepts the first one and rejects all others. This happens because of this verification.

We still have a small dependency. The InputNoteRecord type is needed in order to be serialized and imported by the user. We could change the miden-client to accept the Note type as it's import or move the InputNoteRecord to miden-base.

I didn't see where in the code we are currently using InputNoteRecord, but if we need it, my preference would be to create a struct in miden-objects (e.g., maybe something like NoteFile which is used specifically for serializing different note variants.

I didn't see where in the code we are currently using InputNoteRecord

Here. It's needed because the client can only import serialized InputNoteRecord files.

maybe something like NoteFile which is used specifically for serializing different note variants.

Created an issue for this in miden-base.

So, before merging this, we should probably address https://github.com/0xPolygonMiden/miden-base/issues/715 and propagate the changes here and to miden-client.

Creted a PR adding the new NoteFile object. Drafting this PR until that one is merged. We will also need to update the client to use the new serialized file but it's not a blocking change for the faucet.

@tomyrd - thank you!
@igamigo, @mFragaBA - could one of you take another look and then we can merge?

I see that this was merged into mFragaBA-next-0.4. Should we merge it into next?

I see that this was merged into mFragaBA-next-0.4. Should we merge it into next?

it will change the miden-base dependencies to point to the next branch since it was merged into mFragaBA-next-0.4, if we're ok with that then sure (we'll need to change it before release)

it will change the miden-base dependencies to point to the next branch since it was merged into mFragaBA-next-0.4, if we're ok with that then sure (we'll need to change it before release)

Yes - I think it is fine to have next branch here point to the next branch in miden-base.


New API to clear cache

Codecov Report

Merging #6374 (150344d) into dev (81d34b4) will increase coverage by 9.24%.
Report is 267 commits behind head on dev.
The diff coverage is n/a.

Flag
Coverage Δ

msal-angular
?

msal-browser
?

msal-common
?

msal-core
?

msal-node
?

msal-node-extensions
?

msal-react
94.24% <ø> (-0.45%)
:arrow_down:

node-token-validation
?

see 227 files with indirect coverage changes


Add vertical padding to the cells

Sounds like the natural next step. Can we call it something other than padding though? Perhaps RowSpacing?

Instead of calling our horizontal padding as Padding, I was thinking about having a Padding class as the property of the table. And then we can do something like this:
table.Padding = new Padding(topPadding, RightPadding, BottomPadding, LeftPadding);
table.Padding = new Padding(verticalPadding, horizontalPadding);
table.Padding = new Padding()
{
    Left = 1,
    Right = 2,
    Bottom = 1,
    Top = 3
}

Row spacing also sounds good though

That's an interesting idea. I suppose we need to think about how people will use it.
Will people care about setting left and right independently? Or will they just want a quick, easy way to give their data a bit more "room"? Can we implement this so that we introduce flexibility whilst preserving the simplicity?

Million people will use it in million different ways.
I think having multiple constructors addresses the problem of flexibility and simplicity. And for people who have strange requirements, I think we should give them the ability to set different padding for different sides. My current implementation is this:
public class Padding
    {
        public byte Left { get; set; }
        public byte Right { get; set; }
        public byte Top { get; set; }
        public byte Bottom { get; set; }

        public Padding(byte padding)
        {
            Top = padding;
            Right = padding;
            Bottom = padding;
            Left = padding;
        }

        public Padding(byte verticalPadding, byte horizontalPadding)
        {
            Top = verticalPadding;
            Bottom = verticalPadding;
            Right = horizontalPadding;
            Left = horizontalPadding;
        }

        public Padding(byte top = 0, byte right = 1, byte bottom = 0, byte left = 1)
        {
            Top = top;
            Right = right;
            Bottom = bottom;
            Left = left;
        }
    }

People who just want some "room" can get away by using the default constructor and people who want symmetric appearance can use the Padding(byte verticalPadding, byte horizontalPadding) constructor.

OK, this looks workable. 👍
When you're ready, let's see a PR.


Revisit logging to enhance observability

Revisit our logging, and move to a model that allows:

Distributed tracing concepts, such as spans with inclusion and correlation

Ideally this should map to spans at the service level, which would need to be implemented

Structured logging
Fan-out to multiple backends at different levels

Telemetry ingested by App Insights, ideally via OpenTelemetry
stderr, controlled by an env var
A circular VM-local log file

Since we use tokio, the tracing library with an OpenTelemetry backend would achieve all of the above.

Current ecosystem support for OpenTelemetry + Application Insights:
Rust
No first-party OpenTelemetry/App Insights support here, even at the Preview level. There is a third-party Application Insights exporter for the opentelemetry SDK crate.
All together, we can use tracing, opentelemetry, tracing-opentelemetry, and opentelemetry-application-insights to generate and export async-compatible span data. We can even export log-style events as App Insights Trace telemetry, correctly-associated with spans.

I don't yet see an off-the-shelf mechanism for Custom Events, but it seems like it'd be easy to add. We could also have a separate telemetry channel that uses the appinsights crate just for specialized telemetry like Custom Events. This may be specifically preferable for the optional non-identifying global telemetry.
Python
First-party support, but only in preview. May get some wins if we focus on spans (without events), or use libraries that are getting early attention for pervasive OpenTelemetry instrumentation (FastAPI?).
We can use OpenTelemetry with Python via opentelemetry-sdk/opentelemetry-api, and export spans to Application Insights via azuremonitor-opentelemetry-exporter. The latter is in preview. It currently appears to drop all span-associated events (#21747). Haven't yet checked if there's a way to auto-instrument logging to be span-aware, but seems unlikely (especially since the OpenTelemetry logging spec is not yet stabilized).

I don't yet see an off-the-shelf mechanism for Custom Events, but it seems like it'd be easy to add.

Confirmed, this was very easy to add to the exporter backend. The design question then becomes: how do we determine when a span-parented Event from tracing should be exported as Application Insights "Trace Telemetry", vs. a "Custom Event"? The presence/absence of a level field is not a viable cue, because all normally-created tracing events currently have a Level.
In the long run, OpenTelemetry Logging will make the "event"/"log message" distinction clear in a way that tracing libraries can propagate in a more principled way. In the short term, we wouldn't be any worse off than we already are (most telemetry would become "trace event" items). Exceptions are special-cased in the Rust backend. Also, Custom Events are not displayed in a nicer way in the Transaction Timeline view of Application Insights, nor are they in any way more queryable than Trace Events.
For our "Custom Events" that are more properly treated as metric data, there is a (now-frozen) OpenTelemetry Metrics API that has feature-flagged support in the Rust Application Insights exporter.


Parameters usability

I find current 'CommandArg[]' approach quite daunting, 'cose I am generating commands out of some other code and it should support different types like Vector3, Сolor, enums, etc.
It would be cool to have something like ReflexCLI way of doing things. So we can provide custom types
http://reflex.richardmeredith.net/documentation/index.php?title=Parameter_Processors
And it's possible to have commands like this:
    [ConsoleCommand]
    static int MultiplyAndFloor(float a, float b)

Which is ideal for usability, no workarounds needed

This is done for performance. If all commands have the same signature they can be stored as Action<CommandArg[]> objects, this way the methods can be called with comparable overhead to calling them directly in C#.
Allowing different signatures would require the command methods to be stored as MethodInfo objects and be invoked at run-time with reflection, which is significantly slower than the delegate version (~20x slower in my testing).
I figured the readability trade off was worth it for the performance gains. Letting the arguments be parsed in the command method lets you parse types of Vector3, Color, etc. on your front end code, instead of having a parser that accounts for every type people would want to use.
I really wanted to have proper parameters in commands like in your example, but I don't see a way to do it that doesn't compromise performance, or accounts for custom types.

Although invoking a MethodInfo is much slower than an Action<CommandArg[]>, I'm not sure the performance difference is really relevant for this situation. Computers are just so fast that the user won't ever notice the difference.
Your points about standardizing parsing logic for command input are very good, however.


Limitless led problem reagardin changin to color white when controlling the temperature

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
0.50.2
Python release (python3 --version):
Python 3.4.2
Component/platform:
limitless led
Description of problem:
When rgbww is colored and I want to adjust the temperature - it's possible but nothing happens. If color white is added to the config then the error with mutualy exclusive is thrown (scenes or scripts). Workaround is that first the color has to be switched to white and after that the temperature may be ajusted (impossible for scenes). This is a  issue since 0.49.
Expected:
If temperature is to be adjusted then color should be by default white.
Problem-relevant configuration.yaml entries and steps to reproduce:
    light.living_room_table_light:
      state: on
      brightness: 255
      color_name: white
      color_temp: 154
      transition: 3

Traceback (if applicable):
vi ~/homeassistant/components/light/__init__.py

line 116 produces the error

What version is your bridge?

v6

@happyleavesaoc Is there a possibility to default the color to white every time the color_temperature is modified?

Duplicate of https://github.com/home-assistant/home-assistant/issues/8587.


Expanded example?

I've been looking through this repos demo folder but can't see how to use this aside from needing to add it to the app.module folder. I'm using angular2/typescript and webpack, is there a more full example somewhere online that shows how to import/reference it in my component and component template?

I used it with webpack on my production project too.  The demo application should work. You don't need import/ref in your component. Import/ref should be in your module not component.

I imported in my module and am not getting any errors from that like it showed in the demo. What I mean is in my template, how do I use it to copy something. I tried referencing it like I have other directives in the past like <p ngIIclipboard>hello</p> but I feel like I'm missing something.
Trying to be specific, how to I use it in my template to tell it what I want to be able to copy.

Apologies, it seems I didn't look at the example closely enough. I think I found my answer

It is all good. Good luck with your project.