[Feature Request] Plugin API, Phase V: The __beartype_isinstance__() protocol: Class-specific type-checking violation messages

This feature request comes courtesy @patrick-kidger (AKA, the Big Brain) at issue #216 – now split into smaller issues for easier digestion. :yum:
Exception messages currently generated by @beartype + jaxtyping are appallingly unreadable:
beartype.roar.BeartypeCallHintParamViolation: @beartyped __main__.f() parameter
x="Array(1, dtype=int32, weak_type=True)" violates type hint <class
'jaxtyping.Float[Array, 'dim1']'>, as <protocol "jaxlib.xla_extension.ArrayImpl">
"Array(1, dtype=int32, weak_type=True)" not instance of <class
"jaxtyping.Float[Array, 'dim1']">.

:vomiting_face:
I would punch the nearest pliable object repeatedly if I ever got an exception message like that. This is actually a desperate plea for a new variant of a @beartype plugin API in disguise. See also feature requests #191, #192, and #193. Of course, none of those do what you need. But they do demonstrate that a sprawling and poorly documented plugin system is a thing we should promise to do sometime.
I see two alternate APIs here:

We run with the proposed def __beartype_isinstance__(self, obj: object) -> tuple[bool, None | str]: ... protocol. This works, but has a bit of a drawback: you're probably violating DRY by duplicating validation logic between this new __beartype_isinstance__() and the existing __instancecheck__() in the metaclass. Maybe? Though, I suppose that one could always just internally defer to the other or just drop __instancecheck__() entirely (in which case jaxtyping would strictly require users to use @beartype everywhere, which is just great from my biased perspective but not so great from everybody else's more honest perspective). Still, it seems a little excessive. I wonder if instead...
We pare that down to an alternate def __beartype_violation_message__(self, obj: object) -> None | str: ... protocol, which returns either:

If the passed object obj satisfies the current type hint self, None.
Else, a human-readable substring detailing exactly how obj violates self.

In the latter case, you'd still define an __instancecheck__() in the metaclass; @beartype would then still defer to a standard isinstance(obj, hint) check like it currently does. If that check returns False, @beartype would then call your hint-specific __beartype_violation_message__() dunder method (if defined) to embed a hint-specific description in its violation message.
Since @beartype will embed that substring in its own larger exception message, there will probably need to be a few ground rules governing how exactly that message is formatted (e.g., as a lowercase sentence fragment with no prefixing or trailing punctuation). Blagh! Let's not even begin to consider l18n and i18n concerns here, because my feeble brain is already imploding.
:expressionless: :exploding_head: :boom:

@agronholm -- I've heard rumours (https://github.com/google/jaxtyping/issues/6) that typeguard is planning on adding support for a feature something like this as well.
Would it be possible for us all to standardise on a single API here?

:grimacing:
I'm so sorry, @patrick-kidger. I wasn't able to nail this to the floor for beartype 0.14.0, which now needs to be shipped yesterday due to resolving a critical blocker for our sad-faced PyPy userbase. On a scale of "I don't even care, bro!" to "I will burn this issue tracker if this never happens!", how critical would you say this feature request is for jaxtyping?
I'm assuming super-critical, because that exception message is trash. Still... is this something you can live without for a bit? I'd kinda like to go hard on import hooks for beartype 0.15.0 instead. I leave this decision in your ingenious hands that are hopefully less arthritic than mine.

Haha, it's totally fine -- not critical at all. Best of luck fixing those arthritic hands...

Aww! You're so noice – as always. Thanks so much for your extreme patience here and elsewhere with our swollen issue tracker that spawns ever more bugs. As the spring churns dutifully into summer, we reflect on the nature of exponential growth in insect populations on- and offline.
Now... I just gotta massage these bulging knuckles until the blood flow returns. Shouldn't that happen automatically, though!? :sweat:

Hey @leycec - just wanted to check in on this. Would be nice to get those friendlier error messages

Yes! They're still awful, are they? </sigh>
I'm hip-deep in import hooks, which are such massive hype that everyone will be ecstatic that I did those instead of this. Following that, I'm afraid that deep type-checking of dict and set collections is up next. @langfield must be appeased. He's also right; it's been nearly a year since he first justifiably complained about @beartype not type-checking dict and set items.
Relatedly, @beartype is just this fun hobby thing I do in my scarce free time in a purely volunteer manner mostly without any funding whatsoever. It is all for the :heart: here. Official funding would supercharge this development process, but financial utopia is hard to see from here. Until then, I happily flail my fat limbs like an open-source turtle flipped onto its back.
Sadly, that means __beartype_isinstance__() is currently on the back-burner until the Autumn. I'm still absolutely committed to this, because existing exception messages are trash for common third-party use cases like jaxtyping. But... I lack temporal bandwidth for this. Someone skilled in unethical bioengineering, clone me five hundred times! Let the Bear Clone Wars begin. :bear: :bear: :bear: :bear:

Hah-ah! I've been sloooowly speccing this API out with @tvdboom over at discussion #277. I'm now glad I hesitated to do anything. :grin:
The resulting API is surprisingly non-trivial. Why? Recursion and subscription. For example, consider this typing.Protocol subclass defined by @tvdboom over at #277:
from beartype.typing import Protocol, TypeVar

T = TypeVar('T')
class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

SequenceProtocol needs to be able to generate human-readable violation messages in all possible use cases – including when:

Unsubscripted (e.g., as the vanilla SequenceProtocol class).
Subscripted by a non-nested child type hint (e.g., as SequenceProtocol[int]).
Subscripted by a nested instance of itself (e.g., as SequenceProtocol[SequenceProtocol[str]]).

Here's where our existing object-oriented beartype.door.TypeHint API comes in. @beartype's TypeHint is already almost smart enough to support the above use cases. We just need a bit of extra special sauce. What follows is mostly myself talking to myself, because I will forget this in five minutes after mucking about in the garden with smelly cats:

Define a new private beartype.door._doorerror submodule.
Publicize our currently private beartype._decor.error._errorcause.ViolationCause dataclass as a public beartype.door.TypeHintCause dataclass privately implemented at beartype.door._doorerror.TypeHintCause.

beartype.door.TypeHintCause is a new public dataclass enabling third-party frameworks to control the generation of framework-specific violation messages. In the case of @tvdboom's SequenceProtocol, the final implementation from the end user perspective would resemble:
from beartype.door import TypeHint, TypeHintCause
from beartype.typing import Protocol, TypeVar

T = TypeVar('T')
class SequenceProtocol(Protocol[T]):
    def __iter__(self) -> Iterable[T]: ...
    def __getitem__(self, item) -> T: ...
    def __len__(self) -> int: ...

    # FUN STUFF FOLLOWS. START READING HERE, HOPEFULLY FELLOW HUMAN.
    def __beartype_cause__(cls, cause: TypeHintCause) -> TypeHintCause:
        '''
        Output cause describing whether the object currently being type-checked
        by the passed input cause either satisfies or violates this protocol.

        Parameters
        ----------
        cause : ViolationCause
            Input cause describing the object currently being type-checked.

        Returns
        ----------
        ViolationCause
            Output cause refining this description.
        '''

        # If the object currently being type-checked is *NOT* a sequence,
        # define an appropriate error message and immediately return.
        if not isinstance(cause.obj, cls):
            cause.message = 'not a sequence'
        # Else, this object is a sequence.
        #
        # If this sequence is non-empty...
        elif cause.obj:
            # First child hint of this hint. All remaining child hints if any
            # are ignorable. Specifically, if this hint is:
            # * A standard sequence (e.g., "typing.List[str]"), this hint is
            #   subscripted by only one child hint.
            # * A variadic tuple (e.g., "typing.Tuple[str, ...]"), this hint is
            #   subscripted by only two child hints the latter of which is
            #   ignorable syntactic chuff.
            item_hint: TypeHint = cause.hint[0]

            # If this child hint is *NOT* ignorable...
            if not item_hint.is_hint_ignorable:
                # For each enumerated item of this sequence...
                for item_index, item in enumerate(cause.obj):
                    # Deep output cause, type-checking whether this item
                    # satisfies this child hint.
                    item_cause = cause.permute(
                        obj=item, hint=item_hint).refine()

                    # If this item is the cause of this failure...
                    if item_cause.message is not None:
                        # Human-readable substring prefixing this failure with
                        # metadata describing this item.
                        item_cause.message = (
                            f'{color_type(label_object_type(cause.obj))} '
                            f'index {item_index} item {item_cause.message}'
                        )

                        # Return this cause.
                        return item_cause
                    # Else, this item is *NOT* the cause of this failure.
                    # Silently continue to the next item.
            # Else, this child hint is ignorable.
        # Else, this sequence is empty, in which case all items of this sequence
        # (of which there are none) are valid. Just go with it, people.

        # Return this cause as is; all items of this sequence are valid,
        # implying this sequence deeply satisfies this hint.
        return cause

__beartype_cause__() looks hairy, but that's just because I'm verbose (read: I like the sound of my own voice). In actuality, that's a worst-case __beartype_cause__() implementation – and it's still only ~20 lines of code or so to recursively generate human-readable violation messages for arbitrarily complex and possibly nested sequences.
Moreover, that __beartype_cause__() implementation is copied almost verbatim from our existing beartype._decor.error._pep._pep484585._errorsequence._find_cause_sequence() function. All we're really doing here is publicizing private stuff that already exists and has been known to work for years in the intestinal walls of the @beartype codebase.

This would be awesome! Can't wait for the implementation.
But how would this look like for somethign way simpler, where we don't need a custom protocol class? for example
Annotated[int, Is[lambda v: v>0]]

I want this to error with something like: Value should be larger than zero, got X.

<leycec's post>

Hang on, this API looks odd to me.

Why is the cause passing information about the hint? That's not needed at all, the hint already knows who it is via the cls parameter.
The mutation in cause.message = ... doesn't seem necessary.
This seems to require learning a whole new system for the end user. I think that's a non-starter from a usability perspective.

I'm just imagining something like this:
from typing import Generic, Optional, TypeVar, get_args, get_origin

### library

def _default_beartype_instancecheck(cls, item) -> Optional[str]:
    if isinstance(item, cls):  # in practice also handle non-class hints here
        return None
    else:
        return f"{item} not of type {cls}"

class Message:
    __slots__ = ("msg",)
    def __init__(self, msg: Optional[str]):
        self.msg = msg

    def __bool__(self):
        return self.msg is None

    def __str__(self):
        return str(self.msg)

def beartype_isinstance(item, hint) -> Message:
    cls = get_origin(hint)
    if cls is None:
        cls = hint
    if hasattr(type(cls), "__beartype_instancecheck__"):
        checker = type(cls).__beartype_instancecheck__
    else:
        checker = _default_beartype_instancecheck
    out = checker(hint, item)
    # Return in something that has the right `__bool__`, so that
    # `if beartype_isinstance(...):` has the same semantics as `if isinstance(...):`.
    return Message(out)

### user code

T = TypeVar("T")

class MetaA(type):
    def __beartype_instancecheck__(cls, item):
        (typevar,) = get_args(cls)
        if beartype_isinstance(item, typevar):  # recurse properly, friends
            return None
        else:
            return f"Wahoo, a custom error message. You didn't pass a {cls}!"

class LooksLike(Generic[T], metaclass=MetaA):
    pass

print(beartype_isinstance(1, int))  # None
print(beartype_isinstance(1, str))  # 1 not of type <class 'str'>
print(beartype_isinstance(1, LooksLike[int]))  # None
print(beartype_isinstance(1, LooksLike[str]))  # Wahoo, a custom error message. You didn't pass a __main__.LooksLike[str]!

@tvdboom: Sweetness. Simplicity is my middle name! It's not, actually. But... it should have been.
The above implementation of your SequenceProtocol.__beartype_cause__() method is definitely the worst case; that method necessarily supports deeply nested child type hints (e.g., SequenceProtocol[Dict[str, SequenceProtocol[str]] sort of stuff). Ideally, your newest example of Annotated[int, Is[lambda v: v>0]] would be the best case. That type hint can't possibly be subscripted by anything, so... it should be trivial to define an __beartype_cause__() method describing that type hint. Right?
Well, sorta. If @beartype allowed you to pass a custom cause= keyword parameter inside subscriptions of the Is[...] validator, then the following would suffice – maybe, probably, hopefully, ohgodsisthisevergonnawork:
from beartype.door import TypeHintCause
from beartype.typing import Annotated
from beartype.vale import Is

def positive_int_cause(cause: TypeHintCause) -> TypeHintCause:
    '''
    ``__beartype_cause__()`` implementation for the :pep:`593`-compliant
    :data:`.PositiveInt` type hint declared below.
    '''

    # If the object currently being type-checked is *NOT* an integer, define an
    # appropriate error message.
    if not isinstance(cause.obj, int):
        cause.message = 'not an integer'
    # Else, this object is an integer.
    #
    # If this integer is non-positive, define an appropriate error message.
    elif cause.obj <= 0:
        cause.message = f'value should be larger than zero, got {cause.obj}'
    # Else, this integer is positive and thus satisfies "PositiveInt". Notify
    # the caller of this by doing absolutely nothing. Just go with it, people.

    # Return this cause.
    return cause

PositiveInt = Annotated[int, Is[lambda v: v>0, cause=positive_int_cause]]
'''
:pep:`593`-compliant type hint matching a positive integer.
'''

Super simple. That's just 7 additional lines of code, ignoring extraneous docstrings and comments. Not needing to support child type hints alleviates all of the anguish associated with the above SequenceProtocol.__beartype_cause__() implementation. This is why we rejoice. :partying_face:

Hang on, this API looks odd to me.

...heh. This API looks odd to you, because this API is odd. So, let's back up. The core @beartype decorator dynamically generates Python code that does two sequential things to type-check type hints at runtime. In order, these things are:

Testing. First, @beartype efficiently tests whether the parameters passed to and value returned from the current callable satisfy the type hints annotating that callable. @beartype works very hard to ensure that this test is both macro- and micro-optimized to the hilt and that this test guaranteeably runs in O(1) time with negligible constant factors.
Exception raising. Second, if one or more of these tests fail, @beartype then inefficiently raises a human-readable exception. This phase is completely unoptimized. It's expected to be slow and typically is slow, but nobody cares because it hardly ever happens. If something failed a type-check, then your code is busted and is about to crash anyway. Efficiency is no longer a pressing concern. You have bigger problems.

One of the main philosophical realizations of @beartype is that runtime type-checking can be done extremely fast if you separate the testing and exception-raising parts of runtime type-checking into two distinct phases. Testing can be done fast – but only so long as all you're doing is testing. As soon as you try actually generating a human-readable exception message, you're now slow. Thus the separation. Ideally, correctly functioning code will do a lot of runtime type-checks that always pass these fast tests and thus never even need to go on to the slow portion that raises a human-readable exception on a failing type-check.
So far, so good. Here's where things get less good. Surprisingly, raising human-readable exceptions is non-trivial – especially when you consider non-trivial parent type hints that arbitrarily nest child type hints – especially when some of those child type hints imply conditional branching logic. Something like Union[List[str], MutableMapping[int, Iterable[Collection[Sequence[int]]]] is a horrifying example.
This weirdo API that @beartype will soon be exposing to you? Yeah. That weirdo API has been battle-hardened to handle just these kinds of monstrous type hints that nobody should ever define but (contrary to sanity) everybody defines all the time.
This weirdo API is currently hidden from you in the beartype._decor.error subpackage, which contains almost ~2,500 lines of code alone just to generate human-readable type-checking violation messages. This is why you are squinting. Because this weirdo API is already capable of doing things far in excess of what the standard use case requires. But... there's really no other way to do this. Thankfully, as the much conciser implementation of the positive_int_cause() function above demonstrates, this weirdo API is much simpler than the initial worst-case SequnceProtocol.__beartype_cause() method above made it out to be.
 What are we even doing here!?!?  :face_exhaling:

Why is the cause passing information about the hint? That's not needed at all, the hint already knows who it is via the cls parameter.

...heh. That's actually needed. The cls parameter fails to convey subscriptions. typing.Protocol subclasses typing.Generic. Think def SequenceProtocol(Protocol[T]): in the above example. That's a subscriptable generic – not simply a vanilla unsubscriptable class. All PEP 544-compliant protocols are also PEP 484-compliant generics and can be subscripted as such.
Indeed, @tvdboom's use case requires subscription. Consider SequenceProtocol[int], which effectively carries the same typing semantics as collections.abc.Sequence[int] with the added benefit of supporting non-standard sequences that satisfy SequenceProtocol but not collections.abc.Sequence. These include (...waitforit) NumPy and thus JAX arrays as well as Pandas dataframes, indices, and series.
It's actually a pretty cool idea. I personally applaud @tvdboom for this! Publish SequenceProtocol as an open-source package of some sort and reap the incoming GitHub stars, partying emoji, and positive life karma. This is the way.

The mutation in cause.message = ... doesn't seem necessary.

...heh. You'd prefer to just return a simple dataclass like Message encapsulating a string message, right? I certainly get it. I myself prefer that. That's the standard approach and what everyone would prefer to happen rather than this convoluted dataclass abstraction called TypeHintCause that you then mutate, permute, and return all over the place.
Sadly, the dataclass is probably necessary. Why? Because the TypeHintCause API does alot more than just generate messages. TypeHintCause also does essential bookkeeping chores like identifying the exact culprit responsible for the current type-checking violation, where "culprit" means the beartype.roar.BeartypeCallHintViolation.culprits instance variable associated with all type-checking violations.
Culprits is kinda a deep topic. But the point is that the TypeHintCause API also needs to identify the exact object responsible for a type-checking violation. This is trivial in the case of a simple type, as the above PositiveInt example demonstrates. But this is non-trivial in the case of a subscriptable type hint, as the above SequenceProtocol example demonstrates. In the latter case, the culprit is typically an item of an iterable container. That item needs to be:

Identified (via iteration in SequenceProtocol.__beartype_cause__()).
Exposed (via the BeartypeCallHintViolation.culprits variable).

Sunlight is the best disinfectant for the darkness. That's a great phrase. Thanks, dead Supreme Court Justice Louis Brandeis! But will anyone actually want to do any of this? I... don't know. @beartype already does this. So, at least one living human wants to do this. Yep. It's me. I sigh and then grimace. :face_exhaling: :grimacing:
You are now thinking to yourself: "But... I don't care about culprits or any of that other stuff. I just care about exception messages. Can't we just focus on that, you cretin?" I know you're thinking that, Dr. Kidger. I know you. You demand sane APIs. Admittedly, I am a cretin.
But... @beartype is kinda insane. The problem domain of runtime type-checking is ostensibly a wicked problem. You want to just care about exception messages – but that's not really possible, because generating exception messages is inextricably entangled with identifying culprits and all of that other bookkeeping. Philosophically and programmatically, these problems are all interrelated.
Consider, for example: how do you even generate a human-readable exception message without first identifying the culprits responsible for the current type-checking violation? You can't, really. First, you figure out which object committed seppuku; this is the culprit. Then, you shame that culprit by describing that culprit in an exception message.

This seems to require learning a whole new system for the end user.

Yup.

I think that's a non-starter from a usability perspective.

Yup. I'm sorta fine with that, because this is what @beartype itself internally needs to both generate human-readable exceptions as well as identify culprits for arbitrarily complex type hints. Those things were never going to be easy. They can't be. Indeed, those things are almost harder than dynamically generating code to efficiently detect type-checking violations.
And Odin only knows: that's hard.
Also...
from typing import ..., get_args, get_origin

Beware! Pretty much all runtime typing functionality is busted. This includes both typing.get_args() and typing.get_origin(). None of those functions should ever be called in production-ready code, because none of those functions safely accept arbitrary type hints or behave as expected in various common edge cases.
Instead, this is why the beartype.door.TypeHint API exists – and why the beartype.door.TypeHintCause dataclass internally encapsulates the current type hint as the cause.hint: TypeHint instance variable. You definitely want to use that instead of blatantly busted typing functions.
Fascinatingly, your custom _default_beartype_instancecheck() and beartype_isinstance() functions and custom Message dataclass closely resemble my initial implementations in the beartype._decor.error subpackage. Naturally, things got explosively more complicated as @beartype began supporting more and more PEPs and various kinds of type hints. Memories of those early days are still painful.
Even something that you would think is simple like typing.Union[...] becomes extremely non-simple when you consider that @beartype needs to explain why exactly each child type hint subscripting the union fails to satisfy that union – both in human-readable form via the exception message and in machine-readable form via the culprits variable. Now, a single Message no longer suffices. You need one Message for each branch of the union describing exactly why that branch failed to satisfy its child type hint.
Your Message dataclass very rapidly begins to resemble our TypeHintCause dataclass – with all of its attendant API complexities, nuances, and usability migraines. Trust me, bro. This is the only way.
Never trust anyone who says:

Trust me, bro.

Separating testing and raising is a good point, and I like that.

The cls parameter fails to convey subscriptions.

Look again! My implementation includes passing the subscripted hint as the cls. IMO this is cleaner, as it's just a subscripted generic, not a new TypeHint object.

The mutation in cause.message = ... doesn't seem necessary.

What I'm saying is, you're already returning cause. You don't need to mutate an input as well. An API should typically either mutate its input, or (preferably) return a brand-new object. Not both.
As you point out, this is already on the slow path, so there's no interesting speed advantage to mutation.
(The fact that it's a dataclass is totally fine.)

This seems to require learning a whole new system for the end user.

Do I understand correctly that the reason for this proposed system, as opposed to just "return a string", is specifically (and only) so that implementers of __beartype_cause__ are able to identify a culprit other than just cls? They might want to say that it's actually the fault of
cls[foo, bar[Union[int, str]]]
                   ^^^
                   this bit

?

Pretty much all runtime typing functionality is busted. This includes both typing.get_args() and typing.get_origin()

Haha, I'm definitely willing to believe that. What's the failure mode for these two functions?

OMG. I... totally neglected to reply to @patrick-kidger. I'm sweating in a poorly insulated cabin over here. :sweat_smile:
On the bright side, @beartype is finally doing this. Specifically, our upcoming @beartype 0.17.0 release now supports our first official plugin API. And, no; it's not that hideous __beartype_cause__() thing that everybody hates. Instead, it's a @beartype-agnostic __instancecheck_str__() dunder method that everybody had better love. Like __instancecheck__(), __instancecheck_str__() is intended to be defined on the metaclass of user-defined classes. It has a signature resembling:
def __instancecheck_str__(cls, obj: typing.Any) -> str:

Simple, right? And it actually is. __instancecheck_str__() is intended to be supported by competing runtime type-checkers (e.g., typeguard, Pydantic) as a pseudo-standard. Ain't nobody got the time to write an actual PEP for that, of course. Thus, pseudo-standard.
@patrick-kidger's killer jaxtyping will probably be the first third-party consumer. Let's goooooooo!

Resolved by ef26913b4ac58d71f. Thanks for your patience, forbearance, and... wait. Was that an unexpected (but altogether welcome) bear pun in my @beartype feature request? You're not wrong. Where's there's puns, there's fire. This is your final API for raising human-readable violations:
from beartype import beartype

class MetaclassOfMuhClass(type):
    def __instancecheck_str__(cls, obj: object) -> str:
        return f'{repr(obj)} has disappointed {repr(cls)}... for the last time.'

class MuhClass(object, metaclass=MetaclassOfMuhClass):
    pass

@beartype
def muh_func(muh_obj: MuhClass) -> None:
    pass

muh_func("Some strings, you just can't reach.")

...which now raises the "human"-readable violation message:
beartype.roar.BeartypeCallHintParamViolation: Function __main__.muh_func() parameter
muh_obj="Some strings, you just can't reach." violates type hint <class '__main__.MuhClass'>, as
"Some strings, you just can't reach." has disappointed <class '__main__.MuhClass'>... for the last time.

Note that the string you return from your __instancecheck_str__() implementation:

Should be a sentence fragment whose first character is typically not capitalized.
May optionally be suffixed by a trailing period. In either case, @beartype intelligently does the right thing and ensures that the entire violation message is always suffixed by only a single trailing period.

Bear muscles are glistening with sweat. Flex it, @beartype! :muscle: :bear:


CUDA: Reduce fork detection overhead.

Move fork detection into post-call error handling

Out of curiosity, for which operations is get_context() performance-critical?

for which operations is get_context() performance-critical?

Almost every operation ends up calling get_context() at least once.  Sometimes, an application is required to quickly issue H->D copy, kernel call, D->H copy in multiple asynchronous streams to achieve concurrent kernel calls and copy-execution overlap.  In that case, it is critical to lower the per API call overhead.
There are other cases that require multiple kernel calls to achieve a single task (such as reduction, sorting, searching) due to inter-threadblock communication.  A lower API call overhead reduces the minimum data size to achieve overall speedup.  I have seen it many times that the GPU is starving due to high API call overhead.

Great, thanks.


Popper again

📑 Description
Popper re-written. Breaking changes
Features:

decouple content from trigger - connection made via css query specified in triggeredBy parameter
multiple trigger elements possible - Popper can be re-used from different places in the document
use of the fade animation function from svelte instead of transition-opacity
use of svelte if directive instead of visible opacity classes
createPopper called only when content is open

Can you please do some testing before merge?
@AlessioGr can you check the behavior with SSR rendering?
✅ Checks

[x] My pull request adheres to the code style of this project
[x] My code requires changes to the documentation
[x] I have updated the documentation as required
[x] All the tests have passed
[x] My pull request is based on the latest commit (not the npm version).

ℹ Additional Information
Dropdown, Tooltip, Popover - old API left and some docs require further updates.

Since you are adding events on line 90,  you don't need line from 111 to 114?

Line 90 adds the events to triggers i.e. buttons that will open/close the popup.
Line 111 to 114 are the events set on the popup it's self. This is needed when activeContent is set, to support moving or clicking the popup window. This is the major difference between Tooltip and Popover. In Tooltip you are unable to click or hover the tooltip content, in Popover you can.


picographics - fixed_width parameter missing from method text()

The readme for picographics provides the following signature:
display.text(text, x, y, wordwrap, scale, angle, spacing)

The text after that also describes the fixed_width parameter:
fixed_width - space all characters equal distance apart (monospace)

However, as far as I can determine, this hasn't been implemented but it would be useful.  I'm testing on a Badger 2040 W  (wonderful device!!!).

I think the fixed_width argument is implemented, if you supply the keyword argument fixed_width=True to display.text() it should work.
There were some fixes to it for Badger - https://github.com/pimoroni/badger2040/issues/51

Thanks for the feedback.  My mistake - I was using an out-of-date distribution on my Badger-W.
In the PicoGraphics README.md you might like to change:
display.text(text, x, y, wordwrap, scale, angle, spacing)

to
display.text(text, x, y, wordwrap, scale, angle, spacing, fixed_width)

Thanks for the feedback. My mistake - I was using an out-of-date distribution on my Badger-W.
In the PicoGraphics README.md you might like to change:
display.text(text, x, y, wordwrap, scale, angle, spacing)

to
display.text(text, x, y, wordwrap, scale, angle, spacing, fixed_width)


Social media card image issues

Environment

Minimal Mistakes version:
Ruby gem or remote theme version: Ruby Gem
Jekyll version: I tried to determine what Jekyll version I am working with but the clue that I can provide as to the Jekyll version is that the website was started this week with the latest Jekyll type.
Git repository URL: https://github.com/reshet-net/reshet-net.github.io
GitHub Pages hosted (if yes provide URL to site): https://reshet-net.github.io/)
Operating system: macOS catalina

Expected behavior
I am trying to make the three twitter, facebook, and linkedin social media sharing buttons at the bottom of each blog post page share a link to a page on my website with a default image. I created a default og_image in the _config.yml file and labeled to an appropriate image.
Originally, I used this image, named default_card.jpg:

This is the old image.
I then got tired of this and went into the two assets folders in the repository and replaced it with the following image with the same default_card.jpg name and extension:

This is the only image present in the repository named default_card.jpg. Thus, I expected it to update everything and only the latest image preview being used due to the latest file overriding and replacing the older one.
Instead, I have the following two major issues:

When I click the Twitter button, no image gets displayed at all. This is a consistent issue that I don't know how to remedy, given that I configured the _config.yml page properly in accordance with the Twitter Card requirements (https://mmistakes.github.io/minimal-mistakes/docs/layouts/#open-graph--twitter-card-images)

When I go and click on the various sample blog posts and click the Facebook and LinkedIn share buttons below, I sometimes get the old image presented in the popover window, sometimes its the new one, and sometimes -- no image gets presented at all!

Naturally, I want the newer image and only the newer image to get presented
Steps to reproduce the behavior
I explained that I replaced the old image in the two folders with the newer image with the same name and extension. What's really weird is that I sometimes get the old one but sometimes the newer one.
For example:

https://reshet-net.github.io/blog/post-notice/ --> the linkedin share has no image, at least on my computer and the facebook share has the old image

https://reshet-net.github.io/blog/post-quote/ --> the linkedin has the newer image but the facebook has the older image

https://reshet-net.github.io/blog/welcome-to-jekyll/ --> the facebook and linkedin both have the old image

https://reshet-net.github.io/blog/post-modified/ --> the linkedin has the newer image while the facebook has the older

I'd greatly appreciate your help. I don't know what to do and could use any advice you may be willing to give. Thanks for reading and in advance.

As far as I can tell you've done everything correct and I'm seeing your updated image. The social images are assigned properly in the HTML source for those pages.
The issue is on the various social platforms... they're caching the old image perhaps. Twitter and Facebook both have tools to inspect what meta data a page is using. The OpenGraph debugger tool also has a rescrape option to have your page updated.
https://cards-dev.twitter.com/validator

https://developers.facebook.com/tools/debug/

Closing as this isn't a theme issue.


ERROR: Unable to download webpage: HTTP Error 429

Checklist

[x] I'm reporting a broken site support issue
[x] I've verified that I'm running youtube-dl version 2020.03.08
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar bug reports including closed ones
[x] I've read bugs section in FAQ

Verbose log

PASTE VERBOSE LOG HERE

youtube-dl.exe --verbose -F https://www.youtube.com/watch?v=rHT9hfHcc6g
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', '-F', 'https://www.youtube.com/watch?v=rHT9hfHcc6g']
[debug] Encodings: locale cp1252, fs mbcs, out cp437, pref cp1252
[debug] youtube-dl version 2020.03.08
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.18362
[debug] exe versions: ffmpeg git-2020-02-20-56df829, ffprobe git-2020-02-20-56df829
[debug] Proxy map: {}
[youtube] rHT9hfHcc6g: Downloading webpage
ERROR: Unable to download webpage: HTTP Error 429: Too Many Requests (caused by HTTPError()); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmp378onz6j\build\youtube_dl\extractor\common.py", line 627, in _request_webpage
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmp378onz6j\build\youtube_dl\YoutubeDL.py", line 2238, in urlopen
File "C:\Python\Python34\lib\urllib\request.py", line 470, in open
File "C:\Python\Python34\lib\urllib\request.py", line 580, in http_response
File "C:\Python\Python34\lib\urllib\request.py", line 508, in error
File "C:\Python\Python34\lib\urllib\request.py", line 442, in _call_chain
File "C:\Python\Python34\lib\urllib\request.py", line 588, in http_error_default
Description

#WRITE DESCRIPTION HERE
When I try to get available formats using the -F options, I just get the error message.

link to duplicate issue?
and what is the solution?

See https://github.com/ytdl-org/youtube-dl/issues/23638 and https://github.com/ytdl-org/youtube-dl#http-error-429-too-many-requests-or-402-payment-required


Landscaper control-plane component part 2: add flow + certificate generation

How to categorize this PR?

/area control-plane
/kind enhancement
What this PR does / why we need it:
Next part of the landscaper control plane component.
Adds

changes to the import API of the landscaper control plane. The main part here is that it is possible to provide optional secret references in addition to providing certificate values directly.
the skeleton flow containing everything related to generating, validation, and export of certificates.
updates to the README

Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Adds the type "secrets" to the etcd encryption configuration. The configuration for the Gardener API server looks like this:
apiVersion: apiserver.config.k8s.io/v1
 kind: EncryptionConfiguration
 resources:
 - providers:
   - aescbc:
       keys:
       - ...
   - identity: {}
   resources:
   - secrets
   - controllerdeployments.core.gardener.cloud
   - controllerregistrations.core.gardener.cloud
   - shootstates.core.gardener.cloud

Does not yet contain tests for the steps in the deployment flow. This will be provided in a later PR.

The flow is already runnable, though does not deploy anything to the Garden or runtime cluster yet.
However, generated certificates are exported to the local filesystem.
Release note:

/ping @danielfoehrKn  - can you please finalize this PR so that we can merge it and remove the 'draft' label from #4865?


winget hangs prompting for approval of source agreement terms in PowerShell 7.4.0-preview.6

Brief description of your issue
(follow-up to https://github.com/PowerShell/PowerShell/issues/20452)
When winget needs to prompt for approval of the source license terms, it hangs when run under PowerShell 7.4.0-preview.6 running on Windows 11 10.0.22621.2361.amd64fre.ni_release.220506-1250 within Windows Terminal Preview 1.19.2309.25002.
This works fine under PowerShell 7.3.7.
PS> winget list smartm
The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

Do you agree to all the source agreements terms?
[Y] Yes  [N] No:

Entering 'Y' at this point does nothing: winget cannot read keyboard input.
Steps to reproduce
Run this Update-WinGetSources.ps1 PowerShell script:
#requires -RunAsAdministrator

winget source reset --force
$msix = Join-Path -Path $env:TEMP -ChildPath 'source.msix'
Invoke-WebRequest https://cdn.winget.microsoft.com/cache/source.msix -OutFile $msix
Add-AppXPackage -Path $msix
Remove-Item -Path $msix
winget source update

Then invoke winget list smartm.
At the prompt, type Y
Expected behavior
PS> winget list smartm
The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

Do you agree to all the source agreements terms?
[Y] Yes  [N] No: Y

Actual behavior
PS> winget list smartm
The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

Do you agree to all the source agreements terms?
[Y] Yes  [N] No:

Keyboard input is ignored. The winget.exe process needs to be killed.
Environment
Windows Package Manager v1.6.2771
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.2361
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.2771.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

This issue encountered yesterday was 100% reproducible.
It seems that it's no longer the case (system has been restarted in the meantime).
Any clue?

@sba923 I got another report from a different user trying to reproduce this behavior, and we haven't been able to get the device into that state reliably yet.

If there's anything I can do to help, just tell me.

@sba923 thanks so much for offering. If you have a device in that state or can find some reliable way to get a device in that state, it will make it much easier for us to grab logs and try to isolate the root cause so we can find a fix.
I've just seen several anecdotal instances where a reboot fixes it, so we haven't been able to determine what causes it.

I don't have a device in that state at this very moment. Next time it happens, what logs / data do you want me to capture?
I have a Process Explorer-capture full dump from one of the last occurrences. FWIW, here's what analyze -v had to say:
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 484

    Key  : Analysis.Elapsed.mSec
    Value: 38068

    Key  : Analysis.IO.Other.Mb
    Value: 33

    Key  : Analysis.IO.Read.Mb
    Value: 0

    Key  : Analysis.IO.Write.Mb
    Value: 128

    Key  : Analysis.Init.CPU.mSec
    Value: 77

    Key  : Analysis.Init.Elapsed.mSec
    Value: 10348

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 157

    Key  : Failure.Bucket
    Value: BREAKPOINT_80000003_ucrtbase.dll!translate_text_mode_nolock_char

    Key  : Failure.Hash
    Value: {639c42a6-4c88-886f-bc8f-61d63d42c2a4}

    Key  : Timeline.OS.Boot.DeltaSec
    Value: 8192

    Key  : Timeline.Process.Start.DeltaSec
    Value: 72

    Key  : WER.OS.Branch
    Value: ni_release

    Key  : WER.OS.Version
    Value: 10.0.22621.1

    Key  : WER.Process.Version
    Value: 1.21.2310.4001

FILE_IN_CAB:  winget-hung-202310080945.dmp

NTGLOBALFLAG:  0

PROCESS_BAM_CURRENT_THROTTLED: 0

PROCESS_BAM_PREVIOUS_THROTTLED: 0

APPLICATION_VERIFIER_FLAGS:  0

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress:<PHONE_NUMBER>000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD:  00004aac

PROCESS_NAME:  winget.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE_STR:  80000003

STACK_TEXT:
00000049`e28fe518 00007ffe`a87765fb     : cc581709`e91f3c69 00007ffe`00000340 00000049`00000002 00000049`e28fe620 : ntdll!NtReadFile+0x14
00000049`e28fe520 00007ffe`a8b07030     : 00000167`0ea97340 00007ffe`a8c00990 00000000`00000004 00000049`e28fe5e8 : KERNELBASE!ReadFile+0x7b
00000049`e28fe590 00007ffe`a8b06dbd     : 00000049`e28fe610 00000167`00000000 00000000`00000000 00000000`00000000 : ucrtbase!translate_text_mode_nolock<char>+0x100
00000049`e28fe5e0 00007ffe`a8b07845     : 00000000`00000000 00000000`00001000 00000000`00000000 00000000`00000001 : ucrtbase!translate_ansi_or_utf8_nolock+0x2d
00000049`e28fe630 00007ffe`a8b0798f     : 00000167`0ea97300 00000167`0ea97340 00000000`00000001 00000000`00000001 : ucrtbase!_read_nolock+0x17d
00000049`e28fe6d0 00007ffe`a8b07bae     : 00000000`00000000 00007ffe`a8bff4a0 00000167`0ea97340 00007ffe`220c5e50 : ucrtbase!_read+0xaf
00000049`e28fe710 00007ffe`a8b07f12     : 00007ffe`a8bff4a0 00000000`ffffffff 00007ffe`a8bff4a0 00000000`00000079 : ucrtbase!common_refill_and_read_nolock<char>+0x76
00000049`e28fe740 00007ffe`22049006     : 00007ffe`a8bff4a0 00007ffe`a8bff4a0 00007ffe`a8bff4a0 00007ffe`220c5db0 : ucrtbase!fgetc+0x122
00000049`e28fe790 00007ffe`2204928b     : 00007ffe`220c5db0 00007ffe`220c5db0 00000000`00000001 00007ffe`220c5e50 : msvcp140!std::basic_filebuf<char,std::char_traits<char> >::uflow+0xb6
00000049`e28fe840 00007ffe`22091250     : 00000000`ffffffff 00000000`0000000a 00000000`00000001 00000049`e28fea10 : msvcp140!std::basic_filebuf<char,std::char_traits<char> >::underflow+0x3b
00000049`e28fe870 00007ffd`b85bcfd1     : 00000000`00000000 00000000`00000001 00000000`00000000 00000049`e28fea10 : msvcp140!std::basic_streambuf<char,std::char_traits<char> >::snextc+0x90
00000049`e28fe8a0 00007ffd`b85bbfb4     : 00007ffe`220c5e50 0e38e38e`38e38e39 00007ffe`220c5e50 00000000`00000090 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x96b1
00000049`e28fe910 00007ffd`b85ed48e     : 00007ffe`220c6000 00000167`0c8e3300 00007ffe`220c6000 00007ffe`220c6000 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x8694
00000049`e28fec10 00007ffd`b85f000e     : 00007ffe`2204bdb5 00000167`0868d100 00000049`e28ffa01 00000049`e28ff2c9 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x39b6e
00000049`e28ff260 00007ffd`b85c9ef0     : 00000167`085b0140 00007ffe`ab40ba46 00000049`e28ffae8 00000049`e28ff600 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x3c6ee
00000049`e28ff330 00007ffd`b85f4733     : 00000167`08630aa8 00000000`00000000 00000167`0867c508 00000167`00000000 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x165d0
00000049`e28ff500 00007ffd`b85c4f52     : 00000167`08630aa8 00000049`e28ff710 00000049`e28ffae8 00000000`00000000 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x40e13
00000049`e28ff6c0 00007ffd`b85c56af     : 00000000`00000000 00000167`0869bb40 00007ffd`b890b730 00000167`08682640 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x11632
00000049`e28ff8b0 00007ffd`b85b8d4d     : 00000167`0869bb40 00000167`0869bb40 00000167`0869bb40 00000167`0869bb58 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x11d8f
00000049`e28ff950 00007ffd`b85530da     : 00000167`0860ca60 00000000`00000000 00000000`00000003 00000000`00000000 : WindowsPackageManager!WindowsPackageManagerConfigurationCompleteOutOfProcessFactoryInitialization+0x542d
00000049`e28ffea0 00007ff6`7c151238     : 00000167`0860ca60 00007ff6`7c1512b9 00000000`00000000 00000000`00000000 : WindowsPackageManager!WindowsPackageManagerCLIMain+0x3a
00000049`e28ffed0 00007ffe`a927257d     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : winget+0x1238
00000049`e28fff10 00007ffe`ab42aa78     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x1d
00000049`e28fff40 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28

STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_NAME:  ucrtbase!translate_text_mode_nolock<char>+100

MODULE_NAME: ucrtbase

IMAGE_NAME:  ucrtbase.dll

FAILURE_BUCKET_ID:  BREAKPOINT_80000003_ucrtbase.dll!translate_text_mode_nolock_char_

OS_VERSION:  10.0.22621.1

BUILDLAB_STR:  ni_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  10.0.22621.608

FAILURE_ID_HASH:  {639c42a6-4c88-886f-bc8f-61d63d42c2a4}

Followup:     MachineOwner
---------

Feedback hub would be a good start: https://aka.ms/winget-feedback
After it's filed, share the URL so it's easier for us to find that specific report.

Having the same issue here. It doesn't even give me the YES/No boxes and is being run in the ISE.

Occurred again with PowerShell 7.4.2.
Here are the logs and analyze -v  output.
winget.exe_240421_191810.txt
winget-hung-20240421.zip

Occurred again with PowerShell 7.4.5
Here are the logs and analyze -v output:
WinGet-2024-09-20-10-5X.zip
winget.exe_hung_at_prompt_240920_105704.txt

@denelon how do you suggest to proceed?


Add geolocation altitude to exported data.

Since altitude is already being recorded from the geolocation library, add altitude to export data. Will allow for more precise location matches within buildings with multiple levels.

Closing per #108


map will not be rendered in an angular ui modal or tab

If the directive is used in a modal window or in a tab the map does not show up. The error message is the following:
Uncaught TypeError: Cannot read property 'time' of null

Hi @harpandrew , Could you provide a jsfiddle showing this behaviour?

Hi @tombatossals I have made a codepen that shows the issue :
http://codepen.io/compso/pen/WvWOGv
I think it is because the map object needs to created after the modal dialog is created.

Found a solution:
http://codepen.io/compso/pen/WvWOGv
Works by waiting on the "rendered" promise of the modal dialog, and setting a scope variable to true, then linking this to the ng-if of the openlayers element.

@compso I'm closing this issue now as I think it's resolved :smile:. Reopen it when necessary.


Add "real name" field

Add a field where users can put in their real names, which will be displayed at the top of the employment profile. In general, and throughout the application, where we currently use the display name, use the real name (if entered), defaulting to display name. Continue to update the display name on each login as we currently do.

This will be a part of the initial release. To provide the real name field:

Add a real_name column / RealName property for the citizen
Add an optional field for the real name to the profile edit page

Once this is done, following are the changes that should be applied to display names:

Modify the display_name column / DisplayName to be nullable
Undo the change for #11 that puts the handle in the display name column if it's blank; instead, insert null  if it's blank
Create a CitizenName property that displays the first non-null value from (in order) RealName, DisplayName, and NaUser
Modify all areas in the application where DisplayName is being used to use CitizenName instead

Finally, run a query to set display_name to null if its value matches the na_user column.

This is done, ready for v1.0


Create columns to override definitions

As cross-species terms and non-taxonomy nodes do not have NS forest, they currently do not have any definitions.
To solve this, we need to add definitions that are linked to data.
In DOSDP-tools can add a definition column that will overwrite automated definition processes.
To do:

[x] @hkir-dev to create the columns for definitions
[x] @shawntanzk to write up definitions that link directly to data
[ ] @dosumis to workshop these definitions
[ ] @shawntanzk to add these definitions manually to the columns in point 1

Workshopping definition:
A [gross cell type] of the [species] [brain region]. These cells represent the transcriptomically defined cluster [cluster ID] in the dataset from the referenced publication and are transcriptomically homologous to similar clusters in other species.
I'm trying to create a definition that will 1) be generalizable, and 2) not require changes with more updates.
The above is what I came out with, would like some input and further workshopping on it as I'm not sure it is the greatest def atm.

Definitions column added:
https://github.com/obophenotype/brain_data_standards_ontologies/blob/cross_species/src/patterns/data/default/CCN202002013_class_curation.tsv
https://github.com/obophenotype/brain_data_standards_ontologies/blob/cross_species/src/patterns/data/default/CCN201912131_class_curation.tsv
https://github.com/obophenotype/brain_data_standards_ontologies/blob/cross_species/src/patterns/data/default/CCN201912132_class_curation.tsv

Some cross-species terms do have NS-forest markers, for them, ill tag on the last sentence of the definition "These cells are transcriptomically homologous to similar clusters in other species." at the end of the definition to note that instead.

For non C type (might be cross species but not specifically, eg non-IT projecting (X-species), or Lower FS Basket cell (non X-species)) - definition will be:
A [PrefLabel] of the Mus musculus primary motor cortex. These cells represent the transcriptomically defined cluster [Cluster ID] in the dataset from the referenced publication.
eg
A Lower FS Basket cell of the Mus musculus primary motor cortex. These cells represent the transcriptomically defined cluster CS202002013_257 in the dataset from the referenced publication.

done

These cells represent the transcriptomically defined cluster [cluster ID] in the dataset from the referenced publication. These cells are transcriptomically homologous to similar clusters in other species.

This seems tautologous to me, specifically "These cells are transcriptomically homologous to similar clusters in other species." If the clusters are defined transcriptomically, saying two clusters are similar means they are transcriptomically similar (homologous).

If the clusters are defined transcriptomically, saying two clusters are similar means they are transcriptomically similar (homologous).

I think in this case, while 100% true that it is repeating the same thing, it helps in clarity for the end-user. Saying that they are similar (without the use of transcriptomic) could imply similarities in other ways (eg morphologically, electrophysiological, etc.) which while might be true, we do not have sufficient evidence to back that statement out.  Limiting the scope to only transcriptomically similar would be more honest to the data IMO

Saying that they are similar (without the use of transcriptomic) could imply similarities in other ways (eg morphologically, electrophysiological, etc.) which while might be true, we do not have sufficient evidence to back that statement out.

Sure, that makes sense. But the last sentence states that they are similar without the use of 'transcriptomically' as a modifier of 'similar'.

These cells represent the transcriptomically defined cluster [cluster ID] in the dataset from the referenced publication. These cells are transcriptomically homologous to similar clusters in other species.

Would moving 'transcriptomically' help? Or would the problem just move from 'similar' to 'homologous'?

These cells are homologous to transcriptomically similar clusters in other species.

actually just talked about this in today's meeting with @dosumis - he made a good point that that statement is kind of not useful in the context of the ontology and also misleading if anything - so we will be removing that from the defs and comments - but totally get your point. I guess the use of the term 'homologous' is tricky in general and perhaps we need to reconsider how we present that to people outside who are not familiar with the data. For now, we just have to depend on the logical axioms to hold this up I guess. An important part would probably be to figure out how to make these meanings clear in the cell type cards

Sounds like a good plan.
Thanks, @shawntanzk! Very helpful, as always.


APM Install angularjs-atom not working

what is the command for the atom package manager? is this not published on it? its not on the readme.

use apm install angularjs.
The name is in package.json.


7dof robot moves if I use observed joint position as action

Hello,
my issue is that if I try to use the observed joint_positions as input and null joint_velocities the 7dof robot will move on the x-z plane and not remain still. Is there an explanation for this?
I think this also causes problems when I try to convert the actions to cartesian acceleration of the end effector.
I do this calculating the next end effector position given the current end effector's position, velocity and the desired acceleration (the action) and then I use the inverse_kinematics function to calculate the next joint position. The joint velocities are calculated with finite differences. When using accelerations in this way I notice the robot tends to go the left If the acceleration towards the right is not enough.
Below is my code to reproduce the problem stated at the beginning
import numpy as np
from air_hockey_challenge.framework import AirHockeyChallengeWrapper

env = AirHockeyChallengeWrapper(env='7dof-hit', interpolation_order=3)

env_info = env.env_info
joint_pos_ids = env_info['joint_pos_ids']
n_joints = env_info['robot']['n_joints']

obs = env.reset()

done = False

while not done:
    joint_pos = obs[joint_pos_ids]
    joint_vel = np.zeros((n_joints,))

    action = np.vstack((joint_pos, joint_vel))

    obs, reward, done, info = env.step(action)
    env.render()

Hi,
I think this problem could potentially happen in the real robot. If you always update your controller set point to the current one, the robot will not maintain static due to the controlling error. Typically, you should have a set point in the agent to avoid this small drifting. As a simple fix, if you move the joint_pos = obs[joint_pos_ids] outside the loop, the robot should hold its position.

Hi, thank you for your reply.
About the first problem, shouldn't we expect random movements if the controlling error was the cause? And not a bias towards left.

The error will not be random depending on the model error. For example, if your gravity compensation term is smaller than the actual one. The robot will fall down. But the bias towards the left is pretty strange. I don't think this should happen.

The issue has been closed as there are no further updates available.


Some DELETE queries throw an exception

Some DELETE queries are failing with a The transaction didn't commit cleanly error.
Queries to reproduce the issue:
CREATE TABLE u_xinlin.table0601 (id INT, price DOUBLE, datepartition VARCHAR, customer VARCHAR) WITH (partitioned_by = array['datepartition', 'customer']);
INSERT INTO u_xinlin.table0601 VALUES (0, 1.0, '2020-06-01', 'xinlin'), (0, 1.0, '2020-06-01', 'xinlin0'),(0, 1.0, '2020-06-01', 'xinlin1'),(0, 1.0, '2020-06-01', 'xinlin2'),(0, 1.0, '2020-06-01', 'xinlin3'),(0, 1.0, '2020-06-01', 'xinlin4'),(0, 1.0, '2020-06-01', 'xinlin5'),(0, 1.0, '2020-06-01', 'xinlin6'),(0, 1.0, '2020-06-01', 'xinlin7'),(0, 1.0, '2020-06-01', 'xinlin8'),(0, 1.0, '2020-06-01', 'xinlin9');
DELETE FROM u_xinlin.table0601 WHERE datepartition = '2020-06-01';

Stacktrace in Presto:
io.prestosql.spi.PrestoException: The transaction didn't commit cleanly. All operations other than the following delete operations were completed: drop partition u_xinlin.table0601 [2019-04-25, xinlin9]; drop partition u_xinlin.table0601 [2019-04-25, xinlin]; drop partition u_xinlin.table0601 [2019-04-25, xinlin4]; drop partition u_xinlin.table0601 [2019-04-25, xinlin2]; drop partition u_xinlin.table0601 [2019-04-25, xinlin8]
	at io.prestosql.plugin.hive.metastore.SemiTransactionalHiveMetastore$Committer.executeIrreversibleMetastoreOperations(SemiTransactionalHiveMetastore.java:1710)
	at io.prestosql.plugin.hive.metastore.SemiTransactionalHiveMetastore.commitShared(SemiTransactionalHiveMetastore.java:1170)
	at io.prestosql.plugin.hive.metastore.SemiTransactionalHiveMetastore.commit(SemiTransactionalHiveMetastore.java:959)
	at io.prestosql.plugin.hive.HiveMetadata.commit(HiveMetadata.java:2596)
	at io.prestosql.plugin.hive.HiveConnector.commit(HiveConnector.java:212)
	at io.prestosql.transaction.InMemoryTransactionManager$TransactionMetadata$ConnectorTransactionMetadata.commit(InMemoryTransactionManager.java:594)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
	at io.airlift.concurrent.BoundedExecutor.drainQueue(BoundedExecutor.java:78)
	at io.prestosql.$gen.Presto_unknown____20200601_164801_2.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
	Suppressed: io.prestosql.spi.PrestoException: Got exception: java.io.IOException Failed to move to trash: hdfs://ltx1-faronn01.grid.linkedin.com:9000/user/xinlin/u_xinlin.db/table0601/datepartition=2019-04-25
		at io.prestosql.plugin.hive.metastore.thrift.ThriftHiveMetastore.dropPartition(ThriftHiveMetastore.java:1213)
		at io.prestosql.plugin.hive.metastore.thrift.BridgingHiveMetastore.dropPartition(BridgingHiveMetastore.java:348)
		at io.prestosql.plugin.hive.metastore.cache.CachingHiveMetastore.dropPartition(CachingHiveMetastore.java:732)
		at io.prestosql.plugin.hive.HiveMetastoreClosure.dropPartition(HiveMetastoreClosure.java:220)
		at io.prestosql.plugin.hive.metastore.SemiTransactionalHiveMetastore$Committer.lambda$prepareDropPartition$7(SemiTransactionalHiveMetastore.java:1362)
		at io.prestosql.plugin.hive.metastore.SemiTransactionalHiveMetastore$IrreversibleMetastoreOperation.run(SemiTransactionalHiveMetastore.java:2569)
		at io.prestosql.plugin.hive.metastore.SemiTransactionalHiveMetastore$Committer.lambda$executeIrreversibleMetastoreOperations$14(SemiTransactionalHiveMetastore.java:1681)
		at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run$$$capture(CompletableFuture.java:1736)
		at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java)
		at io.airlift.concurrent.BoundedExecutor.drainQueue(BoundedExecutor.java:78)
		... 3 more
	Caused by: org.apache.hadoop.hive.metastore.api.MetaException: Got exception: java.io.IOException Failed to move to trash: hdfs://ltx1-faronn01.grid.linkedin.com:9000/user/xinlin/u_xinlin.db/table0601/datepartition=2019-04-25
		at org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$drop_partition_result$drop_partition_resultStandardScheme.read(ThriftHiveMetastore.java)
		at org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$drop_partition_result$drop_partition_resultStandardScheme.read(ThriftHiveMetastore.java)
		at org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$drop_partition_result.read(ThriftHiveMetastore.java)
		at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:86)

Error logs in hcat.err:
Caused by: java.io.FileNotFoundException: rename source /users/xinlin/u_xinlin.db/table0601/datepartition=2019-04-25 is not found.
        at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.validateRenameSource(FSDirRenameOp.java:570)
        at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.unprotectedRenameTo(FSDirRenameOp.java:367)
        at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.renameTo(FSDirRenameOp.java:301)
        at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.renameToInt(FSDirRenameOp.java:251)
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:2838)
        at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename2(NameNodeRpcServer.java:1062)

I think the issue is because multiple DROP PARTITION requests are sent to HMS in parallel. Consider a table partitioned by column A and B. Its file structure may be like
table_name
├── A=a0
|   ├── B=b0
|   |   ├── data_file0
|   |   └── data_file1
|   ├── B=b1
|   |   └── ...
|   └── B=b2
|   |   └── ...
└── A=a1
    └── ...

When a DELETE FROM table_name WHERE A = a0 is executed, multiple DROP PARTITION requests are sent to HMS in parallel. For each DROP PARTITION request, according to the observed behavior, HMS will try to delete sub-directory (A=a0/B=b0) firstly, and then delete directory A=a0 if it's empty. However, there's a race condition when executing in parallel. Directory A=a0 may be deleted in multiple DROP PARTITION requests in parallel, which leads to the FileNotFoundException shown in hcat.err.
Although the query failure doesn't affect query correctness (the directory is deleted cleanly), its occurrence prevents one of our scheduled workflows from continuing.

In order to resolve this, I feel we might have to revert the changes in https://github.com/prestosql/presto/pull/1812 although the reversion will make it inefficient to drop a large number of partitions. @rohangarg , @electrum , @sopel39 , could you comment on this?

@lxynov let me rephrase to check whether i understand. We delete two partitions:
A=val_a/B=val_b1
A=val_a/B=val_b2

and the metastore does equivalent of rmdir -p A=val_a/B=val_b1 and rmdir -p A=val_a/B=val_b2 (in threads, because we call it in threads).
The ordering of events can cause both threads to realize A=val_a/ is now empty and should be removed.
Am i correct?
Since partition deletions can be caused by different queries, it feels legal that these coincide on the metastore side.
So failure do delete properly seems to be the bug on metastore side. Is it already reported?

I checked and HMS does try to delete empty parents for a partition directory (here). Also, the hive dir. deletion part tries to ignore FNFE but the exception a lot of times isn't captured/passed properly in the delete or rename calls. I am not sure about why the parent deletion was done in the HMS though.
Also, @lxynov I think your exception shows error in rename because of skipTrash property not set in hive metastore.
For a workaround currently, you can try setting the hive.max-concurrent-metastore-drops property to 1.
Without the metastore change, for parallel drops I think we would require the knowledge of storage locations of partitions to avoid this issue.

Thanks @findepi for the comment. Yes your description is accurate. And I think your argument is valid. Ideally HMS should be able to handle such cases.
Thanks @rohangarg for looking into this. Good to know that hive does try to ignore FNFE when deleting directories. We're running Hive 1.2 so the behavior might be different than the latest one. Thanks for your suggestions on skipTrash and hive.max-concurrent-metastore-drops. I'll try these options as of now.


Dune based build

Closes https://github.com/tlaplus/tlapm/issues/82
This PR extends the dune-based build started at https://github.com/tlaplus/tlapm/pull/81.
This version supports running the tests and creating a release.
The changes are non-invasive, so the previous build/test process remains working.

The PR is ready to be reviewed. In general, it adds:

Make the build process familiar to other projects (make ; make test; make install; make release).
The distribution file is just an archive that is enough to extract to use (no installation).
The test cases can be run without making a release and installing it. Use make -C test -f Makefile.dune fast or similar. The shell autocompletion to select a more detailed test case works this way.
Tlaps, if built with dune, uses dune sites to locate the backend provers and stdlib tla files. This makes taps easier to use, as no PATH updates are needed. As a side-effect, other projects can supply their files to these locations (sites); thus, a plugin system is in place to use, e.g., to add additional tla libraries.

There are some problems still, but I hope those are not blockers:

I found no simple way to run unit (kaputt-based, provided in the mlt files) tests without breaking the existing build. There are a few of them; maybe I could rewrite them using ppx_inline_test or similar?
The current dune install step breaks the symlinks and exec permissions. As a workaround, I fix them afterward with a post-install script. I will try to make a fix/PR to the dune project, but its acceptance will not be fast, I guess. Then we could remove that workaround with the post-install script.
There are now two parallel build systems. Would you agree to remove the old one and keep the dune based only?
I cannot test the scripts on operating systems other than Linux. I would like to have help or pointers with this.

I have resolved poly: Bad CPU type in executable for MacOS and several other incompatibilities in makefiles.

@damiendoligez, could you rerun the pipeline? I hope I have resolved the problems with MacOS.

@kape1395 I don't have any button on my GitHub interface to trigger the CI checks.

I've reviewed all the files that changed since my last review and everything looks good.

The checks are now executed. Maybe I have mistakenly assumed it is manual.

@johnyf, @damiendoligez, maybe this PR can be merged already?

@ahelwer, this is the PR I have updated the CI scripts.
There is room for improvement, especially when a release policy is decided.

@kape1395 okay cool, is there any obstacle to merging the PR? As you said it would be nice to get it in so we don't have PRs piling up on top of PRs. Don't have to issue a release yet.

Hurrah it's merged! @kape1395 do you think this is a good time to add a CI step to test the newly-built TLAPM against the tlaplus/examples repo, like we do for the tools here? https://github.com/tlaplus/tlaplus/blob/dd9f38f26c184014086c37bff8a056b4d51f4464/.github/workflows/pr.yml#L54-L83

@ahelwer, that's probably a good time from the build-script changes perspective, but now #55 was also merged to the main branch and introduced a bug. One of the tests fails; it sounds related to CHOOSE handling or theorem expansion. I hope to look at it deeper next weekend.

@ahelwer, I have updated the build/install instructions with this PR. Probably that can be useful for you: https://github.com/tlaplus/tlapm/blob/main/INSTALL.md

@kape1395 okay cool! Once the new bug is fixed do you think it will be worth cutting a pre-release so we can start consuming it in the tlaplus/examples CI to test that the nondeterministic install bug was fixed?

This question is not to me probably. What do you think about using the latest main all the time? This way some kind of continuous integration would be implemented.

We used to have that and I'm very much in favor or adding it again. :-)

I'd say that depends how much effort is necessary to build TLAPM from a checkout of main. The tlaplus tools are pushed to a nightly build server every time a commit hits main, which is nice, and we pull that down in the tlaplus/examples CI. Does this repo do anything similar?

What OS are you using locally? That could be some incompatibility in the CLI tools.
That line is generated in deps/isabelle/Makefile by the line
echo "all:\n\t chmod +x \$$(FILES)" >> $@

I guess in your OS, echo requires some flags (e.g., -e) to process escaped symbols properly.
Can you try changing that line to
echo -e "all:\n\t chmod +x \$$(FILES)" >> $@

Nah, it fails on my machine with -e added. Maybe there is a mismatch with the make versions? In my case that's
$ make --version
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Hi @kape1395 I can confirm adding the -e flag to echo fixed the issue for me.

You can check the error in files e.g.
./_build/default/test/fast/basic/cvc3_false_test.tla.err
./_build/default/test/fast/basic/cvc3_false_test.tla.out

and correspondingly for other test case files.
Adding -e is probably not enough, as that makes the script non-portable. For example, it fails on my machine. I will experiment with that.
By the way, why do you need the bin installer? There is no installer anymore.
After running
make build install

you can run tlapm e.g. as opam exec -- tlapm.
Or that's not enough to run the tests?
In my case, the tlapm exec is installed then as ~/.opam/5.1.0/lib/tlapm, but I think using opam exec is probably more convenient.


The s3 plugin is broken

Sorry to point this out, just check https://github.com/sebakerckhof/ufs-s3/issues/4

@dufia I am sorry I don't provide support for external projects, my own are already time consuming.
As @sebakerckhof said you should checkout the ufs-s3 repository, put it in your Meteor app "packages" folder and test if the problem is still alive. Hope you'll find a way to fix your error.


Export landmarks 2.0

Hi again,
I have this code to export the facial landmarks in an external file, but I don't know where I must put it. Initially, I put it in FaceDetTest.java. It compiles but doesn't work.
public void landmarkextract(ArrayList<Point> landmarks) throws IOException {          String route = "/sdcard/landmarks.txt";         File lndmrk = new File(route);          BufferedWriter bw = new BufferedWriter(new FileWriter(lndmrk));          for(int i=0; i<landmarks.size(); i++){              bw.write(String.valueOf(landmarks.get(i))+"\n");          }         bw.close();     }
Thanks.
Edit: Solved! I put it on the MainActivity.

If you can successfully obtain the landmarks from your picture, please keep in mind that it is not a Dlib-related issue, and shouldn't be posted here. You can refer instead to google.com or stackoverflow.com
Thanks :)


Build runc with selinux support

docker-ce seems to be building runc with selinux support, let us follow
the same pattern here please:
https://github.com/docker/docker-ce/search?p=1&q=RUNC_BUILDTAGS&unscoped_q=RUNC_BUILDTAGS
Signed-off-by: Davanum Srinivas<EMAIL_ADDRESS>

/ok-to-test


TACE-16

Create a standard library that can
1.Take any unicode input and try to return the codepoints for TACE-16
2. Interpret complex characters and prrovide TACE-16 codepoints
3. String Manipulation on TACE-16

Sathia we can prototype a TACE encoding in the common use area of Unicode 16 bit regular use.
Please add a TACE 16 to UTF8 and back converter to this task.


hack/quickstart: Use env file to keep track of master label/taint

Inspired by tectonic kubelet.service https://github.com/coreos/tectonic-installer/blob/89a6298bd974eaa59b391c9e6cd8218d9e70665c/modules/ignition/resources/services/kubelet.service
Not tested, as I'm not sure if this is out-of-scope for the hack scripts?

Merged via https://github.com/kubernetes-incubator/bootkube/pull/981


Pin search and settings box

Before Submitting Your Feature Request

[X] Check that there isn't already a similar feature request to avoid creating a duplicate.
[X] I have seen the FAQ.

Problem
At the moment to get to the settings you have to scroll the menu for a long time to get to the settings
Also, if there are a lot of entries in the search pattern and you start scrolling, you can't see the search bar.
screenshot

Solution
I suggest fixing the line with search box and settings box so that they don't scroll along with the search history.

You can limit number of visible items in Appearance preferences, that's the only solution at the moment. It's not possible to "pin" individual menu item (search box) while hiding other - there is no such API in macOS.

You can limit number of visible items in Appearance preferences, that's the only solution at the moment.

It seems to me that this is not a solution and not a particularly useful workaround: in just one day, I can copy more than 100 objects, even the current limit of 999 is very small (and I'm not the only one who thinks so https://github.com/p0deje/Maccy/issues/310). Many users, like myself, use clipboard managers to save information instead of notes, and if there is to be a limit, it should be on display, but with the ability to filter (as is done in copyq when copyq config tray_menu_open_on_left_click true is enabled).

It's not possible to "pin" individual menu item (search box) while hiding other - there is no such API in macOS.

Hmm, I know of several applications that have pinned items and scroll views:
open source: OnlySwitch, Itsycal
commercial: JetBrains Toolbox, Paragon NTFS

It seems to me that this is not a solution and not a particularly useful workaround: in just one day, I can copy more than 100 objects, even the current limit of 999 is very small (and I'm not the only one who thinks so https://github.com/p0deje/Maccy/issues/310). Many users, like myself, use clipboard managers to save information instead of notes, and if there is to be a limit, it should be on display, but with the ability to filter (as is done in copyq when copyq config tray_menu_open_on_left_click true is enabled).

I would love to support something like that but AppKit limitations doesn't let me do so easily. There were some attempts and discussions in #229, but so far there is not a decent reliable solution. Maybe in the future macOS would implement new features to support, but for now I don't see anything.
I use Maccy to store some info myself, but I rarely scroll through the list because I would just search for what I need instead. Limiting number of visible items + searching works just fine for me.

Hmm, I know of several applications that have pinned items and scroll views:
open source: OnlySwitch, Itsycal

Both applications use NSPopover controls to implement their UI, while Maccy uses NSMenu. Unfortunately, the latter doesn't support similar functionality, at least without re-implementing its core UI.


C4_W1_docker_cannot bring up local hosts

I'm running it on windows 11
I have executed the command below
C:\Users\fahmi>docker run --rm -p 8501:8051^  --mount type=bind,^ source=C:/tmp/tfserving/serving/tensorflow_serving/servables/tensorflow/testdata/saved_model_half_plus_two_cpu,^ target=/models/half_plus_two^  -e MODEL_NAME=half_plus_two -t tensorflow/serving
and it works but when I try to open localhost:8501 there is a message This page isn't workinglocalhost didn't send any data. ERR_EMPTY_RESPONSE. does anyone know the problem?
and here's the bottom of the log
Successfully loaded servable version {name: half_plus_two version: 123} 2023-05-08 02:43:27.637689: I tensorflow_serving/model_servers/server_core.cc:486] Finished adding/updating models 2023-05-08 02:43:27.639982: I tensorflow_serving/model_servers/server.cc:118] Using InsecureServerCredentials 2023-05-08 02:43:27.640398: I tensorflow_serving/model_servers/server.cc:383] Profiler service is enabled 2023-05-08 02:43:27.658633: I tensorflow_serving/model_servers/server.cc:409] Running gRPC ModelServer at <IP_ADDRESS>:8500 ... [warn] getaddrinfo: address family for nodename not supported 2023-05-08 02:43:27.668963: I tensorflow_serving/model_servers/server.cc:430] Exporting HTTP/REST API at:localhost:8501 ... [evhttp_server.cc : 245] NET_LOG: Entering the event loop ...

Hi Fadhil. Sorry for the late reply. Next time, you can post or search for topics in our community. There might be mentors/learners there who have the same setup and can help you. If you haven't joined yet, you can find instructions in Week 1 of your classroom. Thanks!


Enabling touchscreen and wifi modules of pixel3a by default

Hi,
I'm so glad I found this repo, as I wanted to experiment running bpf code on a pixel3a phone I have,
and didn't know how to port the bpf code to 4.9.
I understand that touchscreen and wifi are kernel modules in pixel3a, which require the use of adb and remounting to copy the updated modules (every time phone is restarted?)
but if I change:
CONFIG_TOUCHSCREEN_SYNAPTICS_DSX_CORE_v27=m
CONFIG_TOUCHSCREEN_SYNAPTICS_DSX_RMI_DEV_v27=m
CONFIG_TOUCHSCREEN_SYNAPTICS_DSX_FW_UPDATE_v27=m
CONFIG_TOUCHSCREEN_SYNAPTICS_DSX_TEST_REPORTING_v27=m
in bonito_defconfig to 'y', touchscreen is now enabled without the need for a kernel module!
so I wanted to ask:

Is there a reason not to change this from 'm' to 'y'?
Wifi code is available out of tree in google sources - do you think it should be easy to put it in the kernel sources and also compile it with the kernel? I tried to do that and failed :-(

Thanks,
Yaniv

Hi,
This is a great suggestion, thanks. Having to update modules manually is a pain. I don't know how to build the wifi driver not as a standalone module, but I'll look around.
From my experience it's enough to copy modules once and then the files stay there in the vendor partition, even if I restart the phone. Is that not the case for you ?

Hi,
The thing is that I'm trying to avoid compiling a user-debug android image,
and only use fastboot to boot to the compiled kernel.
Using android production build, I can't remount the vendor partition,
so I'm trying to workaround this by compiling the modules directly to the kernel image.
I can see in the pixel 3a wifi sources path 'android-kernel/private/msm-google-modules/wlan/qcacld-3.0'
that it already has Kconfig, Kbuild, and Android.mk - so I'm sure it should be possible to compile it as part of the kernel image.
I also see in:
https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-m4/drivers/staging/qcacld-3.0
that this driver was part of the 'drivers/staging' in the past - not sure why the decided to put it as a module.
I tried to put it in the same directory and add its configs, but the build failed (I don't remember the exact reason).
If you'll have any other ideas for how to do this, I'll really appreciate it.
I have another question, if you don't mind.
BCC fails to find the kernel headers - do you know how can I tell it where to find them?
modprobe: chdir '/lib/modules/4.9.165-01459-ge33b0b6ac10b': No such file or directory
Unable to find kernel headers. Try rebuilding kernel with CONFIG_IKHEADERS=m (module) or installing the kernel development package for your running kernel version.
chdir(/lib/modules/4.9.165-01459-ge33b0b6ac10b/build): No such file or directory

Thanks,
Yaniv

You can point BCC and bpftrace to the right directory by setting these env variables:

BCC_KERNEL_SOURCE
BPFTRACE_KERNEL_SOURCE


How can I make predictions on a new dataset?

Is there any pretrained model that I can download? How do I make new predictions with that model?
Thanks in advance.

Sorry, since it was a long time ago, I did not keep the model checkpoints.


Crankier: Log connection exceptions

Sends exception messages back to the worker for agent logging so you can see why faulted connections are failing.

@staff0rd Out of curiosity, what are you using Crankier for? Has it met your needs?

@halter73 attempting to get an understanding of what limits Azure has on SignalR.  Found some weird stuff like Websockets being limited to 768 for P1V1 & S1 app service plans, have raised tickets with support.  I get 8000+ locally.
Confirmed 350 websocket limit on B1 per the limits page.
I also want to test Azure SignalR Service as the pricing is not clear to me.  Notably whether connections count as messages (docs state they don't) and what Price/Unit/Day actually means: does it mean max number of units raised in a given 24 period, or, if I raise one unit for 12 hours and bring it back down, do I pay half the price.  Depending on answers to those I'd be interested in verifying @anurse's tweet - providing I can raise the resources on my VS subscription credit.

@staff0rd FYI in our experience, Azure App Service WebSocket support can be very limited. Azure SignalR Service is strongly recommended when using Azure App Service, since it handles the SignalR connections for you.

Depending on answers to those I'd be interested in verifying @anurse's tweet

FYI that tweet was using a VM, not Azure App Service ;)

@anurse what spec was the VM?

@halter73 changes made.
I dunno if conversation responses or resolving conversations trigger notifications?

what spec was the VM?

I honestly don't remember. That tweet was from a very early exploratory test. #5311 has some data that we've gathered based on Azure VM specs.

@anurse any guidance on how those numbers were achieved? #5311 notes 82,000 connections on B2s - but how are these connections being made?  I ran the benchmark server on a B2s, then ran Crankier but it stops at around 8000 with

System.Net.Http.HttpRequestException: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full

You need many client machines.

Also;

System.Net.Http.HttpRequestException: Only one usage of each socket address (protocol/network address/port) is normally permitted

How did you bring the client machines up?  Any automation here?

Manually, no automation, that's why we didn't go too far with it.

Ok, I stuck it in a container, raised 12 of them, and got 80172 connections on a B2s before something blew up and it lost 20k connections.

I dunno if conversation responses or resolving conversations trigger notifications?

In my experience, conversation responses trigger notifications, but resolving conversations doesn't.

@staff0rd Do you have any details about what blew up in you container-based testing?

@halter73 I do not have any info on what happened, and since decommissioned the resources.  Basically it was over 80k and suddenly about 20k connections.  The containers were still running at this time, and further connections were being made afterwards so it slowly started climbing again - however I switched it off as I didn't want to wait for it to get back up to 80k - I think overall it took about 20min to get that high with 12 containers making connections.
Oddly, some of the earlier containers I raised never even made 1,000 connections, when later ones were peaking at over 10,000 connections.  That said, I've got the suspicion that the 20k drop was due to one or two containers failing, but it's difficult for me to watch logs across 12 containers.
I still want to push the connection limit (just for fun with larger VMs), so I may make some changes to the benchmark server to help diagnose what's going on during multi-client tests.
I've also proven that the 768 limit I was getting on S1 App Services is per client.  While I can't find any docs to confirm that number, it removes any concern of App Service not being feasible for me in the short to medium term.

Thanks!


Change Video Challenges sequence

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm run test-challenges. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[x] Closes currently open issue (replace XXXX with an issue no): Closes #7583

Description

Change 'Video Challenges > Computer Basics' sequence by issue comments

:sparkles: :sparkles: LGTM. :sparkles: :sparkles:
Thanks.


Inconsistent acquired dates

Out of 123,919 records, all but five of the acquired dates of the artworks read in a standardized YYYY-MM-DD format. The following four were in MM-DD-YYYY format, and I think it would be good to change them from 11-17-2009 to 2009-11-17.
Row 110,555:
Untitled #136,José Antonio Suárez Londoño,"(Colombian, born 1955)",1997,Etching,"plate: 5 13/16 × 1 15/16"" (14.7 × 5 cm); sheet: 10 15/16 × 7 9/16"" (27.8 × 19.2 cm)",Gift of the artist through the Latin American and Caribbean Fund,1528.2009,Print,Prints & Illustrated Books,11-17-2009,N,133104,

Row 110,556:
Untitled #137,José Antonio Suárez Londoño,"(Colombian, born 1955)",1997,Etching,"plate: 5 13/16 × 1 15/16"" (14.8 × 4.9 cm); sheet: 11 × 7 1/2"" (28 × 19.1 cm)",Gift of the artist through the Latin American and Caribbean Fund,1529.2009,Print,Prints & Illustrated Books,11-17-2009,N,133105,

Row 110,557:
Untitled #138,José Antonio Suárez Londoño,"(Colombian, born 1955)",1997,Etching,"plate: 5 13/16 × 1 7/8"" (14.7 × 4.7 cm); sheet: 11 × 7 1/2"" (28 × 19.1 cm)",Gift of the artist through the Latin American and Caribbean Fund,1530.2009,Print,Prints & Illustrated Books,11-17-2009,Y,133106,http://www.moma.org/collection/works/133106

Row 110,558:
Untitled #139,José Antonio Suárez Londoño,"(Colombian, born 1955)",1997,Etching,"plate: 5 13/16 × 1 15/16"" (14.7 × 4.9 cm); sheet: 10 7/8 × 7 9/16"" (27.7 × 19.2 cm)",Gift of the artist through the Latin American and Caribbean Fund,1531.2009,Print,Prints & Illustrated Books,11-17-2009,Y,133107,http://www.moma.org/collection/works/133107

The last inconsistent artwork simply had the year 1941 without a month or day. While I understand that dates can be fuzzy in the art world (the date header in the CSV file testifies to that), every other record is very consistent. Personally, I made a change from 1941 to 1941-01-01 and I'll likely attach a note describing a possible missing date. Can we get the true date acquired?
Row 132,209:
Two Figures Seated Beside a Corpse,Cândido Portinari,"(Brazilian, 1903–1962)",1939,Lithograph,"Composition: 5 9/16 × 7 1/8"" (14.2 × 18.1 cm)",Gift of the Artist,352.1941,Print,Prints & Illustrated Books,1941,N,179107,

Thanks for letting us know. We'll look into getting the data changed at the source.


Color customization for TODO,DOING,LATER,WAITING,DONE,CANCELED and Priorities

Hello
Thanks for wonderful them, I really love it.
Is it possible to add coloring for TODO,DOING,LATER,WAITING,DONE,CANCELED and Priorities  ?
like for example todo -> blue, done -> green , waiting -> yellow  and customized priorities coloring

example used on dev theme

Coloring for priority
example used on dev theme

Yes, it can be done.

This what it looks like now,

Customisation will be added in future along with many other overrides under settings. For now you can override the variables using custom css.


Difference between Vertical Text and Rotated Text

@Haftmann commented on Tue Mar 26 2019
As I checked out, Vertical Text rotates Chinese Characters to be readable top-down (i.e. are placed non-rotated). However, Arabic text is in the same way rotated as English text, so readable from left, but from Bottom to top, as usual for that culture.
In opposite, Rotated Text rotates Chinese characters too.
To display text readable from right (typically for a left-side XY scale title), you have to rotate the text. For continuity, right-side scale titles should be created as Rotated Text, not as Vertical Text.
Furthermore, MeasureString() calculates bbox.Height as font height, which is at X direction here.

Dokumentdetails
⚠ Bearbeiten Sie diesen Abschnitt nicht. Er ist für die Verknüpfung von docs.microsoft.com zum GitHub-Artikel erforderlich.

ID: 97eff6cd-f6f5-4ad0-c4dd-9bdc8f2d9570
Version Independent ID: e0517c44-3597-2da1-b25d-220c962d4296
Content: Vorgehensweise: Erstellen von vertikalem Text
Content Source: docs/framework/winforms/advanced/how-to-create-vertical-text.md
Product: dotnet-framework
GitHub Login: @dotnet-bot
Microsoft Alias: dotnetcontent

Hi team,
I'm moving this here since the contributor is making a suggestion on the original documentation


Don't save the layout if it was centered only because of the zenmode

fixes #45610 creating the expected behavior for centered layout and zenmode.

Will have to close this due to the reasons specifyed in https://github.com/Microsoft/vscode/issues/45610


Removed ENABLE_BENCHMARK dependency on ENABLE_TESTS

Removed ENABLE_BENCHMARK's dependency on ENABLE_TESTS so that benchmarks may be created independent from what ENABLE_TESTS is set to.

The context is building Umpire, which has both correctness tests and performance benchmarks. These are conditionally built based on the ENABLE_TESTS and ENABLE_BENCHMARKS options.
I don’t know why benchmarks would need to depend on tests? It doesn’t make sense.

Thanks for the context @davidbeckingsale.
I think I set it up originally, and the best way I could find to automate running the benchmarks (when they were enabled) was through ctest using the custom "Benchmarks" configuration (in the run_benchmarks custom target).
I can see the rationale to separate the two e.g. to build the benchmarks and manually run them. The run_benchmarks target will likely need to depend on both ENABLE_TESTING and ENABLE_BENCHMARKS -- unless you have found a better way to do this.

Can you try the same thing but call “enable_testing()” somewhere?
Also, are our benchmarks using the add_benchmark macro - they might not be getting added to that target.

Our (umpire) benchmarks are calling blt_enable_benchmark().  make run_benchmarks does work if we run with -DENABLE_TESTS=On.

When I placed ‘enable_testing()’ inside of the CMakeLists.txt file within the benchmark/ folder of umpire, I still get the same result.  The ‘make run_benchmarks’ still does not find any tests.
From: David Beckingsale<EMAIL_ADDRESS>Reply-To: LLNL/blt<EMAIL_ADDRESS>Date: Thursday, March 22, 2018 at 2:09 PM
To: LLNL/blt<EMAIL_ADDRESS>Cc: "Mcfadden, Marty"<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [LLNL/blt] Removed ENABLE_BENCHMARK dependency on ENABLE_TESTS (#137)
Can you try the same thing but call “enable_testing()” somewhere?
Also, are our benchmarks using the add_benchmark macro - they might not be getting added to that target.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/LLNL/blt/pull/137#issuecomment-375458305, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGgY1WlfZf17uCV82stKTNnF1_-RZ9Dmks5thBL1gaJpZM4S011j.

It seems like the reported AppVeyor build failure 1.0.679 was not caused by my changes.  What is the preferred way of restarting an AppVeyor test?

@cyrush - can you restart the failed AppVeyor build?

@davidbeckingsale @mcfadden8 , just restarted appveyor.


Can't install on macOS

I get:
$ export GOPATH=$HOME/go
$ export GOBIN=$GOPATH/bin
$ mkdir -p $GOPATH
$ export PATH=$PATH:$GOBIN
$ go get -v github.com/mikepea/go-jira-ui/jira-ui
github.com/mikepea/go-jira-ui
# github.com/mikepea/go-jira-ui
go/src/github.com/mikepea/go-jira-ui/ui_controls.go:170:10: e.Data undefined (type termui.Event has no field or method Data)
go/src/github.com/mikepea/go-jira-ui/ui_controls.go:269:10: e.Data undefined (type termui.Event has no field or method Data)

System details:
macOS 10.14.1 running Go version go1.11.2 darwin/amd64.
Am I missing anything?
Thanks!

@mikepea, thanks for acknowledging this. I'm still experiencing the same issue when trying to install this even though you've pushed a commit to fix it. Is that expected at this stage?
Thank you.

Actually, never mind. I've deleted the local copy of this repository and was able to install. Thanks!


Cosmetics

3 pieces: DTZ = DTM
Better tooltips ...
Expand more moves ...

Decisions:
Keeping DTZ for low piece counts for consistency and maybe to teach the concept.
Tooltips improved.
Scrolling should be fine. Best moves are on top anyway.


toolchain: use proper binary operation for #if directive

"#if" directive expects usage of binary operations in "&&" format, not "and". Change it to fix build failure.
Fixes: "toolchain: do not use posix C code for asm language in gcc.h"

Acked-by: Volodymyr Babchuk<EMAIL_ADDRESS>


Use currentTarget for click handler event.

Happy Memorial Day!
This is related to item #88
Using currentTarget in the click handler over target ensures that even if other extensions change the DOM, we still get what we want.

Thanks 👍


Add code for review for best practices

Thanks for the review @obed300
I am a little confused about not using negative conditionals. I know they can make the code hard to understand sometimes, but in this case, I'm explicitly checking if the input.value is not empty. I think there is no better way to do this.
Can you please explain how can I avoid the negative conditional in this situation?