switch / case / match semantics

As discussed on Discord, we have a fully functioning switch statement from #1278 thanks to @aljazerzen, and there are a couple of options on how this is done:
Conditions
switch [
  score <= 10 -> "low",
  score <= 30 -> "medium",
  score <= 70 -> "high",
  true -> "very high",
]

Advantage — anything is representable in a reasonable way
This is the current approach in main

Compare against a value
switch score [
  <= 10 -> "low",
  <= 30 -> "medium",
  <= 70 -> "high",
  _ -> "very high",
]

Advantage — visually simpler and more concise (personally I really like the thinking process of "OK we care about foo, no need to learn that on each subsequent line")

Comparing a single expression to multiple possible values in a very common use of a logic branch like this

Disadvantages:

We probably need to adjust our parser to allow <= foo as a valid expression — does everything become a UnOp?
Representing a full condition is possible but inelegant ("OK we care about true"??)switch true [
  score <= 10 -> "low",
  status == "exempt" -> "exempt",
]

...since status == "exempt" is compared to true.

Allow an optional condition
Allow either of these. This seems quite compelling, and there's a track-record from other languages. But there are some tradeoffs:

We'd need to use a named parameterswitch on:score [
  <= 10 -> "low",
  <= 30 -> "medium",
  <= 70 -> "high",
  _ -> "very high",
]

We still pay the costs of adjusting the parser to alow for <= 10 as a valid expression.

...or allow for optional positional parameters (which we don't currently do). I'm not entirely opposed to this at some point, though it does make our parameter logic more complicated. Allowing "optional positional parameters with a default of null" doesn't complicate the language much, but isn't sufficient here, since the optional parameter would come first, meaning we'd need something like multiple dispatch. Type-checking and autocomplete could become much more difficult.

Naming

Most languages call this switch, e.g. C / Java / etc
Python calls this match, though also does some level of pattern matching
Kotlin calls this when

SQL calls this case...when...then, quite the coalition...
Defaults
I rather like the approach of defaulting to null (which is what the current implementation does). We can't have exhaustive pattern matching anyway, so I'm not sure there's much cost.

From the proposed syntaxes I like switch on: the most.
An alternative would be a separate match statement:
match x [
   ...
]

Regarding the parsing problem: we can get around that by using patterns:
match x [
    1 -> 'one'
    2..5 -> 'a few',
    5.. -> 'many'
]

We'd have to support ranges for characters, numbers and maybe strings.

Regarding the parsing problem: we can get around that by using patterns:
match x [
    1 -> 'one'
    2..5 -> 'a few',
    5.. -> 'many'
]

We'd have to support ranges for characters, numbers and maybe strings.

Yes interesting, that does work for lots of cases (similar to rust I guess). What would the semantics be here? "Use x | in y where x is the matched value and y is the value on the left side of the match branch"?
Because we can't do proper pattern matching, we don't give as much up by having semantics of "just put x at the beginning of the expression", like:
match x [
    == 1 -> 'one'
    | in 2..5 -> 'a few',
    | in 5..10 -> 'many'
    != null -> 'out of bounds'
    == null -> 'null'
]

though we could have guards so we get something similar with the slicker syntax of the original suggestion:
match x [
    1 -> 'one'
    2..5 -> 'a few',
    5..10 -> 'many'
    _ if x != null -> 'out of bounds'
    null -> 'null'
]

(Something I just found with rust — if x is itself a range 2..5, then matching on it won't work, because 2..5 matches against a range of ints, I guess at the language level, not against the value of x)

Possibly the "closest" option is to allow switch on:x, do the == 1 -> 'one' option, and then later add a match statement. (but no strong view at all — all of these have tradeoffs)

Yes, the semantics of:
match x [
  cond1 -> val1
  .. -> val2
]

would be the same as of:
switch [
   x | in cond1 -> val1
   true -> val2
]

I don't like the guard too much, because it's heavy in additional syntax while it could be rewritten into:
match x [
    1 -> 'one'
    2..5 -> 'a few',
    5..10 -> 'many',
    _ -> switch [
        x != null -> 'out of bounds',
        true -> 'null',
    ]
]

Yes, this is not as clear as the "match with if guard", but for now, I think it's enough. I'm not keen on adding too much features that would bloat the language.

I'm in favour of keeping the current switch using conditions because conditions can reference different variables/columns as you fall through the ladder which can be useful (and is allowed by the underlying SQL).
I also support introducing a separate match statement for the common case where you want to compare a single column/expression against multiple values/conditions.
(Putting thoughts/ideas on match syntax in a separate reply so you can easily downvote/comment on that.)

Would it be possible to extend the match syntax so that it's not just for the in function but any function?
match x [
  in range1 -> val1
  func2 -> val2
  .. -> val3
]

would be the same as:
switch [
   x | in range1 -> val1
   x | func2 -> val2
   true -> val2
]

Then if any match condition involving _ could be rewritten into a lambda, e.g.
_ > 5 becomes func _lambda1 _ -> _ > 5 then you could write
match x [
  _ > 5 -> val1
  .. -> val3
]

would become
switch [
   x | (func _lambda1 _ -> _ > 5`) -> val2
   true -> val2
]

Of course there's not much gained over simply using switch when your match expression is simply x but when you're matching instead on something like (temp_fahrenheit - 32) / 1.8 or more complicated then that is quite a saving.
Of course this goes against "not introducing too many features into the language".

Actually, given that we don't have late binding for functions, I guess my lambda acrobatics above wouldn't work for the common case of
match col1 [
  _ > col2 -> val2,
  ... -> val3
]

since that would become
switch [
   col1 | (func _lambda1 _ -> _ > col2`) -> val2
   true -> val3
]

Better just to rewrite the expression involving the _ if you were to go that route.

Interesting "pattern is a function" idea. I really like the functional aspect of it.
Rewriting _ into lambda can be a separate feature that can work in general (and it would be useful in pipelines).
We can start with this:
match x [
  in foo -> val1,
  eq bar -> val2,
  func2 -> val3,
  default -> val4,
]
# ... is equivalent to:
switch [
  (x | in foo) -> val1,
  (x | eq bar) -> val2,
  (x | func2) -> val3,
  (x | default) -> val4,
]

# ... where default is defined as:
func default x -> true
func eq a b -> a == b

For this to be ergonomic, we'd need a special impl for std.in:
func in pattern val -> {
   # internal compiler implementation
   if low..high = pattern {
     `val BETWEEN low and HIGH`
   } else if low.. = pattern {
     `val >= low`
   } else if ..high = pattern {
     `val <= high`
   } else if .. = pattern {
     `true`
   } else if list = pattern {
     `val IN (list)`
   } else {
      raise error
   }
}

Original example could be rewritten as:
match score [
  in ..10 -> "low",
  in ..30 -> "medium",
  in ..70 -> "high",
  eq null -> "missing",
  default -> "very high",
]

Cool. The _ lambda syntax is inspired / taken from this fn.py python package.
I've used it before and find it a pretty convenient way to write lambdas.

I have some reservations about the naming of the default function. I know it's standard to have the catch all clause in switch statements called "default" but given that this would be a globally available function, I worry that it might lead to unforeseen problems elsewhere. (For example I recall another discussion about aggregate functions returning default / identity elements when given of empty lists which would be a conflicting meaning of default.)
Some ideas for alternative names:

other
catch_all
true
(if you can have a function and constant with the same name that the compiler disambiguates based on type signature)
or_true
(inspired by the Rust or_else and and_then type combinators. Would go with another one called and_false which always returns false.)

If we're going to go with eq then we might as well go with all the other standard comparison operators as well (ne, gt, ge, lt, le) which I think are relatively well known from Python operator module, Bash Comparison operators, HTML Character Escape Codes.

Actually, from looking at your std.in implementation, I see you're already catering for a in .. case mapping to true, so with three extra cases you could probably get the whole thing done with the in function:
   } else if low<.. = pattern {
     `val > low`
   } else if ..<high = pattern {
     `val < high`
   } else if value = pattern {
     `val == value
   }

and then the example would be:
match score [
  in null -> "missing",
  in ..<0 -> "negative",
  in ..10 -> "low",
  in ..30 -> "medium",
  in ..70 -> "high",
  in 100<.. -> "very high",
  in .. -> "NaN",
]

I don't know if that would really be my preferred approach from a readability perspective, just saying you're almost there already with what you sketched out.
For comparison the lambda example would look something like the following:
match score [
  _==null -> "missing",
  _<0 -> "negative",
  _<=10 -> "low",
  _<=30 -> "medium",
  _<=70 -> "high",
  100<_ -> "very high",
  or_true -> "NaN",
]

Actually the previous case with just the in functions looks pretty neat. in null is probably the most awkward of the bunch and you could get rid of that by removing the equality case and just forcing people to use a single element list, i.e.
match score [
  in [null] -> "missing",
  in ..<0 -> "negative",
  ...
  in .. -> "NaN",
]

I have some reservations about the naming of the default function.

I see. We can hold off from defining default and use in .. as you suggested.

If we're going to go with eq then we might as well go with all the other standard comparison operators as well

Sure, I doubt there is any cost to this (unlikely column/table names).

   ...
   else if value = pattern {
     `val == value
   }

I initially wanted to do this, but it doesn't make much sense to say "match x in null". So I prefer match x eq null.

Thanks a lot for #1332.
I really like the approach of passing the arg into an implicit function!
I'm trying to think if we can keep  the syntax of the simple & most common case of "equal to this value" to be simple. I'm not a great fan of the functional form of the infix operators like eq — I'm imagining explaining to someone when they have to write eq rather than == and it being confusing.
Maybe there's a rule like "if the line starts with an infix operators such as ==, then the argument is on its left. Otherwise it's passed into an implicit function".
I'm reminded of Swift's approach of minimizing syntax where possible and unambiguous — the first half of https://docs.swift.org/swift-book/LanguageGuide/Closures.html
Let me think more over the weekend.

That's a valid concern: eq, lte, lt, ... are not ideal.
I don't like having == without left expr, because it's not convenient to parse and introduces new sytnax. Current approach is great on this side: new syntactic constructs are high-level and are composed from normal existing exprs.
Maybe we could have the special rule "if the condition is not a function, just use equals comparison".

Maybe we could have the special rule "if the condition is not a function, just use equals comparison".

Yes this sounds reasonable!
Is there an ambiguity when we want to say "is equal to the result of this function"?
match x [
  5 -> "five"
  add 3 3 -> "six"  # tries to do `add 3 3 x` and fails
]

...but possibly that's no big deal, this wouldn't be allowed, instead functions need to be pre-computed in a derive.

With this we'd cover only eq and leave out lt, lte, gt, gte and neq. But eq is most common by far and most of them can be expressed by ´in range´

Agree, this is completely fine for the lt etc. neq is an inconvenience but survivable.

I don't like having == without left expr, because it's not convenient to parse and introduces new sytnax.

This is fair, though one thing to note — == is already a unary operator from join [==id]. But != & >= & friends would indeed need parsing changes.

Something I realized while thinking about this is that Rust also has a small ambiguity:
    let x = 0..5;
    match x {
        0..5 => true,   # doesn't match based on equality of `0..5 == 0..5` like any other match
        _ => false
    }

...fails because ranges are special.

Not to expand the scope of this needlessly — but worth raising that these plans commit us to having in as a function, rather than an infix operator like and and or. Do we want that?
Whether things like in or as are infix or functions has no Correct answer — it's the usual tradeoff between convenience and consistency.
It's possible to have in like x in 5..10. This ingrains in in the language — it's not possible for standard functions to be infix — but we're already doing that.

[Speculative, need to think more]
So maaaybe there's a synthesis of this where in becomes infix, and match statements need to start with an infix operator. And either we disallow functions for consistency, force a pipe symbol at the start, or add a pipe symbol implicitly for convenience.

This is fair, though one thing to note — == is already a unary operator from join [==id].

This is actually a conflict between the two meanings. If use ==column in match, it this a unary operator or the binary with first arg omitted?

Something I realized while thinking about this is that Rust also has a small ambiguity:

If go for "value in match implies equality operator" semantics, we will also have a clash like this: you wouldn't be able to compare functions. But this doesn't make sense anyway, so it's not a problem.

these plans commit us to having in as a function

This is true and I don't like its current function signature. The fact that these two are idiomatic is not too appealing:
(x | in 1..5)
in 1..5 x

Another idea is to make all binary operations just normal functions (and maybe unary also).
Like have something like:
func binary in left right -> <built-in>
func binary + left right -> <built-in>

x in y
a + b

This is a major breaking change, because it then requires much more parenthesis:
derive 5 + 6
# would be parsed as:
FuncCall
- function: derive
- args: [5, +, 6]

derive (5 + 6)
# would be parsed as:
FuncCall:
  function: derive
  args:
  - FuncCall:
      function: +
      args: [5, 6]

This is a major inconvenience and also has some problems with resolving, so it more of an example of what we want to stay away from.
Essentially, binary operators are a more convenient, built-in way of calling functions. Their "names" are hardcoded into the parser and usually non-alphabetic symbols (+, %, <=) but not always (and, or).
Our problem right now is "how to call these operators with an implicit argument". And proposed solutions were:

define normal functions for each of the operators and use currying,
syntax for constructing lambda functions as _ == 4,
(only in match conditions) allow omitting the leading operand in binary ops.

This is fair, though one thing to note — == is already a unary operator from join [==id].

This is actually a conflict between the two meanings. If use ==column in match, it this a unary operator or the binary with first arg omitted?

I think the rules here would be "if there's a comparison operator, then use as a binary operator. Otherwise add an implicit pipe". So unary operators would always convert to binary operators when at the beginning of a match.
...which would indeed mean we'd need to allow comparison operators at the beginning of those expressions, which does require changing parsing a bit. But I think it would be manageable.

I can see a few alternatives here:

Status quo — we have the current binary operators built into the compiler
Extend infix [^1] operators slightly — i.e. as & in. Rust & Python do the same.

If we thought it were much simpler to understand, we could say "Symbols are infix, and only symbols", and use symbols for and & or & in (& as?).

Allow for more flexibility between infix & prefix operators, e.g. func binary + left right -> <built-in>

[^1]: I'm using "binary functions" & "infix operators" analogously. I think in APL — where they've thought a lot about this — they're similar but slightly different in some way... https://aplwiki.com/wiki/Dyadic_function]
I agree the final one is fraught with peril — we're trying to keep things simple, which sometimes requires thinking about things at a deeper level — but in this case I don't feel qualified to suggest changes at this level that would make things simpler overall.

(only in match conditions) allow omitting the leading operand in binary ops.

So I think I would vote for this — it seems quite simple to explain, doesn't complicate the parser much, and avoids having to define how things like currying would work for infix operators.
WDYT?

(only in match conditions) allow omitting the leading operand in binary ops.

If I expand this option a little, the syntax would look like:
match score [
  <= 10 -> "low",
  in ..30 -> "medium",
  <= 70 -> "high",
  != null -> "very high",
  in .. -> "missing",
]

Am still hesitant on having this unbalanced binary operations... They just don't fell right (although I may just get used to them).
There are now also two ways of doing comparison - which is a basic operation and should have only one idiomatic representation.
I cannot decide which of the options I like best or even which one I dislike the least.

There are now also two ways of doing comparison - which is a basic operation and should have only one idiomatic representation.

Definitely agree with the principle.

I'm less concerned that both in and >= work — that's the case with comparisons at the moment, and we can lint them into a single standard.
Having the cases work in two different ways is not ideal though. It's two, rather than some long discovery of edge cases, but still not ideal

I cannot decide which of the options I like best or even which one I dislike the least.

😆
We can always leave it for a bit. At some point we should start wrapping up 0.4, and maybe this is something we let drag over to 0.5 if we don't have a clear view? (Generally a fan of shipping & iterating, but if it's not blocking and we're not spending time on it, fine to leave!)

One more choice to add to the buffet: do we want this to be match or switch on:.
As part of my campaign to limit keywords, I would vote for switch on:, but not super-strongly, and as ever deferring to the do-ocracy.

With the current impl of match, it is not really much different than switch. When compared with pattern matching in Rust, this is a mere syntactic sugar for if/switch.
If we are to improve our type system, exhaustive pattern matching could be possible and may make much more sense. But we cannot know that now, as we don't have the type system yet.
So my suggestion is to postpone this until we have adequate type system.

I agree with the proposal to leave match for 0.5 or later and rather get 0.4 out with switch because that's a big win and enables a whole lot of new queries. As you pointed out, the proposed match would just be syntactic sugar and doesn't enable anything fundamentally new like switch.

Is there an ambiguity when we want to say "is equal to the result of this function"?

This actually alerted me to the fact that we're currently overloading -> for both function definitions and switch (and possibly match) clauses. Why don't we rather use => for switch like Rust does for match seeing that Rust also makes this distinction also using -> for function return types?
Perhaps this is not a problem for the parser at the moment but given that we may want to use -> for lambda function definitions (as alluded to in #523) then maybe this might become a problem later?

then maybe this might become a problem later?

You're right, this will become a problem if we wanted -> for lambda functions.

Perhaps this is not a problem for the parser at the moment but given that we may want to use -> for lambda function definitions (as alluded to in #523) then maybe this might become a problem later?

Yes good point.
My guess is that it will be "fudge-able" in the compiler. Because we won't be defining functions in a list, and won't be matching on lambda functions. And I don't think it will be confusing for users.
There's also a nice corollary between the two things: "give me the thing on the left and I'll give you the thing on the right":
# (currently `func add a b -> a + b`)
let add = a b -> a + b
switch x [5 -> "five"]

But I'm def open to the point that "these things are similar but not the same, and so having the same syntax is more confusing". Or that we'll hit issues in the compiler.

Looking at the example from here https://github.com/PRQL/prql/issues/1564#issuecomment-1387556359
# from playground
from tracks
select [
  category = switch [
    length > avg_length -> 'long'
  ]
]
group [category] (
  aggregate (count)
)

I'm +1 now changing this to => for switch.
# from playground
from tracks
select [
  category = switch [
    length > avg_length => 'long'
  ]
]
group [category] (
  aggregate (count)
)

What's the logic for the extra arrow type?
That functions and switch expression are sufficiently different and so should have different syntax?
I think we should have as little different syntax as possible, as long as it's not ambiguous — so we should need good reasons for adding a type of syntax.
For example, we use sort [-col], not sort [\col], because we already have a minus sign, and it's sufficiently clear, even though not quite as clear as the downward sloped slash would be.

Those are good questions @max-sixty and I agree that as a general rule we should have as little different syntax as possible.
I expressed my sentiment/vote, probably largely on feeling and observation but I will try to do my best to reason this out as far as possible. @max-sixty I think you actually already listed some of the reasons:

And I don't think it will be confusing for users.

I think it will be confusing, similarly to when people were asking, why can I do sort cost but not sort -cost (which has to be sort [-cost]. I wanted to weigh in on that conversation but didn't get to (yet, not sure if it's still open). I would vote for always requiring the [] as I think it would make simpler in people's minds. In this case, knowing that switch always takes => in my opinion will be simpler for users and they don't have to wonder "why doesn't this trigger a lambda definition" and have to think about how the compiler is context aware ...

But I'm def open to the point that "these things are similar but not the same, and so having the same syntax is more confusing".

I agree with this.

Or that we'll hit issues in the compiler.

That was also a concern of mine but one I can't really comment. However @aljazerzen in a follow up comment said that he thought this would become an issue. I'm actually less concerned though about this because there is a lot that compilers can easily understand that humans can't (e.g. look at code golf examples).

That functions and switch expression are sufficiently different and so should have different syntax?

Not really.
For me, in my last example it mostly came down to that I don't think it reads well.
  category = switch [
    length > avg_length -> 'long'
  ]

Scanning it, my eye first hit the -> and I thought "oh there's a function definition" which then goes into "that doesn't make sense there", then I scan out and see that it's a switch so I try to reparse it and now it looks like blah > blah > blah so it looked like two greater than signs in a row because the minus is quite easy to miss. Of course then you go through it slowly and it all makes sense but it's not as convenient as it could be. To me it goes against the "Don't make me think" maxim of design.
"So @snth, you're saying that -> looks too much like >?"
"I guess ... kinda ... yes."
"So won't that be an issue for lambda definitions as well?"
"Hmmm.... let me think". Actually no, I don't think so because there you'll only have identifiers on the LHS whereas in a switch expression you'll often have comparison operators.
Overall I think the following just reads much better because the double lines in => are much stronger:
  category = switch [
    length > avg_length => 'long'
  ]

What about when you have a == on the left? Good point, I don't know. Let's try it and see:
  category = switch [
    length == avg_length => 'avg'
  ]

Still seems fine to me, whereas
  category = switch [
    length == avg_length -> 'avg'
  ]

I don't know, ... it just seems to lack enough gravitas or strength to "move" you to the expression on the right 🤷♂ Does that make any sense? I know it's a bit wishy washy and not really scientific or measurable but if I try to explain it, I think that's kinda what I based my vote on.
For me it's just about creating the most beautiful language that's the most fun to use and this seemed better. Plus, Rust does it that way so there's that. 😀

I don't know, ... it just seems to lack enough gravitas or strength to "move" you to the expression on the right 🤷♂ Does that make any sense? I know it's a bit wishy washy and not really scientific or measurable but if I try to explain it, I think that's kinda what I based my vote on.

lol, I mean, I wouldn't call it "wishy washy" exactly — but it does sound like it's based on personal aesthetic taste. To some extent that's a lot of what we have with some of these decisions, so it's reasonable to put some weight on it.
The other factors I would weigh are consistency with the rest of the language and familiarity for new users.
Consistency:

Having "arrow" mean something when you're describing a piece of code to someone — rather than "equals greater than" or "fat arrow", or even "switch symbol" — is important.
I am totally ambivalent between -> and => for our arrow syntax, so we could switch (pun intended) both

Familiarity

rust indeed uses => for the switch equivalent, and -> for return types. I tried to find a discussion where someone described why they were different — I think something about it being necessary for the original parser (but until I can find it, we shouldn't put much weight on the point).
Otherwise, I think C# & JS uses => for their function syntax.

One note re voting:

I think that's kinda what I based my vote on.

The way I think about the voting is that we're each responsible for matching the weight of our vote to the strength of our convictions. So it's not like we all are forced to choose a side and then we add up round numbers — if one person is adamant and two don't care much but slightly contrary, we should go with the one person's choice. That ofc relies on us all reporting the strength of our conviction honestly, and our convictions being well-calibrated — I hope we have that trust of each other (I certainly do)

I've merged the PR firstly because the -> syntax would probably clash with lambda function syntax. There would probably be a way around that (parenthesis or just some kind of precedence rule). Second reason were personal aesthetics, which are pointless to discuss.
Overall, I'm +0.5 on =>.

I'm still +1 on having different arrows (what's our scale again? In my mind it's -2..2, not -1..1).

Assuming we go with both -> and => what would we call these? "Thin arrow" & "Fat arrow"?

I think "Thin arrow" & "Fat arrow" are good names!
+1

Second reason were personal aesthetics, which are pointless to discuss.

I think personal aesthetics are important and are ok to discuss. Where the danger lies, and why often it's a good idea to avoid them, is when I try to convince you that my aesthetics are better than yours. Another danger would be to argue for something with technical reasons when it's really motivated by personal aesthetics and that's being hidden. I think that goes with @max-sixty 's point about trust.
I tried to be very transparent in my description to differentiate where I saw technical merits and what I were aesthetical motivations for that reason. In a way I tried to make it easy to shoot down my arguments because I know in technical communities like ours there's not always a lot of weight placed on aesthetics.

Just on aesthetics, I think they are very important. It's hard to draw a line between ergonomics (which are perhaps a bit more technical) and aesthetics (which are probably more personal). However I believe that ergonomics and aesthetics can be a big factor in whether a language becomes popular or not.
I first used Python in 2000 and seriously in 2005 (I think it was 2.3 or 2.4 back then). There was no Pandas, no Numpy (I think the precursor Numeric was around) and Python was largely seen as a scripting language. The main competitors were Perl, Bash and Ruby.
Perl was arguably more ergonomic and you could write very terse things. However I believe Python largely won out, due to some of the following (IMHO):

Perl was a write-only language (good luck trying to decipher those concise hieroglyphics a few weeks later)
Python was fun to write and readable
People worked to bring things like Numpy and Pandas to the language because they enjoyed working in the language and wanted to do more with it.

I don't know what a good way is to bring good aesthetics to a language without ending up in endless bike shedding/yak shaving discussions. Perhaps there can be easy wins though if we all share our personal aesthetic preferences and where they agree then that's probably a good indication that we're onto something good. If there is large disagreement then we just need to take care that we stop any discussions before they get too protracted.

I think personal aesthetics are important and are ok to discuss. Where the danger lies, and why often it's a good idea to avoid them, is when I try to convince you that my aesthetics are better than yours. Another danger would be to argue for something with technical reasons when it's really motivated by personal aesthetics and that's being hidden. I think that goes with @max-sixty 's point about trust.
I tried to be very transparent in my description to differentiate where I saw technical merits and what I were aesthetical motivations for that reason. In a way I tried to make it easy to shoot down my arguments because I know in technical communities like ours there's not always a lot of weight placed on aesthetics.

Just to respond to this since it's small at the object level but I think bigger at the meta level:
I totally agree, and I very much trust your intentions. I hope my message on how I think we should do voting came across as intended — as an attempt to set some principles.

So I guess we're down to two options:

-> for functions, => for switch/match
=> for both functions and switch/match

@aljazerzen the balance may lie with you!

I was split between the two options, but in the end I think we should go with "-> for functions, => for switch/match".
I say that because the only downside of more syntax complexity is a negated by the fact that functions will mostly be used by advanced users who won't mind.

It is decided...

Some more examples that I've fund recently which I believe support the decision that has been reached.
Similar conventions in other languages
Rust
-> : functions
=> : match
Elixir
-> : functions
=> : key-value pairs (dictionaries)

Julia
-> : functions
=> : key-value pairs (dictionaries)

@max-sixty @aljazerzen @snth In the recent Dev Call, I asked about the potential change to the switch / case / match statement syntax/semantics and was met with a collective "gulp!" and a request to discuss it in the next Dev Call.
I have reviewed the discussion in https://github.com/PRQL/prql/issues/1286. I have also used the current implementation and think that it's fine allowing arbitrary expressions to the left of the "->" or "=>" (except for the long line problem.)
Are there any substantive issues with syntax/semantics beyond what I read as a mild preference for "fat arrow" (=>) over "skinny arrow" (->) ? Thanks for indulging a newcomer...

Collective gulp was there because we didn't want to reopen a discussion that was just closed on something that is decided mostly personal visual preference.
Best case for having fat arrows is this comment, but as with most syntactic decisions, this a subject of personal preference.

Oh. I definitely did not intend to re-open a "decided issue." Is this closed, with a plan to use the current switch syntax? I will note:

That would completely satisfy my current use case.
Should we remove the "Experimental" note from the Book?

Thanks, and sorry...

I hope i didn't come across as too dismissive! I'm saying that the matter is very dependent on personal preference and there is no objective "best solution", so these discussions can go on a very long time.
And I don't know why this is still open - the new syntax has been implemented in #1581, which means it should have been released in 0.5. @max-sixty have we forgot to re-apply a revert?
And yes, we can remove experimental note now, unless #1795 yields to any more changes.

You were absolutely not dismissive. I'm just trying to understand the decision...
I will note that it still appears that the switch statement currently uses ->. For example, this works in the 0.5.2 playground:
from foo
select [
  c = switch [
  a < b -> 1,
  a >= b -> 2,
 ]
]

@max-sixty have we forgot to re-apply a revert?

Erm, yes.
I'm happy to do that now — part of the case for reverts is that we can re-revert quickly..
I'm also happy to resolve https://github.com/PRQL/prql/issues/1795 first.
I don't think we should remove experimental until #1795 is resolved

Can you match an integer between 3 and 8?
Can you match a letter between a and f?
Can you match character between 0–9 and a to f?

Can you match an integer between 3 and 8? Can you match a letter between a and f? Can you match character between 0–9 and a to f?

Any expression! Because it's a case rather than a match, it's just running a normal expression for each arm:
from employees
derive foo = case {
  (size | in 2..10) => x,
}

I think this is in a good place now, so closing


coldstart demo

I reran the coldstart demo and found that the hrnn-coldstart precision@5 has gone up to 0.092 from 0.040. The baseline has also gone up to 0.0076 from 0.0044. I can understand that there is a shuffle on the item-ids, which causes the baseline changes. But I was wondering if it would cause this amount of variance in the trained model, too.
Related, the demo notebook created fake_user. I wonder if that is actually necessary.
Attaching a script with the new results:
personalize_coldstart_demo.ipynb.zip
Thanks.

@muralibalki


refactor: modernize loops in hdrgen.d

also use type inference heavily to ease transition to const correctness

Auto-merge toggled on


Add option to Export GeoJSON without altitude

When currently exporting a route as GeoJSON, the coordinates are stored with altitude: [lon, lat, alt]
It would be useful for use cases where the altitude information is not needed to have an option to export GeoJSON without altitude information: [lon, lat]

Great! Thanks @TheGreatRefrigerator


[Bug]: Cannot start GPT cache server with docker

Current Behavior
When
$ docker run -p 8000:8000 -it zilliz/gptcache:latest

I got
Downloading model.onnx: 100%|██████████████████████████████████████████████████████| 46.9M/46.9M [00:08<00:00, 5.85MB/s]
Traceback (most recent call last):
  File "/usr/local/bin/gptcache_server", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.8/site-packages/gptcache_server/server.py", line 181, in main
    init_similar_cache(args.cache_dir)
  File "/usr/local/lib/python3.8/site-packages/gptcache/adapter/api.py", line 174, in init_similar_cache
    embedding = Onnx()
  File "/usr/local/lib/python3.8/site-packages/gptcache/embedding/__init__.py", line 52, in Onnx
    return onnx.Onnx(model)
  File "/usr/local/lib/python3.8/site-packages/gptcache/embedding/onnx.py", line 37, in __init__
    self.ort_session = onnxruntime.InferenceSession(onnx_model_path)
  File "/usr/local/lib/python3.8/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py", line 432, in __init__
    raise e
  File "/usr/local/lib/python3.8/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py", line 419, in __init__
    self._create_inference_session(providers, provider_options, disabled_optimizers)
  File "/usr/local/lib/python3.8/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py", line 451, in _create_inference_session
    raise ValueError(
ValueError: This ORT build has ['AzureExecutionProvider', 'CPUExecutionProvider'] enabled. Since ORT 1.9, you are required to explicitly set the providers parameter when instantiating InferenceSession. For example, onnxruntime.InferenceSession(..., providers=['AzureExecutionProvider', 'CPUExecutionProvider'], ...)

Should it be a issue should fixed by push new image?
Expected Behavior
No response
Steps To Reproduce
No response
Environment
Windows, Docker: Linux container

Anything else?
No response

@julie1234567890 i will release a new version today

Same problem for me.

Hey Folks - was this issue resolved? I am still getting the same error message:
Traceback (most recent call last):
gptcache  |   File "/usr/local/bin/gptcache_server", line 8, in
gptcache  |     sys.exit(main())
gptcache  |   File "/usr/local/lib/python3.8/site-packages/gptcache_server/server.py", line 181, in main
gptcache  |     init_similar_cache(args.cache_dir)
gptcache  |   File "/usr/local/lib/python3.8/site-packages/gptcache/adapter/api.py", line 174, in init_similar_cache
gptcache  |     embedding = Onnx()
gptcache  |   File "/usr/local/lib/python3.8/site-packages/gptcache/embedding/init.py", line 52, in Onnx
gptcache  |     return onnx.Onnx(model)
gptcache  |   File "/usr/local/lib/python3.8/site-packages/gptcache/embedding/onnx.py", line 37, in init
gptcache  |     self.ort_session = onnxruntime.InferenceSession(onnx_model_path)
gptcache  |   File "/usr/local/lib/python3.8/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py", line 432, in init
gptcache  |     raise e
gptcache  |   File "/usr/local/lib/python3.8/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py", line 419, in init
gptcache  |     self._create_inference_session(providers, provider_options, disabled_optimizers)
gptcache  |   File "/usr/local/lib/python3.8/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py", line 451, in _create_inference_session
gptcache  |     raise ValueError(
gptcache  | ValueError: This ORT build has ['AzureExecutionProvider', 'CPUExecutionProvider'] enabled. Since ORT 1.9, you are required to explicitly set the providers parameter when instantiating InferenceSession. For example, onnxruntime.InferenceSession(..., providers=['AzureExecutionProvider', 'CPUExecutionProvider'], ...)
gptcache exited with code 1
Using zilliz/gptcache:latest

@rsharath you can try to update the latest image, which is v0.1.42.


treewide: attempt at markdown option docs

Description of changes
just an attempt at getting option descriptions to markdown (cf #175586).
the conversion is obviously not faithful (since representing the difference between <filename> and <literal> isn't easy to represent in markdown, let alone very useful?), but minimizing the diff between the current options.xml and the one after md conversions is an explicit goal. once all descriptions have been converted we can drop mdDoc again in a mechanical patch.
cc @roberth
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

This fits all the requirements expressed in #175586 at this point, with the exception of @edolstra's dislike of mdDoc, although that was in conjunction with pandoc.
I suppose another potential complaint is that we're using a markdown processor, mistune, that isn't the one used for the rest of the manual, and isn't the one used in the Nix (package) manual either. It is "compatible with sane CommonMark rules."
We may want to review the plugins but otherwise it seems we're good.
If someone can find a good reason to switch to a different markdown processor, they are free to do so during or after this PR, but that should not block migration progress.
The implementation looks ok so far. Will give this a try later.
Looks like we can finally complete the markdown migration! :tada:

the difference between <filename> and <literal> isn't easy to represent in markdown

tl;dr not a problem.
I am not aware of anything that uses this information. The only potential use I can think of is producing links somehow, but it doesn't really hold enough information to produce such links. If we want links, we should just add links.

I suppose another potential complaint is that we're using a markdown processor, mistune, that isn't the one used for the rest of the manual, and isn't the one used in the Nix (package) manual either. It is "compatible with sane CommonMark rules."
We may want to review the plugins but otherwise it seems we're good.

we really only chose mistune because it's a commonmark parser available in python that doesn't enlarge the docs closure by too much. anything else that can parse markdown into an ast would be fine. even shelling out to the favored markdown processor and have it dump an ast wouldn't be a problem, we think.

added literalMD for examples and defaults
fixed link handling and escaping
keep language attrs on programlisting (no option uses this so far)
added lists and emphasis

things we're not sure how to convert:

<option>? probably best to turn them into local links
<replaceable>? would suggest <replaceable>X</replaceable> → «X» since this matches how attrset placeholders are rendered
<note>/<warning>/etc? nixos markdown has admonitions that would be useful here, maybe mistune can be made to support them with plugins/parser rules. haven't checked that yet

admonitions are indeed possible :)

updated description to the current state of the patch set. apart from a few kinds of admonitions the conversion script should be mostly complete (if still very experimental).

does this need more modules converted as examples? :thinking:

[x] converted entries render as usual
[x] non-converted entries render as usual
[x] implementation looks good

does this need more modules converted as examples?

I don't think it helps with review and merge. If you're not confident that others can contribute conversion PRs, you could do some more, but leave them for a follow-up PR.
Some documentation will be helpful:

[ ] Nixpkgs Contributing to this documentation/Syntax

this already explains the existing markdown syntax used in manuals. Is it complete for the purpose of options? Any differences?

[ ] NixOS Writing Documentation

reference the Nixpkgs manual?

[ ] NixOS Contributing to this manual

would be nice to have some links to the other sections

When those are done and it's ready for other to start contributing, I think we're ready for a merge.

we've added some documentation to the nixos and nixpkgs manuals clarifying which extensions are available in options docs. not entirely sure which sections to link for the final nixos manual chapter though :confused:

which sections to link for the final nixos manual chapter though

I was also thinking about documenting the transition process, but it's perhaps better to write an issue for that, similar to the other tracking issues we have, like https://github.com/NixOS/nixpkgs/issues/24288.

I've tried it and it worked well.
My only findings: if you get invalid xml errors in "intermediate.xml", you've forgot mdDoc.

I've tried it and it worked well.

:champagne:!

My only findings: if you get invalid xml errors in "intermediate.xml", you've forgot mdDoc.

not sure we can do anything about that, unfortunately. though what we probably could do is print a warning (error?) if a level of options is not exclusive mdDoc or exclusively docbook. not sure how useful that would be in the face of option merging though

if a level of options is not exclusive mdDoc or exclusively docbook

I'm not sure if it's worth the effort. Option merging is quite rare in NixOS, so I wouldn't expect much trouble from false positives if the error message mentions the possibility. I think it's ok to mention the "bad" error message in the tracking issue. It's a temporary state of affairs anyway, during the transition.

invalid xml errors are probably most often caused by <⋯> links, those are easy to spot. the rest of the MD syntax should usually be valid xml, but hopefully we'll catch that in review. and as you say, temporart state—worst case, it's slightly less sightly until we complete the migration. (which hopefully happens before 22.11!)

For reasons unknown (to me), I'm getting this:
error: builder for '/nix/store/ajymzc86n3gqanmcj2kiwqra49r825g5-lazy-options.json.drv' failed with exit code 1;                                                                                last 10 log lines:                                                                                >
       >           252|         type = nullOr str;
       >           253|         description = mdDoc ''
       >              |         ^
       >           254|           Address to listen on. Listen on `<IP_ADDRESS>`/`::`
       > Cacheable portion of option doc build failed.
       > Usually this means that an option attribute that ends up in documentation (eg `default` or `description`) depends on the restricted module arguments `config` or `pkgs`.

If I drop all the mdDoc references from nixos/modules/services/networking/mosquitto.nix, I can use nixos-rebuild again.

are you backporting newer modules to older revisions? does it work with documentation.nixos.options.splitBuild = false?

@pennae, found some improvements #179351
(not related to the previous two messages)

are you backporting newer modules to older revisions?

This is admittedly with a custom nixpkgs, but it's building the latest unstable. The problem starting showing about a week ago.

does it work with documentation.nixos.options.splitBuild = false?

I'll try to create the smallest possible example that reproduces it and let you guys know. In the meantime I'm just patching out mdDoc.


question about docker images

I've found out that using latest tag on docker image doesn't update app
roflcoopter/viseron:latest
On docker hub  i can't see avalaible image with latest tag
what's the proper way of updating docker image and which version is considered latest kinda "stable"?

latest tag corresponds to the latest stable release.
There has not been one in quite some time, but there is a beta going on right now for v3, which is currently 3.0.0b10

Ok, thank you, I'll try newer version


Correct spelling errors in annotations in locks.go

Signed-off-by: fate-grand-order<EMAIL_ADDRESS>

LGTM


Add support for saving parts of a response for use with subsequent requests

With the http driver, it would be nice to save parts of a response for use with subsequent requests.  This would enable generating and using an auth token, reference values, principle identifiers, etc.  It needs to be available for both single and multi-threaded execution.

Superseded by #938


Tap to edit path

Hi, is it possible to make a change so we can tap to edit this path, and maybe copy and paste a path into this current button in the red rectangle? Just like you do in the path location on windows file explorer.
English is not my first language, but I'm hoping some of what i wrote made sense. If not, just tag me and i will try to explain better.
I built from kptsky_experimenting on my pc.

@kapitainsky I was browsing and searching and editing and found that file_dialog.cpp and file_dialog.h exists, but not file_dialog.ui
If I had that, i might be able to edit the rest myself in QT Creator. Does that sound correct or am i wrong?

These files are used to overwrite methods from standard File Dialog hence dialog.ui does not exist in my code.

On 21 Nov 2020, at 22:04, jobwan<EMAIL_ADDRESS>wrote:
@kapitainsky https://github.com/kapitainsky I was browsing and searching and editing and found that file_dialog.cpp and file_dialog.h exists, but not file_dialog.ui
If I had that, i might be able to edit the rest myself in QT Creator. Does that sound correct or am i wrong?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/kapitainsky/RcloneBrowser/issues/148#issuecomment-731643461, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADXJHOW7UWKL3VLB74EW7B3SRA2P5ANCNFSM4T5L5DIA.

Also it is rather dirty attempt to solve limitations of standard Qt File Dialogue - I am experimenting with other approach now. The biggest challenge is that I try to make it work in consistent fashion across macOS, Linux and Windows.

Also it is rather dirty attempt to solve limitations of standard Qt File Dialogue - I am experimenting with other approach now. The biggest challenge is that I try to make it work in consistent fashion across macOS, Linux and Windows.

I understand. Will continue using your beta test and wait for the other approach then. 😃


Remove undocumented CFN input parameters

Tenancy was not exposed to the users in the configuration file nor documented:

https://github.com/aws/aws-parallelcluster/issues/105 Document tenancy option

you shouldn't use dedicated instances for performance reasons.

CustomChefRunList  was not exposed to the users in the configuration file nor documented:

https://github.com/aws/aws-parallelcluster/pull/125 Add missing parameters to cfnconfig
https://github.com/aws/aws-parallelcluster/issues/147 CUDA not installed at startup on Ubuntu 16.04

ComputeWaitConditionCount was always set to DesiredSize at creation time and not set in the update, so it was the default value or the previous one:

https://github.com/aws/aws-parallelcluster/issues/100 CfnCluster generated CloudFormation template

These two values must be the same during a StackCreate call and afterwards may be different depending on the UpdateStack call.

https://github.com/aws/aws-parallelcluster/issues/202 post_install timeout

Any reason this hasn’t been merged in?


A blog about UP-DETR

Hi authors,
This is not about an issue :smile:
UP-DETR is great! I just wrote a blog about it, see here:
https://medium.com/analytics-vidhya/up-detr-unsupervised-pre-training-for-object-detection-with-transformers-paper-explained-84611e27a144
You could consider to put its link in your ReadMe, so that readers could understand it even easier :smile:
Thanks!
Best regards

Hi @HaoWei-TomTom, thanks for your blog. But I tried everything but only read a small part.

is there any way I can read your entire blog?
Thank you in advance.

@ducvuuit  I see you are using proxy, so I suppose that you are located in China. I am not sure about proxy. If you have a vpn, you might be able to read the entire blog.

Sorry for the delayed response. Thanks a lot for your blog. There is also a Chinese version in 知乎.

Nice, I just added my blog to 知乎
https://www.zhihu.com/question/432321109/answer/2125582248

Hi, I was going through this paper, and was not able to understand a thing.
How do you select the patches that you will be using for the decoder while evaluation? Is it something similar to a region proposal network or something else?

Oh okay, I figured out that we are just using the DETR for fine tuning and hence evaluation. It all makes sense.


ENH: Adds datetime arithmetic with timedeltas

I wanted to be able to add timedeltas to interactive symbols so I made it so.
In [5]: ds.quandl.vix.knowledge_date
Out[5]:
   knowledge_date
0      1990-01-02
1      1990-01-03
2      1990-01-04
3      1990-01-05
4      1990-01-08
5      1990-01-09
6      1990-01-10
7      1990-01-11
8      1990-01-12
9      1990-01-15
...

In [6]: ds.quandl.vix.knowledge_date + datetime.timedelta(days=1)
Out[6]:
   knowledge_date
0      1990-01-03
1      1990-01-04
2      1990-01-05
3      1990-01-06
4      1990-01-09
5      1990-01-10
6      1990-01-11
7      1990-01-12
8      1990-01-13
9      1990-01-16
...

datashape already supported this I just needed to add a _(r)?add and _(r)?sub to isdatelike

Whoa.  Cool.

ah looks like a dask failure

@llllllllll doesn't seem related to your change

@llllllllll what backend are you using there?

blaze client serving a dictionary of alchemy metadata objects.

@llllllllll pull down master and push again, i just fixed the dask failure. it should take care of the failures we're seeing on travis here

Can you add a test for this? You can write it against postgres if you want. I have an instance running locally that I can test against and Travis-CI does as well.

I could do pg and pandas, I imagine this will be common on dataframes, series, and datetimeindidcies.
What is the connection string to use for pg?

'postgresql://postgres@localhost/test::table'
table can be whatever you want

gimme a sec and i'll add a pg db to travis

I imagine I will need to manage the creation of the table and data inside the test?

yeah, but pytest fixtures make that easy enough. if you have any questions about that i'm happy to help. odo also has an example here: https://github.com/ContinuumIO/odo/blob/master/odo/backends/tests/test_postgres.py#L35-L48

@cpcloud I rebased against  #1116 so your commits are pulled in here (under your name)

Excellent. I'll close the other PR then

@llllllllll tiny comment, which isn't critical to address, was just a thought. i hand tested this on redshift and works nicely. merging at some point today.

postgres looks like it has a lot of operations available for date arithmetic http://www.postgresql.org/docs/9.4/static/functions-datetime.html
might be nice to eventually implement some of these :)

I also added a test for numpy; however it only supports the np.timedelta64 objects instead of datetime.timedelta

PR on the way to skip numba optimizing when given a datetime / timedelta expression

Why, does numba not know how to handle these operations?

https://github.com/quantopian/blaze/pull/2

@llllllllll yeah it's not fully implemented in numba yet see here https://github.com/numba/numba/issues/1202

Is there a reason that the pr is against the quantopian fork, not the upstream?

yeah, because i wanted to use your test

kk

Rebased and fixed merge conflict

Looks like numba failed in the numpy test.

it looks like you might've rebased away my commits that fixed that issue

Were they on this branch or on master? I now remember that you had a fix for this

i submitted a PR to your fork

let me see if i have the branch lying around

it'd be in your reflog if you haven't run git gc since the rebase as well

I just cherry-picked them over

cool

sorry about that

no problem!

@llllllllll ok to merge on passing?

yup


Does COGs support batched inference?

How do we figure out scaling requests using a COG? As I understand it, since the models use a GPU and only one process can use a GPU, how do we scale for 100s of requests / second?
Is there anyway COGs supports for batched inference?

There's no built in support for batching yet, though there's an open issue for it: #612. Batching would help with with throughput in some cases, though beyond a certain point you'll need more instances to be able to scale further.
For Replicate we scale by running multiple instances of the Cog model to handle concurrent requests, using the built in queue worker (though we're in the middle of re-architecting that worker in #870).

Can you provide details or point to specific documentation detailing the built-in queue worker?
The README.md says: "automatic worker queues" while the HTTP doc says: "that while this allows clients to create predictions 'asynchronously,' Cog can only run one prediction at a time, and it is currently the caller's responsibility to make sure that earlier predictions are complete before new ones are created."
I'm confused

cc @technillogue @joehoover @daanelson

Hi, can we get a comment on this? I am also confused by contradictory information found in the repo:
From the README:

🥞 Automatic queue worker. Long-running deep learning models or batch processing is best architected with a queue. Cog models do this out of the box. Redis is currently supported, with more in the pipeline.

From docs/redis.md:

Note: The redis queue API is no longer supported and has been removed from Cog.

From my own testing running Cog standalone, given two concurrent requests, the second one will be queued and execute after the first.
However this again is in contradiction to the advice in the README.
So please confirm, is there a built-in in-memory queue out-of-the-box with Cog? If so, what are the limits of this queue, and if not, please explain how my two concurrent requests apparently execute in sequence.
Thank you

Hi, any comment here @zeke @technillogue @daanelson ?

Also interested. I'd like to clearly understand what's happening under the hood when 2 requests are sent to Cog.
The current documentation is a bit unclear, and I'd also like to know if there is an endpoint to know how many predictions are currently "queued" and what are the limit of this queue.
Thanks a lot, appreciate it

hi I've been testing Cog server and stress testing it on my machine. I see that all request are blocking and even when I use the put method with async headers it processes in the background sequentially as well. I'm trying to figure out how to do batching and although the front page of the readme says you support batching in the Q worker I don't see any documentation for it.

this is a supported feature on the front page of the github but i dont see any info in the docs or by looking at the code itself

🥞 Automatic queue worker. Long-running deep learning models or batch processing is best architected with a queue. Cog models do this out of the box. Redis is currently supported, with more in the pipeline.

Just an FYI to the team: the lack of support as demonstrated in this ticket (including a parallel open support ticket) has made us reconsider using Cog in our operation.


Add dtests for compatibility flag introduced in CASSANDRA-13004

I went ahead and just pushed some suggested changes. These tests look correct. Assuming the bug doesn't break our existing upgrade tests (and thus those also need updated), +1. Please squash on merge if you are okay with my commit.

Thank you @ptnapoleon!


In-memory SQL LIMIT

When a query contains a LIMIT clause and optionally an OFFSET but no ORDER BY then Riak TS no longer creates a temporary table.
It now collects the results as it would for a normal query and then uses the OFFSET and LIMIT if provided to take a slice of the query results. For queries containing LIMIT but not ORDER BY, latency is reduced from 30x to 50x to 10%. The increase is measured from a query not containing a LIMIT clause.
Performance tests with eleveldb LIMIT:

Performance tests with in-memory LIMIT:

This does not affect queries that have ORDER BY and LIMIT clauses.
The function head riak_kv_qry_worker:estimate_query_size/1 which checks for a LIMIT has been removed. This has an existing bug where it is multiplying LIMIT by the chunk size, meaning that the estimated result size would be much larger than what it would otherwise calculate and making it more likely to cancel the query.

There is a more comprehensive solution in https://github.com/basho/riak_kv/pull/1587, which also supports ORDER BY and will work with arbitrary ranges.
That said, I am going to +1 this PR on the assumption that we will find ways before 1.6 release to (1) efficiently stop the workers after the required LIMIT records have been collected, and (2) drop records before we reach OFFSET.
One big merit I see going for this simple implementation is that it will go really well in conjunction with descending keys, in situations where the ingest rate is stable and constant (LIMIT records are guaranteed to be found in a range that is small enough to fit in memory), and the prevailing queries are LAST-like,

+1

I'd be a bit nervous about adding this if we weren't guaranteed to add some overload protections (apparently in Andrei's pending changes) before the next release. Should we delay merging until we're sure that will be incorporated?

@macintux The overload protection remains there -- it's just not taking into account the LIMIT value. The projected query result size is still checked against the configured limit (in the other head of estimate_query_size). The upshot is that we will be conservatively cancelling queries based on the entire WHERE range even where LIMIT is small and manageable -- but again, this is fine because in this implementation, the entire WHERE range will have to be kept in memory.

Closing cus.


Exomiser tutorial

added docker installation guide + details for prerequisites

Can you add to the table of contents:
https://github.com/OBOAcademy/obook/blob/master/mkdocs.yml
? Awesome work!

Yes, forgot to do it before but will do it now!


[BUG] Spark 3.1 log arithmetic functions fail

Describe the bug
FAILED integration_tests/src/main/python/arithmetic_ops_test.py::test_log[Double][APPROXIMATE_FLOAT]
FAILED integration_tests/src/main/python/arithmetic_ops_test.py::test_log1p[Double][APPROXIMATE_FLOAT]
FAILED integration_tests/src/main/python/arithmetic_ops_test.py::test_log2[Double][APPROXIMATE_FLOAT]
FAILED integration_tests/src/main/python/arithmetic_ops_test.py::test_log10[Double][APPROXIMATE_FLOAT]clear and concise description of what the bug is.
It looks like a bug in spark 3.1 filed https://issues.apache.org/jira/browse/SPARK-32640
Steps/Code to reproduce bug
run integration tests against spark 3.1
Expected behavior
A clear and concise description of what you expected to happen.
Environment details (please complete the following information)

Environment location: [Standalone, YARN, Kubernetes, Cloud(specify cloud provider)]
Spark configuration settings related to the issue

Additional context
Add any other context about the problem here.

bug https://issues.apache.org/jira/browse/SPARK-32640 was fixed, need to retest

this is already fixed and xfail removed under https://github.com/NVIDIA/spark-rapids/commit/d8aa42eaffe4661a7722915e0777433f84d598ed#diff-e37cdd16e5b60d7ba456f82f3d270571cac52d3b5a4b72455b198fca7e2c02f6


Check chrome version suggestion

Im using chrome 94 which doesn't support EyeDropper (EyeDropper is not defined)
Page doesn't work and everything is broken, might be nice to either check the chrome version, disable EyeDropper or possibly a pollyfill?

Same here, with an up-to-date Chrome (Version 106.0.5249.112 (Build officiel) (64 bits))
You should consider to rename your issue title, by something like "remove EyeDropper to support chrome browser", because it's not supported anymore for many recents versions of chrome.
It's sad, that a (marvelous) tool like this, is not supported in the major browser ;-(


[1.7.10] Thermodynamic conductors kill framerate when attached to reactor

Framerate drops from 120 (set as max) to 12 when 5 ultimate thermodynamic conductors are connected to a fusion reactor, framerate steadily gets better the more the conductors reach the temperature of the reactor.
Maybe slow down operations per second for high-temp thermal transfers?
[edit] this reactor runs at 19GK, in case that is a needed piece of information

Fixed in 1.11

Minecraft version 1.11 or something i dont know about?

@system86 yes, Aidan is focusing on MC 1.11 now.


How do I install on embedded platforms

When I run tools/scripts/start_system.sh on the embedded platform, the following error is displayed
The File "/ usr/lib/python3.8 multiprocessing/process. Py", line 315, in _bootstrap
self.run()
The File "/ usr/lib/python3.8 multiprocessing/process. Py", line 108, in the run
self._target(*self._args, **self._kwargs)
File "web_backend/server.py", line 17, in perception_main
from module.perception import Perception
File "/root/lidar-slam-detection/module/perception.py", line 8, in
import calibration.calibration
File "/root/lidar-slam-detection/calibration/calibration.py", line 4, in
from sensor_driver.common_lib.cpp_utils import (
File "/root/lidar-slam-detection/sensor_driver/common_lib/cpp_utils.py", line 1, in
import cpp_utils_ext
ModuleNotFoundError: No module named 'cpp_utils_ext'
Traceback (most recent call last):
File "web_backend/server.py", line 36, in
from perception_server import PerceptionServer
File "/root/lidar-slam-detection/web_backend/perception_server.py", line 8, in
from message_server import MessageServer
File "/root/lidar-slam-detection/web_backend/message_server.py", line 7, in
from zerocm import ZCM
ImportError: dynamic module does not define module export function (PyInit_zerocm)
Is that something I didn't install

hi,
please use the tools/scripts/install_dependency.sh to install the zcm

Hello, thank you, but there doesn't seem to be a way to do it on an embedded platform yet.
I started to try something new. I installed ubuntu on my computer so that he could use my gpu, but there were still some problems in the running process.
Unlike the non-GPU version, the gpu version does not have any reaction and return value after running, and can only see the page but not operate after opening the website. Why?


BUG - on_thread_create

2023-08-23 13:21:39,040 INFO __main__ requester: {.xarlos#0}
2023-08-23 13:21:39,041 INFO __main__ Command: {{'custom_id': '91b9d44d4e4ef3aff7c3c2366a7ac3df', 'component_type': 2}}
Ignoring exception in on_thread_create
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/discord/client.py", line 378, in _run_event
    await coro(*args, **kwargs)
TypeError: on_thread_create() takes 1 positional argument but 2 were given

Not 100% sure where this one is coming from, but somewhere we log thread creation, and it's tossing an error.

Appears when closing a thread, not when creating it


Change validation messages for D&R conference module and JS

Per request from @schaferjh and @marteki, this slightly changes the form validation messages a user receives.
Changes

Form validation messages for the D&R conference module and the JS

Testing

Run gulp test
Add a conference registration module to a browse page, and submit successfully by adding a valid GD code, and then change the code to something invalid and submit with that to see the other changed message.

Review

@cfpb/cfgov-frontends to check the form validation message change
@cfpb/cfgov-backends to check the rest

Notes

@Scotchester should we also change the Feedback module? Possibly here.

Checklist

[x] Changes are limited to a single goal (no scope creep)
[x] Code can be automatically merged (no conflicts)
[x] Code follows the standards laid out in the front end playbook
[x] Passes all existing automated tests
[x] New functions include new tests
[x] New functions are documented (with a description, list of inputs, and expected output)
[x] Placeholder code is flagged
[x] Visually tested in supported browsers and devices
[x] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

👍

👍

:+1:


Installtion failed (MagicMirror dependencies part)

Platform: Raspbery 3 with raspbian (newest version).
Node Version: Make sure it's version 0.12.13 or later.
MagicMirror Version: Now that the versions have split, tell us if you are using the PHP version (v1) or the newer JavaScript version (v2).
Description: Provide a detailed description about the issue and include specific details to help us understand the problem. Adding screenshots will help describing the problem.
Install Log:
Updating packages ...
Get:1 http://archive.raspberrypi.org/debian buster InRelease [25.2 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:3 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages [13.0 MB]
Get:4 http://archive.raspberrypi.org/debian buster/main armhf Packages [222 kB]
Fetched 13.3 MB in 19s (680 kB/s)
Reading package lists... Done
Installing helper tools ...
Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version (12.6).
curl is already the newest version (7.64.0-4).
git is already the newest version (1:2.20.1-2).
unzip is already the newest version (6.0-23).
wget is already the newest version (1.20.1-1.1).
wget set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 133 not upgraded.
Check current Node installation ...
Node currently installed. Checking version number.
Minimum Node version: v5.1.0
Installed Node version: v10.15.2
No Node.js upgrade necessary.
Check current NPM installation ...
NPM currently installed. Checking version number.
Minimum npm version: V6.0.0
Installed npm version: V5.8.0
npm should be upgraded.
Installing npm ...
Reading package lists... Done
Building dependency tree
Reading state information... Done
npm is already the newest version (5.8.0+ds6-4).
npm set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 133 not upgraded.
npm installation Done!
Cloning MagicMirror ...
Cloning into 'MagicMirror'...
remote: Enumerating objects: 315, done.
remote: Counting objects: 100% (315/315), done.
remote: Compressing objects: 100% (282/282), done.
remote: Total 315 (delta 39), reused 193 (delta 21), pack-reused 0
Receiving objects: 100% (315/315), 655.08 KiB | 899.00 KiB/s, done.
Resolving deltas: 100% (39/39), done.
Cloning MagicMirror Done!
Installing dependencies ...
npm WARN npm npm does not support Node.js v10.15.2
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9.
npm WARN npm You can find the latest version at https://nodejs.org/
npm WARN deprecated<EMAIL_ADDRESS>Deprecated because Grunt is practically unmaintained. Move on to something better. This package will continue to work with Grunt v1, but it will not receive any updates.

><EMAIL_ADDRESS>install /root/MagicMirror/node_modules/electron-chromedriver
> node ./download-chromedriver.js

internal/modules/cjs/loader.js:583
    throw err;
    ^

Error: Cannot find module '/root/MagicMirror/node_modules/electron-chromedriver/download-chromedriver.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
    at Function.Module._load (internal/modules/cjs/loader.js:507:25)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: `node ./download-chromedriver.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!


Layer._display_bounding_box() returns too few dimensions

🐛 Bug
In working on #4849 I had issues because I assumed I would get consistent output from Layer._display_bounding_box(). I would expect a 2d bounding box when passing 2 dimensions, and 3d when passing 3. However, if the layer is a 2D image, I only get 2 dimensions. But I would expect these two layers to behave identically:
Image(np.ones(1, 10, 10))
Image(np.ones(10, 10))

@kevinyamauchi @alisterburt am I wrong about my assumptions here?

Hm, I don't quite see why you would expect the 3D data to give a 2D bounding box unless the image layer drops the dimensionality?

The opposite acually: I would expect to get a 3D bounding box if I ask for 3D:
import napari
import numpy as np

v = napari.Viewer(ndisplay=3)
l1 = v.add_image(np.ones((1, 100, 100)))
l2 = v.add_image(np.ones((100, 100)))

l1._display_bounding_box(l1._dims_displayed)  # get 3 bounds
l2._display_bounding_box(l2._dims_displayed)  # get 2 bounds

l2._display_bounding_box((0, 1, 2))  # get error, but would expect the same as l1, since they *look* the same on the canvas

But I'm not sure I agree with myself here xD

so you currently get a 3D bounding box for 3D data and a 2D one for 2D data?
The _display_* methods slice the nD object (in this case bounding box) by the dims in the same way as the data are (currently) sliced... we know there are lots of problems with the way this slicing occurs, which is what Andys work is on?
You can think of this as the bounds of the data in view :-)

You can think of this as the bounds of the data in view :-)

But that's not relaly true, since the data in view for the two layers above is exactly the same, and yet the bounds look different... It's really the bounds for the data in view, except for the dimensions in which that data has implied thickness of 1 :P
Anyways, this is not urgent, just something interesting I noticed... Definitely will be nice to clean up this.

I see your point but idk, to me it would seem much weirder if the extents of the sliced data had different dimensionality than the data itself 🤷♂
Maybe we could have a system where data is explicitly promoted to have ndim=max(layer.data.ndim for layer in viewer.layers) internally prior to slicing? This would likely resolve lots of weirdness like this

So there I a need to move it outside Layer as layer dhould not need to know viewer state for proper working and creating bounding box base on viewer dimensionality break this.

Agreed @Czaki - I wasn't suggesting literally that we perform this calculation on the layer, rather that the slicing machinery could leave the necessary info somewhere accessible :)

Why would you need info about the layer? You can simply return (0, 0) (translated as appropriate) or something like that for any dimension that's not in the data.

And how many of them? This is determined by other layers.

No, it's determined by the argument of Layer._display_bounding_box, which is dims_displayed. This does not depends on the state of the layer, it simply asks "if you were to be displayed with dimensions 1 and 3, what would be your bounding box?"


Management command for per-user summary stats

We would like to generate a CSV that reports, for each user, some True/False data for each source (if connected, if there's data, if data is public). We can use this to discover summary statistics we may want to track more automatically.
Unsure how to get the resulting data from heroku? Maybe it could output to stdout and pipe to file. Or maybe run locally as a management command using read-only access to the database.

I decided this was too complex to make a CSV, and spreadsheet analyses would be tedious. Switched to JSON and a script for number crunching.
Management command added in 22fbf5c
And a script parsing the output for some numbers added in f7bedfa


Manage orders

Open trades via binance api

https://github.com/crypto-trading-solutions/rwi_strategy/tree/issue_2


Fix Building

Building takes too long, it should be pre-built (possibly with Docker, but doesn't necessarily have to be)

This is all automated now and users can simply pull the latest image and run the correct comments (found in the makefile) to now have to build anything themselves


Docker build fails with  error "/bin/sh: 1: ./install-packages.sh: not found"

I'm trying to build ARMNN using the docker build tool but I run into an error as following:
docker build --build-arg SETUP_ARGS="--target-arch=aarch64 --all" --build-arg BUILD_ARGS="--target-arch=aarch64 --all --neon-backend" --tag armnn:aarch64 --file docker/Dockerfile .
[+] Building 24.6s (11/22)                                                                         docker:desktop-linux
 => [internal] load build definition from Dockerfile                                                               0.0s
 => => transferring dockerfile: 2.96kB                                                                             0.0s
 => WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 59)                                    0.0s
 => WARN: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 72)                                    0.0s
 => [internal] load metadata for docker.io/library/ubuntu:20.04                                                    1.9s
 => [auth] library/ubuntu:pull token for registry-1.docker.io                                                      0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 44.65kB                                                                               0.0s
 => [build-production  1/14] FROM docker.io/library/ubuntu:20.04@sha256:8e5c4f0285ecbb4ead070431d29b576a530d3166d  3.0s
 => => resolve docker.io/library/ubuntu:20.04@sha256:8e5c4f0285ecbb4ead070431d29b576a530d3166df73ec44affc1cd27555  0.0s
 => => sha256:8e5c4f0285ecbb4ead070431d29b576a530d3166df73ec44affc1cd27555141b 6.69kB / 6.69kB                     0.0s
 => => sha256:e5a6aeef391a8a9bdaee3de6b28f393837c479d8217324a2340b64e45a81e0ef 424B / 424B                         0.0s
 => => sha256:6013ae1a63c2ee58a8949f03c6366a3ef6a2f386a7db27d86de2de965e9f450b 2.30kB / 2.30kB                     0.0s
 => => sha256:d9802f032d6798e2086607424bfe88cb8ec1d6f116e11cd99592dcaf261e9cd2 27.51MB / 27.51MB                   1.3s
 => => extracting sha256:d9802f032d6798e2086607424bfe88cb8ec1d6f116e11cd99592dcaf261e9cd2                          1.5s
 => [build-production  2/14] RUN apt-get update &&     apt-get install -y --no-install-recommends         ca-cer  17.3s
 => [build-production  3/14] RUN locale-gen en_GB.UTF-8 &&     update-locale LC_ALL=en_GB.UTF-8 LANG=en_GB.UTF-8   1.8s
 => [build-production  4/14] WORKDIR /root                                                                         0.0s
 => [build-production  5/14] COPY ./scripts/install-packages.sh .                                                  0.0s
 => ERROR [build-production  6/14] RUN ./install-packages.sh                                                       0.4s
------
 > [build-production  6/14] RUN ./install-packages.sh:
0.407 /bin/sh: 1: ./install-packages.sh: not found
------

Hiya,
It looks like it's not able to copy in the install-packages.sh script correctly. It might be that you're running it from the wrong folder. Have you tried running the Docker build from the armnn/build-tool directory?

Hello,
I am running it from the armnn/build-tool folder:
C:\Users\ss205\projects\armnn\build-tool> docker build --build-arg SETUP_ARGS="--target-arch=aarch64 --all" --build-arg BUILD_ARGS="--target-arch=aarch64 --all --neon-backend" --tag armnn:aarch64 --file docker/Dockerfile .

Hi,
Sorry for the delayed response, I was out a lot of last week. I think you issue is you are running it from a Windows system. We unfortunately do not support Windows for our builds / build tool.

The Arm NN Build Tool is tested on x86_64 (Intel) and aarch64 (Arm) build hosts for the Ubuntu platform and on arm64 (Apple Silicon). At present, the tool supports targeting Linux devices (Ubuntu 20.04) and macOS (Mac with Apple silicon). In Linux it supports building on x86_64, aarch64 and android64 architectures.

https://github.com/ARM-software/armnn/blob/branches/armnn_24_08/build-tool/README.md


[$250] Ellipsis color shown in wrong color in Expense Report details

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.60-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @shawnborton
Slack conversation (hyperlinked to channel name): ts_external_expensify_bugs
Action Performed:

Go to staging.new.expensify.com
Submit an expense
Open the report to view expense details
Click on the header to view details of expense report
Observe the From field

Expected Result:
The ellipsis here is in a grayish color and using the correct textSupporting color
Actual Result:
The ellipsis here is in a darker color and is not using the correct textSupporting color (grayish).
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Standalone
[ ] Android: HybridApp
[ ] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021857481644879800683
Upwork Job ID:<PHONE_NUMBER>879800683
Last Price Increase: 2024-11-15
Automatic offers:

FitseTLT | Contributor | 104919616

Issue OwnerCurrent Issue Owner: @Pujan92

Proposal
Please re-state the problem that we are trying to solve in this issue.
Ellipsis color shown in wrong color in Expense Report details
What is the root cause of that problem?
We are missing a text color style here
https://github.com/Expensify/App/blob/cd3f30f73a18c29532d6886b4bb3744fd700ab9d/src/components/ParentNavigationSubtitle.tsx#L55
What changes do you think we should make in order to solve the problem?

Add text supporting color
                style={[styles.optionAlternateText, styles.textLabelSupporting]}

What alternative solutions did you explore? (Optional)

How weird!

Seems simple enough to fix!

@Pujan92 please can you review the proposal above?

@FitseTLT's proposal looks good to me.
🎀👀🎀 C+ reviewed

@FitseTLT How is the PR going on?

PR will be ready tomorrow 👍

When the PR is ready, we'll be waiting on Punjan to review.

bump @Pujan92

Tried to find Punjan on Slack - no dice.

BugZero Checklist:

[ ] [Contributor] Classify the bug:

Bug classification

Source of bug:

[ ] 1a. Result of the original design (eg. a case wasn't considered)
[ ] 1b. Mistake during implementation
[ ] 1c. Backend bug
[ ] 1z. Other:

Where bug was reported:

[ ] 2a. Reported on production
[ ] 2b. Reported on staging (deploy blocker)
[ ] 2c. Reported on both staging and production
[ ] 2d. Reported on a PR
[ ] 2z. Other:

Who reported the bug:

[ ] 3a. Expensify user
[ ] 3b. Expensify employee
[ ] 3c. Contributor
[ ] 3d. QA
[ ] 3z. Other:

[ ] [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to comment:

[ ] [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion:

[ ] [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

[ ] [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:

Regression Test Proposal
Precondition:

Test:

Do we agree 👍 or 👎

payment summary
@Pujan92 requires payment through NewDot Manual Requests - please request $250
@FitseTLT requires payment automatic offer (Contributor) - paid $250 via upwork, contract ended.

$250 approved fro @Pujan92


open_manipulator_with_tb3_simulations: 1.1.0-0 in 'melodic/distribution.yaml' [bloom]

Increasing version of package(s) in repository open_manipulator_with_tb3_simulations to 1.1.0-0:

upstream repository: https://github.com/ROBOTIS-GIT/open_manipulator_with_tb3_simulations.git
release repository: https://github.com/ROBOTIS-GIT-release/open_manipulator_with_tb3_simulations-release.git
distro file: melodic/distribution.yaml
bloom version: 0.7.2
previous version for package: null

open_manipulator_with_tb3_gazebo
* added yaw arguments
* added pid gain for gazebo controller
* added params
* added gripper sub publisher
* added model_5
* updated for sync with new open_manipulator packages #2 <https://github.com/ROBOTIS-GIT/open_manipulator_with_tb3_simulations/issues/2>
* updated pid gain
* changed init position
* changed ar_marker model
* Contributors: Darby Lim, Pyo

open_manipulator_with_tb3_simulations
* added yaw arguments
* added pid gain for gazebo controller
* added params
* added gripper sub publisher
* added model_5
* updated for sync with new open_manipulator packages #2 <https://github.com/ROBOTIS-GIT/open_manipulator_with_tb3_simulations/issues/2>
* updated pid gain
* changed init position
* changed ar_marker model
* Contributors: Darby Lim, Pyo

Now that I've merged some other stuff, this needs a rebase.  Sorry about that!


fix(autobump): Create PR only if bump is required

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

v1.1.0
GitHub release

Your semantic-release bot :package::rocket:


Missing support for multiple EventHubs in 1.1.0.RC5 (#508)

Missing support for multiple EventHubs in 1.1.0.RC5
I tried to backport to 1.1.0.RC5 the fix that was applied to #508 by excluding the EventHubBinderConfiguration (via @SpringBootApplication(exclude=EventHubBinderConfiguration.class) and extending it, to include the following:
@Import({AzureEventHubAutoConfiguration.class, AzureEnvironmentAutoConfiguration.class})

as shown in commit 449a19f.
Here you can find the properties I've tried to use to make it so that the consumer bound to "my-eh2-destination" would consume messages coming from a 2nd EventHub (namely, my-namespace2), different than the default my application uses for other bindings (default-namespace).
spring:
  cloud:
    azure:
      eventhub:
        enabled: true
        namespace: default-namespace
        checkpoint-storage-account: my-storage-account
      credential-file-path: my.azureauth
      resource-group: my-resource-group
      region: West US
    stream:
      default-binder: eventhub
      binders:
        eventhub2:
          type: eventhub
          spring:
            cloud:
              azure:
                eventhub:
                  enabled: true
                  connection-string: 'my-connection-string-2'
                  namespace: my-namespace-2
                  checkpoint-storage-account: my-storage-account
                  checkpoint-access-key: 'my-access-key'
                credential-file-path: my.azureauth
                resource-group: my-resource-group
                region: West US
          environment:
            spring:
              cloud:
                azure:
                  eventhub:
                    enabled: true
                    connection-string: 'my-connection-string-2'
                    namespace: my-namespace-2
                    checkpoint-storage-account: my-storage-account
                    checkpoint-access-key: 'my-access-key'
                  credential-file-path: my.azureauth
                  resource-group: my-resource-group
                  region: West US
      bindings:
        input:
          contentType: application/*+avro
          destination: my-eh2-destination
          group: $Default
          binder: eventhub2

(as you can see I've put a lot of extra properties in the mix, but it didn't help :) )
I've tested my Spring Boot Application with this setup and, even though the application would successfully terminate the bootstrapping process, it still didn't seem to connect to the 2nd EventHub at all (the consumer still consumed messages coming from the first EventHub through my-eh2-destination, even though the binding was linked to the binder that was configured for the 2nd EventHub).
Questions

Is there something else I'm missing to backport #508 into 1.1.0.RC5, that I'm not aware of?
Is there something I'm doing wrong?
Is there an expected date for a release that includes the #508 fix?

Your Environment

Version used: 1.1.0.RC5
Operating System and version (desktop or mobile): Windows 10 Pro 64-bit
SDK version: JDK 8u74

Hi,
Thanks for your feedback.
For q1 and q2: we will try it later, and give you a response.
For q3: according to our release trains, the next release is at Nov.

Hi,
Thanks for your feedback.
For q1 and q2: we will try it later, and give you a response.
For q3: according to our release trains, the next release is at Nov.

Thank you for the useful info.
Waiting for your feedback on q1 and q2.

@dsibilio
For question 1:
I'm not sure whether these changes will work correctly with 1.1.0.RC5. Is it possible for you to share some codes I could check?
For question 2:
There're some extra properties in your configuration as you mentioned, and I modify your version into a workable one.
spring:
  cloud:
    azure:
      eventhub:
        checkpoint-storage-account: my-storage-account
        checkpoint-access-key: my-storage-account-access-key
        connection-string: my-eventhub-namespace-1-connection-string
    stream:
      binders:
        eventhub2:
          type: eventhub
          defaultCandidate: false
          environment:
            spring:
              cloud:
                azure:
                  eventhub:
                    connection-string: 'my-connection-string-2'
                    checkpoint-storage-account: my-storage-account
                    checkpoint-access-key: 'my-access-key'
      bindings:
        input:
          contentType: application/*+avro
          destination: my-eh2-destination
          group: $Default
          binder: eventhub2

As you can see I remove credential file related configurations because connection string is now the only available way as I checked the code.
I remove your default-binder configuration item and add the defaultCandidate: false one.  This configuration indicates that the eventhub2 binder won't be considered as a default binder candidate, which if not set to false, Spring Cloud Stream will use eventhub2 as a default binder.

@saragluna My issue in the first place was that I needed to have more than 10 bindings in my application, since when I asked this question I've actually managed to go around this issue by creating a dedicated EventHub which allows up to 1000 hubs per namespace.
So I don't need to backport the fix and connect to multiple EventHub namespaces anymore.
Thank you for your time, you can close this issue if you want. I trust your solution to work in the upcoming release :)

@dsibilio I'm glad you found a solution. Close this issue.

Could you publish a snapshot build as I would need this feature desperately...
Many thanks,
Oliver

This feature is on master branch so you could try it with our daily built snapshot.

Sorry for asking, but where can I find the artifact to try it out? In Maven Central, I can only see RC5 artifact. Many thanks...

I believe the version number is 1.1.0-SNAPSHOT as described in the pom file on the master branch. You could find the daily built snapshot here https://oss.sonatype.org/content/repositories/snapshots/com/microsoft/azure/spring-cloud-azure-eventhubs-stream-binder/.

Aaah, thanks for that. I added the repo, and now the startup of the App looks promising, connection to two different event hub namespaces was established.
I will give feedback after doing some real world tests.


Avoid duplicating polyfills already maintained elsewhere?

@jdalton raised on https://github.com/Financial-Times/polyfill-service/issues/86#issuecomment-55415462 the issue that we are duplicating work by reimplementing polyfills maintained by others elsewhere, such as the es6shim project.
The reasons this project exists are that things like es6shim:

are not consistently packaged
polyfill not just the thing they are for but all their dependent APIs too, resulting in multiple polyfills on the same page potentially duplicating the polyfilling of lower-level APIs
require developers to know that a polyfill is needed
typically do not offer an easy method of only shipping the polyfill to browsers that lack a native implementation.

However, it makes sense to avoid duplicating work, and we don't want to upset anyone who has the generosity to publish and maintain these polyfills, so I'm open to suggestions for how we could reach our objectives in a way that is more effective for the whole community.

There's now an updated policy on this, see https://github.com/Financial-Times/polyfill-service/pull/338


[fix] Use environment variable for GitHub API

Use GITHUB_API_URL (docs) for the request to the dependency snapshot endpoint so requests work in GitHub Enterprise Server where the API isn't found at api.github.com.
Resolves #312.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for the PR! Rather than passing this in as-is, can we define a custom variable that can be overwritten by the user if needed but has a default value of what we have today? That would ensure we don't break backwards compatibility with the existing users in case there's any issue with this change. WDYT?

Added the ability to override the value. I'm afraid I can't test this in our GitHub Enterprise instance as we're currently only trialling GitHub Advanced Security, and our license has now expired.

@simar7 Anything more you need me to do here?

Anyone?


change package from org.snakeyaml.engine.v2 to it.krzeminski.snakeyaml.engine.kmp

Fix #155
Changed the package from org.snakeyaml.engine.v2 to it.krzeminski.snakeyaml.engine.kmp.
I dropped the v2 part of the package. Specifying v2 doesn't seem relevant.

@aSemy thanks! As it's a breaking change, shall we wait with merging this until we switch to Kotlin 2.0? Then we'd release 3.0.0 with both these changes.

Ah yeah, good idea!
I don't anticipate any minor fixes for our lib, so how about we try Kotlin 2?

merge this PR into main
bump the version to 3.0.0-SNAPSHOT
create another PR to bump Kotlin to 2.0-RC

I'm working on fixing some of the yaml-test-suite failures (I really want to be a 100% compliant parser!), and that includes some ABI changes. We can put those changes into our v3 release too.

Sounds good! I'll review this PR one more time from my laptop, reviewing from phone is hard because the diff loads too long or the browser crashes :smile:


Vulnerability roundup 111: go-1.16.13: 3 advisories [9.1]

search, files

[ ] CVE-2022-23806 CVSSv3=9.1 (nixos-21.11)
[ ] CVE-2022-23772 CVSSv3=7.5 (nixos-21.11)
[ ] CVE-2022-23773 CVSSv3=7.5 (nixos-21.11)

CVE details
CVE-2022-23806
Curve.IsOnCurve in crypto/elliptic in Go before 1.16.14 and 1.17.x before 1.17.7 can incorrectly return true in situations with a big.Int value that is not a valid field element.
CVE-2022-23772
Rat.SetString in math/big in Go before 1.16.14 and 1.17.x before 1.17.7 has an overflow that can lead to Uncontrolled Memory Consumption.
CVE-2022-23773
cmd/go in Go before 1.16.14 and 1.17.x before 1.17.7 can misinterpret branch names that falsely appear to be version tags. This can lead to incorrect access control if an actor is supposed to be able to create branches but not tags.

Scanned versions: nixos-21.11: 2128d0aa28e.
Cc @Frostman
Cc @c00w
Cc @cstrahan
Cc @kalbasit
Cc @mdlayher
Cc @mic92
Cc @orivej
Cc @rvolosatovs
Cc @zowoq

21.11 is EOL.


License Request

Hi can you put an MIT license on it?

Done :D
On Wed, Feb 7, 2024 at 3:18 AM Jubaer Al Meraj @.***>
wrote:

Hi can you put an MIT license on it?
—
Reply to this email directly, view it on GitHub
https://github.com/dbircsak/blog/issues/2, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD57Y3B6SXPJAGJK7FHRMWDYSNPH5AVCNFSM6AAAAABC5UHYRGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZDENZZGEZDMMI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


feat: Support react native bridge

Jira Ticket

ACCSEC-19645

Description

Add properties for SDK version name, version code and bundle name to prevent override by react native module. Update SDK version read

Commit message

feat: Support react native bridge

Testing

[ ] Added unit tests
[ ] Ran unit tests successfully
[ ] Added documentation for public APIs and/or Wiki

Code coverage
Total coverage: 95.38%

File
Coverage

TwilioVerify/TwilioVerify/Sources/Domain/Factor/PushFactory.swift
99.33%

TwilioVerify/TwilioVerify/Sources/Networking/RequestHelper.swift
100.00%

Powered by Slather

  Generated by :no_entry_sign: Danger

Code coverage
Total coverage: 95.38%

File
Coverage

TwilioVerify/TwilioVerify/Sources/Domain/Factor/PushFactory.swift
99.33%

TwilioVerify/TwilioVerify/Sources/Networking/RequestHelper.swift
100.00%

Powered by Slather

  Generated by :no_entry_sign: Danger

Code coverage
Total coverage: 95.38%

File
Coverage

TwilioVerify/TwilioVerify/Sources/Domain/Factor/PushFactory.swift
99.33%

TwilioVerify/TwilioVerify/Sources/Networking/RequestHelper.swift
100.00%

Powered by Slather

  Generated by :no_entry_sign: Danger

Code coverage
Total coverage: 95.38%

File
Coverage

TwilioVerify/TwilioVerify/Sources/Domain/Factor/PushFactory.swift
99.33%

TwilioVerify/TwilioVerify/Sources/Networking/RequestHelper.swift
100.00%

Powered by Slather

  Generated by :no_entry_sign: Danger

@yafuquen Integrations tests in All devices are failing. Is it happening because of this change? Can you please take a look at it?

Passing now, it was a firebase error with one device

@yafuquen Integrations tests in All devices are failing. Is it happening because of this change? Can you please take a look at it?

Passing now, it was a firebase error with one device