Editor version bump?

Any chance this lib gets bumped to version 5 sometime soon after production release arrives?

If ckeditor upgrade version 5, we will upgrade vue-ckeditor compatible.


bug(Menu): Wrapping Menu in your own component breaks focusFirstItem

Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
In the example below...

focus on the menu trigger (the button) then hit Enter on keyboard...
the menu.js code runs the focusFirstItem method..
this._directDescendantItems is empty... and thus keyboard navigation breaks on the dropdown breaks

BROKEN EXAMPLE (pass the values of dropdown from parent component):
@Component({
  selector: 'app-dropdown',
  template: `
    <button [matMenuTriggerFor]="dd">{{label}}</button>
    <mat-menu #dd="matMenu">
      <ng-content></ng-content>
    </mat-menu>
  `,
  ...

parent component:
<app-dropdown label="My Dropdown">
   <button mat-menu-item>Settings</button>
   <button mat-menu-item>Log off</button>
</app-dropdown>

Hard-coding things there works fine (obviously):
@Component({
  selector: 'app-dropdown',
  template: `
    <button [matMenuTriggerFor]="dd">{{label}}</button>
    <mat-menu #dd="matMenu">
       <button mat-menu-item>Settings</button>
       <button mat-menu-item>Log off</button>
    </mat-menu>
  `,

this works
Reproduction
Steps to reproduce:

wrapper menu with component using slots (content projection)
use keyboard to open menu

Expected Behavior
Opening menu with keyboard would focus first menu-item
Actual Behavior
Opening menu with keyboard fails to focus menu items
Environment

Angular: 14.0.4
CDK/Material: 14.0.4
Browser(s): Chrome Latest (103)
Operating System (e.g. Windows, macOS, Ubuntu):  Windows 10

Ty for reporting, @nawlbergs
Could you please provide a stackblitz reproduction of the issue?
-Zach

This won't work, because mat-menu uses a ContentChildren query to pick up the items that have been projected. The query isn't going to find the items if they're coming in from another component.

hurmph...

We are facing the same problem. Is there a workaround for this?

@zarend This is a working Stackblitz for reproduction: https://stackblitz.com/edit/angular-ivy-r2kuph

@marcel-goldammer What is your use case? If you just have a wrapper component to provide a reusable menu trigger button, you can move the <mat-menu> out of the wrapper into the app component and use @ViewChild() in the wrapper component to connect the trigger button with the menu. A bit more work in the app component (one additional element) but the button + connecting it is still in the wrapper component...

@rothsandro Thanks for your reply!
I added an example with our specific use case to that Stackblitz above. We have custom components with mat-menu-items inside. But the behavior (and maybe the cause to the problem) is exactly the same. When I open the menu using my keyboard it won't focus the first item.

Thanks for the reply. That is somewhat bad for us, but now I know, that we have to deal with those circumstances.


Pylance errors with  beartype.typing.TypeAlias

I get errors when trying to use the  beartype.typing.TypeAlias instead of typing.TypeAlias,
here are some of the error messages I get:
Key: TypeAlias = str
Expression of type "Type[str]" cannot be assigned to declared type "TypeAlias"
"Type[type]" is incompatible with "Type[TypeAlias]"PylancereportGeneralTypeIssues
CallbackFunction: TypeAlias = Callable[[Key], Any]
Expression of type "(Unknown) -> Any" cannot be assigned to declared type "TypeAlias"
"object" is incompatible with "TypeAlias"PylancereportGeneralTypeIssues
def press(key: Key):
print(f"'{key}' pressed")
Expected class type but received "TypeAlias"PylancereportGeneralTypeIssues

Clearly, Pylance popped too many benzos last night.
beartype.typing.TypeAlias is literally just typing.TypeAlias. The former is a convenient synonym for the latter; the two are the exact same object. Specifically, this is how the beartype.typing subpackage declares TypeAlias
            from typing import (  # type: ignore[attr-defined]
                ...
                TypeAlias as TypeAlias,
                ...
            )

That's it. beartype.typing just imports typing.TypeAlias into itself under the exact same name. This can't be simplified any further, because this is already maximally simple. It's just a simple import, which means that Pylance can't handle even simple imports. This is where I facepalm myself repeatedly on a Reddit livestream to farm upvotes.
What We Goin' Do Is This
Would you mind filing an upstream issue against Pyright's issue tracker, @rbroderi?
You are probably now wondering why I am now talking about "Pyright," because weren't you just talking about Pylance? Right. So, Pyright is Microsoft's static type-checker. Under the hood, Pylance leverages Pyright to statically check types. The type-checking failures you've exhibited are actually being directly emitted by Pyright – not Pylance. Pylance is just forwarding Pyright complaints to you.
This is a critical issue with Pyright, which appears to be unable to cope with PEP 484-compliant implicit type aliases. That's bad, because PEP 484 is nearly a decade old. Every type checker should at least support PEP 484.
To quote PEP 484:

Type aliases are defined by simple variable assignments:

Url = str
def retry(url: Url, retry_count: int) -> None: ...

Type aliases may be as complex as type hints in annotations – anything that is acceptable as a type hint is acceptable in a type alias:

from typing import TypeVar, Iterable, Tuple

T = TypeVar('T', int, float, complex)
Vector = Iterable[Tuple[T, T]]

def inproduct(v: Vector[T]) -> T:
    return sum(x*y for x, y in v)

Pyright appears to be failing at that. :facepalm: :man_facepalming: :woman_facepalming:

Please feel free to reopen this if there's anything tangible we can do for you, Pylance, or Pyright to make this work. I loathe closing issues unresolved – but this deflated ball is almost certainly in Pyright's court.
Oh, and thanks for the recent spate of issues! Drop us a line at the bear cave if you hit any further snags or come up with any h0t feature requests.

Thank you for the information and I will open an issue with Pyrights upstream issue tracker.

Thanks so much, @rbroderi. I know how time-consuming merely filing GitHub issues can be, because that's pretty much all I did last night. Monday evening, I want you back! :sweat_smile:
@beartype applauds the amazing work you're doing for us all.

opened as issue https://github.com/microsoft/pyright/issues/3363 on pyright. Documenting here for for discoverability.

Issue was closed upstream because Pyright only checks for typing.TypeAlias and won't implement deeper checking.

...heh. Knew it. Upstream's toxic, so it's little surprise they refuse to fix their blatantly broken and PEP-noncompliant behaviour. As detailed above, PEP 484 requires type checkers to support implicit type aliases:

Type aliases may be as complex as type hints in annotations – anything that is acceptable as a type hint is acceptable in a type alias.

typing.TypeAlias is a type hint. So, any type alias of typing.TypeAlias is also acceptable as a type hint:
# Pyright should support this simple type alias.
from typing import TypeAlias
MyTypeAlias = TypeAlias
my_str_type: MyTypeAlias = str

# Pyright should support this simple type alias, too.
from typing import TypeAlias as MyTypeAlias
my_str_type: MyTypeAlias = str

Pyright doesn't support either. Ergo, Pyright violates PEP 484 – Python's core typing standard. To no one's surprise, Pyright then refuses to fix their standards violations. :face_exhaling:
And Pyright's excuse for violating PEP 484...

TypingAlias is one of a handful of special forms that pyright needs to handle early in the "binding" phase, prior to type evaluation.

...is not a valid excuse. Mypy complies with PEP standards. Pyright needs to, too.
If Pyright currently can't because they're improperly handling TypeAlias "early in the 'binding' phase," then they need to stop doing that and start doing what mypy does. Ironically, Pyright is wrong; mypy is right. Low-level implementation details are no excuse for perpetuating wrong behaviour.

Why was beartype.typing.TypeAlias created in the first place?

The beartype.typing submodule is a one-for-one mapping of the typing module. Everything that typing provides, beartype.typing also provides and vice versa.
beartype.typing is a drop-in replacement for typing. Ideally, @beartype users should globally replace all instances of typing throughout their codebases with beartype.typing.
This is a good thing – not a bad thing. beartype.typing is demonstrably superior to typing in increasingly many ways. mypy supports these ways, because mypy is PEP-compliant; Pyright violates these ways, because Pyright is PEP-noncompliant.
This is why standards matter, people. Come on, Microsoft! Throw the community a bone here.

Reluctantly reopening, because upstream refuses to resolve their broken behaviour. It's unclear whether we can circumvent this on behalf of Pylance VSCode users – but maybe we can.
At the least, reopening this will improve discoverability and hopefully provoke some fruitful discussion.
tl;dr
Pylance VSCode users, please prefer typing.Alias to beartype.typing.TypeAlias for the moment. This isn't @beartype's fault, because we comply with PEP 484.

If so, replacing beartype.typing.TypeAlias with typing.Any. TypeAlias is mostly semantically meaningless anyway, so just aliasing to to Any mostly does little harm. Of course, that entirely defeats the purpose of using TypeAlias in the first place... but false positives would still be better than what's happening now.

So, something like this is what we're saying:
# In "beartype.typing.__init__":
if TYPE_CHECKING and IS_TYPE_CHECKER_PYRIGHT:
    TypeAlias = Any
else:
    from typing import TypeAlias as TypeAlias

Should work – maybe, in theory. But Pyright's kinda cray-cray, so maybe it'd still expurgate everywhere even if we feed it that.
B-b-but... How Do We Detect Pyright?
I have no idea. I doubt anyone else does, either. The usual approach is something like:
IS_TYPE_CHECKER_PYRIGHT = 'pyright' in sys.modules

Of course, that's fragile and error-prone. Thanks alot, Redmond.

Okay. Just begging Pyright to "go away already" is clearly an insufficient solution, despite being my preferred solution. Let's brainstorm.
I don't :heart: VSCode, because I :heart_on_fire: Vim. But if I did :heart: VSCode, here's what I personally would do:

Disable Pylance type-checking, because Pylance uses Pyright to statically type-check by default. Pyright demonstrably violates core Python type-checking standards like PEP 484, which is bad. Specifically:

Open the User Settings dialog.
Search for Type Checking Mode.
Find Python › Analysis: Type Checking Mode in the resulting search hits.
Switch the "default rule set for type checking" to off.

Enable mypy type-checking, because mypy complies with literally all Python type-checking standards. In fact, mypy is the de facto Python type-checking standard against which all other type checkers (including @beartype and Pyright) are measured. Specifically:

Install mypy.
Install the Mypy VSCode extension.
Rejoice as things actually work for once.

Data scientists and machine learning specialists especially want to switch from Pyright to mypy, because numerous scientific Python packages of interest provide mypy but not Pyright plugins – because Pyright devs refuse to implement a comparable plugin API on grounds of fundamentalist religious purity. :facepalm:
Time to Open a Can of Whoopie
Because Pylance's bad type-checking makes us look and feel bad, this is mission critical. I'm going to immediately add a new FAQ entry with this exact advice.
If someone who does :heart: VSCode could verify that the above instructions are both valid and make this issue go away, I'll happily close this after amending our FAQ.
Thanks for all the heads up, all.
Since pyright refuses to fix its violations of typing standards required by @beartype, our only recourse is to advise all VSCoders (...this means you) to embrace the VSCode Mypy extension. Let's pretend I actually tested those instructions. :sweat_smile:
Big thanks to @rbroderi for this and the companion issue #126!

Pyright devs seem toxic, so it's little surprise they refuse to fix their blatantly broken and PEP-noncompliant behaviour.

You might want to pump your brakes here a bit, my friend. pyright is basically a one-man show, which is pretty incredible when you think about how many people depend on pyright via VSCode... it probably has more (inadvertent) users than any other static type checker in the python ecosystem. Moreover, Eric is an indispensable member of the typing community, and I have found him to be quite generous with his time.

our only recourse is to advise all VSCoders (...this means you) to embrace the VSCode Mypy extension

Simply opting for the mypy VSCode extension comes with some serious downsides. Beyond pyright being much more performant than mypy speed wise (it takes mypy 60s to scan the src/ of hydra-zen vs pyright taking <6s!), pyright also supports some important typing features that mypy lacks (which would make them non-compliant with several PEPs...). These include:

recursive types
variadic generics
functools.partial (This is why jax has an opaque jit wrapper  -- it returns Wrapped like a coward -- because mypy can't handle it! pyright totally handles partial'd decorators without issue)
dataclass transforms
Self

It is absolutely bonkers how quickly (and correctly) pyright implements new typing features! For all of these reasons, I prefer pyright over mypy, even outside of the context of VSCode. (Also, did you know that it has a really cool tool for measuring the type completeness of a library?)
I just wanted to share this because I don't think that pyright should be underestimated in its importance nor its utility. And more generally, I just want peace and love among the various Python type-checkers, static and runtime alike ☮
P.S. the whole time I was writing this I kept thinking of the ad

but I liked Nintendo as a kid! So I felt like a bad guy who was peddling rude, in-your-face advertising lines from the 90s  while writing this 😞

...heh. :heart_on_fire: the SEGA trash talk. Pretty sure I heard the SEGA startup sound while reading that.
I hear and abide by everything that you are saying. You are not wrong. In fact, you're right. Like beartype, mypy is deficient in various respects. This kinda makes sense, right? Eric's a Technical Fellow at Microsoft. It's his job to get Pythonic typing correct. Meanwhile, most of the rest of us in the open-source typing community are mostly unpaid open-source volunteers. It's hard to compete. We're just here for the sheer joy of type hints. how is that even a thing
Ain't Nobody Got Time for This
Ultimately, my conundrum is that open-source volunteer time is scarce. I'd fervently love to openly embrace mypy, pyright, Google's pytype, and every other static type checker. B-b-but... I lack the bandwidth for that. Even supporting mypy is an ongoing manly struggle with destiny, deliverance, and # type: ignore[EVERYTHING-JUST-IGNORE-EVERYTHING-MYPY] debacles.
Mypy is Python's official static type checker. It's clunky, it's chunky, and it's funky. But it's also community-maintained, CLI-friendly, continuous integration (CI)-friendly, pure-Python, lightweight, and the de facto typing standard.
Pyright is none of those things. I don't know how to properly integrate pyright into either our local pytest + tox test suite or our remote GitHub Actions-based CI testing workflow – if pyright even can be. I don't even know how to properly install pyright as a system-wide package under Gentoo Linux, because pyright is crazily implemented in TypeScript (i.e., typed JavaScript) rather than pure-Python. Pyright requires node, which requires npm. Pyright is heavyweight. Pyright requires that I throw scarce resources at non-standard solutions that I personally will never leverage, because it's Vim all the way down at the @leycec cottage.
Pyright is hostile to my interests. Mypy isn't.
Honestly? I truly abhor all static type checkers. Python isn't statically typed. It's dynamically typed. Trying to pretend otherwise is an exercise in futility and # type: ignore[...] spam. The real reason @beartype supports mypy is that I can force mypy to get out @beartype's way with basically no effort in 2022. That reasoning currently doesn't extend to pyright.
But Reality Always Bats Last
Of course... this isn't the social reality of the situation. The social reality is, as you say, that pyright is inadvertently deployed across a large horizontal slice of Python's dev space. But the personal reality is that Microsoft isn't paying me to support pyright; they're paying Eric to support runtime type checkers like @beartype.
I want everyone to use @beartype. So, I want @beartype to support all actively maintained static type checkers. This includes pyright. If I can enable pyright to trivially support @beartype without a vast expenditure of effort on my part, I happily will. But... I don't know how to do that.
Thus, the conundrum continues. </sigh>

I have good news. I have bad news.
Give It to Me Straight, Doc
The good news is @beartype now officially supports pyright! Rejoice, typing gentleman – for we have vanquished a vacuous evil this day:
$ pyright beartype
No configuration file found.
No pyproject.toml file found.
stubPath /home/leycec/py/beartype/typings is not a valid directory.
Assuming Python platform Linux
Searching for source files
Found 177 source files
pyright 1.1.254
0 errors, 0 warnings, 0 informations
Completed in 13.868sec

0 errors, 0 warnings, 0 informations, people.
Yes, pyright wants us to believe that "informations" is the plural form of "information." It isn't; like the few remaining hairs on my shining head, the English noun "information" is uncountable and thus has no plural. And... that should tell you everything you need to know about pyright.
But I digress. Ultimately, this means we have resolved the related issue #126. pyright should no longer say this (...or anything, really) when confronted with @beartype in real-world code:
Type of "beartype" is partially unknown
Type of "beartype" is "Overload[(obj: BeartypeableT@beartype) ->
    BeartypeableT@beartype, (*, conf: BeartypeConf) ->
   ((BeartypeableT@BeartypeConfedDecorator) ->
   BeartypeableT@BeartypeConfedDecorator),
   (obj: BeartypeableT@beartype, *, conf: BeartypeConf = BeartypeConf()) ->
   (BeartypeableT@BeartypeReturn | ((BeartypeableT@BeartypeConfedDecorator) ->
   BeartypeableT@BeartypeConfedDecorator))]"

Our upcoming beartype 0.11.0 release thus extends static type-checking support to both mypy and pyright. Pretty sure that makes us the first Python package to explicitly support both – but I'm pretty sure someone in the peanut gallery is about to prove me wrong. Do it!
Until then, please dangerously install @beartype from git to silence pyright complains:
python -m pip install git+https://github.com/beartype/beartype.git@720d779a1a4fdb830d6374cc5dc40e6e54153042

So... How Bad Is this Bad News?
Not that bad, actually! How often does that happen, guys?
The bad news is that this issue that we are discussing here still isn't a @beartype issue, as expected. It's an upstream pyright issue. Fairly certain we can't resolve this on our end. I'd happily monkey-patch this if we could with a sketchy kludge that makes our test suite sweat bullets – but pyright is TypeScript, so there's nothing to monkey-patch.
Instead, we need pyright to do something about this. But Eric isn't inclined to do anything about this, because he's Eric. Sadly, the upstreamwontfix tag is more appropriate than even I suspected.
Do Something, You! Do Something or Face Wrath!
...yeah. I totally get it. I'd be annoyed, too.
The only consolation here is that beartype.typing.TypeAlias is just a trivial alias for typing.TypeAlias. So, please just do this for the moment:
# Instead of this...
from beartype.typing import TypeAlias

# ...please do this!
from typing import TypeAlias

# Pyright should no longer complain about this.
MyTypeHint: TypeAlias = bool | int | str | None

With apologies, I hang my head as tears stream down my dirt-streaked cheeks. Thus ends another tale of woe and debauchery in the pits of Python typing. :smiling_face_with_tear:

I have bad news.

# Instead of this...
from beartype.typing import TypeAlias

# ...please do this!
from typing import TypeAlias

With apologies...

This is the least bad bad news ever, but this just goes to show that @beartype's standards are sky high! 🚀 🚀 🚀
This is awesome! @beartype is looking real

right now. Thank you for this incredible work and for suffering through the herculean effort of supporting both pyright and mypy.

Pretty sure that makes us the first large-scale Python package to explicitly support both

You may be right! At least the first large-scale Python package that is heavily steeped in Pythons typing system!

OMG. That apropos promo shot of a 128-in-1 MegaDrive cart stacked on a classic trash Data East SNES cart stacked on an obscure NES cart with a boss logo even I have never seen before but am now desperately scavenging Google Image for.
I see your 8- and 16-bit childhood nostalgia bit-packing and raise you... the MegaDrive Tower of Doom.

Unrelatedly, GitHub's OpenAI Codex-fueled Copilot just launched. What is this nightmare fuel in IDE form? Now paired programming is an abstract cloud-hosted quasi-daemonic entity critiquing everything I code in real time against everything Guido and Soklaski are coding in real time. That's just great, guys.
Pretty sure this timeline ends with a creepy yet wise Alan Watts AI snarkily suggesting that He will catalyze the Singularity sooner than I can release beartype 1.0.0. And what will gall the most is... Alan Watts AI will not be wrong.


Missing Documentation

Is just realized that there is almost no, or at least very minimal user documentation.

In the wiki there is no user documentation at all
the man page is full of FIXMEs
some options like --kbd-list can just be found in the old wiki
options like --fonts are completely undocumented

In my eyes, for a final release, at least a correct und complete man page should be available and there should be a wiki page describing common configurations for users.
I will try to contribute to the documentation, but I do not have the time to study the code for understanding which options are there and how to use them.

I think this should be a blocker issue for 1.0 (at the very least, the manpage needs to be fixed)

Well, I am willing to help, but I do not know my way around with Eclipse, CMake and whatever you use for man pages. I think I got some spare time tomorrow which I will use to write some user documentation in the wiki.

There is an old man page[1] availavble, we need to do license checking before copy it.
[1] https://github.com/FreeRDP/FreeRDP-old/blob/master/docs/xfreerdp.1

ok, I have just updated client/X11/xfreerdp.1.xml which is used to generate the man page. I added the options which appear with xfreerdp -h but do not appear in the man page. I think we can have something more exhaustive in the future though.


QuickStart instructions are missing a crucial step

The section "Connect to your app service" fails to mention a crucial step.  After running :remote connect tinkerpop.server conf/remote-secure.yaml, you must run :remote console before issuing remote commands.   Here's the flow, which clearly shows the issue:
gremlin> :remote connect tinkerpop.server conf/remote-secure.yaml
WARN  org.apache.tinkerpop.gremlin.driver.Cluster  - SSL configured without a trustCertChainFile and thus trusts all certificates without verification (not suitable for production)
WARN  org.apache.tinkerpop.gremlin.driver.Cluster  - SSL configured without a trustCertChainFile and thus trusts all certificates without verification (not suitable for production)
==>Configured eronwright.gremlin.cosmosdb.azure.com/<IP_ADDRESS>:443

gremlin>  g.V().count()
No such property: g for class: groovysh_evaluate
Type ':help' or ':h' for help.
Display stack trace? [yN]

gremlin> :remote console
==>All scripts will now be sent to Gremlin Server - [eronwright.gremlin.cosmosdb.azure.com/<IP_ADDRESS>:443] - type ':remote console' to return to local mode
gremlin>  g.V().count()
==>0

Note that I'm using the Gremlin Console that downloaded from the quickstart section of the portal.

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

ID: cc248d85-e363-bfe6-e374-e265316e7afe
Version Independent ID: 9941f04e-9553-7054-45d6-0d1023713db2
Content: Azure Cosmos DB tutorial: Create, query, and traverse in Apache TinkerPops Gremlin Console
Content Source: articles/cosmos-db/create-graph-gremlin-console.md
Service: cosmos-db
GitHub Login: @LuisBosquez
Microsoft Alias: lbosq

@EronWright Thanks for bringing this to our attention. We are actively investigating and will get back to you soon.

I have assigned the issue to the content author to evaluate and update as appropriate.

@Mike-Ubezzi-MSFT please assign this issue to me

#please-close

@EronWright We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Thaumcraft+Quark dupe

https://github.com/Azanor/thaumcraft-api/issues/66

Do you have any video? I can't replicate this

I think it can be seen correctly on this video I made. You need to throw the pickarang to the chest on the nearest point to the pedestal

Thanks for the video!
Seems it can happen with any block, not only the pedestal. It is a Quark issue, they're not checking if the item entity is "dead" before adding it to the player's inventory, so the item is added twice.
Thanks for the report!


Floating point innaccuracy when adding two numbers

When calculating the addition of two numbers
jexl.eval(that.formula, that.context, function (err, res) {
     console.log(res);
});

where that.formula is
a+b
when the context is
{
a: 1.2,
b: 1.22
}

the result is 2.42
when the context is
{
a: 1.2,
b: 1.222
}

the result is 2.4219999999999997
and when I increase b by one more decimal place
{
a: 1.2,
b: 1.2222
}

the result is 2.4222

Unfortunately, there's nothing Jexl can do about this -- the behavior you're seeing is native to Node, and also native to most floating point math operations on an x86 processor. It's kind of crazy how obviously wrong it is, for you and me to look at it, but with how the x86 works, that's just how it comes out. Regardless of the programming language you use, it's best to convert your significant figures to integers and handle the decimal superficially.
$ node
> 1.2+1.222
2.4219999999999997

$ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1.2 + 1.222
2.4219999999999997

Is it possible to overload the math operators to use operations from another library (such as Big.js, Decimal.js)  I was reading somewhere that this library evaluates to the correct number of decimal places.

@erotavlas: You certainly can! jexl.addBinaryOp(str, (left, right) => { ... })) is exactly what you need. While the intention for this call is to add new operators to the Jexl grammar, you can use it to overwrite existing ones like + and -.  For reference, here is a list of all built in unary and binary operators: https://github.com/TechnologyAdvice/Jexl/blob/2.0/lib/grammar.js
Though, as a performance suggestion, I'd shy away from overwriting + and - et. al. because doing complex calculation for every arithmetic operation would make evaluations unnecessarily heavy. It might be worth it to add operators like +. and -. to denote decimal-sensitive arithmetic instead, and only use them when you know you need them.


mark datumaro library version when exporting as datumaro

Summary

Resolves https://jira.devtools.intel.com/browse/CVS-105523
This PR adds the datumaro format version into an exported dataset.
How to test

export a dataset as datumaro format
datumaro plugin will choose the proper reader of legacy datumaro format version

Checklist

[x] I submit my changes into the develop branch
[x] I have added description of my changes into CHANGELOG
[ ] I have updated the documentation accordingly
[x] I have added tests to cover my changes
[x] I have linked related issues

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2023 Intel Corporation
#
# SPDX-License-Identifier: MIT

Codecov Report
Patch coverage: 75.00% and project coverage change: -0.03 :warning:

Comparison is base (6b613c7) 78.48% compared to head (aafdd4d) 78.46%.

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

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #842      +/-   ##
===========================================
- Coverage    78.48%   78.46%   -0.03%
===========================================
  Files          196      196
  Lines        24304    24336      +32
  Branches      4946     4951       +5
===========================================
+ Hits         19075    19095      +20
- Misses        4127     4135       +8
- Partials      1102     1106       +4

Flag
Coverage Δ

macos-11_Python-3.8
?

ubuntu-20.04_Python-3.8
78.46% <75.00%> (-0.01%)
:arrow_down:

windows-2019_Python-3.8
?

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

Impacted Files
Coverage Δ

datumaro/components/dataset.py
82.06% <58.33%> (-0.37%)
:arrow_down:

datumaro/plugins/data_formats/datumaro/exporter.py
94.09% <75.00%> (-0.36%)
:arrow_down:

datumaro/plugins/data_formats/datumaro/importer.py
93.10% <81.81%> (-6.90%)
:arrow_down:

datumaro/components/environment.py
91.00% <100.00%> (+0.09%)
:arrow_up:

datumaro/components/importer.py
89.92% <100.00%> (+0.23%)
:arrow_up:

datumaro/plugins/synthetic_data/utils.py
83.33% <0.00%> (-1.67%)
:arrow_down:

datumaro/util/test_utils.py
84.31% <0.00%> (-0.99%)
:arrow_down:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

I re-organized code as @vinnamkim suggested, please review this PR.

@vinnamkim after rebase to the lastest develop, I added version field to datumaro_binary format.
Please review this change which is not included previously https://github.com/openvinotoolkit/datumaro/pull/842/commits/98ddc5088f3c88831b05bd4a61ba97cea5954c3c


Sub-daily observations

Possible to use datetime to forecast time series with sub-daily observations?

Hey @dkobia, check out this section of the readme.


how can I export as svg?

Is there a way to export the html contents as svg?

Nope sorry and I don't plan to do that.


Unclear Error Message "Failed to load file"  From S3Loader.load()

Checked other resources

[X] I added a very descriptive title to this issue.
[ ] I searched the LangChain.js documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain.js rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
const langchainS3oader = new S3Loader({
        bucket: process.env.S3_BUCKET || "",
        key: uploadedFile.key, // Use an S3 object that doesn't have a predefined file extension e.g. https://{{bucket_name}}.s3.{{s3_region}}.amazonaws.com/langchain/docs/1714426470392
        s3Config: {
            region: process.env.S3_REGION || "",
            credentials: {
                accessKeyId: process.env.AWS_ACCESS_KEY_ID || "",
                secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY || "",
            },
        },
        unstructuredAPIURL: "http://localhost:8000/general/v0/general",
        unstructuredAPIKey: "", // this will be soon required
    });

Error Message and Stack Trace (if applicable)
Error: Failed to load file /var/folders/42/xpqcn7hd5j9cg4sf7r_dcq800000gn/T/s3fileloader-kBU35H/langchain/docs/1714425989304 using unstructured loader.
    at S3Loader.load (/Users/user/projects/langchain-docu-chat/node_modules/langchain/dist/document_loaders/web/s3.cjs:155:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Description
I was trying to use the S3Loader.load() method to load files from my S3 bucket and I kept getting this error message -
Error: Failed to load file /var/folders/42/xpqcn7hd5j9cg4sf7r_dcq800000gn/T/s3fileloader-kBU35H/langchain/docs/1714425989304 using unstructured loader.
    at S3Loader.load (/Users/user/projects/langchain-docu-chat/node_modules/langchain/dist/document_loaders/web/s3.cjs:155:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

This error message does not explain why it's unable to load the file.
I was eventually able to figure it out by tracing the error message and adding a log in the catch block. It is supposed to throw this error message instead -
Error: Failed to partition file /var/folders/42/xpqcn7hd5j9cg4sf7r_dcq800000gn/T/s3fileloader-kBU35H/langchain/docs/1714425989304 with error 400 and message {"detail":"File type None is not supported."}
    at UnstructuredLoader._partition (/Users/user/projects/langchain-docu-chat/node_modules/langchain/dist/document_loaders/fs/unstructured.cjs:229:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async UnstructuredLoader.load (/Users/user/projects/langchain-docu-chat/node_modules/langchain/dist/document_loaders/fs/unstructured.cjs:238:26)
    at async S3Loader.load (/Users/user/projects/langchain-docu-chat/node_modules/langchain/dist/document_loaders/web/s3.cjs:150:26)

The above has a clearer error message and makes it easier to figure out what's wrong.
System Info

platform: mac
Node version: v20.3.0
yarn version: N/A
npm version: 9.6.7

 try {
      const options = {
        apiUrl: this.unstructuredAPIURL,
        apiKey: this.unstructuredAPIKey,
      };

      const unstructuredLoader = new this._UnstructuredLoader(
        filePath,
        options
      );

      const docs = await unstructuredLoader.load();

      return docs;
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    } catch (e: any) {
      throw new Error(
        `Failed to load file ${filePath} using unstructured loader : ${e.message}`
      );
    }

Maybe this will get clearer error messages.

Yes @jeasonnow that's what worked for me. I was wondering it the team would consider pushing a change for this. (I don't mind working on it).
@dosu

I raised this issue because I already identified the problem and wanted to get a go-ahead before working on it. I have created a PR that fixes this. @dosu


Remove unnecessary call to GetSyntaxRootAsync

Current coverage is 79.48%

Merging #1822 into master will increase coverage by +0.03% as of e2fff11

@@            master   #1822   diff @@
======================================
  Files          556     556
  Stmts        33700   33700
  Branches      9305    9303     -2
  Methods
======================================
+ Hit          26778   26785     +7
+ Partial       5414    5407     -7
  Missed        1508    1508

Review entire Coverage Diff as of e2fff11

Powered by Codecov. Updated on successful CI builds.

:+1:


add documentation

Adding some comments as also previously mentioned in the https://github.com/OpenCovenant/quill/issues/89 issue.

Some comments still need to be resolved. Resolve or dismiss them as needed and I'll have another look again

Alright pushed many changes and merged main into it, let me know if additional changes need to be made.


Open base64 file directly

Is there any suggestion if i want to develop my own extension to open a base64 encoded file directly.

You can use custom editors: https://code.visualstudio.com/api/extension-guides/custom-editors


fix: native filter truncation rerendering loop on hover

SUMMARY
This error was detected on a particular dashboard, for a particular set of conditions and only in chrome.
The truncation, in this case, refers to the right content of the SCOPE row.

The useTruncate function computes the truncated elements by trying to fit one element at a time in the with of their container.
Problem is, by using this information to truncate the element, and add the +X next to it, we're changing the container size, thus triggering another pass at this function.
This, in 99.9% of the cases is fine, but, in very subtle conditions, it can change the truncated count back and forth, if:

the size taken by the +X removes the space needed by the last visible element by 1
the subtle size gain by the +(X - 1) tag makes enough room for the removed element to appear again.

In this dashboard, the change was between +10 and +11, which has a very different pixel difference, but enough to cause the re-rendering loop.
This PR ensures we only compute the truncated elements if their size changes, or if the size of the parent of the container changes.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
For the reasons specified above, and given that the dashboard has private data, no gif is available.
Suffice to say, no change should be visible, the popup and truncation should remain the same for every other use case.
TESTING INSTRUCTIONS
Ensure that the native filters popup content displays correctly, and that the truncation still works as expected.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

/testenv up

Thanks for looking into this @diegomedina248 ! I ran into this a few times when testing something unrelated, and wondered if I did something weird that caused it.

🏷 preset:2022.19


Add xh

https://github.com/ducaale/xh , curl clone

I have a similar complaint https://github.com/taiki-e/install-action/pull/513#pullrequestreview-2105778288 , really don't think we should support everything here.


What about a popup_input() function?

To the best of my knowledge, we have input() and inputdialog(). What about adding a popup_input() function that let users to input chars in a popup menu?

Related: #7555

Hey thanks! I went through the discussion in the PR but in reality my request is much less than a floating window (which I agree may have some issues).
Al I am asking is only inherent to the input() function: having the exact same backend as the input() function but instead of being prompted in the command line, user is prompted in a popup. So, it is only a "frontend" request, nothing more.


Multiple Entry Points For Entry Point Driver

Refactors the Entry Point Driver and C# generation to accommodate Q# code having multiple entry points.
Major Changes:

Updated C# generation:

Now generate a unique entry point class for each entry point. These classes will no longer contain a Main method.
The Main method is generated in its own namespace and class: __QsEntryPoint__.__QsEntryPoint__.
Added a public function generateMainSource to the C# gen's EntryPoint module. This function parallels generateSource in the same module and generates the content for the C# gen's Main file.
The outputted files for C# gen are now:

the .g.cs for the C# of the Q# operations (same as before)
.g.EntryPoint.cs instead of EntryPoint.g.cs for generated entry point classes
EntryPoint.g.Main.cs for the name of the new file containing the Main method.

Microsoft.Quantum.EntryPointDriver.Azure.Submit was made public as it is used in the generated C# for entry points.
Microsoft.Quantum.EntryPointDriver.Simulation.Simulate was made public as it is used in the generated C# for entry points.
The IEntryPoint interface was changed considerably.
And more changes under the Entry Point Driver project. Too many to list here 😄.

Dependent PR on compiler repo: https://github.com/microsoft/qsharp-compiler/pull/881

/azp run


Feature/odi 87

PR checklist

[ ] Read the contribution guidelines.
[ ] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
[ ] Run the following to build the project and update samples:./mvnw clean package
./bin/generate-samples.sh
./bin/utils/export_docs_generators.sh

Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
For Windows users, please run the script in Git BASH.
[ ] In case you are adding a new generator, run the following additional script :./bin/utils/ensure-up-to-date.sh

Commit all changed files.
[ ] File the PR against the correct branch: master (6.3.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
[ ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

abandon


Details is always closed whenever the DOM is patched

This is using v0.12.1 on Firefox.
The details element will always revert to being closed whenever the DOM is patched.  Try by opening the 'Advanced' details section, then pressing the Inside or Outside buttons. I added the Nothing button to show that it is only when things are modified (and not just the triggering of a live event).
Here is the source code used:
package main

import (
	"bytes"
	"context"
	"io"
	"log"
	"net/http"
	"sync"
	"text/template"

	"github.com/jfyne/live"
)

type State struct {
	Inside  int
	Outside int
}

func main() {
	var mu sync.Mutex
	var inside, outside int
	h, err := live.NewHandler(live.NewCookieStore("session-name", []byte("weak-secret")))
	if err != nil {
		log.Fatal("could not create handler")
	}
	h.Render = func(ctx context.Context, data interface{}) (io.Reader, error) {
		tmpl, err := template.New("thermo").Parse(`

Hello

Outside is: {{.Outside}}
<button live-click="inside">Inside</button>
<button live-click="outside">Outside</button>
<button live-click="nothing">Nothing</button>

Advanced
Inside is: {{.Inside}}
<button live-click="inside">Inside</button>
<button live-click="outside">Outside</button>
<button live-click="nothing">Nothing</button>

	`)
		if err != nil {
			return nil, err
		}
		var buf bytes.Buffer
		if err := tmpl.Execute(&buf, data); err != nil {
			return nil, err
		}
		return &buf, nil
	}
	h.HandleEvent("inside", func(context.Context, *live.Socket, live.Params) (interface{}, error) {
		mu.Lock()
		defer mu.Unlock()
		inside += 1

		return &State{inside, outside}, nil
	})
	h.HandleEvent("outside", func(context.Context, *live.Socket, live.Params) (interface{}, error) {
		mu.Lock()
		defer mu.Unlock()
		outside += 1

		return &State{inside, outside}, nil
	})
	h.HandleEvent("nothing", func(context.Context, *live.Socket, live.Params) (interface{}, error) {
		mu.Lock()
		defer mu.Unlock()
		return &State{inside, outside}, nil
	})

	http.Handle("/", h)
	http.Handle("/live.js", live.Javascript{})
	http.ListenAndServe(":8080", nil)
}

If this is the same code as #37 wrapping the Outside and inside with a span will prevent the body from being patched which I believe is what is closing the details tag.

Adding the span does the trick. Perhaps there should be a note of some sort in the readme?
If live could detect when it is having to patch a larger element and issue a warning that would be helpful too.


2 bugs.

final failed aug should be giving half xp instead of full xp.
purchased item level is not factored in some of the calculations

fix these lines
for (var i = itemLevel+1; i <= MAX_AUGMENT; i++) {     avrAugs+= (i-itemLevel)*(cp(i-1, itemLevel))*(1-p(i));     avrXp+= cp(i-1, itemLevel)*(1-p(i)) * (cXpGain(i-1, itemLevel) + xpGain(i)/2); }

Thanks for the report! I'm glad this tool is still seeing some use.
The first issue should be fixed now. The second one is intended behaviour, so I've added some clarification about what the purchased item level is meant to affect.


Minor tweaks to quotes in env vars

Addresses part of #32140, in particular:

this will make it so that double backslashes in double-quoted
strings will result in a single backslash. While in single quotes it remains
a double backslash.
missing closing " and ' will now generate an error

Signed-off-by: Doug Davis<EMAIL_ADDRESS>

let me ping @tianon as well 😅

Like https://github.com/kballard/go-shellquote ? 😄


Create app.yaml

While deploying this app through Google Cloud, app.yaml file is required

While deploying this app through Google Cloud, app.yaml file is required


BuiltInDataSerializer is incredibly verbose

the BuiltInDataSerializer is incredibly verbose. It's also quite an unusual construction.
What is this object doing exactly? You've opted for an imperative style- is there a reason why the usual declarative serde approach doesn't work here? It looks like most of the fields are None, most of the time. Maybe the variants should be different objects?

Yes, it is more verbose and confusing than necessary. It should be improved, i.e. rewritten. I do not know of any technical reason to use the imperative style, but I am not the original author for this part. It seems to have been constructed by heavy use of copy, paste, and edit.
Rewriting could certainly improve this, but on the other hand:

It takes some time and effort. Volunteers are welcome.
Rewrite may introduce bugs. Now it seems somehow work. "If it is not broken, do not fix it."

Regarding "What is this object doing exactly?":
The purpose of BuiltinDataSerializer and the corresponding deserializer is to just (de)serialize some Discovery data types that the RTPS specification, Sections 8.5 and 9.6, mandates. I have been told that they are specified so that it not possible to use the usual CDR serializer/deserializer, but have not gone through the technical details myself.
This serialization is used to communicate with other DDS implementations, so it is important to follow the specification and check interoperability with others when doing any changes.

@jhelovuo i hear. not to be touched without some test coverage. #47 can help with that

If my memory serves, the idea in BuiltinDataDeserializer is that first it produces self by parse_data method. The data on the wire is a tagged list of items, or a "parameter list" representation, and those are used to fill in the various Option fields.
The self object can then be converted to various different types using generate_ -methods, depending on the context (or Topic, really).
The BuiltinDataSerializer does basically the same, but in the other direction.

I'm just starting to look at this in https://github.com/danieleades/rtps...
i'm forming the opinion that serde is not the right solution (neither is speedy!).

the specification does a good job of separating the platform independent spec from the UDP-specific elements. I think for maximum flexibility, the implementation should do the same. implementing serialisation within the platform independent modules breaks that encapsulation
using a serde-based approach makes it difficult to add other modalities in future. For example you would bend over backwards to get the UDP serialization wire format correct by creating a very bespoke serializer, or by careful and bespoke implementation of serde::{Serialize, Deserialize}, or some combination of the two. This would then wreak havoc if you later wanted to create an independent platform-dependent implementation

I now the think the most appropriate serialization strategy is to create new traits (ToBytes/FromBytes, or ToCdr/FromCdr, something along those lines). These traits would handle conversion of the various types to and from the appropriate wire format. This also removes the coupling between the structure of the types in the crate and the structure defined in the specification. Additional platform specific constructors and other methods could also be implemented separately, in a platform-dependent module.
pub trait Cdr {
   type DecodeErr: std::error::Error
   fn as_bytes(&self) -> Vec<u8>;
   fn from_bytes(bytes: impl AsRef<&[u8]>) -> Result<Self, Self::DecodeErr>;
}

that doesn't mean to say that types couldn't selectively make use of speedy or serde as helpers for implementing the Cdr trait, if that's useful.
Adding a new platform-dependent modality would involve creating new traits, and would be entirely decoupled from the UDP implementation.

This is a duplicate of issue #32 .


*: Replace kinvolk github org with flatcar-linux

Stop relying on github redirects, they are a mixed blessing and using
them broke emerge-gitclone inside dev-container in silent way. The
script could not find a desired revision of portage-stable or
coreos-overlay, because it tried to pull from kinvolk instead of
flatcar-linux github org. The redirects seem to hinder fetching a
specific commit, so the script pulled something else (HEAD or main?).

[x] Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)

CI: http://localhost:9091/job/os/job/manifest/4445/cldsv/
Fixes https://github.com/flatcar-linux/Flatcar/issues/577

CI passed.

Cherry-picked to flatcar 3033, 3066 and 3087. LTS didn't need the fix.


updated *_curvecc modulation entries in syntax.yml

changed all to have type of int and min 0 max 127
added in ampeg_hold_curveccN, ampeg_sustain_curveccN, ampeg_decay_curveccN and lfoN_pitch_curveccN
these were all observed in functioning SFZ instruments

Should be also the case to document the https://sfzformat.com/modulations/curveccN page on how this thing works in SFZ v2.
Regarding the unit and values, from what I've read in the last chat channel conversation, in ARIA this has an unsigned integer range between 0 and 255.

the curveccN page currently is all about icurveccN. I can summarize a bit from our discussions and add that in if you like

The good stuff is mostly all in curve_index page currently. Would be maybe better to put in there? Or link the pages?

I'm not the right person to review all of this, my previous reply was some side note reminder. IMHO those pages needs some revision; can't describe a modulation starting from a deprecated opcode extension and all current curve related opcodes just redirects to the related header.

I think having it all in curve_index is OK for people working on instruments. icurvecc is separate, and deprecated, so I'd be OK with adding all info to curve_index and making curvecc a symbolic link to curve_index.

That looks good. One thought... curveccN can be up to 255, but N itself can only be 1 to 127, because curvecc doesn't work with extended CCs... that's what I think based on a vague recollection of trying it once with CC142 and having it not work, but is it actually correct?

Here it is my attempt to distinguish the 2 values, if you agree:

index is the value for N
value is the effective opcode value

Makes sense to me! It already says on the extended CCs page they don't work with curvecc, so no reason to explicitly say that again under the curve header's description, and I think we now got all the info captured. Is having "index" in the YAML going to cause any problems for our data model and page building, or can we safely merge this? I guess that's a @redtide question.

index is already part of the current YAML file, the example I linked is from amp_velcurve_N but it is also used on vN opcode. I just forgot about it after a while it wasn't required to specify different values and ranges, so yes I think it can be merged.
Just as observation for a later time, I'm just a bit confused about versions, where opcodes are SFZ2 and values ARIA maybe?

Merging, then. Where opcodes are SFZ2 but have more range in ARIA (or more range in SFZ2 vs SFZ1), I guess just list the base spec in the YAML and the extra range in the text of the page... not perfect, but I think reasonable.

Hey since you brought it up quick question about index
Should it be used instead of value for varNN_target? The choice fields for that are not referring to the opcode value, but the value of target. I guess it is not really the N value either here...
Similar question for *_mod.
Currently I just have hard-coded overrides for those two in my validator... Don't want to pollute the .yml with metadata specific to my tool

I think index should be the same for all opcodes, so it should be the value of N.
I suppose it should be the case to make it explicit on all opcodes using them, so decide also how to call a second and a third index like in lfoN_eqXbw_onccY
At some point there is a need to choose the same syntax to represent that group of opcodes in the same way of others, either remove 1 N there or add one to all others since it seems that some lfo1_* seems not to be valid as lfo01_* as syntax on some players?
The current state is indeed wrong, targets are not values, this is a special case so I'm not sure how to call it, maybe just target?
I'll do the needed changes myself after your (you, @DSmolken and others) feedback.

Yes. In varNN_target, it's definitely the index that has a range, value is text. Target is another special thing, but how many things have targets? SFZ2 LFOs, SFZ2 envelopes, and var is everything that has a target, I think. So IMO it's not a standard category that needs to be in the YAML in the syntax. Having it in the page text is fine for something that only exists in three places, I think.


"MQTT entity name starts with the device name in your config"

Hi guys.
I setup pyscript in HA 2023.12.4. --> https://github.com/custom-components/pyscript
My script: imeon2mqtt.zip
i got this errors in the protocol:

can anybody help?

@rs3hc Are you sure that you own a inverter manufactured by Imeon? In your screesnhot the messages say something about Victron ...


Discussion: Support Create Sink without MView?

The original issue is at https://github.com/risingwavelabs/risingwave-test/issues/26.
Move it here manually to generate more discussion.

Currently, RisingWave only supports creating sink on a MView:
CREATE SINK my_sink FROM my_mview WITH ( ... )
However,
If RW is used for ETL(Stateless computation proposed by this issue), do we want to directly sink to downstream systems without a materialized view in the middle?
Good question 😇
Originally posted by @fuyufjh in https://github.com/risingwavelabs/risingwave-test/issues/22#issuecomment-1220213733

Q: How does Flink handle this use case?
A: Flink doesn't have Materialized Views. The create table statement in Flink actually creates a source/sink.

About the syntax: CREATE SINK my_sink FROM  may look complex. I think we may ask users to create a (non-materialized) view fist and then creating a sink from that view, which makes the syntax much clear.

Q: By the way, Materialize only supports creating sink from MView like us, unless directly from Source: https://materialize.com/docs/sql/create-sink/#conceptual-framework
I am curious about whether there is any technical reasons to block them from doing that.
A: https://github.com/MaterializeInc/materialize/issues/6468 😄

Related issue: #2317

Flink, as an alternative, has the following syntax:
CREATE TABLE fs_sink (
  auction  BIGINT,
  bidder  BIGINT,
  price  BIGINT,
  dateTime  TIMESTAMP(3),
  extra  VARCHAR,
  dt STRING,
  hm STRING
) PARTITIONED BY (dt, hm) WITH (
  'connector' = 'filesystem',
  'path' = 'file://${NEXMARK_DIR}/data/output/${SUBMIT_TIME}/bid/',
  'format' = 'csv',
  'sink.partition-commit.trigger' = 'partition-time',
  'sink.partition-commit.delay' = '1 min',
  'sink.partition-commit.policy.kind' = 'success-file',
  'partition.time-extractor.timestamp-pattern' = '$dt $hm:00',
  'sink.rolling-policy.rollover-interval' = '1min',
  'sink.rolling-policy.check-interval' = '1min'
);

Difference:

Source and Sink are both Table.   (Seems not much difference, just a different keyword)
Schema is specified.  (Enforce the schema(?) when we insert data to the same sink with output from multiple different queries)
Partition By clause (but we can also add it to the create sink from view statement).

Note that CREATE VIEW in #2317 was assumed to be "lazy" without considering this usage pattern. That is, no executor would be running (or even built) until the view is actually referenced by sth else.
If we want to extend CREATE SINK my_sink FROM my_mview WITH to non-materialized views, the things happening inside the system could be very different.

I see, I think create view has a much higher priority than create sink without MView.
We can first implement create view without considering create sink without MView if it can save a lot of effort.

As suggested by @lmatz, since we (initially) support VIEW after #6023, we can expose this functionality with CREATE SINK sink FROM logical_view and everything sounds reasonable. We can make this feature experimental and develop it for benchmarking purposes first.
We have a lot of code logic reused by CREATE SINK with CREATE MATERIALIZED VIEW, so I believe we can support it without much effort.

Support binding any TableFactor in FROM.
Correctly handle the lifecycle of SINK without materialized view.
Resolve corner issues until #6160, #6161.

As this is now tracked in #6285, we close the discussion issue.


Attempt to fix flaky test in integration/launcher_test.go

What does this PR do?
Fixes a flaky test in pkg/logs/launchers/integration/launcher_test.go by making sure each file is created, written and closed before the next file is created. This should mean that last updated timestamp between each file is greater than it was before this PR.
Motivation
Stops the build from breaking.
Describe how to test/QA your changes
Possible Drawbacks / Trade-offs
Additional Notes

/merge


finally add issue forms & templates

Just this to start? And then keep improving as we go?

Some templates look incomplete. When I was creating issue #2843 I couldn't type in anything. There was only a checkbox. I had to submit it, then edit the first comment.


WIP: SSS Maxwell (for GSoC)

This PR is for my Google Summer of Code project to implement the open/published parts of SSS Maxwell filtering in MNE-Python.

[x] Add new coil definitions that match Elekta's
[x] see why travis and appveyor are not happy
[x] Create new Maxwell filtered dataset for tests
[x] tell us how long it takes to run the tests
[ ] check test coverage with nosetests coverage plugin and tell us how good it is for the new code.
[x] add information about filtering to info like MaxFilter does
[x] change type to not be maxshield after filtering
[ ] add test of covariance calculation
...

There are other tweaks, too, but we can save those for later :) Just wanted to give you these so you can start adjusting practices as you go.

...and thanks for opening this, it's cool to see it taking shape. Feel free to ping at any point for another round of review if you make some substantial, interesting, or confusing progress.

Cool, how long before we have some sort of an example? :)

@jjnurminen, this is still in progress, but feel free to comment now or when I get it to a more finalized state.

@Eric89GXL, @mainakjas, thanks for the helpful comments. I'll come back to this after some work on doing forward solutions with with SSS. @mainakjas, no idea how long it will be before I have a working example -- somewhere between 1-4 weeks I'm guessing...

Awesome, great start. Let us know if you need a hand somewhere :)

Hi!
Happy to see that this is taking shape so quickly! Some general remarks:
In basic (spatial) SSS or Maxwell filtering, the spherical harmonics expansion is first computed for a given origin (and for the particular set of sensors). This creates a "SSS matrix" of dimensions N(sensors) x N(harmonics). From this, the expansion coefficients can be determined for each sample of magnetic field data using a simple matrix inverse. For spatial SSS, the temporal properties of the data are irrelevant; the operation is sample-by-sample and it does not matter whether raw or averaged data is filtered. I'm not sure how much distinction MNE-Python makes between raw and averaged data, but ideally the code should make it possible to filter either. Nowadays, the spatiotemporal SSS (tSSS) is more commonly applied, and usually only for raw data, since averaged data does not have enough temporal information. tSSS uses the same harmonic expansion, but does additional temporal correlation operations.
Since the harmonics need to be computed only once, it might make sense to create a class (e.g. HarmonicExpansion), which would precompute the harmonics (=SSS matrix) and store them as member variables. The class could then have methods for filtering data, using either the spatial or spatiotemporal SSS (both use the same SSS matrix). Just a suggestion.
FWIW, I wrote the original Matlab code 12 years ago as an undergraduate, so it is probably suboptimal in many ways. This might not be that important though, since the harmonics need to be computed only once for a given origin (and it will only take few seconds anyway).

cc @staulu here is Mark's ongoing PR

@jjnurminen, thanks for all the tips! As far as storing the harmonics, we'll probably just recompute them for every raw data file for this first draft. Later down the line, the harmonic expansion will likely get stored within one of our existing data types. No worries on the optimality -- I'm just trying to get everything implemented correctly first, and we'll streamline everything, add tSSS, etc. later.

Coverage increased (+0.22%) to 90.57% when pulling 7a09ae071e107444a5b5c7cdd7689149938098a4 on wronk:sss_maxwell into 2680a0454ce130b554680856fde58d939a3c4c9c on mne-tools:master.

Coverage increased (+0.22%) to 90.57% when pulling 7a09ae071e107444a5b5c7cdd7689149938098a4 on wronk:sss_maxwell into 2680a0454ce130b554680856fde58d939a3c4c9c on mne-tools:master.

Hey @Eric89GXL, I'm starting to write code to actually apply the SSS projection to data and want to get some feedback on the best strategy to do the projection.
Eventually, I'm imagining that this will be incorporated into a separate projection function (modeled after SSP), but what should the first pass look like? Should I just extract the raw's data, use matrix multiplication, and return a reconstructed raw object?

Yeah input is raw instance and output is raw instance. Eventually a matrix
operation will not suffice e.g. with movement compensation so I think it's
likely to be the final API, too.
On Jun 12, 2015 12:50 PM, "wronk"<EMAIL_ADDRESS>wrote:

Hey @Eric89GXL https://github.com/Eric89GXL, I'm starting to write code
to actually apply the SSS projection to data and want to get some feedback
on the best strategy to do the projection.
Eventually, I'm imagining that this will be incorporated into a separate
projection function (modeled after SSP), but what should the first pass
look like? Should I just extract the raw's data, use matrix
multiplication, and return a reconstructed raw object?
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/pull/2115#issuecomment-111587355
.

Okay sounds good.
I think I remember you mentioning that you processed some sample data with SSS. Did that go onto the S3 account or is it somewhere else?

No, look at the testing dataset repo under this github org.

@dengemann, @agramfort  cc:@Eric89GXL, can you check my tests and lmk what more to add? I've added a basic set, but I haven't written many unit tests before.
FYI, I'm working with Samu on tracking down the final bug(s).

before I look:

see why travis and appveyor are not happy
tell us how long it takes to run the tests
check test coverage with nosetests coverage plugin and tell us how good it is for the new code.

thanks

can you add tick boxes on PR description with left out TODOs
also switch the PR to [MRG] when ready to be reviewed.
thanks @wronk

@agramfort I actually prefer putting the better coil defs in this PR. It would presumably make the match up to numerical precision, which would make the tests much cleaner. Right now the comparison would have to be based on a high correlation or some other looser measure. I don't think it would be more than ~20 lines to get it in:

Add an additional file like mne/data/coil_defs_extra.dat (so that our current file can stay equivalent to the MNE-C one)
Add a switch to the coil def retriever for Elekta_values=False in which case it reads and uses the optimized values if Neuromag sensors are present
Modify code to use Elekta_values=True

WDYT?

BTW @wronk I started you off with a few check boxes so you could see how they are done -- please add my suggestions above (assuming @agramfort agrees) and then also anything else we mentioned for this first PR in our email planning thread

Fine with elekta coil if it's not that tricky. I just don't want you to get stuck because of this

Alright, I'll give the new coil locations a try and see if I can't get an exact match between Elekta's Maxfilter and mine. If I get stuck, we can come up with a plan B. Thanks again for all the guidance.

I made two more top-level comments related to tying up loose ends.

We need to make the type of the raw instance non-maxshield (info['maxshield'] = False), since MaxFilter undoes this designation.

We also need to populate the same fields that MaxFilter does -- look at what is in raw.info and raw_maxfiltered.info and you can see what fields you need to populate. At least your test should verify that the raw_elekta_maxfiltered and the raw_mne_python_maxfiltered info dictionaries contain the same set of keys.

If absolutely necessary we can do the info dict population later, but it would be better if it could be part of this PR.

@agramfort, @dgwakeman, @dengemann, ready for next round of comments.
Tests take ~11 sec on my machine and pass. Hopefully, I didn't introduce any new test errors, but the previously failing ones work and so do the maxwell filter specific ones.
My implementation has an avg RMS error that's less than 1000 times below the magnitude of the signal when compared to Elekta's version. Elekta confirmed that they did use single precision in some places, but it's hard to say if that's the only source of error. This implementation also matched Samu's Matlab version to numerical error for an expansion about the device origin. We're going to check a few other origins just to double check, but everything seems to be on track :)

Please also add your function to doc/source/python_reference.rst

You need to modify this like to be coil_def*.dat instead of coil_def.dat, or just add an extra line for your data file:
https://github.com/mne-tools/mne-python/blob/master/setup.py#L103

Any ideas on how to fix this last failing test? Seems like there's some kind of discrepancy in the math with Python 3.4,

setup a python3 env with anaconda for example in order to reproduce.

On Ubuntu you can also do nosetests3 ... instead of nosetests, as you can have Python2 and Python3 installed side-by-side without conflicts.

Since you're going to have to make another commit anyway, please fix the warnings (loading MaxShield raw data, improperly named files) during your test:
https://travis-ci.org/mne-tools/mne-python/jobs/70489188#L1952
Tests should not throw any un-caught warnings. Look for our use of with warnings.catch_warnings(record=True) to see how to do it.

@wronk in the interest of time I made a small cosmit PR into your branch that should make Travis happy.  BTW I think the problem with harmonics was not yours, it passes on my system on Python2 and Python3 even using the exact values of azimuth and elevation that your test had. I think there might be some regression in scipy -- maybe they overwrite some values, which would explain the discrepancy -- but I don't think we need to worry about it here.

Thanks :) I'll merge that and hopefully that will fix things.

@wronk very clean and nice to read python code! Looking forward to get into testing on real data.

+1 for merge from me
You as well @dengemann? Other comments addressed.

Congrats @wronk and welcome to Paris! ;)

@wronk please open an issue with the outline for next steps, we had some in
an email thread at one point. Also add the things marked with XXX from this
PR to our. You can do it on little sleep so perfect for this evening :)

thanks @wronk!

btw, this error still occurs for non-Elekta systems. you should look at the coil type, this should be nested under neuromag sensors check:
Didn't locate find enough Elekta coil definitions, using default MNE coils.

Also, for KIT, the coils are in coil_frame=1, which results an assertion error.
/Applications/packages/mne-python/mne/forward/_make_forward.py in _create_coils(chs, acc, t, coil_type, coilset)
    182     else:
    183         raise RuntimeError('unknown coil type')
--> 184     assert coils[0]['coord_frame'] == FIFF.FIFFV_COORD_HEAD
    185     return coils
    186

AssertionError:

ah, the latter error is caused because I loaded my raw file without the headshape info. we should have a check in there to see if the head_dev_t is defined in the info.

+1, please add that to the list of todo @wronk

Thanks everyone, making an issue now for next round of improvements

Issue #2277

Coverage decreased (-6.8%) to 84.175% when pulling e884e5ba6daec9453ad17756edbbe5c41ec20af5 on wronk:sss_maxwell into 8c28694c755f03ff3dd678075a4233c126f87cd7 on mne-tools:master.


High-level architectural illustration overlaps on the screen display

The illustration of the high-level design in the readme file does not display very well and this really does not give out the details intended to be communicated

I have fixed this issue, literally the illustration for the high-level architecture was overlapping the screen. Fixing this, I used a vertical line to represent the Pyratemeter middleware


ShutdownAsync will not complete when it encounters an error, leaving member in zombie state

I am running the latest pre-release 1.6.1-alpha.0.22
Here is where it occurs in the Cluster class:
public async Task ShutdownAsync(bool graceful = true, string reason = "")
    {
        Logger.LogInformation("Stopping Cluster {Id}", System.Id);

        // Inform all members of the cluster that this node intends to leave. Also, let the MemberList know that this
        // node was the one that initiated the shutdown to prevent another shutdown from being called.
        Logger.LogInformation("Setting GracefullyLeft gossip state for {Id}", System.Id);
        MemberList.Stopping = true;
        await Gossip.SetStateAsync(GossipKeys.GracefullyLeft, new Empty()).ConfigureAwait(false);

        ... continues with shutdown

As you can see, an error there would stop the graceful shutdown in it's tracks. So the member is blocked but never gets to shutdown, so throughout the cluster I see tons of "we are blocked" or "they are blocked" messages. Furthermore it never attempts this again because MemberList.Stopping is now set to true.
I'm not sure why the GossipActor is not able to respond so that's another thing i need to look into, since the gossip loop is also timing out on the BlockGracefullyLeft part.
Nonetheless, it seems it would be good if an issue with the gossip actor would not stop the member from being able to shutdown in a situation like this. So basically curious what other people's thoughts are, and I would be happy to submit some changes for this as well.
Basically thinking about adding try catches and possibly timeouts around each step, so that we can still continue to attempt the rest of the shutdown.
Off the top of my head, something like:
await AttemptTask(Gossip.SetStateAsync(GossipKeys.GracefullyLeft, new Empty()).ConfigureAwait(false),
    TimeSpan.FromSeconds(1), "Setting GracefullyLeft"));

Where AttemptTask looks something like:
private async Task AttemptTask(Task task, TimeSpan timeout, string name)
{
    task.ContinueWith(t =>
    {
        // if the task fails after we timeout, still log the error
        if (!t.IsCompletedSuccessfully)
        {
            Logger.LogError(t.Exception, "Error during shutdown step [{stepName}]", name);
        }
    });

    try
    {
        await Task.WhenAny(Task.Delay(timeout), task);

        if (!task.IsCompleted)
        {
            // if the task isn't complete, we timed out
            Logger.LogError(t.Exception, "Timeout during shutdown step [{stepName}] after {timeout}", name, timeout);
        }
    }
    catch (Exception e)
    {
        // if the task fails while we are waiting, it will already be logged
    }
}

Thanks.

Here's the earlier mentioned error for reference:
RootContext Got exception waiting for RequestAsync response of SetGossipStateKey:SetGossipStateKey { Key = cluster:left, Value = { } } from nonhost/$gossip
System.TimeoutException
Request didn't receive any Response within the expected time.
StackTraceString: at Proto.Future.SharedFutureProcess.SharedFutureHandle.GetTask(CancellationToken cancellationToken)
at Proto.SenderContextExtensions.RequestAsync[T](ISenderContext self, PID target, Object message, CancellationToken cancellationToken)
at Proto.RootLoggingContext.RequestAsync[T](PID target, Object message, CancellationToken cancellationToken)

The issue causing gossip timeouts should be fixed by https://github.com/asynkron/protoactor-dotnet/pull/2133, but this post brings up a separate issue, that the shutdown process is not reliable. This is pretty bad because the member will continue to run but throw various errors and not be able to do anything (zombie state) since it was set to be shutdown but never finished. I'm currently working around this issue by listening for .Cluster().MemberList.Stopping and when that triggers I give it 3 min to complete a clean shutdown otherwise i stop the application anyways.


Blog is now 404

I wanted to track down the original post, but the link is not valid.

I wanted to track down the original post, but the link is not valid.

Just updated the readme to fix this. For convenience, here's the link: https://www.ellahoeppner.com/making-randomness-fair/

Thank you for the speedy fix!


Building does not bundle dependencies

Hey, thanks for making this plugin.
During development, it works fine. However, when building, the resulting code did not bundle the dependencies thus, I was getting module not found error. Is it doing that by design? How would I go about solving this issue?
One note is: I was using dynamic imports in my code.

Put the npm-package into dependencies

it's already there

Can you provide a minimal reproduction repo?

https://github.com/Aasim-A/electron-vite-test

https://github.com/Aasim-A/electron-vite-test
Once you run the executable that was generated, you'll see the error.

A brief look at your example, first vite is not configured correctly, second if you want to bundle dependency packaging, you can use esbuild alone, and finally, the Vite-electron-plugin plugin does not seem to support dynamic loading, it is only suitable for dev mode use.
Refer to the following command:

vite-electron-plugin does not provide bundle capabilities, it is only applicable to build dependencies in dependencies into app.asar. Maybe vite-plugin-electron is more suitable for you.


Quit Menu

Wouldn't it much easier if it would quit as soon as I pressed 'y' instead of having to type 'y' and then press enter?

I suppose, and it can be implemented, but I've designed it that way to prevent accidentally quitting the application. I think pressing y+Enter provides a somewhat more (granular?) control over the quitting process, compared to just pressing y. I'm open to change this though.

I think just y would be fine as the person is already pressing q because he wishes to quit.
To prevent accidental quitting maybe you can make the prompt like Quit (y/N) ?  so if the person presses anything other than y, N is taken as default so it doesn't quit and it only quits if y is pressed.

I'll consider implementing this

+1, I'd be fine with disabling the quit confirmation altogether

I think just y would be fine as the person is already pressing q because he wishes to quit. To prevent accidental quitting maybe you can make the prompt like Quit (y/N) ?  so if the person presses anything other than y, N is taken as default so it doesn't quit and it only quits if y is pressed.

Ok, this will be implemented in the next release.

+1, I'd be fine with disabling the quit confirmation altogether

Disabling the quit confirmation is somewhat "dangerous" in my opinion. For example, if you are running a send/receive file transfer, and you accidentally press Q, the file will be corrupted, various crashes/errors will occur either on bluez, or the bluetooth stack on the other device where you initiated the transfer, since the bluetooth agent wasn't properly terminated.

How about adding Shift+Q i.e. big Q as instant quit option?
This is easy to type but hardly happens accidentally.

Faster quitting is definitely a feature I would greatly appreciate. I think shift+q is a valid choice.

For example, if you are running a send/receive file transfer, and you accidentally press Q

Just to give some context, personally, I use bluetuith as comfortable interface to scan, pair and connect devices. It opens when I click on the bluetooth icon in my waybar (and I would love to be able to quit quickly after connecting). I hadn't a use case for the transfer feature yet. Thanks for developing such a great tool. :+1:


[CROSSDATA-367] [SERVER] Server config file is now loaded only once

Instead of reading the server config file for every instance of the Server Actor, the file is read only once and a few parameters of them are passed to every instance of the Server Actor.

+1


About train_speaker_embeddings train_ecapa_tdnn_big.yaml data enhancement file

in readme.md have a train_ecapa_tdnn_big.yaml file which is concatenate waveform dropout, speed change, reverberation, noise, and noise+rev. but i can't find it in hparams path

sorry. I see this command in readme. i am also not see train_ecapa_tdnn_big.yaml. so i just want to know how use the augmentation. like python train_speaker_embeddings.py hparams/train_ecapa_tdnn.yaml and set sample_rate is ok?

Online-data augmentation has embeded in the training step. Loading  hparams/train_ecapa_tdnn.yaml  can initialize the augmentation class. In python train_speaker_embeddings.py, compute_forward called the initialized augmentation class.

thank you. i will tried use my dataset for try train model for model training


Webview on iOS

When viewing some html in the webview on iOS it appears rather small compared to the same text being viewed on the android platform.  I have tried to use RelScaleTo(2); which causes the text to appear the right size but it creates another problem of the text all positioned in the upper right corner of the control.  Is there a way to correct this?
Thanks for your help

Hi @mancda
IIRC (from Xamarin.Forms), on iOS you need to add <meta name='viewport' content='width=device-width,initial-scale=1,maximum-scale=1'/> to your HTML:
<head>
   <meta name='viewport' content='width=device-width,initial-scale=1,maximum-scale=1'/>
</head>
<body>
  ...
</body>

Very helpful.  Thanks.


how to really use JSON

Hello? I can't locate a place to insert my web address and change signatures so that I can upload to play store under my account. I was trying to integrate some native features into my webview app  which was quite frustrating and time consuming. JSON claims I could do this in less than 5 mins. How can I use this? Thanks

Also tries to import it to android studio but it returned a gradle error. Something about setting up gradle in HTTP.

Tried to import to Android Studio V3 but returned this error
Could not find method google() for arguments [] on repository container.

@arize99 This is not a git issue. Post to the forum

@arize99 please if you still have problems go to the slack channel at jasonelle.com :) thanks.


[Vault PKI] Bundle the Root CA with the intermediate in ca.crt when creating the secret

Hi folks,
We are using a SubCA (intermediate) generated by our own private PKI.
This works fine, it generates certificates but these certs only include the Intermediate SubCA  and not the Root CA.
I'm trying to use these certs for mutual TLS auth but obviously the verification fails.
Is it possible to bundle our Root CA Bundle with the intermediate used by cert-manager ?
Regards,
Smana

The CA used to sign the certificate should be set in the ca.crt field of the signed Certificate, and the chain included as part of tls.crt. Is that not the case?

No but, looking closer, this is probably done when we created the CA on Vault.
The current CA chain only contains the intermediate CA. We are looking for a method to import the full chain.
I'll keep you updated asap.

@munnerz , indeed that is the case.
Via vault pki, cert-manager get the ca.crt with only the Intermediate ca certificate.
But the tls.crt certificate contains all the chain.
Unfortunatly, we want to use it with the enforced verified TLS.
So actually with the ca and certificate returns by cert-manager we have:
openssl verify -CAfile ca.crt tls.crt
CN = vault-tmp.test.gg Intermediate Authority
error 20 at 0 depth lookup: unable to get local issuer certificate
error tls.crt: verification failed

But if I manually add the Root CA into the ca.crt:
openssl verify -CAfile ca_full_chain.crt tls.crt
tls.crt: OK

Is it possible that cert-manager to get the full ca_chain from vault via http://vault.toto.yop:8200/v1/pki/ca_chain ?

This PR would probably help https://github.com/jetstack/cert-manager/pull/1747
What do you think @munnerz ? Is there another way?
Btw @anthonyhaussman works with me

Hi,
we chose to use the root CA to issue the certificate temporarily.
Again, ideally we'd like to have the root and the intermediate CA's in the ca.crt secret.

Is there any update on this issue ?

There's not been any update(s) - if someone is able to investigate what's going on here and write a patch, that'd be great 😄 it's not something we are currently staffing in the core team

No but, looking closer, this is probably done when we created the CA on Vault.
The current CA chain only contains the intermediate CA. We are looking for a method to import the full chain.
I'll keep you updated asap.

Hi @Smana! Were you able to resolve the issue in Vault of Cert-manager? Same issue here, we need either Vault to return the Root CA cert as part of the full chain or Cert-manager to append it once it gets it from Vault. Or a third alternative would be to intervene the K8s secret after it is created by Cert-manager...

No but, looking closer, this is probably done when we created the CA on Vault.
The current CA chain only contains the intermediate CA. We are looking for a method to import the full chain.
I'll keep you updated asap.

Hi @Smana! Were you able to resolve the issue in Vault or Cert-manager? Same issue here, we need either Vault to return the Root CA cert as part of the full chain or Cert-manager to append it once it gets it from Vault. Or a third alternative would be to intervene the K8s secret after it is created by Cert-manager...

No unfortunately, we still face this issue. We have to build the whole chain and mount it as a secret. It's really painful

/reopen Same problem at our side!

When i set up my intermediate CA in vault, I added the root CA to the intermediate CA bundle via the /pki/config/ca API so that vault should return both when certificates are issued.
When i issue a secret manually, multiple certificates are included in the ca_chain section:
$ vault write -format=json pki/mypath_intermediate/issue/domain.somewhere.net common_name="test.domain.somewhere.net" ttl="24h" format=pem_bundle
{
  "request_id": "9c82689b-7393-3b7f-7ebc-383305ff4c6b",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
"data": {
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIEAz...AD=\n-----END CERTIFICATE-----",
      "-----BEGIN CERTIFICATE-----\nMIID+jCCAU=\n-----END CERTIFICATE-----"
    ],

I believe this code in question is responsible: https://github.com/jetstack/cert-manager/blob/efbd1a0095e104177f7dea9c0966d9d8b98d5f6f/pkg/internal/vault/vault.go#L145-L148
It is not clear why this was implemented; I think the full set should be used. I will submit a PR

/reopen

/reopen
/remove-lifecycle rotten
here you go!

looking forward to it @crandles . Thanks

Can we just take last element of array ... if that is a chain, then root CA is always the last one.

@munnerz @meyskens
I've just given a try for v1.2.0-alpha.0 which includes #3433, and it doesn't seem to work in some cases with self-signed certificates and intermediate CA. Not all software expects CAs in the server certificate file (tls.crt), and they are only read from ca.crt (and from system). If I manually add intermediate CA into ca.crt everything is fine. In my case, for example, Erlang SSL client and NATS messaging server aren't able to verify remote peer without intermediate CA in ca.crt. Whereas Postgres server and client work now just fine.
I understand it's intentionally that only root CA is left in ca.crt, but can we have an option (maybe via Issuer metadata) to enable mode where full CA chain is preserved in ca.crt, and tls.crt contains only leaf cert? Thank you!

@munnerz @meyskens
I've just given a try for v1.2.0-alpha.0 which includes #3433, and it doesn't seem to work in some cases with self-signed certificates and intermediate CA. Not all software expects CAs in the server certificate file (tls.crt), and they are only read from ca.crt (and from system). If I manually add intermediate CA into ca.crt everything is fine. In my case, for example, Erlang SSL client and NATS messaging server aren't able to verify remote peer without intermediate CA in ca.crt. Whereas Postgres server and client work now just fine.
I understand it's intentionally that only root CA is left in ca.crt, but can we have an option (maybe via Issuer metadata) to enable mode where full CA chain is preserved in ca.crt, and tls.crt contains only leaf cert? Thank you!

+1 for having an option to enable a mode where a full CA chain is preserved in ca.crt
I'm having the same issue with Ruby SSL Library, appending the intermediate in the ca.crt works fine.

+1 for having an option to enable a mode where a full CA chain is preserved in ca.crt
Although the ClusterIssuer's secret tls.crt contains both the root CA and the intermediate's certificate (as noted here), once I create a Certificate referencing that ClusterIssuer, what  happens is that the new Certificate will create a ca.crt with the root CA only, and its tls.crt will contain the intermediate + the own Certificate's certificate.
I expected to find the ca.crt of the Certificate to match the ClusterIssuer's secret tls.crt (which contains both root CA and the intermediate's certificate)

+1 for the "any update on this" question.


Does inventoryfile support subgroups?

Can I use sub-groups in the inventory file?  The documentation isn't clear on if there is only one level supported, or if you can nest these.
Lets say I currently have:
groups:
  - name: sandbox
    nodes:
      - sandbox1.example.com
      - sandbox2.example.com
      - sandbox3.example.com
      - sandbox4.example.com
      - sandbox5.example.com
      - sandbox6.example.com
  - name: production
    nodes:
      - prod1.example.com

Could I do something like this:
groups:
  - name: sandbox
    group:
      - name: app
        nodes:
           - sandbox1.example.com
           - sandbox2.example.com
      - name: web_server
        nodes:
           - sandbox3.example.com
           - sandbox4.example.com
     - name: db
       nodes:
          - sandbox5.example.com
          - sandbox6.example.com
  - name: production
    nodes:
      - prod1.example.com

I know the obvious answer is "rename your hostnames", but let's assume that's not an option.

We didn't initially add it. However we don't see any reason not to; I've filed BOLT-439 to add subgroups.

They do as of Bolt 0.19.

I like your style!
On Wed, Apr 18, 2018, 5:42 PM Michael Smith<EMAIL_ADDRESS>wrote:

Closed #367 https://github.com/puppetlabs/bolt/issues/367.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/puppetlabs/bolt/issues/367#event-1582577796, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADIVgUExImtutRBwM5HkkhLQnaY0RZWKks5tp8FVgaJpZM4TBzVb
.

@MikaelSmith is there a place where the sub-grouping is documented? I'm trying to find something I can use to utilize this new feature. (It's not working using the example I provided above).

It should be recursive, so try groups instead of group. We may not have documentation, but the original design was that top-level was itself a group, so groups represented the 1st nested level.

@MikaelSmith how would one specify subgroups as a target in i.e. bolt command run whoami -t 'group.subgroup' ?
(above dot notation does not work, neither does /)


Zip deployment failed - az webapp deployment - Deploying Python Teams Bot

Hi team,
I ran into some issues when trying to deploy my Zip file using az webapp deployment source config-zip --resource-group "HotCrossBotRG" --name "HotCrossBotPYWebApp" --src "<myPath>\echo-bot.zip", and I keep getting messages saying Zip deployment failed. The whole output in powershell is as follows:
Getting scm site credentials for zip deployment
Starting zip deployment. This operation can take a while to complete ...
Deployment endpoint responded with status code 202
Configuring default logging for the app, if not already enabled
Zip deployment failed. {'id': <theAppID>, 'status': 3, 'status_text': '', 'author_email': 'N/A', 'author': 'N/A', 'deployer': 'Push-Deployer', 'message': 'Created via a push deployment', 'progress': '',
'received_time': '2020-04-07T01:25:26.9111691Z',
'start_time': '2020-04-07T01:25:27.0231444Z',
'end_time': '2020-04-07T01:26:36.3530893Z',
'last_success_end_time': None, 'complete': True, 'active': False, 'is_temp': False, 'is_readonly': True,
'url': 'https://hotcrossbotpywebapp.scm.azurewebsites.net/api/deployments/latest',
'log_url': 'https://hotcrossbotpywebapp.scm.azurewebsites.net/api/deployments/latest/log',
'site_name': 'hotcrossbotpywebapp'}.
Please run the command az webapp log tail -n HotCrossBotPYWebApp -g HotCrossBotRG

The content of 'log_url' is
{
"ClassName": "System.IO.FileNotFoundException",
"Message": "No log found for 'latest'.",
"Data": null,
"InnerException": null,
"HelpURL": null,
"StackTraceString": "   at Kudu.Core.Deployment.DeploymentManager.GetLogEntries(String id) in /tmp/KuduLite/Kudu.Core/Deployment/DeploymentManager.cs:line 111\n   at Kudu.Services.Deployment.DeploymentController.GetLogEntry(String id) in /tmp/KuduLite/Kudu.Services/Deployment/DeploymentController.cs:line 432",
"RemoteStackTraceString": null,
"RemoteStackIndex": 0,
"ExceptionMethod": null,
"HResult": -2147024894,
"Source": "Kudu.Core",
"WatsonBuckets": null,
"FileNotFound_FileName": null,
"FileNotFound_FusionLog": null
}

I googled the problem and found an answer telling developers to issue this with Kudu directly(https://github.com/Azure/azure-cli/issues/11261#issuecomment-601325612).
Additional info:
The Python Microsoft Bot example can successfully run locally. (https://docs.microsoft.com/en-us/azure/bot-service/python/bot-builder-python-quickstart?view=azure-bot-service-4.0)
The deployment instructions I followed is in this page: https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-deploy-az-cli?view=azure-bot-service-4.0&tabs=Python

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


InterCa.crt is not the one the install.ps1 got signed with

Hi,
we cannot run install.ps1 with ExecutionPolicy RemoteSigned  / AllSigned as we do not have the signing certificate.
Sadly the Certificate provided in this Repository is not the one this ps1 got signed.
Can you provide the signer certificate to add it to our truststore?
Thank you

You could use install.ps1 signature to install the root certificate. Simply click Properties in Explorer over Install.ps1, select "Digital Signatures" => "View Certificate" => "Install Certificate".


Question for the FAQ

Can you clarify what happens in this scenario?

Alert suppression window is active.
An alert triggers
Alert suppression window ends
Alert has not self-resolved. Will it notify the action group as soon as the alert suppression window ends?

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

ID: f826c77e-a9c8-5baa-af70-690e8383372b
Version Independent ID: df6cea2c-8b90-706a-2dfd-041026e7396d
Content: Action rules for Azure Monitor alerts - Azure Monitor
Content Source: articles/azure-monitor/platform/alerts-action-rules.md
Service: azure-monitor
Sub-service: alerts
GitHub Login: @rboucher
Microsoft Alias: robb

Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review. Thanks for your patience.

Hi @gpetersOB
No, the action group will not activate once the suppression window is over.
When an alert wants to generate a notification (for example, it is fired or resolved), if there is an active suppression that affects it, that notification (action groups) is suppressed == not sent.

Hi @ofirmanor ,
I am not sure if I am reading your last comment correctly. If an alert was suppressed during this window and it hasn't self-resolved then after the suppression window is over no team will NOT be notified? How/What is your recommendation for us to deal with this scenario? Sounds like we need to deal with problem resources that happened during the suppression manually outside of our ITSM automations because it is not going to re-fire once the suppression window is over?

#reassign:ofirmanor

@ofirmanor Does this require a doc update?
@rajkumar-munusamy Rewording what Ofir said. Action rules suppress the notifications at the time of notification. The ending of a notification window doesn't force a recheck of alert status.  If you are using a stateless log alert, the alert will refire each time the query evaluates as true so you would get notified in that case. With a metric alert, you get notified on on firing and on  resolution.  So if the window ends after the the firing but before the resolution, you would NOT get a fired alert.
So yes, there is a potential to not be notified of the firing in this case with the stateful metric alerts.  We can update the documentation to make this clearer.  I'll see if there is some other workaround we can offer.
#label:"CreateAzMonWIFeb2021"

Thank you for your contribution to the Azure Monitor documentation. We have created a workitem for this issue in our internal backlog database. We will prioritize it and make any necessary changes as we are able.
#please-close


[MIST-1168] Prevent auto scaling when recovery is ongoing

This PR resolves #1168 via

Create a method that checks ongoing recovery in RecoveryScheduler.
Checks whether the recovery is currently ongoing or not in PeriodicDynamicScalingManager.

This issue will be addressed after #1170 is done.


Add a user-defined list of URLs to be ignored.

So that the script can be used with other scripts already doing the job (eg. youtube urls)

Is it in a new release soon?

Initially looks ok. I will try to test this properly and integrate soon.


Fix #5104: popup shown when tapping an already uploaded image in Medi…

Description (required)
Fixes #5104
What changes did you make and why?
Added The Check For READ_STORAGE_PERMISSION cause There is an error while extracting image from storage
Tested build variant on ASUS_X00TD with API level 28
Screenshots (for UI changes only)

** Screencast ***
https://user-images.githubusercontent.com/61725413/209470243-899edcd0-847f-4da4-849c-71c150a36e63.mp4

When you perform the 4 steps listed at #5104 (comment) , is the "Welcome to Full-screen Selection Mode" popup shown or not shown? A screencast would be great, thanks!

Yes Pop Up is shown but only for the first time, is it intended ?

Added The Screen Cast and Updated The Code to remove the Welcome POPUP

Tested, it seems to fix the issue, thanks!

Thanks Arin! :-)