Add smartmatch and switch

This PR adds new "smartmatch" operators ~~ and !~, a new String.part getter to use with them, and a switch statement.
Edit Lest this seem overwhelming --- Wren programmers who only want to use switch don't have to know or care about smartmatch.  The switch Just Works :) .
Smartmatch

needle ~~ haystack is called a "smartmatch", and is exactly haystack.~~(needle).  !~ is the logical negation of ~~.
Smartmatch has the same precedence as == and !=.
Each of the built-in classes defines ~~ to connote matching, in a type-specific way (read on for why).

E.g., numbers and strings test for equality and lists test for containment.
Functions are unusual: needle ~~ fn == fn.~~(needle) == fn.call(needle).  This way, you can write arbitrarily complicated test conditions as functions.

You can override ~~ and !~ in your own classes to provide specific matching behaviour.

For example, if we add regexes (#933), a regex match could be concisely written string ~~ regex.
This also provides users a way to extend the language without having to change the syntax.  E.g., a bounding-box class could express collision detection as sprite ~~ bbox.

String.part

Smartmatch on strings is an equality test: "bar" ~~ "bar", but "a" !~ "bar".
To make it easier to match substrings, new String.part returns an instance that will match a partial string.  E.g., "a" ~~ "bar".part ("a" is part of "bar".
String.part returns an instance of new core class SeqMatchIfContains.  This class exists solely to override ~~ to call .contains(needle) on an object it is given.  SeqMatchIfContains is currently only used for Strings, but could be used for any Sequence.

Switch
In the switch statement, the topic variable is smartmatched against each test in turn, from top to bottom.  For example:
var topic = /* whatever */

switch(topic) {
  1: System.print("the topic was == 1")
  "a": System.print("the topic was the string 'a'")
  2..5: System.print("the topic was between 2 and 5")
  [7, 9]: System.print("the topic was either 7 or 9")
  Fn: System.print("the topic was a function!")
  {|v| v%2 == 0}: System.print("the topic was even")   // Accept function literals, just like Fn.new does
  else: {
    System.print("nothing else matched")
    doSomethingElse()
  }
}

This is where smartmatch shines: you can give any value as a switch test, and the semantics will be clear and consistent.  (This also makes it easier to implement parsing of switch statements, since the lower-level expression and statement parsers are unchanged!)
Yet to be done

I have not updated the documentation yet.  If the code receives community approval, I will modify this PR to include documentation.
Edit Performance tests are done --- https://github.com/wren-lang/wren/pull/1009#issuecomment-835410641 I have not tested performance of switch vs. an if/else ladder.
If this PR is merged, I plan to open separate issues for:

adding fallthrough from one case to the next (e.g., https://github.com/wren-lang/wren/issues/956#issuecomment-818693436)
implementing Object.!~(_) in core in terms of instance.~~(_).  Currently, if you override ~~, you also need to override !~.  I'd like it to be possible to override only ~~, and get a correct !~ without writing any extra code.

Relationship to other issues
If accepted, this PR will:

Close #1005
Fix #956
Fix #989

This PR replaces #968 per https://github.com/wren-lang/wren/issues/968#issuecomment-826285746 .
This PR relates to #1002.
Credits

Smartmatch, and the idea of using smartmatch in a switch, come from the Raku programming language
Thanks to @ChayimFriedman2 @clsource @CrazyInfin8 @joshgoebel @mhermier @PureFox48 for productive discussions!

I think we all accept that, if performance is a consideration, then you shouldn't be using a switch statement with fancy cases in a tight loop - you should use an if/else ladder instead.
However, you can't make an omelette without breaking eggs and, unless switch is limited to equality of values (no containment, type or pattern matching) then some changes to class infrastructure are inevitable even though @cxw42 is doing what he can to minimize them.

I don't blame @cxw42 efforts, I think it is unfortunately a consequence of the design. It encourage a style of coding that introduce bad performances when extended.
@cxw42 would it be possible to make the patch set in that order switch (based on equality), smart match, and than modify switch to work with smart match ? It would make the patch set more atomic if one (at least me) want to test the impact/revert the feature of switch with smart match

@cxw42 thanks, there is still a little of noise Add switch statement diff with non necessary change in core.

@mhermier

It would make the patch set more atomic if one (at least me) want to test the impact/revert the feature of switch with smart match

I split smartmatch off of switch at the end rather than redoing the whole patch set.  New cdc3d18 has switch using test == topic, and new f14c03d changes that to test ~~ topic.  I hope this helps!
I leave it to you and @PureFox48 to debate the merits of complex conditionals.  I refer you to @PureFox48 's https://github.com/wren-lang/wren/issues/956#issuecomment-817876958 ;) .

The problem is more that it implies such behavior, eg what if I need a ignore case match, an upper or lower case match or ... each time you create a unique method name, the size of the virtual tables of all future class grow

Thanks for the clarification!  I agree that someone could run into issues that way.  I also am mindful of Donald Knuth's injunction to avoid premature optimization.
I looked at replacing SeqMatchIfContains with a function.  I was not able to while still keeping String.part usable outside a switch.  This is because I want String.part to support !~ as well as ~~.  For cases in a switch, however, a function would be enough.  switch does not need !~ in this PR.  Therefore, I think people writing Wren code would use a function rather than a new class --- a single function is much less typing than a class :) .
Custom classes written by users will not need adapter classes, because those classes will implement ~~(_) directly.

For the methods, I looked and was not able to find the message

Thanks for trying!  Your explanation was a perfect alternative.

I also asked that change, because basically it was doing 2 thing in one patch. switch is based on equality, and smartmatch change the notion of equality of switch to be '~~'. While doing in one go is feasible, It more understandable and maintainable in the git sense (add/revert) that way.

@mhermier Not the specific tests you asked for, but some initial data.  The data do show some slowdown, as you expected.
Since I have String.part in this PR, I compared its performance in a switch against String.contains in an if/then.  I generated wren code like this:
if-then:
for(iter in 1..2000) {
  var topic = "a" // can't possibly match
  if(false) { // so the loop below can be regular
  } else if("1".contains(topic)) {
    Fiber.abort("matched 1")
  } else if("2".contains(topic)) {
    Fiber.abort("matched 2")
...

switch:
for(iter in 1..2000) {
  var topic = "a" // can't possibly match
  switch(topic) {
    "1".part: Fiber.abort("matched 1")
    "2".part: Fiber.abort("matched 2")
    "3".part: Fiber.abort("matched 3")
    "4".part: Fiber.abort("matched 4")
    "5".part: Fiber.abort("matched 5")
...

I ran different numbers of cases in each iteration: 1 13 25 37 50 .  I ran different numbers of iterations:<PHONE_NUMBER> 1525 2000.  The results are show below as the rate of if-then divided by the rate of switch test runs, i.e., the percentage by which if-then is faster than switch (1.1 = if-then is 10% faster than switch).

The minimum is 98% --- switch is actually faster than if-then in my test with one switch case and 100 iterations.  The maximum is 183% --- if-then is 83% faster than switch for 37 switch cases, 1525 iterations.

(Separate post to keep data and opinions separate)

My initial tests show that switch can slow down compared to if-then, as @mhermier predicted.  However, switch still runs more than half as fast as if-then in all cases I tested.
I think the slowest case, a switch with 37 String.part calls in a tight loop of 1525 iterations, is so bizarre that it does not disqualify this PR from consideration!
In the 13-case tests, which I think are more likely to occur in practice, switch still runs 67% as fast as if-then.

I think we should definitely mention this performance consideration in the documentation for switch.  However, I think the likely use cases of switch will not suffer the more significant performance losses in this test set.
I also collected some data on using functions, which I will report soon.

Can you show the testing infrastructure? The Fiber creation/life might have contributed to a general slow down, making the test biased in favor an extra allocation. I may be chasing an ideal scenario, but users might look after a no allocation path for performance.
The oddity at 1 test making switch fast is due to the way your test is laid out. Since the is no optimization in the compiler the "if (false)" results in a test. So to some extend the results for 'if-then' are shifted by one, so the results should be a very small worse for switch with smart match.
Could you also make a test with the switch calling equality and using an adapter like:
class PartTestAdapter {
  construct new(value) {
    _value = value
  }
  ==(rhs) { rhs.contains(_value) }
}

I would like to see the viability as a replacement compared to smart match.

My tests are at https://github.com/cxw42/wren/tree/switch-speed-trials .
@mhermier To test PartTestAdapter, I had to add an equality-based switch.  That gave me an idea: what if we actually added both == and ~~ comparisons, and let programmers choose which they wanted?  In my tests, those are switch for ~~ and switcheq for == .  I suppose they could alternatively be match for ~~ and switch for == .

replacement compared to smart match.

I don't think that the PartTestAdapter idea should be encouraged as a replacement for smartmatch.  It is a technique that can be useful when all the rhs values have the same type.  If different cases have different rhs types, I think the code will become unwieldy.  E.g.:
switch(topic) {
  case "a": ...
  case "b".part: ...
  case [1,2,3]: ...
}

would translate to something like:
class PartTestAdapter {
  construct new(value) {
    _value = value
  }
  ==(rhs) {
    if(rhs is String) {
      return rhs == _value
    } else if(rhs is SeqMatchIfContains) {
      return _value ~~ rhs
    } else if(rhs is Sequence) {
      return rhs.contains(_value)
    } else {
      Fiber.error("I don't know how to handle %(rhs)")
    }
  } // ==(_)
}

switcheq(PartTestAdapter.new(topic)) {
  case "a": ...
  case "b".part: ...
  case [1,2,3]: ...
}

That strikes me as very tedious to maintain and extend!  One of the advantages of smartmatch is that it replaces the typeswitch in the ==(_) with method dispatch.

Today's run: https://github.com/cxw42/wren/tree/switch-time-tests/test/speedtrials/switch/2021-05-12
Results: https://github.com/cxw42/wren/blob/switch-time-tests/test/speedtrials/switch/2021-05-12/summary-2021-05-12-220400.csv (higher numbers are better)

Example result line:
"test/speedtrials/switch/2021-05-12/t0009","Wed May 12 22:11:29 2021","t0009_s00050_i00575_adapter.wren",106.913580246914,"t0009_s00050_i00575_fn.wren",75.5924170616114,"t0009_s00050_i00575_fn_hoisted_test.wren",98.0722891566265,"t0009_s00050_i00575_ifthen.wren",117.910447761194,"t0009_s00050_i00575_switch.wren",69.8296836982969,"t0009_s00050_i00575_switch_hoisted_test.wren",104.950495049505
test group,                                test timestamp,            test name including technique,     count/sec,       test name including technique,count/sec,       test name including technique,             count/sec,       test name including technique,    count/sec,       test name including technique,    count/sec,       test name including technique,                 count/sec

count/sec: higher numbers are faster
I will analyze when I have a chance, but won't be upset if someone beats me to it! :)

I'm worried that we're starting to loose objectivity here and that the merits of this PR are being clouded by too many performance tests. I'd therefore like to make what seems to me to be some obvious points to get us back to some sort of reality.

Although @ChayimFriedman2 may be right that: "the Wren community is not big enough to identify potential problems in time", one thing I do feel sure about is that virtually no-one will want to experiment with using SmartMatchAdapters or PartTestAdapters. If they've any doubts at all about switch, they'll use an if/else ladder instead. It therefore seems to me that it's pointless testing against these concepts, we should stick to testing against an if/else ladder.

When given a choice between using switch and if/else what will our thought processes be? My own will be to ask whether all the branches involve the same variable/expression - if they do I'll prefer to use switch because it's less verbose and easier to read. I certainly don't want to make a further decision between using switch or switcheq so for me that idea is dead in the water. I also don't want to be thinking too much about performance at that stage - as @mhermier said earlier : "users usually trust the devs behind core libraries know what they are doing". If I find there is a performance bottleneck later, I can always change to if/else.

A smart-matching operator is a novel idea taken from a language (Raku) which is nothing like Wren so I can understand why people may dislike it on those grounds alone. Inevitably, its introduction would mean some changes to class infrastructure (which again can be objected to on the grounds of increased pressure on core) and it's perfectly obvious that it's not going to be as fast as if/then and that the fancier features (such as the use of part and function matching) are going to be the slowest of all. Nevertheless, the rationale for having a switch statement in the first place, and the reason why most languages have it in some shape or form, is convenience and so all we really need to know is whether the drawbacks outweigh that convenience. From what I've seen so far, I don't think they do but others clearly disagree and the lack of unity won't make it any easier for @Ruby01 to decide whether or not to merge this PR.

I looked at your testing protocol and indeed you are producing to much data. Everything bellow 2000 iterations is useless (basically you are bench-marking the startup time). Even 2000 may be not high enough to have proper numbers (in particular for small number of cases)?
As this I can already conclude that in this pretty ideal scenario (where garbage collection is fast, because the memory is not used with anything than the benchmark) that it is at around 2 times slower than the if-else ladder when the numbers of cases start to be consequent(>10), and that the adapter is working nearly as good as if-else when the number of entries increase which was what I expected.
What I did not expected is that it performs better than I anticipated, so I wonder if the garbage collector effects I expected are not shown because it performs way better than I expect ?
I don't know own to insert images, but in the view I have (logarithmic number of cases/speed) the difference is quite linear. But I can't completely confirm it, because of the lack of numbers in the low number of cases (<13).
About point 2, for me it is more about trimming than being verbose. The writing implies that the value to be trimmed is at the top of the switch, and the selector follows.
And to answer your concern about point 3, I don't dislike, but I want to know precisely what it will cost us. Because the naive implementation using the operator == is a trivial conversion of the if-else ladder, and that you showed that using it smart-match might involves the allocator, I don't what that implication to become a huge unsolvable bottle-neck.
I'm more concern by the fact that option implies the form of switch would take, and this is more what I don't like with the submission, things go in reverse. Here the solution enforce the grammar, where usually the grammar implies the solution. This is why I think we should take a conservative approach and use switch with equality first to see if it satisfy everyone, and than we can consider smart-match.

This is why I think we should take a conservative approach and use switch with equality first to see if it satisfy everyone, and than we can consider smart-match.

Well, I can see some sense in that if we can't all agree on this PR as it stands. However, one concern I have is that, if we did that, then I think we'd have to cater for fall-through, which personally I'd prefer not to support.
The reason I say that is because there would be no way of grouping values within a case using a List as there is with this PR. Consequently, unless there was at least implicit fall-through, you wouldn't be able to 'stack' empty cases like you can do in C which folks will probably expect to be able to do in Wren also.

Responses
@PureFox48

1 ...  virtually no-one will want to experiment with using SmartMatchAdapters or PartTestAdapters. If they've any doubts at all about switch, they'll use an if/else ladder instead.

Agreed!

2 ... I certainly don't want to make a further decision between using switch or switcheq so for me that idea is dead in the water.

I respectfully disagree.  Just to make it easier to distinguish them, suppose switch is equality and match is smartmatch.  You won't actually have to make a further decision --- you (and I) will always use match and be done with it :) .  And @mhermier and @ChayimFriedman2 will always use switch and be equally happy.

3 ... the rationale for having a switch statement ...  is convenience and so all we really need to know is whether the drawbacks outweigh that convenience. From what I've seen so far, I don't think they do

Agreed!!!
@mhermier

Everything bellow 2000 iterations is useless (basically you are bench-marking the startup time).

Would you please clarify?  In the 5/12 data, I see the speed dropping as the number of switch cases increases.  I also see the speed dropping as the number of iterations increases.  If the benchmark were dominated by the startup time, would that be the case?

it performs better than I anticipated

Wren is a well-designed, well-built language :D .

using it smart-match might involves the allocator, I don't what that implication to become a huge unsolvable bottle-neck.

I believe the data we now have shows it is not an unsolvable bottleneck.  Do you disagree?

Here the solution enforce the grammar, where usually the grammar implies the solution

Would you please expand on this point?  I don't think I understand what you are getting at.  Thanks!
@PureFox48

With equality ... there would be no way of grouping values within a case

You have been advocating for complex conditionals from the beginning, and I agree with you that they are very useful.

Thoughts
@mhermier and @ChayimFriedman2 have good reasons for wanting equality-based switch, and @PureFox48 and I have good reasons for wanting smartmatch-based switch.  Since supporting both only requires ~15 extra lines in wren_compiler.c (ref), and that code is already written :D , I think our best chance to reach agreement is to do both.  I am personally willing to let switch be equality as long as match or some similarly brief keyword is smartmatch-based.
It also occurs to me that "Matching" could be a new top-level page of documentation.  We could cover switch with the other control structures, and ~~ + match in the new section.
What say you?

I say that since we want to keep Wren minimal, we should let @ruby0x1 decide which of those we want (or maybe both, or maybe we don't want a switch at all).

My last post for the day: here's one way of looking at the latest numbers.  If/then is 1.0; higher numbers are faster.

switch is on the bottom in red/yellow colors, with a similar shape to the 2021-05-11 data.
hoisted switch is on the top in blue/green colors.  It performs pretty close to if/then.

The difference is that hoisting does var foo="foo".part before the loop, and then smartmatches against the existing foo in the loop.  Regular switch evaluates the "foo".part each time through the loop.

About the speed concerns of why it goes slower when the iteration grows, I think it shows the effects of memory allocation/fragmentation/garbage collection/cache misses. The faster if goes down the heavier you are pressuring the memory. But to me it is a good metric of a more realistic use case, when your program is expected to behave for long periods.
What I really don't like here is that you have to use hoisting to achieve relatively good performances.
Changing the selector to match can be a solution, even thought I don't like that we will have a duplicated feature in language that would probably ban the introduction of switch if adopted before.

I have an idea, thought I don't know how well it would be received:
switch(foo) { // Regular equality
  ...
}

switch(foo, Fn.new(lhs, rhs) { lhs ~~ rhs }) { // User defined equality
  ...
}

(Though I'm still in favor of my original idea, about providing equality evaluation per case, since I think it follow the KISS principle in some sense)

@cxw42

You have been advocating for complex conditionals from the beginning, and I agree with you that they are very useful.

I have, partly because I've observed the power of pattern matching in other languages at first hand and also because the conclusion of the earlier #352 discussion seemed to be that a switch statement would only be worth doing if it included some elements of pattern matching.
My view has softened slightly in that, after all this discussion and effort (particularly by yourself), I think it would be disappointing if nothing were to come out of it even if that were only an equality based switch. At least there would be the potential to improve it later.

Just to make it easier to distinguish them, suppose switch is equality and match is smartmatch. You won't actually have to make a further decision --- you (and I) will always use match and be done with it :)

That's true but we have to spare a thought for Wren programmers at large who aren't immersed in this discussion - the decision may be less easy for them.
I'd be nervous about having two ways of apparently doing the same thing (albeit the functionality of one would be a small subset of the other) even though the underlying implementation were different.
One idea that's being go around my (otherwise rather empty) head is whether one could distinguish between the two by making one a statement and the other an expression. We do, after all, already have this in the shape of the if/then ladder and the conditional (?:) operator. In fact, I sometimes use the latter to simulate the conciseness of a switch though you have to be careful how you do it to avoid an otherwise unreadable mess.
You'd probably want the more powerful smart-match version to be the statement and the equality based switch to be the expression. That way the latter wouldn't have to worry about fall-through which makes no sense in a switch expression.
But I can't see those who prefer the equality based switch being happy with that as it would severely curtail what could be done in each case (basically you'd be limited to a single expression). Consider for example:
var f = Fn.new {
  var a = 1
  // the following expression is used like a statement
  // with its value being discarded
  (a == 1) ?  System.print("yep") : System.print("nope")
}
f.call()  // >  yep

So it would probably have to be able to serve both as a statement and an expression which muddies the waters yet again!

@mhermier
I'm not keen on that idea which seems to be a more explicit version of your SmartMatchAdapter concept.
I think whatever we do here that the functionality needs to be available straight 'out of the box'.

Yes, but the function could be hoisted, contrary to the other version. But I wanted to talk about it just in case it could get some interest. As of now, all the solutions, other than my original idea seems to be limiting or lacking of functionality in some form. So I'm dealing with to many trades-off and considerations to be fully objective on my new ideas and prefer to tell just in case it can get some traction.

As of now, all the solutions, other than my original idea seems to be limiting or lacking of functionality in some form. So I'm dealing with to many trades-off and considerations to be fully objective on my new ideas and prefer to tell just in case it can get some traction.

I appreciate that you're just trying to come up with a new idea which is always a worthwhile exercise when faced with an apparent impasse whether the immediate reaction is good or bad :)
I'll share an idea of my own which I was saving in case this PR (which I much prefer) doesn't get merged or is replaced by an equality based switch. In fact it builds on the latter in such a way that the whole thing could be easily transformed into an if/else ladder thereby minimizing any performance/memory impact and is not a million miles from what you initially suggested yourself in https://github.com/wren-lang/wren/issues/956#issuecomment-813097515 (et seq).
Firstly, I'd want to resurrect my in proposal (#968), preferably with the addition of !in and !is, which I closed in favor of this one. Even if there were no switch statement at all, I'd still consider this worth doing.
What I'd then suggest would be a switch on these lines (using Option 1 syntax):
switch (e) {
  op expr: ...
  op expr: ...
  ...
  else:    ...
}

where 'op' denotes a boolean binary operator and so could be any one of the following:
< <= > >= 	Comparison
is !is          Type test
in !in          Containment
== !=           Equality

If 'op' were omitted, then "==" would be used i.e. the case would degenerate to an equality based one.
Fallthrough wouldn't be allowed - it would rarely be needed and would be awkward to implement anyway.
So each case would be equivalent to: (else) if (e op expr) within an if/else ladder.
Some examples:
switch (e) {
   1 :          // match a number
   "abc" :      // match a whole string
   in 2..5:     // inside a range
   !in [6, 7]:  // not inside a list
   in "abcde":  // inside a string
   is String:   // type match
   !is Num:     // negative type match
   <= 10:       // numeric comparison
   == 11:       // numeric equality (== optional, usually omitted)
   != "def":    // string non-equality
}

There'd be no support for smart-matching against functions which gives the present PR a lot of its power. However, it still could do quite a lot and is, I feel, reasonably intuitive so it would be a lot better than just a simple equality-based switch.
If option 2 syntax were used, the switch would look like this:
switch (e) {
  case op expr: ...
  case op expr: ...
  ...
  case else:    ... // or perhaps use the familiar `default`
}

The only other difference would be that blocks would be needed for multi-statement cases for Option 1 but not for Option 2 though arguably it might still be better to consider each case as a putative block (as Go does) in the interests of having sensible variable scope.

I appreciate that you're just trying to come up with a new idea which is always a worthwhile exercise

Agreed!!!!

I'd be nervous about having two ways of apparently doing the same thing

@PureFox48 I think that is primarily a documentation issue.  I agree it's cleaner not to have to make the choice, but I would rather explain the choice than remove the choice.  (I should mention that I actually like writing documentation, so this idea does not bother me :D .)

in 2..5:     // inside a range https://github.com/wren-lang/wren/pull/1009#issuecomment-841164557

I think the option-1 based syntax could be a fallback option.  However, I think it will complicate the parser code quite a bit.  The parser, or at least expression(), will need to learn how to accept synthetic tokens, so we can push a reference to the current topic.
Actually, now that I think about it, if case were an expression token that pushed a DUP on the stack, the option-2 based syntax would work with fewer changes --- case would become a stand-in for the topic.  I still think braces should be used for blocks so we don't have to change statement().
So, given that, I still prefer switch+match+~~.  What I described in the previous paragraph would be my second choice
I do note that the modified option 2 would actually be a larger change to Wren than this PR is --- it adds more tokens, more operators, more keywords, and more individual things for people to learn.  The modified option 2 also does not smooth the path for future enhancements in the way that smartmatch does.  It's all about the trade-offs! :)

@PureFox48 it is almost my original plan, the only real problem I have with it is the addition of literal values. If you can find a solution to handle negative numbers (aka unary operators values), I would be satisfied with that solution, and could expand it for my needs.

@mhermier
I don't actually see a problem with negative numbers or the unary minus operator. They would just be part of expr which could be any expression at all.
op would need to be a binary boolean operator and so couldn't be confused with unary minus or with any other unary operator for that matter.
However, if I'm missing something here, then one solution would be for == to be compulsory rather than optional when testing for simple equality, though I think the proposal would lose a little sparkle if that were done.

@cxw42
Mnay thanks for your comments.
Although I still have reservations about having two statements, I'll start by reaffirming my support for this PR which does everything I'd like it to as well has having scope for further expansion.
However, we are where we are and I think we therefore need to explore new ideas (or rehashed old ones) in the hope of at least finding some consensus amongst ourselves.
I hadn't really thought about my proposal favoring option 2 rather than option 1 syntax but I can see the point you're making.
Given that I think we'd need putative blocks for option 2, I'd have no objection to making this explicit by using braces.
I don't know what's best for the default case. I was looking for some way to make it stand out more by using case else rather than just else though traditionalists may prefer to just use the familiar default, even if it means adding a new keyword, and have done with it.
You're right, of course, that the proposal would need more new stuff than this PR. But, if the smart-matching operator were gone, I'd certainly want to go back to an in operator (as a minimum) as I regard that as an essential part of the proposal as well as something useful to have in its own right

Thanks for your kind words!

== Compulsory

It doesn't have to be as long as we don't mind it looking a little strange.
switch (topic) {
  case is Str: ...
  42: ...
}

Since we have one token of lookahead, we can distinguish case from equality and manually emit the DUP/expression ()/callSignature for equality, like this PR does for all test values.

It doesn't have to be as long as we don't mind it looking a little strange.

Couldn't we still do:
switch (topic) {
  case is Str: ...
  case 42: ...
}

Granted it would be more difficult to parse, but I think the extra complication would be worthwhile as it would enable us to reproduce a simple equality based switch.

Yes, as long as there is a fixed set of binary operators that can follow a case, it is doable.  We'd have to either be able to back up the bytecode pointer or emit an extra POP, I think, but both are doable.

Good :)
There would be a fixed set of 10 binary boolean operators available (including == itself)  assuming we implement !in and !is as well as in.

The problem is that:
switch(foo) {
  case -42: // should be evaluated to `foo` - 42 because of an issue/feature in the compiler because
            // It can't be determined to be a literal value and not doing so would have more impact
}

It could be even more problematic trying too match bit patterns ...
And I don't really like the idea of white-listing operators, it create something to remember that may vary across versions.
A stupid idea that doesn't look at the expense of keyword could be:
switch(foo) {
  case -42: // check for equality
  match is Foo: // check for extend binary expression
}

Yes, but it couldn't be evaluated as foo - 42  because - isn't  a binary boolean operator.
It's not so much a matter of white-listing operators but simply allowing all the ones we have.
If a new boolean binary operator were introduced in a future version, then switch would have to be adjusted to cater for it.
Although I'm still not convinced it's  necessary (particularly in the light of https://github.com/wren-lang/wren/pull/1009#issuecomment-841233123), I think it would be preferable to insist on the use of == rather than introduce cases with a mixture of keywords:
switch(foo) {
  case == -42: // check for equality
  case is Foo:  // check for type
}

Incidentally, if we did allow any binary operator (not just boolean ones), then foo - 42 would always match since it would evaluate to true.
So clearly doing that would be a non-starter.

@PureFox48 it is not a binary boolean operator because you said so, who said that in my crazy DSL it does not produce a boolean because I have to ?

Well,  in my simplistic way of looking at things a binary boolean operator is one which produces a Bool, either true or false.
It just so happens in Wren that binary arithmetic or bitwise operators produce a Num which is then regarded as truthy but there's still in a distinction between them and natural boolean operators in my mind at least.
Besides, if your DSL needs to act on stuff like foo-42 being truthy, then how is a simple equality based switch going to help you?

I've been thinking some more about this and I've concluded that it would be better to make the use of == compulsory when testing for basic equality.
It would make the implementation easier and it would both be and 'look' more consistent if the operator always had to be specified. It's also how @mhermier had it when presenting his original idea in #956.

Should we allow instance methods on the switch expression?  Would it be worth the extra complication?
Looking at the built in classes there are a few which might be useful such as: startsWith, endsWith for strings and isInteger, isInfinity and isNan for numbers. However, this would probably see more use for user defined classes. Suggested syntax:
switch(a) {
  case == 42.5: ...
  case .isInteger: ...
  case .isNaN: ...
}

So it should be easy to recognize these from the preceding dot.
If this were allowed, one thing you'd need to be careful about is methods which didn't return a Bool. These would always match if they returned anything other than null in accordance with the usual truthy/falsy rules.

@PureFox48 and now we are full round circle with my original idea... I think it is hard too beat because I think it follow KISS principle (the usual switch syntax with explicit equality declaration), with pseudo method chaining extension twist. And this is the problem of that syntax, it has a high chance of rejection by @ruby0x1 like method chaining syntax was.
For the syntax of the DSL, the real problem is that because of the wren nature (and most object oriented programming languages don't have strict restrictions on operator), you can't restrict what is the return type of an operator. You can document what a method/operator is expected to take as arguments and return for the sake of uniformity, but cannot enforce that it must be.

and now we are full round circle with my original idea.

I'm glad you've noticed that :)
Although I tried initially to marry it with a simple equality based switch by omitting the ==,  it didn't really work and just looked inconsistent.
Allowing instance methods gives it a little more power without going overboard.
However, I'm still adamant that only the 10 (or whatever) boolean operators should be allowed. I realize, of course, that people can override these in their own classes to return something other than Bool but, if they do silly things, then they should expect silly results.
I've no idea what @ruby01's thinking is on this matter as I don't think she's commented so far.
All the rest of us can do is to try and put forward (hopefully coherent) ideas for consideration and, if we can find some sort of consensus on them, then that will obviously help.

Just saw that python 3.10 will add match statements, and their compiler will have some fun creating variables dealing list pattern matching of variables... way out of the league of our simple compiler.

Yes, pattern matching seems to be all the rage just now, with Python (which didn't even have a switch statement before) being the latest to jump on the bandwagon.
As you say,  it doesn't look like being  a good model for us to try and follow - too complicated for our compiler.

If case were an expression token meaning DUP, case.foo would work out of the box, I think.

Not really... It has control flow so it cannot be be an expression. But in code yes it be producing a DUP to some extent.

@mhermier One last performance test re. this PR.  If you are still not convinced, I will close this PR so we can resume discussion in #956 .
I realized the above tests were basically testing the speed of function calls.  The if-then tests were calling String.contains(_) each case.  The switch tests were calling String.part, SeqMatchIfContains.new(_), and String.contains(_).  There was no other work in the loop.  Therefore, the switch was indeed slower, as we would expect.
I ran a new test with dummy work inside the loop, and with higher iteration counts and for longer.  Code is below.  Results (1.0 = if/then):

In this test:

for a switch with 10 String.part cases, smartmatch switch is over 75% of the speed of the if-then.
there is much less dependence on the number of iterations than in the earlier tests.

Optimization is always workload-specific.  This more realistic test suggests to me that this PR would be OK in longer-running programs.
Test code
Below is the 30-case, 1000-iteration test.  All the others are here.
The "Waste some time" at the end of each loop is the additional work.  I think using a switch but not actually doing anything with the results can safely be considered a degenerate case :) .  The extra work is outside the switch because no switch case matches.  (That, in turn, is because this is by design a worst-case test.)
  In this PR, the control flow is handled without any case at all.  It is an odd way of thinking about it, but I don't see any reason it wouldn't work.  I am thinking of it like:
switch(var case = <topic expression) {
  case == 42: {...}
}

@PureFox48 if we had regexes, could we get rid of String.part?

Have to look at the data later.
If case become an expression value then one could do case == 42 || case == 43: { ... } it is not really a 'DUP' anymore one has to do a lookup so one could do MyUnaryPredicate.call(case): { ... }. While the idea is really interesting, I would like to see it in action on real code, because it still does not permit fallthrough (I still don't have a definitive opinion about it).
About regexp, yes and no, regexp performance is a huge rabbit hole.

@cxw42

if we had regexes, could we get rid of String.part?

This question came up in my email notifications though I can't actually find it on the site.
The answer, of course, is yes we could. However, given the likely size of a regex implementation (even my own simple pattern matcher is nearly 800 lines!), I think it would need to be an optional module and some embedders might therefore decide not to include it. part on the other hand just requires adding a few lines to core and would always be on tap.
Incidentally, I see no reason to close this PR just because we can't reach unanimity on it. It  remains the best idea IMHO and you've done a lot of work to flesh it out. So I think it should be left to @ruby0x1 to decide whether it would be suitable for Wren or not.
That doesn't mean we can't continue to discuss it in the (probably forlorn) hope that we can all eventually agree on something.
@mhermier

While the idea is really interesting, I would like to see it in action on real code, because it still does not permit fallthrough (I still don't have a definitive opinion about it).

Although I've swung backwards and forwards on switch issues, one thing I do feel confident about is that fallthrough is a can of worms and should be avoided. The only exception would be if it's decided to go for a simple equality-based switch where (unfortunately) I think we'd have to support it so people could stack empty cases.
Even that might be avoidable if we could allow for (say) a comma separated list of values within each case:
switch (a) {
  case 1:  ...
  case 2, 3, 4: ...
}

Sorry for the confusion about regexes --- I posted the comment but then deleted it when I realized Regex.new would be at least as heavy as String.part.  If we had regex literals, though.... ;)

Hi! I've tried using this patch, but I've encountered a weird issue. I've added a following code to test/language/switch/basic.wren:
switch ("qwe") {
  "qwe": {
    var n = 1
    System.print(n)  // expect: 1
  }
  else: System.print("nope")
}

And test is failing:
> python3 ./util/test.py
FAIL: test/language/switch/basic.wren
      Expected output "1" on line 14 and got "qwe".

877 tests passed. 1 tests failed.

I guess switch messes up the stack, so it uses the switch value and not the case variable.

@RazrFalcon thanks for the test case!  I am able to reproduce it.

Fixed!

Added your test case
Bugfix: Updated compiler to save the topic in a local variable.  That way, the VM knows the topic's stack slot is occupied.  This is the same way for loops are handled.
Rebased on the latest main.

All tests pass.

Relevant diff hunks from f14c03d to e65f58f6 (click to expand...)
This diff includes only the changes made in this PR.
diff --git a/src/vm/wren_compiler.c b/src/vm/wren_compiler.c
index 893e9d16..bbc8fc4e 100644
--- a/src/vm/wren_compiler.c
+++ b/src/vm/wren_compiler.c
@@ -2072,7 +2075,7 @@ static void methodCall(Compiler* compiler, Code instruction,
     called.type = SIG_METHOD;
     called.arity++;

-    // Name the function based on the method its passed to.
+    // Name the function based on the method it's passed to.
     char blockName[MAX_METHOD_SIGNATURE + 16];
     int blockLength;
     signatureToString(&called, blockName, &blockLength);
@@ -2902,7 +2905,6 @@ static int getByteCountForArguments(const uint8_t* bytecode,
     case CODE_FALSE:
     case CODE_TRUE:
     case CODE_POP:
-    case CODE_DUP:
     case CODE_CLOSE_UPVALUE:
     case CODE_RETURN:
     case CODE_END:
@@ -3201,16 +3203,55 @@ static void whileStatement(Compiler* compiler)
   endLoop(compiler);
 }

-// Switch: a series of (topic ~~ test) conditions
+// Switch: a series of (topic ~~ test) conditions.
+// This follows the same pattern as forStatement().  A switch like:
+//
+//     switch (topic) {
+//       "case 1": {
+//         var n = 1
+//         System.print(n)
+//       }
+//       "case 2": System.print(2)
+//       else: System.print("nope")
+//     }
+//
+// is compiled to bytecode almost as if the source looked like this:
+//
+//     {
+//       var topic_ = topic
+//       if(topic_ ~~ "case 1") {
+//         var n = 1
+//         System.print(n)
+//       } else if(topic_ ~~ "case 2") {
+//         System.print(2)
+//       } else {
+//         System.print("nope")
+//       }
+//     }
 static void switchStatement(Compiler* compiler)
 {
   Signature smartmatch = { "~~", 2, SIG_METHOD, 1 };
   IntBuffer cases;
   wrenIntBufferInit(&cases);

+  // Create a scope for the hidden local variable used for the topic.
+  pushScope(compiler);
+
+  // Verify that there is space for the hidden local variable.
+  if (compiler->numLocals + 1 > MAX_LOCALS)
+  {
+    error(compiler,
+          "Cannot declare more than %d variables in one scope. (Not enough "
+          "space for switch-statement internal variables)",
+          MAX_LOCALS);
+    return;
+  }
+
   // Compile the topic expresssion
   consume(compiler, TOKEN_LEFT_PAREN, "Expect '(' after 'switch'.");
   expression(compiler);
+  int topicSlot = addLocal(compiler, "topic ", 6);
+
   consume(compiler, TOKEN_RIGHT_PAREN, "Expect ')' after switch topic.");
   consume(compiler, TOKEN_LEFT_BRACE, "Expect '{' after switch topic.");
   consumeLine(compiler, "Expect newline after '{' starting switch statement.");
@@ -3233,7 +3274,6 @@ static void switchStatement(Compiler* compiler)
     }

     // Normal case: emit topic ~~ test
-    emitOp(compiler, CODE_DUP);   // copy the topic's value
     if (match(compiler, TOKEN_LEFT_BRACE))
     {
       if (peek(compiler) != TOKEN_PIPE)
@@ -3247,7 +3287,11 @@ static void switchStatement(Compiler* compiler)
     {
       expression(compiler);
     }
-    emitOp(compiler, CODE_SWAP);  // smartmatch: make the test the invocant
+
+    // Now we have loaded test, which is the invocant.  Load the topic as
+    // the parameter to the test's smartmatch, and ask the test whether the
+    // topic matches.
+    loadLocal(compiler, topicSlot);
     callSignature(compiler, CODE_CALL_0, &smartmatch);

     consume(compiler, TOKEN_COLON, "Expect ':' after switch expression.");
@@ -3271,9 +3315,11 @@ static void switchStatement(Compiler* compiler)
     patchJump(compiler, cases.data[i]);
   }

-  emitOp(compiler, CODE_POP);     // Remove the original topic value
   consume(compiler, TOKEN_RIGHT_BRACE, "Expect '}' after switch body.");

+  // Hidden variables.
+  popScope(compiler);
+
   wrenIntBufferClear(compiler->parser->vm, &cases);
 }

diff --git a/src/vm/wren_core.c b/src/vm/wren_core.c
index bac0fdea..526db42c 100644
--- a/src/vm/wren_core.c
+++ b/src/vm/wren_core.c
@@ -916,8 +916,8 @@ DEF_PRIMITIVE(object_not)
 }

 // Equality and smartmatch for objects.
-// In smartmatch, the order of arguments is reversed.  However, that doesn't
-// matter for a symmetric equality check.
+// These two have opposite orders of arguments.  However, that doesn't matter
+// for a symmetric equality check.
 DEF_PRIMITIVE(object_eqeq)
 {
   RETURN_BOOL(wrenValuesEqual(args[0], args[1]));
diff --git a/src/vm/wren_debug.c b/src/vm/wren_debug.c
index d5e4e7bf..52f5cda5 100644
--- a/src/vm/wren_debug.c
+++ b/src/vm/wren_debug.c
@@ -177,7 +177,6 @@ static int dumpInstruction(WrenVM* vm, ObjFn* fn, int i, int* lastLine)
     case CODE_STORE_FIELD: BYTE_INSTRUCTION("STORE_FIELD");

     case CODE_POP: printf("POP\n"); break;
-    case CODE_DUP: printf("DUP\n"); break;

     case CODE_CALL_0:
     case CODE_CALL_1:
diff --git a/src/vm/wren_opcodes.h b/src/vm/wren_opcodes.h
index f36176ce..8159c7c1 100644
--- a/src/vm/wren_opcodes.h
+++ b/src/vm/wren_opcodes.h
@@ -77,9 +77,6 @@ OPCODE(STORE_FIELD, -1)
 // Pop and discard the top of stack.
 OPCODE(POP, -1)

-// Push a copy of the value currently on the top of the stack.
-OPCODE(DUP, 1)
-
 // Invoke the method with symbol [arg]. The number indicates the number of
 // arguments (not including the receiver).
 OPCODE(CALL_0, 0)
diff --git a/src/vm/wren_vm.c b/src/vm/wren_vm.c
index 92d89b0e..133b0804 100644
--- a/src/vm/wren_vm.c
+++ b/src/vm/wren_vm.c
@@ -950,12 +950,6 @@ static WrenInterpretResult runInterpreter(WrenVM* vm, register ObjFiber* fiber)
     }

     CASE_CODE(POP):   DROP(); DISPATCH();
-    CASE_CODE(DUP):
-    {
-      Value value = PEEK();
-      PUSH(value); DISPATCH();
-    }
-
     CASE_CODE(NULL):  PUSH(NULL_VAL); DISPATCH();
     CASE_CODE(FALSE): PUSH(FALSE_VAL); DISPATCH();
     CASE_CODE(TRUE):  PUSH(TRUE_VAL); DISPATCH();
diff --git a/test/language/switch/basic.wren b/test/language/switch/basic.wren
index c5683b61..e03389fb 100644
--- a/test/language/switch/basic.wren
+++ b/test/language/switch/basic.wren
@@ -7,3 +7,11 @@ switch(2) {
   1: System.print("one")
   else: System.print("nope")  // expect: nope
 }
+
+switch ("qwe") {
+  "qwe": {
+    var n = 1
+    System.print(n)  // expect: 1
+  }
+  else: System.print("nope")
+}
diff --git a/test/language/switch/pathological.wren b/test/language/switch/pathological.wren
index 0e2b21ff..16176b39 100644
--- a/test/language/switch/pathological.wren
+++ b/test/language/switch/pathological.wren
@@ -16,3 +16,7 @@ switch(1){
 switch(1){
   1: System.print("yes")      // expect: yes
 }
+
+switch(1){
+  1: 1    // the statement can be an expression
+}

Thanks!


HDDS-1784. Missing HostName and IpAddress in the response of register command.

SCMNodeManager sets the HostName and IpAddress to the response of register command, but that is being ignored in SCMDatanodeProtocolServer while sending the response back to the datanode.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
63
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
514
trunk passed

+1
compile
262
trunk passed

+1
checkstyle
66
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
863
branch has no errors when building and testing our client artifacts.

+1
javadoc
156
trunk passed

0
spotbugs
315
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
503
trunk passed

_ Patch Compile Tests _

+1
mvninstall
455
the patch passed

+1
compile
263
the patch passed

+1
javac
263
the patch passed

+1
checkstyle
77
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
683
patch has no errors when building and testing our client artifacts.

+1
javadoc
156
the patch passed

+1
findbugs
527
the patch passed

_ Other Tests _

+1
unit
319
hadoop-hdds in the patch passed.

-1
unit
2164
hadoop-ozone in the patch failed.

+1
asflicense
180
The patch does not generate ASF License warnings.

7439

Reason
Tests

Failed junit tests
hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.hdds.scm.pipeline.TestRatisPipelineCreateAndDestory

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures

hadoop.ozone.client.rpc.TestReadRetries

hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1078/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1078

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 39600f334c9d 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / acef5e0

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1078/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1078/1/testReport/

Max. process+thread count
5040 (vs. ulimit of 5500)

modules
C: hadoop-hdds/server-scm U: hadoop-hdds/server-scm

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1078/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Strange: There is a compilation error. Do not make sense, maybe retest?

/retest


chore(tests): regression fix for master-4430349b5f

What this PR does / why we need it:
Which issue(s) does this PR fixes?:

Fixes #
Additional comments?:

[x] deps: ethers & hardhat installed for evm stuff
[x] container: add -ethrpcbind to support eth rpc call + add RUST_LOG=debug
[x] CI: add npm run compile
[x] enhance checkIfEvmTx
[x] fix: TD test (dftx composer, rpc & rawtx)
[x] func: add ListUnspentQueryOptions to support provider listunspent method
[ ] fix: UpdateMN test
[x] lint: ts-ignore buggy AbortController.signal type check

due to that has updatemn bug on beta-12.. so switch to more later version master-4430349b5f


Enhancing Error Message Readability on Hashscan for Reverted Smart Contract Calls

Problem
Description:
Currently, when a smart contract call is reverted, the error message displayed on Hashscan is well-readable if the error message is either Error(string) or Panic(uint256). However, for custom errors, the display lacks human readability, as it doesn't decode the custom data into a readable format.
Example:
function buy(uint amount) public payable {
    if (amount > msg.value / 2 ether)
        revert("Not enough Ether provided.");
}

In this example, the error generates an Error(string) data, which Hashscan displays nicely.

link to example transaction: https://hashscan.io/testnet/transaction/1708618373.183662003
Proposal:
Enhance the error message display for custom errors such as:
error Unauthorized(address);
function withdraw() public {
    if (msg.sender != owner)
        revert Unauthorized(msg.sender);
}

Currently, Hashscan decodes custom error data into a non-human-readable format.

link to example transaction: https://hashscan.io/testnet/transaction/1708620069.753947441
This issue proposes improving this to make custom error messages more easily understandable to developers.
Expected Outcome:
With this enhancement, developers will benefit from better readability of error messages, especially for custom errors, leading to improved debugging and development experiences when interacting with smart contracts on Hashscan.
Solution

If the contract is not verified, display the data hash
- If the contract is verified, decode the error using its ABI

Alternatives
No response

Updated: Hashscan does decode the error message using the contract interface when the contract is verified.
error Unauthorized(address account, string message, uint256 ID, bool status);
    function withdraw() public {
        if (msg.sender != owner)
            revert Unauthorized(msg.sender, "Unauthorized!!", 369, false);

        payable(msg.sender).transfer(address(this).balance);
}```
<img width="1120" alt="image" src="https://github.com/hashgraph/hedera-mirror-node-explorer/assets/66233296/b29a90e8-78b5-4618-aa6e-f251a132946f">
**link to example transaction**: https://hashscan.io/testnet/transaction/1708635063.837440003

This will leave the solution left with `If the contract is not verified and the error is caused by a custom error, display the data hash`

Below is an example of a redirectForToken function call that reverts with the following error that isn't plainly human readable.
0x494e56414c49445f4f5045524154494f4e
https://hashscan.io/mainnet/transaction/1723125786.080226003


[enhancement]: Add border to the control image preview.

Is there an existing issue for this?

[X] I have searched the existing issues

Contact Details
No response
What should this feature add?
Currently there is no border to the control image preview, due to which the UI looks a little messed up depending upon the ratio of the uploaded image. Also, sometimes the buttons overlayed over bright images are not easily visible.
There should be a clear border present around the uploaded control or upscale image preview, and the overlayed buttons should be moved outside of the border to make the UI look more polished. The buttons should always be present and just greyed out when no image is uploaded.

Alternatives
No response
Additional Content
No response

Agreed it would look better w/ a border. I like how the action icons are not overlaid but instead in their on spot off to the side - easier to see them.


Integrate new colors

Who is this for?
All of us
What is it doing for them?
Integrates the new colour palette.
Updates the Palette story, the goal is to add more details as to what the goal is for each colour section (core, accent, neutrals, warm neutrals, validation).
Notes and next steps
The codebase currently uses the newColors object, the NewPaletteColors type and the newColors() function. This is to help ensure we've covered all grounds. I'm concerned in the time it take to review and merge, conflicting PRs will cause us to forget some newer changes and this helps catch them.
Once it's merged in, I'll get a new PR up to revert to colors, PaletteColors and colors() and hopefully get that out very quickly.
Once it goes to staging, it would be good to have a short freeze on prod deployments just so we can make sure a11y and our e2e still passes. I've tested as much as I could every step of the way so I'm hoping it works out.

I’ll dive into this after the retro.

I move to get this merged ASAP and work on issues as we find them. 🦑

Sounds good to me! I've pushed some changes based on your comments, thanks for looking so quickly! There shouldn't be issues with tests  🤞 I'll merge it first thing tomorrow after a final merge from main and a double check.

I guess I must be wrong about the rgb/hsl typing otherwise TypeScript would be shouting, but I couldn't immediately see why.

Good spot! I think if you dig in, the types are so heavily nested that at some point it anys them and the type checker gets stuck.


Don’t use instantiateStreaming for rotate wasm module

Fixes #493
(H/T @alisaitbilgi)

I was thinking to try something like that and not sure to have a performance penalty by feature detecting instantiateStreaming:
const getInstancePromise = async () => {
  const response = await fetch(wasmUrl);
  const buffer = await response.arrayBuffer();
  const module = await WebAssembly.compile(buffer);

  return WebAssembly.instantiate(module);
};

const instancePromise = ('instantiateStreaming' in WebAssembly)
  ? (WebAssembly as any).instantiateStreaming(fetch(wasmUrl))
  : getInstancePromise();

As I say in the comment in the code, I don’t think it’s worth shipping the detection code considering we are loading a 500B wasm module here.

hoo, cool I thought it was 500MB :D

That would not have made it to production. Ever. 😂


Error [ERR_REQUIRE_ESM]: require() of ES Module

Describe the bug
Using the component causes the following error:
Error [ERR_REQUIRE_ESM]: require() of ES Module /myapp/node_modules/mui-file-input/node_modules/pretty-bytes/index.js from /myapp/node_modules/mui-file-input/dist/mui-file-input.umd.js not supported.
Instead change the require of index.js in /myapp/node_modules/mui-file-input/dist/mui-file-input.umd.js to a dynamic import() which is available in all CommonJS modules.
To Reproduce
Install the package
import MuiFileInput
Use the MuiFileInput in a page/component
Desktop (please complete the following information):

Mac OS 13.3.1 (a)
Chrome
Version 113.0.5672.126

Additional context
Changing the require in dist to import() fixed it.

I have the same issue as well. Any solution?

Exactly same problem appeared this week.

I got the same error, so i tried it.

Change the module option in tsconfig.json below.

{
       "compiler options": {
         ...
         "module": "CommonJS" // change 'esnext' to 'CommonJS'
}

My team's Next.js project loads dynamic import components on page load. But in this case, module in tsconfig.json is automatically changed to CommonJS → esnext. (same error...)

The MuiFileInput component also uses "dynamic import" to load the component.

const MuiFileInput = Dynamic(
  () => import("mui-file-input").then((d) => d.MuiFileInput),
  {
    SSR: False,
  },
);

it worked fine without any errors. :)

Let me fix that

Fixed in 2.0.5


[REEF-423]: Move Streaming Codec classes from Network to Wake layer

This addressed the issue by

actually moving the StreamingCodec to Wake layer

JIRA: REEF-423

I'll have a look.


Add versioning to docs

Adding a placeholder for this so we don't forget about it. Original discussion here: https://github.com/facebook/create-react-app/issues/5238#issuecomment-432428041

Stale be gone


Added link to AUR

2nd attempt at this as in #10 I accidentally pushed a commit to the wrong branch.
I went ahead and made an AUR package for this (I prefer to have my stuff managed there if not on an official repo). Figured I'd add it to the list of downloads so people are aware its there.

Thank you, this looks good 👍

Thank you, this looks good 👍


Error trying to run demo projects

Type-safe project accessors is an incubating feature.
Project accessors enabled, but root project name not explicitly set for 'buildSrc'. Checking out the project in different folders will impact the generated code and implicitly the buildscript classpath, breaking caching.
Kotlin does not yet support 22 JDK target, falling back to Kotlin JVM_21 JVM target

> Task :buildSrc:compileKotlin
Kotlin does not yet support 22 JDK target, falling back to Kotlin JVM_21 JVM target
w: Inconsistent JVM-target compatibility detected for tasks 'compileJava' (22) and 'compileKotlin' (21).
This will become an error in Gradle 8.0.
Consider using JVM Toolchain: https://kotl.in/gradle/jvm/toolchain
Learn more about JVM-target validation: https://kotl.in/gradle/jvm/target-validation

> Task :buildSrc:jar
:jar: No valid plugin descriptors were found in META-INF/gradle-plugins

> Configure project :wgpu4k
JReleaser Gradle Plugin 1.13.1. Consider becoming a sponsor at https://opencollective.com/jreleaser
w: file:///C:/Github/wgpu4k/wgpu4k/build.gradle.kts:116:5: Experimental API in the Kotlin Gradle Plugin: No stability guarantees can be provided. The API could get removed in the future without replacement
w: New 'wasm' target is Work-in-Progress and is subject to change without notice. Please report encountered issues to https://kotl.in/issue

w: The following Kotlin/Native targets cannot be built on this machine and are disabled:
iosArm64, iosX64, macosArm64, macosX64
To hide this message, add 'kotlin.native.ignoreDisabledTargets=true' to the Gradle properties.

w: The Default Kotlin Hierarchy Template was not applied to 'project ':wgpu4k'':
Explicit .dependsOn() edges were configured for the following source sets:
[androidNativeArm64Main, androidNativeX64Main, iosArm64Main, iosX64Main, linuxArm64Main, linuxX64Main, macosArm64Main, macosX64Main, unmappedMain]

Consider removing dependsOn-calls or disabling the default template by adding
    'kotlin.mpp.applyDefaultHierarchyTemplate=false'
to your gradle.properties

Learn more about hierarchy templates: https://kotl.in/hierarchy-template

> Configure project :wgpu4k-toolkit
w: file:///C:/Github/wgpu4k/wgpu4k-toolkit/build.gradle.kts:24:5: This declaration needs opt-in. Its usage should be marked with<EMAIL_ADDRESS>or '@OptIn(org.jetbrains.kotlin.gradle.targets.js.dsl.ExperimentalWasmDsl::class)'
w: file:///C:/Github/wgpu4k/wgpu4k-toolkit/build.gradle.kts:71:5: Experimental API in the Kotlin Gradle Plugin: No stability guarantees can be provided. The API could get removed in the future without replacement

> Configure project :examples:common
w: file:///C:/Github/wgpu4k/examples/common/build.gradle.kts:12:2: This declaration needs opt-in. Its usage should be marked with<EMAIL_ADDRESS>or '@OptIn(org.jetbrains.kotlin.gradle.targets.js.dsl.ExperimentalWasmDsl::class)'
w: file:///C:/Github/wgpu4k/examples/common/build.gradle.kts:38:2: Experimental API in the Kotlin Gradle Plugin: No stability guarantees can be provided. The API could get removed in the future without replacement

> Configure project :examples:web-js
w: file:///C:/Github/wgpu4k/examples/web-js/build.gradle.kts:20:5: This declaration needs opt-in. Its usage should be marked with<EMAIL_ADDRESS>or '@OptIn(org.jetbrains.kotlin.gradle.targets.js.dsl.ExperimentalWasmDsl::class)'
w: file:///C:/Github/wgpu4k/examples/web-js/build.gradle.kts:50:5: Experimental API in the Kotlin Gradle Plugin: No stability guarantees can be provided. The API could get removed in the future without replacement

> Task :wgpu4k:downloadFile-wgpu-linux-aarch64-release.zip
Download https://github.com/gfx-rs/wgpu-native/releases/download/v<IP_ADDRESS>/wgpu-linux-aarch64-release.zip

> Task :wgpu4k:downloadFile-wgpu-macos-x86_64-release.zip
Download https://github.com/gfx-rs/wgpu-native/releases/download/v<IP_ADDRESS>/wgpu-macos-x86_64-release.zip

> Task :wgpu4k:downloadFile-wgpu-macos-aarch64-release.zip
Download https://github.com/gfx-rs/wgpu-native/releases/download/v<IP_ADDRESS>/wgpu-macos-aarch64-release.zip

> Task :wgpu4k:downloadFile-wgpu-linux-x86_64-release.zip
Download https://github.com/gfx-rs/wgpu-native/releases/download/v<IP_ADDRESS>/wgpu-linux-x86_64-release.zip

> Task :wgpu4k:downloadFile-wgpu-windows-x86_64-release.zip
Download https://github.com/gfx-rs/wgpu-native/releases/download/v<IP_ADDRESS>/wgpu-windows-x86_64-release.zip

> Task :examples:glfw:run FAILED
will extract library to path C:\Program Files\Java\jdk-22\bin\WGPU0.dll
Exception in thread "main" java.nio.file.AccessDeniedException: C:\Program Files\Java\jdk-22\bin\WGPU0.dll
        at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
        at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:234)
        at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:482)
        at java.base/java.nio.file.Files.newOutputStream(Files.java:227)
        at java.base/java.nio.file.Files.copy(Files.java:3145)
        at io.ygdrasil.wgpu.internal.jvm.LibraryLoaderKt.extractResourceToTemp(LibraryLoader.kt:95)
        at io.ygdrasil.wgpu.internal.jvm.LibraryLoaderKt.exportAndLoadLibrary(LibraryLoader.kt:14)
        at io.ygdrasil.wgpu.WGPU$Companion.loadLibrary(WGPU.kt:113)
        at io.ygdrasil.wgpu.examples.GlfwMainKt$main$1.invokeSuspend(GlfwMain.kt:18)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
        at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:277)
        at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:95)
        at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:69)
        at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
        at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:48)
        at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
        at io.ygdrasil.wgpu.examples.GlfwMainKt.main(GlfwMain.kt:17)
        at io.ygdrasil.wgpu.examples.GlfwMainKt.main(GlfwMain.kt)

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':examples:glfw:run'.
> Process 'command 'C:\Program Files\Java\jdk-22\bin\java.exe'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.8/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 4m 20s
29 actionable tasks: 29 executed```

Hello, thank you for your feedback.
This isn't the first time I've encountered issues with library extraction on Windows. I guess this part is a bit clunky. Give me some time to improve it, unless you have an idea about where to safely extract the library?

Should be fix by https://github.com/wgpu4k/wgpu4k/pull/25.
@ValorZard Could you retry from the main branch ?

it works!


Add descriptive text box for variables, reorder variables in dropdown

This PR accomplishes two main goals:

It adds a descriptive box below the variable selector dropdown with a layman's description of the variable selected. The text dynamically updates with new selections. See screenshot below for an idea of what this looks like (the added text is circled).
It reorders the variables in the drop down selector to match the order of variables in the csv file containing the extended variable descriptions. Therefore, in order to re-order the variables, you just change the order of the variables in the csv file (no need to change the source code).

Notable code/data additions:

A new file variable_descriptions.csv that contains each variable name, the catalog description (from whatever model used to generate it), and an extended variable description. This file is located in climakitae/data (a new folder).
A new unit testing file tests/test_var_csv.py to ensure that the variable descriptions csv file is compatible with the variables in the catalog, to avoid unexpected issues in the source code if the csv file is changed. As in, we need the variable names and catalog descriptions of each variable in the catalog and the csv file to match to avoid conflicts.

Important note:
One of the tests in the new testing file is not currently passing. This is due to a bug in main (the variable "Precipitation (total)" is lacking a variable name). This bug will be fixed once the add_var_test branch is merged.

Does the CSV work with the quotations removed? Quotations are needed when there are "," in the field as the comma is used as the field delimiter. So the quotes might need to go back?

Does the CSV work with the quotations removed? Quotations are needed when there are "," in the field as the comma is used as the field delimiter. So the quotes might need to go back?

No it doesn't work, I'm working on adding the quotations back in now. I got confused by your comment and made a mess out of the file.

Sorry about that! Yeah, just need to clean up the white space!

Ugh, me and GitHub are not friends today. I accidentally clicked "Close with comment" to this PR. I just reopened it. Sorry for any confusion.

I deleted a few comments from Owen that were just repeats. They were attached to Cora's PR likely by mistake. The comments are the same as those he posted in his review, so I deleted the repeat comments  attached to Cora's PR for clarity.

Owen had a comment about ensuring that the radiation variable descriptions are accurate in regards to WRF's treatment of radiation. In an effort to move forward with this PR, I'll plan to address that comment in a later PR if the descriptions require further editing after looking more into the WRF documentation.


Remove microbenchmarks from pom.xml aggregation

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[*] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[*] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[*] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[*] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

The microbenchmarks should not be released as part of the Beam
distribution, rather they exist for internal measurements and testing.

R: @davorbonaci

LGTM.
For posterity, this is being removed since it uses dependencies with unapproved licenses. We have to remove this code until we find a suitable replacement dependencies.


Corrected URLs for raw data on all test pages

This pull request corrects URLs to raw data on all test pages.

This change is

LGTM


Webpack fails to bundle node_redis

Whenever I require redis inside a file other than the one where I start the server, I get the following error while webpack is bundling:
ERROR in ./~/redis/index.js
Module not found: Error: Cannot resolve module 'net' in     C:\NodeServer\AppInTheWild\node_modules\redis
 @ ./~/redis/index.js 3:10-24

ERROR in ./~/redis/lib/parser/hiredis.js
Module not found: Error: Cannot resolve module 'hiredis' in C:\NodeServer\AppInTheWild\node_modules\redis\lib\parser
 @ ./~/redis/lib/parser/hiredis.js 3:14-32

EDIT: being solved at: https://github.com/webpack/webpack-dev-server/issues/227

https://github.com/webpack/webpack-dev-server/issues/227#issuecomment-125803858


Adds GPS tags support and upgrades to higher libexif_jll version with ARM MacOS support

For:

Upgrade libexif_jll to newer version 0.6.24
Add support for GPS tags

Fixes #17( for ARM MacOS support) #11 (for GPS tag support), major issue is in consistency of generator, I don't want such big changes in LibExif.jl every commit

Problem was that some tags have same value based on which they get assigned their tag and hence can't be used in @enum ExifTag(unique value only in enum) so some GPS tags are left out and kept out marked as const.
To incorporate those for to be read when reading GPS IFD, what I did is made another enum ExifTagGPS which holds GPS tags. When I read the tags and if it is GPS IFD, I check if that number for identification of tags exists in ExifTagGPS or not..if it does I update it with Tag from ExifTagGPS. I don't consider support in GPS IFD and prioritize GPS tags. Also I kept changes to minimum in the generated file, hoping it stays similar next time too whenever I have to generate it next. Closes #17 and #11


Node version mismatch

There is a mismatch between the node version specified in package.json and the actual node version when used as a part of GitHub workflow:
https://github.com/ScribeMD/docker-cache/blob/8cd7495f37b9e168dc6461e56ca302c4e8f6ddfd/package.json#L17-L20
https://github.com/ScribeMD/docker-cache/blob/8cd7495f37b9e168dc6461e56ca302c4e8f6ddfd/action.yaml#L23-L27

Please correct me if I am wrong, but I don't believe that GitHub Actions yet supports using: node18. We have never encountered any issues as a consequence of this intentional discrepancy, and I would expect them to be caught in CI. Using the latest LTS version in package.json effectively allows us to test against both Node.js 16 and 18, reducing the risk that code is introduced that breaks once GitHub Actions does support Node.js 18. Please let me know if I may have overlooked some drawback of this admittedly counterintuitive decision.

Oh, I see. You are targeting Node v18 specifically to support it when GitHub Actions support it. Our internal repo actually targets Node v16 and when trying to add this repo (b/c it is not published as npm package), we've run into some issues. In #612 you've mentioned that perhaps GHCR is better suited for our needs so I'll proceed to close this issue and resume conversation there.

Yep, although it's not something I feel strongly about in such a small repository, so we are open to changing the Node.js version in package.json in the future. Thank you for alerting us to this issue in any case. If I understand correctly, the issues you encountered would only apply to those attempting to use docker-cache from a JavaScript action, not as a GitHub Action? If so, it sounds like we need to remember to drop the Node.js version to 16 in package.json if there is more interest in using docker-cache as an npm package, but it's safe to leave it for now?

If I understand correctly, the issues you encountered would only apply to those attempting to use docker-cache from a JavaScript action, not as a GitHub Action?

Yup, that's what I was initially thinking to do.

If so, it sounds like we need to remember to drop the Node.js version to 16 in package.json if there is more interest in using docker-cache as an npm package, but it's safe to leave it for now?

Yeah, safe to leave for now. As mentioned in https://github.com/ScribeMD/docker-cache/issues/612#issuecomment-1684284304, using docker save and docker load did not lead to better performance so I've decided to leave it as it is for now and come back to the issue of time later.


[Bug] Get-DbaAgentSchedule description does not capture "1" hours

It appears that the code to compute the descriptions of schedules skips schedules set to every 1 hour. I'd say it skips every 1 minute, and 1 second as well but have not tested.

Environmental information

#### PowerShell version:

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.3
PSEdition                      Core
GitCommitId                    7.0.0-preview.3
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

#### dbatools Module version:

Name    : dbatools
Path    : C:\Users\shane.oneill.KNEATORG\Documents\PowerShell\Modules\dbatools\1.0.83\dbatools.psd1
Version : 1.0.83

Name    : dbatools
Path    : C:\Users\shane.oneill.KNEATORG\Documents\PowerShell\Modules\dbatools\1.0.73\dbatools.psd1
Version : 1.0.73

Name    : dbatools
Path    : C:\Users\shane.oneill.KNEATORG\Documents\PowerShell\Modules\dbatools\1.0.52\dbatools.psd1
Version : 1.0.52

#### PowerShell version:

Name                           Value
----                           -----
PSVersion                      5.1.17763.771
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.771
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

#### dbatools Module version:

Name    : dbatools
Path    : C:\Users\shane.oneill.KNEATORG\Documents\PowerShell\Modules\dbatools\1.0.83\dbatools.psd1
Version : 1.0.83

Name    : dbatools
Path    : C:\Users\shane.oneill.KNEATORG\Documents\PowerShell\Modules\dbatools\1.0.73\dbatools.psd1
Version : 1.0.73

Name    : dbatools
Path    : C:\Users\shane.oneill.KNEATORG\Documents\PowerShell\Modules\dbatools\1.0.52\dbatools.psd1
Version : 1.0.52

Name    : dbatools
Path    : C:\Program Files\WindowsPowerShell\Modules\dbatools\1.0.90\dbatools.psd1
Version : 1.0.90

Name    : dbatools
Path    : C:\Program Files\WindowsPowerShell\Modules\dbatools\0.9.418\dbatools.psd1
Version : 0.9.418

LCID             Name             DisplayName
----             ----             -----------
6153             en-IE            English (Ireland)

SQL Server:

Microsoft SQL Server 2017 (RTM-CU15-GDR) (KB4505225) - 14.0.3192.2 (X64)   Jun 15 2019 00:45:05   Copyright (C) 2017 Microsoft Corporation  Developer Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 17763: ) (Hypervisor)

/* REPLACE WITH output of @@LANGUAGE */

Report

Host used

[x] powershell.exe
[ ] ISE
[x] VS Code
[ ] Other (please specify)

If anything other than powershell.exe was used, please confirm that you can duplicate the issue with powershell.exe

[ ] Still buggy in powershell.exe

Errors Received

Steps to Reproduce

Run Get-DbaAgentSchedule on a SQL Server instance that has a schedule set to run hourly.

Expected Behavior

The expected behaviour is that the description shows the schedule will run every 1 hour.
Actual Behavior

The command does not return a description that the schedule will run every 1 hour
Get-DbaAgentSchedule -SqlInstance localhost | Format-Table Name, Description

I will close this for now, but you can reopen it if this is still an issue with the current version.


MRG, FIX: allow explicit non-data picks

closes #7631
New test fails on master and passes on this PR

cc @gpeyton

still waiting for Travis, but other CIs are all green; this should be ready for review.

LGTM +1 for merge after latest.inc update

thanks @drammock


'Cheerio' Error

[Enter steps to reproduce below:]

...
...

Atom Version: 1.9.8
System: Unknown Windows Version
Thrown From: browser-plus package, v0.0.75
Stack Trace
Uncaught Error: Cannot find module 'cheerio'
At module.js:341

Error: Cannot find module 'cheerio'
    at Module._resolveFilename (module.js:339:15)
    at Function.Module._resolveFilename (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\module-cache.js:383:52)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\native-compile-cache.js:50:27)
    at Function.module.exports.BrowserPlusView.checkBase (file:///C:/Users/Walddys Emmanuel/.atom/packages/browser-plus/lib/browser-plus-view.coffee:357:15)
    at Function.module.exports.BrowserPlusView.content (file:///C:/Users/Walddys Emmanuel/.atom/packages/browser-plus/lib/browser-plus-view.coffee:31:36)
    at Function.<anonymous> (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\node_modules\atom-space-pen-views\node_modules\space-pen\lib\space-pen.js:156:31)
    at Function.View.buildHtml (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\node_modules\atom-space-pen-views\node_modules\space-pen\lib\space-pen.js:123:10)
    at BrowserPlusView.View [as constructor] (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\node_modules\atom-space-pen-views\node_modules\space-pen\lib\space-pen.js:155:33)
    at new BrowserPlusView (file:///C:/Users/Walddys Emmanuel/.atom/packages/browser-plus/lib/browser-plus-view.coffee:23:5)
    at ViewRegistry.module.exports.ViewRegistry.createView (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\view-registry.js:136:16)
    at ViewRegistry.module.exports.ViewRegistry.getView (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\view-registry.js:86:21)
    at atom-pane.PaneElement.getActiveView (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\pane-element.js:194:25)
    at atom-pane.<anonymous> (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\pane-element.js:51:55)
    at atom-pane.PaneElement.activated (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\pane-element.js:113:19)
    at Function.module.exports.Emitter.simpleDispatch (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\node_modules\event-kit\lib\emitter.js:25:14)
    at Emitter.module.exports.Emitter.emit (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\node_modules\event-kit\lib\emitter.js:125:28)
    at Pane.module.exports.Pane.activate (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\pane.js:833:27)
    at atom-workspace.module.exports.WorkspaceElement.handleFocus (C:\Users\Walddys Emmanuel\AppData\Local\atom\app-1.9.8\resources\app.asar\src\workspace-element.js:127:41)

Commands
     -0:32.2.0 core:close (ul.list-inline.tab-bar.inset-panel)

Config
{
  "core": {
    "autoHideMenuBar": true,
    "openEmptyEditorOnStart": false
  }
}

Installed Packages
# User
atom-beautify, v0.29.10 (inactive)
atom-html-preview, v0.1.22 (active)
autoclose-html, v0.23.0 (active)
autocomplete-html-entities, v0.1.0 (active)
autocomplete-paths, v1.0.2 (active)
autoprefixer, v3.2.0 (inactive)
browser-plus, v0.0.75 (active)
browser-plus-block, v0.0.4 (active)
browser-plus-zoom, v0.0.1 (active)
close-tags, v0.6.0 (inactive)
color-picker, v2.2.2 (active)
double-tag, v0.4.0 (active)
file-icons, v1.7.18 (active)
highlight-line, v0.11.1 (active)
html-to-css, v0.2.2 (inactive)
linter, v1.11.16 (active)
linter-csslint, v1.3.2 (active)
linter-jscs, v4.0.5 (active)
linter-jshint, v2.1.0 (active)
linter-tidy, v2.2.0 (active)
minimap, v4.24.7 (active)
minimap-bookmarks, v0.3.1 (active)
minimap-cursorline, v0.2.0 (active)
minimap-find-and-replace, v4.5.1 (active)
minimap-git-diff, v4.3.1 (active)
minimap-highlight-selected, v4.4.0 (active)
minimap-pigments, v0.2.1 (active)
minimap-selection, v4.4.0 (active)
pp, v0.0.1 (active)
preview-plus, v1.2.7 (active)
script, v3.8.3 (inactive)
tree-view-copy-relative-path, v1.0.1 (inactive)
atom-dark-syntax, v0.27.0 (inactive)
atom-dark-ui, v0.51.0 (inactive)
atom-light-syntax, v0.28.0 (inactive)
atom-light-ui, v0.43.0 (inactive)
base16-tomorrow-dark-theme, v1.1.0 (inactive)
base16-tomorrow-light-theme, v1.1.1 (inactive)
one-dark-ui, v1.3.2 (active)
one-light-ui, v1.3.2 (inactive)
one-dark-syntax, v1.2.0 (active)
one-light-syntax, v1.2.0 (inactive)
solarized-dark-syntax, v1.0.2 (inactive)
solarized-light-syntax, v1.0.2 (inactive)
about, v1.5.2 (active)
archive-view, v0.61.1 (active)
autocomplete-atom-api, v0.10.0 (active)
autocomplete-css, v0.11.1 (active)
autocomplete-html, v0.7.2 (active)
autocomplete-plus, v2.31.0 (active)
autocomplete-snippets, v1.11.0 (active)
autoflow, v0.27.0 (inactive)
autosave, v0.23.1 (active)
background-tips, v0.26.0 (active)
bookmarks, v0.41.0 (active)
bracket-matcher, v0.82.1 (active)
command-palette, v0.38.0 (inactive)
deprecation-cop, v0.54.1 (active)
dev-live-reload, v0.47.0 (active)
encoding-selector, v0.22.0 (active)
exception-reporting, v0.39.0 (active)
fuzzy-finder, v1.3.0 (active)
git-diff, v1.1.0 (active)
find-and-replace, v0.198.0 (inactive)
go-to-line, v0.31.0 (inactive)
grammar-selector, v0.48.1 (active)
image-view, v0.58.0 (active)
incompatible-packages, v0.26.1 (active)
keybinding-resolver, v0.35.0 (active)
line-ending-selector, v0.5.0 (active)
link, v0.31.1 (inactive)
markdown-preview, v0.158.0 (active)
metrics, v0.53.1 (active)
notifications, v0.64.1 (active)
open-on-github, v1.2.0 (inactive)
package-generator, v1.0.0 (inactive)
settings-view, v0.238.2 (active)
snippets, v1.0.2 (active)
spell-check, v0.67.1 (active)
status-bar, v1.4.1 (active)
styleguide, v0.46.0 (active)
symbols-view, v0.113.0 (inactive)
tabs, v0.98.1 (active)
timecop, v0.33.1 (active)
tree-view, v0.208.0 (active)
update-package-dependencies, v0.10.0 (active)
welcome, v0.34.0 (active)
whitespace, v0.32.2 (active)
wrap-guide, v0.38.1 (active)
language-c, v0.52.1 (active)
language-clojure, v0.21.0 (active)
language-coffee-script, v0.47.0 (active)
language-csharp, v0.12.1 (active)
language-css, v0.36.2 (active)
language-gfm, v0.86.0 (active)
language-git, v0.13.0 (active)
language-go, v0.42.0 (active)
language-html, v0.44.1 (active)
language-hyperlink, v0.16.0 (active)
language-java, v0.22.0 (active)
language-javascript, v0.119.0 (active)
language-json, v0.18.0 (active)
language-less, v0.29.3 (active)
language-make, v0.22.2 (active)
language-mustache, v0.13.0 (active)
language-objective-c, v0.15.1 (active)
language-perl, v0.35.0 (active)
language-php, v0.37.0 (active)
language-property-list, v0.8.0 (active)
language-python, v0.45.0 (active)
language-ruby, v0.68.5 (active)
language-ruby-on-rails, v0.25.0 (active)
language-sass, v0.52.0 (active)
language-shellscript, v0.22.3 (active)
language-source, v0.9.0 (active)
language-sql, v0.21.1 (active)
language-text, v0.7.1 (active)
language-todo, v0.28.0 (active)
language-toml, v0.18.0 (active)
language-xml, v0.34.8 (active)
language-yaml, v0.26.0 (active)

# Dev
No dev packages

Assuming should have fixed the error..as there is no response.


Package build123d

Build123d describes itself as "an evolution of CadQuery", relies on the same hellish-to-package cadquery-ocp library, and seems to have some community overlap.

Got this started in https://github.com/marcus7070/cq-flake/pull/42.

Opened a similar issue at https://github.com/NixOS/nixpkgs/issues/245258.


Migrate volume snapshot tasks to Tasks section

This is a refactor request

What would you like to be added
Create a new task page that contains the task-like content relating to snapshots, such as Create a PersistentVolumeClaim from a Volume Snapshot. It's OK to create more than one page if you need to.
You should not need to write new content or change the existing content.
Make sure that the concept page for PersistentVolume hyperlinks to any pages that you create as part of this work.
Why is this needed
The concept page is plenty big, and the snapshot tasks are hard to isolate from the rest of the text. When readers want to perform specific tasks, it helps if there is page that walks through the steps to follow without diversions.
Comments
Add the refactor label to any pull request this makes a change, or flag to your review that that label is needed.
/language en
It's OK to address this issue through multiple pull requests.
Mention me (@sftim) if you are working on this and would like help with the work - you can comment on this issue with your query.
The wider Documentation SIG will also be available to offer tips.

Remember to update https://kubernetes.io/docs/concepts/storage/volume-snapshots/ if you make any relevant changes.

/sig storage

/triage accepted

@sftim Are we eyeing at creating seperate pages, each for a task like:

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-an-existing-pvc
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot

and others? I personally believe a nice way would be to create 1-page with a list of all these tasks, I am still a bit confused about approaching this issue though.

/remove-lifecycle stale

@sftim Are we eyeing at creating seperate pages, each for a task like:
* https://kubernetes.io/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-an-existing-pvc

* https://kubernetes.io/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot

* https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volume-claim-requesting-a-raw-block-volume

* https://kubernetes.io/docs/concepts/storage/persistent-volumes/#pod-specification-adding-raw-block-device-path-in-container

and others? I personally believe a nice way would be to create 1-page with a list of all these tasks, I am still a bit confused about approaching this issue though.

I don't have a strong view on whether that should be one page or several. @Rishit-dagli if you want to do it as one page I think that sounds fine - it's an improvement on what we have now.

/remove-lifecycle rotten

Help on this issue is welcome.


before and after on user module unit tests

Wouldn't you be better with beforeEach and afterEach?

Which parts/files specifically?

I'm assuming @gilesbradshaw is taking about changing before and after ti beforeEach and afterEach. So instead of creating a two users as the beginning for all tests to share, it would create new users for each test to share. Then after each test it would reset the database before moving onto the next test.
https://github.com/meanjs/mean/blob/0.4.0/modules/users/tests/server/user.server.model.tests.js
If this is something we want, we could discuss it with #684 otherwise, I think we should close this issue.

I don't think it's an all or nothing. Some tests require other tests to run before them and are based on the previous test.
I do however suggest @gilesbradshaw that if you want to add more tests (and there are many places to add them, whether it's the backend, frontend, or e2e) then just go ahead and create a PR.


Username and password for Smart Charging

I have launched the Smart Charging package and activated it for one of my tenants. When configuring, it asks for username and password. Where can I define the username and password for the smart charging plugin?

Ok, I just didn't use the right endpoint ending with /api/v1/OptimizeChargingProfiles... then it takes whatever username and password.


Fix projector preview

Closes #2702

the projection is too far up if "show header and footer" is activated

Two things:

I can't see/replicate this, so I would probably need a better replication description or a picture or something
All I did was fix the projection data in order to make the preview work again, I did not change anything about the preview projector itself, which is the same component as the normal projector. Unless this "projection being too far up"-thing happens only in the preview and not in the normal projector, I'd say that is a separate bug.

@Elblinator  Please take a closer look at this and act accordingly

This indeed only happens in the preview:
the actual projector(same in projector-detail):

projector preview:

projector preview without the header:

It happens with an election, a topic, the agenda, a LoS
Additionally png files in the preview are only a black field

the files still don't work


Add Usage guide to wiki

Add a Wiki with information on how to use this mod, or alternatively link to somewhere else that has this information!

So I see this thread is now almost 6 months old, any update on when there will be a wiki on how to use the mod other than the reddit post from 2 years ago about using /profile e to profile everything?

I don't plan to write one currently, as I am busy with university and work. The wiki is open to public editing, so if someone else wants to that would be great.
I will still be updating the mod for newer minecraft versions when/if people request it. I don't plan to add any new features at this time.

So the usage information in MC 1.7.10 returns this information: Usage: /profile [e/(c [chunk x] [chunk z])] [time=30] [dimensionid=all]
However, when I try to tell it to run in just a specific dimension, it runs in all worlds for 30 secs as if I only typed /profile. I have tried /profile e dimensionid=-112, /profile c dimensionid=-112, /profile dimensionid=-112, /profile [dimensionid=-112], /profile e [dimensionid=-112], /profile c [dimensionid=-112]
No matter how I enter the information I either get the Usage: /profile [e/(c [chunk x] [chunk z])] [time=30] [dimensionid=all] reply, or tick profiler runs for 30 secs in all worlds.

The help message is somewhat unclear.
/profile [e/(c [chunk x] [chunk z])] [time=30] [dimensionid=all]
/profile e [time=30] [dimensionid=all]
/profile e 30 [dimensionid=all]
/profile e 30 1
Is what it's supposed to mean.

ahh thanks for the update

I've added a basic usage guide to the wiki. If anyone wants to clean it up or improve it you're welcome to.

How about documentation on the /dump command?  It's there in the code but reading it didn't quite tell me what it's for.


Add a "Deploy to Digital Ocean" button.

https://docs.digitalocean.com/products/app-platform/how-to/add-deploy-do-button/
https://docs.digitalocean.com/products/app-platform/references/app-specification-reference/

Looks like both PostgreSQL and Redis are configured under "databases".

As you can tell by the number of commits on the branch I started working on, this one's taking some effort to get moving. I've been going back and forth with Digital Ocean's support team for a bit and have gotten to the point where the site is deployed, but I'm getting an error when trying to actually access the site.
Although it's kind of old, I'm putting this video here for reference.
Currently trying to attach a database, since the details in the template I wrote aren't seeming to pick up on production: true.

@andrewculver I’ve spent a decent amount of time on this, and I’ve come to the conclusion that a one-click deploy button is great for static websites and applications early in the development process, but for a number of reasons I don’t think that this is currently a viable option for Bullet Train and that BT devs will be better off simply going the whole 9 yards by setting up everything via Digital Ocean for their Bullet Train.
Here are the reasons why:

You can only make a dev database to experiment with deployment. Upgrading to a production-ready database involves more steps.
You can’t get the DATABASE_URL connection string until after the app successfully deploys. You then grab it from the db settings and set it as an environment variable (in my opinion, Render took care of this better in that you didn’t need to have a successful deployment first).
After you finally set the connection string, THAT’S when you run rake db:migrate in the console. I wanted to automate this step instead of just write it in the console so I asked customer support about it, and they said I needed to use a post-deploy job for this. This isn’t something configured in the deploy template, but in the dashboard. It takes a few steps which can be read in this page in the docs that customer support sent to me.
We usually run bin/dev to spin up multiple processes. In the app platform, which is what one-click deployment uses, each component is one container so we can’t use multiple servers (rails s + sidekiq, etc.). Customer support told me however that this can be done by creating a droplet. If it comes to that, I think Bullet Train devs would just better off configuring a droplet from the start and deploying that way.

I’ve read a bunch of Digital Ocean’s articles in the past and I’m sure their service is great, I just think that trying to use one-click deployment will cause more headaches than anything when a lot else has to be configured just to get things moving. The impression I also get from the one-click docs is that it's used more just to test things out, and not for full-on production.
By the way, here’s the spec I used in the digital-ocean-deployment branch:
spec:
  name: bullet-train
  services:
    - name: web
      git:
        repo_clone_url: https://github.com/gazayas/bullet_train.git
        branch: digital-ocean-deployment
      envs:
        - key: BASE_URL
          # TODO: Replace this with the URL Digital Ocean provides after successfully deploying your application.
          value: http://localhost:3000/
          scope: RUN_AND_BUILD_TIME
        - key: SECRET_KEY_BASE
          scope: RUN_AND_BUILD_TIME
  databases:
    - name: bullet-train-dev
      engine: PG
      production: false

Also, here is the deployed website after attaching the connection string and migrating the database.

@gazayas @andrewculver It sounds like maybe the thing to do here is to provide a page in the /docs area that describes how to deploy to Digital Ocean. Unless things have changed significantly at DO over the last year?

@jagthedrummer I'm open to either solution, thinking back on this one I just remember this being pretty difficult to implement. A lot has changed since then though, so if we want to prioritize it I can take another shot at it.