protoc-gen-php-grpc plugin support

I can see that the code of protoc-gen-php-grpc plugin moved to the plugins repo https://github.com/spiral/roadrunner-plugins/tree/master/grpc/protoc_plugins/protoc-gen-php-grpc.
That arises some questions:

which version should we use, which one you are going to maintain?
if from plugins repo - do you plan to publish binaries like for this repo?

Hey @hotrush. This repository was deprecated and will receive only urgent bug or security fixes.
Regarding your questions:

which version should we use, which one you are going to maintain?

https://github.com/spiral/roadrunner-plugins/tree/master/grpc/protoc_plugins/protoc-gen-php-grpc

if from plugins repo - do you plan to publish binaries like for this repo?

Yes, we will publish protoc-gen-php-grpc binaries in the https://github.com/spiral/roadrunner-binary repository shortly.

@hotrush https://github.com/spiral/roadrunner-binary repo now contains protoc-gen-php-grpc binaries.


Swift Codegen, fragments

Question/Feature request regarding the output of the generated code for swift when fragments are used.
We have a fragment called "FormattedText" to encapsulate complex text fields that have nested bold/italic/link content.
And example quest would be
...
...
  headingText {
        ...formattedText
      }
...

The returned data is as follows
"headingText": {
            "spans": [
              {
                "text": "Credit card utilization"
              }
            ]
          },

The issue arrises with the gerenated code:
...
public let headingText: HeadingText?
...

  public struct HeadingText: GraphQLMappable {
                    public let __typename = "FormattedText"

                    public let fragments: Fragments

                    public init(reader: GraphQLResultReader) throws {
                        let formattedText = try FormattedText(reader: reader)
                        fragments = Fragments(formattedText: formattedText)
                    }

                    public struct Fragments {
                        public let formattedText: FormattedText
                    }
                }
...
...
//and finally Fragmented Text

public struct FormattedText: GraphQLNamedFragment {
    public static let fragmentDefinition =
        "fragment formattedText on FormattedText {" +
        "  spans {" +
        "    text" +
        "  }" +
        "}"

    public static let possibleTypes = ["FormattedText"]

    public let __typename = "FormattedText"
    public let spans: [Span?]?

    public init(reader: GraphQLResultReader) throws {
        spans = try reader.optionalList(for: Field(responseName: "spans"))
    }

    public struct Span: GraphQLMappable {
        public let __typename = "FormattedSpan"
        public let text: String?

        public init(reader: GraphQLResultReader) throws {
            text = try reader.optionalValue(for: Field(responseName: "text"))
        }
    }
}

In order to access this object you would write:
data.headingText?.fragments.formattedText

The feedback is the fragments contatiner necessary? Should the HeadingText class itself not be a FormattedText or more closely implement the FormattedText fragment. This indirection strikes me as unnecessary.
	"Credit card utilization"	some

So my suggestion is, can we make HeadingText more directly inherit from FormattedText?
 public struct HeadingText: FormattedText {

What are the conditions under which this fragment structure becomes more useful?

I actually started out with the approach you're suggesting, generating objects with fields from fragments merged in, and conforming to a generated protocol for each fragment.
This broke down because of limitations of the Swift type system, and then I realized there were also positive consequences to keeping fragments as separate objects.
To start with the typing limitations, the main issue is that properties of protocols are invariant in the current version of Swift. So you cannot conform to a protocol with a property of a more specific type, even if the property is read only.
To take a simple example, given this GraphQL query and fragment:
query Hero {
  hero {
    ...HeroDetails
    friends {
      appearsIn
    }
  }
}

fragment HeroAndFriendsNames on Character {
  name
  friends {
    name
  }
}

You would expect to be able to generate something like this (leaving out a lot of code):
class HeroQuery {
  struct Data {
    struct Hero: HeroAndFriendsNames {
      let name: String
      let friends: [Friend]
      struct Friend: HeroAndFriendsNames_Friend {
        let name: String
        let appearsIn: [Episode]
      }
    }
  }
}

protocol HeroAndFriendsNames {
  var name: String { get }
  var friends: [HeroAndFriendsNames_Friend] { get }
}

protocol HeroAndFriendsNames_Friend {
  var name: String { get }
}

But this code doesn't compile because let friends: [Friend] does not conform to var friends: [HeroAndFriendsNames_Friend] { get }, even though Friend conforms to HeroAndFriendsNames_Friend.
It gets even more complicated when you take type conditions into account, because now the type hierarchy starts to diverge based on the actual type of the object.
Generating fragments as separate objects is a way to overcome these issues. But the more positive way of looking at it is that it enables the kind of data masking Relay also advocates.
Child components (e.g. table view cells) can define fragments with their exact data needs. And parent components (e.g. a table view controller) only have to know the name of the fragment and pass it on without inadvertently depending on data requested by the child (or the other way around). See the Frontpage iOS app for an example of this structure.

I see what you're describing.
The two suggestions I can make that somewhat alleviate the uglyness are
a) Add an "as" operator similar to "asDroid/asHuman" downcasting.
public var asHeroAndFriends : HeroAndFriendsNames {
       get {
            return self.fragments.heroAndFriendsNames
       }
}

b) Add an init extension to HeroAndFriendsNames
extension HeroAndFriendsNames{
    init(_ hero : HeroAndFriendsNamesQuery.Data.Hero) {
        self = hero.fragments.heroAndFriendsNames;
    }
}

for usage like
let heroAndFriends = HeroAndFriendsNames(data.hero!)

I may have gotten too used to it by now, and I remember thinking it was ugly before, but making fragments explicit doesn't actually seem too bad to me.
The upside is that you make it very clear you're accessing data from a fragment, and you get convenient code completion with just the fragment names, so it's easy to see what fragments are there.
I think the switch I had to make is to see fragments as not just an implementation construct, but as a way of defining view models that clearly ties data needs to specific UI components.
I'm definitely open to better solutions (of those two, I think I would prefer the first, because you still get code completion), but I'm not yet convinced they are needed.

Hmm,  @martijnwalraven in the example above, just using an associated type should correctly constrain things and make it more ergonomic. The following compiles correctly:
public enum Episode: String {
  case newhope = "NEWHOPE" /// Star Wars Episode IV: A New Hope, released in 1977.
  case empire = "EMPIRE" /// Star Wars Episode V: The Empire Strikes Back, released in 1980.
  case jedi = "JEDI" /// Star Wars Episode VI: Return of the Jedi, released in 1983.
}

class HeroQuery {
  struct Data {
    let hero: Hero
    struct Hero: HeroAndFriendsNames  {
      let name: String
      let friends: [Friend]

      struct Friend: HeroAndFriendsNames_Friend {
        let name: String
        let appearsIn: [Episode]
      }
    }
  }
}

protocol HeroAndFriendsNames {
  associatedtype Friend: HeroAndFriendsNames_Friend

  var name: String { get }
  var friends: [Friend] { get }
}

protocol HeroAndFriendsNames_Friend {
  var name: String { get }
}

let x = HeroQuery.Data(
  hero: HeroQuery.Data.Hero(
    name: "Foo",
    friends: [
      HeroQuery.Data.Hero.Friend(
        name: "Bar",
        appearsIn: [.newhope]
      )
    ]
  )
)
print(x)
print(x.hero.friends[0].appearsIn[0])

@erydo: Using associated types is an interesting approach, but the biggest drawback is that you can no longer store fragments.
In this example, it's impossible to have a variable of type HeroAndFriendsNames. As you mentioned, you can use fragments as type constraints in a generic function, and that is useful, but I think it is important we can still treat fragments as stand-alone types as well.

I'd argue that fragments that can be spread are not necessarily standalone types, which is even emphasized by their name. They're essentially structural constraints. The fields returned in a selection set form a union of each of the fields listed and each of the fields from their (spreadable/non-upcasting) fragments.
Fragments implemented as above can be stored, either passed abstractly as "any kind of result that includes that fragment" (hiFromHeroAndFriendsFragment above) or concretely (hiFromHeroQueryHero).
For cases where it's really necessary to create a common struct type for a fragment, it would still be straightforward to make that available. You could generate a struct implementation of that fragment protocol with only the fragment members—similar to what apollo-codegen does now—and a single toXXXFragmentStruct implementation to get that from any fragment implementor.
Excuse the poor naming in the following, I'm roughly simulating what the generated code might look like. The following added to code in the earlier comment:
struct HeroAndFriendsNamesStruct: HeroAndFriendsNames {
  let name: String
  let friends: [Friend]
  typealias Friend = HeroAndFriendsNames_FriendStruct
}

extension HeroAndFriendsNames {
  typealias FragmentStruct = HeroAndFriendsNamesStruct

  // Converts any selection set with this fragment to a common struct type.
  var toHeroAndFriendsNamesStruct: FragmentStruct {
    return FragmentStruct(
      name: self.name,
      friends: self.friends.map { (f: Friend) in f.toHeroAndFriendsNames_FriendStruct }
    )
  }
}

struct HeroAndFriendsNames_FriendStruct: HeroAndFriendsNames_Friend {
  let name: String
}

extension HeroAndFriendsNames_Friend {
  typealias FragmentStruct = HeroAndFriendsNames_FriendStruct

  // Converts any selection set with this fragment to a common struct type.
  var toHeroAndFriendsNames_FriendStruct: FragmentStruct {
    return FragmentStruct(name: self.name)
  }
}

That would allow you to use a concrete type if using the protocol is undesirable:
// Generic for any query results that include that Fragment:
func hiGeneric<H: HeroAndFriendsNames>(hero: H) -> String {
  let friends = hero.friends.map { $0.name }.joined(separator: ", ")
  return "\(hero.name) says, 'Hi, \(friends)!"
}

// Results specifically from one query which includes that fragment:
func hiFromQuery(hero: HeroQuery.Data.Hero) -> String {
  let friends = hero.friends.map { $0.name }.joined(separator: ", ")
  return "\(hero.name) says, 'Hi, \(friends)!"
}

// If you can't use generics or otherwise want a concrete struct:
func hiOnlyFragmentStruct(hero: HeroAndFriendsNames.FragmentStruct) -> String {
  let friends = hero.friends.map { $0.name }.joined(separator: ", ")
  return "\(hero.name) says, 'Hi, \(friends)!"
}

print(hiFromQuery(hero: x.hero))
print(hiGeneric(hero: x.hero))
print(hiGeneric(hero: x.hero.toHeroAndFriendsNamesStruct))
print(hiOnlyFragmentStruct(hero: x.hero.toHeroAndFriendsNamesStruct))

// Will not work because x.hero isn't exactly the fragment type, and
// hiOnlyFragmentStruct isn't generic.
// print(hiOnlyFragmentStruct(hero: x.hero))

// Will not work because hiFromQuery expects a type greater than the limited
// fragment provides:
// print(hiFromQuery(hero: x.hero.toFragmentStruct))

That approach covers both cases: It allows fragments on results to be treated generically and ergonomically, but still allows them to be isolated out if for some reason they need to be.
Another benefit is that factoring a query's fields into a fragment no longer forces all code using that query to be refactored, which is intuitive, because the actual structural guarantees of that query wouldn't have changed.
On that note, it's useful to consider upcasting fragments separately.
The ...HeroDetails example above is a guaranteed type match (all of its fields could be inlined), but that same fragment used as an upcast on a node() query wouldn't be—you wouldn't be able to inline the fragment's fields. For those cases I think apollo-codegen's current approach of putting those as nullable members is good.
But many (perhaps most?) instances of fragments are not upcasts in that way, but are simply spreads of common fields.

Fragments implemented as above can be stored, either passed abstractly as "any kind of result that includes that fragment" (hiFromHeroAndFriendsFragment above) or concretely (hiFromHeroQueryHero).

That depends on what you mean by stored. They can not be stored as instance variables, which is something most people would want to do be able to do with a fragment.
The current restrictions on protocols with associated types, until we get something like generalized existentials in the language, mean many legitimate uses will end up with a Protocol ‘HeroAndFriendsNames' can only be used as a generic constraint because it has Self or associated type requirements error.
This severely limits the usefulness of the approach, and I don't think being able to use the protocol as a generic constraint justifies the added complexity of generating both protocols and structs for every selection set for every fragment.
Protocols with associated types and generic methods are pretty advanced concepts that are hard to grasp for many developers. I don't think we can ask people to make every method that deals with a fragment generic.

I'd argue that fragments that can be spread are not necessarily standalone types, which is even emphasized by their name. They're essentially structural constraints. The fields returned in a selection set form a union of each of the fields listed and each of the fields from their (spreadable/non-upcasting) fragments.

In practice, fragments are as much a run time as they are a typing construct. We often have a need to deal with the data from a fragment independent of the query it came from, or even independent of any query.
This is even more important as we're working on an imperative store API similar to the one recently introduced in Apollo JavaScript. This means we should be able to read/write fragments without an associated query, so we do need the ability to instantiate a fragment as a stand-alone type.

I think we might be talking past each other slightly, I apologize…
My second comment specifically showed storing instance variables by allowing a fairly trivial struct to be created from a generic protocol implementor. That struct is similar to apollo-codegen's current output, and is always constructible from the protocols, so it's certainly not more limited. You wouldn't be losing any capability that's already there, you'd only be gaining the ability to have more refined types available.

In practice, fragments are as much a run time as they are a typing construct. We often have a need to deal with the data from a fragment independent of the query it came from, or even independent of any query.

The proposal above does not add any restrictions to that. It only only removes them. Right now, for example, the structs generated for inline spreads (AsFoo) are completely unrelated in the type system of the generated swift code. Structs can't be inherited, and there are currently no protocols to conform to, so you're SOL if you want to do anything generic with GraphQL interfaces.
I might've been unclear in what I was proposing be generated, which is, for each fragment:

A protocol definition (with associated types for sub-fragments)
A convenience struct definition that minimally satisfies that fragment protocol.
A default toXXXStruct member for implementors of that fragment protocol to produce a concrete struct. Or the struct definition could just have a constructor.

This means that you still always have access to the general struct form (which is the only form currently generated by apollo-codegen), but are additionally able to have more specifically refined types, which is very useful. Additionally, you aren't restricted to a strictly descending taxonomy, which means the result of a selection set with multiple fragment spreads can just implement the protocols for each of those fragments.
Here's a motivating example, adapted (and contrived a bit) from a real schema and query:
Schema:
interface ProfileAttribute {
  id: ID!
  isVerified: Boolean!
  isMutable: Boolean!
}

type EmailAttribute implements ProfileAttribute {
  id: ID!
  isVerified: Boolean!
  isMutable: Boolean!
  emailAddress: String!
  normalizedEmailAddress: String!
}

type PhoneAttribute implements ProfileAttribute {
  id: ID!
  isVerified: Boolean!
  isMutable: Boolean!
  numberE164: String!
}

# …
# There are several more common fields
# and several more attribute types omitted.

type Profile {
  id: ID!
  primaryEmailAttribute: EmailAttribute!
  primaryPhoneAttribute: PhoneAttribute
  otherProfileAttributes: [ProfileAttribute!]
  # …
}

type Query {
  profile: Profile!
}

Then the query:
fragment ProfileAttributeFragment on ProfileAttribute {
  id
  isVerified
  ...on EmailAttribute {
    emailAddress
  }
  ...on PhoneAttribute {
    numberE164
  }
  # …
}

# This is slightly contrived, but helpful for illustration.
fragment MutabilityInfoFragment on ProfileAttributeFragment {
  isMutable
}

fragment ProfileFragment on Profile {
  id
  primaryEmailAttribute {
    ...ProfileAttributeFragment
    normalizedEmailAddress
  }
  primaryPhoneAttribute {
    ...ProfileAttributeFragment
  }
  otherProfileAttributes {
    ...ProfileAttributeFragment
  }
  # …
}

query GetFullProfile {
  profile {
    ...ProfileFragment
    primaryEmailAttribute {
      ...MutabilityInfoFragment
    }
  }
}

In the above, a few things to notice:

The profile {…} selection:

The selection set is guaranteed to match the on Profile type condition.
The selection set includes all of the fields from ProfileFragment.
(If we were to move the id field from ProfileFragment into the query itself, it still would, but would just have an additional field).

The primaryEmailAttribute {…} selection in ProfileFragment:

The selection set is guaranteed to match the on ProfileAttribute type condition.
Further, it's guaranteed to match the ...on EmailAttribute type condition within the ProfileAttributeFragment.
That means that the result, if any, is guaranteed to have a non-null .emailAddress property.
We also add the normalizedEmailAddress in addition to the fragment.

The primaryEmailAttribute fragment in GetFullProfile

We also add the fields from MutabilityInfoFragment

We could generate protocol definitions for this, as well as a general struct form. For any given use of a fragment, we can also return a type with additional guarantees based on its parentage in the schema, while still conforming to the very generic fragment protocol.
The following compiles fine and runs—sorry for the length…
//////// Fragment protocols {

protocol ProfileAttributeFragment {
  var id: String { get }
  var isVerified: Bool { get }
}
protocol ProfileAttributeFragment_AsEmailAttribute: ProfileAttributeFragment {
  var emailAddress: String { get }
}
protocol ProfileAttributeFragment_AsPhoneAttribute: ProfileAttributeFragment {
  var numberE164: String { get }
}

protocol ProfileFragment {
  var id: String { get }

  var primaryEmailAttribute: PrimaryEmailAttribute { get }
  var primaryPhoneAttribute: PrimaryPhoneAttribute? { get }
  var otherProfileAttributes: [OtherProfileAttributes] { get }

  associatedtype PrimaryEmailAttribute: ProfileAttributeFragment_AsEmailAttribute
  associatedtype PrimaryPhoneAttribute: ProfileAttributeFragment_AsPhoneAttribute
  associatedtype OtherProfileAttributes: ProfileAttributeFragment
}

protocol MutabilityInfoFragment {
  var isMutable: Bool { get }
}

//////// }

//////// Fragment structs (most general, least refined representation of fragments) {
//
// These structs conform to the protocols, but only consider the fields from
// the particular fragment, and require separate structs with duplicated data
// if there is more than one fragment spread into a selection set in a query.
// This is similar to the current apollo-codegen output.
//
// apollo-codegen currently uses structs for everything, which is fine if
// you have protocols for conformance checking, but it makes it impossible to
// subtype. In apollo-codegen, a ProfileAttributeFragment and
// ProfileAttributeFragment.AsEmailAttribute are not related in the type system
// _at all_. The following is similar, but the use of protocols allows them
// to be used with generic functions.
//

struct ProfileAttributeFragmentStruct: ProfileAttributeFragment {
  let id: String
  let isVerified: Bool

  let asEmailAttribute: AsEmailAttribute?
  let asPhoneAttribute: AsPhoneAttribute?

  // Note that ProfileAttributeFragmentStruct.AsEmailAttribute is not a subtype
  // of ProfileAttributeFragmentStruct (same restriction as current
  // apollo-codegen). It does, however, conform to both the
  // ProfileAttributeFragment and ProfileAttributeFragment_AsEmailAttribute
  // protocols.

  struct AsEmailAttribute: ProfileAttributeFragment_AsEmailAttribute {
    let id: String
    let isVerified: Bool
    let emailAddress: String

    var asEmailAttribute: AsEmailAttribute { return self }
    var asPhoneAttribute: AsPhoneAttribute? { return nil }
  }
  struct AsPhoneAttribute: ProfileAttributeFragment_AsPhoneAttribute {
    let id: String
    let isVerified: Bool
    let numberE164: String

    var asEmailAttribute: AsEmailAttribute? { return nil }
    var asPhoneAttribute: AsPhoneAttribute { return self }
  }
}

struct ProfileFragmentStruct: ProfileFragment {
  let id: String

  let primaryEmailAttribute: ProfileAttributeFragmentStruct.AsEmailAttribute
  let primaryPhoneAttribute: ProfileAttributeFragmentStruct.AsPhoneAttribute?
  let otherProfileAttributes: [ProfileAttributeFragmentStruct]

  typealias OtherProfileAttributes = ProfileAttributeFragmentStruct
}

struct MutabilityInfoFragmentStruct: MutabilityInfoFragment {
  let isMutable: Bool
}

//////// }

//////// Conversions from any selection set with a fragment to bare structs for that fragment:
//////// This is probably more verbose than it needs to be, but it would be generated anyway.

extension ProfileAttributeFragmentStruct {
  var toProfileAttributeFragmentStruct: ProfileAttributeFragmentStruct {
    return self
  }
}
extension ProfileAttributeFragment {
  var toProfileAttributeFragmentStruct: ProfileAttributeFragmentStruct {
    return ProfileAttributeFragmentStruct(
      id: self.id,
      isVerified: self.isVerified,
      asEmailAttribute: nil,
      asPhoneAttribute: nil
    )
  }
}
extension ProfileAttributeFragmentStruct.AsEmailAttribute {
  var toProfileAttributeFragmentStruct: ProfileAttributeFragmentStruct.AsEmailAttribute {
    return self
  }
}
extension ProfileAttributeFragment_AsEmailAttribute {
  var toProfileAttributeFragmentStruct: ProfileAttributeFragmentStruct.AsEmailAttribute {
    return ProfileAttributeFragmentStruct.AsEmailAttribute(
      id: self.id,
      isVerified: self.isVerified,
      emailAddress: self.emailAddress)
  }
}
extension ProfileAttributeFragmentStruct.AsPhoneAttribute {
  var toProfileAttributeFragmentStruct: ProfileAttributeFragmentStruct.AsPhoneAttribute {
    return self
  }
}
extension ProfileAttributeFragment_AsPhoneAttribute {
  var toProfileAttributeFragmentStruct: ProfileAttributeFragmentStruct.AsPhoneAttribute {
    return ProfileAttributeFragmentStruct.AsPhoneAttribute(
      id: self.id,
      isVerified: self.isVerified,
      numberE164: self.numberE164)
  }
}
extension ProfileFragmentStruct {
  var toProfileFragmentStruct: ProfileFragmentStruct {
    return self
  }
}
extension ProfileFragment {
  var toProfileFragmentStruct: ProfileFragmentStruct {
    return ProfileFragmentStruct(
      id: self.id,
      primaryEmailAttribute: self.primaryEmailAttribute.toProfileAttributeFragmentStruct,
      primaryPhoneAttribute: self.primaryPhoneAttribute?.toProfileAttributeFragmentStruct,
      otherProfileAttributes: self.otherProfileAttributes.map { $0.toProfileAttributeFragmentStruct }
    )
  }
}
extension MutabilityInfoFragmentStruct {
  var toMutabilityInfoFragmentStruct: MutabilityInfoFragmentStruct {
    return self
  }
}
extension MutabilityInfoFragment {
  var toMutabilityInfoFragmentStruct: MutabilityInfoFragmentStruct {
    return MutabilityInfoFragmentStruct(isMutable: self.isMutable)
  }
}

//////// }

//////// Query types (includes fragments as protocols, implemented with maximum information) {
// Notice that PrimaryEmailAttribute as the additional fields from the query.
// It has two fragments and one additional field (normalizedEmailAddress).

class GetFullProfile {
  struct Data {
    let profile: Profile
    struct Profile: ProfileFragment {
      let id: String
      let primaryEmailAttribute: PrimaryEmailAttribute
      let primaryPhoneAttribute: PrimaryPhoneAttribute?
      let otherProfileAttributes: [OtherProfileAttributes]

      // Implements ProfileAttributeFragment and ProfileAttributeFragment_AsEmailAttribute,
      // adds the additional fields (`normalizedEmailAddress`)
      // Can always call .toProfileAttributeFragmentStruct
      // or .toProfileAttributeFragmentStruct to get only that fragment field.
      struct PrimaryEmailAttribute: ProfileAttributeFragment_AsEmailAttribute, MutabilityInfoFragment {
        let id: String
        let isMutable: Bool
        let isVerified: Bool
        let emailAddress: String
        let normalizedEmailAddress: String
      }

      // Single spread fragment and no additional fields. In this case, could
      // just typealias directly to that minimal type.
      // Alternatively, this could replicate the structs explicitly herethey'd
      // still conform to the relevant protocols and would be convertible.
      typealias PrimaryPhoneAttribute = ProfileAttributeFragmentStruct.AsPhoneAttribute
      typealias OtherProfileAttributes = ProfileAttributeFragmentStruct
    }
  }
}
//////// }

There are a lot of benefits to that.
When accessing fields directly, you get the full type/nullability guarantees that the schema actually provides for that specific query. You can have structs that are still related via protocol conformance (so you don't have to duplicate code when dealing with inline spreads).
And you still have access to fragment-only struct forms.
let x = GetFullProfile.Data(
  profile: GetFullProfile.Data.Profile(
    id: "14",
    primaryEmailAttribute: GetFullProfile.Data.Profile.PrimaryEmailAttribute(
      id: "email-123",
      isMutable: true,
      isVerified: false,
      emailAddress<EMAIL_ADDRESS>      normalizedEmailAddress<EMAIL_ADDRESS>    ),
    primaryPhoneAttribute: GetFullProfile.Data.Profile.PrimaryPhoneAttribute(
      id: "phone-321",
      isVerified: false,
      numberE164: "+15551234567"
    ),
    otherProfileAttributes: []
  )
)
print(x)

// You can still use concrete types, you just have to do toXXXFragmentStruct.
// This is the same as the current requirement of accessing through
// apollo-codegen's `.fragments` field.
func printConcreteAttributeInfo(_ a: ProfileAttributeFragmentStruct) {
  print(a.id)
}
func printConcreteProfile(_ a: ProfileFragmentStruct) {
  print(a.id)
  print(a.primaryEmailAttribute.emailAddress)
    if let phone = a.primaryPhoneAttribute {
    print(phone.numberE164)
  }
}
printConcreteProfile(x.profile.toProfileFragmentStruct)
printConcreteAttributeInfo(x.profile.primaryEmailAttribute.toProfileAttributeFragmentStruct)
if let phone = x.profile.primaryPhoneAttribute {
  printConcreteAttributeInfo(phone.toProfileAttributeFragmentStruct)
}

// Generics now supported, useful for fragments used in multiple places, or for
// type-refined sub-fragments maintaining an is-a relationship via protocols:
func printGenericProfile<F: ProfileFragment>(_ a: F) {
  print(a.id)
  print(a.primaryEmailAttribute.emailAddress)
    if let phone = a.primaryPhoneAttribute {
    print(phone.numberE164)
  }
}
func printAttributeInfo<F: ProfileAttributeFragment>(_ a: F) {
  print(a.id)
}
func printSomethingWithMutabilityInfo<F: MutabilityInfoFragment>(_ a: F) {
  print(a.isMutable)
}

printGenericProfile(x.profile)
printAttributeInfo(x.profile.primaryEmailAttribute)
printAttributeInfo(x.profile.primaryEmailAttribute.toProfileAttributeFragmentStruct)

// Multiple fragments/protocols supported in a selection set:

printAttributeInfo(x.profile.primaryEmailAttribute)
printSomethingWithMutabilityInfo(x.profile.primaryEmailAttribute)
print(x.profile.primaryEmailAttribute.isMutable)

// Can access full fields directly without having to deal with every single fragment:
print(x.profile.primaryEmailAttribute.emailAddress)
print(x.profile.primaryEmailAttribute.toProfileAttributeFragmentStruct.emailAddress)
if let phone = x.profile.primaryPhoneAttribute {
  print(phone.toProfileAttributeFragmentStruct.numberE164)
  print(phone.numberE164)
}

I think we might be talking past each other slightly, I apologize…

I did get what you were proposing, but I should have commented on the second part explicitly to make that clear, sorry.

You wouldn't be losing any capability that's already there, you'd only be gaining the ability to have more refined types available.
You can still use concrete types, you just have to do toXXXFragmentStruct. This is the same as the current requirement of accessing through apollo-codegen's .fragments field.

This isn't really about losing a capability, but about adding complexity for users. I think asking people to use toXXXFragmentStruct every time they want to store a fragment in an instance variable, and to remember they'll have to type the variable as XXXFragmentStruct instead of XXXFragment, is too much of a burden and will make the code hard to understand.
Using .fragments has the benefit of offering a clear conceptual model; it is more than a workaround. If you see fragments not just as a way of reusing selections but as an abstraction mechanism, there is a benefit to Relay-like data masking (https://facebook.github.io/relay/docs/thinking-in-relay.html#data-masking), which hides data defined in fragments from the parent. This way, child components define their own data dependencies, and if parents need the same data they'll have to ask for it themselves.
Looking at the queries you used as an example, I can see how keeping fragments separate and accessing them through .fragments is a pain. But I would suggest simplifying them by getting rid of  ProfileAttributeFragment and MutabilityInfoFragment, and by inlining selections:
fragment ProfileFragment on Profile {
  id
  primaryEmailAttribute {
    id
    isVerified
    emailAddress
    normalizedEmailAddress
  }
  primaryPhoneAttribute {
    id
    isVerified
    numberE164
  }
  otherProfileAttributes {
    id
    isVerified
  }
}

query GetFullProfile {
  profile {
    ...ProfileFragment
    primaryEmailAttribute {
      isMutable
    }
  }
}

I would argue the resulting query and fragment are a lot clearer and easier to deal with.
If you need to treat primaryEmailAttribute, primaryPhoneAttribute, and the individual otherProfileAttributes as instances of a shared type, you can still define a protocol and make them conform to it manually. I think that is perfectly acceptable; not everything needs to be solved at the GraphQL level.

Just came across this, sounds like it might solve our issues if it lands!
https://github.com/apple/swift/pull/8718

I think asking people to use toXXXFragmentStruct every time they want to store a fragment in an instance variable, and to remember they'll have to type the variable as XXXFragmentStruct instead of XXXFragment, is too much of a burden and will make the code hard to understand.

The current API could be emulated:
protocol GetProfileFragmentStruct {
}
extension ProfileFragment {

}

I think asking people to use toXXXFragmentStruct every time they want to store a fragment in an instance variable, and to remember they'll have to type the variable as XXXFragmentStruct instead of XXXFragment, is too much of a burden and will make the code hard to understand.

I believe the current API could be replicated by making a getter for .fragments.profileFragment which does the same operation as .toProfileFragmentStruct in the example above. This, I think, would allow all or nearly-all current code to behave the same.
I believe that the API could be designed to avoid requiring any user-facing complexity beyond the current generated code, but maybe I'm wrong.
As for refactoring the GraphQL query itself, I know that can be done—but it's undesirable for two reasons:

It's inconvenient that pure-refactors of the GraphQL query (i.e. refactors that do not alter the guarantees of the returned structure) forces the user-facing code to also be refactored.
In the real-life case of the example above, there are 6+ "ProfileAttribute" types, which are used either concretely or through the interface in nearly a dozen queries. (Sometimes directly, sometimes as children of another fragment). Being required to inline them is error-prone and completely negates the benefits of named fragments.

It does look like covariant protocol conformance would help here…but I'm not entirely certain. Structs need to have known sizes to be stored, so if I understand correctly, covariance protocol conformance would still require generics to be passed around. I might be misunderstanding that, though.

I believe the current API could be replicated by making a getter for .fragments.profileFragment which does the same operation as .toProfileFragmentStruct in the example above. This, I think, would allow all or nearly-all current code to behave the same.

Well, you'd still need to type the variable as XXXFragmentStruct instead of XXXFragment if you're storing the result or passing it around.

It does look like covariant protocol conformance would help here…but I'm not entirely certain. Structs need to have known sizes to be stored, so if I understand correctly, covariance protocol conformance would still require generics to be passed around. I might be misunderstanding that, though.

If you're referencing a struct through a protocol, that always requires an existential container, and covariance doesn't change that. There should be no need to make the type generic.
See here for a nice writeup of the difference between the use of an existential container and generic methods.


MAINT: Renaming to virsorter2

This PR deals with the renaming of the repo to q2-virsorter2
Set up the environment
mamba create -n q2-virsorter2 -c conda-forge -c bioconda -c https://packages.qiime2.org/qiime2/2023.7/core/passed/  -c defaults q2-types numpy=1.23.5 q2cli virsorter=2 "python=3.8" scikit-learn=0.22.1 pandas seaborn hmmer==3.3 prodigal=2.6 screed=1 ruamel.yaml click pip last ncbi-genome-download pyhmmer

Activate q2-viromics environment
conda activate q2-virsorter2

Clone the repo and checkout the PR branch
git clone https://github.com/bokulich-lab/q2-virsorter2.git
cd q2-virsorter2
git fetch origin pull/9/head:pr-9
git checkout pr-9
pip install -e .

Test
qiime virsorter2

Hey @VinzentRisch,
Can you have a look at this PR? There is a problem with the CI coverage but leave this to me.


Drill 3947

Abhishek,
I verified drill-3947 and added some test cases. The dataset for these test cases should contain more than 4096 auto partitioned files to reproduce the issue. So there are lot of new small data files added as part of this commit. The functional run passed without any issues. Let me know your thoughts

Rahul

Hey Rahul, I think we should take a look at this together in person. Github doesn't show me any changes made, since the number of files are so many. I tried looking at your branch, but its just the same.

Sure!

As discussed, looks good. +1


remove schema_name from information_schema tables

@mfussenegger please review

Current coverage is 81.03% (diff: 85.71%)

Merging #4349 into master will decrease coverage by 0.03%

@@             master      #4349   diff @@
==========================================
  Files          1306       1306
  Lines         44264      44250    -14
  Methods           0          0
  Messages          0          0
  Branches       7030       7030
==========================================
- Hits          35885      35858    -27
- Misses         5721       5726     +5
- Partials       2658       2666     +8

Powered by Codecov. Last update 41c5876...cb9f076


iOS navigation connection with real app

Don't really know what is going on here, So I will wait for review from @grabbou also before I merge

LGTM, this is work we have done together to expose interface for mobile app to integrate with React Native. Previous approach was good, but there were certain limitations we have to overcome.


tour: Wrong comment

Context: https://tour.golang.org/moretypes/1
*p = *p / 37   // divide j through the pointer

That's not true. That code divides j by 37. 37 is not the pointer.

It doesn't say "divide j by the pointer", it says "divide j through the pointer" -- that is, divide j by accessing it through the pointer. Seems fine to me.

Maybe s/divide/access ?

I think it's fine. It doesn't say "by the pointer". It says "through the pointer". At least in English, we would never say "divide j through 37".


Extract test framework

This pull request contains the extracted test framework.

Reviewed.

Oh, why you published a package before pull request was reviewed and merged. :-(

Oh, why you published a package before pull request was reviewed and merged. :-(

I had to test this, can't the published packages just be updated?

I had to test this, can't the published packages just be updated?

Yet it can, but it cannot be renamed. There is also something called "release candidate" release. Don't worry. I am just asking as a general principle.
You could test it by using it as a git submodule.

Why force push?

I amended the existing commit.

We do not really do that. Just add to the branch.

LGTM.


Coral Extract Workflow seems to be creating duplicate records in FOLIO

From Lisa F.

Right now there are 1440 Source = Coral items in FOLIO.   The script that produces this needs some tweaking?  I think it needs to search all records, not just Mode of issuance = integrating resource – to determine if there is already a record in FOLIO for the publication.
For example, for ‘Academic video online” there is already record in00003934156 with Coral ID = 10549, but a short coral record was produced on in00004731711

We need to identify why these duplicates are being created, and modify the workflow logic to ensure that this no longer occurs.
It could be that these duplicates are the result of the workflow having failed som many times. If this is the case, remediation of the data is all that is needed, now that we have addressed the permission issue.

It appears that this issue is no longer occurring


Vertical lines on axes inline with layoyt ticks in Scatter chart

Hi,
Is there a way to show vertical lines on axes connecting to center of the chart inline with ticks on the layout. I attached the pic as an example.

Please let me know. Thanks.

@kkknet I tried playing with ticks but it's not possible to use them as your use case. So I don't see anyway for now

@nicgirault Thank you for checking.


Refactor metrics in the IOOS_BTN.ipynb notebook

@MathewBiddle these are the first functions I extracted from IOOS_BTN.ipynb. I'll do the rest soon but I'd like to get your input before moving forward with this idea. For now you can run it with:
from ioos_metrics.ioos_metrics import update_metrics

df = update_metrics()
df.dropna(axis=1)

When we have all the metrics as their own function we can:

have a main script that collects them all and create the same output from the notebook
test them individually in the CIs with a cronjob so w catch breakages earlier
run automate code quality/lints on the individual scripts

This will also be easier to maintain and review as individual pieces. Here, for example, I removed on dependency (bs4) , two extra steps, and fixed a pandas deprecation when creating the table to make it future proof.

I like the direction this is going. Thanks @ocefpaf. I'd like to test this locally before I say anything else, however.

@ocefpaf this is looking good. Did you want to add any more to this PR, or should we merge and move to the next batch?

@ocefpaf this is looking good. Did you want to add any more to this PR, or should we merge and move to the next batch?

Let's merge and move to the next batch. I have a few extra commits here that could use a rebase and a new PR to avoid confusion.


ngAfterContentInit executed twice

I'm using directives to mark components as content items for example, *contentItem and then using that as a way for @ContentChildren(ContentItemDirective) to pick up only those components for rendering.
The problem is, those children marked with *contentItem have their ngAfterContentInit executed twice even though the component is only rendered once. Since we start event listeners on an EventBus during ngAfterContentInit, we end up having duplicate event listeners on the bus causing things to happen twice. For example, a toast popup saying busy saving / done saving now gets display twice since we have two listeners created on the bus. Once the component gets destroyed, both listeners are also destroyed at the same time.
The suggestion was that in dev mode, things are checked twice and in production it doesn't check for side-effects. I've experienced the same behavior in production as well, so not sure if that's related. Some other suggestions said that if there's a template error, ngAfterContentInit will get executed twice. I stripped down the HTML to the bare minimum and can't see anything that's blatantly wrong in the template.
Currently on Dart 1.24.2 and Angular 3.1.0
I've submitted a very detailed StackOverflow question:
https://stackoverflow.com/questions/44832253/stop-ngaftercontentinit-from-executing-twice
Reproduced in Dartium on both Windows10 and OSX as well as on Chrome (latest), I don't think this is browser related.
I've published a sample project here which will reproduce the problem:
https://github.com/jVaaS/stackoverflow/tree/master/ngaftercontentinit
Run the project with pub serve and observe in the console that >>> ngAfterContentInit: Demo is printed twice.
In the meantime, is there a workaround for this? Maybe another Angular hook where we can wire in our EventBus where it won't get wired in twice?

It's like you have an exception occurring somewhere:
https://github.com/dart-lang/angular/blob/master/doc/crash_detection.md

I've stripped away almost everything, there's not much code left where it can fail. How would one go about detecting such an exception?

@matanlurey , I'm just following up, does needs info mean you're waiting for more info from me?
If it's a mechanism to reproduce the problem that's outstanding, I've added that info in the github repo: https://github.com/jVaaS/stackoverflow/tree/master/ngaftercontentinit

@janvladimirmostert Taking a look!

This doesn't seem like a bug.
Here is the generated code for demo.dart:
https://gist.github.com/matanlurey/f311d90053e36cc09c6e28f28ab2d4cd
  void detectChangesInternal() {
    bool firstCheck = identical(this.cdState, ChangeDetectorState.NeverChecked);
    final _ctx = ctx;
    if (!import8.AppViewUtils.throwOnChanges) {
      dbg(0, 0, 0);
      if (firstCheck) {
        _Demo_0_2.ngAfterContentInit();
      }
    }
    _compView_0.detectChanges();

I was suspicious, so I changed your print message to include the hashCode:
	@override
	ngAfterContentInit() {
		print(">>> ngAfterContentInit: Demo $hashCode");
	}

Then I saw the following:
> ngAfterContentInit: Demo 516575718
> ngAfterContentInit: Demo 57032191

Which means two diffferent instances of demo were alive, not just one emitting twice. I then added StackTrace.current to the constructor of demo to get a stack trace:
Demo() {
		print('Created $this:$hashCode');
		print(StackTrace.current);
	}

And got:
#0      Demo.Demo (package:bugdemo/demo.dart:11:20)
#1      ViewBuggyApp1.build (package:bugdemo/buggy-app.template.dart:136:21)
#2      AppView.create (package:angular2/src/core/linker/app_view.dart:180:12)
#3      DebugAppView.create (package:angular2/src/debug/debug_app_view.dart:73:26)
#4      TemplateRef.createEmbeddedView (package:angular2/src/core/linker/template_ref.dart:27:10)
#5      ViewContainer.createEmbeddedView (package:angular2/src/core/linker/view_container.dart:86:43)

Which in turn said your component was being created by BuggyApp's template:
		<standard-layout>
			<demo *contentItem></demo>
		</standard-layout>

Closer. Kept digging.
I commented out ContentItemDirective, and saw Demo was now created once. I imagine you expected it not to be created at all due to *contentItem, so kept digging - and finally figured it out.
Your StandardLayout component creates templates:
		<div *ngFor="let item of contentItems ?? []">
			<template [ngTemplateOutlet]="item.template"></template>
		</div>
``

But so does your `ContentItemDirective` via _ComponentResolver_. I imagine you did not intend this. So I'd figure out what you were trying to do and address your issue by removing creating the component in one of these places.

This is brilliant, you've given me the tools to detect such problems in the future, thanks @matanlurey !
So creating the component inside the ContentItemDirective via component resolver is intentional, I have about 7 different directives each creating components (ContentItemDirective, FooterItemDirective, SideBarItemDirective, etc).
I had no idea <template [ngTemplateOutlet]="item.template"></template> was creating another instance, I was under the impression it was merely displaying the component already created inside the ContentItemDirective
How do I display these components [that are created by the directive] inside the standard layout without creating another instance? Or is it possible to tell ngTemplateOutlet that it should use the existing component instead of creating another one?
I have an open bounty on the StackOverflow question that you can claim:
https://stackoverflow.com/questions/44832253/stop-ngaftercontentinit-from-executing-twice

@janvladimirmostert Thanks. Done as https://stackoverflow.com/questions/44832253/stop-ngaftercontentinit-from-executing-twice/44930521#44930521.


Cannot delete folder with instance of AGSAdministration

def admin_access():
	'''admin access to ags'''

	from arcrest.manageags import AGSAdministration
	from arcrest import AGSTokenSecurityHandler

	url = "http://localhost:6080/arcgis"
	sh = AGSTokenSecurityHandler(username="psa", password="psa", org_url=url)

	my_ags = AGSAdministration(url, sh)

	folder_name = "newFolderTest"
	print my_ags.services.createFolder(folder_name, description='new folder added')
	#{'status': 'success'}

	print my_ags.services.deleteFolder(folder_name)
	#500 [u'1']
	#{'status': 'error', 'code': 500, 'messages': ['1']}

admin_access()```

I have figured out the problem. In the _services.py file, the function deleteFolder
uURL = self._url + "/%s/delete" % folderName
should be deleteFolder instead of delete in the REST url:
uURL = self._url + "/%s/deleteFolder" % folderName
When changed to ````deleteFolder```, the code works as expected.
Link to the REST API Help Delete Folder page: http://localhost:6080/arcgis/admin/www/doc/index.html#/Delete_Folder/02w00000002q000000/

fixed on the next commit


Use standart ActiveRecord error message for email uniqueness validation

According to the Rails Guides there already is a localization for the uniqueness validation. And the key is :taken.
So if one wants to provide his own translation, he should redefine one of the keys in the following order:
activerecord.errors.models.user.attributes.email.taken
activerecord.errors.models.user.taken
activerecord.errors.messages.taken
errors.attributes.email.taken
errors.messages.taken

LGTM!

thanks @mpugach


List matlab files variables (scipy.io.matlab)

The new function whosmat tries to resemble the matlab 'whos' command. At the moment it gives a list of (name,shape) tuples.
I thought of writing this, to avoid loading the whole .mat file to know the names of variables, sometimes the .mat files can be really huge.
Regards!

Looks good.
I'm wondering about the <7.3 support (in general, not just this function), because fewer and fewer people will have a Matlab from before 2006. It may be useful to support more recent versions in the same functions with an optional dependency on pytables or h5py. Do you happen to know how much work that would be? Presumably it's a lot easier for hdf5 files.


Decoding in conv seq2seq

In the convolutional sequence to sequence learning, the decoder input should be masked or the conv kernel should be casual. The model can not see future information when doing incremental decoding.
I have problems when dealing with the teacher forcing problems in conv seq2seq so I found this repo for help. Will the full inference function realized in the future? Thx～

Yep, I do plan to implement inference into the conv seq2seq model. Hopefully will have some time during this week!

Thank you !
Also I noticed that in fairseq version of ConvSeq2seq they decode the whole sentence at a time and transform the convolution block to linear when infer, which is called linearized_convolution.
They also use ConvTBC which is an alternative version of Conv1d to do temporal convolution without any mask operation, both in encoder and decoder.
I have no idea why they do so.


Promises and asynchronous loading of mesh and texture.

Currently, the landmarker makes many synchronous expensive trips to the server in order to display a textured mesh.
The following two synchronous steps happen when the landmarker loads to cache thumbnails for rapid browsing.

GET /images/assetid - just to find out the size of the image, and if there is one.
GET /thumbnail/assetid - load the thumbnail, now we know the size.

And then, once a new asset is loaded...

GET /meshes/assetid - load the actual mesh geometry
GET /textures/assetid - synchronously load the texture after the fact. Note that only a texture can be placed on a mesh, a thumbnail is just shown as an image placeholder.

Over a slowish-secure connection this number of round trips makes the experience of using the landmarker pretty sluggish.
As a solution to this problem, I've started work on a branch which instead makes the loading of assets totally asynchronous in the landmarker. In the new solution:

The call to GET /images/assetid is eliminated. We just get the image and inspect it to find it's size.
The calls to GET /meshes/assetid and GET /textures/assetid happen asynchronously. If the texture is absent the thumbnail is used as a texture to the mesh - once the texture loads the thumbnail is replaced.

This really improves the perception of the landmarker 'feeling' fast. The work is ongoing and unfortunately had to be left up in the air before I went on vacation, but is largely complete. I would like to revisit it shortly before it bit rots away.

implemented in release now, see fcd4208778a4dad51c39a63208537a0ec00ddba9 for key changes.


Issue: App running slow on a specific armeabi-v7 Device

Details
So I was testing my application on this, and noticed it was unbearably sluggish.
I tried installing a version specific to armeabi-v7 by using split, but to no luck. After which I though maybe it was something wrong with my code so create a fresh new project and tried installing it. This also resulted in the same performance issue.
I know this is an OEM device and wouldn't be in the testing suite, but I just wanted to know if there is something that can be done, or else if this is a lost case.

Target Platform: Android
Target OS version/browser: API 23
Devices: SystemView 10”
Logs

Logs

> flutter analyze
Analyzing nube_mqtt_dashboard...

   info • The value of the field '_page' isn't used • lib/application/layout/pages/pages_cubit.dart:12:20 • unused_field

1 issue found. (ran in 12.4s)

[✓] Flutter (Channel stable, 1.22.5, on Linux, locale en_AU.UTF-8)
    • Flutter version 1.22.5 at /home/hill/snap/flutter/common/flutter
    • Framework revision<PHONE_NUMBER> (5 weeks ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/hill/Android/Sdk
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /home/hill/Android/Sdk
    • Java binary at: /home/hill/Downloads/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.
[!] Android Studio
    • Android Studio at /home/hill/Downloads/android-studio
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • android-studio-dir = /home/hill/Downloads/android-studio
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
[✓] VS Code (version 1.52.1)
    • VS Code at /usr/share/code
    • Flutter extension version 3.18.1
[✓] Connected device (1 available)
    • EasyIO SystemView10 (mobile) • 20080411 • android-arm • Android 6.0.1 (API 23)
! Doctor found issues in 1 category.

Export from Observatory (In txt cause I couldn't include json)
dart-timeline-2021-1-12.txt

Video Export

Hi @riteshakya037
Can you please provide your flutter run --verbose, the actual vs expected results and a minimal complete reproducible code sample?
Thank you

Hi @riteshakya037
Can you please provide your flutter run --verbose, the actual vs expected results and a minimal complete reproducible code sample?
Thank you

I can send you the verbose next working day, since I don't have the device at hand atm.
My main concern is that even the starting flutter counter app runs a sluggish. I've attached a video recording of the starter app.

I can send you the verbose next working day, since I don't have the device at hand atm.
My main concern is that even the starting flutter counter app runs a sluggish. I've attached a video recording of the starter app.

As promised I have attached flutter run --verbose logs. As for the minimal complete reproducible code sample, the delay is throughout the app so, it's not like its a piece of code.
actual_app_verbose_logs.txt
Here's the export of Observatory for the sample counter app running on the tablet.

dart-timeline-2021-1-13 Counter App.txt

As promised I have attached flutter run --verbose logs. As for the minimal complete reproducible code sample, the delay is throughout the app so, it's not like its a piece of code.
actual_app_verbose_logs.txt
Here's the export of Observatory for the sample counter app running on the tablet.

dart-timeline-2021-1-13 Counter App.txt

Is this generally reproducible on Android API 23? It will be difficult to root cause this without the hardware. It's possible that it's due to the hardware itself; it looks like that platform is based on a 7-year-old SOC. We may just not be able to perform adequately on it.  As filed, we're afraid this isn't actionable.

Is this generally reproducible on Android API 23? It will be difficult to root cause this without the hardware. It's possible that it's due to the hardware itself; it looks like that platform is based on a 7-year-old SOC. We may just not be able to perform adequately on it.  As filed, we're afraid this isn't actionable.

@kf6gpe Thanks for the response. As you mentioned it isn't reproducible on API 23. And since it is most probably because of the outdated SoC the best approach would be to upgrade the hardware and move forward anyways.

@kf6gpe Thanks for the response. As you mentioned it isn't reproducible on API 23. And since it is most probably because of the outdated SoC the best approach would be to upgrade the hardware and move forward anyways.


chore(workflows): Adds workflow to release hotfix version

WHAT
Adds a temporary workflow to enable the release of bugfix versions.
This workflow should be reworked as it contains duplicate code from draft-new-release and publish-new-release.
This workflow, as is, should be executed after the hotfix branch is created and all needed PRs are merged
WHY
To release 0.7.4 and since the current publish-new-release workflow doesn't work for hotfix releases.
FURTHER NOTES

The workflow should be released manually and only runs for branches that match the hotfix/* pattern.
The workflow doesn't merge to main. It also doesn't update the project version.
The workflow also creates the "Prepare Release X.Y.Z" commit that changes the version in all needed files to the one provided as workflow input (similar to draft-new-release workflow).
A validation job was added as entry gate to verify if a tag already exists for the input provided on workflow dispatch.
The released version will not be the latest.

@paullatzelsperger
Thanks for your review. I'll comment here since i'll address most comments still unanswered.
The idea of this PR was to have a working version of the publish-new-release workflow that functions for hotfix releases.
I avoided changes to existing jobs/steps as much as possible to avoid breaking them since fixing GH workflows by running them countless times isn't a great experience.
Yes its true somethings need rework: probably unnecessary use of variables, unnecessary jobs, probably unnecessary permissions.
Since we are refactoring the workflows afterwards anyway i left it for that PR and not this one...

I understand that this is supposed to be a temporary workflow, but once these kinds of things are in the code base, they have a habit of remaining there, or be used as reference later. So I'd rather have a temporary, clean WF now, of which we could - in good conscience - borrow elements later.

since fixing GH workflows by running them countless times isn't a great experience.

I'm sorry, but "it's hard/annoying to do" isn't a valid reason IMO.

I'm also not an adept of doing half-solutions, and I do understand your point that "there isn't a more permanent solution than a temporary one". As with everything, there are exceptions and considering a permanent solution is imminent this was one of them.
I'll consider your previous comments and adjust the pr.

@wolf4ood @paullatzelsperger
Thanks for the review. Can you merge it? I'll open another PR to replicate this exact WF in main, so we can run it from the Actions tab.

I'll open another PR to replicate this exact WF in main, so we can run it from the Actions tab.

I don't think we need this in main, since we are currently between versions, and we should have enough time to get the "proper" solution in.


Fixes #1079: Introduce a logging module enum so the callers can simpl…

…y call the qd_log() function using this enum instead of calling it with log source.

Tested using flimflam
LOGGING-REFACTOR branch
RUN 1
=====
Duration:   5s
Bits:       21.4G
Bits/s:     4.3G

RUN 2
=====
Duration:   5s
Bits:       20.6G
Bits/s:     4.1G

RUN 3
=====
Duration:   5s
Bits:       22.4G
Bits/s:     4.5G

================================================

MAIN branch
RUN 1
=====
Duration:   5s
Bits:       22.2G
Bits/s:     4.5G

RUN 2
=====
Duration:   5s
Bits:       20.7G
Bits/s:     4.1G

RUN 3
=====
Duration:   5s
Bits:       21.6G
Bits/s:     4.3G


Schematic está incompatível com Angular 12.x

Passos para reprodução

Instalar ou fazer upgrade para Angular 12.x
Executar schematic com ng add @wizsolucoes/angular-starter

Comportamento atual:
A execução do schematic falha:
$ ng add @wizsolucoes/angular-starter
ℹ Using package manager: npm
✔ Found compatible package version<EMAIL_ADDRESS>✔ Package information loaded.

The package<EMAIL_ADDRESS>will be installed and executed.
Would you like to proceed? Yes
✔ Package successfully installed.
"AngularStarterSchematics" schema is using the keyword "id" which its support is deprecated. Use "$id" for schema ID.
? Essa aplicação é 'White-Label'? Yes
Cannot read property 'configurations' of undefined

Comportamento esperado:
O schematic deve executar com êxito. Com as versões suportadas do Angular: 10.x, 11.x, e 12.x

Closed by https://github.com/wizsolucoes/angular-starter-schematic/pull/76


Add CLN config option to disable BTC swaps

This adds a config option for the [Bitcoin] section in peerswap.conf that disables BTC mainchain swaps so nodes can choose to only swap L-BTC if they desire. The existing behavior of enabling BTC swaps if there are no config options set, or if peerswap.conf doesn't exist, is also maintained.
Example:
[Bitcoin]
bitcoinswaps=false

Added documentation to setup_cln.md, clarified the commit message, and squashed the two initial commits.

I changed my mind. It looks bad to have the same config option look different in the [Bitcoin] and [Liquid] sections. Please rename Bitcoin's option to simply "enabled" to make it match.

Confirmed this patch does the right thing. Just rename the CLN option and it's ready.


replace "table" with dplyr::tbl()"

Unless I'm mistaken, we don't need the "table" function in db, we can manage with just straight dplyr::tbl.

@SimonGreenhill I hope it's okay that I merge this since Forkel has approved it.


Rethink about the avatar and status design on the new Global Nav

🚨 This issue is for the internal design team. Please DO NOT post proposals.
The new navigation panel (Global Nav) was added to NewDot. Some components on the Global Nav turned out to be cropped because of the limited space.
Please refactor the designs of these components if necessary.
Please see:

this issue where a button is cropped on the new Global Nav

this issue where the Avatar with a status is cropped on the new Global Nav

Convo happening here. This were variations for status:

And for public rooms:

Let me know if anything is needed here. Think consensus in Slack seemed to be that the status bar with the smaller emoji was the right one rather than vertically stacked

Not overdue, just awaiting confirmation

sorry for the delay in response. yes we can close this issue for now. thank you so much for working on the high fidelity!


Fix comparison between mismatched enums

This fixes the following warning:
src/API/LimeSDR_mini.cpp: In member function ‘virtual int lime::LMS7_LimeSDR_mini::Calibrate(bool, unsigned int, double, unsigned int)’:
src/API/LimeSDR_mini.cpp:163:44: warning: comparison between ‘enum lime::LMS7002M::PathRFE’ and ‘enum<unnamed>’ [-Wenum-compare]
     wr_val |= lms_list[0]->GetPathRFE() == LMS_PATH_LNAW ?  0x100 : 0x200;
                                            ^~~~~~~~~~~~~

This still worked because the enums it was comparing between happened to have the same value for the LNAW path, but comparing raw values between enums is generally not a good idea because in doing so you lose all the benefits of type-checking.

The enum values in LimeSuite.h were were specifically made to match LMS7002M::PathRFE. and in this place LMS_PATH_LNAW was probably used for consistency with LMS_PATH_TX2 above it. But I see no problem in changing it.


undefined local variable or method 'machine_specs'

Hi,
I get the above error when I execute chef provision --no-policy -r ostest
my provision recipe: (sensitive Data removed)
require 'chef/provisioning'

with_chef_server "http://localhost:7799",
  :client_name => Chef::Config[:node_name],
  :signing_key_filename => Chef::Config[:client_key]

machine 'foobar' do
  machine_options({
      :bootstrap_options => {
          :image_ref => 'stuff',
          :nics => [{ :net_id => 'stuff'}],
          :key_name => 'automation',
          :floating_ip_pool => 'stuff'
      },
      :ssh_username => 'test'
  })
  action :setup
end

my knife.rb: (sensitive data  removed)
current_dir = File.dirname(__FILE__)
log_level                :info
log_location             STDOUT
cookbook_path            ["#{current_dir}/../cookbooks"]

driver 'fog:OpenStack'
driver_options :compute_options => {
    :openstack_auth_url => 'https://foobar:5000/v3',
    :openstack_username => 'stuff',
    :openstack_api_key  => 'stuff',
    :openstack_tenant   => 'stuff'
}

chef_server_url 'http://localhost:7799'
node_name       'foobar'
local_mode true
chef_zero.enabled true

Chef Zero is running on the port and responding to requests
I hope it is just a pebkac

no idea?

@mrmarbury Sorry for the late response. This was fixed in 0.26.1, which is in the latest chefDK 2.x and 3.x


dotnet/docs/blob/master/styleguide/template.md is misleading in term of metadata rendering

Issue description
https://github.com/dotnet/docs/blob/master/styleguide/template.md is misleading in term of metadata rendering.
I found this document very useful for my own purpose but in fact it may be outdated on one point:

Metadata and Markdown Template
This dotnet/docs template contains examples of Markdown syntax, as well as guidance on setting the metadata. To get the most of it, you must view both the raw Markdown and the rendered view (for instance, the raw Markdown shows the metadata block, while the rendered view does not).

As you can notice by viewing this file, it seems github renderer saw some unfortunate changes since this document has been written, leading to metadata being rendered against the initial will.
Do you know if this change will be reverted or fixed?
Best regards

Guys, you realize you didn't fix anything to the problem here?
You didn't fix the wrong GitHub renderer by changing a bit the documentation and the metadata is still rendered. Well, that's a kind a fix, though. I would have taken another approach to it.

Can't. That is the way github renders YAML headers.

Indeed. Makes sense on some manner.
Thanks

Really the point about checking both the preview and the source is to understand how the markdown syntax styles the output. The header note was definitely not needed. So thank you for pointing that out. 👍


Use generated TokenSpecSets in ASTGen

https://github.com/apple/swift/pull/67111/files#diff-e513d3adfa93904a74cb6d3e8ac3ae4701ed41ccaa0461428708231d8aee5b63R469-R482 basically re-implements ImportDeclSyntax.ImportKindSpecifierOptions (https://github.com/apple/swift-syntax/blob/452e07df5459309a10766e4a7f9f67f74bd23763/Sources/SwiftParser/generated/Parser%2BTokenSpecSet.swift#L1663-L1672).
ASTGen should use ImportDeclSyntax.ImportKindSpecifierOptions. For that, we need to

Decide whether to move ImportDeclSyntax.ImportKindSpecifierOptions to SwiftSyntax or whether it should stay in SwiftParser
Check if we need to add a new initializer to the generated TokenSpecSet that ASTGen can use.

Hey, is this issue still open?

Yes, we still switch over all the keyword kinds here
https://github.com/swiftlang/swift/blob/d9f7d94ae9969f52d115c501a0846321f850026c/lib/ASTGen/Sources/ASTGen/Decls.swift#L794-L805

I am interested in working on this, but since I am relatively new to open source, I would appreciate it if you could provide me with a bit more context.


feat:adjust histogram buckets

The default histograms buckets are not providing the level of detail we need to track our services. We should change them to more suitable values.

Thanks for this @oliverpauffley however I would like to see some documentation / reasoning behind those values.
As it stands, these are magic numbers, and I don't know what they refer to, or whay their significance is.
Could you please add some comments and perhaps something in the readme for the middleware that details this?

Haha, I asked the same thing.
Changes look good @oliverpauffley


nag : fix nag defects - missing fco records and e.t.c

Duplicate code is still there

forgot to push that file change done now


Add ftplugin for Elixir

This primarily sets the commentstring for Elixir files. Now that elixir is detected by Vim, it makes sense to add this functionality and reduces the need for external plugins.
Thank you for considering this patch 🙇.

Thanks, I'll include it.  There actually is no need to save and set cpo, since there is no line continuation.


async/await

[Babel transform: enabled]
Input:
async function x() { return 100 }
await x()

Output:
SyntaxError:  Unexpected token function

Expected output:
100

However if you code only this line:
async function x() { return 100 }

you get no error (right) and x() returns a promise (right).
Then, if you code this line:
await x()

you get another promise (!) and it should return 100.

@pmros async auto wrapper for awake is handled for simple pattern as below:
await expression

and it will transformed to
(async function() { let result = (await expression); return result; }())

If you feed expressions one after another, you will get expected result(pull latest code).

It would be nice if you could enable/disable await wrapper at preference panel.

@pmros In your case, it was not wrapped since its not a candidate for wrapping and await is not valid construct outside async.

I understand. What I was trying is something like this:
(async function() {
async function xxx() { return 10 }
return await xxx();
})().then(x => console.log(x))

On Tonic you get the same result just coding this:
async function xxx() { return 10 }
await xxx();

I guess Tonic autowrap all your input code.
Whatever it's OK for me now I know how it works. Thank you.

Contextify the wrapped calls is the challenge. Tonic has no such problem (I guess).

Merged to master


Update nf-hidsdi-hidd_getphysicaldescriptor.md

Add info on HID Physical Descriptors from USB HID spec.

@DJm00n thank you for helping to clarify!


Setting for Logging Level

[x] Have you signed the Contributor License Agreement?
[x] Are you working against an Issue?

Resolves #1940
This is my first time really digging into the codebase, so I wouldn't be surprised if this is entirely incorrect.
This PR allows users to set their preferred logging level to any of the levels available with the default remaining Info. This preference is overridden by the use of --verbose-logs
Tested: Manually + Unit Tests

Microsoft Reviewers: Open in CodeFlow

/azp run

/azp run

@denelon - Another instance of CLA outage;
Previous PR's - https://github.com/microsoft/winget-cli/pulls?q=is%3Apr+author%3ATrenly and all of the winget-pkgs ones

/azp run

Putting this here as CLA verification -

Let me try close and reopen. If this does not work, I'll have to edit project settings to override the policy.


Correct typo in word2vec.py

Can one of the admins verify this patch?

I signed it!

You might also want to make this change to the master branch.


[feature] a grpc sample request

Can the kfserving support grpc and http invoke in one inference service?  Is there a sample?

@edenbuaa No, currently it is not possible due to knative limitation https://github.com/knative/serving/issues/8471


Running vagrant up hangs on NFS mounting (Vagrant 1.4.3)

Vagrant hangs when booting this image while attempting to mount the NFS path. I'm not positive, but I believe Vagrant is failing at OS detection and executing /etc/init.d/nfs-kernel-server on the client. Running Linux Mint (Debian / Ubuntu) on the host.
$ vagrant -v
Vagrant 1.4.3
$ ls
Vagrantfile
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2200 (adapter 1)
[default] Running 'pre-boot' VM customizations...
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
[default] Configuring and enabling network interfaces...
[default] Exporting NFS shared folders...
Preparing to edit /etc/exports. Administrator privileges will be required...
sudo: /etc/init.d/nfs-kernel-server: command not found
[default] Mounting NFS shared folders...

I can, however, kill the boot process, then vagrant ssh to get in (the filesystem of course isn't mounted):
Preparing to edit /etc/exports. Administrator privileges will be required...
sudo: /etc/init.d/nfs-kernel-server: command not found
[default] Mounting NFS shared folders...
^C[default] Waiting for cleanup before exiting...
^C[default] Exiting immediately, without cleanup!
$ vagrant ssh
Last login: Mon Feb 24 17:41:56 2014 from <IP_ADDRESS>
FreeBSD 10.0-RELEASE (GENERIC) #0 r260789: Thu Jan 16 22:34:59 UTC 2014

                                       _    _
                 __      ___   _ _ __ | | _(_)  ___  _ __ __ _
                 \ \ /\ / / | | | '_ \| |/ / | / _ \| '__/ _` |
                  \ V  V /| |_| | | | |   <| || (_) | | | (_| |
                   \_/\_/  \__,_|_| |_|_|\_\_(_)___/|_|  \__, |
                                                         |___/

Email<EMAIL_ADDRESS>Twitter: @wunki

Tip of the day:
--------------------------------------------------------------------------------
[vagrant@vagrant-freebsd-10 ~]$

I've tried everything suggested here and my box still hangs on
==> default: Mounting NFS shared folders...

@FractalizeR Are you able to start it in gui mode? I can't remember the setting to add to your Vagrant file but it could be that your box is waiting for input. You would be able to see this in gui mode. I'll try and find you a link.

@FractalizeR maybe something like this: http://stackoverflow.com/questions/19013851/enabling-gui-in-vagrantfile-settings

The problem was in starting vagrant command from inside PHPStorm. I just started it from pure shell and got password request for modifying /etc/exports on host machine. After that all went fine.

Hi,
I tumbled upon this thread while looking for a solution (had the same problem on Mint 17.1).
I could fix it by installing the missing package ;)
sudo apt-get install nfs-kernel-server

more on this here:
https://github.com/mitchellh/vagrant/issues/1534
Hope this helps

I had this problem with Test Kitchen on CentOS 7. I fixed it by giving sudo privileges to the user running Test Kitchen (I have no idea why it just hung rather then giving me some sort of permission denied error).

@gfauredumont Thanks, your comment above helped me get it working on Linux Mint 17.1. nfs-kernel-server package was not installed.

I am having the same problem, taking out udp from mount_options did not work for me, both my guest and hosts are 14.04 LTS

apparently it was my Firewall blocking NFS and rpcbind ports

I'm getting this as well.  Does anyone know a way to manually run the NFS mount?

Thanks @aftabnaveed! Your comment made me solve my issue. I had a firewall that was blocking incoming requests and prevented nfs to mount the folder. After disabling the firewall everything was fine.

In my case it was the firewall, I'm using Fedora 21 and we know that all RH based distros come with a very restrict firewall!
Maybe Vagrant should test with a simple netcat if the door is opened, this would made things easier to deduce!

This config works for me:
>cat Vagrantfile
Vagrant.configure("2") do |c|
c.vm.define :freebsd do |f|
f.vm.box = "opscode-freebsd-10.1"
f.vm.box_url = "https://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_freebsd-10.1_chef-provisionerless.box"
f.vm.hostname = "freebsd-10.1"
f.ssh.shell = '/bin/sh'
f.vm.network(:private_network, {:ip=>"<IP_ADDRESS>"})
f.vm.synced_folder ".", "/vagrant", disabled: true
f.vm.synced_folder "/home/azul/gits/azulinho-cuisine", "/vagrant", create: true, type: :nfs, :mount_options => ['nolock,vers=3,tcp,noatime,clientaddr=<IP_ADDRESS>']
f.vm.provider :virtualbox do |p|
p.gui = false
end
f.vm.provision :shell, path: 'tests/freebsd/bootstrap.sh'
end
end

Hi there,
I have the same problem but I found a simple workaround. In fact,  as soon vagrant up hangs on the infamous "Mounting NFS" I access the box with vagrant ssh. First, I check it with ps the blocking command:
ps -afxu | grep nfs
mount -t nfs -o nfsv3 <IP_ADDRESS>:/Users/mypath/myrepo /vagrant
mount_nfs -o nfsv3 <IP_ADDRESS>:/Users/mypath/myrepo

Then I kill and execute it:
sudo killall mount mount_nfs
sudo mount -t nfs -o nfsv3 <IP_ADDRESS>:/Users/mypath/myrepo /vagrant

And everything works fine. If you have a firewall enable on Guest side make sure to add the proper rules. As example, with Little Snitch for OS X you can temporary disable it to run the mount command and the re-enable it (at least while trying this workaround).
Now, this is really boring and it should work out of the box with Vagrant.
Anyone can figure out why the command executed by Vagrant fails? It's something wrong in FreeBSD or it's really a Vagrant bug?
Thanks for your help!
Regards,
Nicholas
Host: OS X 10.9.5
Guest: FreeBSD 10.1-p10
Vagrantfile:
config.vm.network "private_network", ip: "<IP_ADDRESS>"
config.vm.synced_folder ".", "/vagrant", create: true, :nfs => true, :mount_options => ['nolock,vers=3,tcp,noatime,clientaddr=<IP_ADDRESS>'], id: "vagrant-root"

/etc/exports:
# VAGRANT-BEGIN: 501 XXX-XXX-XXX
"/Users/mypath/myrepo" <IP_ADDRESS> -alldirs -mapall=501:20
# VAGRANT-END: 501 XXX-XXX-XXX

another hint: i needed to restart the nfs-kernel-server after doing a delete and fresh checkout of a project from git. nfs server was probably looking at the old inode.

I have also had this problem and what what causing this is McAfee. Had to change desktop firewall to adaptive mode. If this is not your case, check your anti-virus settings.

For Linux (Ubuntu/Debian) make sure you either stop the firewall or add exception.
sudo service ufw stop

@fdemmer, same here; thank you for the hint!  Apparently, this issue can have very many causes.  Better diagnostics would be very helpful.

In my case this issue was solved just installing the vagrant-nfs_guest plugin.
After that it simply worked!

Moving this to documentation soon.

@rafaeltuelho thx, installing the vagrant-nfs_guest plugin solved my issue too. It's weird, because I don't need the features offered by this plugin.

I'm not using this VM, being an Ubuntu guy (host, guest, and production), but vagrant-nfs_guest as suggested by @rafaeltuelho solved my issue with "ubuntu/trusty64". Not sure if :mount_options => ['nolock,vers=3,udp,noatime'] suggested by @kaamaru played a part, but I've seen it recommended elsewhere for Virtualbox so I'm keeping it. Thanks for the suggestions.

For anyone on OSX check your Firewall preferences System Preferences -> Security & Privacy -> Firewall -> Firewall Options.
Make sure Automatically allow signed software to receive incoming connections is checked.
Otherwise just disable the OSX Firewall altogether if you don't need it.

@bradleyflood Actually, I don't have that option enabled and it works fine. In fact I don't think is a good security suggestion.
Please look at your settings, it's not necessary to disable the firewall to make NFS working properly with Vagrant.

Work for me -
VAGRANT_USE_VBOXFS=true vagrant up

It was a firewall in my case. sudo ufw disable  solved it.

Thank you @bradleyflood!

Thanks, @bradleyflood!

@bradleyflood THANK YOU!!!

If you are using Fedora, just allow the nfs ports through the firewall, or quickly disable the firewall sudo systemctl stop firewalld while you figure it out.

My case is that the nfs directory from the host server is not visible on guest.
This http://unix.stackexchange.com/a/243808/188279 resolves it.
PS I'm running on fedora 23, running a rhel7.2 box with libvirt.
Hope that helps someone.

It was McAfee that was the NFS share on Vagrant. Anyone know what rule to put into McAfee to enable this to work as kinda would like the firewall on!

+1 firewall issue.  Had to disable suse's default firewall.  Not ideal, will have to add a rule at somepoint

For Debian users. If you've configured a private IP for your Vagrant machine, similar to this:
config.vm.network "private_network", ip: "<IP_ADDRESS>"

You just need to add as firewall exception for that specific IP:
$ sudo ufw allow from <IP_ADDRESS>

for SuSE users: edit /etc/sysconfig/SuSEfirewall2
find FW_TRUSTED_NETS and add the VBox net.
i.e. FW_TRUSTED_NETS="<IP_ADDRESS>/24"

I had a similar problem in Ubuntu, Vagrant version 1.9.3, VB version 5.1.22
The problem was that my host's OS has changed the ifconfig to the ip command, and vboxnet0 did not have an ip address.
I had to run:
ip a add <IP_ADDRESS>/<IP_ADDRESS> dev vboxnet0 before Vagrant could start the NFS share
There were many other things I tried: starting/stopping the firewall (ufw, iptables, both, neither); adding specific rules to the firewall to allow all traffic to this IP; service start for each of nfs-common, nfs-kernel-server, nfs-server, nfs-client; and clearing out my /etc/exports
It wasn't until I made sure my vboxnet0 had an IP on the host machine that everything worked.

Ubuntu 16.04.2
Virtualbox Version 5.1.24 r117012 (Qt5.5.1)
Vagrant 1.9.7
Similar to @chadfurman , ifconfig -a showed my vbox0 interface down but it had an ip, so sudo ifconfig vboxnet0 up was the fix.
Not exactly sure why but i'll be keeping an eye out on reboot, I believe i just updated virtualbox versions.


Menu icon

I'm running macOS Sierra, so take this feedback with a grain of salt.
Minor critique: the Z icon in the macOS menu bar is a too big and looks out of place.

Nice, yeah, we should definitely shrink that :)

App is using png image for icon. On mac it should use .icns. Need to change it here.

@GervaisdeM I have added a new tray icon which is little smaller than the last one. Let me know if it looks good.

Looks great!


fuzzing linearizer transformations

(this has been very stale, i'll come back to working on this once i finish off the bitcast PRs)
This fuzzes compiled devices and asts from the kernel dataset.
I also wanted to fuzz random buffer inputs but that wasn't possible because memory ops aren't scheduled. right now we just pass 0s, if the kernel is doing some math that doesn't impact 0s the accuracy test could give a false positive.
TODO:

[ ] add beam to optimizers - maybe there's a nicer pattern for getting optimizers than just manually adding them to a list?
[ ] There's no time or gflops based assertion, it only asserts accuracy - should it do some quality checks like:

one device doesn't exceed a timeout or take a lot longer to compute
the optimizer takes less time than base_tm

[ ] If the fuzzer is gonna be really cross-device we need to have a remote location to store results from the runs, ie. METAL can't run on the same vm that runs CUDA.
[ ] Could bufs_from_lin be faster?

It should really randomly pick optimizations and confirm that they are the same.

closing in favor of 2188:)


V5 API upgrade additional work

Expanding on @palfrey 's V5 upgrade pull request #16 this adds additional data from the V5 API.

Updates serveral of the types to match what is returned from the V5 API.
Several methods have been added to the services
Creating & saving projects have been added which should solve issue #15
Account Service have been added to get information about the current account
Membership Service have been added to get project memberships
Search Service have been added.
Support for side loading of objects have been added to some calls.
A PivotalTrackerClient have been added so you don't have handle the multiple services instances.
Nuget references have been updated to newer versions

Note that since the data objects has changed, there will be breaking API changes for users.

Fixed the merge conflicts after #18 was merged in.


⚠ Bofrost.lu has degraded performance

In 06aa3e0, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1408 ms

Resolved: Bofrost.lu performance has improved in 9484765 after 9 minutes.


CSV Import - Foreign reference issue

Hi,
I would like to ask You for help with Data-Import Bundle for SF2 used together with Sonata Admin.
Importing future is based partialy on tutorial mentioned here: http://fungus.at/2013/10/04/universal-csv-import-feature-for-sonata-admin-symfony-2/
Import module works pretty fine until I'm going to import to the Entity / Table with foreign references.
CSV looks like:
id;supplier;name;auNumber;gaNumber;dwg
0;3;Test 1;80A999990;156017213-001;AA-000012541
Supplier is the relation field to another entity.
During the import the function setValue has in the parameter $value object of the foreign entity which is correct, but as soon as the setter is fired it will finish with exception that instead of an object string was passed.
My primary entity has following setter:
public function setSupplier(\Ausys\Bundle\SupplierBundle\Entity\Supplier $supplier = null)
If you would have any idea how to fix it, I would appreciate your feedback.
Best regards,
Martin

Maybe late, but in case it helps someone, you want to use the StringToObjectConverter converter:
// Convert suppliers to objects
$supplierConverter = new StringToObjectConverter($em->getRepository('YourApp:Supplier'), 'id');
$workflow->addValueConverter('supplier', $supplierConverter);

Thanks for the explanation, @gonssal!


Use forked openapi-typescript-codegen

Codecov Report

Merging #74 (daee4d2) into dev (f244ec2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev      #74   +/-   ##
=======================================
  Coverage   99.39%   99.39%
=======================================
  Files           7        7
  Lines         166      166
=======================================
  Hits          165      165
  Misses          1        1

Continue to review full report at Codecov.

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


Create drink_multi_vending

Hi,
I added the new file "drink_multi_vending", to make it possible to add the field for "drink" also to those vending machines, which do sell drinks, but do not sell only drinks. For this, the requirement would be, that ONE value of the key "vending" would be the value "drinks" then. So later on, the vending_machine preset would have to be edited, too.
But how do I add this information correctly? Is this possible with the
"value"~ "drinks"
code that "drinks" would be one value of the key "drinks" then? Or how do we do that? I think I might need your help in this point, so please inform me or maybe you can help me in this thing, thank you very mech! :-)

Unfortunately, this is not yet possible. It would need some code in the iD editor to support such a field and also a change in the tagging schema builder (something like a valueRegex property for example).

Oh, I see. Thanks for your answer. Hmm, too bad.


Add support adding/removing members and transferring leadership via REST API. Fixes #1544 and fixes #1543

Fixes #1544 and fixes #1543


this needs to be higher up in load order

Yo @DominicHomeflow  - this needs updating or gem fails as load order matters
@crispinandrews - FYI

Yes, good point. Guess you want the employee before the reponse.


Update README with newer infos

Update badges and installation method.

FIY, the url of the discord badge gives an Invalid badge.

ah, edited with the correct URL

maybe we should make the towncrier snippets capitalized?

Maybe this can be enforced at build time.


Name resolution of FQDN for compute clusters are not required

[Enter feedback here]
"Prerequisites" section includes the following statements

If you have your own DNS server, we recommend using DNS forwarding to resolve the fully qualified domain names (FQDN) of compute instances and clusters. For more information, see Use a custom DNS with Azure Machine Learning.

Since the compute instances require name resolution for "<compute instance name>.<region the workspace was created in>.instances.azureml.ms", but compute clusters do not, could you please modify it as follows. Thanks.

If you have your own DNS server, we recommend using DNS forwarding to resolve the fully qualified domain names (FQDN) of compute instances. For more information, see Use a custom DNS with Azure Machine Learning.

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

ID: 90a6beff-4f9f-cbee-64ca-4309118f524d
Version Independent ID: e642737a-d6dd-f97e-785d-7a72a8adf93e
Content: Secure training environments with virtual networks - Azure Machine Learning
Content Source: articles/machine-learning/how-to-secure-training-vnet.md
Service: machine-learning
Sub-service: enterprise-readiness
GitHub Login: @jhirono
Microsoft Alias: jhirono

@koheina
Thanks for your feedback! We will investigate and update as appropriate.

@koheina
Thanks for reporting this! We have created a PR for this issue and the changes should go live soon.


Port 3000(or every other port no matter the number) is already in use

This issue mysteriously appeared after a system update. And my express js apps can no longer open ports even though these ports are not in use. I tried sudo, does not help at all. It will only listen to port when using node app.js directly.
Node JS version v12.22.12
Express version v4.16.4

npx kill-port 3000
Also, update your node version
Or
Switch to some other port like 5000 | 6000 after ctrl+c closing your current application and stop databases

I tried every single port, all of them said in use while clearly not. This only happens when using npm start but not directly with node. So this is not a issue due to occupied port.

@LovelyA72, a few things:

Update your system -- especially your Node.js Version. That version hasn't been supported for the majority of this year.
Confirm the application can run on any other.
Provide additional information on the system.
Provide the package.json's start command. If the issue doesn't occur running the node executable, then certainly, it's something to do with whatever is getting called when calling the npm executable.

Overall, we need more information.

https://nodejs.org/en/docs/guides/debugging-getting-started/
https://docs.npmjs.com/cli/v9/commands/npm-config
https://docs.npmjs.com/cli/v9/using-npm/scripts
https://nodejs.org/docs/latest-v12.x/api/net.html#net_server_address

Kill port

Linux

lsof -i:[PORT]

Windows

npx kill-port [PORT] (node)
taskkill /PID [PORT] /F


local variable 'sol' referenced before assignment

I encounter an error UnboundLocalError: local variable 'sol' referenced before assignment
In min_norm_solvers.py,
def _min_norm_2d(vecs, dps):
"""
Find the minimum norm solution as combination of two points
This is correct only in 2D
ie. min_c |\sum c_i x_i|_2^2 st. \sum c_i = 1 , 1 >= c_1 >= 0 for all i, c_i + c_j = 1.0 for some i, j
"""
dmin = 1e8
for i in range(len(vecs)):
for j in range(i+1,len(vecs)):
if (i,j) not in dps:
dps[(i, j)] = 0.0
for k in range(len(vecs[i])):
dps[(i,j)] += torch.mul(vecs[i][k], vecs[j][k]).sum().data.cpu()
dps[(j, i)] = dps[(i, j)]
if (i,i) not in dps:
dps[(i, i)] = 0.0
for k in range(len(vecs[i])):
dps[(i,i)] += torch.mul(vecs[i][k], vecs[i][k]).sum().data.cpu()
if (j,j) not in dps:
dps[(j, j)] = 0.0
for k in range(len(vecs[i])):
dps[(j, j)] += torch.mul(vecs[j][k], vecs[j][k]).sum().data.cpu()
c,d = MinNormSolver._min_norm_element_from2(dps[(i,i)], dps[(i,j)], dps[(j,j)])
if d < dmin:
dmin = d
sol = [(i,j),c,d]
return sol, dps
The sol variable is only assigned if d < dmin, what if d >= dmin always, what should the sol variable be?
I assume that it will be sol = [(i,j),c,dmin], is that right?

I solve it by initializing dmin to a larger number, i.e. dmin=float('inf')


add remote openshift parameters

Related to https://github.com/kiali/kiali/pull/5021

@jmazzitelli I ran into an issue when I attempt to install Kiali on a K8S cluster, while the actual mesh cluster is Openshift (which is the purpose of this PR).
TASK [default/kiali-deploy : Confirm auth strategy is valid for Kubernetes environments] ***
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Invalid auth.strategy [openshift]! Must be one of either 'token', 'openid', 'anonymous', or 'header'"}

In this case this may not be a user error, so I wonder if I could eliminate it in case when i.e. the server_prefix is provided in the auth settings, suggesting that the oauth server (and so the cluster itself) is not the one where kiali being installed on.

I haven't thought about this before. Is this even a valid use case? Installing both non-OpenShift and OpenShift clusters (having Kiali in one and the service mesh in the other)?

Once you start looking at setups spanning over more than one cluster, I may think that it makes sense in a more general perspective. So, you may have one cluster in each cloud (let's think of AKS, EKS, GKS and well... perhaps OpenShift-on-AWS). I guess you are free to choose where to install Kiali, but if you want OpenShift to handle auth, well... I think you should be capable of it.

Yes, so this is for sure a valid production use-case for us. We are the provider of an Openshift as a Service offer, where the mesh itself is operating on the user's cluster (Openshift in this case), but there is also a management cluster which belongs to the provider (not accessible for the user on k8s level). This management cluster may be pure K8S or Openshift, hosting Openshift master components, istiod for the mesh, and now Kiali. I think it should not really matter for Kiali because it will only talk to the mesh cluster (at least for oauth purposes and k8s API resources).
I added a commit to allow the installation in this tricky case.

see discussion in https://github.com/kiali/kiali/pull/5021
We don't need this PR (at least not now). We can resurrect in the future if need be.


Add 3D structure viewer to web UI

[ ] view bonds
[ ] polyhedra
[ ] supercells
[ ] coordinate viewer
[x] from toolkit method
[ ] handling static files on DigitalOcean

I currently have a minimal 3D viewer ready and working. The issue is that it depends on Blender, which can't be installed via pip or conda. For local servers and testing, I think it's fine to have user install Blender manually from the main website, but I'm trying to figure out how to do this for webservers.
For digitalocean, I'll need to use a Dockerfile to run apt-get blender  -- this currently runs out of memory during builds though. DO support suggested moving to github actions to avoid the memory limit errors:
- https://github.com/digitalocean/app_action
- https://github.com/tahafatimaDO/test-DOCR
This may cause other problems with our "Deploy to DigitalOcean" button though.
For now I remove the structure viewer entirely.


Move gl device implementation into separate crate

I am having trouble understanding it. It would be great if it were more decoupled from the common device interface.

@bjz I believe you are working on this one?

I was working on it, but was blocked by the associated item stuff.

Posting your comment, assuming it was about this issue:

Arg, trying to get associated types working with handles
but I am running into issues
I end up needing to pass the Device as a type parameter around
and the CommandBuffer trait needs the handle types
so CommandBuffer needs Device as a type parameter
but that ends in type checker recursion and blowing up rustc's stack
:pensive:

@bjz So you are running into a type dependency recursion? Come back to gitter, when you have a moment, to share more info. Perhaps, you could push your branch for me to check out.


torch.distributed.elastic.multiprocessing.errors.ChildFailedError

Does anyone know how to solve torch.distributed.elastic.multiprocessing.errors.ChildFailedError?

Thanks.

Solved.
I change Python=3.8 to 3.9, and install a CUDA11.X.


[WFLY-14115] Multinode tests failures: grant delete permission for EJ…

…B XA recovery log files
https://issues.redhat.com/browse/WFLY-14115
This PR is an alternative to: https://github.com/wildfly/wildfly-http-client/pull/45
I believe we should just provide the tests with required permissions. I have checked that it prevents the hang.

@tadamski Is your thinking here that if this client were an external application running with a security manager the user would need to give the app the permissions needed to read/write/delete these files used for tx recovery? So the same would be true for a client running inside the server?
I'm just asking to be sure I understand.
In any case, if it's correct for the app to have write perms it makes sense to have delete as well.

@tadamski @gaol #13734 seems to be about the same thing as this one.

@bstansberry please ignore #13734, just closed it. :)

@bstansberry Yes, actually in those case scenarios both client and server are running inside the server. OTOH, I believe such properties won't be required in standalone client - as it cannot be transaction coordinator it wouldn't require to deal with those logs.

@tadamski I apologize for not coming back to this sooner. The point that a standalone client wouldn't need perms concerned me but I wasn't sure why and didn't have a good response at the time.
Looking at the stack trace in https://github.com/wildfly/wildfly/pull/13422#issuecomment-680012845 I don't see why the ClientEjb used by TransactionInvocationTestCase should need special permissions. It's not doing anything exotic; it's just a BMT EJB that invokes UserTransaction.rollback().
When I look at FileSystemXAResourceRegistry$XAResourceRegistryFile I see that the one of the two constructors is doing a permission check that it can read,write the file's directory. I'm not sure why the other constructor doesn't. Anyway it seems that class contemplates ensuring it has perms for the dir and then opening a file using a privileged block, at least in some cases, i.e. the ones that result in fileChannel not being null. So it seems like in those same cases removeResource could use a privileged block to delete the file it created.
@mmusgrov @ochaloup wdyt?

I'm not sure about the permission checks in the constructors but it's right that the ejb client needs the security manager permission for the file system access.
The ClientEjb makes a call from one server to another. The WFTC persists own data about transaction propagation that could be needed on transaction failure to recover correctly. Ie. it's the BMT EJB bean but the rollback is propagated to the second server and the results back then.
In case of failure the transaction recovery may come to the client (to WFTC) and asks if there were some unfinished operations which need to be rolled-back. The transaction manager for JTA stores data to Narayana object store only when the prepare 2PC phase finishes successfully. Otherwise recovery manager has no data and it only verifies with participants if there is something to get finished.
Adding the security manager permissions seem reasonable to me here.

@bstansberry hmm, TBH I thought that it is better to avoid privileged blocks when possible and I haven't noticed that the class already does it; I will prepare alternative PR then

/retest