[RFE] Upgrade all releases to iproute2 v5.8.0+

Current situation
While attempting to take advantage of XDP with cilium and have found we’re hitting an issue similar to #172. and looking it seems like this libelf and iproute2 issue was resolved and merged in a few LTS branches, but it’s not currently in the stable branches. I am wondering if there is a reason I’m not finding or if it would be possible to cherry-pick the change into stable branches going forward. https://github.com/flatcar-linux/portage-stable/pull/100
Impact
Would provide a newer iproute2 binary that is also linked against libelf.
Ideal future situation
n/a
**Implementation options
n/a
Additional information
n/a

Hi @andy-v-h,
Thanks for raising this issue. It seems we are hitting a regression, let's compare two iproute2 from current (3033.2.0) stable and an old stable (2765.2.6):
3033.2.0:
$ ldd $(which ip)
	linux-vdso.so.1 (0x00007ffda0301000)
	libbsd.so.0 => /lib64/libbsd.so.0 (0x00007f1aa9622000)
	libmnl.so.0 => /lib64/libmnl.so.0 (0x00007f1aa961a000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f1aa9615000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f1aa944e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1aa9720000)

2765.2.6:
$ ldd $(which ip)
	linux-vdso.so.1 (0x00007ffd145ea000)
	libbsd.so.0 => /lib64/libbsd.so.0 (0x00007fc18620f000)
	libelf.so.1 => /lib64/libelf.so.1 (0x00007fc1861f5000)
	libmnl.so.0 => /lib64/libmnl.so.0 (0x00007fc1861ed000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc1861e8000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc186024000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fc18600a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc186317000)

As you pointed, libelf linking is missing - it seems to appear in this commit: https://github.com/flatcar-linux/portage-stable/commit/406576c5e554e10950c82fa7f3692d62743958b2:
$ git show 406576c5e554e10950c82fa7f3692d62743958b2 -- profiles/base/package.use | grep iproute
-sys-apps/iproute2 elf

Hi @andy-v-h,
Thanks again for this bug report. iproute2 should be now linked against libelf in the following set of releases.


Pixels in pixel context widget get larger in higher miplevels

The pixel's size in the pixel context widget get larger in higher miplevels, which is not helpful.
a side effect is that when heavily enlarging a texture and then rightclick-dragging inside a pixel, the context widget actually scrolls although i stay in the same pixel. screenshot illustrating this:

i'd expect the widget to have a single pixel selected, not some small part inside it.

Changed as you suggest, since indeed it doesn't make any sense. I think I noticed this before some time but didn't get around to fixing it properly and forgot about it so it's always good to get a reminder :smile:. I might change it again to make the pixel context more zoomed in for lower mips (since it's kind of silly at 2x2, 4x4) but for the moment I'd rather keep it a consistent size than have the zoom flip back and forth:

works as expected for me.


⛏ Write a test to check if a user can redeem the same coupon code multiple times

💭 Introduction:
We want to test whether an attacker can redeem the same coupon multiple times by exploiting race condition vulnerability.
🎯 Requirements:

Filters - This test should run on apis which are used to redeem coupons. You can choose an API that has a query-param named "coupon".

Execute - Re-run the same request without any changes

Validate - If we get 90% response match, then it is vulnerable

The test should correctly detect whether the api is vulnerable to race condition.
✅ Task summary:

[ ] Ask to be assigned to the issue.
[ ] Wait to be assigned. We will try to assign in less than 2 hours.
[ ] Signup for Akto
[ ] Fork the tests-library repository, create a new branch and commit the yaml file which will be called in your test.
[ ] Submit both the PR here.

📚 Reading
You can find a detailed documentation of test editor rules here
Find 100+ examples of YAML tests here
🙋🏼♂ Questions:
If you have questions, need any help, or just want to hang out, make sure to join us on our Discord server.

@aktoboy I want to work on this issue please assign it to me.

Hey @Roshani9731, let me know if you need any help with this issue.

Hi @Roshani9731 do you need any help with this?

Hi @Roshani9731 thanks for your submission in Hackfest. 🔥 We are reviewing your work. Do these two below:

Join this group on discord for discussions around prizes? 🚀 🏆
Please fill this form your PR to be considered for prizes!

@ankush-jain-akto - I can work on this test. Could you please assign the same to me.

@Ankita28g @ankush-jain-akto
hii there!
i want to work on the test to check if a user can redeem the same coupon code multiple times #175. could you assign me this issue.

@Ankita28g @ankush-jain-akto I have raised a PR for this one. Please review and let me know if any suggestions/changes.

Hey @Ankita28g @ankush-jain-akto !! Can you please assign me this issue ?? I would love to contribute to it.

@harshalkh your YAML seems to be invalid. Logic is correct but please run the template on some valid endpoint before you make a PR.

@harshalkh your YAML seems to be invalid. Logic is correct but please run the template on some valid endpoint before you make a PR.

@avneesh-akto - I have verified the yaml using Test Editor. Please review. https://github.com/akto-api-security/tests-library/pull/21/files

@harshalkh your YAML seems to be invalid. Logic is correct but please run the template on some valid endpoint before you make a PR.

@avneesh-akto - i have made changes and tested on Test editor. please check now. https://github.com/akto-api-security/tests-library/pull/21

Hello @harshalkh , could you please make a minor adjustment? Instead of solely searching for the coupon in the query parameters, could you also check for it in the request body? Thank you! Rest looks good to me

Also change target branch to develop instead of master

Also change target branch to develop instead of master

@avneesh-akto - requested changes done..
akto-api-security/tests-library#29

Looks good @harshalkh.


Keyboard shortcuts not respected in notebook editor

Bug: Notebook Editor, Interactive Window, Editor cells
In general, it seems a lot of the vscode global shortcuts aren't respected in the Notebook Editor.
I see in the docs that:

Ctrl+Enter runs the currently selected cell, Shift+Enter runs the currently selected cell and inserts a new cell immediately below (focus moves to new cell), and Alt+Enter runs the currently selected cell and inserts a new cell immediately below (focus remains on current cell).

In this case, I'd like to change the functionality of shift+enter to just run cell and NOT select cell below. (Large cells below will scroll the whole screen and is very disruptive).
Steps to cause the bug to occur
I've changed execute notebook cell and select below to ctrl+enter (to see if I can specifically overwrite this):

And set all these run cell commands to shift+enter:

Actual behavior
shift+enter continues to run cell and select next
Expected behavior
shift+enter runs cell WITHOUT selecting next

Your Jupyter and/or Python environment
Please provide as much info as you readily know

Jupyter server running: Local
Extension version: v2020.9.114305
VS Code version: 1.50.1
Setting python.jediEnabled: (was definitely false in the past, but just checked and this doesn't show up in settings anymore. Pylance related?)
Setting python.languageServer: Pylance
Python and/or Anaconda version: 3.7.8, 3.8.1
OS: Mac
Virtual environment: conda | pipenv

Python Output
VSCode - Python Interactive Debug Log.txt

Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

Thanks for your feedback. This issue will be addressed once VS Code adds native support for editing notebooks. Please see https://github.com/microsoft/vscode/issues/91987.


PIVOT

My current project requires PIVOT statement. I also found question in StackOverflow with similar request:
http://stackoverflow.com/questions/30442969/group-by-in-angularjs. Are there any reasons to do not include it in AlaSQL?

:+1:

I like PIVOT BY syntax proposed in this SO. It easier to read and easier to realize. Of course, standard syntax also to be supported.

Love the syntax. We can even use the answer as base for the wiki about it

Hmm. How will it work when there is more than 3 cols in the original select?

Yes, there are some problems with this syntax. Anyway I am close to finish with standard syntax. Hope, this will be the first step to micro-olap features, like MDX
Отправлено с iPhone

7 июня 2015 г., в 9:50, Mathias Rangel Wulff<EMAIL_ADDRESS>написал(а):
Hmm. How will it work when there is more than 3 cols in the original select?
—
Reply to this email directly or view it on GitHub.

Another option: we can add pseudo-MDX syntax like:
SELECT ... ON ROWS, ... ON COLUMNS..., but it can interfere with AlaSQL JSON, because it used { } brackets.
Отправлено с iPhone

7 июня 2015 г., в 11:32<EMAIL_ADDRESS>написал(а):
Yes, there are some problems with this syntax. Anyway I am close to finish with standard syntax. Hope, this will be the first step to micro-olap features, like MDX
Отправлено с iPhone

7 июня 2015 г., в 9:50, Mathias Rangel Wulff<EMAIL_ADDRESS>написал(а):
Hmm. How will it work when there is more than 3 cols in the original select?
—
Reply to this email directly or view it on GitHub.

Some ideas on pivots from Postgres http://www.postgresql.org/docs/9.1/static/tablefunc.html


Small apps don't run

Don't run:

Rock, Paper, Scissor
Snake
Puzzle
Chess

Run:

Flappy bird
Star War
Timer
Clock
Windows Utilities secret apps

Bug


feat: 🎸 update github release token env

Description
Update the release token to a new ENV.
@prashantasdeveloper are we able to use the one for the SDK, or should we make a new one for this project? I think you updated the SDK and want to be consistent.
I update the ENV here to match the SDK, but we still need to set it for this repo.
Breaking Changes
N/A
JIRA Link

Checklist

[ ] Updated the Readme.md (if required) ?

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

npm package (@latest dist-tag)
GitHub release
v4.6.0
v4.6.0

Your semantic-release bot :package::rocket:


[QUESTION] How to use with async?

First check

[x] I used the GitHub search to find a similar issue and didn't find it.
[x] I searched the Typer documentation, with the integrated search.
[x] I already searched in Google "How to X in Typer" and didn't find any information.
[x] I already searched in Google "How to X in Click" and didn't find any information.

Description
I have existing methods/model functions that use async functions with encode/databases to load data but I'm unable to use these within commands without getting errors such as RuntimeWarning: coroutine 'something' was never awaited
How can I make make my @app.command() functions async friendly?

Just found https://github.com/pallets/click/issues/85#issuecomment-503464628 which may help me

It'd be nice if we could use Typer with the async-click fork.

Seeing as how FastAPI is an async framework, having an async CLI seems logical.  The main reason being sharing code from the CLI and Web entry points.  You can of course use the asgiref.sync.async_to_sync converter helpers to call existing async methods from the CLI but there are complications here and it makes your cli code clunky.  I replaced typer with smurfix/trio-click (which is asyncclick on Pypi) and it works great, but of course this is just async click, not the cool typer implementation.  Forking typer and replaceing all import click with import asyncclick as click works like a charm but it means maintenance of the fork yourself.  If @smurfix could keep his async fork maintained and up to date with click upstream, and if typer was based on asyncclick then we would really have something great here.

Thanks @smurfix.   Once you have asyncclick updated, if @tiangolo doesn't have a nice async typer by then, perhaps ill make a good typer-async fork of typer and use asyncclick and add to pypi for us all to use.

Thanks @smurfix. Once you have asyncclick updated, if @tiangolo doesn't have a nice async typer by then, perhaps ill make a good typer-async fork of typer and use asyncclick and add to pypi for us all to use.

@mreschke I made a pull request to this repo that gets you most of the way to async. https://github.com/tiangolo/typer/pull/128

@mreschke I've updated @jessekrubin's PR to remove the conflicts with master, in case you find it useful.

Thanks guys.  Ill need some time to pull it all in and prototype this instead of asyncclick.  If this all works out what is the probability of merging this request and making it a part of this official typer repo.  Optional async would be perfect.  I really hate to fork permanently.

Thanks guys.  Ill need some time to pull it all in and prototype this instead of asyncclick.  If this all works out what is the probability of merging this request and making it a part of this official typer repo.  Optional async would be perfect.  I really hate to fork permanently.

We all need this

I agree with @mreschke, we tightly couple all of our code and actually use Type CLI to call our uvicorn/guinicorn using various "management" commands. Ran into this once we wanted to use some of the async calls we have.

Hi :)
Anything new on this ?

Hi :)
Anything new on this ?

@neimad1985 I don't think async is PR-ed in yet, but I use async with typer all the time by just running the async processes from within my sync functions once the parsing is done. It works for most basic things.

Thanks for the quick answer @jessekrubin
Would it be possible that you share a simple code example on how you do this please ?

@neimad1985
from asyncio import run as aiorun

import typer

async def _main(name: str):
    typer.echo(f"Hello {name}")

def main(name: str = typer.Argument("Wade Wilson")):
    aiorun(_main(name=name))

if __name__ == "__main__":
    typer.run(main)

@jessekrubin
Ok thanks, that's exactly what I was thinking.
The problem is the duplication of functions main and _main and their arguments.
If you have multiple subcommands, which I have, for your program you have more and more duplication.
Anyway thanks for answering me.

@neimad1985 A decorator might help you:
from functools import wraps
import anyio

def run_async(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        async def coro_wrapper():
            return await func(*args, **kwargs)

        return anyio.run(coro_wrapper)

    return wrapper

@run_async
async def main(name: str = typer.Argument("Wade Wilson")):
    typer.echo(f"Hello {name}")

You can even have async completions:
import click

def async_completion(func):
    func = run_async(func)

    @wraps(func)
    def wrapper(*args, **kwargs):
        try:
            return func(*args, **kwargs)
        except (click.exceptions.Abort, click.exceptions.Exit):
            return []

    return wrapper

async def list_users() -> List[str]:
    ...

@run_async
async def main(
    name: str = typer.Argument("Wade Wilson", autocompletion=async_completion(list_users))
):
    typer.echo(f"Hello {name}")

@cauebs
Thanks, that is actually a nice idea, I will try it !

@neimad1985 Easier, but less fancy than the decorator solution is to just nest your async func:
from asyncio import run as aiorun

import typer

def main(name: str = typer.Argument("Wade Wilson")):
    async def _main():
        typer.echo(f"Hello {name}")

    aiorun(_main())

if __name__ == "__main__":
    typer.run(main)

@jessekrubin
Very nice trick. I should have thought about this. Thank you.

Just found pallets/click#85 (comment) which may help me

As that issue was closed a few years ago and is now locked I decided to open a new one containing a bit more information and addressing some comments in the previous issue. You can look at it yourself, leave some feedback (preferably typer agnostic) and upvote it to show interest in this feature: https://github.com/pallets/click/issues/2033

I think just adding those decorators to the library and having @app.command() auto detect if the function it's decorating is async or not and just pick the appropriate decoration. Not hard at all to implement. Thanks everyone for the suggestions

Actually the decorator doesn't make sense to me. The point is to support running the asynchronous function in two modes:

Called directly from the cli
Called as an asynchronous function from another function as a library function

If you just decorate the function with a function that makes it synchronous, you've ruined it.
But also we need argument information preserved.
So I propose the following:
from asyncio import sleep, run
import typer
app=typer.Typer()

def async_command(app, f):
    raise NotImplementedError()

async def async_foo(bar: str = typer.Arument(..., help="foo bar")):
    """Foo bar"""
    return await sleep(5)

cli_foo = async_command(app, async_foo)

Any ideas?

Tested the code I posted above and it works. You could probably just add it as a method to typer.Typer. I'll make a pr.

Unsure why @aogier downvoted. It runs and its integrating well into my repo.

i'm not able to be enthusiast about your attitude in this PR, this is where my emoji stem from. Given the irrelevant value your little boilerplate adds upstream this will neither add nor remove value to this library in my (irrelevant) opinion.

Noted but I don't think I've been impolite in this thread... And I believe I've added a relevant feature (the ability to wrap async functions as cli commands). Correct me if I'm wrong.

Okay, we're all trying to help here. Let's not take anything personally.
@ryanpeach Your solution is in essence very similar to mine, but yours is one step ahead. One thing you missed and that I will insist on is that we should tackle not only commands but also things such as autocompletion functions (and others I might be missing).
And another matter we should discuss before jumping to a PR (and here I kind of understand the discomfort you might have caused to @aogier) is supporting different async runtimes other than asyncio. I couldn't use the feature as it stands in your code, because I use trio instead of asyncio.
My proposal: add an "extra" on the package called anyio, alt-async or something else, that toggles an optional dependency on anyio=^3. Then, in this decorators impl, we check if anyio is available, and if it's not we fallback into asyncio (your current impl). Otherwise it's just a matter of time until someone opens another issue here requesting support for trio or something else.
On a final note, I usually wait for a maintainer to weigh in, so as not to waste any time on an unwelcome solution. I salute your initiative, but give people time to evaluate your proposal! :smile: Cheers.

@cauebs I suppose jumping to a PR is a bit of a jump, I wasn't really aware the project was big enough to have a lot of maintainers or QA. We are planning on using the code I just wrote on a rather big company cli, so the feature is required for us, and is complete for our purposes. I just demo'd how to add basic anyio support, and I'll help out as best I can. I'm sure the PR can provide good scaffolding for a future solution.

You could possibly implement Tiangolo's new little reop Asyncer, it has Aynio support for making functions async. It is very similar to @ryanpeach's implementation of anyio :)
https://github.com/tiangolo/asyncer

What is the final solution for this? I'm a bit confused.

Also interested in a solution to this.

Typer mentions being able to stack the FastAPI and Typer decorators on top of each other because they're "meant to work together". However, with FastAPI preferring async functions this actually becomes impossible. I'm not going to have to separate out my commands form the FastAPI ones despite them being the same. It really seems directly in line with the stated design of Typer to make this work.

pr  #340 test ok.  it is better.
from https://github.com/skeletorXVI/typer/tree/feature/anyio-support
not merge yet
good tutorial
import asyncio

import typer

app = typer.Typer()

@app.command()
async def wait(seconds: int):
    await asyncio.sleep(seconds)
    typer.echo(f"Waited for {seconds} seconds")

if __name__ == "__main__":
    app()

I like @ryanpeach solution. I've made an alternative that doesn't require patching the Typer class directly. You can just inherit from it normally:
from asyncio import run
from functools import wraps

import typer

class AsyncTyper(typer.Typer):
    def async_command(self, *args, **kwargs):
        def decorator(async_func):
            @wraps(async_func)
            def sync_func(*_args, **_kwargs):
                return run(async_func(*_args, **_kwargs))

            self.command(*args, **kwargs)(sync_func)
            return async_func

        return decorator

app = AsyncTyper()

@app.async_command()
async def my_async_command():
    ...

@app.command()
async def my_normal_command():
    ...

if __name__ == "__main__":
    app()

@gpkc This is f*cking genius!
@tiangolo What do you think?

class AsyncTyper(typer.Typer):
    def async_command(self, _func: Callable = None, *args, **kwargs):
        def decorator(async_func):
            @wraps(async_func)
            def sync_func(*_args, **_kwargs):
                return run(async_func(*_args, **_kwargs))

            self.command(*args, **kwargs)(sync_func)
            return async_func

        if _func:
            return decorator(_func)
        return decorator

Then it also works without parenthesis
@app.async_command
async def my_async_command():
    pass

The workaround here are very clever! In my codebases I'm trying to use type annotations wherever possible, so I annotated the above to the point where I think everything works fine. If there are any type annotation aficionados here, feel free to rip it apart:
import asyncio
from collections.abc import Callable, Coroutine
from functools import wraps
from typing import Any, ParamSpec, TypeVar

import typer

P = ParamSpec("P")
R = TypeVar("R")

class AsyncTyper(typer.Typer):
    """Asyncronous Typer that derives from Typer.

    Use this when you have an asynchronous command you want to build, otherwise, just use Typer.
    """

    def async_command(  # type: ignore # Because we're being generic in this decorator, 'Any' is fine for the args.
        self,
        *args: Any,
        **kwargs: Any,
    ) -> Callable[
        [Callable[P, Coroutine[Any, Any, R]]],
        Callable[P, Coroutine[Any, Any, R]],
    ]:
        """An async decorator for Typer commands that are asynchronous."""

        def decorator(  # type: ignore # Because we're being generic in this decorator, 'Any' is fine for the args.
            async_func: Callable[P, Coroutine[Any, Any, R]],
        ) -> Callable[P, Coroutine[Any, Any, R]]:
            @wraps(async_func)
            def sync_func(*_args: P.args, **_kwargs: P.kwargs) -> R:
                return asyncio.run(async_func(*_args, **_kwargs))

            # Now use app.command as normal to register the synchronous function
            self.command(*args, **kwargs)(sync_func)

            # We return the async function unmodified, so its library functionality is preserved.
            return async_func

        return decorator

Then for testing, how I should run CliRunner?
I have this example:
import pytest

from typer.testing import CliRunner

from manage import cli_app

runner = CliRunner()

@pytest.mark.asyncio
async def test_create_admin():
    result = runner.invoke(cli_app, ['create-admin'<EMAIL_ADDRESS>'Camila'], input='!Berlin123\n')
    assert result.exit_code == 0

I don't think it makes sense for typer to have an async_command built in.
Calling asyncio.run in the first line of the command does the job.

Calling asyncio.run in the first line of the command does the job.

Of course you actually need to pass another function to asyncio.run, so for every command you need two functions, one of which is boilerplate.
So maybe you write a decorator for it... but it's such a common case, maybe someone wrote it already...
Wait, why it isn't a part of the library?

I don't think it makes sense for typer to have an async_command built in.
Calling asyncio.run in the first line of the command does the job.

Can you please point to any examples?

I don't think it makes sense for typer to have an async_command built in.
Calling asyncio.run in the first line of the command does the job.

Can you please point to any examples?

Just call asyncio.run inside the command if you want to do it like that.
from asyncio import run as aiorun

@app.command()
def my_command(email: str) -> None:
    async def do_set_user_active():
        from <some_module> import awaitable
        await awaitable()

    aiorun(do_set_user_active())

I think the solutions above by @macintacos @rafalkrupinski @gpkc are close, but they miss the magic of typer, which is no instructions needed.  using inspect.iscoroutinefunction() (in python since 3.5) we can just do the code automatically so users can just do @app.command() as normal.
This implementation also allows to switch event loop (example show for uvloop) using the asyncio.Runner available in python >= 3.11.
I think something like this would be good to have in typer as it fits the simple design of typer.
#!/usr/bin/python

import typer
import asyncio
import inspect
import uvloop
import sys
from functools import wraps

class UTyper(typer.Typer):
    def __init__(self, *args, loop_factory=None, **kwargs):
        super().__init__(*args, **kwargs)
        self.loop_factory = loop_factory

    def command(self, *args, **kwargs):
        decorator = super().command(*args, **kwargs)
        def add_runner(f):

            @wraps(f)
            def runner(*args, **kwargs):
                if sys.version_info >= (3, 11) and self.loop_factory:
                    with asyncio.Runner(loop_factory=self.loop_factory) as runner:
                        runner.run(f(*args,**kwargs))
                else:
                    asyncio.run(f(*args,**kwargs))

            if inspect.iscoroutinefunction(f):
                return decorator(runner)
            return decorator(f)
        return add_runner

app = UTyper(loop_factory=uvloop.new_event_loop)

@app.command()
def hello(name: str):
    print(f"Hello {name}")

@app.command()
async def goodbye(name: str, formal: bool = False):
    if formal:
        print(f"Goodbye Ms. {name}. Have a good day.")
    else:
        print(f"Bye {name}!")
    await asyncio.sleep(1)

if __name__ == "__main__":
    app()

prints:
$ ./test.py goodbye asdf --formal
Goodbye Ms. asdf. Have a good day.
$ ./test.py hello asdf
Hello asdf

and the latter test pauses for a second, as expected.

This looks good, maybe this should transform into a PR?

Looks like someone is working on a PR, maybe.
One issue I'll leave here for @borissmidt is that if you use

subapp=Typer(loop_factory=...)

app=Typer(loop_factory=...)
app.add_typer(subapp,"mysub"))

then it would be nice that the "subapp" app users the loop_factory from the root Typer() object.  I hadn't written that up yet, and currently it doesn't do that in my child class or your native implementation AFAICT

I'm a bit junior in python asyncio, so if you have a sample that would be
great. I expected that it is automatically used from the task context? I.e.
you can call get_current_loop or something like that.
I coded it in a way that if the async function is called directly that the
loop factory isn't used.
On Fri, 7 Jul 2023, 21:03 toppk, @.***> wrote:

Looks like someone is working on a PR, maybe.
One issue I'll leave here for @borissmidt https://github.com/borissmidt
is that if you use
subapp=Typer(loop_factory=...)
app=Typer(loop_factory=...)app.add_typer(subapp,"mysub"))
then it would be nice that the "subapp" app users the loop_factory from
the root Typer() object. I hadn't written that up yet, and currently it
doesn't do that in my child class or your native implementation AFAICT
—
Reply to this email directly, view it on GitHub
https://github.com/tiangolo/typer/issues/88#issuecomment-1625911781, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNXZFR4C5OG2X2VYY33EQDXPBMRNANCNFSM4MGSXYGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Here's my attempt at some asyncio background: there is only one call to run during an event loop lifecycle.  you can create tasks while an event loop is running, but if there isn't an event loop you need to start it up, and the run interface is the only game in town.  The whole get_running_loop() interfaces is when you know there is a running loop and you want to do something with it.  That's not applicable for us (well it is in the fact that I use it to demonstrate different event loops in use).
Of course you can spin down the event loop and start up another one, but most of the time it's just one event loop per run.
What typer does is route to a method, and we're putting in a asyncio.run (well specifically the 3.11 version of that interface) into the decorator.  Since typer will never call two methods, then we're only starting one event loop.  Getting the loop factory option shared between Typer instances linked via Typer.add_typer is probably a more obscure use case, because it's not clear how many people replace the event loop, and certainly how many people chain together Typer instances.  But imagine if you have Typer instances started in a dozen modules then you have to go to each one to set the loop_factory, that then the one place where it all joins together.
what I'm saying that it would be nice if you don't have to set the loop factory for every typer instance, just the root.  This example below (that needs my UTyper class above, as well as uvloop package installed) shows that the loop_factory in use has to be set for each typer instance, and I think that's sub optimal, and unexpected behavior.
Since this the add_typer call is after all the decorations done, such a solution will require some minor surgery that occurs at the time of the add_typer call.  Hopefully not too bad.  But if this work is too much, I think we can get it into a second PR after this one goes it (which is what I hope you're looking to do soon).   It might be better to defer this, as it will certainly complicate the implementation.
Demonstrating that the loop factor needs to be set to each Typer instance instead of just the root.
$ python test-utyper.py goodbye foo
Bye foo!
asyncio.get_running_loop()=<uvloop.Loop running=True closed=False debug=False>

$ python test-utyper.py sub hello foo
Hello to subtest foo
asyncio.get_running_loop()=<_UnixSelectorEventLoop running=True closed=False debug=False>

app = UTyper(loop_factory=uvloop.new_event_loop)
app2 = UTyper()

@app2.command()
async def hello(name: str):
    print(f"Hello to subtest {name}")
    print(f"{asyncio.get_running_loop()=}")

app.add_typer(app2, name="sub")

@app.command()
def hello(name: str):
    print(f"Hello {name}")

@app.command()
async def goodbye(name: str, formal: bool = False):
    if formal:
        print(f"Goodbye Ms. {name}. Have a good day.")
    else:
        print(f"Bye {name}!")
    await asyncio.sleep(1)
    print(f"{asyncio.get_running_loop()=}")

if __name__ == "__main__":
    app()

1 Looking at the python async docs the loop factory might be unnecessary if
you set the eventloop policy. The disadvantage is that you have to set it
before any app is ran.
2 An alternate is to make typer uvloop aware and set it when the package is
installed.
3 The disadvantage of doing it on an typer.add is that it is a bit magic
that the parents setting is ported to the child setting bur only for the
loop. It would also be tricky to get it right with multiple levels of apps.
Also when you then run the subapp separately you still don't get the uv
eventloop.
4 maybe an classvar to set the eventloop can be used.
I think option 2 needs buy in from the project owner. Option 1 seems the
most correct solution so set the policy and i might need to update the pr
to use asyncio.get_event_loop.
Then the factory stays for app specific overrides.

asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())

loop = asyncio.get_event_loop()

On Sat, 8 Jul 2023, 07:11 toppk, @.***> wrote:

Here's my attempt at some asyncio background: there is only one call to
run during an event loop lifecycle. you can create tasks while an event
loop is running, but if there isn't an event loop you need to start it up,
and the run interface is the only game in town. The whole
get_running_loop() interfaces is when you know there is a running loop
and you want to do something with it. That's not applicable for us (well it
is in the fact that I use it to demonstrate different event loops in use).
Of course you can spin down the event loop and start up another one, but
most of the time it's just one event loop per run.
What typer does is route to a method, and we're putting in a asyncio.run
(well specifically the 3.11 version of that interface) into the decorator.
Since typer will never call two methods, then we're only starting one event
loop. Getting the loop factory option shared between Typer instances
linked via Typer.add_typer is probably a more obscure use case, because
it's not clear how many people replace the event loop, and certainly how
many people chain together Typer instances. But imagine if you have Typer
instances started in a dozen modules then you have to go to each one to set
the loop_factory, that then the one place where it all joins together.
what I'm saying that it would be nice if you don't have to set the loop
factory for every typer instance, just the root. This example below (that
needs my UTyper class above, as well as uvloop package installed) shows
that the loop_factory in use has to be set for each typer instance, and I
think that's sub optimal, and unexpected behavior.
Since this the add_typer call is after all the decorations done, such a
solution will require some minor surgery that occurs at the time of the
add_typer call. Hopefully not too bad. But if this work is too much, I
think we can get it into a second PR after this one goes it (which is what
I hope you're looking to do soon). It might be better to defer this, as it
will certainly complicate the implementation.
Demonstrating that the loop factor needs to be set to each Typer instance
instead of just the root.
$ python test-utyper.py goodbye foo
Bye foo!asyncio.get_running_loop()=<uvloop.Loop running=True closed=False debug=False>
$ python test-utyper.py sub hello foo
Hello to subtest fooasyncio.get_running_loop()=<_UnixSelectorEventLoop running=True closed=False debug=False>
app = UTyper(loop_factory=uvloop.new_event_loop)app2 = UTyper()
@app2.command()async def hello(name: str):
print(f"Hello to subtest {name}")
print(f"{asyncio.get_running_loop()=}")
app.add_typer(app2, name="sub")
@app.command()def hello(name: str):
print(f"Hello {name}")
@app.command()async def goodbye(name: str, formal: bool = False):
if formal:
print(f"Goodbye Ms. {name}. Have a good day.")
else:
print(f"Bye {name}!")
await asyncio.sleep(1)
print(f"{asyncio.get_running_loop()=}")
if name == "main":
app()
—
Reply to this email directly, view it on GitHub
https://github.com/tiangolo/typer/issues/88#issuecomment-1626860346, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNXZFTB4GASOBGDK2W7W4TXPDTXFANCNFSM4MGSXYGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@borissmidt good find.  yes, the entire loop factory/runner thing is not necessary.  i've posted a concise version below.
#!/usr/bin/python

import typer
import asyncio
import inspect
import uvloop
import sys
from functools import wraps

class UTyper(typer.Typer):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

    def command(self, *args, **kwargs):
        decorator = super().command(*args, **kwargs)
        def add_runner(f):

            @wraps(f)
            def runner(*args, **kwargs):
                asyncio.run(f(*args,**kwargs))

            if inspect.iscoroutinefunction(f):
                return decorator(runner)
            return decorator(f)
        return add_runner

app = UTyper()

"""
Demonstrating that the loop factor needs to be set to each Typer instance
 instead of just the root.

$ python test-utyper.py goodbye foo
Bye foo!
asyncio.get_running_loop()=<uvloop.Loop running=True closed=False debug=False>

$ python test-utyper.py sub hello foo
Hello to subtest foo
asyncio.get_running_loop()=<_UnixSelectorEventLoop running=True closed=False debug=False>

"""

app2 = UTyper()

@app2.command()
async def hello(name: str):
    print(f"Hello to subtest {name}")
    print(f"{asyncio.get_running_loop()=}")

app.add_typer(app2, name="sub")

@app.command()
def hello(name: str):
    print(f"Hello {name}")

@app.command()
async def goodbye(name: str, formal: bool = False):
    if formal:
        print(f"Goodbye Ms. {name}. Have a good day.")
    else:
        print(f"Bye {name}!")
    await asyncio.sleep(1)
    print(f"{asyncio.get_running_loop()=}")

if __name__ == "__main__":
    asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())
    app()

I agree, in the pr i made i only wrap the callback registered to typer. Not the function itself. I'll see if there was any progress on getting it merged.

I am working on a cli part of an async app with async DB connection, so needed the async cli as well, thanks for all contributors to the AsyncTyper / UTyper workaround, here is my working version:
import asyncio
import inspect
from functools import wraps, partial

from typer import Typer

class AsyncTyper(Typer):
    @staticmethod
    def maybe_run_async(decorator, f):
        if inspect.iscoroutinefunction(f):

            @wraps(f)
            def runner(*args, **kwargs):
                return asyncio.run(f(*args, **kwargs))

            decorator(runner)
        else:
            decorator(f)
        return f

    def callback(self, *args, **kwargs):
        decorator = super().callback(*args, **kwargs)
        return partial(self.maybe_run_async, decorator)

    def command(self, *args, **kwargs):
        decorator = super().command(*args, **kwargs)
        return partial(self.maybe_run_async, decorator)

I needed the callback to be async as well to handle database connection init instead of repeating it

Is there any good reason that async commands are not part of the library? Or is it just a missing feature?

Its a missing feature and i have a PR open but there is a funny collision
between mypy and the python versions.
https://github.com/tiangolo/typer/pull/633
I also didn't get any response on it.
On Sun, 3 Sept 2023, 10:31 Joscha Götzer, @.***> wrote:

Is there any good reason that async commands are not part of the
library? Or is it just a missing feature?
—
Reply to this email directly, view it on GitHub
https://github.com/tiangolo/typer/issues/88#issuecomment-1704048748, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNXZFXA6D4L7DSO5IVYLZ3XYQ54RANCNFSM4MGSXYGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I can't see any appeal for having it at the moment other than it being extra code to be maintained to be honest. What's the problem with just calling aiorun?

I really like typer that a function and command are the same thing. This
allows me to reuse a command to chain bigger commands together.  With
argparse i have to manually write a mapping for each typed function i want
to expose. Now we have to manually wrap each async function to become sync
or subclass typer for each project we use typer in.
While it would be better that this is handled by the typer library.
Especially since asyncio is in the standard library.
For example i could have an install dependency command which then reused
the install dependency command for each dependency. With asyncio I could
make this concurrently.
On Sun, 3 Sept 2023, 16:12 Guilherme Caminha, @.***>
wrote:

I can't see any appeal for having it at the moment other than it being
extra code to be maintained to be honest. What's the problem with just
calling aiorun?
—
Reply to this email directly, view it on GitHub
https://github.com/tiangolo/typer/issues/88#issuecomment-1704317088, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNXZFW626J7F4Y26WIM4B3XYSF47ANCNFSM4MGSXYGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I can't see any appeal for having it at the moment other than it being extra code to be maintained to be honest. What's the problem with just calling aiorun?

Either change the project motto to "Another random CLI lib that works a little bit like FastAPI" or introduce async and keep the "little brother of FastAPI" headline.
FastAPI without async? Huh?
Jokes aside, is this really such a large maintenance effort?

I can't see any appeal for having it at the moment other than it being extra code to be maintained to be honest. What's the problem with just calling aiorun?

Why not use argparse and not have extra dependencies? It's the same kind of argument. Ironically with how argparse there's less work to do this, because you don't have to place asyncio.run() for every subcommand. Given how typer operates and interest in this ticket I believe this is necessary.

Of course none of those are fair comparisons. It's still FastAPI's sibling because it follows the same design philosophy with types and clarity. Not to mention that async support is much more needed on a web framework, which allows it to handle requests concurrently. For a CLI, it's not the case that you really need concurrency in most cases.
So, in the end, the appeal to support async on Typer is purely from a compatibility perspective. For example, you might have a FastAPI project and your code will have many async parts, it can be handy to be able to call those directly from your Typer CLI.
In any case, it was just a devil's advocate positioning, no need to get emotional over it :) I'm assuming these are probably the reasons why the support for async hasn't been done yet, and of course everyone is welcome to fork the project and add it too, so you don't have to repeat anything.

I didn't mean compatibility with FastAPI. I meant compatibility with async projects' codebase in general.
If you're making multiple remote requests with HTTPX, you could organize your code to, for example, chain aiorun with asyncio.gather. If you're making a single request, there's no advantage on using asyncio as https support synchronous calls.
Again, this is just some basic questioning which I assume the package maintainers will think about and are probably the reason why thins hasn't been fixed yet.

Of course none of those are fair comparisons. It's still FastAPI's sibling because it follows the same design philosophy with types and clarity. Not to mention that async support is much more needed on a web framework, which allows it to handle requests concurrently. For a CLI, it's not the case that you really need concurrency in most scenarios.

Just because you use async only for web doesn't mean everyone else is. There are many async-only libraries that have little to do with web.

Nobody would be complaining about missing async support if was just for compatibility (similarity actually) with FastAPI. There's a increasingly common case of calling async functions, IMO the main example would be remote requests with httpx. I must admit I'm really surprised with the resistance over the 15 lines of code this change represents.

The person has nothing to do with this project he is just there to waste everyone's time, because he only uses async when using "web framework" and nothing else.

Just because you use async only for web doesn't mean everyone else is. There are many async-only libraries that have little to do with web.

Hmm you seem to lack context or interpretation. I wasn't even responding to just you, but also to someone else who was comparing Typer with FastAPI, hence my response was focused on the comparison between the two. But interesting that you are able to instantly infer my whole dev experience from this brief conversation.
This issue has been open for 3 years with no traction forward so I'm just trying to figure out why that is the case :) since I don't think there's been any official positioning about it. I'm pretty sure my questions won't change the maintainers' mind if they are leaning towards incorporating this into the package, when they get time to come here it should actually help if it doesn't get derailed by this kind of comment.
In any case, just to address your "answer", it doesn't matter if there are other async-only libraries and/or if they have to do with web. The point is that adding async capabilities to Typer means there should be an appeal for it to handle concurrency. This means now Typer will have to deal with the async loop in some form. If this hasn't been added yet, maybe the maintainer's philosophy is that this isn't the case and that concurrency should be handled by the user.

Hello all! Thanks for all the discussion and workarounds.
I want to add support for async in Typer, without making it required or default, using AnyIO as an optional dependency. In FastAPI/Starlette, AnyIO is required, as everything is just async underneath. But in Typer I don't want to force people to use AnyIO when they don't really need it. That makes the whole thing a bit more complex as I need to add all the logic to conditionally use or not AnyIO and do async or not.
This is one of the top priorities for Typer, along with a code reference (API reference). I'm finishing some things in FastAPI, I have some things in SQLModel too, and then I'll continue with Typer stuff.

AsyncTyper for anyio (Still with typing problems)
import inspect
from functools import partial, wraps

import anyio
import asyncer
import typer
from typer import Typer

class AsyncTyper(Typer):
    @staticmethod
    def maybe_run_async(decorator, f):
        if inspect.iscoroutinefunction(f):

            @wraps(f)
            def runner(*args, **kwargs):
                return asyncer.runnify(f)(*args, **kwargs)

            decorator(runner)
        else:
            decorator(f)
        return f

    def callback(self, *args, **kwargs):
        decorator = super().callback(*args, **kwargs)
        return partial(self.maybe_run_async, decorator)

    def command(self, *args, **kwargs):
        decorator = super().command(*args, **kwargs)
        return partial(self.maybe_run_async, decorator)

app = AsyncTyper()

@app.command()
async def async_hello(name: str, last_name: str = "") -> None:
    await anyio.sleep(1)
    typer.echo(f"Hello World {name} {last_name}")

@app.command()
def hello() -> None:
    print("Hello World")

if __name__ == "__main__":
    app()

I ran into a related problem when running async unit tests with pytest-asyncio because by the time the test calls runner.invoke(...) there is already a running event loop.  I'm not aware of a straightforward way to work around this issue, but I managed to find a slightly convoluted one, by effectively doing the same async-to-sync trick with the test 🤓
Would love your feedback on whether there is a better way to go about this.
# cli/commands/generate.py
...
@app.command("profiles")
@embed_event_loop
async def generate_profiles(
    count: typing.Annotated[int, typer.Argument()] = DEFAULT_COUNT
):
    """
    Generates profile data using Random User Generator API (https://randomuser.me/) and
    adds them to the database.
    """
...

# test/integration/cli/test_generate.py
...
def test_generate_profiles_happy_path(
    event_loop, # comes from pytest-asyncio
    runner: CliRunner,
):
    result = runner.invoke(["generate", "profiles"])
    assert result.exception is None
    ...
    async def verify():
        # Verify that the profiles were saved correctly to the database.
        async with db_service.session() as session:
            ...
    event_loop.create_task(verify())
...

+1 for all the efforts to add ‘asyncio‘ to ‘typer‘. It’s soon 2024 and the ‘asyncio‘ support is still missing…
I am bit dumbfounded of the hostility towards adding the ‘asyncio‘ support. I wonder is that due to divided opinions towards ‘asyncio‘ programming in general? Yes, everyone using ‘typer‘ could just go and implement their own wrappers, but that kind of negates the whole point of making a neat CLI parsing package in the first place. We could all just use ‘argparse‘, right? Sounds bit a religious argument to me. Well, the situation is the same with ‘click‘…
Thanks for all the proposals in the thread. I shall take one of those and implement it in my util library as I did with ‘click‘.

Hello all! Thanks for all the discussion and workarounds.
I want to add support for async in Typer, without making it required or default, using AnyIO as an optional dependency. In FastAPI/Starlette, AnyIO is required, as everything is just async underneath. But in Typer I don't want to force people to use AnyIO when they don't really need it. That makes the whole thing a bit more complex as I need to add all the logic to conditionally use or not AnyIO and do async or not.
This is one of the top priorities for Typer, along with a code reference (API reference). I'm finishing some things in FastAPI, I have some things in SQLModel too, and then I'll continue with Typer stuff.

Hello @tiangolo,
At least for me, by putting AnyIO as a dependency is not a problem. Actually, an async variant of the typer with specialyzed algorythm to run async functions could be enough.
In this case a check if AnyIO is importable could be put in the AsyncTyper constructor.
Thank you for these libraries you develop.

@borissmidt's PR is still open. Not sure about 'hostility'

Any news on the async support? Any way we can help?

Any news on the async support? Any way we can help?

with syncer:

✅ try this lib: https://github.com/miyakogi/syncer

pip install syncer

usage:

import os

import typer
from faststream.nats import NatsBroker
from loguru import logger
from syncer import sync

app = typer.Typer()

HOST = os.getenv("NATS_HOST", default="nats://localhost:4222")

async def aio_pub(host: str, msg: str, subject: str):
    async with NatsBroker(host) as broker:
        logger.debug(f"publish message: {msg}")
        await broker.publish(msg, subject=subject)

@app.command("pub")
def pub_task(host: str = HOST):
    #
    # here! converter: async -> sync
    #
    f_pub = sync(aio_pub)

    # sync call:
    f_pub(host, "Hi async wrap!", "test")

    logger.debug("pub task done")

if __name__ == "__main__":
    app()

any news on this?

There is a new issue, https://github.com/fastapi/typer/issues/950, meant to introduce asyncio support to Typer.
Besides that, I made a new type-annotated wrapper around typer.Typer based on this earlier comment with the added benefit that it does not depend on AnyIO or Asyncer.  I intend to use AsyncTyper until Typer gets built-in support for decorating asyncio functions.


Delete package-lock.json

Description of changes

Issue Resolved

Fixes #416

Add package-lock.json to .gitignore, and I will approve.


UnixPB: Symlink ccache to stop building from source

Fixes: #1472
Stops ccache being built from source when it is extracted from the binary retrieved in the gcc_7 task.
VPC Run: https://ci.adoptopenjdk.net/view/Tooling/job/VagrantPlaybookCheck/773/
(Only CentOS VMs are ran as they're the only ones that have the gcc_7 task ran on them)

Rerun : https://ci.adoptopenjdk.net/view/Tooling/job/VagrantPlaybookCheck/775/

Okay, I've put in a task that checks if anything is at /usr/local/bin/ccache. Also changed the tags to gcc_7 as opposed to gcc-7, to stay consistent with the name of the role.


[#1608][part-3] feat(spark3): support reading partition data from multiple reassignment servers

What changes were proposed in this pull request?
Support reading from partition block data reassignment servers.
Why are the changes needed?
For: #1608
Writer has been writing data into reassignment servers, so it's necessary to read from reassignment servers.
And the blockId will be stored in their owned partition servers, so this PR can read blockIds from these servers and
support min-replica requirements at the same time.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
PartitionBlockDataReassignTest integration test.

Codecov Report
Attention: Patch coverage is 88.88889% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 54.96%. Comparing base (1051d26) to head (7dfdb43).

Files
Patch %
Lines

...he/uniffle/server/buffer/ShuffleBufferManager.java
0.00%
2 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1615      +/-   ##
============================================
+ Coverage     53.98%   54.96%   +0.98%
- Complexity     2872     2881       +9
============================================
  Files           438      418      -20
  Lines         24927    22584    -2343
  Branches       2126     2130       +4
============================================
- Hits          13456    12414    -1042
+ Misses        10626     9398    -1228
+ Partials        845      772      -73

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

PTAL @dingshun3016 @xumanbu @jerqi

There are some points which I cared:

Do we support multiple times reassignments? Do we add some tests for this case?
Do we work with multiple replicas well?

In the same task, when the failed blocks resend successfully and the remaining blocks need to be sent, partitionToServers needs to be replaced with the last one in org.apache.spark.shuffle.writer.WriteBufferManager#createShuffleBlock

In the same task, when the failed blocks resend successfully and the remaining blocks need to be sent, partitionToServers needs to be replaced with the last one in org.apache.spark.shuffle.writer.WriteBufferManager#createShuffleBlock

Yes, this is on the plan, but i will not reuse the concept of partitionToServer. Please wait for the following PRs

Fix the CI failure. PTAL @jerqi

Thanks @jerqi @dingshun3016 @xumanbu @EnricoMi  for your review. Merged.


[PROPOSAL] - make all the identifiers case sensitive in v 3.0

In v 2.x there are some incoherences in how OrientDB manages case sensitivity of identifiers.
Two examples:

class names are case insensitive, but property names are case sensitive
class names are case insensitive everywhere, except as out(), in()... arguments

I propose, in v 3.0, to make all the identifiers case sensitive.
Identifiers include:

class names
property names
index names
cluster names
function names
method names
aliases

:+1: Without consistency, intuitiveness is unreachable. :smile:
Scott

I vote for the opposite: let's make fields case insensitive, so everything is coherent and is back compatibile. The only things it wouldn't work if somebody created properties 'name' and 'Name' on the same record, but this is not common.
Also identifiers are case insensitive in many SQL grammars too. The RDBMS user is expecting this.

@lvca different RDBMS implementations have different behaviors on this.
Let me add some reasons to have case sensitive implementation:

no need for toLowerCase() toUpperCase() in the code, that means less CPU cycles, less memory consumption, less GC
no problems with locales (see https://en.wikipedia.org/wiki/Dotted_and_dotless_I)
no problems with non-ascii characters
compatibility with TinkerPop standard (property names are case sensitive)

btw, case insensitive field names would not be backward compatible

In Mysql the table names and aliases are case sensitive, because the Linux file system is case sensitive. On Windows and OSX (with HFS), they aren't. Column/ Field names are case insensitive. http://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html
In PostgreSQL, the identifiers are automatically reduced to lower case, unless they are in double quotes. So, a very forced case sensitivity. https://le-gall.net/pierrick/blog/index.php/2006/12/01/90-postgresql-and-case-sensitivity
MSSQL is partially case sensitive. You can't mix cases when creating, but can for the RUD commands. I think I explained that right.  https://msdn.microsoft.com/en-us/library/aa290089(v=vs.71).aspx
So, summa summarum, the programmer won't be expecting case insensitivity necessarily. But for sure, he or she would very much expect consistency, which case sensitivity offers. Also, it means we devs don't have to add quotes to queries to be case sensitive. It also means user land must hold up (and can use) a particular case type for their identifier naming convention https://danielmiessler.com/blog/a-list-of-different-case-types/ which I really like. :smile:
Scott

Hi,
I'm for the case sensitive, also because the other protocol we use appart sql are case sensitive (Json,our binary protocol).
In general case sensitive make the engine simpler and faster, on the other side the IDE (studio) should give suggestion in case is defined a property with differnet case of the one in the sql.

+1 for case sensitive

Just to add even more fuel to the flame:

Also identifiers are case insensitive in many SQL grammars too. The RDBMS user is expecting this.

I'm for Luca's approach here :)
And Postgres way (see @smolinari's comment) feels as most common sensetive.

:D It's a hard decision to take, so all the fuel is welcome
Thanks
Luigi

+1 for case-sensitive, for all the reasons outlined already.
Mario
On Wed, Apr 27, 2016 at 10:47 AM, luigidellaquila<EMAIL_ADDRESS>wrote:

:D It's a hard decision to take, so all the fuel is welcome
Thanks
Luigi
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/orientechnologies/orientdb/issues/6052#issuecomment-215107479

--

Mario Cormier

@a-unite - How do you see the semi-forced case sensitivity, as PostreSQL does it, as the best way? What are the advantages and disadvantages?
The only thing I can think of is the ability to use spaces in identifiers with double quotes, which is still possible to do with ODB too. So, ODB could also be completely case sensitive without quotes, and only need double quotes for the spaces in identifiers.
What I personally don't like about the PostgreSQL method is the forcing of all identifiers (without double quotes) to lower case. You send in aClassWithALongNameWhichYouCanRead and get back aclasswithalongnamewhichyoucantread (yeah, PostgreSQL won't add the "t" :smile: ). That's a problem and limits us as developers. It "dumbs down" the API.
Scott

@smolinari,
My main reason is:
If ODB is going to be popular - then we have to provide most convenient way for ordinal users, not only for advanced and highly professional ;) geeks as we are.
This is especially important since we don't have and will not have any possibility to signal user (in schema-less mode), that he has empty result set not because there is no data for his query, but because he wrote one or whatever letters (i.e. AClassWithALongNameWhichYouCanRead.Property) in wrong case.
About identifiers returned in low-case when select query executed - I agree, this is not so good. Sorry, I must misunderstood your comment and didn't check actual Postgres behavior (already forgot how it worked). But I guess, we could store two versions of identifiers - in low case for system use (if it is chipper than conversion and to use them as file names, so there are no problems in transition between operating systems) and actual (as is) version to return for humans to read.
There is still the problem with case conversion if non Latin letters used for identifiers, but I believe, again - it is better to strict them with Latin only symbols, to prevent any possible problems with OS file systems support.
Regards,
Ata

Thanks for the explanation @a-unite.
Scott

+1 for case sensitive for all the reasons reported above and because it allows a better management of unstructured data.

Hi,  :+1:  for  case sensitive . this is **orientdb ** in the new age of databases absolutly  :)

👍 for case sensitive everywhere.

Looks like Case Sensitivity is winning! :smile:
Scott

Guys, I'd rather prefer looking at the big picture here. Changing this means that all the current users could have to rewrite most of their queries if they want to upgrade to v3.0 and in some application this could be really expensive.
Take a look at the biggest DBMS players:

Oracle is case insensitive
MySQL change behaviour on Linux and Windows...
Postgres is case insensitive
Cassandra is case insensitive by default

This change is not about resolving a critical bug or increasing the performance by 2x.
I'm against introducing this big break in compatibility, just for the sake of being more "coherent" (coherent with what?).  I can be coherent with the syntax if everything is declared and documented. There is no need to be "uniform" (this is a better word to represent the intent) across all the names in every section of OrientDB and plugins.

Hi Luca,
I understand your point and it makes sense, but let's define an expected behavior for class name equality.

How is a class name stored in the db? I'd say the original name that is defined at creation time.
How is class name equality calculated? The String.equalsIgnoreCase() method does not accept a locale, the toUpperCase() and toLowerCase() can be used with a locale. Which locale? The db locale or the machine locale? What does it happen when you move your DB to another machine or when you manually change the locale?

Thanks
Luigi

Agreed (so like now)

About (2), this is the implementation of Java String:
    public boolean equalsIgnoreCase(String anotherString) {
        return (this == anotherString) ? true
                : (anotherString != null)
                && (anotherString.value.length == value.length)
                && regionMatches(true, 0, anotherString, 0, value.length);
    }

So we could use regionMatches() that supports case insensitivity:
public boolean regionMatches(boolean ignoreCase, int toffset, String other, int ooffset, int len)

But this doesn't support Locale that it should be always what you defined in the database (everywhere), or if not defined, the default that is the system Locale. Behind Locale there are a lot of edge cases. Look at This and The "turkish case".

Hi guys,
The only problem is performance, equalsIgnoreCase is very slow.
So if we keep  case-insensitive behavior, I think we should normalize names
of classes, clusters and so on before they will go inside of database
engine.
The problem now that we do not know whether all those names normalized or
not and as a result we have tons of toUppperCase toLowCase, equalsIgnorCase
over the system.
We should be sure that if I take clasName inside of storage it always in
lower case for example.
Also, I support Luca because the implementation of the case sensitive
approach will be a disaster for our existing users.
On Thu, Jul 7, 2016 at 4:55 PM Luca Garulli<EMAIL_ADDRESS>wrote:

Agreed (so like now)

About (2), this is the implementation of Java String:
public boolean equalsIgnoreCase(String anotherString) {
    return (this == anotherString) ? true
            : (anotherString != null)
            && (anotherString.value.length == value.length)
            && regionMatches(true, 0, anotherString, 0, value.length);
}

So we could use regionMatches() that supports case insensitivity:
public boolean regionMatches(boolean ignoreCase, int toffset, String other, int ooffset, int len)
But this doesn't support Locale that it should be always what you defined
in the database (everywhere), or if not defined, the default that is the
system Locale. Behind Locale there are a lot of edge cases. Look at This
http://blog.eyallupu.com/2010/08/four-things-to-remember-about.html and The
"turkish case"
http://mattryall.net/blog/2009/02/the-infamous-turkish-locale-bug.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/orientechnologies/orientdb/issues/6052#issuecomment-231084474,
or mute the thread
https://github.com/notifications/unsubscribe/AAGaahyK4L4VQv5jI4bV19ZeuyXSEj35ks5qTQU3gaJpZM4IQtZB
.

--
Best regards,
Andrey Lomakin, R&D lead.
OrientDB Ltd
twitter: @Andrey_Lomakin
linkedin: https://ua.linkedin.com/in/andreylomakin
blogger: http://andreylomakin.blogspot.com/

@laa, exactly!
My proposal was to store low case class names in some new structure (this means new database format though), but progressively.
That means, that every create class or alter class touching name or superClass name should have store low case name in addition to its original version. Original case version could be used in all query results, though, as it is now.
When read - we should check, if there is such a "lower case" data in the class (means database was imported, or this class was altered/created with recent API version), then we could use this value for quick comparison (still have to make provided query value lowercased, of course).
By version 3.0 we could switch database version completely, making sure, that DB was re-imported and classes|clusters all have the needed (system) lowcase field.
@luigidellaquila about the speed, I'm still wander about next case:
let's suppose our file system is case insensitive (it is easy - try to make folder "name" and folder "Name" in the same place in Windows) - then we will have to store clusters and classes in some special way to distinguish them. Lets say name.cpm and Name_.cpm respectively. Then you either will need to store that mapping somewhere (and lookup for it every time), or resolve that problem with some other quite complicated (if not expensive) method.

well i think we could separe a bit the sections, i know that have only one behaviour would be better, but not sure if is doable.
The most important case for performance and consistency overall is the "properties" also called "field names"
As today we have this beaviour:
Schema properties are case insensitive
document fields are case sensitive
sql fields are case sensitive
to unform the not consistent current behaviour we have two way, make everything case sensitive or case insesitive.
case insensitive:
Advantages:

maybe more user friendly in case of misstyping ecc.
Disadvantges:
incompatibility for old schemaless case sensitive
slow down of filed access in odocument
impossible to implement binary query
issue on locale corner cases

case sensitive:
Advantages:

locale independecy
ability to do binary query ecc
compatible with current ODocument api
Disadvantges:
maybe less user friendly
incompatibility with current schema properties api

for the properties/fields it seems more convinient to do case sensitive.
the other cases as far as i got does not make much difference for case sensistive and insensitive, you have equal (opinion based)vantages on usability on case insensitive, no huge performance differences, and some small issues based on the locale.
so from what i listed here and from my point of view is better have case sensitive properties, and maybe does really matter the rest.
It may only have meaning keep just one way to work to be more user friendly.
my 2 cents bye

hi @a-unite,
I understand your point, you said the engine should work lower case (or case sensitive) and should show the result to the user as the case was configured with.
well i'm not sure we want to keep both version of the field name in the database, and the mapping later on may be expensive, due to all "SchemaLess" cases.

Hi guys,
If it is related only to fields and because most of the areas use case
sensitive fields IMHO better to make them case sensitive.
On Thu, Jul 7, 2016 at 5:56 PM tglman<EMAIL_ADDRESS>wrote:

hi @a-unite https://github.com/a-unite,
I understand your point, you said the engine should work lower case (or
case sensitive) and should show the result to the user as the case was
configured with.
well i'm not sure we want to keep both version of the field name in the
database, and the mapping later on may be expensive, due to all
"SchemaLess" cases.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/orientechnologies/orientdb/issues/6052#issuecomment-231103232,
or mute the thread
https://github.com/notifications/unsubscribe/AAGaak9KpHV1f9SvbcVAFau6JBUedIf5ks5qTROkgaJpZM4IQtZB
.

--
Best regards,
Andrey Lomakin, R&D lead.
OrientDB Ltd
twitter: @Andrey_Lomakin
linkedin: https://ua.linkedin.com/in/andreylomakin
blogger: http://andreylomakin.blogspot.com/

@tglman, thanks. You are right - I'd prefer to have lower case case for fields too (I see too often issues, which are related to mistyping or misunderstanding of case sensitivity for field names here).
But as I understand, we are discussing now class\cluster names only and I agree, that for field names we have to count on back compatibility anyway.

Changing this means that all the current users could have to rewrite most of their queries if they want to upgrade to v3.0 and in some application this could be really expensive.

This is assuming that all of the current users change the case of their class name identifiers, when they write their queries. Why would they do that? I can't say it is completely false, but I can say, it probably isn't completely true that they ALL do that. So, I'd say going to case sensitivity for classes won't mean all the users have to rewrite all of their queries. It will be more like some of the users will have to correct their misspellings on some of their queries. That doesn't sound as painful as you put it. :wink:
This might get a grumble from you guys, but couldn't we do it like MySQL and have a global setting for what is wanted by the user? That way, all bases are covered.
From the Mysql docs:
Value	Meaning
0	Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement. Name comparisons are case sensitive. You should not set this variable to 0 if you are running MySQL on a system that has case-insensitive file names (such as Windows or OS X). If you force this variable to 0 with --lower-case-table-names=0 on a case-insensitive file system and access MyISAM tablenames using different lettercases, index corruption may result.
1	Table names are stored in lowercase on disk and name comparisons are not case sensitive. MySQL converts all table names to lowercase on storage and lookup. This behavior also applies to database names and table aliases.
2	Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement, but MySQL converts them to lowercase on lookup. Name comparisons are not case sensitive. This works only on file systems that are not case sensitive! InnoDB table names are stored in lowercase, as for lower_case_table_names=1.
Scott

I was going through the top most reacted posts for ODB and this was one of them and I'd like to pull back my suggestion above. Don't do it the MySQL way, as it only adds way too much complexity.
I am still for case sensitivity and I feel backwards compatibility won't or rather shouldn't be a concern. We are now talking 3.0, which is supposed to be breaking old ways to do them better. I feel going full case sensitive is a move forward, as can be seen by the majority of sentiment shown in this thread.
I'll throw in one other reason, case sensitivity is necessary to be able to support full NoSQL. As someone else mentioned, JSON is case sensitive. I really feel ODB needs to break with the RDBMS world as much as possible.  It holds ODB back from doing smarter things, if you ask me. ODB needs to be a leader in the NoSQL fold, but doing relationships much better the rest of them. That is the real trick to winning hearts. 😄
Scott


Add Swell Network (Mainnet)

Adding a New Chain
This PR adds [Swell Network] to the registry.
Checklist

[x] I have declared the chain at the appropriate Superchain Level.
[x] I have run just validate <chain-id> locally to ensure all local validation checks pass.
[x] I have run just codegen to ensure that the chainlist and other generated files are up-to-date and include my chain.

Closing in favour #760


Make ibuffer-visit-buffer workspace-aware

Fixes #5061
check if the buffer that is being visited belongs to any
existing workspace and then switch to the workspace before opening the
buffer
** 2 review items marked in code comments
Please review and suggest the best ideas and I will address and/or delete comments accordingly.
** Performance
I tried it locally and it worked, but I usually run <6 workspace with 10 buffers each. I am not show what kind of performance
degradation we should expect for power-users with 10 workspace with 100 buffers in each.
** On even if ibuffer is commented out in init.el
After testing locally, I realised that this patch works even when ibuffer customisations aren't activated as they aren't in my config
https://github.com/petr-tik/dot-doom-emacs/blob/master/init.el#L69
I understand I could move my patch from modules/ui/workspaces/config.el to the sexp here
https://github.com/hlissner/doom-emacs/blob/5b3f52f5fb98cc3af653b043d809254cebe04e6a/modules/emacs/ibuffer/config.el#L42
When I turned ibuffer on in my config, I experienced an unpleasant slowdown in ibuffer generation (i guess it's projectile running slowly on my tramp projects), so i would personally prefer to leave it where it is, but am happy to take guidance and move under ibuffer/config.el

thanks for the review. Appreciate you must have been busy, i will try to address it this week and ping you again

boop

are you booping me or Henrik?

Oh I just wanted to make sure that the PR first get closed cause it got marked as stale. It's still relevant, Henrik has just been a bit busy

Sorry for taking so long to get to this. After some deliberation, I've added this functionality in c309e61, with four differences to what's proposed here:

If a buffer is present in more than one workspace, prompt the user to select which workspace they want to end up in.
If the buffer is present in no workspaces, add it to the current one.
Isolate the functionality to the ibuffer module. I'm working on generalizing this functionality in the workspaces module.
I've named the function +ibuffer/visit-workspace-buffer to match +vertico/switch-workspace-buffer, which does similar. I'm not 100% on this naming, but that's a yak I'll shave later (as part of a bigger effort to rename a bunch of poorly named functions/variables in Doom's code base).

In any case, this should resolve this and #5061. Let me know if I've missed anything!


Inconsistent Count query being generated

GORM Playground Link
https://github.com/go-gorm/playground/pull/344
Description
Count() generates a different query depending on whether the session as been cloned using the Session() method. I would expect it to produce the same query irrespective of the call to Session().
For context, we use the pattern in the playground example to return pagination info along with results on a GraphQL API. We generate the query, call Count to get the total possible record count, then add offset/limit and call a Find() to get the desired page.
Without the Session() call to clone the db instance, the finisher aspect of Count causes the Find to run a SELECT * ... which causes issues when the query has joins. With the Session call to create a clone just for the Count the Find then correctly adds the specific list of columns for the desired model, i.e. SELECT model.column1, model.column2, ...
I've tracked down the issue:
When Session is called DB.clone is set to 2. However on the original instance, DB.clone is 0. That causes an inconsistent behaviour at this line: https://github.com/go-gorm/gorm/blob/master/finisher_api.go#L413
delete(db.Statement.Clauses, "ORDER BY")

I believe this should be delete(tx.Statement.Clauses, "ORDER BY") (i.e. tx rather than db) to be consistent with how SELECT clauses are handled.
The demonstrated behaviour occurs because the call to db.getInstance at the first line of the function (https://github.com/go-gorm/gorm/blob/master/finisher_api.go#L369) will return db in the case DB.clone is 0, in which case db and tx are literally the same object in memory and this code to handler ORDER BY works as expected. However in the case DB.clone is 2 due to the Session call, tx is a copy of db so calling delete on the db instance doesn't remove the ORDER BY clause from the executed query.

Running into this same issue


Python Source

Since Python installers are a little tough to understand, I think having attendees download Python via a data science package such as Anaconda is a good idea. Its installers are pretty straight forward, but it will take a long time to download and setup. Are you guys aware of Miniconda? It's just Python and conda.

Is the full anaconda distribution required because we rely on matplotlib and pandas ? If not, I'd accept a PR updating the README. Needs to be updated with R install anyways.


pi_examples: Building label_image shows missing graph.pb.h then graph.pb.h version error

When building the label_image example in pi_examples:
./tensorflow/core/framework/graph.pb.h:12:2: error: #error This file was generated by a newer version of protoc which is
./tensorflow/core/framework/graph.pb.h:13:2: error: #error incompatible with your Protocol Buffer headers. Please update
What related GitHub issues or StackOverflow threads have you found by searching the web for your problem?
None, the mentions of graph.pb.h were all for that file simply being missing.
In my case, moving graph.pb.h to the location the compiler expects resulted in the version error message, above.
Also, the issue reports seemed to be pre- TF v.1.0.0, and likely not relevant.
Environment info
Operating System:
Raspbian Jessie, version "Jan 2017", release date "2017-01-11"
https://www.raspberrypi.org/downloads/raspbian/
Installed version of CUDA and cuDNN:
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
N/A
If installed from binary pip package, provide:
N/A

A link to the pip package you installed:
The output from python -c "import tensorflow; print(tensorflow.__version__)".

If installed from source, provide

The commit hash (git rev-parse HEAD)
321d38ee0ff76d749a8578f37128b02bf033ce76

The output of bazel version
Build label: 0.4.3- (@non-git)
Build target: bazel-out/local-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Feb 24 03:14:34 2017<PHONE_NUMBER>)
Build timestamp:<PHONE_NUMBER>
Build timestamp as int:<PHONE_NUMBER>

If possible, provide a minimal reproducible example (We usually don't have time to read hundreds of lines of your code)
Build tensorflow from source, exactly as at:
https://github.com/samjabrahams/tensorflow-on-raspberry-pi/blob/master/GUIDE.md
Attempt tp build label_image example, exactly as at:
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/pi_examples/
Corrected error caused by missing graph.pb.h by copying graph.pb.h from:
/home/pi/tensorflow/bazel-tensorflow/tensorflow/core/framework/graph.pb.h
to
/home/pi/tensorflow/tensorflow/core/framework/node_def.pb.h
and ran the label_image make again. Error shown below.
What other attempted solutions have you tried?
None, not very familiar w/Bazel and TF building yet... after all, the pi_examples are for newbies to get started with and learn TF, right?
Logs or other output that would be helpful
(If logs are large, please upload as attachment or provide link).
pi@raspberrypi:~/tensorflow $ make -f tensorflow/contrib/pi_examples/label_image/Makefile
gcc --std=c++11 -O0 -I/usr/local/include -I. -I/home/pi/tensorflow/tensorflow/contrib/pi_examples/label_image/../../makefile/downloads -I/home/pi/tensorflow/tensorflow/contrib/pi_examples/label_image/../../makefile/downloads/eigen/ -I/home/pi/tensorflow/tensorflow/contrib/pi_examples/label_image/../../makefile/gen/proto/ -I/home/pi/tensorflow/tensorflow/contrib/pi_examples/label_image/../../makefile/gen/proto_text/ -c tensorflow/contrib/pi_examples/label_image/label_image.cc -o /home/pi/tensorflow/tensorflow/contrib/pi_examples/label_image/gen/obj/tensorflow/contrib/pi_examples/label_image/label_image.o
In file included from tensorflow/contrib/pi_examples/label_image/label_image.cc:32:0:
./tensorflow/core/framework/graph.pb.h:12:2: error: #error This file was generated by a newer version of protoc which is
#error This file was generated by a newer version of protoc which is
^
./tensorflow/core/framework/graph.pb.h:13:2: error: #error incompatible with your Protocol Buffer headers. Please update
#error incompatible with your Protocol Buffer headers.  Please update
^
./tensorflow/core/framework/graph.pb.h:14:2: error: #error your headers.
#error your headers.
^
In file included from tensorflow/contrib/pi_examples/label_image/label_image.cc:32:0:
./tensorflow/core/framework/graph.pb.h:31:51: fatal error: tensorflow/core/framework/node_def.pb.h: No such file or directory
#include "tensorflow/core/framework/node_def.pb.h"
^
compilation terminated.
tensorflow/contrib/pi_examples/label_image/Makefile:79: recipe for target '/home/pi/tensorflow/tensorflow/contrib/pi_examples/label_image/gen/obj/tensorflow/contrib/pi_examples/label_image/label_image.o' failed
make: *** [/home/pi/tensorflow/tensorflow/contrib/pi_examples/label_image/gen/obj/tensorflow/contrib/pi_examples/label_image/label_image.o] Error 1

Note: The original problem is that these files were reported by the compiler as missing from
./tensorflow/core/framework
graph.pb.h
node_def.pb.h
attr_value.pb.h
tensor.pb.h
resource_handle.pb.h
tensor_shape.pb.h
types.pb.h
function.pb.h
op_def.pb.h
versions.pb.h
I read that these files are generated (and then placed in tensorflow/core/framework, i assume), but apparently that didn't happen while building TF.
Rebuilding TF showed that all files were current.
Running configure (to clean) and make will take over 10 hours (and recovering from numerous Pi "hangs"!), so I haven't done that again yet.
However, I did get a good build of the TF 1.0.0 Python .whl file, it installed OK, and reports version OK in Python. So, the TF (and Bazel?) build appears to be partially successful.

@avantol Have you tried following the instructions here to build TF on your pi:
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/pi_examples
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/makefile#raspberry-pi
Note that *.pb.h files are generated by the protocol buffer compiler.  That's where to start looking wrt problems with your install.

@tatatodd: THANKS!!! Using make (instead of Bazel) to build tensorflow:
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/makefile#raspberry-pi
worked....  and label_image builds correctly now.
I also had to update protobuf to 3.2.0, others should take note.
My conclusion is that Bazel on Raspberry Pi is a huge waste of time, it just doesn't work, likely a problem with defining the build for Raspberry Pi. Also, it crashed Pi frequently (yes, I used the memory tips).
"make" is 8 hours faster and works correctly.
Also, others should note that the statement
"The recommended way to build TensorFlow from source is using the Bazel open-source build system" at:
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/makefile#raspberry-pi
does NOT necessarily apply to Raspberry Pi!
This advice took me down completely the wrong road for a week. Beware!


CRASHLYTICS - Undefined symbol: OBJC_CLASS$_JSContext

Description
it happens when using other linker flags -Objc
Reproducing the issue
it happens when using other linker flags -Objc
Firebase SDK Version
10.28
Xcode Version
15.3
Installation Method
Swift Package Manager
Firebase Product(s)
Crashlytics
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

ld: warning: Could not find or use auto-linked framework 'CoreAudioTypes': framework 'CoreAudioTypes' not found
Undefined symbols for architecture arm64:
"OBJC_CLASS$_JSContext", referenced from:
in GoogleMobileAds[arm64]448
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Could not find or use auto-linked framework 'CoreAudioTypes': framework 'CoreAudioTypes' not found
Undefined symbol: OBJC_CLASS$_JSContext
Linker command failed with exit code 1 (use -v to see invocation)

The missing symbol comes from the GoogleMobileAds SDK rather than a Firebase SDK.

"OBJC_CLASS$_JSContext", referenced from:
in GoogleMobileAds[arm64]448

The JSContext symbol is defined in Apple's JavaScriptCore framework: https://developer.apple.com/documentation/javascriptcore/jscontext?language=objc
I would recommend trying to link the JavaScriptCore by going to your target's build settings > Frameworks, Libraries, and Embedded Content > + > search for JavaScriptCore` > select and add.

For more help with Google Mobile Ads, please file an issue over at https://github.com/googleads/swift-package-manager-google-mobile-ads


Snippet to be applied to multiple scopes - Ex. Sass and CSS

Awesome extension!
It would be dandy if a snippet name could support more than one scope (file type)
Ex: "red" - I would like it to generate a red border (border:1px solid red;) that I use in HTML, CSS and LESS/SASS for debugging.
It's entirely possible that I'm missing something, but for some reason, it does not allow me to use the same keyword and assign it multiple "scopes".

YES PLEASE! Or at the very least make it so snippets in CSS also work automatically in LESS and SASS. It is crazy not to have that.

As workarround you could just create an equal snippet for every scope you want it.

Obviously that is what we want to avoid doing.

well the only alternative I see so far would be to set the scope to "--any--" so at least you don't have to configure them multiple times


Remove identical if statement branches in keyDown handler

This is a minor tweak.  These two code paths are identical, there's
no need for the if statement here.

CC @dperpeet


FABCAG-27 Update chaincode-integration tool to use fabric 2.1 images

in order for fabric-contract-api-go to pick this up and use in integration tests

Signed-off-by: heatherlp<EMAIL_ADDRESS>

Thanks Andy, I've pushed the updates and I did a run locally in contract-api-go to check it still works. It looks like I don't need to up the sleep, so I removed those updates.

@btl5037 Could you please merge this when you get chance?

@btl5037 Could you please merge this when you get chance?

Done


fixes #365 user edition

Fixes the previous fix, which would kill the json editor.

Codecov Report

Merging #376 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #376   +/-   ##
=======================================
  Coverage   85.89%   85.89%
=======================================
  Files          38       38
  Lines         723      723
=======================================
  Hits          621      621
  Misses        102      102

Continue to review full report at Codecov.

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


Re-include variable definitions and prepare for last round

Changes to variabledefs are in the second commit:
https://github.com/IAMconsortium/concordia/pull/59/commits/ab9b424223f2468f742e67304ad556adf3edb922

Thanks @coroa - I went through the csv and added all comments directly there


[BUG] Archive images not loading

Describe the bug
When I click to read a chapter in the extension no images are loaded
To Reproduce
Steps to reproduce the behavior:

Go to Series
Click on Chapter 1
See no images loaded

Expected behavior
Images are loaded
Screenshots

The XML of from https://kavita.[REDACTED]/api/opds/[REDACTED]series/4451/volume/13241/chapter/131229

Additional logs
18-02.Paperback.txt
I've redacted the sensitive information

It looks to be using the wrong series ID, and the chapter ID for the volume ID in the OPDS url call:
https://kavita.[REDACTED]/api/opds/[REDACTED]/series/4/volume/131229/chapter/131229
When it should be:
https://kavita.[REDACTED]/api/opds/[REDACTED]/series/4451/volume/13241/chapter/131229

This bug happens by I guess this bug is caused by a mismatch between volumeId and chapterId.
Currently, this plugin assumes volumeId and chapterId are the same.
We are planning to remove the implementation using opds soon and implement it again using kavita api.
Thanks for reporting the bug.

Newer version of Kavya with Kavita API is just released. Hopefully it fixes this issue.
I'll close this issue now. If you still have issues, please file an issue again.
By the way, there seems to be a paperback issue with the extension version not displaying properly.
You might need re-install paperback.


Add mutator functions to allow modify the Kubernetes resources used b…

…y volume population

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test

/kind feature

/kind flake

What this PR does / why we need it:
In some cases we might want to customize the default Kubernetes objects in volume populator, so add plugin functions to allow modification for the objects.

Add MutatorConfig to Volume Populator Controller to allow specify mutator functions to modify the Kubernetes resources used by volume populator
Add the PvcPrimeMutator to allow modify PVC prime before object creation

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Add MutatorConfig to Volume Populator Controller to allow specify mutator functions to modify the Kubernetes resources used for volume population. Add the PvcPrimeMutator function to allow modify PVC prime before object creation

/assign @msau42

/assign @pwschuurman

/lgtm

/approve


Shared Secret Generation

You need examples (or a link to another docs article) of how to generate shared secrets correctly in Windows Server (and possibly Linux), both On-Prem and in the cloud.  Database Admins do not have the requisite experience to assume that they can create a C# program or call a method to do this unless you were to give a T-SQL function or PowerShell cmdlet example.

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

ID: 0d903c17-112d-c463-0af8-e1b6799df66f
Version Independent ID: 008ccdde-b62c-92a1-98fd-377ad97a769d
Content: Create Identical Symmetric Keys on Two Servers - SQL Server
Content Source: docs/relational-databases/security/encryption/create-identical-symmetric-keys-on-two-servers.md
Product: sql
Technology: security
GitHub Login: @jaszymas
Microsoft Alias: jaszymas

@PrometheusRising1 -- thank you for your feedback.
@jaszymas -- please look into this issue.

Hi, any additional info on this one?  I am building a restore script out right now and need the information on KEY_SOURCE and IDENTITY_VALUE  to ensure that i am creating something according to general best practices.  Is it best to generate these from a .NET library and stored them out-of-band?  Use a random string of letters and numbers (e.g. can I use special characters?  It doesn't say), or a phrase that my team would remember, or should I avoid dictionary words and phrases altogether?

Hello @PrometheusRising1! Sorry for the delay! I hope you were able to find what you were looking for, but if not, the CREATE SYMMETRIC KEY syntax is documented here: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-symmetric-key-transact-sql
You should be able to find what you need for KEY_SOURCE and IDENTITY_VALUE. I hope that helps! I'll go ahead and close this issue, but please feel free to @ me if you have any questions on this.


ClickAwayListner close on its child element click

Bug-ClickAwayListner close on its child element click
On npm update new packages

Your issue has been closed because it does not conform to our issue requirements.
For how-to questions and other non-issues, please use Spectrum.chat or StackOverflow instead of Github issues. There is a StackOverflow tag called "material-ui" that you can use to tag your questions.


PrecisionAlignment: bug fix

This issue was discovered through a report upstream in issue squizlabs/PHP_CodeSniffer#2179#issuecomment-437634372.
What it comes down to is that if the ignoreAlignmentTokens property would be set, the merge_custom_array() call in the process_token() would override it with a flipped array with values false and for the next file, would override it again, flipping the array again etc etc.
This in effect made the custom property only work for the first file, not for subsequent files.
This has now been fixed.
Includes unit tests to guard against the issue.
Additionally, I've improved the inline comments to clarify what's being tested in test case file 2.

FYI: I've done a quick code review of all other uses of the merge_custom_array() method and I don't believe any other sniffs are susceptible to this issue as they currently are.

I've tested this PR with the repo I created to reproduce the issue and can confirm the proposed change does fix the problem.
A note to others that end up in this thread directly: The issue being fixed in this PR only seems to exist on macOS. Linux and Windows seem to be fine.

@DaveLak Thank you for testing and confirming the validity of this fix.

A note to others that end up in this thread directly: The issue being fixed in this PR only seems to exist on macOS. Linux and Windows seem to be fine.

FYI: With the unit test cases I've added in this PR, I did manage to reproduce the issue on Windows as well, so I'm honestly not sure what was causing the issue not to show up with the original POC.


VSCode extension: Intellisense is not recognizing required parameters for Microsoft.ContainerService/managedClusters@2021-05-01

Bicep version
Bicep CLI version 0.4.451 (e14a1f9511)
Describe the bug
I expect the VSCode Intellisense to tell me what are the required parameters for the resource during creation, however this is not the case.
Notice how the Intellisense is not detecting that I am missing a required parameter servicePrincipalProfile and agentPoolProfiles

This is confirmed when I attempt to deploy the resource, see error message below:
{"error":{"code":"InvalidTemplateDeployment","message":"The template deployment 'cluster' is not valid according to the validation procedure. The tracking id is 'a40642cf-6485-4083-8586-6ae4dc3ba0df'. See inner errors for details.","details":[{"code":"InvalidParameter","message":"Provisioning of resource(s) for container service sometestname in resource group asilverm-bicep failed. Message: {\n  \"code\": \"InvalidParameter\",\n  \"message\": \"Required parameter servicePrincipalProfile is missing (null).\",\n  \"target\": \"servicePrincipalProfile\"\n }. Details: "}]}}

To Reproduce
Steps to reproduce the behavior:

Create a valid bicep file containing the resource below

resource cluster 'Microsoft.ContainerService/managedClusters@2021-05-01' = {
  name: 'sometestname'
  location: resourceGroup().location
}

Attempt to deploy the file using the az command
 az deployment group create -f ./test.bicep -g somegroup
Additional context
Add any other context about the problem here.
Notice how the documentation  says that this value is not required but it is

If you do end-up specifying the servicePrincipalProfile, then you encounter an error with agentPoolProfiles

Unfortunately, this is a bit out of our control as both the bicep types and the docs are generated from this resource types API spec, which as you've pointed out is not accurate. I will send this issue to them to see if they can get it updated.


restore manifest in-memory cache

motivation: better performance for operations that load manifest often
changes:

add in-memory cache in ManifesLoader
only cache JSON parser results and add package location to the cache key to address potential issues such as rdar://73462555 which made us remove such cache in the past
add test

rdar://73521470

@swift-ci smoke test

@swift-ci test

[1602/1602] Testing CommandsTests.TestToolTests/testSwiftTestSkip
Test Suite 'Selected tests' started at 2023-09-29 05:57:49.681Test Suite 'SwiftPMPackageTests.xctest' started at 2023-09-29 05:57:49.683Test Suite 'PackageDescription4_2LoadingTests' started at 2023-09-29 05:57:49.683Test Case '-[PackageLoadingTests.PackageDescription4_2LoadingTests testCaching]' started./Users/ec2-user/jenkins/workspace/swift-package-manager-with-xcode-self-hosted-PR-osx/branch-main/swiftpm/Tests/PackageLoadingTests/PD_4_2_LoadingTests.swift:682: error: -[PackageLoadingTests.PackageDescription4_2LoadingTests testCaching] : XCTAssertEqual failed: threw error "timeout waiting for parsing"Test Case '-[PackageLoadingTests.PackageDescription4_2LoadingTests testCaching]' failed (8.120 seconds).Test Suite 'PackageDescription4_2LoadingTests' failed at 2023-09-29 05:57:57.803.
	 Executed 1 test, with 1 failure (1 unexpected) in 8.120 (8.120) secondsTest Suite 'SwiftPMPackageTests.xctest' failed at 2023-09-29 05:57:57.803.
	 Execut

Probably related to the changes?

@swift-ci test

for reference, brings back https://github.com/apple/swift-package-manager/commit/48e477aec0a3856a6b7dfdc9c1c30117b0d91259

@swift-ci test windows