nightly-devel-gpu Docker broken with ImportError: libcuda.so.1: cannot open shared object file

To reproduce:
sudo docker run -it --name t2 tensorflow/tensorflow:nightly-devel-gpu
python -c "import tensorflow"
It's looking for libcuda.so.1, but I can't find that file in the image
Furthermore, LD_LIBRARY_PATH is pointing to /usr/local/nvidia/lib64 but there's no such folder. There's /usr/local/cuda/lib64, but no libcuda.so.1 there either (should it be loading libcudart.so.8.0 instead?)
cc @craigcitro

/cc @caisq

It has been 14 days with no activity and this issue has an assignee.Please update the label and/or status accordingly.

Nagging Assignee: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 242 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 257 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 272 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 287 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 302 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 317 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 332 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 347 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 362 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @caisq: It has been 377 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Can this be closed ?

Nagging Assignee @caisq: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Closing as the docker issue is resolved


Intersection PEP

PR relating to https://github.com/CarliJoy/intersection_examples/issues/48. Still some work to be done on this, but feel free anyone to have a review if you'd like @CarliJoy @erictraut @NeilGirdhar @gvanrossum @DiscordLiz @vergenzt . It builds a lot on the work of @mikeshardmind, but I've tried to thin it down a bit and add some more examples. It also approaches the problem from a slightly different angle conceptually, but the result is somewhat similar.
Broadly the main update I'm planning is to finish the intersect simulator and link it as the reference implementation (Proof of Concept I suppose), then we can move to opening a discussion related to the PEP on python discuss.
I'll also add something discussing the equivalence of Callable to certain Protocols and maybe add an example.
Finally, this issue is still outstanding: https://discuss.python.org/t/take-2-rules-for-subclassing-any/47981, but my hope is that this may not be critical to finalising the PEP. The behaviour as far as Intersection is concerned is now well defined under the PEP, and I'm thinking that if this proves to be a major issue perhaps it will arise during later discussion.

I've now updated to resolve the issues above - any comments please take a look. If there are no further comments, next week I'll read it over again, then open an issue on the discuss forum for a draft PEP.
The main thing I think this might be missing is potentially some of the rejected ideas (as there were many!), but I've tried to summarise any major ones.
As far as I know, the implementation and specification are complete in that it seems to resolve all outstanding issues I'm aware of - if there's anything I've missed here please let me know.
Quite excited to think we may actually have a fully fledged specification - getting there!

This approach has the same flaw with __getattr__ that the prior did, it's just hidden differently. You'll want to explore the test case that led to the prior approach falling apart: https://github.com/python/typing/pull/1672#discussion_r1550639648
@ mikeshardmind had a simple formulation that still works with Any, but based on his most recent messages here, it seems like he's not going to advocate for the simpler option remaining. As I understand it, he'd rather intersections not be added until the underlying issues are resolved.

A :> Intersection[T1, T2, ... Tn] if and only if A :> T1 and A :> T2 .... and A :>Tn
A <: Intersection[T1, T2, ... Tn] if and only if A <: T1 and A <: T2 .... and A <:Tn

That's the entire definition of what can and can't be inferred from an intersection expressed in 2 short lines describing subtyping and supertyping relationships. He didn't like the implications of trying to combine this with a bad definition of Any and tried to work around that. It being independent of the definition of Any and having no special casing might mean we can ignore Any having a bad definition and just get something that works for most people. If it doesn't work for someone, they can pick up improving the definition of Any from the case where it doesn't work.

@DiscordLiz I added this section: https://github.com/CarliJoy/intersection_examples/blob/intersection-pep-new/docs/specification.rst#any-subclassing-rules
to try and resolve this. Broadly my thought it that by relaxing the inheritance restriction on Any by making it a structural type, it doesn't matter if Intersection diverges from the way subclassing with Any currently works. There is a potential ambiguity in the way that methods with __getattr__ and things that inherit from Any work, but by considering A and B below as different types we go around this issue:
class A:
    foo: str = "foo"

class C(Any, A):
    pass

D: Intersection[Any, A]

There nothing to say that objects of type C and D above have to behave in exactly the same way. D has all attributes as Any and must inherit from A, while C inherits from A and has all attributes as Any except foo which is str. In this case C is a subtype of D, but D is not a subtype of C.

There is a potential ambiguity in the way that methods with getattr and things that inherit from Any work, but by considering C and D below as different types we go around this issue:

We were always considering an intersection as different to a specific class declaration. Simply saying we do this doesn't solve the problems that were raised around this.
I don't know how to explain this any better, you're still conflating parts of the type system that should not be conflated after multiple explanations throughout the discussions, and it seems to be having an impact on what you are writing ending up missing the problem. Maybe someone else can explain better.
What type checkers need are the subtyping rules. I have seen no indication that the extra complexity you have here solves any problems. It does creates new ones, treating Any as a structural type rather than Any means you need to define it's behavior as a structural type without breaking any more fundamental rule and having a decidable interface and rules for how type checkers address that in an intersection. You have not provided those things.
The focus on splitting inheritance and structural types has you missing the more fundamental rule that both must abide by. Both of these imply rules for subtyping relationships. It would be better to focus on a consistent subtyping relationship that does not try to treat either of these differently. You can refer to my last post for the minimal relationships to define an intersection. I think any proposal that does not use these needs to show definitively why it behaves better. The prior attempt did not actually behave better than those, and was abandoned.
You also retained a section on ordering, but intersections don't have to be ordered at all, that was a synthetic requirement of the previous attempt that we showed definitively doesn't solve the problem, it's unclear why you've retained this as none of the new language resolves those issues either.

I don't know how to explain this any better, you're still conflating parts of the type system that should not be conflated after multiple explanations throughout the discussions, and it seems to be having an impact on what you are writing ending up missing the problem. Maybe someone else can explain better.

@DiscordLiz Apologies, I am trying to understand this - what parts of the type system am I conflating?

What type checkers need are the subtyping rules. I have seen no indication that the extra complexity you have here solves any problems.

Broadly, I'm trying to define a set of rules that would be easy to implement for type checkers. I think the sets of rules you define here:

A :> Intersection[T1, T2, ... Tn] if and only if A :> T1 and A :> T2 .... and A :>Tn
A <: Intersection[T1, T2, ... Tn] if and only if A <: T1 and A <: T2 .... and A <:Tn

...are not in conflict with the specification, but I think they don't cover all situations. We've discussed before non-LSP violating method clashes that can occur, and these rules don't really show how to resolve that.

The focus on splitting inheritance and structural types has you missing the more fundamental rule that both must abide by. Both of these imply rules for subtyping relationships.

This is true - I'm really trying to break down what it means to be a subtype into rules that will be easier to implement, and resolve unspecified cases at the same time. Also, I think the statement about Any being a structural type may already be effectively present. Suppose we had:
class A:
    def foo(self):
        pass

def test(x: T) -> Intersection[A, T]:
    class New(type(x), A):
        pass
    return New()

class B:
    def bar(self):
         pass

b: Any = B()

x = test(b) # Intersection[Any, A]

So here we have created an Any intersection, as let's say B was an unknown type.
Based on the ruleset:
A subtype of x must be a subtype of A and a subtype of Any
Subtype of A
A subtype of A, must inherit from A and have attribute foo.
Subtype of Any
A subtype of Any, must inherit from Any and have all attributes as Any
Now here we have an issue - B does not inherit from Any, and neither does x. My point is that subtypes of Any do not have the inheritance restriction, so it seems it's already been defined as a structural type.
If there is a PEP somewhere I've missed that lays out what it means to be a subtype I'd be interested to read it.

You also retained a section on ordering, but intersections don't have to be ordered at all, that was a synthetic requirement of the previous attempt that we showed definitively doesn't solve the problem, it's unclear why you've retained this as none of the new language resolves those issues either.

I've summarised a few of the issues the ordered nature resolves:
https://github.com/CarliJoy/intersection_examples/blob/intersection-pep-new/docs/specification.rst#ordering

we showed definitively doesn't solve the problem

Could you point me to this? I know there was discussion about the issue with __getattr__ and Any, but there are other advantages to it being ordered.

Could you point me to this? I know there was discussion about the issue with getattr and Any, but there are other advantages to it being ordered.

Type information is used for more than just static type checking. It’s also used for runtime type checking and for edit-time features like completion suggestions and signature help. For every Python developer who uses pyright for static type checking, there are 40x as many developers who do not use static type checking but rely on static type evaluation for language server features. These developers are more likely to be using untyped or partially-typed code, so they will more often hit the case where a class has an unknown base class. If we were to change the spec to treat all methods and attributes of such a class as Any, it would significantly harm their user experience — enough so that I don’t think I could justify making such a change in pyright regardless of what the typing spec says.

From a message explaining why a spec that just turns everything into Any in such types would be harmful to users: https://discuss.python.org/t/take-2-rules-for-subclassing-any/47981/5
It's also not even correct to do so.
class A:
    foo: int

B = Any

C = Intersection[B, A]

C().foo  # int

The ordering was only ever a bad compromise, and the reason Any was shuffled to the end in the attempt at that was to specifically avoid this issue. foo here can't be Any, as any type that isn't int would have been a type error.

The focus on splitting inheritance and structural types has you missing the more fundamental rule that both must abide by. Both of these imply rules for subtyping relationships.

This is true - I'm really trying to break down what it means to be a subtype into rules that will be easier to implement, and resolve unspecified cases at the same time. Also, I think the statement about Any being a structural type may already be effectively present.

Any isn't a structural type. It's a concept that says "some compatible type is present here". I cannot stress enough how important the different between a higher order concept to express an uknown is different from a structural type that expresses a structure.
Casting to and from Any is a free operation that doesn't require an explicit cast or checking, the type system assumes compatibility as that's the purpose.
You don't have to break this down into "Easier to implement", type checkers already need to have the facilities to handle subtyping relationships, and doing so is causing important things to be gotten wrong, not all simplifications preserve the truth.

Does this have to be the case? I don't see why c.foo couldn't be Any here, e.g.:

Any allows more than int, this is an unsafe widening of the type and should not be done by the type system. If C is a subtype of A, then C.foo can't not be compatible with int. Any is special. It's compatible but the way it is compatible is a problem to do this kind of transformation with in a way that looses known type information, becase now from the type system perspective, you're allowed to assign anything to it, even things which break the rules for A

I want to avoid retreading too much ground here, but with a simple modification:
class A:
    def __init__(self, x: int) -> None:
        pass

B = Any

C: type[Intersection[B, A]] = ...
c: Intersection[B, A] = C()

c.foo  # int

If C is a subtype of A, then C.foo can't not be compatible with int.

This statement applies in the case I originally gave, but in the case above that doesn't necessarily apply (As __init__ can take any form). By making the Intersection ordered we could just make the one with the defined __init__ take priority by switching A and B, so the issue goes away.

Any allows more than int, this is an unsafe widening of the type and should not be done by the type system

The ordering effectively shifts the responsibility to the user to make sure they don't create effects like this unless that's what they want to do. If the result should always have an attribute foo of type int, then that means this was a mistake, and the order should be the other way around. It shifts responsibility but it also shifts control to the user.

The ordering effectively shifts the responsibility to the user to make sure they don't create effects like this unless that's what they want to do.

We established we can't ban Any from intersections because the user might not have control over where they come in (typevars) The user does not have that capability to avoid this problem. The prior ordered form avoided this by moving Any last, always, but that was flawed. You're doing something far worse with this, leaving a loaded gun pointed all all users of gradual typing.

You're doing something far worse with this, leaving a loaded gun pointed all all users of gradual typing.

Is there a particular use case you're imagining here that would negatively impact these users? I've thought about quite a few different ways this could be used, but so far haven't found anything drastic - I'd be interested to know if there's something I haven't considered.

Is there a particular use case you're imagining here that would negatively impact these users? I've thought about quite a few different ways this could be used, but so far haven't found anything drastic - I'd be interested to know if there's something I haven't considered.

Returning an intersection to a user, as in mixins and class decorators, the only cases we have for intersection that can't already be solved with just protocols.

I think this should be required reading for anyone working on this, as it is another language with gradual typing adding a full type system. https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradual-typing/, running into the same problems we have with Any (with Elixir's dynamic), and finding solutions that preserve useful types for users.

@mikeshardmind Thanks, I'll have a read

It is possible to reduce typechecker complexity to remain linear rather than polynomial here without introducing an ordering or giving up on the subtyping-based outcome, it's just going to be more complicated to work on. That benefit was not unique to having an ordering, it was just more obviously available as an easy optimization that could be made if the ordering was sound.

I can see that there might be a way to resolve an unordered intersection in linear time, but the simplicity of implementing an ordered intersection is still there.
As you noted in your closing points though the __init__ clashes are still an issue, and currently only solved by ordered intersection. I also have a feeling that there will be lots of code that features LSP violations, as this is quite a new feature, so it might be handy to be able to support these too.

Callable signatures should not be reduced either. (int) -> int & (str) -> str should be left as-is, then you only need rules for evaluating if a function signature is compatible with each (again, a logical and)

We're also back to this whole thing of evaluating when Callables are compatible, which may be not trivial. Secondly, I'm not sure how this intersection of callables would be implemented, we end up back at how to generate overloads when merging classes.

The ordering isn't sound.

As far as I can tell there's a whole heap of issues that get solved with ordering, and the problems it creates seem pretty minimal. At least, I haven't seen any compelling examples against it.

We're also back to evaluating when Callables are compatible, which may be not trivial. Secondly, I'm not sure how this intersection of callables would be implemented, we end up back at how to generate overloads when merging classes.

It's simple, and in trying to map this to overloads we (myself included) made it more complicated than it needs to be.

Don't generate overloads, they can't be equivalent in the absence of type negation.
For each callable in the intersection, individually check compatibility (Already something type checkers need to be able to do)
If any fail, it's not compatible.
Optionally short circuit on first failure (type checker choice, this is performance vs error message not correctness)

As far as I can tell there's a whole heap of issues that get solved with ordering, and the problems it creates seem pretty minimal. At least, I haven't seen any compelling examples against it.

I don't mean to be rude here, but the entire reason why there was such a long discussion on Any & T, as well as why the attempt to come up with a clever way to hide the problem with reordering Any before, were the problems with this. There's no way to discuss this without leaving out prior nuanced arguments or feeling like we're rehashing ground that I imagine people are tired of rehashing as I certainly am.
There are multiple reasons, and I'm not going to rehash all and the rationale of each or provide specific cases

In the face of known type information, erasing it as Any erases things that people expect the type system to know about and check for them, so this harms people using this for static analysis. (detectable False negatives on typed code)
The majority of users of typing are not writing types, but language server users. Having type information vanish in an intersection harms language servers providing accurate completion hints, so this harms those who do not have strong knowledge about typing and are indirect consumers of it.
Widening to Any without a user explicitly doing so is theoretically unsound, so this harms all future attempts to improve the soundness and expressiveness of the type system.

The only group not negatively impacted by this would be the people who do not use typing at all, and I'm not even sure that's true, as they may end up with worse libraries they use, but don't use the typings of, especially if library authors have to do gymnastics to make this work how they expect it to.
The only benefit to this appears to be making it easier to implement. While making something easier to implement is usually a laudable goal, care must be taken to ensure that it does not consume the usefulness of what is being implemented.
I can understand wanting to have something to show for this and get it done, but getting this wrong could be disastrous with how many things this has the potential to interact with. Other than HKTs, this is probably the single most complex thing that is being seriously proposed for python's type system. It's not an easy task to make sure everything we have to consider is being given proper weight.
With all of that said, I don't want to say any of this and leave you without a way forward either, so....
I think there are only 3 paths forward that remain viable right now, but if you find another we can certainly discuss it.

Go with a strict subtyping-based rule. (@DiscordLiz provided the necessary rules above, there are a couple of corollaries from it that may be useful to type checkers, some of which can be found in #22 )
Improve on the surrounding parts of the type system, then come back to this with an easier-to-work-with foundation.
Have intersections only work for disjoint types for now (This implies either constraining Any or banning Any) and revisit extending what is allowed with the benefit of seeing what people still have use cases for beyond this.

My opinion is that while any of those 3 would be fine,

would have the strongest immediate benefit to users without compromising on important issues
would be the best longterm outcome, but could push this into something that never gets worked on because it feels like there is an insurmountable barrier to contribution.
would be easy to be correct, but would be very limiting on typevariable use if users can't denote certain requirements

@mikeshardmind Thanks for breaking this down, appreciate it. So I'll park the discussion about Any for now - although I don't understand why expanding to Any where more information is available is so critical, I can accept that this may be a requirement.
The path forward I'm not sure I understand why it was rejected is the one you were proposing in the previous PEP edition (where Any is the lowest priority). I appreciate the __getattr__ case might present an issue, but I did have another thought which is based on the idea of a "fallback".
Based on certain conditions, if Any is present in a intersection Any becomes the "fallback" which is used when all other objects in the intersection do not have the required attribute. There might be another situation where the __getattr__ return type is the "fallback" (which takes priority would be determined by the desired outcome).

As you noted in your closing points though the __init__ clashes are still an issue, and currently only solved by ordered intersection.

Also, I'm still not sure how this could be resolved in an unordered intersection, which is why I'm keen to resolve issues with the ordered one. Banning an intersection with clashing __init__ would be one way to go, but I have a feeling this would lead to many more issues. This reason alone I think is quite compelling, all others aside.

The path forward I'm not sure I understand why it was rejected is the one you were proposing in the previous PEP edition (where Any is the lowest priority). I appreciate the getattr case might present an issue, but I did have another thought which is based on the idea of a "fallback".

I determined that getting the special casing right on this would be harder and more fragile than it was worth. (specifically, it would be harder than getting the full theory-drive intersection correct, while keeping it useful to a wide audience, while having issues of fragility)
Every level of special casing needed here makes it more and more complex, harder to reason about, and more sensitive to other changes/additions to the type system. The moment it was shown that simply re-ordering Any to the end was insufficient, any additional layered special casing was more complex than just doing it "right", the ordering was meant as a means to approximate the same behavior without needing as much to be specified to simplify things and it stopped being simpler as we discovered more issues, which I took as a sign (for myself) to take a break and come back to it later.

As you noted in your closing points though the __init__ clashes are still an issue, and currently only solved by ordered intersection.

Also, I'm still not sure how this could be resolved in an unordered intersection, which is why I'm keen to resolve issues with the ordered one. Banning an intersection with clashing __init__ would be one way to go, but I have a feeling this would lead to many more issues. This reason alone I think is quite compelling, all others aside.

clashes of constructors (__init__, (metaclass) __call__, and (metaclass) __new__) are already special-cased (much to my disappointment), so a special case around this, in particular, is unnecessary, and would already be covered by the existing ones for subtyping rules. While I'm disappointed in the special casing, it's very too late to undo that, and recent improvements to the specification on this do manage to avoid most issues and I think it's nearing a pragmatic enough point as to be a non-issue.

I determined that getting the special casing right on this would be harder and more fragile than it was worth. (specifically, it would be harder than getting the full theory-drive intersection correct while keeping it useful to a wide audience, and would have issues of fragility)

@mikeshardmind I see, that makes sense, but I'm not sure I agree.

Every level of special casing needed here makes it more and more complex, harder to reason about, and more sensitive to other changes/additions to the type system. The moment it was shown that simply re-ordering Any to the end was insufficient, any additional layered special casing was more complex than just doing it "right", the ordering was meant as a means to approximate the same behavior without needing as much to be specified to simplify things and it stopped being simpler as we discovered more issues, which I took as a sign (for myself) to take a break and come back to it later.

The way I see it, there are really only two special cases we've identified so far for an ordered intersection: Any, and __getattr__. If there are many more of these that arise, then I think I agree, but this doesn't seem like a dealbreaker for it as things stand (__init__ doesn't need to be a special case in ordered intersection).
If we look at the special cases for unordered intersection on the other hand, there are many: Any, signatures for __init__, __call__, __new__, Callables (although there is now a defined logic for resolving this above), other non-LSP violating methods of same name (I imagine this would resolve similarly). Some of these special cases may have existing logic in python to handle them, but that still makes it a much more complex specification. What's more, I believe __getattr__ would still end up being a special case in an unordered intersection, it'd just be get handled differently.
Special cases will arise in any specification like this, but the ordered version seems to have fewer and is easier to explain the logic for, as for any conflict there is a default way to resolve it. In the unordered version, everytime two classes "compete" for the same attribute or method, a resolution method has to be determined, so by it's nature it must be more complex to specify.

I also think it's worth noting that waiting for a lot of pre-requisites to be resolved internally is quite unrealistic. Even if right now all of the pre-requisites appear on a TODO list, any one of these could be delayed, and it's unlikely all of them will come to fruition. This is a tool that I personally think could be very useful, and we're incredibly close to a specification that would be implementable. It seems a shame to me to park the discussion for a future point that will in all likelihood never happen.

Ok, let's suppose we go with option 1 with the subtyping rules. If something is a subtype of T & Any it must be a subtype of T and a subtype of Any. We're still back to the old 4 vs 5 debate from a few months ago, on if an attribute of the irreducible quantity can be said to follow type T if it's present on T. Which means we're kind of back to square 1.

If intersections got accepted with ordering rather than with either purely subtyping (possible now) or with denotable lower and upper bounds and constraints (would require groundwork), I think it would create a situation where HKTs would be impossible to support properly, and that's a gigantic detriment. HKTs are significantly more important to people than intersections are, they are also just more complex and not as easy to tackle in the current landscape.

This is interesting. HKTs would be cool - is there any possibility of this happening in reality though? If there is and an ordered intersection presents a blocker (although I don't see why) then that is something to consider. I guess my follow up is why does it present a blocker?
My main reasoning is that if the only real blocker to an ordered intersection is that __getattr__ becomes a special case, that's not much of an argument when the alternative is trying to resolve attributes of T & Any which may be unresolvable.
I also still don't really understand why __getattr__ isn't a special case for unordered too - with ordered we were saying that the ordering priority may be reversed in some cases with this attribute, but with unordered we still need to define which item in the intersection takes priority. E.g.
from typing import Any, cast

class A:
    def __getattr__(self, item: str) -> int:
        return 1

B = Any

class C:
    foo: str

x= cast(A & B & C, type("D",(B,A,C),{})())
x.foo # str I suppose
x.bar # What type goes here?

It was my intent to after taking some more time for myself, to dig into this vs explicit denotable lower and upper type bounds, I still intend on that at some later point, but we painted ourselves into a corner we didn't need to with some of the original discussions, and looking elsewhere for answers and perspective on why certain attempts at simplification were misguided and where they fell short of making things simpler has helped

If something is a subtype of T & Any it must be a subtype of T and a subtype of Any. We're still back to the old 4 vs 5 debate from a few months ago, on if an attribute of the irreducible quantity can be said to follow type T if it's present on T. Which means we're kind of back to square 1.

This, just like callable is simpler than we made because we were looking at it through the wrong lens at the time. The thing I linked about how Elixir is solving this is very illuminating as to how we framed the discussion made finding a solution harder than it should have been. We were working under the assumption that we must provide a single resulting type and that that type itself could not be an intersection, but there's no actual rule that that be the case.
It's irreducible in most cases, and that includes the attributes. But that makes things Easier not harder if context is preserved properly.
A.foo & B.foo can't get resolved to a single non-intersection type unless A.foo and B.foo are trivally overlapping (ie A.foo is exactly B.foo) or only one of A.foo and B.foo exist.
When using x.foo where x is a subtype of A & B, x.foo's use must be consistent with both A.foo and B.foo
When assigning to x.foo, the assignment must be consistent with assignment to A.foo and B.foo
This preserves both what those in favor of 4 wanted (a wider upper bound due to the presence of Any) and preserving the lower bound provided by any known specific type. It's also significantly simpler to implement as it doesn't require a polynomial algorithm in the case of resolving certain types, and instead only a linear one at each usage.

I also still don't really understand why __getattr__ isn't a special case for unordered too - with ordered we were saying that the ordering priority may be reversed in some cases with this attribute, but with unordered we still need to define which item in the intersection takes priority. E.g.

Because the rules for __getattr__ will continue to work as they already do. It is already a special case, but its specialness is currently only acknowledging how attribute access works in python to match the data model, and we'd avoid adding another special case for it that behaves slightly differently.
We keep the existing rules for when __getattr__ is used, and any updates to those in the specification at any later point just work, without having to consider intersections again to ever improve that.

This is interesting. HKTs would be cool - is there any possibility of this happening in reality though?

Continues to be brought up with varying interest, it's significantly more likely with the new type alias syntax and type variable defaults, as the applications are more accessible and natural to more developers, and it's been stated as a priority for a few people heavily involved in python's typing. I'd say that yes, there's a real possibility of this happening.

If there is and an ordered intersection presents a blocker (although I don't see why) then that is something to consider. I guess my follow up is why does it present a blocker?

I really don't want to try and work through an example of this right now, there's still a lot of unknowns. I forsee an issue with each an intersection of higher kinded types, and with intersections within higher kinded types if the behavior is inconsistent with other subtyping.
I can't definitely say that this would be unresolvable for HKTs, but I can definitively say that every special case that exists will increase complexity of HKTs and that any single one of those cases could potentially be the straw that was too much. There's too many unknowns with it right now, and it hasn't been explored enough to know. I'm taking the pragmatic stance that if we don't need new special cases, we should do it without them to reduce the number of things that don't "simply work" together.


Add RequiredJsonBody/OptionalJsonBody once we implement the JSON support

this is exactly what i was looking for, thanks!

You're welcome @keeth! If you're using 0.3.0 version you can take a look at this docs section. If you're using 0.4.0-SNAPSHOT, please have a look at the demo example that reads JSON object from the HTTP request using the new API (RequiredJsonBody[Json] -> RequiredBody[Json]).

I should make a PR to change the docs :P

Don't worry @pasviegas! I will clean up the docs before 0.4.0 release. It's ok to have the docs for 0.3.0 version for now, since people use it by default.

Cool, if you need any help :)

Thanks @vkostyukov I am on 0.3 and my endpoint looks like this (my model is a case class called Hint):
def route = {
    case Method.Post -> Root / "hints" => new Service[HttpRequest, HttpResponse] {
      def apply(req: HttpRequest) = for {
        hint <- RequiredJsonBody[Hint](req)
        _ <- hintRepository.save(hint)
      } yield Ok(hint.asJson)
    }
}

I looked in vain for a documented example of *JsonBody, since it is different from the *Param ones, but I got it working anyway.
I really appreciated your demo example Main.scala.. I wouldn't have been able to get started on Finch without it (I am new to both Scala and Finagle).

I'm glad it works for you @keeth! Feel free to ask any questions or for advices either here or on Gitter page: https://gitter.im/finagle/finch.


link not rendered properly

Hi
I am using Facets Dive in Jupyter Notebook, want to display a link on the right panel. I set one of the field value as
img_path= "image"
expect to see a link, but saw this displayed
img_path
image
Thanks
Dong

Hi Dong,
Yes, HTML and/or URLs are not rendered in the info card by default. However, you could implement a custom infoRenderer() method to do this. This is described in the documentation on advanced customization properties.
I'm not sure how you'd do this in a Jupyter notebook, but it requires a little custom JavaScript. Something like this (untested code):
function yourInfoRenderer(dataObject, elem) {
  elem.innerHTML = dataObject.img_path;
}

const dive = document.querySelector('facets-dive')[0];
dive.infoRenderer = yourInfoRenderer;

You can see how the default info renderer is implemented in the file info-renderers.ts.

got it working, thanks!

Awesome, thanks for letting us know!


I guess smth is wrong with initial setup for VS Code

[Enter feedback here]
I can not run the wep api app from VS Code by clicking Ctrl+F5 neither dotnet build command from the terminal.
It throws error about missing dev certificate or smth similar to it, although I had run previously dotnet dev-certs https --trust

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

ID: 583ae3e7-5915-f22b-e54c-6c100cf2a7da
Version Independent ID: 95f2549e-29f9-e31a-b4d0-432b971643ff
Content: Tutorial: Create a web API with ASP.NET Core
Content Source: aspnetcore/tutorials/first-web-api.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

ok. my bad. I had old certificate on my windows and VS code used it. Strange is that dotnet dev-certs --clean didn't removed it. Closing.

@YaroslV  that's interesting  Does https://github.com/dotnet/aspnetcore/issues/15357#issuecomment-555782605 help?

@YaroslV  https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-3.0&tabs=visual-studio#windows---certificate-not-trusted has the answer


Invoke the OTARequestor logic from the chip task context

Problem
Calls into the core CHIP functionality from OTARequestor APIs are not done in the context of the CHIP task on the platforms that use FreeRTOS; CHIP logic should only be invoked from the context of the CHIP task. For example, writing the UpdateState attribute in OTARequestor::Init() is not done in the context of the chip task on the platforms that use FreeRTOS. Detailed discussion: https://csamembers.slack.com/archives/G014G30SVV0/p1644588487457649
Proposed Solution
Investigate whether it is possible for the OTARequestor APIs to internally schedule the actual work through PlatformMgr::ScheduleWork() or a similar method -- and if so, implement this fix. If the above is not possible, ensure that all the platforms schedule OTARequestor API calls from the correct context.

On FreeRTOS the other option is to take the Matter lock around the relevant calls.


ValueError: messages.PushNotification cannot be assembled as data has not been provided

        android_config = client.build_android_config(
            priority="high",
            ttl=2419200,
            collapse_key="push",
            data={"discount": "15%", "key_1": "value_1", "timestamp": "2021-02-24T12:00:15"},
            title="Store Changes",
            body="Recent store changes",
        )

        result = await client.push_multicast(device_tokens=tokens, android=android_config)

get these error
File ~/Code/chat_python_lib/chat_python_lib/chat/firebase.py:66, in AsyncGoogleMessageClient.send_message(cls, data, notification, tokens)
     50 message = client.build_android_config(
     51     data=data,
     52     title="WOMO",
   (...)
     55     click_action="FLUTTER_NOTIFICATION_CLICK",
     56 )
     57 android_config = client.build_android_config(
     58     priority="high",
     59     ttl=2419200,
   (...)
     63     body="Recent store changes",
     64 )
---> 66 result = await client.push_multicast(device_tokens=tokens, android=android_config)
     67 return result

File ~/Code/chat_python_lib/.venv/lib64/python3.8/site-packages/async_firebase/client.py:445, in AsyncFirebaseClient.push_multicast(self, device_tokens, android, apns, data, notification, webpush, dry_run)
    431     raise ValueError(
    432         f"A single ``messages.MulticastMessage`` may contain up to {MULTICAST_MESSAGE_MAX_DEVICE_TOKENS} "
    433         "device tokens."
    434     )
    436 message = MulticastMessage(
    437     tokens=device_tokens,
    438     data=data or {},
   (...)
    442     apns=apns,
    443 )
--> 445 push_notification = self.assemble_push_notification(apns_config=apns, dry_run=dry_run, message=message)
    446 response = await self._send_request(push_notification)
    447 return response.json()

File ~/Code/chat_python_lib/.venv/lib64/python3.8/site-packages/async_firebase/client.py:96, in AsyncFirebaseClient.assemble_push_notification(apns_config, message, dry_run)
     94 if len(push_notification["message"]) == 1:
     95     logging.warning("No data has been provided to construct push notification payload")
---> 96     raise ValueError("``messages.PushNotification`` cannot be assembled as data has not been provided")
     97 return push_notification

ValueError: ``messages.PushNotification`` cannot be assembled as data has not been provided

because of tokens is []


Verified Filter for Extensions

Doesn't look like there is a 'Verified' filter for the Extensions search.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Actually attempt to maintain min_idle idle connections

Prior to this commit new connections would only be estalbished to
maintain min_idle when the pool is first initialized, or when a broken
connection is returned to the pool.
This commit additionally tries to maintain min_idle connections when a
connection is taken out of the pool.

Thanks!

Ah, looks like it needs a rebase, but LGTM otherwise.

Done


Document PolicyEngine & Config to advertise Static Routes

Issue Description
https://github.com/facebook/openr/commit/77040d2946d9cd92aa701501d058fe194385f630 removed LinkMonitor CLI argument for redistributing static routes.
We should document how to do this with config.
Minimal test code / Steps to reproduce the issue

Pass the arg and it does not work

What's the expected result?
Have a documented way that works for OpenR Users to share static routes.

FYI, we're moving away from gflags and all functionality is now being supported by OpenrConfig. The documentation exists in the OpenrConfig.thrift. For this specific case you would like to populate AreaConfig.redistribute_interfaces field - https://github.com/facebook/openr/blob/master/openr/if/OpenrConfig.thrift#L317

As a matter of caution, do not use any gflags for config instead specify them explicitly in the OpenrConfig. In next few weeks most gflags will be deprecated -- Aim is to have following as the start command
/bin/openr --config=/etc/sysconfig/openr.conf

Oh and for advertising static routes such as ::/0, you can use route origination feature through configuration. It should be working for simple use-case of static route advertisement, however the feature is still in progress - https://github.com/facebook/openr/blob/master/openr/if/OpenrConfig.thrift#L489

Closing as this has been resolved.


chore(dependencies): update tower-service to 0.3

This unblocks some work that I'm doing in tracing where I'm updating tracing-tower to the versions that use std::future::Future.

@seanmonstar Fixed!

Rebased again; had to push due to Travis breaking out of nowhere.

Huh, Travis is failing with:
$ cd davidbarsky/hyper

$ git checkout -qf c5b79cae31b40dabb97d2c1b3e091bf84ee9ba3e

fatal: reference is not a tree: c5b79cae31b40dabb97d2c1b3e091bf84ee9ba3e

The command "git checkout -qf c5b79cae31b40dabb97d2c1b3e091bf84ee9ba3e" failed and exited with 128 during .


Improving Cartoonify Images GUI

Is your feature request related to a problem? Please describe.
Improving the GUI from using Tkinter to Dearpygui
Describe the solution you'd like
Using Tkinter for GUI is not very visually appealing, so I am thinking of using dearpygui to change the GUI modification

Sure assigning you


[Service Bus] Observe peek behaviour to make design decisions

Attempt to peek a particular session that is known to be locked by a different receiver.
To Do -

Send many messages to a sessionful entity with the same session-id
With a session receiver, stream the messages which would mean the session is locked, then peek into the entity.
Case 1. In parallel, with a normal receiver, peek into the same entity
Case 2. In parallel, with a session receiver, peek into the same entity

Do, the exercise with track 1 and track 2 libraries.
Based on the observations, decide on generic peek's existence and the place to put it under.

From a terminology perspective - "Generic peek" here is "peek the queue/subscription without needing to acquire a session lock", right?

"Generic peek" here is "peek the queue/subscription without needing to acquire a session lock", right?

yes.

We are currently not exploring peeking without getting a session lock when working with queues/subscriptions with sessions enabled. Based on the feedback from the service, this would not be a reliable way to get the right information.


4.1.x Backport: Fix ORT parent orders to be deterministic

Backported from Github #5048

I think this will incorrectly sort these values that should already be sorted by ParentInfoSortByRank. Maybe that function needs more sort specificity?
Fixed


remove span from custom select

Bug Description
the custom select component wraps every select item inside an span preventing full width
Reproduction
create a custom select component
try to set the select item as w-full
Expected behavior
no style inference from the select item component
Who can help?
No response
Operating System
mac os
Langflow Version
1.0.18
Python Version
3.12
Screenshot
No response
Flow File
No response

@anovazzi1 please share the slow with screen shoot. It will be helpful.


Mentor Table Queue

Create a queue for mentoring at the event that people can enter when they need mentoring.
Probably use Amplify to build an AppSync API that can hold the queue.
We also want a portal where mentors can access the queue and remove people from the queue.

honestly this isn't really needed and we won't be moving forwards with this


chore(build): Use AWS ECR binfmt image mirror for QEMU setup

Description
Set up QEMU github action pulls docker.io/tonistiigi/binfmt:latest under the hood. Due to frequent docker pull requests it might lead to toomanyrequests error and hence flaky CI run (example failed Build / build-and-push-main ). Switching to AWS ECR image registry should allow pulling images more often
User-facing documentation

[ ] CHANGELOG is updated OR update is not needed
[ ] documentation PR is created and is linked above OR is not needed

Testing and quality

[ ] the change is production ready: the change is GA or otherwise the functionality is gated by a feature flag
[ ] CI results are inspected

Automated testing

[ ] added unit tests
[ ] added e2e tests
[ ] added regression tests
[ ] added compatibility tests
[ ] modified existing tests

How I validated my change

N/A

/retest


Instructions on how to get Authorization token for using the APIs

Is your feature request related to a problem? Please describe.
To call the REST API's the Authorization header is required but there are not instructions on how to obtain the Authorization token from an external service application rather than a registered user in the app.
Describe the solution you'd like
Ideally it would be great if we can generate API tokens within the interface to use with APIs
Describe alternatives you've considered
I can think of creating file/folder watching scripts to pipe data into the R2R ecosystem as they appear.
Additional context
Provide Machine2Machine integration support or integration with external workflow & orchestration frameworks.

Hey @emahpour you can get the auth token by calling the "login" endpoint. The SDKs will automatically apply this to all requests, for your convenience.
Can you expand on Machine2Machine integration support? Not sure I follow there.

Thanks for the prompt response. by M2M I mean service to service where it does not require a UI interaction. I guess you answered my question by using /login endpoint. I can try it and let you know if I had any issues.
Thanks!


add meQuilibrium to list of mental health apps

I'm not entirely sure where to find the app for personal use. Is it a service that can't be used by an individual?


Upgrade to SendGrid v3 Web API

https://sendgrid.com/docs/Classroom/Send/v3_Mail_Send/how_to_migrate_from_v2_to_v3_mail_send.html
https://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/index.html
Thanks!

There is a new Android SendGrid library utilising Sendgrid's v3 API.
The updated library negates the issues when implementing older libraries into applications that target newer Android API version.
The library can be imported with maven central
implementation 'uk.co.jakebreen:android-sendgrid:1.0.0'
https://github.com/Jakebreen/android-sendgrid


Disable translations keys nesting

Is your feature request related to a problem? Please describe.
I wanted to migrate from lingui.js and currently I really like using flat messages (instead of creating translations keys, I just use the whole translation text).
e.g.
Instead of t('card.title') i would have t('Welcome to my website. This is a subtitle') (written in the default language) so that I don't have to spend time on making translations keys.
I tried but it gave me an error because the '.' is used for nesting.
Describe the solution you'd like
Would it be possible to have a flag to disable this behavior?
I'm really loving using next-intl so it would be amazing to have also this small feature. Unfortunately it's the last thing that's "blocking" me to migrate all over to next-intl.
Describe alternatives you've considered
I haven't any other solution than using translation keys but I would really like to continue with "explicit" translations.

I looked a bit into the code and I have seen that making a change of "disabling nesting" is too much of refactoring, but i may have found a solution that could cover any case.
Introducing a "nested char" or "nested divider" or whatever we can call it, that replaces the checks, splitting and everything of '.' with that config param (with default '.') so that for my use case I could just pass a param like nestedChar="-----" and it would never split the key and I would be able to have a flat structure.
If you think this is something you would like to support I could also create a PR to help you with most of the work.
It's sad because I'm loving next-intl and its simplicity but I would also really like to have a flat structure 🥲

Hmm, the . separator is currently not supported in message keys also due to the TypeScript integration, where the separator can unfortunately not be customized.
This was also discussed in https://github.com/amannn/next-intl/issues/105 before.

@amannn I see the problem. In my case I don't even need the namespace so I think I will fork the repo and remove the nesting logic completely. Unfortunately I will lose the lib updates but it is what it is I guess. Thanks for the reply.

Hmm, I see! You can btw also use https://www.npmjs.com/package/patch-package to avoid a fork and allow for easier updates.
I’ll keep an eye on this topic in case more people run into this!

Thanks for the suggestion! I would certainly use that.
I will keep an eye for changes on this topic but for the moment I will close this.
And thanks for the awesome package you are maintaining!

I ran into the same problem... I'm working on an extremely dynamic app where strings are used multiple times on different components so keeping strings-as-keys approach solves string search and avoid duplicities. next-translate lib has an option to disable key nesting but does not support app router + SSG so we're looking for another lib and next-intl is amazing at SSG but lacks of key nesting customization.

+1

Nested keys makes it hard to find which translations are being used. I expect translation keys being 1:1 copyable and findable in the code (ex. session.notLoggedIn). Alternative is to use underline (ex. session_notLoggedIn).

+1


Hermes needs an active maintainer

Hi!
It has come to my attention that I don't have the time and ambition to maintain Hermes, so I'm looking for a dedicated maintainer to actively work on Hermes. In addition I won't have a Mac to maintain Hermes with, starting in a few weeks. I do intend to contribute back where it's sensibile -- e.g. I might end up with an old mac mini for some work projects, so maybe this won't be the last of my contributions. Regardless, we should find somebody that better fits the project responsibilities.
One person that comes to mind is @Aahung.
Any thoughts, comments, feedback is welcome.

Thank you for all that you have done, and the rest of the Hermes team. It has been a great project and really do not want to see it become abandonware. I don't have the technical ability to be any help, and my needs probably differ too far from the majority of users (I'm still on 10.8.5).

Hermes is a great projects due to many contributors. I would like to continue to contribute more. I don't have adequate skills and experience (I am gaining), hope to form a maintain group.

I should mention that this goes for me too — unlike @winny- I do still use a Mac every day but am busier than I've ever been at work and have multiple open source projects of my own that I'm trying to keep maintained as well.  I've really enjoyed working on Hermes and really enjoyed seeing it flourish, but unfortunately can't be part of its development in the forseeable future.

I'd like to help keep this project alive. I have only recently discovered Hermes and I love it. I've already made some changes to make it build with Xcode 7, to send the distributed notifications immediately, and to add a distributed notification for player state changes. I'd be happy to contribute here and there.

awesome... I use Hermes... but unfortunately I am not a coder.
On Thu, Oct 15, 2015 at 6:22 AM, obycode<EMAIL_ADDRESS>wrote:

I'd like to help keep this project alive. I have only recently discovered
Hermes and I love it. I've already made some changes to make it build with
Xcode 7, to send the distributed notifications immediately, and to add a
distributed notification for player state changes. I'd be happy to
contribute here and there.
—
Reply to this email directly or view it on GitHub
https://github.com/HermesApp/Hermes/issues/237#issuecomment-148384250.

--
Thank you for your attention,
Maurice P. O'Connor

@obycode Great! Please feel free to fork away :-)

@nriley I have forked and submitted a pull request, but CI didn't seem to like it and I'm not sure why. I'll need to spend some time figuring out what is wrong there.

Ugh, sorry :-/ Good luck.

I'd also be interested in keeping the app alive

Great. Perhaps a couple of you could start a fork, start contributing to it and if it makes some decent progress it can replace the "official" version here?

It might help to merge some of the outstanding pull requests... the networking one @dwaite filed looks like a good candidate!

I can compile, test, and grep logs all day long.  But that isn't anything to write home.  Happy to test, and assist where I can.  Alas my coding skills are, er, coding skills?  hehe...  Still.  The integration with the keyboard (play, pause, next) is hands down, why this cannot die!

@Aahung are you still interested in working on this?
If no-one else wants to stand up for this one, I'm willing to keep active on top of pull requests and some fixes (no guarantees to pleasing everyone but I'd like to see this stay alive)

I am interested in contributing to this project. I am experienced with iOS dev but haven't worked with Mac apps before. I've been using Hermes for 2 years now and just realized its maintenance has been dropped :(.
I don't have the time right now to jump in head first but come June I should have some extra time to dedicate. I would really hate to see this application go under.

Thanks folks! I would recommend one or more of you fork Hermes and start merging patches. If there becomes a consensus I can give you access to the project and at some point we will figure out the way to share the appropriate information for making an actual release!

I'd be interested in taking on ownership on Hermes. I've already forked it and have it building on OS 10.11(Ah the deprecations!), and seems to be running, after much work on compiler issues.
I still have some issues, like getting an error code 9 on initial login, but hopefully I'll have it fixed up soon. I'll make a pull request once it's running correctly.

Travis CI has passed all the building checks, so it should be good to go for Xcode 7.3 - Pull Request #262 . I'll keep working to merge all the existing patches in to it as well

Awesome! Will take a look later this week — one warning for the future (from personal experience :-) is to make sure with the deprecation fixes that you're clear about your eventual OS minimum requirement.

Great. Thanks for the tip! The biggest change was using NSRunningApplication (available in OS 10.6 and later) instead of ProcessSerialNumber (Which was deprecated in 10.9 i believe) to deal with hotkey support. Everything else was mainly syntax changes

@jmjones88 - I just created a pull request to your repo with the two changes that I'd like to see that help Hermes work better with third parties using the notifications. I'd be happy to help with maintenance work too.

@obycode Thanks for that, I merged your requests in. Also thank you for all the work you did updating it for Xcode 7, it sure was a great resource

Great, I'm glad it could help! I never had the time to go through and get it passing the tests.Thanks for finishing that up!

I live in Hong Kong and I don't use Pandora very often. But, yep I will be here to help fix something if I can.

Okay, merged and listening to the new Hermes at the moment! Updated the release notes too. Next thing I think we need to work on is getting the Web site updated and making a release. I've never actually done a release myself but can track down some info that @winny- and @alexcrichton sent me.

OK, I fixed a bunch more stuff (please keep in mind this is not sustainable for me) and built a beta.  Can't figure out how to upload it to S3 at the moment, but here it is on my Web site: https://sabi.net/temp/Hermes-1.2.7b1.zip.
If this works for people, I'll release it and then hopefully hand over the reins to someone(s) else.

I've been playing with it this morning and it works great.

I haven't encountered any problems with 1.2.7b3 so far, nice work!

OK, 1.2.7 is released with a bunch of changes — thanks to everyone who contributed.  I still need to document the release process, which has changed (for the better, I think — everything is now hosted on GitHub rather than S3).  Barring any catastrophic issues, I hope this will be good enough for a while to give some other folks a chance to get up to speed.

Thumbs up to everyone who contributed to 1.2.7. Thanks very much for keeping this great app alive.

The release process is now documented. Let me know or post to this issue when you're ready for 1.2.8 or 1.3.0 or whatever and I'll make the necessary project changes.

I have done a bit more cleanup and fixed a bunch more bugs, including a regression introduced in 1.2.7, which will hopefully give the app a bit more time to find its footing with other maintainers.
Sorry to abuse this issue, but I imagine the participants have some interest in Hermes.  Please test and file issues with any problems, particularly regressions!
Download: https://github.com/HermesApp/Hermes/releases/tag/v1.2.8b4
Changelog: https://github.com/HermesApp/Hermes/blob/master/CHANGELOG.md

May I may a suggestion that given all the great work that @nriley has done for Hermes - that the project gets moved to his Github as the 'main' maintainer?

I appreciate the thought, but please no — the point of a lot of my work and doing things like documenting the release process was to make it easier for other people to get involved.  I made a pile of cleanups/fixes in the last couple months because I had a lighter-than-usual work schedule, but I do not expect this to continue in the future and I also have a lot of my own open-source software that needs work. I did start using Hermes again myself which certainly contributed to my enthusiasm, though!
Hopefully some other folks can continue to pitch in. I think the code is in pretty good shape at this point, there are a bunch of open tickets, and I’m more than happy to answer questions going forward. Particularly there seem to be some signifcant crashing bugs with the 10.12 beta I don't know if/when I'll have time to address as I don't even have a 10.12 install right now (#258).

Hello @winny- @HermesApp !
I am Adib Murshed, the President of the Iniftar Foundations at: http://www.blog.iniftar.com. I would like to claim this project to continue its development, open-source and non-profit.

Hello, make sure to highlight @nriley - he's the guy to talk to. Best of luck :)

@nriley

Thanks @winny- - was on vacation. The comment you responded to was deleted and I could never figure out what it was about in any case... FYI for anyone else, if you want to start contributing, just do so, you don't need to ask permission :-)

@nriley I would be interested in contributing. Objective-C is not my forte but I can handle smaller issues especially if someone else just wants to review my work. I tackled a simple issue (#320) to get started.

What's the deal with maintenance at this point?

 I have done a lot to make the project easily buildable and accessible and am happy to offer assistance getting set up, though I think if you don’t have some Cocoa experience this would not be a great starting project. Otherwise work will come very slowly or not at all.

On Oct 23, 2018, at 2:54 PM, Perry E. Metzger<EMAIL_ADDRESS>wrote:
What's the deal with maintenance at this point?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

But has anyone else been given commit rights over the app so they can maintain things, merge pull requests, etc.?

But has anyone else been given commit rights over the app so they can maintain things, merge pull requests, etc.?

Just fork it and do pull requests? People who want to maintain it and take over the project might also add malware to it.

But has anyone else been given commit rights over the app so they can maintain things, merge pull requests, etc.?

Just fork it and do pull requests? People who want to maintain it and take over the project might also add malware to it.

Agreed, if you want to work on it, just fork it and get started; there have been some pretty high-profile cases of the malware thing recently when bad actors are added as contributors.
I'm in a slightly better place to handle contributions than I was a few years ago, but don't have enough time/ability to resume actively maintaining Hermes — though I use it daily.

I did a quick fork and build in macos 11 xcode 12.5. You are right it is a lot of work if you are not expert in Cocoa.
Kudos to you btw for being able to support FOSS with a day job as a MD. I as a JD am stop and go.

Folks are jacked up for the silicon rebirth of Hermes - https://www.reddit.com/r/macapps/comments/1ggq1fn/hermes_silicon_fork_in_2024_free_open_source/ .

Folks are jacked up for the silicon rebirth of Hermes - https://www.reddit.com/r/macapps/comments/1ggq1fn/hermes_silicon_fork_in_2024_free_open_source/ .

Damn thanks for the shoutout.


no_std training

https://github.com/esp-rs/no_std-training/pull/37

No need to track this here IMO, the draft PR in the training repo will suffice.


fix: support node:test in node 18

closes https://github.com/esbuild-kit/esm-loader/issues/32

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Please give merge rights to someone in europe

In the last couple of weeks we often have red builds because of merge errors.
This blocks us - please consider to give merge rights (only restricted to build fixes) to one of the community members.
I suggest @vasily-kirichenko

I think it should be someone from Microsoft, but yes, 9-11 hours time shift between Redmond and us in Europe is a huge pain.

Don can merge


[Docs] Remove the extra toc item and double header for the examples Gallery

Currently the toc has an extra entry Gallery for napari-threedee that actually links back to the homepage. Also the header of the Gallery is duplicated. See:

In this PR I try to fix this by deleting the extra README which might be responsible.

OK, so the README has to be there. Trying to change the toc now

Ok, so changing the toc didn't do anything, just changed the name in the toc.
Looks like it's designed to have examples at the top level? Lets try that.

Ok, it's working. I will post some screenshots with the new look. I think it might be better? but can just as easily close this and leave it be.

The new look:

and if you scroll:

Both of the sub-menus work as before:

I put the plugin ones first, but could swap around to Library on top.

Ok, so changing the toc didn't do anything, just changed the name in the toc. Looks like it's designed to have examples at the top level? Lets try that.

It is generally designed to have examples at the top level, but Keven asked me to keep separate subpages https://github.com/napari-threedee/napari-threedee/pull/104#issuecomment-1486274034

Fair enough. Closing.


Fix express probe behavior

res.response is not guaranteed to exist. Additionally, the official appmetrics readme states that the express probe will yield a top-level duration property: https://github.com/RuntimeTools/appmetrics#event-express

We didn't version bump for the other bug fixes, though they did represent patch-level changes. I don't think we want to diverge from Strongloop's versioning schedule.

👍

:+1:


reStructuredText docs not rendering

I followed the documentation for doing reStructuredText doc strings, and it works fine in the django rest framework docs:

but in the swagger docs it doesn't render:

What I found interesting is that if I install markdown, the docs do get rendered as markdown, which sort of works.  It seems to me that there is probably just one place it isn't calling the DRF VIEW_DESCRIPTION_FUNCTION callable, but I couldn't find it easily.
here are the pip freeze related packages
django-rest-swagger==0.3.5
djangorestframework==3.3.2

I'm happy to write the code if someone can point me at the possible places this might be happening, and thanks so much for the awesome project!

Hey @carsongee did you found anyway to solve this problem?
docutils==0.12
django-rest-swagger==0.3.6
djangorestframework==3.3.3

I'm afraid not, we are still just using the markdown rendering which makes it more readable but still not great:

Yaml docstrings have been deprecated as of v2, so won't be supporting a fix. Thank you!


Bug with Off hand

When holding an item with a socket in the off hand and a gem in the main hand before combining it causes a duplication of both items. (You get a gemmed item in one hand and unchanged in the other.) When this happens, the normal gem behaviour is nonfunctional and it does not disappear as it should.

Sorry, didn't notice the report below.


Autocomplete

To be tested on OSX. //cc: @rojepp

I can check tomorrow.

Sorry about the delay. This works beautifully. :)


chore: modified server schema version

Description

fixes xml parser

Fixes: https://github.com/appsmithorg/appsmith/issues/28364

/ok-to-test

/ok-to-test

/ok-to-test

/build-deploy-preview

lgtm cc: @arunvjn


created a new udf for multivariate

time series forecasting

Hi Ish, what is the difference between the forecasting in this PR and existing forecasting in EvaDB

Hi Ish, what is the difference between the forecasting in this PR and existing forecasting in EvaDB?

Hi Andy, this is for multivariate forecasting. The previous PR works for univariate forecasting only.

Hi Ish, what is the difference between the forecasting in this PR and existing forecasting in EvaDB?

Hi Andy, this is for multivariate forecasting. The previous PR works for univariate forecasting only.

Thanks Ish! Does multivariate subsumed univariate? If so, we can direclty change the existing function instead of creating a new one.

Hi Ish, what is the difference between the forecasting in this PR and existing forecasting in EvaDB?

Hi Andy, this is for multivariate forecasting. The previous PR works for univariate forecasting only.

Thanks Ish! Does multivariate subsume univariate? If so, we can direclty change the existing function instead of creating a new one.

Hi Andy, Prophet works for univariate also. I think we can update to having a single function.
 CREATE FUNCTION MultivariateForecast IMPL 'evadb/functions/multivariate_forecast.py' train_end_date '2005-02-07'  type 'MULTIVARIATE' model 'PROPHET' horizon 365 frequency 'd' ;
Will this syntax work?
we can have default parameters for univariate (ARIMA) and multivariate (PROPHET) types.
@americast can you also share your thoughts on this

Hi @IshSiva, thanks for the PR. I think for multivariate forecasting, the user would have to also provide multiple columns that need to be considered for forecasting. Thus, the user would have to provide the target column, as well as columns that would be considered as additional regressors.
You can check out statsforecast's implementation at this link. If you would like to directly use prophet, it's even simpler as they have an add_regressor option..

this link

Hi @americast , I have used this statsforecast implementation of Prophet for the multivariate forecasting. The target column can be given as an additional argument in the create udf function. So can we just update this new function to support univariate also? (because it is just an extension).

@IshSiva I think we can give statsforecast's Prophet Holiday a try. The only change that might be needed is support for more columns as user input while creating the UDF that would act as a reference for forecasting. The model option is also a parameter already implemented (I think I missed adding it to the docs), so the user can simply choose AutoARIMAProphet if they need multivariate forecasting. Or, we can create an alias for the same.

Let's go with just statsforecast and neuralforecast.


feat: Attach RAG documents to ModelFiles

Good afternoon!
I had a great idea when playing with ModelFiles in the webui.
What if it were possible to attach RAG documents (or a group of RAG documents) to a modelfile? I know a lot of work would have to be put into this because ollama doesn't support this directly, but I think it could be done. It would be nice to have a model file that would just always have a rag document attached to it when conversing with it, rather than including all my data in the system prompt or manually attaching a document every time I ask it a question.
For example, I could make a modelfile that's based on mixtral or something but has a RAG document attached to it with a big essay about my life or whatever, and anyone who asks the model a question about me would get an answer from it utilizing RAG. This would also be nice if this worked through the API as well.

Duplicate: #529


Enable date and time at logger

Add log time on gallery:

Remove time from ignore, https://github.com/xemle/home-gallery/blob/c3eeb57a089bee4bd1e81e4136acf67dc474ad88/packages/logger/src/pretty-stream.js#L50
Add translateTime, as pino-pretty default only use time. Translatetime help adding date.

Before patch:
cli.run Starting server
cli.spawn Run cli with server
server Your own Home Gallery is running at http://localhost:3000
server.cli Run cli with run import --initial --update --watch...
cli.run Import online sources: /data/Pictures
cli.task.import Run import in watch mode. Start watching source dirs for file changes: /data/Pictures
server.api.database.read Read database file /data/config/database.db with 20004 entries 0.85s
server.api.events Read events file /data/config/events.db with 3 events 1ms
cli.task.import Run incremental import in batch mode of different file sizes
cli.task.import Run batch import: Import files up to 20 MB
cli.task.import Import files from source dirs: /data/Pictures

After patch:
[2023-06-20 15:29:16.729]: cli.run Starting server
[2023-06-20 15:29:16.734]: cli.spawn Run cli with server
[2023-06-20 15:29:17.139]: server Your own Home Gallery is running at http://localhost:3000
[2023-06-20 15:29:17.139]: server.cli Run cli with run import --initial --update --watch...
[2023-06-20 15:29:17.374]: cli.run Import online sources: /data/Pictures
[2023-06-20 15:29:17.374]: cli.task.import Run import in watch mode. Start watching source dirs for file changes: /data/Pictures
[2023-06-20 15:29:17.899]: server.api.database.read Read database file /data/config/database.db with 20004 entries 752ms
[2023-06-20 15:29:17.901]: server.api.events Read events file /data/config/events.db with 3 events 1ms
[2023-06-20 15:29:18.753]: cli.task.import Run incremental import in batch mode of different file sizes
[2023-06-20 15:29:18.754]: cli.task.import Run batch import: Import files up to 20 MB
[2023-06-20 15:29:18.754]: cli.task.import Import files from source dirs: /data/Pictures

More info look into https://github.com/xemle/home-gallery/issues/82
Thanks.

Hi @martadinata666
thank you for the PR. Awesome.
So you prefer to have the date in the stdout? I think the stdout log is more for concurrent logs and therefore the date is not required.
For longer log inspection the logfile should be used and can be inspected with all the details...
That are my 2 cents. You deside. I have a preference, but both versions (date vs time only) are fine for me
Please leave a comment or update your PR. Than I can merge it...

Hello, thanks for your attention.
This is the part where I'm also thinking a lot and decide to include the date, after checking my containers (apache, nginx, and some other apps) stout/stderr it mostly includes the date. Uniformity sense I guess.

OK. I am fine with the date-time format.
Thank you for your contribution


fix(release): add missing config files for release

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Disconnect button is missing

Issue Type: Bug
After the connection to the database is established, right clicking on the database name (under the connections section on the left) would not show disconnect. Clicking into databases folder first then right click on the database name, the disconnect will show up.
Azure Data Studio version: azuredatastudio 1.32.0 (4a45ba7cf20dd4129f1a08e5e776dfb33e3d1d1e, 2021-08-16T18:09:20.282Z)
OS version: Darwin x64 20.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 3

Memory (System)
16.00GB (0.17GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (5)

Extension
Author (truncated)
Version

admin-pack
Mic
0.0.2

agent
Mic
0.48.0

dacpac
Mic
1.8.0

import
Mic
1.3.1

profiler
Mic
0.11.0

@alanrenmsft  I think it happens to any sql server versions but the ones that I have been working on are on-Prem SQL Server 2016 and 2017. Typically, I don't need to restart ADS to find disconnect button. I have to click on the databases or the object inside it then right click again on the connection. Here the screenshot.

I could not reproduce the issue easily but here what I did to reproduce the screenshot above

Open new connection in ADS, alter view, run it with cmd+F5, close the query window without saving it
Open several new query windows, write simple queries, close the query window one by one without closing the connection
While having ADS connecting to the one of the database, switch focus to something else such as chrome or other applications for several minutes then come back to ADS

One thing that I notice, it seems I accidentally right clicked on the other inactive connection (that hasn't been open) but the screenshot shows I was right clicking on the active connection (see the dotted outline square in the active connection).
I'm wondering if ADS lost connection briefly and try to reconnect.

@alanrenmsft I think it happens to any sql server versions but the ones that I have been working on are on-Prem SQL Server 2016 and 2017. Typically, I don't need to restart ADS to find disconnect button. I have to click on the databases or the object inside it then right click again on the connection. Here the screenshot.
I could not reproduce the issue easily but here what I did to reproduce the screenshot above

Open new connection in ADS, alter view, run it with cmd+F5, close the query window without saving it
Open several new query windows, write simple queries, close the query window one by one without closing the connection
While having ADS connecting to the one of the database, switch focus to something else such as chrome or other applications for several minutes then come back to ADS

One thing that I notice, it seems I accidentally right clicked on the other inactive connection (that hasn't been open) but the screenshot shows I was right clicking on the active connection (see the dotted outline square in the active connection). I'm wondering if ADS lost connection briefly and try to reconnect.

@wwangsa Thanks for opening this issue! From what I understand, you don't see a Disconnect button when you right click on a connection. Does this happen as soon as you connect to a server or after you leave it for a while and return to it? If it's the latter, it might explain the behavior you're describing, because that's by design.
What I assume is happening is, that your connection to the server is disconnected when it's left stale/idle for a long time and hence you don't see the disconnect button. However, when you expand the databases folder, it establishes a connection to the server again and hence you see the disconnect button this time.
If this is not the case i.e. you connect to a server and then right click on it as soon as it's connected (or when not left idle for a while) and don't see the disconnect option, please let me know.

@abist Is the timeout session defined by the sql server or visual studio? When I tried to reproduce the issue, it seems it happenned within 15 minutes and I was able to do the query as usual. Is there any other indicator that tells the connection is stale? I wish i have consitent way to replicate the issue. May be keep an eye on it in the future?


scoped css with content distribution

Component scope css rules didn't applies to elements in slot.

Could you provide a jsfiddle?
Also, what _v-40.. stand for?

That's intended. Slot content is considered from parent and thus styled by the parent.

Actually, there might be a better way to handle this. But let's move this to vue-loader.


use git revision id to locate source file.

Made changes according to prior review feedback.
I am creating a new PR for I added a second private branch into this PR too.
Major changes

use git command to replace libgit2sharp for license problem.
Delete temporary files immediately after file is opened.

Modified please check.

Ian, Jim,
Could either of you take a look since Ivan is on vacation?
I've made changes according to Ivan's request.

Created a GitUtils project for git commands.
Use async execution for git commands.  If a command takes relatively longer , user will see a progress dialog.
Others (comment etc)

@Deren-Liao is this blocking any other work?  It's a fairly large PR which Ivan has all the context for.

Thank you for looking into this.
Not completely blocking, but waiting for another week is too long.  Also I
have bug fixes etc that I want to submit PR too.  I hope to submit the bug
fixes PR on top of this rather than doing merges later which is quite
painful. Actually I've been holding a few bug fixes.
The overall logic, design etc Ivan already reviewed, I think it's Okay if
you focus on individual method implementations etc.
On Wed, Apr 12, 2017 at 12:13 PM, Ian<EMAIL_ADDRESS>wrote:

@Deren-Liao https://github.com/Deren-Liao is this blocking any other
work? It's a fairly large PR which Ivan has all the context for.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-visualstudio/pull/554#issuecomment-293678774,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVxZpMxncV6idbvoAdxTXwX-cxyu6Cybks5rvSJFgaJpZM4M3n3t
.

Thank you for the comment.
I'll address the comment one by one.  To the overall question

We are not allowed to use gitlib2sharp for it contains GLP license.
I'll see if I can change the code to all the way async up. If it is kind too much code change, unless there is clear benefit of doing so, I'd like to keep it as is.  Do you agree?
Please note, for those that I return null , they are valid cases.  I search multiple paths for local git root.   if it is not there, I return null and try next one. In the end, if none of them are found, it is still valid user case. I'll simply display a dialog to tell user the information.

Hi Jim,
Thank you for doing the code review. I updated code on your comment. Please take a look again.

When it is not waited, user is able to click on other part of the UI.  I
intentionally want it be blocked . Then user will see a progress dialog if
it takes time.
On Wed, Apr 12, 2017 at 7:03 PM, Jim Przybylinski<EMAIL_ADDRESS>wrote:

@ILMTitan commented on this pull request.
In GoogleCloudExtension/GoogleCloudExtension/
StackdriverLogsViewer/LogItem.cs
https://github.com/GoogleCloudPlatform/google-cloud-visualstudio/pull/554#discussion_r111298016
:

@@ -215,7 +215,8 @@ public LogItem(LogEntry logEntry, TimeZoneInfo timeZoneInfo)
}

             SourceLinkVisible = true;

           OnNavigateToSourceCommand = new ProtectedCommand(() => SourceVersionUtils.NavigateToSourceLineCommand(this));

           OnNavigateToSourceCommand = new ProtectedCommand(

               () => SourceVersionUtils.NavigateToSourceLineCommandAsync(this).Wait());

You don't need the lambda expression or the .Wait(). Just call it like
you did previously.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-visualstudio/pull/554#pullrequestreview-32533444,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVxZpH910NAvxWSCmI7LifLerg4DUv76ks5rvYJZgaJpZM4M3n3t
.

Thanks Ivan and Jim for doing the review!


Add ability to specify knife[:secret] and knife[:secret_file] in knife.rb

This would bring it to parity with EC2 cloud tools, and a few other knife subcommands.

Closing pull request per discussion on ticket.
http://tickets.opscode.com/browse/CHEF-2602