CLI: -File arguments don't recognize [bool] parameter values when passed as separate arguments

In response to #4036, passing Booleans to [switch] parameters was fixed.
However, the problem persists for [bool] parameters if you pass the value as a separate argument (-param value), which is the typical syntax; by contrast, -param:value (the form that you must use with [switch] parameters) works fine (but using : and whitespace - -param: value - is also broken).
While [bool] parameters are rare, there's no reason for them not to be supported.
Additionally, the -param: value syntax form (: separator and whitespace) also doesn't work with [switch] parameters, only -param:value does (:, but no whitespace).
Also, given that [bool] parameters (but not [switch] parameters) also accepts numbers inside PowerShell - notably 1 for $true and 0 for $false (e.g., & { param([bool] $p) $p } 1 yields $true) - passing numbers should be supported too.
Steps to reproduce
Describe "-File with Booleans" {
  BeforeAll {
    Push-Location testdrive:\
    'param([bool] $foo) $foo' > testB.ps1
    'param([switch] $foo) $foo.IsPresent' > testS.ps1
  }

  # [switch] parameter

  It "[switch] param: `$true can be passed with ':' and *no* whitespace" {
    pwsh -noprofile -file ./testS.ps1 -foo:`$true | Should -Be 'True'
  }
  It "[switch] param: `$true can be passed with ':' *with* whitespace" {
    # Note the escaped $, so that '$true' is passed as a string.
    # However, it should work even without escaping, in which case 'True' is passed.
    pwsh -noprofile -file ./testS.ps1 -foo: `$true | Should -Be 'True'
  }

  # [bool] parameter

  It "[bool] param: `$true can be passed with ':' and *no* whitespace" {
    # Note the escaped $, so that '$true' is passed as a string.
    # However, it should work even without escaping, in which case 'True' is passed.
    pwsh -noprofile -file ./testB.ps1 -foo:`$true | Should -Be 'True'
  }

  It "[bool] param: `$true can be passed with ':' *with* whitespace" {
    pwsh -noprofile -file ./testB.ps1 -foo: `$true | Should -Be 'True'
  }

  # A [bool] parameter - unlike [switch] - *requires* an explicit argument,
  # so you should be able to pass it with the customary value-as-separate
  # argument syntax.
  It "[bool] param: `$true can be passed as a *separate argument*" {
    pwsh -noprofile -file ./testB.ps1 -foo `$true | Should -Be 'True'
  }

  # A [bool] parameter - unlike [switch] - also supports *numbers* as arguments
  # where 0 is coerced to $false and 1 (any nonzero number) to $true
  It "[bool] param: 1 can be passed for $true" {
    pwsh -noprofile -file ./testB.ps1 -foo:1 | Should -Be 'True'
  }
  It "[bool] param: 0 can be passed for $false" {
    pwsh -noprofile -file ./testB.ps1 -foo:0 | Should -Be 'False'
  }

  AfterAll {
    Pop-Location
  }
}

Expected behavior
The test should pass.
Actual behavior
All tests except the ones with syntax form -foo:$true fail:
Expected $true, but got @('.../test.ps1 : Cannot process argument transformation on parameter 'foo'.
Cannot convert value "System.String" to type "System.Boolean". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.

Environment data
PowerShell Core 7.0.0-preview.4

Should we escape $ in $true?

@iSazonov
Good point, but it makes no difference here, because the target pwsh instance should recognized both literal strings $true and True, the latter being what is passed without escaping.
For clarity I've added escaping and a comment to the OP.
Note that the tests do succeed - both with literal $true and True - if you use the -param:value syntax (: as separator, no whitespace):
# OK: literal '$true'
pwsh -noprofile -file ./test.ps1 -foo:`$true

# OK: literal 'True'
pwsh -noprofile -file ./test.ps1 -foo:$true

It seems the same as:
> [bool]'false'
True

No, it's not the same: we're talking about the CLI here, where all arguments are of necessity initially strings, and you need some way to pass a Boolean when you use -File.
The inability to pass a Boolean with -File - still a problem in Windows PowerShell - led to the fix in #4036, but that fix was incomplete, which is what this issue is about.

I see two way:

enhance a binder so that for -File option it tries to convert string arguments to parameter types
enhance a workaround for switch so that always convert $true and $false literals to boolean.

We don't need new parameter-parsing functionality, we just need to amend (fix) a previous fix:
That fix was to allow literal strings $true, true, $false, false to be converted to [bool] when bound to [switch] or - less commonly - [bool] parameters when the CLI is used with -File.
This now works in principle, except in particular syntax forms, which should obviously not be treated any different than its equivalent forms.
As stated, -foo:$false works, but neither -foo $false nor -foo: $false do - even though these are just syntax variations.
Note that -foo $false - whitespace-only separator - is only applies to [bool] parameters, because with [switch] parameters you must use : (given that switch parameters never treat a separate argument as their value).
@SteveL-MSFT, you implemented the original fix in https://github.com/PowerShell/PowerShell/pull/4178 - does this make sense to you?

We don't need new parameter-parsing functionality,

If somebody run ps1 file in pwsh session and then do the same in command line (copy-paster) different behavior may surprise the user.

It may, but it shouldn't:
If you want the same behavior as inside PowerShell, invoke the CLI with -Command rather than -File.
It was a deliberate design decision to treat all -File arguments as literal string, at least initially.
This doesn't preclude later conversions when binding to the script's parameters, such as from string to [int], but it does preclude passing arguments such as @{foo=1} and (1+2) and expecting them to be evaluated up front, as expressions as they would inside PowerShell.
If you disagree with this design, I suggest you create a new issue.
An exception to the design was deliberately put in place to allow binding strings $true, true, $false, false to [switch] and [bool] parameters when binding calling via -File, as it would otherwise be fundamentally impossible to pass a Boolean via -File.
The issue at hand is that this exception wasn't implemented comprehensively.

However, there is one problematic aspect about how the exception was implemented, @SteveL-MSFT, though it may not matter much in practice:
The Boolean-like strings are unconditionally converted to [bool] - even if the parameter they bind to is untyped:
The right behavior is to retain them as strings in that event, just like a "number string" such as 1 remains a string when bound to an untyped parameter via -File.

Conditional conversion means a binder enhancement which is likely unjustified complexity.

@mklement0 seems like this is becoming a slippery slope.  At some point, it seems that using -Command is a good enough workaround.

I'm personally fine with leaving the unconditional conversion mentioned in my previous comment be, but I don't think there's anything slippery about the issue as original reported:
Supporting a feature in only one syntax form, but not in others that should always result in the same behavior is a baffling inconsistency that is well worth fixing.

@mklement0  Passing commands to an executable - any executable -  requires that the arguments be passed as literal strings because  that's what the operating systems support. All type information is lost so trying to get the exact semantics of calling a PowerShell function from within PowerShell is tilting at windmills. As @SteveL-MSFT says, after a while you have to accept good enough. If there's something that just doesn't work, then it needs to get fixed (encoding scriptblocks, Steve's fix) but otherwise it just leads to playing wack-a-mole with bugs.

@BrucePay: To succinctly recap my previous comment:
All that is needed is to fix the incomplete fix that was implemented in https://github.com/PowerShell/PowerShell/pull/4178, as detailed in the OP.

This is still an important issue.  I hit it today.  It still has not been addressed.  I request that it be re-opened.


SQLite DB state machine test failure.

Release
Operating System
Cause

next
Linux
Code

Context
First seen here:
https://hydra.iohk.io/build/1338908
https://hydra.iohk.io/build/1338908/nixlog/23
Steps to Reproduce
Run the following command:
stack build \
    --test cardano-wallet-core:test:unit \
    --ta '--seed<PHONE_NUMBER>' \
    --ta '--match "Sequential state machine tests"'

Expected behaviour
The tests pass.
Actual behaviour
The tests do not pass:
PostconditionFailed "PredicateC (Resp (Right (Metadata (Just (WalletMetadata {name = WalletName {getWalletName = \"charmander\"}, creationTime = 2096-07-20 08:00:00 UTC, passphraseInfo = Just (WalletPassphraseInfo {lastUpdatedAt = 2769-03-31 20:10:53 UTC}), delegation = Delegating (PoolId {getPoolId = \"de93c1d4404bded49254700a42172901\"})})))) :/= Resp (Right (Metadata (Just (WalletMetadata {name = WalletName {getWalletName = \"charmander\"}, creationTime = 2096-07-20 08:00:00 UTC, passphraseInfo = Just (WalletPassphraseInfo {lastUpdatedAt = 2769-03-31 20:10:53 UTC}), delegation = Delegating (PoolId {getPoolId = \"447f333b6d629daccfc965226e51b766\"})})))))" /= Ok

Resolution Plan

Revise the primary key on DelegationCertificate table
Use repsert instead of insert_, or make sure that the database fails if trying to insert at the same slot twice :thinking: ?

PR

Number
Base

#997
master

QA

Test was re-run 10k times after fix to control that everything was okay.

lgtm.


JSON quote rendering is not colorblind friendly

I can't read the red text in

Thanks @jmandel for the report!
Does this come out differently on the webapp? I.e. if you look at the same message, and also in dark mode.
(We generally use the same HTML for message bodies as the webapp, and try to keep the CSS similar.)
If it's the same, then we can fix it for both the same way; if it's different (and the webapp version works for you), then we should try to copy that :wink:

It's much better on the web app in night mode:

Thanks -- that's a very helpful comparison!
I notice a few things from looking at the two screenshots:

On web, the code block has a darker background than the surroundings. For us, it's a lighter background.

Looking at our CSS, it looks like we don't have anything specific for this in the night-mode case, so that's probably the root cause of this part.
We should probably just copy exactly the same CSS properties that the webapp sets.

The red for strings is quite light on web, and rather darker for us.

Darker red text plus lighter background -> probably pretty similar lightness, so that's probably the core of the problem for you.
Again we should probably just copy what the webapp has.

The webapp has something for the keys, too (they're in a light green, plus are bold), whereas we seem to leave them unstyled.

This part probably doesn't make as much difference for you one way or the other, but may be helpful for others.
And like other bits of this style, there isn't an obvious reason why the pros and cons of different choices would be different for us vs. the webapp -- so we should probably do the same thing as the webapp.


Task - Browse Collection Objects - Toggle panels on/off as preference

Probably user per project scoped in the metadata.

Duplicate of #3230.


Look at using zod to build all the API endpoints?

https://github.com/RobinTail/express-zod-api

So not happening.


Private repo problem

I've read #112 . I have the same problem. But I'm sure my repo was forked from a personal account.

I followed the Advanced Setup (with config)  to setup my forked private repo, grand permisstion to my forked private repo.

.github/pull.yml file looks like
version: "1"
rules:
  - base: master
    upstream: stackia:master
    mergeMethod: hardreset
  - base: hzv2
    upstream: stackia:hzv2
    mergeMethod: hardreset

And set this branch as default.
Go to https://pull.now.sh/check/${owner}/${repo}, it said File not found.
Then I found that the commits after forked not updated.
Did I miss something?
Thank you in advance. :)

The check url currently only works on public repos. Is it still not creating pull requests for you?

Hey wei:
Thank you for your reply.
There is still no PR for me. 10 commits behind the original repo so far.

And I try to reinstall Pull App, still not work.

Thanks for reporting. I will check tonight and report back.

I can reproduce! The REST API Endpoint to compare changes for private forks is returning 404 when using the Installation Token obtained by our Github App. I have opened a bug ticket with Github and will report back as soon as I hear anything.

Thank you for your patience, wei.
I look forward to your reply and wish you and your work can be better and better. ❤

Thanks for reaching out. What you're looking to do is not possible currently. It's not possible to compare two commits for private forks with a GitHub App installation token. The reason why that's not possible is that any installation has access only to public resources and private resources owned by the target of the installation. An installation for target X can't have access to private resources of target Y. The reason why that's not possible is that this is how permissions for GitHub Apps are defined -- an installation of a GitHub App has permissions only for resources owned by the target of the installation.
In most situations, this is not a problem since most functionality is related only to resources owned by a single target. But the compare endpoint is a bit different since it supports comparing across forks, which means that multiple targets are involved.
The team is aware that there are some use-cases where this would be useful, but it would be a fundamental change to how permissions for GitHub Apps work. With that in mind, I don't expect any changes will be made to support this in the near future.

Unfortunately, the installation token does not have access to your fork's parent fork which is a private repo. The only way around it is a personal token which pull does not currently (or ever) support. Please let me know If you can think of any other methods.

@wei I think there might be a solution - to provide a personal access token that grants this permission.
See https://github.com/TG908/fork-sync/issues/8
There could potentially, in the configuration, be a token field that is used in lieu of the GITHUB_TOKEN which would widen the scope of permissions.
This would be a life-saver for those of us with private repos who are working with collaborators.

@b-zurg thanks for the suggestion. Please try out GitHub Actions: [git-sync]https://github.com/wei/git-sync) or github-sync. They will allow for maximum flexibility in syncing.


Calendar invite

Is there a way to get the calendar invites?

Hi,
I tried some actually, but none of them worked.
I would like to know the answer, too :+1:

I already can get emails and calendar events that were accepted. But the invites, not yet.


Sync stage with 1.2.x

Purpose

$subject

 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.


Building and run unikernels with OPS

this is a duplicate
Article checklist
Formatting and structure checks

[X] Have you used the correct folder and file structure? - see Contribution Guidelines

[X] Is your article properly formatted in Markdown? - see Github Markdown guide

[X] Have you used our preferred heading structure? - H3 (###) and up

[X] Does your article follow any of the suggested structure formats? - see example formats

[X] Is your article over 750 words? - Tool: Wordcounter.net

[X] Is the article you are submitting an in-depth and unique article? Does it go beyond what is in the official docs and what is covered in other blog sites. See these articles as examples.

[X] Does your article provide enough value and detail about your topic? - Articles should be clear, accurate, and fully explained.

[X] Can your article be understood by beginners? - Assume the audience is smart but has no prior exposure to the common terminology in your article.

[X] Have you included a hero image that is 600x400 pixels, under 300KB in size, and have the copyright to use it? - Tools: Pixlr Image Editor for resizing and Unsplash for Creative Commons images

Grammar & plagiarism checks

[X] Have you spellchecked and grammar checked your article? - Tools: Write&Improve - ProWritingAid - Grammarly
[X] Please place your article through a 3rd party plagiarism checker. We suggest using Quetext, this tool is free and has a daily limit. We typically accept articles with 10% or less.
[X] Have you checked your article for readability? - Tool: Hemmingway
[ ] Have you added sources for quotes and images that aren't yours?

Technical checks

[X] Are your code snippets properly formatted for syntax highlighting - see Syntax guide
[X] Have you checked your code runs correctly and you've highlighted all necessary dependencies for installation?
[X] Are the software programs and packages you're highlighting in your article up to date, using current versions and not deprecated?

Topic suggestion this closes
This closes #4390
.

@jumamiller i have done the changes.

Hello @Gladysoby
Upon running your article through our 3rd party plagiarism checker it seemed to raise a few flags and the % was higher than we typically accept.
Please see attached PDF - and revisit the article to ensure we are contributing wholly unique and original content.
Be sure to see our resources page to see more info on plagiarism and what is considered as such.
Building and run unikernels with OPS #5465 Copyleaks Report.pdf

Hello @Gladysoby,

Upon running your article through our 3rd party plagiarism checker, it seemed to raise a few flags, and the % was higher than we typically accept.
We will be closing this article indefinitely due to repeated plagiarism violations.

The conclusion seems to be heavily flagged @Gladysoby

Hello @Gladysoby,
Upon running your article through our 3rd party plagiarism checker, it seemed to raise a few flags, and the % was higher than we typically accept.
We will be closing this article indefinitely due to repeated plagiarism violations. New Scan 5_58 PM Copyleaks Report.pdf

The conclusion and some parts of the code seem to be copied. Can you correct that and let ping the peer reviewer once done?

@jumamiller i have made the changes

jumping on this one

@jumamiller
This article was a bit difficult to read!
cc @Gladysoby please be sure to go over any and all edits made by the review to improve future articles and review and avoid article closure.


Store counts for processed object in raw.X

According to the CZI schema, the raw counts should be saved to the X layer, unless normalized data is also included. In the event that normalized data is present the raw counts should be moved to raw.X and the normalized data stored in X.
Once we complete #429 and have saved the normalized counts to X, we will need to go into the AnnData objects and move the counts layer to raw.X. Unfortunately we cannot do this while converting, so we will need a separate process that reads in the hdf5 file and moves the counts. We probably only want to run this process on the processed.rds objects.

Just thinking this through for a sec... Would we expect to do this processing in R via reticulate or by writing two hdf5 files and then a separate python script to merge the assays? (or does zellkonverter write out both assays? In which case we could probably just leave the default output and move things in python if logcounts is present?)

zellkonverter writes out all assays and stores them to the layers slot in AnnData. For our objects right now, the counts assay is stored as X and the other assays are present in layers.
My expectation was to do the following:

For normalized objects, store logcounts as X when writing out the object.
Have a python script that reads in the processed objects only
Move the counts from layers to raw.X
Save the modified processed object

Alternatively, we could write them out so they all look the same and then in a separate process read in only the processed objects and save logcounts to X and then move counts to raw.X.
I was originally trying to save having the secondary process, but now it looks like we will need to do some modifications psot writing the object.

Closed by #439


Conflicts with Easyloot

When running with Easyloot, it appears that it is not able to retrieve all the loot information.
All items that are picked up by Easyloot will not be seen as they are picked up before it that information is returned while those that are left in the loot box will be seen.

Done @ f49f3cfb4ad7cee02b1e29d62188140e1dfe1bb8.


Add jwt token in session and validate from there

Fix issue where cockpit client uses a global client not specific to
user of the request.
Store jwttoken on the user session and validate from there.

@xmonader can you test this PR? I hope this fixes some of the jwt mess.

Looks good to me. I can merge after test is done.

Works for me.

I switch my cockpit to this branch to test. I'll re-test tomorrow cause the error occurs after the JWT has expired so after 24h. If tomorrow still no error I'll merge

@zaibon even if it doesnt fix the jwt expired issue you should still merge it cause if fixes a global state issue.


Adding Mattermost-supported plugins to product docs

Documentation for: https://github.com/mattermost/docs/issues/7005

/update-branch

I am unassinging myself per an offline discussion


Fix GetNameClassWriter errors during remap on JDK11 classes

Although the remap process for ASM8 supports higher JDKs, remapping fails on some classes because GetNameClassWriter (which only gets the class name) was throwing an error when processing JDK11 classes with newer features like those from org.jgroups:jgroups.
Example errors:
2021/05/27 04:24:11 WARN ClassTransformerJarProcessor[main]: Failed to read class org/jgroups/protocols/Locking.class: java.lang.UnsupportedOperationException: This feature requires ASM7
2021/05/27 04:24:11 WARN ClassTransformerJarProcessor[main]: Failed to read class org/jgroups/protocols/SSL_KEY_EXCHANGE$SessionVerifier.class: java.lang.UnsupportedOperationException: This feature requires ASM7

The fix here is to simply change ASM5 to ASM8, the highest stable version / matching version of the current depended-on ASM.
Additionally, we change StringReader to use the higher ASM version as well to prevent errors for the strings command, but do not make any specific changes to process/display additional strings for the newer features available since ASM5 in ClassVisitor.

+1 for merging this, it was invaluable for fixing the linked issue.

@etinquis I think this project is abandoned. I had to do an internal fork with just this commit.

@redcape Yeah it seems like it, but one can only hope 😄


incompatible with Monterey developer preview 5

Monterey developer preview 5 disables MailTrackerBlocker entirely. Any word on an update?

No plans to support Monterey since it already includes a similar feature. My suggestion at this time is to enable that built-in Mail Privacy Protection and uninstall MailTrackerBlocker.


Facilitate configuration file loading outside training script

🚀 Feature
I'd like to request a feature that would allow to use the LightningCLI configuration more easily in Jupyter notebooks, or in general, outside the main training script (e.g. for serving). This could be done by implementing a mode for LightningCLI that exposes the correctly configured parser without actually trying to parse any arguments.
Motivation
After training a model on the command line, I often want to load it in a Jupyter notebook, e.g. to run it on some toy examples. Often I need to create not just the model itself, but also the data module and maybe even the trainer, optimizers etc. Sometimes I even want to modify the configuration (e.g. the maximum sequence length in a Transformer) before creating the model.
With LightningCLI, this is not currently straightforward (see #10363, #12302).
Pitch
Probably the most flexible solution would be to implement a mode for LightningCLI that sets up and exposes the parser without actually trying to parse anything (e.g. parse=False). Then one could, for example, feed custom configuration (modified on the fly) via parser.parse_object(). Then one could call instantiate_classes(), ideally with the possibility to choose which top-level objects (model, data module, trainer) to instantiate.
cc @borda @carmocca @mauvilsa

Hi!
The LightningCLI exposes several hooks that you can subclass to introduce your own parsing logic. See it's API reference: https://pytorch-lightning.readthedocs.io/en/latest/api/pytorch_lightning.utilities.cli.html#pytorch_lightning.utilities.cli.LightningCLI

@carmocca I guess I could subclass the parser in my notebook and override parse_arguments() and instantiate_classes() to prevent them from actually doing anything. Then I could access the parser and use it to do whatever I want (e.g. parse custom configuration using parser.parse_object() then call parser.instantiate_classes()). Would that work?

I think it will fail because it will try to access the config, but it will not be there because the parsing hasn't been done. Specifically these two lines https://github.com/PyTorchLightning/pytorch-lightning/blob/7ee690758ccad7f702460d056f6369c1d4371a46/pytorch_lightning/utilities/cli.py#L554-L556.

@mauvilsa I see... It's probably possible to work around this, but in any case, it would be easier to have an option to skip all the parsing.

@mauvilsa I see... It's probably possible to work around this, but in any case, it would be easier to have an option to skip all the parsing.

A workaround would not be advisable. I have thought a bit about this and right now I am not sure about a change in LightningCLI. I know of one more use case in which there is a need to get the parser of a CLI. Thus, it might make sense to add a feature to jsonargparse for this. Basically a way to capture the parser from a CLI without any need to modify the CLI.

@cifkao in the current version of jsonargparse in master there is now a way to capture the parser from a cli function. You can see the documentation for this feature at https://jsonargparse.readthedocs.io/en/latest/#capturing-parsers.


Issue/49

fixes #49

Codecov Report

Merging #56 into development will not change coverage.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##           development      #56   +/-   ##
============================================
  Coverage        83.18%   83.18%
============================================
  Files               78       78
  Lines             1255     1255
  Branches           113      113
============================================
  Hits              1044     1044
  Misses             198      198
  Partials            13       13

Impacted Files
Coverage Δ

...lib/src/adapters/database/ElementPouchDBAdapter.js
68.96% <0%> (ø)
:arrow_up:

...ckages/element-lib/src/sidetree/serviceBus/sync.js
91.11% <100%> (ø)
:arrow_up:

...nt-lib/src/adapters/database/ElementRXDBAdapter.js
86.2% <100%> (ø)
: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 c4c4ac7...1a74281. Read the comment docs.


DDC should determine null safe "strongness" based upon entrypoint language version

Enabled #41203
Requires #41205

I posted a question in #41203 to clarify the overall goal and plan here.
Even if the goal is to make tools pick a default, I don't believe we can in DDC. When DDC runs on a module, it doesn't know what the entrypoint will be. We expected this would be determined by the tool that embeds DDC (whether that is build_runner, bazel, or flutter's frontend-server)

I posted a question in #41203 to clarify the overall goal and plan here.
Even if the goal is to make tools pick a default, I don't believe we can in DDC. When DDC runs on a module, it doesn't know what the entrypoint will be. We expected this would be determined by the tool that embeds DDC (whether that is build_runner, bazel, or flutter's frontend-server)

@johnniwinther @natebosch @jakemac53 @leafpetersen ?

@sigmundch - this issue only covers the case of dartdevc from the command line. I thought we had a set of flags that you could use to invoke dartdevc against a main.dart like you can with dart2js, but now I can't figure out what the exact command should be. We will indeed be handling this in the build system for modular builds.

CFE now supports computing the language version for an entrypoint (https://dart-review.googlesource.com/c/sdk/+/141250) and .dill files now contain a Component.mode that matches the nnbd compilation mode for the entry-point when present (https://dart-review.googlesource.com/c/sdk/+/142149).

Moving this to tech preview 2 since this is no longer a requirement by dartpad

Is this still a requirement? I'm not sure how DDC can know when it is compiling a file with the entry point.
If we still think this is needed maybe we could only detect the version iff we are given a single input file?
In cases where DDC is provided multiple inputs it requires a .packages to be provided. It looks like this should probably be updated to accept a packages.json instead and it can determine the mode for all the files from there.
I think the build system should provide the --sound-null-safety or --no-sound-null-safety flag. DDC should just use that mode when provided.

Is this still a requirement? I'm not sure how DDC can know when it is compiling a file with the entry point.

It is a requirement that user-facing tools (compilers, build systems, etc) do this. DDC is in a grey area because the vast majority of the time it is compiling a single module and doesn't have access to the entrypoint, so it must be told the correct mode to compile in. Given that I don't think it can distinguish the modes and the relative low usage of it as a whole world compiler that users are directly invoking, I think it should not implement this.

If we still think this is needed maybe we could only detect the version iff we are given a single input file?

This could still have false positives. If anything I would try to do defaulting when no mode is explicitly passed.

In cases where DDC is provided multiple inputs it requires a .packages to be provided. It looks like this should probably be updated to accept a packages.json instead and it can determine the mode for all the files from there.

This should already be working properly, package_config.json files are passed using the same arguments as regular package files, and in fact will be loaded even if a .packages file is passed - if there is a .dart_tool/package_config.json directly next to it. The CFE implements this, as does loadPackageConfigUri from package:package_config.

I think the build system should provide the --sound-null-safety or --no-sound-null-safety flag. DDC should just use that mode when provided.

Yes at least in the general case, this is how it has to work.

Closing in favor of https://github.com/dart-lang/build/issues/2723


Consider renaming startFlushUpgradeHandshake

The name of the function suggests that the channel switches to FLUSHING status (assuming there are in-flight packets), which is what happens in the pseudocode of the spec, but in the implementation the flush status changes in the functions WriteUpgrade{Try, Ack}Channel.

I remember we had a small discussion on this with Cian in slack, naming also implies theres some sort of handshake going on when there isn't. We should def discuss it.


[infra] Enforce a character on explicit or implicit linkTitle

Originally posted by @svrnm in https://github.com/open-telemetry/opentelemetry.io/discussions/5039#discussioncomment-10541689

Yes, we need to keep a balance here. Can we enforce a character limit somehow? Maybe some of our linters can help with that? We can still decide to raise that limit from time to time, but at least we keep track of it.

It would be worth investigating if the linters can help, but I'm unsure that they can be used to process arbitrary front matter. Either we can do it in Hugo (probably my preferred solution so that we can report the error on the page concerned), or a post-processor, which could examine the left-nav of the generated /doc index page a report errors.
@theletterf continues:

I think 50 characters is a good limit — it'd translate to a double-line menu item in most desktop resolutions. Below is a 37 char example borrowed from Noam Chomsky.

@svrnm writes:

Yes, something between 40 and 50 was also what I was thinking about.

I agree that 40 seems good. As you mention, we can adjust as necessary.
To be clear, are we wanting this limit for the docs section only? All localizations? Or maybe excluding jp and zh?

To be clear, are we wanting this limit for the docs section only? All localizations? Or maybe excluding jp and zh?

Good tricky question! As we've no linguists among us, I'd go for the same (safe) limit of 40 characters for all. jp and zh will probably never pass that limit...


Reference gallery has extra scroll bars

When hovering at the edge, it creates extra scroll bars. Not a big deal, just wanted to report it's a bit awkward.

But it's a really nice reference gallery!

I'm not seeing this.

Still see it on a smaller monitor (aka laptop screen):

I also don't see this in the latest chrome on macos monterey
@ahuang11 do you still see it? if so, what browser/os are you using?

Cannot reproduce anymore.


Can this be used in the browser?

I'd like to write a client side app that presents videos scraped from youtube, is it possible to use this library in the browser?

I don't think so, never tried but you'll probably face CORS problems & other issues related to how the library caches the yt player.

Hi! I wanted to do something similar, so I forked the project and made it api-rest like. Right now only search is working, as it's the only method I needed, but any method can be implemented at will. Thanks LuanRT for your good work!


Fix Reset to default for DateTime, #185

I added a flag in the context for DateTime type
In the template I use get_format('DATE_INPUT_FORMATS')[0] and get_format('TIME_INPUT_FORMATS')[0] from Django Admin to format the date and time. I similar pattern is used in for Now and Today functionality available in the widget.

@jezdez are there any issues with this PR?

@jazdez would you mind having a look at this? I updated the code as you suggested but I am not sure it is correct to do such a transformation.

@jezdez Please take a look

@rvernica could you please update your files? I would like to see this merged.

The files were updated back then. There was no more feedback after that.

I'm seeing a conflict with one of the files. All the other feedback was done as I can tell.
Fixing the conflict will allow us to merge it, right?

I see. I wish this was merged back then...
Resolving the conflict is not trivial. The way Reset to default is implemented has been changed in c8568b3f6b8098c70edacb1a91d41579686a46fb Maybe @whs can help.
In this patch we use two ID variables, '{{ item.form_field.auto_id }}_0' and '{{ item.form_field.auto_id }}_1'. The way Reset to default is implemented right now, it only accepts one.

I'll take a look later today after work.

Thank you. I hope we can sort this out today.

Continued in #243


rootless: check if the conmon process is valid

if the pause process doesn't exist and  we try to join a conmon
namespace, make sure the process still exists.  Otherwise re-create
the user namespace.
Signed-off-by: Giuseppe Scrivano<EMAIL_ADDRESS>

LGTM

/lgtm
/hold

/hold cancel


define a range of a "green" coverage

Hey, I want to reach at least 70 % by coverage again,
we maybe should adjust a bit that not only a few lines below this goal the coverage test shows the CI has a failure.
What would be a good value for https://coverage.readthedocs.io/en/7.4.4/config.html#report-fail-under

I don't think the setting you have referenced applies for coveralls, right? I.e. it is for coverage.py and would make the pytest run fail if coverage is below this value, but it would not affect what the status check from coveralls shows (which is green if coverage stayed the same or increased, and is red if coverage decreased, compared to a previous run), right?
I would prefer to stay with what coveralls already does, but fix our test suite to actually have a deterministic coverage (unlike what we have right now, where there is a handful of lines that may or may not be covered at random, for some reason).

oh, right, we moved from there. It only illustrates what a solution can be.
I dislike that it currently looks like the tests have failed but it is only less line covered.
But at all for much new lines I think it's a good idea to remember that with a merge we end up there again.

The proper fix is to get the test suites coverage to be deterministic. Do you have any idea why it is not? I can only guess that it depends on what Qt has done already at the end of a test, so maybe a qWait at the end of every test would pave this over, for now. I would have to test that out.

@matrss I think we can close this, a follow up may also get a different description, as my initial one.


Compiler raises null reference warning for property injected using [Inject] attribute

When using nullable reference types and injecting a service using the [Inject] attribute the compiler does not recognise the property as non-nullable.
When using constructor based dependency injection the compiler does not give the warning.
Reproduce
Enable null reference types, use [Inject] attribute to inject a service into a component.
As an aside, it would be great if the default Blazor templates could be converted to have null reference types enabled.
I'm not sure if this can be fixed in the aspnet code or if this issue should rather be moved to another project.

Thanks for contacting us, @tn-5.
For the changes in templaets, we're tracking that work as part of https://github.com/aspnet/AspNetCore/issues/10921.

Hi @cartermp. What should our guidance be here regarding nullability checks for traditional properties?

I think this is a post-3.0 kind of thing. We need to expose certain APIs in CoreFX to allow ASP.NET and EF to have a sane way to represent nullability.

This is not a question, this is a bug in the compiler - using an NNRT with @inject will always result in a warning right now.
The fix is to generate the property like so:
[Inject] IFoo Foo { get; set; } = default!;

This has to be contingent on whether nullability context is enabled at the project level, which we already flow into the compiler.

/cc @NTaylorMullen

@NTaylorMullen is this done already? If so, please close this one.

Yup, I fixed this in preview9.


[JENKINS-42022] Remove 'unix machines' from plugin's description.

JENKINS-42022
Adapt descriptions in POM and index.jelly files after  PR #33
@reviewbybees @stephenc @olamy

@stephenc @olamy could you please kindly review this?

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

@stephenc @olamy ping?

@stephenc I think this one is ready to be merged.

@reviewbybees done


Adding Scripting API Support for 9212 and 9213

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?
Adds the ability to create a 9212 or 9213 module in the scripting API and read the configuration back.
Changes the Create Default Channel Array.vim to include a default settings input, allowing the user to define what should be instantiated in the array in the event the channels settings array is empty.
Why should this Pull Request be merged?
Adds support for the 9212 and 9213.
What testing has been done?
Validated that all custom device unit tests continue to run including newly created ones for these two modules.

FYI: @Sarci1 is OOO for the rest of the year and I will be taking over for her to address the comments and have this PR submitted

@oscarfonloz I didn't change the XML intentionally so I don't know what that's about. You can probably revert it. As for the modes, I expect the same regarding the *.vim

[x]  What are the changes to Custom Device Scan Engine.xml and why were they made? I was able to determine one of the changes was making one of the actions non-modal, but I don't understand why that change is necessary for 9212/13 scripting.

Reverted this change

[ ]  Why are there changes to all the Mode classes in this PR? It should be limited to 9212/13 and Thermocouples. Maybe the base Analog Input too, but I don't see why this should modify digital modes. If this is due to the change in Create Default Channel Array.vim, I would like to have that change in a different PR so both changes are easier to digest and document.

Yes, the vim changed all the creation VIs to add the default settings. From my message in Teams: "I am concerned this request will delay too much the PRs to go in. Do you have a chance to review the two separate PRs tomorrow if I were to make the change? I am assuming you're taking vacation already, and we want to keep making as much progress as we can while some of us are still in office. This will likely mean ending up with a couple of separate and stacked PRs, but this one touches all the modes, so it might be a good idea to pass it quick"

[x]  Convert Channel Settings to Thermocouple.vi is not part of the Scan Engine Scripting.lvlib.

Good catch! I added it to the library under the Utility virtual folder

[x]  Please order the cases in Get Slot.vim.

I like this and it was one of the things I had in mind on the last review for preventing this VI from becoming a bottleneck. Seems like we could have a dynamic dispatch VI in Module.lvclass that could take in the RSI Module and handle all of the conversion without needing the case structure for the module. We don't need to change it now, but can you create an enhancement issue on the repo so we can look at this at a later date?

I agree and opened Issue 138 to track this enhancement.

I believe the build is failing because we're missing the module's accessors from PR 40, let me know if this is not correct.

[ ]  Why are there changes to all the Mode classes in this PR? It should be limited to 9212/13 and Thermocouples. Maybe the base Analog Input too, but I don't see why this should modify digital modes. If this is due to the change in Create Default Channel Array.vim, I would like to have that change in a different PR so both changes are easier to digest and document.

Given the substantial progress made on code changes over the holidays, I will acquiesce and we can put this change in on this PR, but please add information to this pull request that tells us this change was made in this PR because it is not really related to the description and intent of this PR.

[ ]  Please order the cases in Get Slot.vim.

These still need to be ordered.

[ ]  Why are there changes to all the Mode classes in this PR? It should be limited to 9212/13 and Thermocouples. Maybe the base Analog Input too, but I don't see why this should modify digital modes. If this is due to the change in Create Default Channel Array.vim, I would like to have that change in a different PR so both changes are easier to digest and document.

Given the substantial progress made on code changes over the holidays, I will acquiesce and we can put this change in on this PR, but please add information to this pull request that tells us this change was made in this PR because it is not really related to the description and intent of this PR.

[ ]  Please order the cases in Get Slot.vim.

These still need to be ordered.

Thanks for the comments @buckd

[x]   Why are there changes to all the Mode classes in this PR? It should be limited to 9212/13 and Thermocouples. Maybe the base Analog Input too, but I don't see why this should modify digital modes. If this is due to the change in Create Default Channel Array.vim, I would like to have that change in a different PR so both changes are easier to digest and document.

Given the substantial progress made on code changes over the holidays, I will acquiesce and we can put this change in on this PR, but please add information to this pull request that tells us this change was made in this PR because it is not really related to the description and intent of this PR.

@Sarci1 helped me adding the note about this VI to the PR's description

[ ]   Please order the cases in Get Slot.vim.

These still need to be ordered.

It shows ordered in my side for this commmit.
I cleared the compiled object cache in my machine, since I noted it started doing "weird things" when loading items from previous commits. Is this not what you see?

Thanks for the comments @buckd

[x]   Why are there changes to all the Mode classes in this PR? It should be limited to 9212/13 and Thermocouples. Maybe the base Analog Input too, but I don't see why this should modify digital modes. If this is due to the change in Create Default Channel Array.vim, I would like to have that change in a different PR so both changes are easier to digest and document.

Given the substantial progress made on code changes over the holidays, I will acquiesce and we can put this change in on this PR, but please add information to this pull request that tells us this change was made in this PR because it is not really related to the description and intent of this PR.

@Sarci1 helped me adding the note about this VI to the PR's description

[ ]   Please order the cases in Get Slot.vim.

These still need to be ordered.

It shows ordered in my side for this commmit.
I cleared the compiled object cache in my machine, since I noted it started doing "weird things" when loading items from previous commits. Is this not what you see?


DELETE cli

We need to create the cli for DELETE method in the same way of the rest of the method:
hjs generate delete [path] --headers [headers]* --status [status]* --cookies [cookies]* --description [description]*
Take in mind a DELETE test template will be generated by default

These fields are optional

https://www.npmjs.com/package/@hectorjs/stub-backend
Method available in the version.
Execute hjs --help for more information


System does not boot up after reboot

I want to to a reboot with sudo reboot.
after installing from https://wiki.geekworm.com/X-C1_Software
cd ~
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install -y git pigpio
sudo apt-get install -y python-pigpio python3-pigpio
sudo apt-get install -y python-smbus python3-smbus
git clone https://github.com/geekworm-com/x-c1.git
cd x-c1
sudo chmod +x *.sh
sudo bash install.sh
echo "alias xoff='sudo /usr/local/bin/x-c1-softsd.sh'" >> ~/.bashrc
sudo reboot

I ran the command sudo reboot the system does not boot up.
blue ssd is on but red and green led from pi remain off

+1
No solutions found ?

After the install process and before the reboot, open the /etc/rc.local with nano or vim, then comment the line where there is "/etc/x-c1-pwr.sh &"
You'll be able to reboot but still issue with the fan management. I'm on it.

I'm having this issue, I've commented out all "/etc/x-c1-pwr.sh &" in /etc/rc.local but still can't get any output after the initial boot on my Pi4
I can ssh in fine and if I remove the x-c1 module then the login screen is displayed. Unfortunately the case is useless without the x-c1 board

FYI

Hello, Here is my modified fan.py and running the python script in systemd daemon. I also created  ansible tasks pigpio.yml which automates the installation of pigpio and fan.py installation


Adding Probes to sidecars

I see right now the sidecars does not have liveliness and readiness probes attached to them, sometime when i restart the servers e.g. minikube the apps immediately shows its Running 2/2 but when the apps tries to connect it shows connection refused ...  the kubectl describe <pod> shows that its trying to pull images with policy "Always"..
will it be worth to add probes or is there any other rationale behind not adding ?

Yes, it's definitely worth adding them to the sidecar. Ideally, to the proxy itself, so that k8s awaits for the first successful fetch of RDS/LDS from Envoy.

Please add assignees

/assign

Issue moved to istio/istio #1404 via ZenHub


Update Column Definition with formatterParams - TypeError

Hi @s-cork,
I have a tabulator component on my form and depending on a user input, I need to update the displayed value in a column.
I can update a column definition by getting the column component and using column.updateDefinition({ }) on it. It works fine except when we need to update the formatter parameters.
Here is a sample column definition:
{"title": "My Title", "formatter": myFormatter, "formatterParams": {"value_type": "units"}}
If I wish to update the value_type, I can't say column.updateDefinition({"formatterParams": {"valueType": "currency"}}) because it throws the following type error:
TypeError: <lambda>() got an unexpected keyword argument 'units'
at app/tabulator/Tabulator/_helpers.py:142

I have a work around by updating the column definition by including the formatter again as such:
column.updateDefinition({"formatter": myFormatter,"formatterParams": {"valueType": "currency"}})
Just thought might be worth mentioning.

Yeah I guess that's to do with the internals of tabulator js. I don't do anything special here with params so I'm inclined to think your work around is probably the correct solution.


Add a within command to find all points within a search radius

Closed #15 and split it into two commits.
Side note, can we remove the panic on the creation of the tree and return a result, or allow empty trees to be made? Was so confused until I realized the panic came from the library.

Looks good, but it seems even your original test are gone, maybe you forgot to add the files?
re panic: yes, of course we can do that I'll create new issue later in the day for that.
I saw that they are working on improving the readbility of that btw! https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages
I havent had the chance to test that thing yet.

Updated with tests.

Looks good, i'll be merging this.
I'll take a deeper look and add the property based testing this week just to double check
After that i'll proceed to release new version


Feat : To create the relavant APIs

To create the relevant APIs for the login form.

Taking this up!


clear mmx state after mmx procedures, fix #94

Sets the values of all the tags in the x87 FPU tag word to empty (all 1s). This operation marks the x87 FPU data registers (which are aliased to the MMX technology registers) as available for use by x87 FPU floating-point instructions. (See Figure 8-7 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, for the format of the x87 FPU tag word.) All other MMX instructions (other than the EMMS instruction) set all the tags in x87 FPU tag word to valid (all 0s).
The EMMS instruction must be used to clear the MMX technology state at the end of all MMX technology procedures or subroutines and before calling other procedures or subroutines that may execute x87 floating-point instructions. If a floating-point instruction loads one of the registers in the x87 FPU data register stack before the x87 FPU tag word has been reset by the EMMS instruction, an x87 floating-point register stack overflow can occur that will result in an x87 floating-point exception or incorrect result.
EMMS operation is the same in non-64-bit modes and 64-bit mode.

I can confirm it works.


docs: small updates to jsonld docs

Just some small rewording, no substantive changes

Codecov Report

Merging #1141 (63d3e17) into main (eb3fd94) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1141   +/-   ##
=======================================
  Coverage   98.70%   98.70%
=======================================
  Files         439      439
  Lines       24416    24416
=======================================
  Hits        24099    24099
  Misses        317      317


[PROPOSAL] Client Support For Extensions

What/Why?
Prior Art

Extensions Proposal: https://github.com/opensearch-project/OpenSearch/issues/2447
Clients Generation from API Specs: https://github.com/opensearch-project/opensearch-clients/issues/19

Java client generation proposal: https://github.com/opensearch-project/opensearch-java/issues/284
Generator prototypes:

https://github.com/opensearch-project/opensearch-java/pull/318
https://github.com/opensearch-project/opensearch-java/pull/336
https://github.com/opensearch-project/opensearch-java/pull/366
https://github.com/opensearch-project/opensearch-ruby/issues/139

What are you proposing?
Allowing the creation of thin-clients for extensions which will be composable with the core client in every supported programming language. Extensions will publish their REST interfaces in the shape of OpenAPI specs, a generator will then consume the spec and output a client that can be composed with the core client. Manual work and intervention will be minimized by automating as much of the process as possible, providing build-and-test tooling such as CI workflows, so that both OpenSearch project-owned extensions and externally developed extensions can benefit with uniform support.
What users have asked for this feature?
There have been many requests for complete support of plugins in clients and as extensions are an evolution of plugins, these can be treated as a direct indicator of need for support of extensions due to the fact that the plugins will necessarily be migrated into extensions in time:

https://github.com/opensearch-project/opensearch-py/issues/90
https://github.com/opensearch-project/opensearch-java/issues/59
https://github.com/opensearch-project/opensearch-js/issues/329
https://github.com/opensearch-project/opensearch-go/issues/94
https://github.com/opensearch-project/opensearch-py/pull/93
https://github.com/opensearch-project/opensearch-py/issues/284
https://github.com/opensearch-project/opensearch-js/issues/190
https://github.com/opensearch-project/opensearch-go/issues/74
https://github.com/opensearch-project/opensearch-py/issues/177
https://github.com/opensearch-project/opensearch-py/issues/143
https://github.com/opensearch-project/k-NN/issues/634
https://github.com/opensearch-project/opensearch-py/issues/291

What problems are you trying to solve?
When a user wants to invoke an extension from a programming language of their choice, they currently lack an easy and reliable method to do so. At present a user would need to directly invoke a “raw” HTTP client directly implementing any additional authentication alongside their core OpenSearch client, or in some cases a languages OpenSearch client exposes a “raw” request method alleviating some of the duplication. However, the current solutions lack any definition of what endpoints are available, their request shape, strong typing of query parameters or any documentation.
What is the extension owner experience going to be?
Extension owners will author an OpenAPI REST specification for their extension. A code generator will then consume it and output the complete compilable & runnable source code for a high level thin-client that is composable with the core client in every supported programming language. Automations such as CI workflows will be provided to streamline the process of generating and publishing a given thin-client, and there will be minimal ongoing maintenance overhead by the extension owner for the generated thin-client.
Example flow of adding a new API:

New endpoint is implemented in the extension
Endpoint definition is added to the extension’s OpenAPI specification
New extension version is tagged and released publishing the updated spec
Client generation workflows are automatically triggered consuming the spec
Clients are generated containing the new endpoint
Finally one of:

New client versions are released automatically
Workflows automatically create pull-requests to include the new endpoint in checked-in source of clients. Allowing manual review and management of how the clients are versioned if desired.

Are there any security considerations?
At this time, there are no specific security considerations related to this proposal.
Are there any breaking changes to the API?
No, there are no breaking changes to the API, as this relates to an entirely new development.
What is the user experience going to be?
Users will have an easy and reliable way to invoke any extension from their preferred programming language. They will also have access to all new APIs or API updates immediately after an extension is released. Furthermore, due to the thin per-extension nature of the clients users will be able to pull in only the necessary extensions.
Example flow:

User has installed the security extension into their OpenSearch cluster, and now wants to interact with it in an application they are building
The user adds a dependency on the extension’s thin-client to their application in the programming language of their choosing, which transitively pulls in a dependency on the core OpenSearch client & transport.
The user can immediately begin developing their application using the client to interact with the extension in a reliable and well-defined manner.

Are there any breaking changes to the User Experience?
Previously a subset of plugin APIs were included directly in the language clients, differing in coverage between languages. As extensions will be published as separate packages rather than bundled into the core clients this will be a breaking change for the relatively small set of plugins that were covered and will now be migrated to extensions. This is relatively minor as coverage for plugin APIs was generally poor if not non-existent.
Why should it be built? Any reason not to?
Building this proposal brings value to the OpenSearch community by providing a high-standard solution that supports both first-party and third-party extensions uniformly, increasing the "feel good factor" for third-party developers. It also lowers the barrier to entry and increases velocity, scalability, and reliability with well-thought-out tooling and automation. Not building this proposal could limit the flexibility, ease of use, and integration of extensions for the end-users.
What will it take to execute?
The language client maintainers will need to:

Ensure the core clients provide a stable interface for interacting with the low-level REST transport layer, potentially as a separate library (JAR, RubyGem, NuPkg, Crate, etc.) which the core client also depends on. This will involve integration tests of the core interface to aid reliability guarantees.
Provide code generators that accept OpenAPI REST specifications and output client code targeting the aforementioned stable interface. This work is already underway as part of https://github.com/opensearch-project/opensearch-clients/issues/19.
Provide prebuilt automations, such as GitHub Actions, that enable the running of the code generators in a quick and easy manner.
Documentation and a guide for how to use the provided tooling to configure and set up the client generation for an extension.
A template repository for a simple extension and uses the provided automations to generate a full suite of clients so that extension builders can easily adopt this paradigm.
Integration tests that make use of the template extension to validate the code generators and the stable core interface.

Extension owners will need to:

Provide OpenAPI REST specifications for the APIs provided by the extension.
Integrate the generators & automations into their workflows to generate their thin-clients.

For opensearch-project owned extensions this and the following point will be done in collaboration with both the clients maintainers and the build automation maintainers.

Publish the thin-clients to their desired package managers.

Questions:
Why independent thin-clients?

Allows the core client for each language to remain as lightweight as possible while enforcing separation of concerns.
End-users can pull in the exact extensions they need and nothing else. For example where small-footprint, fast cold-start applications are desired such as AWS Lambda functions or Docker images.
Allows extension and their clients to be versioned completely independently of the server and the core clients.

Will the explosion in number of thin-clients cause issues?
The number of thin-clients as we multiply the number of extensions by the number of supported languages will almost certainly be huge in the not too distant future. However, we can mitigate as much of the burden as possible by providing high-quality prebuilt automations (i.e. GitHub Actions) to streamline the process of generating and publishing a given thin-client. As they will in the general case be 100% generated, there will be essentially zero ongoing maintenance overhead by the extension owner. Extension owners can further reduce any overhead by taking a piecemeal approach to which language clients they generate and publish depending on demand (i.e. a machine learning extension may only primarily care about Python).
Why not bundle extension clients into the core client?
As it will be possible for independent developers to create extensions, it would not be feasible to include client code for all extensions in the core client. So we would end up having to draw some kind of delineation which would naturally end up being only first-party (opensearch-project owned) extensions or a subset thereof. This would in turn require supporting both the directly bundled approach and supporting the externally generated thin-client approach. There will likely be many first-party extensions as well so would not be scalable to include all in one client so would lead to further disparity of treatment between extensions.
Why OpenAPI specifications?
Defining the extensions API in a ubiquitous spec language such as OpenAPI, enables developers to generate clients more easily as well as allowing users to use off-the-shelf tooling to generate clients or interact with the APIs as they desire. It can also be used in a spec-first approach where the spec is used to generate the necessary scaffolding to set up the routes and actions in the extension itself.
Using other spec languages such as Smithy as the basis for code generation were considered in the context of https://github.com/opensearch-project/opensearch-java/issues/284, however OpenAPI was chosen as it’s a de-facto standard within the community.
Can this proposal be extended to support other types of specifications besides OpenAPI?
At this time, OpenAPI is the chosen specification language for this proposal due to its wide adoption and tooling support. Other specification types such Smithy often have mechanisms to be converted into OpenAPI, potentially allowing extension authors to write their specifications in something other than OpenAPI and merely publish the converted output.
How will this proposal affect developers who are not familiar with OpenAPI?
OpenAPI is a widely adopted standard with plenty of resources available for learning, so it should not be a significant barrier to entry for most developers.
Will extension owners be able to extend upon their generated thin-clients?
As extension owners will have full control over the generation and publishing of their clients, they will be able to do anything they like with regard to modifying or extending them. The primary recommended manner in which extension owners would be able to extend upon the generated clients would be for them to create a new package/library that depends on the generated client. In their higher-level library they could implement any new logic or features necessary and recommend it as the definitive client for the extension, with users still free to use the simple generated client if desired. There may be other solutions such as checking-in the generated client source to Git and making any necessary additions within the same library.
Any further questions?

I like it!

@Xtansia certainly huge +1, we have been discussing this subject in the past and, the plugins / extensions would benefit the most from  usage of the OpenAPI as the universal specification format (comparing to Smithy fe, no need to learn new tool). I think this also strong argument to use OpenAPI for core clients (the POCs we have are good starting points).
Regarding the thin-client integration, the consensus we've reached so far is that opensearch-java should be the only recommended way to connect to OpenSearch from Java. We could use ServiceLoaders to discover and load the thin clients, something like (very roughly):
public class public class OpenSearchClient {
    <A> plugin(Class<A> );
    <E> extension(Class<E> );
}

So whenever the thin-client for plugin or/and extension is on classpath, it could be used (the wiring details could be laid out later on, this is just high level idea).
But this is Java only, I think for other languages (Rust/Python/Go/Ruby/...), we would need to work on finding out the "pluggable" options or just use different approaches altogether.

@Xtansia  +1  Great presentation on the topic! I have a few questions after reading it:

Is the OpenSearch-Project responsible for managing code generation?  What about distribution?
Will pre-release extensions and extension features be compatible with thin clients?
Have you considered non-open-source extensions?
With multiple thin clients loaded at once, could using datatypes and APIs from other extensions cause issues with type duplication or incompatibility?
How will extension developers be prompted to author OpenAPI specs to enable thin client generation?

Thanks all for the feedback and questions. I've done my best to answer your questions as I understood them, feel free to ask follow-up questions or clarify if I've misunderstood.

@reta

I think for other languages (Rust/Python/Go/Ruby/...), we would need to work on finding out the "pluggable" options or just use different approaches altogether. This is probably the only unanswered question I have at the moment.

I didn't want to get too deep into language specific suggestions as I'm not up-to-speed on what's idiomatic for all the languages. But the most basic approach here is just something along the lines of an IOpenSearchClient interface and the extension client just takes it as a constructor argument. C# & Rust at least have some mechanisms for nicer ergonomics around this, essentially being able to define extension methods so that you could define OpenSearchClient.Security() -> SecurityExtensionClient from outside the library that owns OpenSearchClient.

@peternied

Is the OpenSearch-Project responsible for managing code generation?  What about distribution?

This depends on how you define "managing code generation" and "distribution", so if you could be more specific that would be great.
In general the OpenSearch project would be responsible for implementing and distributing the code generators for the language clients we currently support along with associated reusable automation/CI workflows. The project would not be responsible for the execution of the generators nor the hosting of the final generated artifacts, except for where the project owns the given extension.
So an external third-party extension developer will be responsible for their own running of generation and distributing their client artifacts, but making use of the tooling we'll provide.

Will pre-release extensions and extension features be compatible with thin clients?

Could you please expand on this question, by "extension features" is that like feature flags?
For pre-release extensions, as the extension owners will control generation it'd be reasonable to expect they could generate and publish pre-release clients.

Have you considered non-open-source extensions?

As the extension owner controls the actual generation & publish step, they would be able to take our open tooling and run it inside their private CI and publish their thin clients to internal package registries if they desired.

With multiple thin clients loaded at once, could using data types and APIs from other extensions cause issues with type duplication or incompatibility?

This is a potential concern, however we can define any truly global types in the core client/library, and handle the mapping in the code generators so that they output a reference to the shared type rather than recreating the definition.

How will extension developers be prompted to author OpenAPI specs to enable thin client generation?

In the general case this will fall under a larger umbrella item of complete documentation for "Getting Started Developing An Extension" and associated examples.
For those that have begun development or soon to begin within the OpenSearch project, it'll more likely be a push (either just a nudge, or some assistance in initial authoring) from the clients maintainers as we roll out the generators and want to get the adoption going.

Thanks for clarifying and expanding, hope this clears things up a bit more.

Let us consider OpenSearch extensions, like anomaly detection, called AD for short. Since it is part of the OpenSearch Project, its hosted inside of github.com/opensearch-project/AD. The AD extension offers new APIs, a perfect fit for a thin client. Since there will be N different language clients, who is responsible for generating the clients?

In this example, the AD maintainers/owners would be responsible for the triggering of the generation, as they'd be in the best position to make decisions around when the API of the extension has changed sufficiently. In general, I'd expect this to be almost entirely automated, whether triggered via tag push or a manual workflow run that regenerates all clients at once thus requiring minimal specific knowledge from the extension maintainers.
It would just not be scalable for the core clients maintainers to directly monitor and own all extensions' generation. However, the clients maintainers would provide ongoing support and guidance for the process as well as taking care of the onboarding.

Honing in on the AD client for python. Does this client get generated and checked into github.com/opensearch-project/AD-py-client, somewhere else, or not under direct source control? What if the AD extension team/contributors want to add improvements to the client, how do they do that?

I see this as a choice to be made by the AD maintainers, it should be possible to take any of these approaches with the tooling the clients maintainers will provide:

Keep client source code ephemeral, having no extra repos or checked in code. Essentially a completely invisible process.
Have a mono-repo of checked in client source code for all languages. Not really an ideal approach, but should still be possible, as may be appealing to external devs.
Have n repos each with checked in source code of the language client, allowing transparency of changes, adding extra libraries or making improvements.
Some combination of the above, i.e. 7 out of 8 languages are "invisibly" generated, but Python specifically is checked in with extras.

In essence, I believe the tooling and GitHub actions etc. provided should be composable and flexible such that the extension maintainers can use it in their work flow as they please. Even if there may end up being a "golden path" that's recommended within the OpenSearch project.

Moving to distribution, how is the thin client consumed? For python the typical place is pypi. How does the AD thin client for python get registered and updated?

In general, they will be consumed in whatever is the standard for the language, e.g. PyPi for Python, NuGet for .NET, Maven for Java.
The clients maintainers (working with the build automation maintainers) will provide automations for publishing the clients to their given artifact registry. These already exist for the core clients, so will mostly be re-using or expanding upon existing automations.
There will be some difference in requirements for OpenSearch project extensions versus external ones, as we have requirements around security, artifact signing and separation of ownership, whereas external devs will more than likely just need a relatively simple GitHub workflow they can plug a NPM API key into for example. So we'll require that support from the build maintainers to aid in provisioning of access to our artifact registry accounts for repos within the OpenSearch project and ensuring we meet our requirements.

Not feature flags, I mean will the process allow for release vs snapshot builds of thin clients?

Unfortunately some languages and artifact registries do not have a good concept of a "snapshot build", so it may not be reasonable to actively publish a snapshot build of a given client. It will certainly be possible to have prerelease versions that publish e.g. explicitly versioned betas or release candidates (1.2.0-beta.1, 1.0.0-rc.3 etc.)


Is it possible to run multiple signatures in parallel?

Say I have 1000 gene expression signatures -- would it be possible to run them faster than sequentially? I notice there's a calibration step before each enrichment step -- could that step be performed just once?

The calibration is for the value distribution of a given signature. If the signatures have different values, then technically a calibration would be required for each signature. I could add a flag that can skip the calibration. It would probably be fine.

I'd appreciate that! Each of my signatures is different but they all share an identical range / nearly identical distribution, so I'd like to only compute it once (takes quite a while otherwise)

The function blitzgsea.gsea now has a parameter called shared_null. By default False, if set to True will reuse the null. Hope this does the trick.


What is "_objCount"?

I have a quick question of what is "_objCount" when I log something like this:
ParseObject { className: 'testClass', _objCount: 12, id: 'euALHDKUWd' }
Whenever I log this object for ex. the "_objCount" would be incremented up by +1. so If i refresh the browser which is firing a Get method for the route "/" and i have a console.log the object, it would get bumped up to 13, and so on up by one.

https://github.com/ParsePlatform/Parse-SDK-JS/blob/73ccdd3ce5031db81eaed1ffd8523c08efb74b5c/src/ParseObject.js#L63

That's an internally use value, you should not worry about it

@flovilmart thanks for the response. I also had a quick question regarding parse-express-cookie-session module.
I understand it's outdated at this point with Parse Server. Is something like this an appropriate replacement? http://code.runnable.com/U0tEnHwraXYyp-JG/simple-usage-of-express-session-and-cookie-parser-with-express-for-node-js


Disappearing Sender (@) column

Hi,
I'm running Thunderbird 68.10.0 on Linux Mint 20.1 Cinnamon with these addons:

Allow HTML Temo
DKIM Verifier
Enigmail
Lightning
Paranoia
Rise of the Tools
Signature Switch
Send later
and obviously Full Address column v.1.0.2

The Sender (@) column keeps disappearing occasionally, not after each TB shutdown/launch. I'm using local folders for my e-mail accounts. I have not yet identified a way how to consistently reproduce this behavior.
Is there anything else that I could do/check for other than to observe more carefully and notice some potential correlation?
Thanks.

When you notice the column disappears, check console (CTRL-SHIFT-J) for any unusual messages and compare them with those you get during normal Thunderbird startup.

I have similar problems: Sender@ and Recipient@ columns disappear when Thunderbird is closed. But only in virtual folders. They combine the mails of 10 accounts and several archive-folders. All folders are online(imap).
Thunderbird 102.7.1 is a fresh and clean install on a fresh installed Linux Mint 20.1 Cinnamon.
I cannot compare different startups, because every startup has lost the columns in the virtual folders.

You mean saved search folders? I can't reproduce the behavior on TB 102.7.2 on Debian 11, Windows 7 or Windows 10. Please provide step-by-step description how you do it.

After adding Sender@ and Recipient@ to all folders, the saved search folders _Trash and _Junk (10 folders each) are ok.
_Inbox (85 folders) is more stable than before but the columns disappear sometimes.
My idea is the issue is depending on the number of searched folders or on the column order of the searched folders.

Not really sure what I can do about this bug.


feat(graphql): allow the ability to ignore certain fields

Which problem is this PR solving?
The inability to specify fields that you may want to ignore due to high levels processing needed to get through all of those fields.
Short description of the changes
Add a new option into the config to ignore fields.
Checklist

[x] Ran npm run test-all-versions for the edited package(s) on the latest commit if applicable.

@dyladan sorry that this is so late and it does not have code coverage on the new code, but this is what I was talking about in our one meeting. When you have arrays that are 20,000 objects that each of those objects have 20-40 properties, it leads to a major slowdown. This is one way of fixing the issue since it would allow us to ignore fields that we do not want to put into the tracing.
It also should allow us to hide values from entering into our telemetry platform. If you think this is a good idea, I'll continue with this and add an actual feature and finish this up.

@Flarna @blumamir or others, can I get a set of eyes on this? Will help me do some more things with this instrumentation from a PII perspective

@jscherer92 I'm not familiar with graphql so can't really comment that much on this change.
The current owner of this instrumenation is @obecny but as far as I know he moved to other topics then OTel a while ago.
@open-telemetry/javascript-maintainers  what is the right approach here? I think we should be happy to have people to contribute but the contribution guideline is not that clear to me how to move ownership.

Would a HashSet be better?

Would a HashSet be better?

Pseude code
this._ignorehMap = {};
for (let i = 0, j = ignoreKeys.length; i < j; i++) {
  this._ignorehMap[ignoreKeys[i]] = true;
}

if (
    !type ||
    typeof type.getFields !== 'function' ||
    this._ignorehMap(type.name) ||
...

Oh I agree that we could do it that way. I'm just wondering if the HashSet would be better;
`
this.ignoreFields = new HashSet(this.config.ignoreFields);
if(this.ignoreFields.has(field))
`

Oh I agree that we could do it that way. I'm just wondering if the HashSet would be better;
` this.ignoreFields = new HashSet(this.config.ignoreFields);
if(this.ignoreFields.has(field)) `

hash map is faster the set

should be switched over now

hash map is faster the set

I cannot understand how that can even be the case. I mean... even if it would, why didn't the smart people behind node think of implementing Set through Map then?

GraphQL tests seem to be flaky(see #1184). Merging this will be blocked until that's fixed.
@jscherer92, maybe you'd be willing to look into it?

Nvm, GraphQL tests are now fine.

@jscherer92 Thanks for the time you put into this. I apologize for taking long to review.
Are you still interested in it or should I close?

Definitely still interested! I can take a look at the comments and fix up what is there


update value on current humidity work so so

if a start my deshumidifier the value of curent humidity work well and target humidity work well
what does't work is the polling current humidity at 30 second, the refresh does't work. I try to change de refresh at 15 sec or 1 min but no effect.
in my NetHome plus the value of curent humidity is 40% in my HomeKit is 48% exemple.
when I stop the déshumidifier the value of curent humidity updating well. if my dehumidifier is on, and I change fan speed, current humidity value updating well. In my Nethome plus and HomeKit curent humidity is same.
[14/12/2022, 23:57:12] [midea-air] Triggered SET Active To: 0
[14/12/2022, 23:57:12] [midea-air] [sendUpdateToDevice] Generated a new command to set targetHumidity to: 40
[14/12/2022, 23:57:12] [midea-air] [sendUpdateToDevice] Header + Command: [90,90,1,16,90,0,32,0,1,0,0,0,189,179,57,14,12,5,20,20,29,129,0,0,0,16,0,0,0,4,2,0,0,1,0,0,0,0,0,0,170,33,161,0,0,0,0,0,3,2,72,0,1,60,0,0,0,40,0,0,0,0,0,0,0,0,0,0,0,0,0,0,20,120,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
[14/12/2022, 23:57:13] [midea-air] Send command to: Déshumidificateur<PHONE_NUMBER>22406) [sendUpdateToDevice] attempt 1/2 success!
At this point a stop deshumifier
[14/12/2022, 23:57:13] [midea-air] Current Humidity: 40
[14/12/2022, 23:57:13] [midea-air] Target humidity set to: 40
[14/12/2022, 23:57:13] [midea-air] Water level at: 0
[14/12/2022, 23:57:13] [midea-air] Power State set to: 0
[14/12/2022, 23:57:13] [midea-air] Operational Mode set to: 1
[14/12/2022, 23:57:13] [midea-air] Fan Speed set to: 60
[14/12/2022, 23:57:13] [midea-air] Full data: 11001000,0,1,111100,1111111,1111111,0,101000,0,10000,0,0,0,0,0,110010,101000,1011000,0,0,0,0,0,0,1,1001001,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[14/12/2022, 23:57:13] [midea-air] [sendUpdateToDevice] Send command to device: Déshumidificateur<PHONE_NUMBER>22406)
[14/12/2022, 23:57:13] [midea-air] [sendUpdateToDevice] Fetching again the state of the device after setting new parameters...
[14/12/2022, 23:57:13] [midea-air] Updating accessory: Déshumidificateur<PHONE_NUMBER>22406)
[14/12/2022, 23:57:13] [midea-air] [updateValues] Header + Command: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,0,3,65,129,0,255,3,255,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[14/12/2022, 23:57:17] [midea-air] Triggered SET Active To: 1
[14/12/2022, 23:57:17] [midea-air] [sendUpdateToDevice] Generated a new command to set targetHumidity to: 40
[14/12/2022, 23:57:17] [midea-air] [sendUpdateToDevice] Header + Command: [90,90,1,16,90,0,32,0,1,0,0,0,189,179,57,14,12,5,20,20,29,129,0,0,0,16,0,0,0,4,2,0,0,1,0,0,0,0,0,0,170,33,161,0,0,0,0,0,3,2,72,1,1,60,0,0,0,40,0,0,0,0,0,0,0,0,0,0,0,0,0,0,20,119,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
[14/12/2022, 23:57:17] [midea-air] Send command to: Déshumidificateur<PHONE_NUMBER>22406) [sendUpdateToDevice] attempt 1/2 success!
At this point a start dehumidifier
[14/12/2022, 23:57:17] [midea-air] Current Humidity: 40
[14/12/2022, 23:57:17] [midea-air] Target humidity set to: 40
[14/12/2022, 23:57:17] [midea-air] Water level at: 0
[14/12/2022, 23:57:17] [midea-air] Power State set to: 1
[14/12/2022, 23:57:17] [midea-air] Operational Mode set to: 1
[14/12/2022, 23:57:17] [midea-air] Fan Speed set to: 60
[14/12/2022, 23:57:17] [midea-air] Full data: 11001000,1,1,111100,1111111,1111111,0,101000,0,10000,0,0,0,0,0,110010,101000,1011000,0,0,0,0,0,0,10010011,10110110,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[14/12/2022, 23:57:17] [midea-air] [sendUpdateToDevice] Send command to device: Déshumidificateur<PHONE_NUMBER>22406)
[14/12/2022, 23:57:17] [midea-air] [sendUpdateToDevice] Fetching again the state of the device after setting new parameters...
[14/12/2022, 23:57:17] [midea-air] Updating accessory: Déshumidificateur<PHONE_NUMBER>22406)
[14/12/2022, 23:57:17] [midea-air] [updateValues] Header + Command: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,0,3,65,129,0,255,3,255,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[14/12/2022, 23:57:23] [midea-air] Send command to: Déshumidificateur<PHONE_NUMBER>22406) [updateValues] attempt 1/2 returned error: The asyn reply does not exist  (3176)
[14/12/2022, 23:57:25] [midea-air] Updating accessory: Déshumidificateur<PHONE_NUMBER>22406)
[14/12/2022, 23:57:25] [midea-air] [updateValues] Header + Command: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,0,3,65,129,0,255,3,255,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[14/12/2022, 23:57:27] [midea-air] Send command to: Déshumidificateur<PHONE_NUMBER>22406) [updateValues] attempt 1/2 returned error: The asyn reply does not exist  (3176)

https://github.com/hillaliy/homebridge-midea-air#-dehumidifier-relative-humidity

https://github.com/hillaliy/homebridge-midea-air#-dehumidifier-relative-humidity

the problem ils the repporting humidity sensor.. look NetHome Plus

and look HomeKit

This happens to me as well. Current Relative Humidity doesn't update on Homebridge or the Apple Home app unless I turn off/turn on the dehumidifier.


How to hide yellow line of overflower.

My expectation is to gradually hide a layout at the top with rolling.
But in debug mode, the yellow line of overflower will be displayed.
How to hide the line in debug mode.

Why do you want to hide it?
What about fixing it, for example using a scroll view or similar so that id doesn't actually overflow?

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Charging stations

Hi,
I would like to extract all the charging stations in Germany. I guess the  ladestationen would give me this info. However, I'm not sure what "geometry" should be provided as input here. Also, the URI is localhost. Could you please provide a valid URI?
Thanks

Hi,
here is the repo for the ladestationen.
Here you can find the API description where you should be able to experiment easily with different parmeters.
The direct URL should be this:
https://services6.arcgis.com/6jU7RmJig2Wwo1b0/ArcGIS/rest/services/Ladesaeulenregister/FeatureServer/7

For the geometry you need to provide the JSON of the type you specify:
Available types : esriGeometryEnvelope, esriGeometryPoint, esriGeometryPolyline, esriGeometryPolygon, esriGeometryMultipoint


cluster not starting

Error After connecting:
<IP_ADDRESS>:7000> GET *
(error) CLUSTERDOWN The cluster is down
docker-compose config
version: '2'
services:
redis-cluster:
environment:
IP: '<IP_ADDRESS>'
build:
context: .
args:
redis_version: '4.0.10'
hostname: server
ports:
- '7000-7007:7000-7007'
environment:
CLUSTER_ONLY: 'true'

I have literally nothing to go on here becuase yoou have baiscally copied the docker-compose.yml file that is already checked into the repo and i know for a fact works. Check the logs for the container and look if you have any errors there when it tries to build up the cluster. Also if you can, try to download the container from docker-hub and run that one and see if you have the same issue or not


Negative time delays for quests

What is your Quests version / build number (do not say "latest")?
4.0.1
Describe the problem and how to replicate it. Any console errors to post using a pastebin?
Random stages of quests are delayed -1 seconds, causing the quest to get permanently stuck. The delay for these stages are actually set at a positive number (i.e. 1, 2 3 seconds).
When reaching the stage that causes the negative delay the console spits out:
[Wed, 24. Mar 2021 20:27:52 GMT WARN] Task #1147572 for Quests v4.0.1-b233 generated an exception
When quitting the quest it spits out
[Wed, 24. Mar 2021 20:28:43 GMT INFO] prototypeX37B issued server command: /quests quit Ship Rigging
[Wed, 24. Mar 2021 20:28:43 GMT INFO] b94bfded-99d5-45df-9d57-eff740af8992 quit quest Ship Rigging
When using /questadmin reload the console reads
[Wed, 24. Mar 2021 20:30:07 GMT INFO] prototypeX37B issued server command: /questadmin reload
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Loaded language en-US. Translations via Crowdin
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Loaded Module: Kill MythicMobs Objective by BerndiVader
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Registered events for custom objective "Kill MythicMobs Objective"
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Loaded Module: MythicMobs Item Require by BerndiVader, idea Wahrheit
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Loaded Module: MythicMobs Item Reward by BerndiVader
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Loaded Module: MythicMobs Conditions Require by BerndiVader, idea Wahrheit
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Loaded Module: MythicItem NPC Deliver Objective by BerndiVader, idea Wahrheit
[Wed, 24. Mar 2021 20:30:07 GMT ERROR] Plugin Quests v4.0.1-b233 has failed to register events for class com.gmail.berndivader.mythicmobsquests.MythicItemDeliverObjective because net/citizensnpcs/api/event/NPCRightClickEvent does not exist.
[Wed, 24. Mar 2021 20:30:07 GMT INFO] Registered events for custom objective "MythicItem NPC Deliver Objective"
If applicable, can you provide an example quest from quests.yml using a pastebin?

Note: we reverted back from build #233 to build #230 and that fixed the issue with the negative delays.

Thanks for the report. Would need to see an example quest for testing.

If applicable, can you provide an example quest from quests.yml using a pastebin?

Thanks for the report. Would need to see an example quest for testing.

If applicable, can you provide an example quest from quests.yml using a pastebin?

Sure, that's one of the easier quests where it was confirmed to go into negatives.
https://pastebin.com/5D6A4Cpp
We got a few other ones confirmed but probably better to get the simplest one.

I was unable to replicate the "delayed -1 seconds" issue, but I did run into #1662 which is now fixed. Hoping this will inadvertently resolve your issue as well:
https://ci.codemc.io/job/PikaMug/job/Quests/234/


Bug: filings.get(accession_no) throws: LiveError: Only one live display may be active at once

This one is quite strange and may be related to https://github.com/dgunning/edgartools/issues/20
It looks like only NEW filings are throwing this error, though I have not yet confirmed. When taking one of the most recent filing accession numbers from https://www.sec.gov/cgi-bin/browse-edgar?company=&CIK=&type=8-K&owner=include&count=100&action=getcurrent&start=2 and passing it to find the following error is thrown:
accession_no = '0001493152-24-001619'
f = find(accession_no)
           WARNING                                                                                _filings.py:626
                        Provide a year between 1994 and 2024 and optionally a quarter (1-4) for which the SEC has
                    filings.
                            e.g. filings = get_filings(2023) OR
                                 filings = get_filings(2023, 1)
                        (You specified the year 2024 and quarter 2)
           WARNING                                                                                _filings.py:626
                        Provide a year between 1994 and 2024 and optionally a quarter (1-4) for which the SEC has
                    filings.
                            e.g. filings = get_filings(2023) OR
                                 filings = get_filings(2023, 1)
                        (You specified the year 2024 and quarter 3)
           WARNING                                                                                _filings.py:626
                        Provide a year between 1994 and 2024 and optionally a quarter (1-4) for which the SEC has
                    filings.
                            e.g. filings = get_filings(2023) OR
                                 filings = get_filings(2023, 1)
                        (You specified the year 2024 and quarter 4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/blahblah/python3.11/site-packages/edgar/__init__.py", line 77, in find
    return get_by_accession_number(search_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/blahblah/python3.11/site-packages/edgar/_filings.py", line 2050, in get_by_accession_number
    return filings.get(accession_number)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/blahblah/python3.11/site-packages/edgar/_filings.py", line 812, in get
    with Status(f"[bold deep_sky_blue1]Searching through the most recent filings for {accession_number}...",
  File "/blahblah/python3.11/site-packages/rich/status.py", line 97, in __enter__
    self.start()
  File "/blahblah/python3.11/site-packages/rich/status.py", line 87, in start
    self._live.start()
  File "/blahblah/python3.11/site-packages/rich/live.py", line 113, in start
    self.console.set_live(self)
  File "/blahblah/python3.11/site-packages/rich/console.py", line 836, in set_live
    raise errors.LiveError("Only one live display may be active at once")
rich.errors.LiveError: Only one live display may be active at once
>>>

and if attempted again...
>>> f = find('0001493152-24-001619')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/blahblah/python3.11/site-packages/edgar/__init__.py", line 77, in find
    return get_by_accession_number(search_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/blahblah/python3.11/site-packages/edgar/_filings.py", line 2050, in get_by_accession_number
    return filings.get(accession_number)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/blahblah/python3.11/site-packages/edgar/_filings.py", line 812, in get
    with Status(f"[bold deep_sky_blue1]Searching through the most recent filings for {accession_number}...",
  File "/blahblah/python3.11/site-packages/rich/status.py", line 97, in __enter__
    self.start()
  File "/blahblah/python3.11/site-packages/rich/status.py", line 87, in start
    self._live.start()
  File "/blahblah/python3.11/site-packages/rich/live.py", line 113, in start
    self.console.set_live(self)
  File "/blahblah/python3.11/site-packages/rich/console.py", line 836, in set_live
    raise errors.LiveError("Only one live display may be active at once")
rich.errors.LiveError: Only one live display may be active at once

Taking a look. Will probably fix by tomorrow or Sunday. Thanks

Fixed in release 2.6.5

Awesome thanks @dgunning for the quick turnaround!


gaurav bhaskar Tic Tac Toe game contribution

Tic Tac Toe is a Classic game of strategic Xs and Os, where two players aim to form a winning trio in a 3x3 grid.

@gauravbhaskar080 As far as I can see, you have just created an empty file named Tic-Tac-Toe. Are you still working on it ???...

@gauravbhaskar080 we believe this PR was made by mistake, so we're closing this PR. Notify us if it's not created by mistake.


Fix unable to resolve path eslint error

Reduce eslint error from

✖ 4959 problems (4872 errors, 87 warnings)

Down to

✖ 1915 problems (1828 errors, 87 warnings)

Thanks!


Is there a batch doc write or async doc write interface in redisearch-py?

Hi, guys,
I only found hset to write a doc? Is there any batch write or async write to accelerate the process?
thanks~

The way to do it is by using pipeline see: https://github.com/redis/redis-py#pipelines

Oh, thanks. pipeline is also usable for ft(idx_name).client? @gkorland


XML config from documentation does not validate against schema (file appender)

Description
I am using the example configuration from https://logging.apache.org/log4j/2.x/manual/appenders.html#FileAppender and just added the schema configuration:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration xmlns="http://logging.apache.org/log4j/2.0/config"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://logging.apache.org/log4j/2.0/config https://raw.githubusercontent.com/apache/logging-log4j2/master/log4j-core/src/main/resources/Log4j-config.xsd" status="warn" name="MyApp">
  <Appenders>
    <File name="MyFile" fileName="logs/app.log">
      <PatternLayout>
        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
      </PatternLayout>
    </File>
  </Appenders>
  <Loggers>
    <Root level="error">
      <AppenderRef ref="MyFile"/>
    </Root>
  </Loggers>
</Configuration>

This config fails to validate against https://raw.githubusercontent.com/apache/logging-log4j2/master/log4j-core/src/main/resources/Log4j-config.xsd (error below). It seems that only "Appender" and "Console" are valid appender types.
Configuration
Version: 2.20.0
Operating system: Ubuntu 22.04
JDK: OpenJDK 20
Logs
Message from xmllint:
log4j2.xml:6: element File: Schemas validity error : Element '{http://logging.apache.org/log4j/2.0/config}File': This element is not expected. Expected is one of ( {http://logging.apache.org/log4j/2.0/config}Appender, {http://logging.apache.org/log4j/2.0/config}Console ).
log4j2.xml fails to validate

Eclipse gives a similar error:
cvc-complex-types.2.4.d: Invalid content was found starting with element 'File'. [...]

Reproduction
Create config file as specified and verify against linked schema (either via xmllint --noout --schema Log4j-config.xsd log4j2.xml or via Eclipse).

@zi4k4j74yn,
We renamed master to main a couple of months ago. So this is the current schema on master: https://raw.githubusercontent.com/apache/logging-log4j2/main/log4j-core/src/main/resources/Log4j-config.xsd
However, similarly to Ant and Maven, Log4j's configuration is schema-less: unless you are using the strict XML syntax (which you are not), you can not verify every valid Log4j configuration with a schema.
The one we provide only contains (part of) the definitions of those components maintained by Apache Logging Services, but there are also many custom components developed by third parties.

My bad, I did not see the main branch. Thank you a lot for the clarification!


Cannot add / remove / toggle element class inside Vue directive?

Version
2.2.6
Reproduction link
https://jsfiddle.net/hLga2jxq/
Steps to reproduce
Click the button in jsfiddle
What is expected?
"Hello! :D" text should show and hide on click of button
What is actually happening?
console shows classes where toggled but nothing visually happens

This is an example without the directive just to show what should be happening: https://jsfiddle.net/hxyv40ra/

So I tried this from another angle and also made the 'hide-name' attribute a directive as well, then on click I emitted the 'uniqueID' which 'hide-name' directive picked up.
I'm still not sure why Vue is not visually updating the browser though. I'm guessing it must have something to do with the 'virtual-dom'? In which case this might not be a bug.
Demo: https://jsfiddle.net/hLga2jxq/3/ (if anyone is interested)

You have to get the elements again as they may change: https://jsfiddle.net/posva/qr9tajLy/
Please, next time, ask questions on the forum or StackOverflow, thanks 🙂


Hosted

@lluiscampos what about https://github.com/mendersoftware/integration/pull/2451, and in particular https://github.com/mendersoftware/integration/pull/2451/commits/169880f9cc21f3371f7369ed7483ecf43d9fa663?