text:
Implement class declarations

Proposed syntax:
class Q::Statement::My {
    my ident;
    my assignment = None;

    sub Str {
        if assignment == None {
            return "My" ~ children(ident);
        }
        return "My" ~ children(ident, assignment);
    }

    sub run(runtime) {
        if assignment == None {
            return;
        }
        assignment.eval(runtime);
    }
}

(Here's the Perl 6 class for comparison:)
role Q::Statement::My does Q::Statement {
    has $.ident;
    has $.assignment;
    method new($ident, $assignment = Empty) { self.bless(:$ident, :$assignment) }
    method Str { "My" ~ children($.ident, |$.assignment) }

    method run($runtime) {
        return
            unless $.assignment;
        $.assignment.eval($runtime);
    }
}

A couple of things of note:

Much like Python, we re-use lexically declared variables and subs to create attributes and methods.
Unlike Python, there's no __init__ method. You're not expected to need one.
Variables with an assignment on them are optional. Variables that are not assigned are mandatory.
Perhaps most crucially, there is no instance context. There's no self, there's no this. The variables declared with my in the class block happen to be lexically available in the methods, but that's all.
As a consequence, there's no private state. You can't even emulate it by having the methods close over a lexical defined outside of the class. (Or you could, but it would be "static", not per instance.)
There's no class inheritance.
Just as with arrays and object literals, everything's immutable from construction-time onwards. If you want to mutate something, you call setProp (or butWith or whatever we end up calling it).
Anything other than my or sub inside the class block is conservatively disallowed.

Any "ordinary statements" are disallowed because they don't further the function of a class declaration. Use a BEGIN block instead. On similar grounds, BEGIN blocks are out.
constant declarations might be OK, though. They'd be a kind of once-only variables, valid throughout the class. If we wanted to be fancy, we could even allow MyClass.someConstant to resolve. But I doubt we'd want to be that fancy.
I nearly wanted to allow other class declarations inside the class body. Felt it could help to establish name spaces. (And then we'd probably switch from Q::Statement::My to Q.Statement.My.) Eventually decided against it because it feels like it's confusing together two very different things: the closed declaration of a class and its attributes/methods, and the open-ended declaration of namespaces.
Finally, macros would have been really really cool to allow as methods. Unfortunately, macros run long before the late-bound method dispatch happens. Even if we had types and knew what class the macro was run on, we still wouldn't know what instance it was called on.

The syntax for creating an object mirrors object literals quite a lot.
my declaration = Q::Statement::My {
    ident: Q::Identifier {
        name: "foo"
    },
    assignment: None
};

(In this case, we could've skipped passing assignment, as it's already optional.
We could have used the new keyword in the construction syntax, but I don't feel that it adds anything.
As a nice retrofit, writing Object { ... } also works, and means the same as an ordinary object literal. Unlike user-defined classes, the Object type doesn't check for required or superfluous properties.
Tuple classes
After we get types, I'd very much like for us to get a "tuple class" syntax, where you don't name your attributes, but only specify their types as a tuple:
class Q::Statement::Sub (Q::Identifier, Q::Parameters, Q::Block) { ... }

And the corresponding constructor syntax would look like a function call:
my function = Q::Statement::Sub(
    Q::Identifier("fib"),
    Q::Parameters(Q::Identifier("n")),
    Q::Block(Q::Statements(...))
);

Internally, the attributes of a tuple class could have 0-based indices instead of names, and so you could still index them with getProp et al. This type of class would really shine if we had ADTs and case matching, the issue which see.
Meta-object protocol
If you ask type(Q::Statement::My), you get back the answer Type. (Much like Python.) Here's a rough attempt to get Type to "close the loop", meta-object-wise. Using the conjectural/future type syntax.
class Type {
    my name: Str;
    my tuplish: Int;    # since we don't have Bool
    my properties: Array<PropSpec>;
}

class PropSpec {
    my name: Str | Int;
    my type: Type;
}

constant declarations might be OK, though. They'd be a kind of once-only variables, valid throughout the class. If we wanted to be fancy, we could even allow MyClass.someConstant to resolve. But I doubt we'd want to be that fancy.

Nah. We should avoid doing this, for two reasons:

It complicates the nice-and-simple role of the class as a constructor-ish callable.
It's hanging data off the wrong peg. Yes, constant declarations do run at BEGIN time, but everything else in that block properly belongs to the instance, and mixing class/instance initialization in the same block is part of the disease that is OO.

So, no constant. If you want this, you can still emulate it with something like this:
constant RingBearer::defaultRingCount = 74;

class RingBearer {
    my ringCount = RingBearer::defaultRingCount;

    # ...
}

As a consequence, there's no private state. You can't even emulate it by having the methods close over a lexical defined outside of the class. (Or you could, but it would be "static", not per instance.)

Thinking about this one more iteration, this is a feature. Notice in particular that you can still get per-instance closure semantics by providing your own methods through the constructor syntax.
This leads to a situation where the class author controls the per-class mutable state, and the class consumer controls the per-instance mutable state. And there's a bit of a hand-over and negotiation taking place during object construction, in which the consumer gets the last word. I like everything about that.

It's funny, we use the {} constructor syntax to create objects that are like records, and the () syntax to create tuple-like objects. It's quite clear what the [] constructor syntax would do if we employed it:
my args = Q::Arguments [
    Q::Literal::Int(42),
    Q::Infix::Addition(Q::Literal::Int(2), Q::Literal::Int(2)),
];

Array-like types! Currently, we have three types that would benefit from being constructed that way. In Perl 6 terms, it would be does Positional types.
The tricky part would be how to declare them. I've gone through a number of different possibilities, but no syntax feels perfect:
class Q::Arguments: Array<Q::Expr>;

This one is very clear, but it presupposes #33 and type annotations, which are not supposed to be core (while the class declaration syntax is). Then I thought maybe this form:
class Q::Arguments [Q::Expr];

This works, but then I felt it clashes in an unfortunate way with the proposed fixed array types syntax. (Through note the lack of : in the declaration — this isn't a type annotation.)
My current favorite is this:
class Q::Arguments {
    my q::arguments;
}

That is, no new syntax. If the class happens to have (a) exactly one attribute, (b) which happens to be the .lc of the class name — then it's of array type.
I know it's a little bit "magical". But I think it will have fairly few false positives. And I can't think of a solution with less egregious flaws.
Oh, and this one doesn't presuppose type annotations. If you do have type annotations loaded, there would also be a (c) condition: the annotated type of the attribute is Array<T> for some type T.
Basically, the values constructed would be Val::Array values. Except the container has a type name, not just Array. (Very similar to Object versus typed objects.) Also, the elements are typed whenever there's a type annotation on the attribute.
Naturally, all the functions/methods that work on ordinary arrays (elems reversed sorted join filter map) would work on these typed arrays. And, most importantly, postfix:<[]>. This, in fact, would be the whole point of having these, that they behave like normal arrays.
(Note: Q::Statements currently doesn't qualify for arrayhood because it has two attributes. This is temporary and will be fixed.)

Can we use somethign like newtype Arguments = (Expr, Foo)?

Another issue not addressed yet: subtype relations.
I'm a bit hesitant with this one, because I think class inheritance tends to be abused much of the time to shunt methods around between classes and smear them out across a code base. Also, given that what we already have relies quite heavily on lexical scopes and implicitly created constructor forms, straightforward extends-type syntax doesn't seem like a very good fit.
If not for that, we could've simply done
class Q::Statement::My is Q::Statement {
    # ...
}

and been done with it.
Here's what I think we should try instead. A class S is a subtype of a class T (S <: T) iff the attributes of T are a prefix of the attributes of S. In practice, this means that the deriving class still needs to repeat the attributes from the base class. (And in case of a rename refactor, all those attributes need to be found and renamed together, or the link will be lost.)
...so maybe we should do both, as a kind of failsafe? 😋 Seriously, though, I think just relying on implicit subtyping as above would be fine, at least for the rather small Q type hierarchies we have.

Array-like types!

As I'm using this in practice, it becomes clear that this is a general phenomenon where I just saw the specific case of the array until now.
my id = Q::Ident "x";
my lit = Q::Literal::Int 7;

Both of these feel very natural too. The common denominator is not a single array attribute, but a single attribute, period.
By the proposed "attr name mirrors class name" convention, the classes would be implemented like this:
class Q::Ident {
    my q::ident: Str;
}

class Q::Literal::Int {
    my q::literal::int: Int;
}

It strikes me that I would also be OK with the convention being that the sole attribute be called value, a bit like in Java annotations. (See the JLS, Example 9.6.1-3.)

The common denominator is not a single array attribute, but a single attribute, period.

And yes — in practice this gives us Ven++'s newtype functionality. Single-attribute types are simply wrappers for a value. Under the typed 007 extensions, they are type-checked wrappers for a value. In the cases when one wants several typed values, one uses tuple types.

A class S is a subtype of a class T (S <: T) iff the attributes of T are a prefix of the attributes of S.

Thinking about this a bit more: the one place where I see this working less well is for empty class declarations.
From the 007 sources:
role Q {
}

role Q::Literal does Q {
}

So every Q node type would inherit from Q (which is nice). But so would all non-Q types (which, ugh). Similarly, Q and non-Q types alike would inherit from Q::Literal.
So maybe just give up and write it explicitly as is Q::Literal, etc. 😞
I think the prefix thing is still worthy, though. Maybe the thing we should keep is that a class that declares itself a subtype must also declare all the attributes of its supertype. (In any order.) Under the typing regime, we'd also require that these attributes all be assignable to the corresponding attributes in the supertype. (That is, they can be the same type or narrower.)

Maybe the thing we should keep is that a class that declares itself a subtype must also declare all the attributes of its supertype.

And all the methods, presumably. I wonder how tempted we'd be to have some syntactical convenience for allowing methods to be "inherited" over from base classes.
Interestingly, this makes it very feasible to also have multiple inheritance. Under the typing regime, there'd even be some welcome conflict detection, in which the same method name with wildly different signatures will simply be un-implementable in the deriving class.

It strikes me that I would also be OK with the convention being that the sole attribute be called value, a bit like in Java annotations.

Not to mention that this would mesh quite well with #41. In fact, I think that settles it: value it is.

Rethinking the MOP and the names a little, I think this is what I want:

Type

T::Class
T::Tuple
T::Enum

I'm already going with the class and enum keywords, so maybe the middle one should use have the tuple keyword for consistency?

There's a total collision between subcalls foo(1, 2, 3) and tuple creation syntax MyTuple (1, 2, 3).
(That space there is just convention. It's good for humans, but 007 ignores it.)
The verdict here is that if MyType isn't defined as a tuple by the time you parse MyTuple (1, 2, 3), then the parser assumes it's a sub. If that assumption turns out to be wrong, then the user gets an error and the program doesn't compile.
This is the best we can do (same as Perl 6, by the way). The alternative is to hedge the parser and go eeee maybesubcallmaybetuplecreation, and leave something weird in the Qtree that can collapse later... and we're not doing that. We have enough interesting problems as it is.

As a consequence, there's no private state. You can't even emulate it by having the methods close over a lexical defined outside of the class. (Or you could, but it would be "static", not per instance.)

Having tried out objects in 007 a bit, I think the above design decision would be a mistake. Private state is available through lexical closure in normal objects. Not having that feature through classes would be a great pity, and would make Plain Old Objects strictly more powerful (and more desirable) than classes. Below is the current implementation of the Runtime object in runtime.007 to illustrate how closure is used in the new method to hold private state.
my Runtime = {
    new(config) {
        my out = config.output;
        my pads = [];
        sub enter() { pads.push({}) }
        sub leave() { pads.pop() }

        sub declare_var(name) {
            pads[pads.elems() - 1][name] = None;
        }
        sub find(name) {
            for pads.reverse() -> pad {
                if pad.has(name) {
                    return pad;
                }
            }
            throw new Exception { message: "Cannot find variable " ~ name };
        }
        sub get_var(name) {
            my pad = find(name);
            return pad[name];
        }
        sub put_var(name, value) {
            my pad = find(name);
            pad[name] = value;
        }

        my eval_of_type = {
            # properties omitted for this example
        };
        sub eval(q) { return eval_of_type[type(q).name](q); }

        my run_of_type = {
            # properties omitted for this example
        };
        sub run(q) { run_of_type[type(q).name](q); }

        return { run, get_var, put_var };
    }
};

Here's what I would like to be able to write with the class syntax instead:
class Runtime {
    has out;

    my pads = [];
    my eval_of_type = {
        # properties omitted for this example
    };
    my run_of_type = {
        # properties omitted for this example
    };

    sub enter() { pads.push({}) }
    sub leave() { pads.pop() }

    sub declare_var(name) {
        pads[pads.elems() - 1][name] = None;
    }

    sub find(name) {
        for pads.reverse() -> pad {
            if pad.has(name) {
                return pad;
            }
        }
        throw new Exception { message: "Cannot find variable " ~ name };
    }

    sub eval(q) { return eval_of_type[type(q).name](q); }

    method run(q) { run_of_type[type(q).name](q); }

    method get_var(name) {
        my pad = find(name);
        return pad[name];
    }

    method put_var(name, value) {
        my pad = find(name);
        pad[name] = value;
    }
}

Both the object form and the class form clock in at exact 40 lines. But the class form looks cleaner IMO.
Here are the significant differences from what has been proposed so far in this issue:

There are now has and method keywords. They are like my and sub respectively, but unlike those they declare visible properties/methods.
From a Perl 6 point of view has foo is much like has $.foo, and my foo is much like has $!foo.
Similarly, sub foo is much like Perl 6's method !foo, and method foo is like method foo.
In other words, everything in the class block has access to the instance context (but there's no this, you just access private and public stuff directly by name).
I'm open to having a constructor keyword with things that run after all the initializers. In this example I didn't need that, though.
In some sense, one could think of the class syntax being "compiled down to" or otherwise standing in for the object/closure syntax. Also in some sense, the class block now corresponds to the new() method block, in that in both cases, each instance has one, and that's where all the private state lives.

-1 to changing my's behavior in class as compared to Perl 6, I'd argue either it's lexical or it's not. The other solution would be executable class bodies, scala-ish variant where everything in the class body is ran in order

-1 to changing my's behavior in class as compared to Perl 6, I'd argue either it's lexical or it's not.

It is lexical. What's changed isn't the behavior of the my variables; those work the same as usual. The change is that the class block (the { ... } in class Runtime { ... }) creates a new Frame with each new instance, in analogy with how a sub block creates a new Frame each time it's invoked.

The other solution would be executable class bodies, scala-ish variant where everything in the class body is ran in order

We kinda have this, except that we're conservatively restricting the allowable statements to my, has, sub and method. (And conjecturally constructor.)

I think it would be nice to start implementation of this feature pre-v1.0. I suggest we try doing it behind a feature flag (rather than a branch). I don't want v1.0 to block on classes, but it might benefit everyone to have actual classes to try out before v1.0.

One interesting thing that's always worked in Elixir, and feels nice (though a bit surprising): class bodies are compile-time evaluated context.
defmodule MyModule do
  for name <- ["a", "b", "c"] do
    def unquote(name), do: unquote(name)
  end
end

(yes, def "a"(..) ... is valid syntax)
So basically, class bodies are executable

At first glance, I'm surprised to see an unquote outside of a quasi. But I guess that's an Elixir thing?

Yes, that's how they do "executable class bodies". The for's body is quoted

I see.
Though I'm unsure what you're suggesting here for 007. Would you like the class block to be an implicit quasi block, so that unquotes work inside of it? Or would it be limited to for loops in the class block?
Is there somewhere I can read about Elixir's compile-time evaluation of class bodies?

I'm just trying to create a discussion about how languages with macros without a MOP usually manage those things.
For Perl 6, it's still a totally open discussion as well, not sure how to intermix those two :)

Ah, I see. Yes, that discussion is very much worth having. Thank you for bringing it up.
I have no idea how the balance will come out between macros/Q and MOP... but in some ways I'm not so troubled by it, as long as they interoperate well enough.

Thinking about this, I realize what we do need a good story for is how to inline a bunch of stuff (attributes and methods) into a class using unquotes and macros.
Something like this:
class XYZ {
    has normal_attr;
    method normal_method() {
        # ...
    }
    macro_with_more_stuff();
}

Or like this:
quasi {
    class {{{Q::Identifier @ ident}}} {
        has normal_attr;
        method normal_method() {
            # ...
        }
        {{{Q::MemberList @ more_stuff}}}
    }
}

We should take a leaf from JSX here, which essentially allows an array of elements and text nodes to be injected in element position; the array melts away, and the elements and text nodes are injected in sequence without any intervening structure.

By the way, implementation has now started, under a feature flag.
The ability to introduce new class names into user code is currently slowly causing an upheaval in some assumptions and things we got away with before. :smile: But it's all good.

In some sense, one could think of the class syntax being "compiled down to" or otherwise standing in for the object/closure syntax.

This notion is not obviously compatible with inheritance between classes. I'm currently pondering how to address that.

-1 to changing my's behavior in class as compared to Perl 6, I'd argue either it's lexical or it's not.

Belatedly I'm coming around to this. It's a lot more reasonable for my in a class block to mean "per-class lexical variable, kinda like a static variable in other languages" than for it to mean "private member".
I hope to throw up a complete class syntax/semantics proposal soonish.

(...where "soonish" apparently means "more than one month later"...)
class Runtime {
    property out;

    private property pads = [];
    private property eval_of_type = {
        # properties omitted for this example
    };
    private property run_of_type = {
        # properties omitted for this example
    };

    private method enter() { pads.push({}) }
    private method leave() { pads.pop() }

    private method declare_var(name) {
        pads[pads.elems() - 1][name] = None;
    }

    private method find(name) {
        for pads.reverse() -> pad {
            if pad.has(name) {
                return pad;
            }
        }
        throw new Exception { message: "Cannot find variable " ~ name };
    }

    method eval(q) { return eval_of_type[type(q).name](q); }

    method run(q) { run_of_type[type(q).name](q); }

    method get_var(name) {
        my pad = find(name);
        return pad[name];
    }

    method put_var(name, value) {
        my pad = find(name);
        pad[name] = value;
    }
}

The four possible member declarations, in other words, are:

property and private property
method and private methods

Private properties and methods I imagine will be handled with Symbols as described in #207. In other words, they'll be inaccessible from outside view. Both the declaration and every use in the class is desugared behind the scenes to deal in symbols. You access a private property or method as foo, not as self.foo. This cuts down immensely on the need to write self.
I like this syntax. The only objection I have myself is that private property and the like are a bit long to type. I tried to do it with sigils, but nothing really felt right.

The above proposal also completely avoids changing the behavior of my, which ought to make @vendethiel happy.

I came up with a variant that's virtually keyword-free:
class Runtime {
    out;

    !pads = [];
    !eval_of_type = {
        # properties omitted for this example
    };
    !run_of_type = {
        # properties omitted for this example
    };

    !enter() { pads.push({}) }
    !leave() { pads.pop() }

    !declare_var(name) {
        pads[pads.elems() - 1][name] = None;
    }

    !find(name) {
        for pads.reverse() -> pad {
            if pad.has(name) {
                return pad;
            }
        }
        throw new Exception { message: "Cannot find variable " ~ name };
    }

    eval(q) { return eval_of_type[type(q).name](q); }

    run(q) { run_of_type[type(q).name](q); }

    get_var(name) {
        my pad = find(name);
        return pad[name];
    }

    put_var(name, value) {
        my pad = find(name);
        pad[name] = value;
    }
}

I think I like that better. It's strangely consistent both with the 007 object syntax (except semicolons separate members instead of commas separating properties) and with Perl 6's private-slot twigil (except in 007 it's a sigil, kinda).

The method constructor(x, y, z) is what new MyClass(x, y, z) calls under the hood. I guess Object should have a constructor() by default. The constructor is inherited, just like other methods. (Are they in ES6? Yes, seems so:)
$ node
> class A { constructor(x) { console.log(x) } }
[Function: A]
> class B extends A {}
[Function: B]
> new B("OH HAI")
OH HAI
B {}

I feel C# got it right with the new MyClass(x, y, z) { prop1 = 1, prop2 = 2 } combination of constructor and initializer block. It's kind of the best of both worlds: you can do special things in the constructor if you want, but you can still pass in boring properties in any order in the initializer block too. Let's try and steal that for 007.

...oh, but does that syntax mean that we again run into trouble with if statements and the like? It does, doesn't it? :disappointed: Need to think about that.

self is available inside public and private methods, including of course constructor. Due to self just being an invisibly declared lexical variable, it's also available inside nested subs in methods.
However, if we allow sub declarations in classes (which we can now do if we want), then self is not available. Probably we should have some custom error message in that case.
We can try to make self available in field defaults too, but that's not a priority.
a = 1;
b = 2;
sum = self.a + self.b;    # like this

Maybe allowing that will have unintended consequences, such as users declaring all their methods as sub expressions or arrow functions? Ah, gotta trust the users on this one.
It should be a redeclaration error to try to declare a parameter self in a method (private or public), even though the declaration of self is not visible. Nested subs in the method are allowed to shadow self, though.

As soon as we allow both property initializers and constructors, the question naturally arises which order they should run in. I'd say property initializers first, then the constructor, without hesitation.
Furthermore, initializers in base classes should also run before the constructor, ordered from base class to derived class. (In other words, in declaration order.)
The above follows C#'s design. Java does it a bit differently — it inlines the initializers into each class's constructor. This ultimately can lead to surprises during initialization, especially when a base class's constructor calls a mehod overridden by a derived class, which in turn expects the derived class's initializers to have run. They have in C# but not in Java.

I realize I need to think more about what exact MOP instructions the various bits of the class syntax (properties, constructors, methods, private/public) desugar to.

Not to add to all the self-bikeshedding on syntax (except really yes)...
I was enjoying The Left Hand of Equals when on page 8 this syntax showed up:
class point(x0, y0) → Point {
    method x { x0 }
    method y { y0 }
    method leftEquals(other : Object) {
        match (other)
            case { p : Point → (x.leftEquals(p.x)) && (y.leftEquals(p.y)) }
            case { _ → false }
    }
}

(The Point { ... } syntax does something with anonymously subclassing an interface, like in Java. That's not really the important part.)
I was struck by how neatly class definition is made into a type of function/routine definition. Specifically, the constructor is represented as parameters on the class body itself. I'm surprised I haven't seen this in a language somewhere. Maybe it exists but I'm unaware of it?
Anyway, I'm wondering if we should steal it for 007.
(Note that Python uses parentheses after the class name too, but for inheritance, as in the is keyword. It's one of the few things I find "too cute" about Python. Sure, it's a parameter to the class, I guess. And in Python it makes somewhat more sense, because everything is evaluated at runtime, including class definitions.)
Here's how I would write the above as 007 code, maybe:
class Point(@has x, @has y) {
    method leftEquals(other) { # not really interested in this method but here goes
        return other ~~ Point
            && x.leftEquals(other.x)
            && y.leftEquals(other.y);
    }
}

Here, the @has annotation (using #257 syntax) automatically binds the x and y parameters to their respective fields, so that (a) we don't have to declare them with has x; has y; and (b) we don't have to initialize them.
I'm thinking any additional constructor logic one might want can just be written at the top of the class body, maybe?
Note that this pretty squarely gives the class one constructor... but 007 already had it that way, so that's OK.
Does this play well with inheritance? Well, kinda:
class ColoredPoint(x, y, @has c) is Point(x, y) {
    # ...
}

Here, the is inheritance declaration and the super() call are baked into one, sort of. Again, is this enough for the general case? Again... maybe?
In this case, x and y don't need the @has annotation, because Point takes care of that. It'd work to have it, but it's redundant.
This comment is just a bikesh^Wsuggestion. I'm torn, but kinda curious. I find the syntax suggestive, not least because it would rhyme well with #307 and (even moreso) #308. (In that class declaration and class construction would look alike, just as function declarations and function calls do.)
To top it off, this syntax (and @has too) would fit well into the #306 story.

I think the strongest argument against a class Point(x, y) { .. } syntax is that 007 would end up innovating (aka "grinding an ideological axe"), which (a) 007 has not set out to do, and (b) has backfired before (see #147, for example).
I think the biggest confidante here is our tiebreaker language, JavaScript, which indeed puts parameters on its "classes" in the old-skool constructor syntax. But that's only barely comparable. Secondly, in the new ES6+ class syntax, JavaScript explicitly does not go that route, even though it could. (It would be interesting to know if TC39 discussed a syntax like that.)
Maybe simply the fact that it's an unusual syntax, whereas 007 tries to be as syntactically "uninteresting" as possible, is an argument against.

Furthermore, initializers in base classes should also run before the constructor, ordered from base class to derived class. (In other words, in declaration order.)

Coming back to this issue — ow, my head, all the ideas — I think this one means that initializers can't just be sugar for initializations in the constructor; they need to be their own thing.
This complicates things a little bit. But I suspect that extra complication might still be better than Java's surprising behavior.

I was struck by how neatly class definition is made into a type of function/routine definition. Specifically, the constructor is represented as parameters on the class body itself. I'm surprised I haven't seen this in a language somewhere. Maybe it exists but I'm unaware of it?

Holy gosh! Simula does it this way! 😱

This changes everything!
(😛 )

In this talk, Hejlsberg laments a little bit that JavaScript didn't get a syntax where the parallel between a class and a function were made more explicit and the class took in its constructor parameters as a parameter list after the class name.

Beyond all the syntactic self-bikeshedding I've inflicted on myself, I'm plagued by a number of orthogonal Tough Tradeoffs on the semantic level:

Early vs Late. Preferably types in general and classes in particular should be so static that they could be erased at compile time -- even if we don't actually do that in practice. But then classes cannot have closure semantics, right?

Bound methods. This is one I feel I have figured out: like in Python, methods defined in a class resolve to a bound method when accessed on an instance, so that detaching a method from its object and calling it as a function works. (I feel this one is pretty non-negotiable. Making it work is basically a kind of eta rewriting. It's highly surprising that this doesn't work in JavaScript.)

Should methods in object literals bind like that? Should they allow self? I don't know. Willing to drop this one if it becomes in any way problematic.

Type vs static vs undefined instance. I find at various different times I want the value MyClass to do three distinct things: (a) specify instances of that class: fields and methods, (b) be a "static level" where class-wide fields and methods could reside, (c) be an "empty instance" containing default field values and unbound methods. Pretty sure it's (a) I want, but that doesn't mean the other two use cases don't make themselves felt sometimes.

Fields and methods distinct? I mean, they're definitely in the same (property access) namespace already, like in Python. The bound method/descriptor thing makes it possible for them to be the exact same thing, but... where/how does the method get looked up? Presumably methods are not assignable; what guarantees that?

Re some of the above questions, I found it useful to think of it in the very concrete example of the following method lookup:
my a = [1, 2];
a.push(3);

a is an Array, of course. The a.push goes to look up a method (possibly having looked for a field first), and whatever happens inside the conceptual black box in between, at the end of that process the Array type's push method gets called with a as the invocant and 3 as the single argument.
Where does it find (the functional value representing) the push method? Well, the "right peg" in this case is somewhere in a method lookup table inside the Array type object. Nominally, evaluating a.push on its own needs to have already triggered the descriptor semantics, so that a.push is actually more like Array.findMethod("push").bind(a)`. (This intermediate form can of course be optimized away in theory whenever we're making the call right away.)
There needs to at least be a distinction between fields and methods in the sense that a field gets found immediately on the instance, whereas a method goes through the above dance. Still, the interface looks like a property access in both cases.

Yet another dimension to this: is it possible to make methods behave indistinguishably from func/arrow function props?

I think the strongest argument against a class Point(x, y) { .. } syntax is that 007 would end up innovating (aka "grinding an ideological axe"), which (a) 007 has not set out to do, and (b) has backfired before (see #147, for example).

The solution to this conundrum is this: make the safe syntax the default. Have the exotic syntax available through a module.
There needs to be a way to displace/supersede grammar rules -- probably something with exactly the same category and declarative prefix as an existing rule needs to have an is replacing trait (possibly which even identifies the name of the old rule), otherwise the declaration is considered a compile-time conflict.
I'm thinking it'd also make sense to conservatively forbid an already displacing rule to be displaced by another rule... In the future when we understand the dynamics better, we might relax that.

The solution to this conundrum is this: make the safe syntax the default. Have the exotic syntax available through a module.

But Simula (and C#) do it that way, so it's not innovating ;-).

C#, really? Not in this brief introduction to C# classes. Could you link me to where C# does this?
Anyway, even with some of those languages having that syntax, it would be "exotic" for 007 to step away from the way Perl 6, Python, and JavaScript do it — which differs in the details but is otherwise fairly consistent.

Well, I suppose what I say was misleading. The feature I’m talking about is called « records » but is only coming with C# 8.

And C#'s upcoming records don't appear to be the same, syntactically, as Simula and what I'd like for 007's "exotic" syntax — the former is syntactic sugar for a very predictable value class (well, a "record"), while the latter contains the constructor arguments up in the class declaration header while still having an explicit body (where the constructor parameters are in scope).

authors: masak vendethiel


text:
Leverage trait methods more

This is closer to what I had in mind in #4, as an alternative to #11.

Hi,
Thanks for this example, I'll modify the approach for #4 to be in line with this, and also incorporate the changes we need for better handling of the extension types mentioned in #14

source: gharchive/pull-request

authors: djc masalachai

repo: masalachai/epp-client

license: MIT

license_type: permissive

license_source: github-api


text:
new project- input box

实际结果：输入项目名称，如‘’互动和速度‘’想要删除互动点击鼠标无法点击

resolved

source: gharchive/issue


text:
🛑 POH events bot from render hosting is down

In eec2ae9, POH events bot from render hosting (https://poh-events-bot.onrender.com/ping) was down:

HTTP code: 0
Response time: 0 ms

Resolved: POH events bot from render hosting is back up in 59bdb06.

repo: masch/poh-events-uptime


text:
🛑 POH events bot from render hosting is down

In 248a225, POH events bot from render hosting (https://poh-events-bot.onrender.com/ping) was down:

HTTP code: 0
Response time: 0 ms

Resolved: POH events bot from render hosting is back up in 6e47a6c after 1 hour, 6 minutes.


text:
🛑 POH events bot from render hosting is down

In 5b8c4a0, POH events bot from render hosting (https://poh-events-bot.onrender.com/ping) was down:

HTTP code: 0
Response time: 0 ms

Resolved: POH events bot from render hosting is back up in 1cd0f9a.


text:
🛑 POH events bot from render hosting is down

In babbbfc, POH events bot from render hosting (https://poh-events-bot.onrender.com/ping) was down:

HTTP code: 0
Response time: 0 ms

Resolved: POH events bot from render hosting is back up in f8fef44 after 19 minutes.


text:
🛑 POH events bot from render hosting is down

In f8b5b09, POH events bot from render hosting (https://poh-events-bot.onrender.com/ping) was down:

HTTP code: 0
Response time: 0 ms

Resolved: POH events bot from render hosting is back up in eddab25 after 8 minutes.


text:
[Proposal] Remove add props

remove additionalProperties from existing artifacts and add pre-commit to prevent this in the future.
please tell me if I'm misunderstanding the need for this as part of: https://github.com/massdriver-cloud/massdriver-cli/issues/64 @coryodaniel

additionalProperties: false prevents users from adding additional properties to our objects. This is a good thing because API consumers could at some point in the future add giant objects of random garbage and wreak havoc on our system. We want to keep additionalProperties: false. Any parameter we take via JSON schema should be accounted for and validated.

so is the idea to only remove these in the publish workflow here: https://github.com/massdriver-cloud/artifact-definitions/blob/main/.github/workflows/publish-stable.yaml#L25 ?

That CLI issue has to be addressed in the CLI code. We can sync tomorrow on this but we don’t want it removed on the definitions.

authors: coryodaniel jaketf xpositivityx

repo: massdriver-cloud/artifact-definitions


text:
🛑 RESTREAM-IR-11-ZirSakht-2 is down

In 8746b07, RESTREAM-IR-11-ZirSakht-2 ($IR_11) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RESTREAM-IR-11-ZirSakht-2 is back up in 0a44e17.


text:
🛑 RESTREAM-IR-10-ParsOnline-4 is down

In dd75592, RESTREAM-IR-10-ParsOnline-4 ($IR_10) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RESTREAM-IR-10-ParsOnline-4 is back up in 1e3ea5e.


text:
🛑 Iran 10 - Zirsakht 3 is down

In 477690a, Iran 10 - Zirsakht 3 ($IR_10) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Iran 10 - Zirsakht 3 is back up in cb9bc4f.


text:
🛑 Iran 1 - VIP 1 is down

In d3e9ebc, Iran 1 - VIP 1 ($VIP1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Iran 1 - VIP 1 is back up in 37f81ec after 9 minutes.


text:
🛑 Iran 1 - VIP 1 is down

In b425833, Iran 1 - VIP 1 ($VIP1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Iran 1 - VIP 1 is back up in 6ef3401 after 32 minutes.


text:
Smaller subitems

Hi! First of all congratulations, the FAB works really good.
It would be nice if the sub-items could be smaller in size.

You can do that! Use the prop size in ActionButton.Item. I know it's not documented..

Okey, thanks!

Hi,
when you set the size of Actionbutton.Item,
the subitems does not showed completely and its ugly, is there any solution?
Thanks

Same problem... sub items do not render correctly when changing size

Same for the v2.7.2

authors: EnriqueDev githubdoramon likeconan mastermoo nikolay-radkov

repo: mastermoo/react-native-action-button

license: mit

license_source: bigquery


text:
Exe Not working!

Describe the bug
I am able to create the exe file. After I create it, It opens a dist folder with "Source_Prepared.exe. Everything is fine. But that's till the exe is ran. As soon as I run the exe, it gives me an error:
Traceback (most recent call last):
File "source_prepared.py", line 3, in
ModuleNotFoundError: No module named 'pynput'
Not only that, It also shows this error at starting when compiling:

Expected behavior
It should run the exe, create the channels and the bot should come online, while nothing happens.
Screenshots

Desktop (please complete the following information):

OS: Windows 10
Python Version: 3.10.9

Additional context
N/A

it looks like you are missing pip? but that shouldnt be the case since you have actually managed to install some packages. Please try uninstalling python completely and install a newer version (preferably 3.11.4)

i get the same error but instead of pynput its 'requests'

authors: FluxxyBoi KilaxYT Yaw-Dev

repo: mategol/PySilon-malware


text:
race condition while starting the app

Hey, doing
{:ok, _} = Application.ensure_all_started(:cqerl)
{ok, Client} = :cqerl.get_client()

fails with :cluster_not_configured
but.. adding a timeout seems to solve it :(

Thanks for reporting! It was reported in #111, and is now fixed, if you use v1.0.3

i still see this hapenning

What version do you see when you type Application.loaded_applications?

Ah, I see the difference, the other ticket was for timing issue with add_nodes and get_client, you're reporting Application.start and get_client. My bad!

This is fixed in v1.0.4 that I just pushed, thanks for reporting!

confirmed! working!

authors: BlueHotDog matehat

repo: matehat/cqerl


text:
[codelab] No argument named $component-height

In following the tutorial: (Web)MDC-102 Web: Material Structure and Layout (Web)
After updating home.scss and saving, the compilation fails as follows:
  [25] ./home.scss 1.44 kB {0} [built] [failed] [1 error]
    + 11 hidden modules

ERROR in ./home.scss
Module build failed:
undefined
   ^
      No argument named $component-height.
   ┌──> node_modules\@material\list\_mixins.scss
536│ ┌     @include shape-mixins.radius(
537│ │       $radius,
538│ │       $rtl-reflexive,
539│ │       $component-height: $height,
540│ │       $query: $query
541│ │     );
   │ └─────^ invocation
   ╵
   ┌──> node_modules\@material\shape\_mixins.scss
30 │   @mixin radius($radius, $rtl-reflexive: false, $query: feature-targeting-functions.all()) {
   │          ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ declaration
   ╵
  node_modules\@material\list\_mixins.scss 536:5             radius()
  node_modules\@material\list\_mixins.scss 536:5             single-line-shape-radius()
  node_modules\@material\drawer\_mixins.scss 304:3           item-shape-radius()
  node_modules\@material\drawer\_mixins.scss 71:5            core-styles()
  node_modules\@material\drawer\common.scss 24:1             @use
  node_modules\@material\drawer\mdc-drawer.scss 23:1         @forward
  node_modules\@material\drawer\mdc-drawer.import.scss 37:1  @import
  stdin 2:9                                                  root stylesheet
      in C:\Users\moranmat\Downloads\Dev\material-components-web-codelabs-master\mdc-101\starter\node_modules\@material\list\_mixins.scss (line 536, column 5)
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./home.scss

It seems that within this codelab, the command npm install @material/drawer @material/list installs both dependencies on the latest version @^7.0.0 instead of @^6.0.0 (which has explicit been used in the previous lab MDC-101).
After running npm install  @material/drawer@^6.0.0 @material/list@^6.0.0 everything seems to work again.

authors: JayDijkstra Mamikel


text:
Warning when using md-outlined-text-field with v-model in Vue.js

What is affected?
Other/unknown
Description
Describe the bug
When using md-outlined-text-field with v-model in a Vue.js application, a warning message is displayed in the console, even though the component seems to be working correctly.
The warning message is:
Element md-outlined-text-field scheduled an update (generally because a property was set) after an update completed, causing a new update to be scheduled. This is inefficient and should be avoided unless the next update can only be scheduled as a side effect of the previous update. See https://lit.dev/msg/change-in-update for more information.
To Reproduce

Create a Vue.js component that uses md-outlined-text-field with v-model.
Run the application.
Open the browser console.
When the first character is entered in the md-outlined-text-field component, a Warning is displayed in the console.

Expected behavior
The warning message should not be displayed.
Screenshots/Code snippets
<script lang="ts" setup>
import type { MdOutlinedTextField } from '@material/web/textfield/outlined-text-field'

interface Props {
  modelValue: string | number
  error?: boolean
  errorText?: string
  label?: string
  type?: 'text' | 'email' | 'number' | 'password' | 'search' | 'tel' | 'url' | 'textarea'
  prefixText?: string
  suffixText?: string
}

const props = withDefaults(defineProps<Props>(), {
  modelValue: '',
  error: false,
  errorText: '',
  label: '',
  type: 'text',
  prefixText: '',
  suffixText: '',
})
const emit = defineEmits<{
  'update:modelValue': [value: string | number]
}>()

const onInput = (e: Event) => {
  const value = (e.target as MdOutlinedTextField)?.value
  emit('update:modelValue', props.type === 'number' && value !== '' && !isNaN(Number(value)) ? Number(value) : value)
}
</script>

<template>
  <md-outlined-text-field
    v-bind="props"
    :value="modelValue"
    @input="onInput"
  />
</template>

<script lang="ts" setup>
import { z } from 'zod'
import type { MdDialog } from '@material/web/dialog/dialog.js'
import type { MdFilterChip } from '@material/web/chips/filter-chip.js'
import type { MdSlider } from '@material/web/slider/slider.js'
import type { FilterParams } from '@/interfaces'

…

const {
  value: totalMinutesMin,
  meta: totalMinutesMinMeta,
  errorMessage: totalMinutesMinError,
} = useField<FilterParams['projects']['totalMinutesMin']>('totalMinutesMin')

…

</script>
<template>

…

  <PJOutlinedTextField
    v-model="totalMinutesMin"
    type="number"
    label="分"
    min="0"
    max="59"
    .error="totalMinutesMinMeta.dirty && !totalMinutesMinMeta.valid"
    :error-text="totalMinutesMinError"
    class="is-full"
  />

…

</template>

Environment:

OS: macOS 14.5
Browser: Chrome 127.0.6533.72
@material/web: 2.0.0
nuxt 3.12.4
vue: 3.4.34
@vee-validate/nuxt: 4.13.2

Additional context
We have tried several workarounds, including:

Using requestUpdate() after updating the value property of md-outlined-text-field.
Manually triggering an input event after updating the value property.
Using watch to observe changes to the v-model value and update the md-outlined-text-field accordingly.

However, none of these solutions have successfully resolved the warning message.
This issue seems to be related to a timing issue between Vue.js's reactivity system and LitElement's rendering cycle.
We would appreciate any guidance or suggestions on how to resolve this issue.
Reproduction
https://stackblitz.com/edit/nuxt-starter-ivpnqt?file=app.vue
Workaround
I have not found a workaround
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
2.0.0
Browser/OS/Node environment

OS: macOS 14.5
Browser: Chrome 127.0.6533.72
@material/web: 2.0.0
nuxt 3.12.4
vue: 3.4.34
@vee-validate/nuxt: 4.13.2

Thanks for the detailed bug report!
The warning appears because your props type for :value is modelValue: string | number, and HTMLInputElement.value is supposed to only be a string. When you set the value to a number, it triggers this fail-safe that re-sets the value to a string.
textField.value = 5;
console.log(textField.value); // 5, a number
// Text field updates, sees that input.value is a string '5', which doesn't match the number 5
await textField.updateComplete;
console.log(textField.value); // '5', a string

This warning is safe to ignore, but it could lead to some unexpected type bugs.
Some options to consider that will remove the warning and be more type-safe:

Create a computed property that converts modelValue to a string, and bind :value="modelValueAsString" instead of the possibly-a-number modelValue.
You can also bind to :valueAsNumber, which gets and sets a Number version of the value when the input type is numeric.
This Vue forms guide may also be relevant, which recommends using v-model.number when binding to numeric inputs. You may be able to take advantage of that when using your text field wrapper Vue component that has v-model support.

Closing since this is WAI, but feel free to continue the conversation!

Dear @asyncLiz
Thank you for your prompt and detailed explanation.
I had forgotten that HTMLInputElement.value supports only string type.
The first method you described resolved the warning without any problems.
Thank you very much for your help.

authors: asyncLiz pennin-style

repo: material-components/material-web


text:
AtomRef Updates

A few edits to the AtomRef class:

added max_z as optional kwarg for cases where offsets have not been fitted yet.
Removed all use of numpy
Use lstsq instead of explicitly pseudo-inverse
Made property_offset a buffer to avoid errors when running on GPU and with lightning modules
Save precomputed identity matrix for onehot vectors as buffer.

The errors have to do with "Bad serialized model". I don't really understand how to fix those.
I also keep getting this error when running pre-commit:
error: TOML parse error at line 69, column 3
   |
69 |   "PERF203", # try-except-in-loop
   |   ^^^^^^^^^
Unknown rule selector: `PERF203`

Any ideas on how to get rid of it?

I think it is a version of ruff that is the problem for the PERF. For bad serialized model, I think your fork may have cached an old model. Maybe mgl clear --yes command to remove all models first?

Thanks @shyuep !
The "bad serialized" error was actually from my changes. I had to do a few things to change it:

use strict=False when using load_state_dict in IOMixin.load.
check if property_offset is a list or ndarray in AtomRef constructure for backcompat with pretrained models.

I also added a raise from the BaseException leading to the "Bad serialized" error because otherwise it can be unclear what the error actually is.
Pls have a look and lmk your thoughts

Thanks. I think this is fine. I will merge.

authors: lbluque shyuep

repo: materialsvirtuallab/matgl


text:
[v1.8.x] Customize Deserializer in kafka:consume Command

This PR enable to specify the which deserializer class to use when consuming message via kafka:consume command. Currently, it uses the default MessageDeserializer from app service provider, and can't override for each consumer when there are multiple serializer/deserializer needed for multiple topics.

Thanks!

authors: cragonnyunt mateusjunges

repo: mateusjunges/laravel-kafka


text:
Customization

How can you customize the template? The documentation is confusing and doesn't show what to put where.

Copy https://github.com/matfish2/vue-pagination-2/blob/master/src/Pagination.vue to your own MyPagination.vue file. (If you are using the vue3 version copy from the vue3 branch instead)
Modify to your needs.
Tell the plugin to use your template instead of the default:

import MyPagination from './MyPagination'
...
{
    options: {
        template: MyPagination
    }
}


text:
Convert ConnectionHandler into an AMQP worker which contains its own connection handler

Currently AMQPWorker contains AMQP::Connection and everything else required to connect to an AMQP host. It creates a ConnectionHandler and runs its operator() to process messages. However, it should be possible for ConnectionHandler to pass itself into an AMQP::Connection constructor and store AMQP::Channel inside of it, itself. This would remove the need for an additional class to contain the connection information.
Find out if this is possible.

Nice and neat rearrangement of IWorker -> ConnectionHandler -> IAMQPWorker -> AMQPWorker inheritance. User definition of only a single function, ProcessMessage, is required to create an AMQP worker that processes messages of the defined type.

Nice and neat rearrangement of IWorker -> ConnectionHandler -> IAMQPWorker -> AMQPWorker inheritance. User definition of only a single function, ProcessMessage, is required to create an AMQP worker that processes messages of the defined type.

repo: mathemaphysics/agent


text:
[HIGH]: Decouple samples from prior/initial density

Feature Request

should be able to specify a distribution independent of a set of samples used for loading
three datasets should be packaged in 2D: uniform, normal with 95% of samples in (0,4), normal with 99% of samples in (0,4)
in 1D, same idea.
in 5D, just uniform
1000 samples for each, 100 sensors maximum
stop inferring distribution from filename
get rid of prefix handling

Must do:

default to log likelihoods in mud, don't compute the evidence for the posterior. It causes divide by zero errors.

Nice to haves:

decouple runner from pde example, make it entirely independent
pde 1D probably can be separated out since it has a different set of figures
can we attach the geometry study to the output as well?
check out contents of results.pkl and decide if it's worth keeping
refactor the experiment-handling methods to be more transparent in what they are doing. Use dictionaries as configs?

Other bugfixes:

[ ] matplotlib fontsize in comparison figures

mud_run_pde -d n --loc 0 --scale 1 -m 20 100 500  # unassuming prior
mud_run_pde -d n --loc -2 --scale 0.2 -m 20 100 500  # very nice comparison
mud_run_pde -d n --loc -2 --scale 0.1 -m 20 100 500  # too restrictive

I made extensive use of kwargs to support arbitrary distributions (so, this should work beyond just scipy in theory as long as methods .pdf exist).
if loc/scale not provided as kwargs, then we default to -2, 0.2 in Normal, -4, 4 in Uniform.
code not refactored yet, but the feature is working, and results can be put in front of Troy for review. Warrants a release candidate.
prefix handling is gone, prefix=results hard-coded into make_reproducible_without_fenics, shell scripts not updated.
still infer distribution from file name in order to pass sample_dist as an argument (if u (uniform), then use weighted KDE always... since if the prior/initial is uniform, it's fine, and if normal, beta, etc, then it's using the right tranformation with the weights set as the initial pdf evaluations).

also made some headway on moving functions around / modules. tests passing, see #33

repo: mathematicalmichael/mud-examples


text:
Crash on large number of cards in bulk add

Issue: Crashing when adding large number of cards with audio included.
Possible solution: processes downloading audio files in parallel (in ankiconnect.py)

I don't know if this is related, but I get this error when I try to use Passage in Card Builder:
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'map')
at card-builder-4b7d228926b94485.js:1:11323

What is your passage?


text:
OS X Lion support

In Lion you can hold down a key to show its variations. This doesn’t seem to work with custom keyboard layouts that were based on Snow Leopard-layouts though.

This should be possible with Ukelele 2.1.8: http://groups.google.com/group/ukelele-users/browse_thread/thread/5e5b74fd9cd7f793


text:
Alias that empties the trash for all external mounted volumes

Like rm -rfv /Volumes/*/.Trashes but with a filter so it only targets external volumes (e.g. not the main HDD).
@janmoesen suggested to use something like system_profiler SPUSBDataType -xml to get a list of USB-connected volumes.

I hate you. You made me look at AppleScript again.
tell application "Finder"
set ejectableDisks to every disk whose ejectable is true
repeat with theDisk in ejectableDisks
	do shell script "sudo rm -rvf " & quoted form of POSIX path of (theDisk as alias) & ".Trashes"
end repeat
end tell

Nice work!
Here’s your script in alias format:
# Empty the Trash on the main HDD and all ejectable mounted volumes
alias emptytrash="rm -rfv ~/.Trash; osascript <<< 'tell application \"Finder\"
    set ejectableDisks to every disk whose ejectable is true
    repeat with theDisk in ejectableDisks
        do shell script \"sudo rm -rvf \" & quoted form of POSIX path of (theDisk as alias) & \".Trashes\"
    end repeat
end tell'"

I noticed that wireless network disks have ejectable == false so this snippet doesn’t target them, unfortunately.
To be honest, I forgot why I wanted to exclude all partitions on the main HDD from this. I’m sure there was a reason… But for now, perhaps a simple sudo rm -rfv /Volumes/*/.Trashes could suffice after all.

authors: janmoesen mathiasbynens

repo: mathiasbynens/dotfiles


text:
bin: Update and improve httpcompression

:bowtie:

:+1:

authors: alrra mathiasbynens


text:
Fix UnicodeDecodeError when installing Django on a remote server

Should resolve #5.
Thanks @mathiasertl for the idea for the fix, tested to work for me at least.
Note: Built on top of #7 as that was useful in unit testing to check the test and fix worked on Python 2+3, so #7 should be reviewed first.
--
Additional testing notes:
# pip has a very useful --no-cache-dir option to force a re-download of a dependency
# which generates the progress bar with █ characters present
pip install --no-cache-dir
https://pip.pypa.io/en/stable/reference/pip_install/#caching

Large dependencies like Django tend to get more rendered progress bars, so I've had it fail usually between 14-32% of the way in, and never succeed without the connection getting closed (it does succeed in the background, so you can just rerun the fabric script).
For the final integration test I pip install -e ~/Projects/fabric and checked out the relevant branch then ran the relevant pip install --no-cache-dir Django==1.8.7 # or 1.8.8 (to force a change and download/progress bar) in a fabric script. Obviously results were as expected :beers:

Thanks @mathiasertl

repo: mathiasertl/fabric


text:
(KeyError) key :array? not found in v5

After upgrading from 4.1.1 to 5.0.0, I'm getting this compile-time error:
** (KeyError) key :array? not found in: [
  retain_unlisted_types_on_load: [],
  nilify_unlisted_types_on_load: [],
  type_field_name: :__type__,
  types: [
    my_type_a: MyApp.MyTypeA,
    my_type_b: MyApp.MyTypeB
  ],
  on_type_not_found: :raise,
  on_replace: :update,
  field: :data,
  schema: MyApp.MySchema
]
    (elixir 1.17.2) lib/keyword.ex:602: Keyword.fetch!/2
    (polymorphic_embed 5.0.0) lib/polymorphic_embed.ex:121: PolymorphicEmbed.init/1
    (ecto 3.12.1) lib/ecto/parameterized_type.ex:196: Ecto.ParameterizedType.init/2
    (ecto 3.12.1) lib/ecto/schema.ex:2058: Ecto.Schema.__field__/4
    lib/my_app/my_schema.ex:24: (module)

my_schema.ex:24 is:
  embedded_schema do
    field :data, PolymorphicEmbed,
      types: [
        my_type_a: MyApp.MyTypeA,
        my_type_b: MyApp.MyTypeB
      ],
      on_type_not_found: :raise,
      on_replace: :update
  end

Hello, interesting that you are using field instead of the macros polymorphic_embeds_one and polymorphic_embeds_many as documented.
Any reason?

Huh, I didn't notice. I don't know why it wasn't using polymorphic_embeds_one. I changed it and everything works fine. Thank you for the quick answer.

authors: mathieuprog woylie


text:
small problems with menclose

Issue Summary
There are some issues with positioning and length of 'strikes' arrows in menclose.
Also, RTL direction is not being handled (an issue only if RTL is meant to be handled).
Description:
Position and Length
Overall, there are some small rendering errors with the positioning of the strikes and arrow notation values. There are a few that are larger. You can see the contrast in the following. In the first example below, the arrows are close to correct -- the lines should go through the center of the '+' and through the division line as those are the centerpoint of the box. Within a subpixel, these are correct (shown zoomed at 200% to make it easier to see, but it is off at 100% also):

A problem with the above rendering is that the diagonal arrows are a little short and don't reach the box around the contents; the horizontal and vertical lines do touch the box.
If only left or right is given (as opposed to box which is both left and right), the position is worse:

I believe the problem occurs because the border padding is only added on one side. The positioning of the vertical line/arrow should not be affected by other decorations (as per the spec).
A similar problem happens with the horizontal positioning and top and bottom:

RTL
I didn't see anything in the MathJax docs that said MathJax supports right-to-left rendering. If it does, then you missed support of it on menclose. Here are three cases that should switch according to the spec:

Technical details:
I have put a large suite of test examples in codepen. It is using MathJax (see the JS section for details)

MathJax Version: 3.1.2 (CHTML Output Jax)
Happens with Chrome and Firefox.

Kudos:
I discovered these problems when working on a polyfill for MathML Core. I used the clever ideas for drawing the pieces with CSS borders in my polyfill. A big round of applause to whomever came up the CSS for drawing the arrowheads! I wouldn't have thought you could do that if I hadn't seen it written down.

Thanks for the report.  You are correct that the misplacement is due to the change in size on one side only.  I will look into how to resolve that.
For 19 and 20, do you mean that the arrow should be on the fraction line (not the center of the plus)?
We don't currently support RTL, but would like to in the future.
Thanks also for the kudos.  The arrows are my doing.  I was pleased that I was able to do all the enclosures with CSS, and didn't have to resort to SVG as I did in v2.

You are correct that the the text for 19 and 20 is incorrect -- copy/paste that wasn't updated. I'll fix up the codepen.

authors: NSoiffer dpvc

repo: mathjax/MathJax


text:
TryFindRoot allows negative accuracy which always fails to find a root

Brent.TryFindRoot and Bisection.TryFindRoot both allow a caller to pass in a negative value for the accuracy (arguably 0 could also be problematic, but should probably be permissible). However, the implementation of each means that it never considers itself to be within the requested accuracy, therefore always returns false.
Given that an accuracy is an absolute value, ideally the caller is either required to pass in a non-negative/positive value (i.e. throw ArgumentException(nameof(accuracy)) if a negative value is passed in) or accuracy should be converted to its absolute value.
Whichever solution is chosen should also be noted in documentation for the accuracy parameter on the TryFindRoots method, so users know what to expect.
I found this using MathNet.Numerics version 3.19.0 nuget package, from reading the code the issue is still present in master.

In what use case would one provide a negative accuracy parameter? What would be the desired intention of this? One could argue that a negative accuracy is impossible to reach, so always failing to find roots would be the expected result.
But I agree that either way this should at least be explicitly documented.

Since the accuracy is being checked against an absolute value already it seems to make the most sense to me to test the absolute value of accuracy and accuracy is usually written as +/-N which returns the same set of numbers for -N as +N.

I wish I understood roots better, but I'm way too far past my math classes.
I think if accuracy is expected to be an absolute value to mathematicians, then throwing an error on negatives makes sense.
If the accuracy checks should be for less-than or equal to the accuracy, then allowing 0 makes sense.  Right now the formulae are written with Math.Abs(fx) < accuracy, so 0 is impossible.
If anyone knows the rules for how this is supposed to work, I'll be glad to put in a PR updating the code and the XMLDoc to match.

I spoke with a data scientist I know and this is what he said...
"I don't think I've ever used a root finding implementation that didn't error when tol <= 0.  Zero as a tolerance can't happen except in the most ridiculous of trivial circumstances."
"Since Brent's method uses quadratic approximations it's probably more sensitive to the tolerance being too small, whereas bisection will be less sensitive... but once you get near that epsilon value then numerical errors start to swamp out your real goal."
"But yeah I'd error out on zero or negative tolerance."
I'll credit him by name later if he approves it.

https://github.com/mathnet/mathnet-numerics/pull/697 created to fix Brent and Bisection invalid accuracy values.

The PR looks good to me - throwing seemed the better solution to me as well.

PR merged - thanks!

authors: RyanGrange andrewimcclement cdrnet

repo: mathnet/mathnet-numerics


text:
Is it possiable that the id and title of group can be assigned

I tried to add group id with props.containerApi.addGroup({id:'customID', direction: 'within' }); , but it did not work
And in my case, title of group is very helpful
it is great if this two props can be added to the feature, thank you for any help you can provide

Providing the group id could probably be exposed. Groups do not have titles though and you also wouldn't be able to place a group with the direction within since that would imply placing a group inside another group.
Could you explain how you would see the title and direction property being applicable to a group here?

In order to create collapsible group, after collapsed, title can display as group name
#664

authors: chhsgithub mathuo

repo: mathuo/dockview


text:
🛑 Gestor Applicados21 is down

In e6f30f4, Gestor Applicados21 (https://applicados21.e-valuados.com) was down:

HTTP code: 502
Response time: 63 ms

Resolved: Gestor Applicados21 is back up in df8d6ca after 8 minutes.

repo: matiasmir/status


text:
improve brew install

Upgraded to the latest version of swift-graphql, declared dependencies with uses_from_macos, fixed indentation.

Thanks! This is great 🙌

PS.: Do you by chance know of any GitHub action that could automate the brew file update on every release?

authors: maticzav singingwolfboy

repo: maticzav/swift-graphql


text:
Make compatible with SwiftBar

Current version of SwiftBar (https://github.com/swiftbar/SwiftBar/) doesn't works well with the plugin.
Investigate issues, create PR or Issue in SwiftBar repo

It is fully compatible with current version of swiftbar

It is fully compatible with current version of swiftbar

repo: matopeto/xcode-build-times


text:
Install basemap in google colab

Hello there, I was used the following script to install Basemap in Google Colab.
!apt-get install libgeos-3.5.0
!apt-get install libgeos-dev
!pip install https://github.com/matplotlib/basemap/archive/master.zip
But this script didn't work anymore because of some update in the github repo. Can anyone help me how to install basemap right now (after the update)? Here is the error messages:
ERROR: HTTP error 404 while getting https://github.com/matplotlib/basemap/archive/basemap-master.zip
ERROR: Could not install requirement https://github.com/matplotlib/basemap/archive/basemap-master.zip because of HTTP error 404 Client Error: Not Found for url: https://codeload.github.com/matplotlib/basemap/zip/basemap-master for URL https://github.com/matplotlib/basemap/archive/basemap-master.zip
Thanks in advance.

@titan-khan Thanks for the feedback and sorry for the inconvenience!
I was doing a big refactoring of the basemap project in order to make the wheel packaging easier. Now basemap is split in three parts (basemap, basemap-data, basemap-data-hires), these three packages are now under the packages folder and there is no setup.py file at the top-level folder anymore. That is probably why it is failing to you.
Could you give a try to the recent wheels that I uploaded to PyPI? We have at the moment the beta release 1.3.0b1 there (with libgeos already bundled so no need of compiling anything by yourself):
!pip install "basemap == 1.3.0b1" "basemap-data == 1.3.0b1"

If you need the high-resolution data files, just add "basemap-data-hires == 1.3.0b1" to the former pip call. At the moment you need to specify both basemap and basemap-data as basemap depends on basemap-data and pip cannot find it because we only have beta releases at the moment. Once we have the final version 1.3.0, you will be able to do:
!pip install basemap

and then basemap-data will get downloaded automatically too.

Hi @molinav, thank you for the response. Your suggested solution have solved my problem. Now, I can install it successfully in my google colab. And I would like to thanks for your hard work to make the installation of Basemap easier.  Looking forward for the final version 1.3.0!

Maybe someone is making changes again?
Yesterday I was working a lot with basemap. Today I got an error 'no module named mpl_toolkits.basemap'
Anyone knows what's going on with this libraries and toolkits?
Thanks!

Hi @FenixDigitalB. How did you try to install basemap in Google Colab? I have just tried it out and it works:
!pip install basemap

Output:
Collecting basemap
  Downloading basemap-1.3.1-cp37-cp37m-manylinux1_x86_64.whl (862 kB)
     |████████████████████████████████| 862 kB 5.0 MB/s
Collecting pyshp<2.2,>=1.2
  Downloading pyshp-2.1.3.tar.gz (219 kB)
     |████████████████████████████████| 219 kB 50.1 MB/s
Requirement already satisfied: six<1.16,>=1.10 in /usr/local/lib/python3.7/dist-packages (from basemap) (1.15.0)
Collecting pyproj<3.4.0,>=1.9.3
  Downloading pyproj-3.2.1-cp37-cp37m-manylinux2010_x86_64.whl (6.3 MB)
     |████████████████████████████████| 6.3 MB 51.6 MB/s
Requirement already satisfied: matplotlib<3.6,>=1.5 in /usr/local/lib/python3.7/dist-packages (from basemap) (3.2.2)
Requirement already satisfied: numpy<1.22,>=1.19 in /usr/local/lib/python3.7/dist-packages (from basemap) (1.19.5)
Collecting basemap-data<1.4,>=1.3
  Downloading basemap_data-1.3.0-py2.py3-none-any.whl (30.5 MB)
     |████████████████████████████████| 30.5 MB 55.8 MB/s
Requirement already satisfied: pyparsing!=2.0.4,!=2.1.2,!=2.1.6,>=2.0.1 in /usr/local/lib/python3.7/dist-packages (from matplotlib<3.6,>=1.5->basemap) (3.0.6)
Requirement already satisfied: cycler>=0.10 in /usr/local/lib/python3.7/dist-packages (from matplotlib<3.6,>=1.5->basemap) (0.11.0)
Requirement already satisfied: kiwisolver>=1.0.1 in /usr/local/lib/python3.7/dist-packages (from matplotlib<3.6,>=1.5->basemap) (1.3.2)
Requirement already satisfied: python-dateutil>=2.1 in /usr/local/lib/python3.7/dist-packages (from matplotlib<3.6,>=1.5->basemap) (2.8.2)
Requirement already satisfied: certifi in /usr/local/lib/python3.7/dist-packages (from pyproj<3.4.0,>=1.9.3->basemap) (2021.10.8)
Building wheels for collected packages: pyshp
  Building wheel for pyshp (setup.py) ... done
  Created wheel for pyshp: filename=pyshp-2.1.3-py3-none-any.whl size=37324 sha256=7b9a5e94151002117c08fe6f93fb17c94ca6370c93fc1eaced83dab23011ff2a
  Stored in directory: /root/.cache/pip/wheels/43/f8/87/53c8cd41545ba20e536ea29a8fcb5431b5f477ca50d5dffbbe
Successfully built pyshp
Installing collected packages: pyshp, pyproj, basemap-data, basemap
Successfully installed basemap-1.3.1 basemap-data-1.3.0 pyproj-3.2.1 pyshp-2.1.3

WARNING: The following packages were previously imported in this runtime:
  [mpl_toolkits]
You must restart the runtime in order to use newly installed versions.

Then I restart the colab runtime, and this:
from mpl_toolkits import basemap
print(basemap.__version__)

returns:
1.3.1

as expected.

Yes.
I don't know what happened, but it started working a while after I post my question.
Thanks for checking!

authors: FenixDigitalB molinav titan-khan

repo: matplotlib/basemap


text:
Delete all files uploaded by specifi user

there should be an option to delete all media uploaded by specific user or deleting a user should delete the uploaded files on the server
spammers are taking advantage of this issue through using flooding bots to upload bulk data on the server and flood it there should be an options to ban this behavior

this seems like it would be an implementation-specific feature, rather than something appropriate to the Matrix protocol as a whole?
For Synapse, I don't think there is a way to do this directly, but you should be able to script something by combining the "list media of a user" api with the "delete media" api.

authors: githuberyt richvdh

repo: matrix-org/matrix-doc


text:
Fix scale and position for cameras with non 16:9 aspect ratio

Before:

After:

A comment in the code mentions

All this binding and transforming essentially aims to make the iframe behave like background-size: cover

Not sure if it would be better for the image/iframe to behave as contain?

Yeah, you're right


text:
com.squareup.moshi.JsonDataException: Expected an int but was ....

I've found this very rare error and I did not see it posted as an issue.
I compiled with the latest commit: 25bd4a4
Error:
[1 ->] GET https://oauth.reddit.com/r/MisleadingPuddles/new?limit=100&sort=new&raw_json=1
[<- 1] 200 application/json: '{"kind": "Listing", "data": {"after": "t3_3flxcj", "dist": 100, "modhash": null, "whitelist_status": null, "children": [{"kind": "t3", "data": {"domain": "i.imgur.co(...)
Exception in thread "main" com.squareup.moshi.JsonDataException: Expected an int but was 3153600000 at path $.data.children[82].data.secure_media.oembed.cache_age
	at com.squareup.moshi.JsonUtf8Reader.nextInt(JsonUtf8Reader.java:853)
	at com.squareup.moshi.StandardJsonAdapters$7.fromJson(StandardJsonAdapters.java:163)
	at com.squareup.moshi.StandardJsonAdapters$7.fromJson(StandardJsonAdapters.java:161)
	at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
	at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
	at net.dean.jraw.models.AutoValue_EmbeddedMedia_OEmbed$MoshiJsonAdapter.fromJson(AutoValue_EmbeddedMedia_OEmbed.java:102)
	at net.dean.jraw.models.AutoValue_EmbeddedMedia_OEmbed$MoshiJsonAdapter.fromJson(AutoValue_EmbeddedMedia_OEmbed.java:18)
	at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
	at net.dean.jraw.models.AutoValue_EmbeddedMedia$MoshiJsonAdapter.fromJson(AutoValue_EmbeddedMedia.java:44)
	at net.dean.jraw.models.AutoValue_EmbeddedMedia$MoshiJsonAdapter.fromJson(AutoValue_EmbeddedMedia.java:17)
	at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
	at net.dean.jraw.models.AutoValue_Submission$MoshiJsonAdapter.fromJson(AutoValue_Submission.java:219)
	at net.dean.jraw.models.AutoValue_Submission$MoshiJsonAdapter.fromJson(AutoValue_Submission.java:30)
	at net.dean.jraw.models.internal.AutoValue_RedditModelEnvelope$MoshiJsonAdapter.fromJson(AutoValue_RedditModelEnvelope.java:38)
	at net.dean.jraw.models.internal.AutoValue_RedditModelEnvelope$MoshiJsonAdapter.fromJson(AutoValue_RedditModelEnvelope.java:17)
	at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
	at net.dean.jraw.databind.RedditModelAdapterFactory$StaticAdapter.fromJson(RedditModelAdapterFactory.kt:112)
	at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:128)
	at net.dean.jraw.databind.RedditModelAdapterFactory$ListingAdapter.readListing(RedditModelAdapterFactory.kt:197)
	at net.dean.jraw.databind.RedditModelAdapterFactory$ListingAdapter.fromJson(RedditModelAdapterFactory.kt:168)
	at net.dean.jraw.databind.RedditModelAdapterFactory$ListingAdapter.fromJson(RedditModelAdapterFactory.kt:154)
	at com.squareup.moshi.JsonAdapter.fromJson(JsonAdapter.java:35)
	at com.squareup.moshi.JsonAdapter.fromJson(JsonAdapter.java:39)
	at net.dean.jraw.http.HttpResponse.deserializeWith(HttpResponse.kt:49)
	at net.dean.jraw.pagination.Paginator.next(Paginator.kt:66)
	at net.dean.jraw.pagination.Paginator$iterator$1.next(Paginator.kt:80)
	at net.dean.jraw.pagination.Paginator$iterator$1.next(Paginator.kt:78)
	...

Edit.: If it helps you in any way, here is the link to the post

Signed 32-bit integers store a maximum value of ~2 billion, but the value in question is 3.1 billion. The fix here is to just change the type of EmbeddedMedia.getCacheAge() to Long

authors: andrasferenczi mattbdean

repo: mattbdean/JRAW


text:
Profile spectroscopic data reduction

Calibration has become slow for SARDARA data. It's time for a new profiling

Main culprit was the plotting done for debugging purposes. Now performance acceptable.

repo: matteobachetti/srt-single-dish-tools


text:
Save _id as "ObjectId" instead of "String"

Folks,
After migration from 3.1.5 (with .net core 2.1) to 6.3.5 (with .net core 3.1), the object has been saved as "String" instead of "ObjectId".
I tried without success override Id property, althought it saves two "Ids" in collection.
Startup:
services.AddIdentityMongoDbProvider<ApplicationUser, ApplicationRole>(identityOptions =>
         {
             identityOptions.Password.RequiredLength = 6;
             identityOptions.Password.RequireLowercase = true;
             identityOptions.Password.RequireUppercase = true;
             identityOptions.Password.RequireNonAlphanumeric = true;
             identityOptions.Password.RequireDigit = true;
         }, mongoIdentityOptions => {
             mongoIdentityOptions.ConnectionString = Configuration.GetConnectionString("MongoDbDatabase");
         });

ApplicationUser:
private string _id;
    [BsonRepresentation(BsonType.ObjectId)]
    public override string Id {
        get { return this._id;}
        set
        {
            ObjectId result;
            if (!ObjectId.TryParse(value, out result))
                value = ObjectId.GenerateNewId().ToString();
            this._id = value;
        }
    }

Startup:
Data:
{     "_id" : "5e855b9506cf7b1818579dce",     "UserName" : "fernando@cerkal.com.br",     "NormalizedUserName" : "FERNANDO@CERKAL.COM.BR",     "Email" : "fernando@cerkal.com.br",     "NormalizedEmail" : "FERNANDO@CERKAL.COM.BR",     "EmailConfirmed" : false,     "PasswordHash" : "AQAAAAEAACcQAAAAEJrg3Xf5Yw3ss8zFwtOhYG3ln/gHIvhrVZg+y4ZH4c6Wt0kvmY9LAvZk5X9FDEqkLw==",     "SecurityStamp" : "ET5JPIOZ7PL4I4433MSEWCY3HXZEVFZL",     "ConcurrencyStamp" : "3dbf8453-109e-443d-888f-cdf06d34a260",     "PhoneNumber" : "21995555555",     "PhoneNumberConfirmed" : false,     "TwoFactorEnabled" : false,     "LockoutEnd" : null,     "LockoutEnabled" : true,     "AccessFailedCount" : 0,     "AuthenticatorKey" : null,     "Roles" : [          "partner"     ],     "Claims" : [],     "Logins" : [],     "Tokens" : [],     "RecoveryCodes" : [],     "Name" : "Luiz",     "FacebookId" : NumberLong(0),     "PictureUrl" : null,     "BirthDate" : ISODate("2000-03-26T23:59:59.999Z"),     "RegNumber" : "05775741856",     "ActivateNumbers" : "145586",     "Id" : ObjectId("5e855b9506cf7b1818579dce") }

@fernandocerkal nuget package was recently updated and added support for ObjectId. Please update your version to 6.7.0


text:
Implement basic autoupdate

This will add autoupdate for windows and possibly osx via electron-gh-releases
I can't really work on the OSX side of things.
Windows is done and works, you just need to build an installer and upload them to the github releases. Like I did here
OSX is missing the 'auto-updater.json' and probably the signing, see documentation here
There is also an package to simplify the osx part of the release: https://github.com/jenslind/electron-release

HI @Razzeee, appreciate your thoughtfulness and your PR here.
Auto-update is a feature that is definitely desired long term. Right now, we need to focus on code-signing, installers, documentation and a few higher priority fundamentals before auto-update is the top priority.
Also, we want to be careful about not accepting PRs too early, before features have achieved the full vision of their contributors.
Would you be open to maintaining a long-running fork of the repo with your auto-update work, so community members can try out the feature, share feedback, and mature the functionality before it's merged into master?
While it's a little more work to maintain, in our minds it will lead to the highest quality outcome.

Hey @it33

Auto-update is a feature that is definitely desired long term. Right now, we need to focus on code-signing, installers, documentation and a few higher priority fundamentals before auto-update is the top priority.

Your probably refering to #137
The problem is there is not much I can work on there:

needs jenkins access
probably can't do it because you need to offer the cert
no ftp access to your side
can do, but no code signing yet
again no ftp access or way to automate it without jenkins access
that's a platform feature and not for this repo

So well it seems like I'm out of luck. :( ;)

Also, we want to be careful about not accepting PRs too early, before features have achieved the full vision of their contributors.

Not sure how this doesn't seem mature enough.  Other then the OSX version missing and the desktop version moving the releases away from github. Which would be nice, but somebody would need to setup a squirrel server for us. One of these servers: https://github.com/electron/electron/blob/master/docs/api/auto-updater.md#autoupdater

Would you be open to maintaining a long-running fork of the repo with your auto-update work, so community members can try out the feature, share feedback, and mature the functionality before it's merged into master?

Can do, but it would be pretty worthless if you can get a server setup on your end. So if that is possible in a timely manner I would like to not do the fork. I'm a branded child regarding server admins getting servers going for open source... So I choose the way we could benefit right now in the PR.

Thanks @Razzeee,
Makes sense,
Highly appreciate your patience, we're trying to get code signing and Jenkins up--we definitely want this.
Also thanks for continuing to build as we try to get everything spun up.

@it33 So code signing and jenkins is done right?
Is there a ticket to install an auto update server?

Thanks @Razzeee,
We're still looking into some updates with Windows code-signing, and I'll post an update once we know more.
Thanks for your patience, as it will be a great improvement to have for the desktop apps.

Please make the auto updater optional. When this feature request about adding admin configuration for software deployments in companies gets accepted, companies most likely don't want auto update. That is what software deployment is for. Also, in many companies the users don't have admin rights on their computers and an update would fail anyways on Windows with an installer.
Until the named feature is implemented, please at least add an option to the user config on if to enable the auto update feature.

There are setups that don't need to hae admin rights. See clickonce etc, haven't really checked how electron does it.

On a company computer I want it to be installed for all users on the machine. If it is stored at a location where the user can change the program files, they could also change the proposed way the admin config is set up etc. Another reason to disable auto update is that I don't want 300 clients downloading the same setup and clog our internet access. I know the setup isn't that big, but 50MB x 300 is 15GB that have to go through in the morning of the update. The next reason not to allow auto update: You want to test the update on a few limited machines first and then do the full roll out or continue in steps.
There are many reasons why auto update should be an optional feature. I'm okay with it if it is there and turned on by default (it's a good thing for private machines), but the admin or end user should decide if it happens or not.

Hey @Razzeee, I think we've got the desktop app into a state where we can consider taking a pull request that let's users check for updates. Added to v3.5 tag.
We should first carefully consider the design and how it should work, such as whether to use automatic updates, whether to make it optional, and so on.
Once we have the design nailed down including a clear vision of how it should work, we'd be ready to start on the implementation.
How would you feel about that?

Sounds good to me. Another thing you need to talk about is having a server,
that knows that there is an update.
On Sat, Oct 8, 2016, 02:40 Jason Blais notifications@github.com wrote:

Hey @Razzeee https://github.com/Razzeee, I think we've got the desktop
app into a state where we can consider taking a pull request that let's
users check for updates. Added to v3.5 tag.
We should first carefully consider the design and how it should work, such
as whether to use automatic updates, whether to make it optional, and so
on.
Once we have the design nailed down including a clear vision of how it
should work, we'd be ready to start on the implementation.
How would you feel about that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattermost/desktop/pull/162#issuecomment-252390811,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFqyZDguGun4orxKe54RDqYy6PMFwFJEks5qxuaFgaJpZM4IzY5S
.

FYI - here's an early draft of a plan for auto-updates if anyone is interested to take a look. https://docs.google.com/document/d/1ITm0ZsRdo0ER_nVcAB31aaBi5CvDXE52OOUGBXHBTx4/edit
If you have any feedback, feel free to add notes and comments on the document or in this thread.
Note that the spec is at an early stage and is subject to change.

Thanks @Razzeee for the pull request!
Per the CONTRIBUTING.md file displayed when you created this pull request, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
This is a standard procedure for many open source projects. Your form should be processed within 24 hours and reviewers for your pull request will be able to proceed.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

The bot misfired here?

Sorry for the noise @Razzeee, we've been working on adding a bot to all the mattermost repos, which triggered a few unnecessary notifications
Hope you're doing well! :)

Doing fine.
Just wondered what's going on :)

This PR is covered by #582
//cc @yuya-oc

authors: Razzeee it33 jasonblais mattermod meilon

repo: mattermost/desktop


text:
Permalink previews

Added documentation for permalink previews under Channels > Work with Messages > Sharing Messages

Tweaked slightly, thanks Carrie

@cwarnermm I added Do Not Merge label for now as the feature may be disabled for this release.

This is ok to merge.

authors: amyblais cwarnermm esethna

repo: mattermost/docs


text:
MM-15431 Removing apple cert configmaps and replacing them with k8s secrets

Jira Ticket -> https://mattermost.atlassian.net/browse/MM-15431

The current helm chart is using configmaps to create the pem files for Apple certs.
The update replaces configmaps with K8s secrets.

After the PR merge the new push proxy helm chart version will be pushed to the production k8s cluster and will be used by Mattermost community.

@cpanato It is tested but not yet deployed in prod. I was waiting for the PR review. I will deploy it later today and if all good, then I will merge this ;)

@stylianosrigas but did you test the upgrade?

@cpanato I created a new cluster where I deployed the old push-proxy helm chart and then I upgraded using my new chart. It upgraded smoothly with no interruption in the notifications.

authors: cpanato stylianosrigas

repo: mattermost/mattermost-helm


text:
Clear failed images from post draft when posting

Ticket Link
https://mattermost.atlassian.net/browse/RN-538

@hmhealey done

great catch @mkraft fixed it

repo: mattermost/mattermost-mobile


text:
WIP: [GH-6597] introduce Phabricator support

Summary
Support for login through Phabricator.
Ticket Link
Fixes: https://github.com/mattermost/mattermost-mobile/issues/6597
Checklist

[ ] Added or updated unit tests (required for all new features)
[x] Has UI changes
[x] Includes text changes and localization file updates
[ ] Have tested against the 5 core themes to ensure consistency between them.

Device Information
This PR was tested on:
Screenshots

Release Note
Added support for login through Phabricator.

Hello @okias,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.
Per the Mattermost Contribution Guide, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
Once you have signed the CLA, please comment with /check-cla and confirm that the CLA check is green.
This is a standard procedure for many open source projects.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

Adding @laneycs as she is the PM owner for the Suite Users team who owns authentication

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

I'm not sure where we landed with this PR @mkraft I think there was a related PR that we commented in with more questions before we could take action on this ticket, but I can't recall where it lives.

@mkraft @laneycs if adding this auth method is not expected, I'm going to close this PR, specially cause this is for the v1 app that is not accepting new features at the moment.
please feel free to re-open or better yet, submit it against the v2 app once a decision is made to include the auth method.
Thanks.

authors: enahum esethna laneycs mattermod okias


text:
[MM-58397] Add calls offloader metrics, incl. cpu, memory, and live captions

Summary

Adds an offloader row and a few panels for offloader health.
Merge when Calls v0.28.0 is released

Screenshot:

Ticket Link

https://mattermost.atlassian.net/browse/MM-58397

@cpoile This can be merged now.


text:
PLT-7917: Auto-close archived dms

Summary
This makes DMs auto-close when the other user is deactivated.
Ticket Link
https://mattermost.atlassian.net/browse/PLT-7917?filter=14400
Checklist

[x] Added or updated unit tests (required for all new features)

Test Information
This PR was tested on: Chrome/Firefox on Mac

Not my build error. #336 is failing to the same issue.

@enahum Updated! I think that was the only one (Calls for group channels don't need to be updated.).

repo: mattermost/mattermost-redux


text:
[BUG] Execute binary with LDC >= 1.19 cannot find 'cc'

Using execute binary works with LDC < 1.19.
With LDC >= 1.19 it no longer works, with the error: Error: failed to locate cc. This is because of https://github.com/ldc-developers/ldc/pull/3202 . LDC >= 1.19 defaults to calling cc if the environment variable CC is not defined. Previously, gcc was used on CE's platform. The temporary fix is to explicitly add -gcc=gcc to the compiler arguments.
Probably best to specify CC=gcc in the container?

HI @JohanEngelen ! We don't have a container as such any more: I'd suggest we pass -gcc=<path_to_a_known_gcc> in either the compiler/ldc.js or in the settings for the ldc compilers. Probably the latter for best (we do this e.g. for clang : https://github.com/mattgodbolt/compiler-explorer/blob/08772b98041f88142c15861fec53c04c7d5f2e40/etc/config/c%2B%2B.amazon.properties#L124 for example

authors: JohanEngelen mattgodbolt

repo: mattgodbolt/compiler-explorer


text:
Add spacing between address and opcodes in binary view

As requested via email; they're a bit close together.

Can't do much until https://github.com/Microsoft/monaco-editor/issues/515 is adressed, as it would become unreadable if spacing was to be added

Duplicate of #484

authors: RabsRincon mattgodbolt


text:
Ada language support

Hi,
I have attempted to add support for Ada to the Compiler Explorer using the GNAT compiler. I have been able to get syntax highlighting working in the editor, all example programs compile and produce an assembly file that can be viewed. Currently the default result of compilation is just an assembly file, no binary is produced and there is no execution available. I have attempted to get this working locally, but GNAT is being a bit of a pain and I'm not an expert on using the GNAT compiler. It should however at least give someone who is a starting point.
I have based the ada.amazon.properties file on the fortran.amazon.properties file. I believe that GNAT should be included in GCC much like GFORTRAN if the build includes Ada as a language, if this is not the case let me know what I need to change.
I have run make lint and make check and everything appears to be passing for the Ada support.
Please let me know if there is anything else I may have missed.

Hello @Mitchtdk! Thank you for taking the time to implement Ada to the CE supported languages, it looks really good, and the code is super nicely commented :)
We need to check that we do indeed have Ada available, or change some things around to get it. We'll get back to you as soon as possible with more info.
Thank you again for your contribution :)

Hi @Mitchtdk, sorry for the lack of updates!
We currently do not build/have access to GCC's gnat binaries, but it should not be too hard to change the necessary bits over at the sister repo.
If you want, feel free to open a PR there (mattgodbolt/compiler-explorer-image), otherwise, we will end up adding it ourselves, but it may take a while until we actually do add it (You might have noticed we're all kinda busy around here! :) )

authors: Mitchtdk RabsRincon


text:
Interceptors / Default Headers

I'm trying to include an auth header in each request to my API.
I can do this with jQuery.ajax using beforeSend, and AngularJS has something called interceptors which make it really easy.
But I can't figure out how to do this using fetch. Any ideas?

Why don't you make a new function?
function makeAuthenticatedRequest(url, opts) {
  opts.headers = opts.headers || {};
  opts.header.Authorization = "a-secret";
  return fetch(url, opts);
}

then use that?

authors: lynndylanhurley matthew-andrews

repo: matthew-andrews/isomorphic-fetch


text:
Plot of maxferet, minferet etc.

I want the option to call feret.max(img, plot=True) and get a plot which shows the image, the two parallel lines which enclose the object and a line that runs along the maxferet.
Analog for minferet.
And analog for maxferet90 and minferet90, if #10 is solved.
I think the best would be to have a own plot.py file.

a feret.plot(img) method is implemented now,

repo: matthiasnwt/feret


text:
bin_age_csv missing in util/init

Hi all,
I'm an R guy. I was trying bucky and bumped into an error early on when running:
./bmodel make_input_graph -d 2020-10-01
I solved it by adding "bin_age_csv" to the bucky/util/__init__.py  file as follows:
# flake8: noqa  # pylint: disable=missing-module-docstring
from .util import TqdmLoggingHandler, _banner, cache_files, dotdict, estimate_IFR, bin_age_csv

Cheers

Thanks for the report,
This should now be fixed in devel by https://github.com/mattkinsey/bucky/commit/5437645d24cd6ee0cb46f9b84ce7943903e949fd

authors: marounbs mattkinsey

repo: mattkinsey/bucky


text:
Set bootstrap as optionalPeerDependency

According to the doc:
Bootstrap 3+ (CSS only - optional if you use a custom template)
So bootstrap is not always required.
I think you could add it as optional peer dependency.

Agreed, I've just completely removed bootstrap as a dependency so you're free not to use it.


text:
Remove unused variables

There are a few instances of assigning a result and an error, but the result is not used. That variable is always used later in the test so setting := there

Thank you

authors: mattn mellowdrifter

repo: mattn/go-mastodon


text:
Overlay devices icon

Hi!
I'm trying to improve a bit the vuforia overlay, by making it a bit customizable (now that we have an options object, we can add many optionals parameters).
Do you need to keep the devices icon? It doesn't look essential, and doesn't fit well with what I'm doing.
Thank you!

The devices icon is kind of an artefact... It was added as a 'scan a page with this icon on it' kind of thing
It's not essential, but just removing it wholesale seems a bit permanent... We could make an options flag that allows it to not be added to the screen?

Okay, now the devices icon is optional, and disabled by default! I have some changes to do, I'll do my pull request soon.
Thank you!

authors: Stending mattrayner

repo: mattrayner/cordova-plugin-vuforia