Freeze when exiting a taglist window

I am using the taglist plugin. I've found a strange issue: when I open a taglist window—with :TlistOpen—and then try closing the whole MacVim window without closing the taglist window separately with :TlistClose, MacVim freezes.
More investigation shows that this apparently innocent line in taglist.vim caused the freeze (commenting it out eliminates the problem):
let &columns= &columns - (g:Tlist_WinWidth + 1)

It looks like bug in MacVim. There is no such problem in, say, gVim for Windows.
I am currently using macvim stable 8.0-134 (bottled) from Homebrew.

@adah1972 Does it still an issue?

I can still reproduce this issue with the latest Homebrew build, version 8.1.1517 (156).

Is it be reproducible with (Mac)Vim from terminal?

No, not in a terminal.
One more important thing: I have just discovered that it happens in the GUI only when I check "Use Core Text Renderer". After unchecking it, the problem goes away.

Thank you, it's a very valuable addition to investigate further.

BTW, it's a quite strange, as I use NERDTree without a problem. Probably it's caused by using outdated features, as this plugin wasn't updated since ... 2013 and Vim changed quite a bit.
I'll investigate how to install it on plugin managers era and will play around

Meanwhile you can play around with tagbar as it seems to be newer with about the same functionality

Still, it is a strange thing that changing &columns about the time of an exit will cause a freeze. Even though taglist is old, what it does seems innocent to me…
Thanks for recommending tagbar. I'll take a look.

I've just tried tagbar. It looks impressive, but it does not change the window width (as taglist does). So there is no way it can trigger a bug like this.
(If I turn off the window width change with let Tlist_Inc_Winwidth=0, taglist will not trigger this bug either.)

Wow! Thank you for an additional discovery to narrow down the reason where bug is triggered!

If there is a way to freeze MacVim this definitely needs to be fixed. Tagging to the next milestone.

Documentation in code says about this variable below. This is common to almost all ViM implementations except for Terminal
    " Increase Vim window width to display vertically split taglist window.
    " For MS-Windows version of Vim running in a MS-DOS window, this must be
    " set to 0 otherwise the system may hang due to a Vim limitation.
    if !exists('Tlist_Inc_Winwidth')
        if (has('win16') || has('win95')) && !has('gui_running')
            let Tlist_Inc_Winwidth = 0
        else
            let Tlist_Inc_Winwidth = 1
        endif
    endif

@ychin This actually do the following, and this is the reason why it is disabled by default.
let &columns= &columns - (g:Tlist_WinWidth + 1)

I can't make it freeze with taglist 4.6 and MacVim 156.

@eirnym Did you turn on "Use Core Text Renderer"? It is triggered only when the Core Text Renderer is used.

yes, I have only "quick start" turned off (see my defaults below) . I've executed the line with various values manually and tried this plugin as well. I use a binary build from GitHub, not from Homebrew.
PS: I've attached this plugin by putting it into new local git repo and used Vim-Plug to import it. I don't remember how to put such plugins in "old way". It'll be helpful to investigate further if you share your configuration which produces the freeze.
A copy of my .vim folder is public (you need to start vim 2 times to attach all plugins)
$ defaults read org.vim.MacVim
{
    MMAutosaveColumns = 84;
    MMAutosaveRows = 52;
    MMCurrentPreferencePane = General;
    MMLastWindowClosedBehavior = 1;
    MMOpenLayout = 4;
    MMRenderer = 1;
    MMTopLeftPoint = "{270, 807}";
    NSNavLastRootDirectory = "~";
    NSNavLastUserSetHideExtensionButtonState = 0;
    NSNavPanelExpandedSizeForOpenMode = "{799, 448}";
    NSNavPanelExpandedSizeForSaveMode = "{712, 448}";
    NSQuotedKeystrokeBinding = "";
    NSRepeatCountBinding = "";
    "NSWindow Frame NSFontPanel" = "929 110 445 237 0 0 1440 877 ";
    "NSWindow Frame SUUpdateAlert" = "650 510 620 392 0 0 1920 1057 ";
    SUCheckAtStartup = 1;
    SUEnableAutomaticChecks = 1;
    SUHasLaunchedBefore = 1;
    SULastCheckTime = "2019-06-24 15:02:42 +0000";
    SUSendProfileInfo = 0;
}

The build (Homebrew) caused the difference? I do not see other significant differences. My OS is High Sierra, BTW.
I did this to test:
cd ~
mv .vimrc .vimrc_bak
mkdir .vim
cp -pr .vim_bak/pack/my/start/taglist/* .vim/

Lauching mvim after doing this, I can still reproduce the problem.

I still can't reproduce. I have to install Homebrew and try the version from it.

My MacVim's feature list, in case it helps:
Huge version with MacVim GUI.


RFC: let-expression

Rendered
Please add a comment in addition to downvote (or upvote existing comments), because comments are more helpful. But feel free to downvote as well ;)

I'm against the now-merged let-else RFC. But this one is even worse in terms of readability.
For example:

// let else else future possiblity
let Some(x) = a else b else c else { return; };

// with let expression
(let Some(x) = a) || (let Some(x) = b) || (let Foo(x) = bar) || { return; };

In a general case, if it's not Option::Some, but Foo instead:
The let-else syntax requires user to figure out Foo in let Foo(x) = a else .. is a Sum type and thus the binding is fallible. (Otherwise else doesn't make any sense.)
But with the new syntax, (let Foo(x) = a) || (let Bar(x) = b) || (let Baz(x) = c) || .., you're gonna process each and every identity on the left hand side of = and they must all be Sum types.
Even worse, this will allow the following readability nightmare:
pub mod XXX {
    pub enum YYY { Foo(i32), Bar(u32) }
	pub struct Baz (i8);
}

use XXX::YYY::*;
use XXX::Baz;

fn nightmare () {
    let (a, b, c) = (Bar(0), Foo(0), Baz(0));

    // Here we go
    (let Foo(x) = a) || (let Bar(x) = b) || (let Baz(x) = c) || { return; };
}

The reader gotta process the entire expression and internalize that the first two bindings may fail, but then, wait, Baz is a Product type and the binding never fail. So there's no need for the { return; } at the end.
This is nowhere being any better for new learners. It's confusing and error-prone.

@lebensterben I don't see your concern. The user can write this today:
if let Baz(x) = c { } else { }

and just get a warning for unreachable code, which is good in my opinion. Irrefutable patterns in let expressions are like x==x and refutable ones are like x==2 and you can use both of them in || and if and similar. I don't see any catastrophic thing in your example and it isn't semantically wrong or meaningless. It just has unreachable code in || { return; } which probably will be removed by a compiler warning, before being read.

Isn't the || operator lazily evaluated? Can the rest of my code rely on a let binding behind a || operator?

It is short circuited but since both side of || must have equal bindings (both in name and type), we can be sure that at least one of them is bound and it doesn't matter which one is. So rest of code can rely on them.

Regarding "let as a bool expression", it's worth noting that this isn't necessarily the only or most obvious thing a let expression might evaluate to.
Expressions like x = 5 (without let) evaluate to ().
In Javascript x = 5 evaluates to 5, and similarly with x := 5 in Python. Though this behavior wouldn't be possible in Rust for non-Copy types.

@ids1024 your point is valid. I added it to drawbacks.

If I submitted something like
(let Some(x) = a) || (let Some(x) = b) || (let Foo(x) = bar) || { return; };

to a code review; it would be rejected as unreadable. Phrases like "keep it simple" would be used. Even if I understand it today, am I going to understand it in six months?
The fact we can introduce this feature is not a justification for including it.

@joew60 What is unclear in your example that you may not understand it in six months?

The fact we can introduce this feature is not a justification for including it.

Certainly. The justification for this RFC is that it unites features like if-let, if-let-chain and let-else, which are known to be useful, in a general and consistent manner, and then get some extra features for free (with no adding to grammar and concepts of the language). At the end there will be some complex usages (which I don't believe your example is among them) that code reviewers can reject.

If I submitted something like
(let Some(x) = a) || (let Some(x) = b) || (let Foo(x) = bar) || { return; };

to a code review; it would be rejected as unreadable. Phrases like "keep it simple" would be used. Even if I understand it today, am I going to understand it in six months?

That's how I feel about most of the examples in the RFC. I think this RFC is too focused on what is theoretically possible instead of what is useful, readable, practical, and realistic. Cramming more logic into a single statement is not an improvement. Code that looks like minified JavaScript is bad code.
I don't feel great about this RFC, but I might consider it more seriously if it had a more practical lens.

@camsteffen I added some practical examples in this section and I probably add some more when I find.

Cramming more logic into a single statement is not an improvement. Code that looks like minified JavaScript is bad code.

This is minified JS: (picked from this page assets)
!function(){"use strict";function e(e){const t=[];for(const o of function(){try{return document.cookie.split(";")}catch(e){return[]}}()){const[n,r]=o.trim().split("=");e=

Is that example really looks like minified JS? What are their similarities? Just because it is in one line, it looks like minified JS? You can put it in multiple lines:
(let Some(x) = a)
|| (let Some(x) = b)
|| (let Foo(x) = bar)
|| { return; };

And the point of this is not count of lines. You can put current alternative in one line as well:
let x = if let Some(x) = a { x } else if let Some(x) = b { x } else if let Foo(x) = bar { x } else { return; };

Or in multiple lines:
let x = if let Some(x) = a {
    x
} else if let Some(x) = b {
    x
} else if let Foo(x) = bar {
    x
} else {
    return;
};

Either way, current solution has unnecessary noise, two times more x, and let expression solution has more cognitive load because it is a new syntax, but it is clear that what it wants to do.
Maybe you can explain your feelings and what you mean from minified JS by some examples.

Maybe you can explain your feelings and what you mean from minified JS by some examples.

JS is a very flexible language and allows you to write very dense code. Perhaps this is a better fit for the goals of JS. But I don't want to dwell on that comparison. The point is that the code is hard to read. That's just my own subjective feeling from looking at the examples.

@camsteffen minified JS is a machine generated and unreadable by design code, Which doesn't related to that examples I think. JS is flexible but you can minify rust as well. Anyway, it is not our discussion, lets move on.

The point is that the code is hard to read. That's just my own subjective feeling from looking at the examples.

Can you please explain your feeling in more details? These questions may help:

Is || inside if scrutinee hard to read? And if so, what is your feeling about existing if-let-chain proposal?
Are ||, && in top level of a block hard to read? If so, does reading them as orelse, andalso like in standard ML make it easier? Problem is chaining them or single || is bad as well? And do you find else in let-else syntax easier to read than || in equivalent statement?
Do () around let makes them hard to read? And changing precedence of operators help?
Are consumed let expressions in places like assert! hard to read and if <expr> { true } else { false } is better?
Are your feeling for real code examples, equal to you feeling about other ones? Real code examples have more context in them and their variables are not single letter, so maybe they are easier to read.

In each case, if it is applicable, please provide which is wrong, for example bindings are unclear, side effects are unclear, ... It isn't necessary and you can simply don't like anything you want.

Using a top level || followed by a block is not necessarily hard to read, but it's definitely surprising because I've personally never seen that in any other language.
To me this:
(let Some(x) = a)
|| (let Some(x) = b)
|| (let Foo(x) = bar)
|| { return; };

is way harder/surprising to read than
if let Some(x) = a || let Some(x) = b || let Foo(x) = bar {
	return;
};

Using a top level || followed by a block is not necessarily hard to read, but it's definitely surprising because I've personally never seen that in any other language.

|| followed by some command or block occurs quite often in bash scripts (and Perl too iirc).

How about adding and_then and or_else method to bool? Then we can write:
(let Some(x) = a)
  .or_else(let Some(x) = b)
  .or_else(let Foo(x) = bar)
  .or_else({ return; });

Which in my opinion is much more clear to read and ergonomic to write with autocomplete.
The only problem I can see is that this may potentially muck with operator precedence and some compiler optimizations.

@changhe3 What's the scope for x then?

@iago-lito The calling scope of course. I don't think function parameters are in their own scope, unless you explicitly use {}.

@changhe3 In this proposal, they are. And for good reason, If you allow function parameters to bind variables, then:
assert!(let Some(x) = foo);
println!("{}", x);

What would be the result of this program?

Do () around let makes them hard to read?

That is maybe the main problem for me. Each set of parenthesis causes me to pause and say "watch out, the operator precedence is being overriden here..." Lots of parenthesis is also a signal to me that factoring in a variable may be helpful for readability. But that isn't an option here. Rust currently enables you to be very conservative with parenthesis and I like that.

And changing precedence of operators help?

I don't think that is really an option? I have an expecation for the operator precedence of pat = x || y.
Another issue is that let is allowed anywhere in an expression. I like that in current Rust, bindings are generally introduced in predictable places - at the beginning of a statement, at the start of a match arm, or in function args. When reading code, the binding names "tell the story". So the readability of a function is highly affected by how quickly I can identify all the binding names defined. With this change, binding declarations are much less prominent.

@camsteffen

I don't think that is really an option? I have an expectation for the operator precedence of pat = x || y.

Your expectation isn't met always, and we changed it once in if-let-chain RFC.
I have a very vague and hacky idea to remove need to parenthesis without breaking change: let pat = x || y only is valid if pat and x and y types are bool. If it is possible to type check x and if it wasn't bool, rotate the parse tree to (let pat = x) || y, the need to parenthesis would be solved. If it isn't possible to change parse tree after type check, we can check if pat is a bool pattern without type checking, it should have format of ident, true, ident @ false, and | combination of this things, so it should be easy to detect it by parse level information. If we find that pat surely is not a bool pattern, we can rotate the parse tree. Negative point of the latter is that false positives like ident is possible and it still mandate parenthesis for let ident = x && y which x can be not bool, but it is better than mandating parenthesis everywhere. (Note that (let ident = x) || y is non sense and y is unreachable here.) With both solutions, there is no breaking change.
I don't know if this level of context sensitivity is feasible, and if something like this is done before, but if it is ok, (or ok with changes) let me know to put this in RFC. If it isn't, I should add parenthesis to drawbacks.

at the beginning of a statement, at the start of a match arm, or in function args

And macros. If the problem here is possibility of creating a mess, macros can do that very better, but if concern is that people accidentally make an unclear binding statement that make problem for code readers, I claim that 98% of meaningful binding statements have let at the beginning (or ((let) and it can be forced by lint, so you can keep looking at beginning of the statements for discovering bindings.

@fee1-dead

Do new learners actually expect let to be a bool expression?

I personally would expect that.
@camsteffen

I don't feel great about this RFC, but I might consider it more seriously if it had a more practical lens.

I don't understand the intricacies here, but as a +1: I would definitely find it nice to be able to write:
if let Some(x) = self.some_func() && let Some(y) = self.other_func() {}

instead of having now to do
if let Some(x) = self.some_func() {
    if let Some(y) = self.other_func() {}
}

It would reduce the number of braces, which is objectively better.
I realize this is possible sometimes, but it's not as readable
if let (Some(x), Some(y)) = (self.some_func(), self.other_func()) {}

It's not possible when the output of some_func needs to be piped into other_func. The workaround being:
if let Some((x, Some(y)) = self.some_func().map(|x| (x, self.other_func(x))) {}

I feel like that should be a default clippy warning. It's bad style, but imo shouldn't block this feature.

as a +1: I would definitely find it nice to be able to write

That is not something coming from this RFC, see if-let-chains which is already an accepted RFC.

I made some changes:

! operator removed from this RFC so binding rules are now much less complex.
With changes proposed to parser, need for () is eliminated in most cases.
Assignment bools with bindings now require explicit discarding by {}

Found it strange that you couldn't chain if lets when I was learning Rust. I think this would make the language more consistent and easier to teach. But this is something that I think 95% of people would only use inside ifs or while loops.

Just to be clear, does this code block guarantee that b() is always called or does the RFC allow an early return if a() returns Some(x)?
if let Some(x) = a() || let Some(x) = b() {
  //...
}

@nielsle It does not guarantee that b() is called. || is short-circuiting. Just like when you do a() || b().

@pYtoner

But this is something that I think 95% of people would only use inside ifs or while loops.

let-else (that is, let Some(x) = y || break; in top-level) is also believed to be useful.

I posted a comment on this in a subthread on a particular chunk of code, but I want to bring it up to the top level:
https://github.com/rust-lang/rfcs/pull/3159#discussion_r693414879
I find let-else to be a specific contained construct, simplifying a very common code pattern (match this pattern or bail out if it doesn't match).
Similarly, I find if-let chaining to be a specific contained construct, matching several things in a row without nesting, simplifying a common pattern.
This, on the other hand, feels like the wrong side of the tradeoffs between expressiveness and readability, and I think it's a rare example of language orthogonality taken too far. Normally, I'm very much in favor of orthogonality, and of general constructs that cover many different cases with the same mechanism. However, I don't think let matching should be a general boolean construct like this. I think the kind of code enabled by this that isn't enabled by let-else or if-let chaining is not code we want to enable. Every example of it in this RFC seems less readable than the equivalent way of expressing it without this construct.
I really appreciate the look at what a fully orthogonal construct could look like. But I don't think we should do this.

@rfcbot close

@joshtriplett We could talk more about what's useless and what's not and remove the useless parts.
Anyway, even if you closed this, consider using || instead of else in let-else (smallest subset of this RFC) before stabilization of let-else. It can be memoized as a special syntax, like original let-else. else in let-else will add another dimension to the language, which can (and will, let it go in the wild) extended in that dimension (things like let-else-else or let-let-else) and if-let will be extended too, so result would be inconsistency and double constructs for same thing. On the other hand let-|| keeps the doors open and its extensions (if needed) can naturally fill the gap between it and if-let.

@HKalbasi I didn't say "useless", and I genuinely appreciate you writing this up. I can see the expressive power of this construct. I'm suggesting that the potential for confusion outweighs that expressive power.

consider using || instead of else in let-else

There were long discussions in the let-else RFC thread already about what syntax should be used. else was chosen for many reasons, among them familiarity and understanding and readability.

and if-let will be extended too, so result would be inconsistency and double constructs for same thing

let-else and if-let serve different functions. let-else handles cases where you expect to successfully bind something with a pattern, and you want to bail if it doesn't match; after the let-else statement, the variable is bound. if-let handles cases where you might bind something but you want to handle both paths; after the if-let statement, the variable is no longer bound.

things like let-else-else or let-let-else

I personally find let-else-else confusing and excessively terse, and I don't plan to support it.
The idea of "let-let-else" sounds more appealing, though, and raises a useful possibility:
let Variant(x) = expr
else let OtherVariant(x) = other_expr
else {
    diverge
}

That generalizes nicely: you can use the same pattern multiple times if you want to match it against multiple expressions, but you can also match a different pattern to a different expression as long as it binds the same variables. That seems much clearer than || or any of the examples given in this proposal.

There were long discussions in the let-else RFC thread already about what syntax should be used. else was chosen for many reasons, among them familiarity and understanding and readability.

I read that thread more or less, there was a strange proposal around || which changes the meaning of operator and I didn't understand. If we put that aside and stick to single else construct, let-else and let-|| just differs in one keyword, which even reads the same (else vs or-else) and I can't see how it can have major effect on familiarity and understanding and readability. If I wasn't aware of this RFC, I would consider let-else and let-|| as really equal and arguing for one over another as bike-shedding. (and I can give bike-shedding reasons in favor of ||, e.g. familiarity for other languages such as bash which use this for same propose, or else without if (or while) doesn't exist in any language I'm aware of). If there is specific comment in this thread or a reason against || that I'm not aware, please tell it.

let-else and if-let serve different functions. let-else handles cases where you expect to successfully bind something with a pattern, and you want to bail if it doesn't match; after the let-else statement, the variable is bound. if-let handles cases where you might bind something but you want to handle both paths; after the if-let statement, the variable is no longer bound.

They can enter another territories. Consider in future we see duplicate else blocks in consecutive let-else, so we come with something like let Some(x) = y, let Some(z) = foo(x) else { diverge }; but meanwhile in if-let-chain we do the same chaining with && instead of ,. Same can happen with let-elselet-else and || counterpart of if-let-chain.

That seems much clearer than || or any of the examples given in this proposal.

I don't see how it really differs in clearness with this:
let Variant(x) = expr
|| let OtherVariant(x) = other_expr
|| {
    diverge
}

they just differs in a keyword, I see their difference equal to difference of raise and fail.

Keep in mind that in other languages || is generally only used as an operator for booleans, while else is used with ifs. One should not be expected to read || as "or-else", because I simply read it as "or" and nothing "else". :)
For newcomers they might be able to understand better if it was else, since they might previously know ||'s role as an operator.

Keep in mind that in other languages || is generally only used as an operator for booleans, while else is used with ifs.

So both are bad, until we make let a bool expression or an if statement.

One should not be expected to read || as "or-else", because I simply read it as "or" and nothing "else". :)

It can be advertised as so. || is short circuiting in all languages, and it can be explained why it should read as or-else from some short circuiting examples of normal bools in rust.

For newcomers they might be able to understand better if it was else, since they might previously know ||'s role as an operator.

I think they have very little difference, (and which is better is arguable) so places where people learn language features (learning texts and compiler errors) have more important rule than what the keyword actually is.

It can be advertised as so. || is short circuiting in all languages, and it can be explained why it should read as or-else from some short circuiting examples of normal bools in rust.

I am sorry that I have to disagree here. The argument is not about whether it can be explained, but about whether it will be straight-forward and easy to learn for beginners. || is widely understood as logical OR, and I don't know if there are people, when they first learn about ||, thinks about it as or-else. And there is something about that: else precedes behavior. "if this condition is met, do this, or else do that".

OP said:

The reasoning here is, new learners when see if let, expect that let should behave like a bool expression (like anything else inside if scrutinee)

We need to make it clear that if let is not simply putting two keywords if and let next to each other, but rather itself is a keyword.
In the previous version of this PR, OP expressed that if let seems random, while someone mentioned it's inspired by if let in swift. But it's worth mentioning this appears in LISP before Swift.
In LISP, if-let is a macro that expands to a if clause nested in a let clause.
For example, the following if-let form
(if-let ((foo (computation-1))
         (bar (computation-2)))
    (then-clause)
  (else-clause))

is equivalent to the common pattern
(let ((foo (and t (computation-1)))
      (bar (and (computation-2) foo)))
  (if bar
      (then-clause)
    (else-clause))

The then-clause is evaluated only if all local bindings evaluates to non-nil value.
It's critical to understand that LISP doesn't have algebraic data type, and nil acts as both false and None in Rust. (while t acts as both true and Some(T))
So the if form of LISP IS NOT a conditional control flow on a Boolean!
It's rather testing whether there's any value at all.
We can transcribe the above LISP codes in Rust:
if let Some(foo) = computation_one() {
    if let Some(bar) = computation_two() {
        return /*then clause*/;
    }
}
return /*else clause*/;

and
let foo = computation_one();
let bar = foo.and(computation_two());
if bar.is_some() {
  // uncomment if either `foo` and `bar` is used in computation
  // let foo = foo.unwrap();
  // let bar = bar.unwrap();
  return /* then clause*/;
}
return /* else clause*/;

Though this is not the actual implementation of if let in Rust, but we can see that there's not any resemblance of the binding form in if-let to a Boolean value.

@fee1-dead

|| is widely understood as logical OR, And there is something about that: else precedes behavior. "if this condition is met, do this, or else do that".

Logical OR is |. And || can interpreted the same as long as their observable behavior is equal (i.e. when conditions don't have side effect) in precedence of side effect, c1 | c2 is check c1, check c2, check logical or of results and c1 || c2 is check c1 or else check c2 (so don't check c2 in case of c1). I'm not the one who invented or-else for calling ||, it exists because logical OR doesn't explain all aspects of ||.

but about whether it will be straight-forward and easy to learn for beginners.

I can see people may become surprised if they are not familiar with short circuiting behavior of ||. My point here is that difference is not much. There will be a sugar in language (until possible generalizations) let pat = expr xxxx { diverge; } and it really doesn't matter what is xxxx. This is a sugar, would become let bindings = if let ..., and even very bad choices like | and or doesn't affect learning much (while it is a sugar in current state, a choice can considerably harm or benefit future generalizations). And on the other hand there are many programmers familiar with short circuiting behavior (I said bash sometimes in this thread, another example is JS, they even added another short circuit operator ?? and this is popular there), but else without if isn't in any language. So there are small costs and small benefits, so difference is very small and I say sacrifice this very small (positive or negative) for future consistency with if-let-chain proposal, which validly can be said that it is even smaller, worthless, or even negative, but IMO is big, at least for considering it one more time before stabilization of let-else.

@lebensterben How do you see the if-let-chain proposal? How it will play with your if-let keyword view?
I can see another good choice in favor of consistency: remove if-let-chain RFC instead of let-else. And if I understand correctly, this is what @lebensterben suggests.

@HKalbasi
As I said in my first comment, I'm against if-else and even more against this PR.

@kennytm

With #2497 the above can be translated like this, where if and let are two separated keywords.

I'd say this
if bar() && let Some(h) = g && let Some(i) = h && foo() && Foo::A(b) = i {
    dbg!(b);
}

is merely a sugar of
if bar() && if let Some(h) = g && if let Some(i) = h && foo() && Foo::A(b) = i {
    dbg!(b);
}

Just as
if foo() && bar() && baz() {
	/* .. */
}

is sugar of
if foo() {
   if bar() {
       if baz() {
           /* .. */
       }
   }
}

And if let /= if + let

@kennytm
if-let expression is never said to be a combination of if expression and let expression.
See: https://doc.rust-lang.org/nightly/reference/expressions/if-expr.html#if-let-expressions

@joshtriplett I feel like you haven't really addressed the points made in the RFC.
That is, I'm missing the following:
Why is a specific contained construct for let/else more important than consistency?
The point about let/else + let chains being confusing due to not having a consistent mental model rings true to me.
I'd find this RFC a lot easier to explain than having to explain let/else and let chains as being 2 different things that look similar but are completely different things.
In general, I'm concerned that both let/else, let chains, and this PR don't pull their weight, but if we want to do extensions here, this feels like the most understandable.

@lebensterben

the reference does not include unstable features, and thus you can't see the effect of #2497.
whether if let/while let are one or two keywords is not a consideration whether this RFC should be closed or not, since orthogonality is not the deciding factor here (https://github.com/rust-lang/rfcs/pull/3159#issuecomment-903189180).

and we're getting off-topic, let's stop here.

@kennytm
Please point out where does #2497 mentioned anything that if let is if plus let.
Actually the very PR illustrated that if-let-chain is indeed the sugar I described above.
See https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md#plenty-of-real-world-use-cases
This comment https://github.com/rust-lang/rfcs/pull/3159#issuecomment-903189180 indeed mentioned orthogonality is not the reason why it's proposed to close this PR. But what I said is that this PR is based on misconception and doesn't improve orthogonality at all.

@samlh

I'd find this RFC a lot easier to explain than having to explain let/else and let chains as being 2 different things that look similar but are completely different things.

The scoping rule in this RFC is very hard to learn besides those important special cases, and that's enough for me to :-1: it.
In #2497 (if let chain) it is very simple, a binding in the condition is visible in the later conditions and inside the then clause, and all bindings do not exist in the else clause and outside of the if statement.
In #3137 (let else) it is also very simple, a binding does not exist in the else clause (required to be diverging) and visible below the let/else statement.
(we also have rust-lang/rust#65479 matches!() which never leaks the binding out.)
This RFC intends to support both use cases of #2497 and #3137, and thus introduced some rather elaborated desugaring rules requiring analyzing every &&, ||, !, if, while and prove of divergence ("provably_unreachable!()") to know if a binding will be in-scope. Proving divergence requires type-checking, so now whether a variable is in scope depends on the type-checking result of the previous statements. But type-inference requires information from the entire function scope. So, I don't know, how are you going to convincingly teach the compiler which z are being shadowed or unused, and what should be the type of m?
let mut m = Vec::new();
let z = Some(Some(Some(Some(Some(12345)))));
(let Some(z) = z) || mystery_function_1(&m);
(let Some(z) = z) || mystery_function_2(&m);
(let Some(z) = z) || mystery_function_3(&m);
(let Some(z) = z) || mystery_function_4(&m);
(let Some(z) = z) || mystery_function_5(&m);
m.push(z);

@kennytm Fair enough, you've convinced me :)

@kennytm Your example doesn't compile in terms of this RFC, because mystery_function_1(&m) doesn't contains z, and because compiler can't proof (let Some(z) = z) || mystery_function_1(&m) is always true. So binding rules are clear (bring counter proof), if you see a variable in toplevel, it will bound surely at same line. That is, let Some(x) = y || ... will bound x in this line (maybe x filled inside ...) and won't shadow x, regardless of what ... is.

@HKalbasi
fn mystery_function_1<T>(_: &T) -> ! {
    panic!();
}

Also I thought not containing z is the entire point of the RHS of ||? Taking the example from the RFC:
(let Some(x) = foo) || panic!("foo is none");  // `panic!("foo is none")` contains no `foo` or `x`.
println!("{}", x);

@kennytm Hm, but the logic to fail compilation if the expression fails to diverge does seem to answer your question:

Proving divergence requires type-checking, so now whether a variable is in scope depends on the type-checking result of the previous statements. But type-inference requires information from the entire function scope. So, I don't know, how are you going to convincingly teach the compiler which z are being shadowed or unused, and what should be the type of m?

Assuming divergence and double-checking later does solve that issue. The answer for the example you gave is thus that z is always in scope, and m is always a number.
I'm still in agreement that it is hard to explain, and that this is a bad idea, but your example does have a specified result :).

On Mon, Aug 23, 2021 at 01:37:59PM -0700, HKalbasi wrote:

@fee1-dead

|| is widely understood as logical OR, And there is something about that: else precedes behavior. "if this condition is met, do this, or else do that".

Logical OR is |.

| is bitwise OR, not logical OR. || is logical OR.

I'm not the one who invented or-else for calling ||, it exists because logical OR doesn't explain all aspects of ||.

Logical OR does explain all aspects of ||: if the first expression is
false, the whole expression can't possibly be true, so there's no point
in evaluating the second expression.
More importantly: it feels like you have a very specific conception of
how people "should" read ||, and you're looking to educate people to
accept your interpretation. In general, we try to make it our very last
resort to present something unusual and just ask people to memorize and
go with it. Any time we can leverage people's existing understanding,
intuition, experience, or similar, we will often prefer to do so.
In that regard: nobody is arguing that it's not possible to use ||
in the way you're proposing. However, I believe (and it appears that
others do as well) that else will align better with people's
exising intuition and experience.
 I don't think we should, however.

but about whether it will be straight-forward and easy to learn for beginners.

I can see people may become surprised if they are not familiar with short circuiting behavior of ||.

It's possible to be familiar with the short-circuiting behavior of
||, and still find it awkward to use for control flow. It feels more
like the territory of C *x++ = *y++, or Perl one-liners; it doesn't
feel like Rust, at least to me. It feels like a construct that puts more
priority on having a single language construct and making it work for
everything, and less priority on making code easy to read and
understand.

There will be a sugar in language (until possible generalizations) let pat = expr xxxx { diverge; } and it really doesn't matter what is xxxx.

It does matter, though. The syntax we use becomes part of people's
models and intuitions, and else there feels like it forms part of a
consistent languge model. || doesn't feel like as good of a fit.
(There are things that would fit even worse, such as => or !, but
I feel that else fits better than || in this context.)

else without if isn't in any language

Python has for-else and try-else, Ruby has begin-rescue-else, and
several languages have unless-else. There's a common meaning for else
in all of those constructs, in addition to if-else.

if mystery_function_* is diverging, your example is equivalent to this:
(let Some(z) = z) else { mystery_function_1(&m); };
(let Some(z) = z) else { mystery_function_2(&m); };
(let Some(z) = z) else { mystery_function_3(&m); };
(let Some(z) = z) else { mystery_function_4(&m); };
(let Some(z) = z) else { mystery_function_5(&m); };
m.push(z);

How you see problem (and what is the problem you see) with this RFC but not with let-else?

Also I thought not containing z is the entire point of the RHS of ||?

It is not exception of RHS, but exception of diverging values. You can imagine diverging branch add a hidden z which will be in the scope for the result of function (which we won't see after diverge)

@HKalbasi What if mystery_function_2() returns a bool and not diverge? What if the divergence of mystery_function_3() depends on the type of m?
trait Q { type A; fn a(&self) -> Self::A; }
impl Q for Vec<i32> { type A = !; }
impl Q for Vec<Option<i32>> { type A = bool; }
impl Q for Vec<Option<Option<i32>>> { type A = !; }
...
fn mystery_function_3<T: Q>(q: &T) -> T::A {
    q.a()
}

How you see problem (and what is the problem you see) with this RFC but not with let-else?

In let-else we know for sure, before type-checking, that all z are shadowing, because the else clause is guaranteed to diverge.
There is no such guarantee in this RFC, (let Some(z) = z) || BOOL_VALUE; is a valid expression statement (which does nothing).

@kennytm

There is no such guarantee in this RFC, (let Some(z) = z) || BOOL_VALUE; is a valid expression statement (which does nothing).

Not true:

If we combine two let expressions via ||, their bindings should be equal, otherwise we will get a compile error.

This example seems wrong, unless I’m misunderstanding something

A more complex example in this category from sentry-cli:
if let Ok(var) = env::var("SENTRY_DISABLE_UPDATE_CHECK") {
    &var == "1" || &var == "true"
} else if let Some(val) = self.ini.get_from(Some("update"), "disable_check") {
    val == "true"
} else {
    false
}

Which can become:
{ let Ok(var) = env::var("SENTRY_DISABLE_UPDATE_CHECK") && (&var == "1" || &var == "true") }
|| { let Some(val) = self.ini.get_from(Some("update"), "disable_check") && val == "true" }

Wouldn’t the “translation” be behaving differently if &var == "1" || &var == "true" evaluates to false?

@joshtriplett Thanks for your detailed comment. I can answer to some parts but I want to focus on my main point.

It does matter, though. The syntax we use becomes part of people's
models and intuitions, and else there feels like it forms part of a
consistent languge model. || doesn't feel like as good of a fit.
(There are things that would fit even worse, such as => or !, but
I feel that else fits better than || in this context.)

All of my point is: if that amount of better-ness is more important than consistency between let-else like construct
and if-let-chain like construct (and even consistency between if and if-let and if-let-chain by making let a bool expression) then everything seems ok. We will get a better and meaningful keyword, with cost of losing and forgetting let-expression as a bool forever, a concept predates to if-let-chain (see Centril's comments in this thread about let expressions, when let-else was a postponed and unknown proposal).
They are hard to compare, because they are different type of costs. But I like to see your reasoning here. To make things easier to compare, what will you decide in these scenarios? :

Imagine if-let-chain RFC proposed a let-expression RFC like this one, but no one used let-else style of it. Then a let-else RFC comes in and you would realize that by replacing else with ||, it becomes a existing (but unpopular because it isn't rusty) thing in current language. Then would let-else still deserve a new keyword with better meanings?
Now imagine a weaker let-expression RFC proposed by if-let-chain, which only allows && and || inside if or consuming as bool, and doesn't unifies with let statements. Now a let-else RFC would come in, would you still choose else over ||?

These aren't impossible, due the fact that people (like centril I mentioned above) was aware of let-expression. If your answers is consistent and you always choose else over ||, it shows that a special keyword for this construct with better meanings worth it costs, but otherwise I doubt there is a strong benefit for else over || in let-else but you can explain what is the difference that change decision to a non-optimal one.

@kennytm

There is no such guarantee in this RFC, (let Some(z) = z) || BOOL_VALUE; is a valid expression statement (which does nothing).

It is valid as long as BOOL_VALUE binds z, or diverge. So there is a guarantee that this statement shadows z if compiles.

@steffahn good catch, seems it is a common pitfall. I will update the example.

In the lang meeting today, Josh pointed out that https://github.com/rust-lang/rust/issues/53667 has a checkbox for thinking about syntax -- and thus things like this -- as part of stabilization for that.  So I think I agree with looking at how if-let-chaining goes further before considering this more.

@scottmcm It is ok to put thinking on this kind of thing on the time of stabilization for if-let-chain and let-else, but let-else seems is intentionally not mentioned. From meeting note:

Josh: I don’t think this should be a blocker for let/else, since if we introduce an is syntax, it wouldn’t affect let/else.

So it should be a blocker until we declare that we want is syntax instead of the current one for if-let-chain. Right? Before that, they are intertwined because both use let.
And as a general comment about is: I see is expression for if and while and let statement for top-level bindings a good and meaningful separation, but what will happen to if let? It will become deprecated?

The examples in this RFC are very unconvincing. There are barely less symbols and barely less rightward drift in the proposed versions compared to the current macro-based ones. I won't bash at the problems already mentioned, but I can't help but note that the problems have more idiomatic solutions.
This example
let Some(x) = foo() && let Some(y) = bar(x) && f(y)

can be rewritten much more cleanly and idiomatically using try operator:
let x = foo()?;
let y = bar(x)?;
f(y)

The only problem is that it doesn't work locally since the try operator always returns from the containing function. We may want to postpone returning, and the function may not even return an Option<T> as required to use ?. However, this problem will be fixed more idiomatically with try blocks:
try {
    let x = foo()?;
    let y = bar(x)?;
    f(y)
}

Done! Very clean, very readable, doesn't require to mess with the enclosing function. In current stable Rust one can use option-returning closures instead of try blocks, which are less ergonomic, but still a net win if you're doing a lot of matching:
let opt_chain = {
    let x = foo()?;
    let y = bar(x)?;
    let z = quux(y)?;
    Some(f(z))
};
if let Some(t) = opt_chain() {
    // do stuff
}

The || operator cannot be represented this way, however since the produced bindings must be the same with the same bound type, we can just compose a few options:
if let Some(t) = foo().or_else(|| bar()).or_else(|| quux()) {
    // do stuff
}

Sure, it's less readable than composition via ||, but not significantly so, and as a benefit there is no confusion about binding semantics. Perhaps Rust could, like Python, introduce || operator on Options with the semantics of or_else-chaining, but the consensus seems to be against that feature. If you're doing this stuff a lot, you can write a simple macro to simplify those expressions:
macro_rules! option_or {
    ($e: expr $(, $es: expr)* $(,)?) => {
        $e $( .or_else(|| $es) )*
    };
}

if let Some(true) = option_or!(foo(), bar(), quux()) {
    //do stuff
}

Finally, there is stuff about bindings for arbitrary sum types. Again, this case is easily solved by a macro, together with the techniques above:
macro_rules! option_or {
    ($e: expr $(, $es: expr)* $(,)?) => {
        $e $( .or_else(|| $es) )*
    };
}

macro_rules! bind {
    ( $($ident: ident),+ , $pat: pat = $expr: expr) => {
        #[allow(unused_parens)]
        if let $pat = $expr { Some(( $($ident),+ )) } else { None }
    };
}

enum Foo {
    T(bool),
    H { y: u32, g: bool },
    F
}
struct Bar { f1: u32, f2: bool }

let x = bind!(x, Foo::T(x) = foo())?;
if let Some((n, b)) = option_or!(
    bind!(y, g, Foo::H { y, g } = baz(x)),
    bind!(f1, f2, Bar { f1, f2 } = bar(x)),
) {
    // do stuff with `n: u32, b: bool`
}

One could probably write an even more nice looking bind! macro as a procedural rather than declarative macro.
The techniques above compose seamlessly, don't require any modification to the base language or parsing rules, and don't introduce any potential ambiguities with respect to binding scope and order. They are a bit less readable, but imho not significantly so, and not enough to outweigh the benefits. These patterns also don't look like something which should be very common in most of the projects (syntax analysis and compilers are a different case, of course).
The main downside is that the compiler can't give good error messages for macros, unlike built-in let-expressions. However, this is outweighed by the fact that someone would first need to implement all that extra analysis and syntax-awareness. The macros are also quite simple and well-scoped, which should limit any possible confusion.

My first comment ever in any Rust discussion! As someone who works with Rust and Swift daily I am interested in the outcome of this discussion. I am mostly interested in two use cases I have encountered in the code.

In Swift there is guard let which I use all the time. Statement like this:

guard let value = result else {
    return 0
}
// value is in scope.

This is described as something that helps with the indentation but I find that it actually simplifies how I reson about that code.
In stable Rust I don't know how to express this without nesting. So two options I can think of are either:

Introduce new expression—guard expression like Swift.
Beef up existing if let expression to allow negation, like:

if !let EnumKind(value) == result {
    return 0;
}
// value is in scope.

I find the latter more familiar.

In Swift you can chain let expressions like this:

while let next = lines.peek(),
   let nextTag = next.split(separator: "=", maxSplits: 1, ommitingEmpty: false).first,
   tagSet.contains(nextTag) {
   result += lines.next()
}

Notice the use of comma as the separator. It makes it obvious what order the bindings happen at and that conjunction is the only option. The reson this construct is useful is only because you can use the binding from one expression in the following expressions. In Rust without #![feature(let_chains)] I feel the urge to write something like this:
while let Some(true) = lines.peek().map(|next| match next.split_once("=") {
    Some((next_tag, _)) => tag_set.contains(next_tag),
    _ => false,
}) {
    result.push_str(lines.next().unwrap());
}

My experience with large Javascript codebases is that we want to steer clear of this.
Now in Rust with #![feature(let_chains)] we can do this:
while let Some(next) = lines.peek() &&
      let Some((next_tag, _)) = next.split_once("=") &&
      tag_set.contains(next_tag) {
    result.push_str(next);
    lines.next();
}

We're introducing && which looks like a well-known, short-circuiting Boolean operator. But it's not, because there is no ! and ||. Sucks because in the non-let subexpressions you can use both of them. I get a pause each time I write something like
if a || b && let Some(value) = value { }

Which doesn't compile. But these do:
if (a || b) && let Some(value) = value { }

if a || b && c { }

I find this janky and confusing. I see two directions that are easy to defend:

Go the Swift way, don't mix Boolean logic and chained bindings and introduce new statements. This works well in Swift, it removes expressivity and nudges towards The Right Path which I find to be a good thing as Rust doesn't need more complexity. I like the try statement for its own merits although you can't introduce two bindings with it, nor zero, so it doesn't help with the example above. I think macro solutions are inferior for the same reason I think e.g. C coroutines implemented with the preprocessor are a horror show.

Implement full Boolean logic for let bindings and deal with the order of operations. We're not introducing a new mental model but using Boolean algebra so I actually see this as a simplification of things and this simplification is the only reason why I think it's a good idea. I haven't seen any arguments against that can't be solved with "unused variable"/"condition is always true" warnings, and on the other hand I am not aware of any language that implements this so I've got the fear. But now that we're half way there with #![feature(let_chains)], not even trying it out feels weird.

Maybe the next step is to try a prototype of this RFC and then decide between let expressions which I see as the logical continuation of #![feature(let_chains)] or a completely different approach? I don't want this to come out as "that's a great 20% project" kind of comment—can I help somehow? Does this RFC have a champion in the compiler team or maybe a WIP PoC implementation?


ALGO_PRIDU: scale step size by maximum eigenvalue (closes #128)

Hm. It seems wrong that the scaling is used here... Inititial scaling of the data should have no direct effect on the algorithm and its purpose is to make regularization which depends on the scaling of the data more robust. But I do not see why the parameters of the algorithm are changed based on this.
And couldn't the sigma be identified with 'step' ? Then we could get rid of the special logic....

I think this is addressed now with using 'step'.


Releasing 3.0.1

This time not using sbt release, just for giggles.

By the way, the rationale for just bumping the patch number is that this is not new API. The equivalent request did work in 2.3.3; the bug was a regression in 3.0.0. Fixing the bug just makes the existing API work correctly.

LGTM. I don't even know if it's useful to wait for the travis PR build... Anyway, will merge once that is green unless someone else gets to it first.

Agreed, With no code changes, what could go wrong? Merging.


Consider clear command

The clear command should take a sheet title and a special keyword (e.g., data-validation or something like that). Then, it will clear all "applied" attributes from the sheet. I think the keywords we want to support are:

formats
data-validation (or rules?)
notes

For example: cogs clear [keyword] -t [sheet-title] or alternatively cogs clear -t [sheet-title] -k [keyword]. I'm not sure which makes more sense.
Let me know if I missed anything.

We could overload cogs apply with this functionality, but I like a distinct cogs clear better. There should also be an "all" keyword. And it should be possible to clear all sheets.


integrate the pull-to-refresh with section-list-view

integrate section-list-view, like [http://jsharkey.org/blog/2008/08/18/separating-lists-with-headers-in-android-09/],
and the pull-to-refresh list.
Sample also add the header-view to the list.

Thanks for this but it's really anything to do with Pull-to-Refresh. If you want to do this I'd recommend using MergeAdapter which uses a standard ListView (therefore you can use the normal PullToRefreshListView).


Namespace Support

Tilt should have build in support for setting a Kubernetes namespace that all objects get created in for the duration of the session.
Tiltfile syntax could look like this:
set_namespace("dan-dev")

Tilt would remember the namespace that you specify and append it as a command line flag every time it invokes kubectl.

For now, I am using the following
def set_namespace(namespace):
  command = 'kubectl config set-context $(kubectl config current-context) --namespace=%s' % (namespace)
  current_context = str(local(command)).rstrip('\n')

def set_context(context, namespace=''):
  command = 'kubectl config use-context %s' % (context)
  current_context = str(local(command)).rstrip('\n')
  if namespace:
    set_namespace(namespace)

set_context('docker-for-desktop')
# set_context('docker-for-desktop', 'dev')
set_namespace('dev')

@jazzdan : Would it make sense for that command set_namespace, to create the namespace if it didn’t already exist? See https://kubernetes.slack.com/archives/CESBL84MV/p1589465928081300?thread_ts=1589454049.073200&channel=CESBL84MV&message_ts=1589465928.081300

@victorwuky yup I think that could make sense.

When has a tool that sets a setting every created it?
What would happen if kubens created the namespace for every typo that a user typed?
These should be seperate functions/commands  Linux philosophy here do one thing and one thing well. If people want the namespace they could use a create_namespace
Just for the record I would love to tilt to be able to create namespaces but I would hate it creating namespaces for me when I am trying to set the namespace/context.


Feature Request: Add/Remove components, access Entities

One thing I've see a lot in other ECS implementations is the ability to add or remove components from entities as they flow through systems. Some examples include removing movement components to freeze entities, adding "hostile" components to make entities attackable/aggressive, placing and removing debuffs from targets, etc.
But I can't see any simple way to do this with EgoCS. This wouldn't inherently be such a big deal, except that I also can't see any way to get a component's Entity (GameObject), which I could have used to addComponents to...
For the project I'm working on now, these things are kind of crucial.

Please see this page on the wiki.


Change field names from lower case to upper case everywhere

In the CDM workgroup the convention has changed: field names now must be written in UPPER CASE. We want to be consistent in the book, but so far we've followed the old convention.

Fixed here: https://github.com/OHDSI/TheBookOfOhdsi/pull/62


Update index.markdown learn more about OP_RETURN - link to the Bitcoi…

…n Explained episode

Thank you for your contribution.


feat(pinch): allow modifierkey to be an array

Allow specifying multiple modifier keys to trigger pinching when using wheel, so you can scale using for example ctrlKey and metaKey

@BJvdA Thanks a lot for this and sorry for the very late reply.
Should also help #624


added manual publish for preview

Could this work? When I need a package to test a new feature on poc site.
I dont want to merge in main because it is not finished. So I could merge in "preview" and give it a tag like "preview-version" and then use it for the poc.
What do you think?

Could this work? When I need a package to test a new feature on poc site. I dont want to merge in main because it is not finished. So I could merge in "preview" and give it a tag like "preview-version" and then use it for the poc.
What do you think?

Yes, it will work, but we do not need another workflow for this we just need to mention the other branch name in the publish.yaml that we already have

Added preview branch to existing yml. So like this?

Added preview branch to existing yml. So like this?

Yes it should work, Also It would be great to test and ensure if it works perfectly.


How to do hyperparameter optimization?

❓ Questions and Help
I would like to do try out different hyperparameters and compare their performance for the NMT example.
There are libraries like the Hyperopt library for tuning.
I would be interested to know is there a programmatic way to try out automated hyperparameter tuning option. Any ideas welcome.

For hyperparameter tuning, please refer to issue #553, thank you for your feedback.


[BUG] Failing test cases

Library name and version
Azure.ResourceManager.DataShare
Describe the bug
2 test cases are failing in main https://dev.azure.com/azure-sdk/public/_build/results?buildId=2753824&view=logs&j=5c1c6b8d-4c43-56d0-23a6-720b383b6e9d&t=c0689a97-7641-5aa2-9bbf-6a4650990a4c&l=406
Expected behavior
expected that they don't fail :-)
Actual behavior
They fail
Reproduction Steps
See linked pipeline
Environment
No response

Same issue is happening here in automation: https://dev.azure.com/azure-sdk/public/_build/results?buildId=2755940&view=logs&j=43780012-0f03-502d-9415-dae360b050f8&t=58b36873-ee18-54a8-1e91-f99aabccf378


BUG: Reloading / Load More function disabled when unable to find notes in one subject, even when others are selected.

When filtering for specific notes, sometimes the program is unable to retrieve any, whether due to networking issues or simply because of the lack of notes in that section. However, when this happens the reload button does not work, instead becoming greyed out and nonresponsive, even when other sections are selected. This necessitates a webpage reload.

Clear the filter button and press filter - does that fix?

The button stays greyed-out still.


Fix inconsistency and misinformation in gddocs

The download link for the music library song is supposed to be .ogg not .mp3. I've changed it to avoid any other confusion.
I've also add some minor details in resources/levels.md and added NCS guantlets.
And fixed getGJLevelLists.php mistaken as levels.

Btw, to make the ncs gauntelts "appear" from the server response you need to include the BINARY_VERSION, I haven't checked if you need the 2.206's binary version or if it just accepts anything
NCS gauntlets:
BINARY_VERSION = 46
def get_raw_gauntlets(self, get21gauntlet=False) -> str:
    '''
    Return a list of raw Gauntlets
    '''
    data = {
"secret": COMMON_SECRET,
"special": 1,
"binaryVersion": BINARY_VERSION # Used for the NCS Gautlets (for some reasons)
}
    if get21gauntlet:
        data["special"] = 0

    req = requests.post(ROOTURL + "database/getGJGauntlets21.php", data=data, headers=HEADERS)
    return req.text

without the NCS gauntlets:
BINARY_VERSION = 43
def get_raw_gauntlets(self, get21gauntlet=False) -> str:
    '''
    Return a list of raw Gauntlets
    '''
    data = {
"secret": COMMON_SECRET,
"special": 1
}
    if get21gauntlet:
        data["special"] = 0

    req = requests.post(ROOTURL + "database/getGJGauntlets21.php", data=data, headers=HEADERS)
    return req.text

Most of the changes look good, but please make separate PRs, one giant PR is difficult to review. Make one PR where you fix periods, other where you edit other general info etc. basically don't mix all the changes in a giant pr. Also revise which stuff has already been added (merge conflicts)


Accessing the Linter object via services interface is broken.

According to package.json:
"providedServices": {
    "linter-plus-self": {
      "versions": {
        "0.1.0": "provideLinter"
      }
    }
  },

However, this is the code in main.coffee:
  provideLinter: ->
    @Linter

It should probably be @instance. As it is now, provideLinter returns null, so you cannot consume the main Linter object via services.

It's not 0.1.0, It's 1.0.0. :sweat_smile:

I'm trying to get access to the Linter object service, not provide an interface to Linter. See the code snippets above.

Let me create an example quicky. Just a few minutes.

It's been fixed and a release has been pushed.

Thanks mate.

Why do you want to access the linter instance? We're providing it just
because we can and no one else has ever given a reason they might need it.
On Jun 26, 2015 6:28 PM, "Arron Washington"<EMAIL_ADDRESS>wrote:

Thanks mate.
—
Reply to this email directly or view it on GitHub
https://github.com/AtomLinter/Linter/issues/636#issuecomment-115908624.

@AsaAyers They are using it in their dart-tools package to collect messages from an external daemon that doesn't care about editor saves and feed it to linter.

Then we should provide a service for that, not just expose the internals of linter for any other package to poke at.

@AsaAyers I think our public methods are quite stable for other packages to use, and the global atom variable has all of the atom, instead of increasing the complexity and keeping the two things separate, they choose to expose the whole of it and then people use the Public API. and I haven't found any problems with it to date.

You're still completely wrong. We should have a documented service that we know is exposed to others instead of just blindly exporting everything that shows up on the linter. Is it ok for them to call deactivate? No, it shouldn't be on the object we hand over. What about addLinter and removeLinter? Definitely not
It seems like you want to export an object that contains getProjectMessages, setProjectMessages, and deleteProjectMessages. That's all that should be exposed in this service.

Those few methods won't really work for everyone in my opinion.
They also need eachEditorLinter, observeEditorLinter and some other methods in @views.
and I am not sure if someone would ever call deactivate on a service they're consuming, and if they do that, then they suffer the consequences, not our problem.
The same knife can be used to cut apples or people's throats, You would blame the user not the person.

Sorry, this shows your lack of experience managing such a project.

There is no documentation on what they can do with our current approach
linter is primarily internal. I will at some point refactor things and
break the service
You simply shouldn't expose things you don't want people messing with
because they will

If you want to expose a service, you should expose exactly the service you
want used.
On Sat, Jun 27, 2015 at 11:37 AM, Steel Brain<EMAIL_ADDRESS>wrote:

Those few methods won't really work for everyone in my opinion.
They also need eachEditorLinter, observeEditorLinter and some other
methods in @views.
and I am not sure if someone would ever call deactivate on a service
they're consuming, and if they do that, then they suffer the consequences,
not our problem.
The same knife can be used to cut apples or people's throats, You would
blame the user not the person.
—
Reply to this email directly or view it on GitHub
https://github.com/AtomLinter/Linter/issues/636#issuecomment-116089673.

@AsaAyers
I do plan on writing the documentation very soon.
Negative about Point 2, I have made sure that we don't have any redundant methods in the codebase.
About Point 3, It is ideal to not expose them, but there's nothing wrong if you would. 'cause If they were, then I am not sure that It won't be just me that would fit in your lack of experience circle, all of the atom core team and contributors will too.
Also I think our public API is quite stable, I am even trying to connect with abe of atom-minimap to request him for a minimap plugin for Linter. I still agree that we need documentation but there's nothing wrong with exposing all of us.

You're never going to convince me. I've been doing this for enough years to
know this is a VERY bad idea. When I have some time I'll extract it into a
proper service.
On Sat, Jun 27, 2015 at 11:44 AM, Steel Brain<EMAIL_ADDRESS>wrote:

@AsaAyers https://github.com/AsaAyers
I do plan on writing the documentation very soon.
Negative about Point 2, I have made sure that we don't have any redundant
methods in the codebase.
About Point 3, It is ideal to not expose them, but there's nothing wrong
if you would. 'cause If they were, then I am not sure that It won't be just
me that would fit in your lack of experience circle, all of the atom core
team and contributors will too.
Also I think our public API is quite stable, I am even trying to connect
with abe of atom-minimap to request him for a minimap plugin for Linter. I
still agree that we need documentation but there's nothing wrong with
exposing all of us.
—
Reply to this email directly or view it on GitHub
https://github.com/AtomLinter/Linter/issues/636#issuecomment-116089982.

Looking forward to your PR :)
I'm 100% cool with it if you wanna wrap the externals of @instance and put them in a new object.

Also I've added some Public API to the wiki here.


Bug: SERVER CRASHES

I don't know if I am doing this wrong but no it isn't fixed

i assume that the bit on the right links to a line in the log based on the translation can you please actually send the log here rather than just saying there is an error. without the error itself it is impossible to fix it

and if you are saying that this is still issue #28 the fix has not been released yet


Would love build instructions for the GUIs

Doesn't seem to be a Makefile or any build instructions for the GUIs, I know you host the executables and that's great but seeing as you've opened the source it would be great to build from there.
Thoughts?

The Windows GUI is cross-compiled on Linux, the Makefile is in C/win32gui:
https://github.com/jamesbowman/spidriver/tree/master/c/win32gui
The Linux.Mac GUI is the Python gui.py
https://github.com/jamesbowman/spidriver/blob/master/python/samples/gui.py
It is made into an executable with pyinstaller - the I2CDriver Readme gives the command-line:
https://github.com/jamesbowman/i2cdriver

Awesome man, I've built a package for Arch Linux that builds spicl and also a shared library, then installs to the system. I'll do the same for the GUIs based on your instructions above.
Also, just a side note: this device is the best thing I have ever purchased. Thank you!


Ctrl + keybindings won't work if no text is selected

Lovely project, can't wait to integrate it into my day to day workflow, but I've hit a reasonably major problem. The shortcuts I would consider important (Ctrl+X, Ctrl+C, and Ctrl+V) won't work if no text is selected.
Steps to reproduce:
- Clean Ubuntu 18.04 install
- Install Chrome & Git
- Install sshcode
- Run sshcode to Ubuntu 18.04 host
- Ctrl + X not working , nor is Ctrl + C, Ctrl + V, etc..
With a clean VSCode install Ctrl + X will delete the line if nothing is highlighted, same thing for Ctrl + C, etc...

cc @kylecarbs

Thank you for the reproduction steps, @kylecarbs is working on fixing this.

New release with the fix is out now. Running sshcode will automatically download the new release.
Here's a direct link if you're interested: https://github.com/codercom/code-server/releases/tag/1.939-vsc1.33.1
Thanks for the report!

When I tested on my side this does not seem to be fixed.
Same machine, same set up, and I get the same behavior.
Also it crashes after a few seconds with this error message:
WARN  stderr {"data":"(node:9963) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.\n"}
Error: ENOENT: no such file or directory, open '/home/travis/build/codercom/code-server/packages/server/build/web/favicon.ico'
INFO  WebSocket opened / {"client":1,"ip":"<IP_ADDRESS>"}
INFO  Connected to shared process
internal/child_process.js:366
    throw errnoException(err, 'spawn');
    ^

Error: spawn ENOMEM
    at ChildProcess.spawn (internal/child_process.js:366:11)
    at Object.spawn [as _spawn] (child_process.js:538:9)
    at t.async (/home/travis/build/codercom/code-server/packages/server/out/cli.js:504:34598)
    at e.exports (/home/travis/build/codercom/code-server/packages/server/out/cli.js:504:34099)
    at e (/home/travis/build/codercom/code-server/packages/server/out/cli.js:504:32722)
    at Timeout.u [as _onTimeout] (/home/travis/build/codercom/code-server/packages/server/out/cli.js:504:33015)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10)

Hm. What version does code-server output? Just to ensure you're on the latest version.
That error indicates you're out of memory. Is that the case?

The server is indeed feeble at 2GB of RAM, my bad! I'll try with another one.

Version is indeed code-server v1.903-vsc1.33.1 which is not the one you said to use.
I did use sshcode to connect though, and you said it would update automatically.

Found the issue. Binary in our public bucket wasn't updated.
Should be good to go now!


fix: fs shim when running inside electron renderer process

The fs shim does not work properly when used inside an electron renderer process, where both native node modules and chromium (i.e. global window) are available. This is one simple way to address the issue.

Thanks! We can get this into 0.24.0


Label "Amount" crosses the borders of field with its value (minor UI bug) +

Testing Environment:
Windows 10, Google Chrome 73.0.3683.86 (64bit), 15.6", 1920х1080
Steps to reproduce:

Navigate to http://rfai.singularitynet.io.s3-website-us-east-1.amazonaws.com/
Observe the page

EXPECTED RESULT:
Label "Amount" doesn't cross the borders of field with its value
ACTUAL RESULT:
Label "Amount" crosses the borders of field with its value
Please see the screenshot below

@raamb Can you please request Ananya to look into this UI changes.

This is as per the UX design and is not an issue

Ok, more detailed opinion in comments to that issue #25


Api endpoint

Subject of the issue
Api endpoint
Your environment

version of your python
which browser and its version
OS Type (iOS/Android/Linux/Windows)

Steps to reproduce
Tell us how to reproduce this issue. Please provide a working demo as a GIF, if possible.
Expected behaviour
Tell us what and how exactly is it supposed to  happen
Actual behaviour
Tell us what happens instead or what went wrong

#273

https://documenter.getpostman.com/view/182878/RWToQdF1 from Saifur Rahman Mohsin


mihiphoenix

Proposed changes

Subject Matter
Phoenix
Content Location

and in the darkness, bind them.
Additional information
[](url)

@mihihathi


Minimum Steps to Collect Coin Stacks

🚀 Feature
A solution to Minimum Steps to Collect Coin Stacks
Have you read the Contributing Guidelines on Pull Requests?
Yes
Motivation
To show the minimum steps required to collect coin stacks in C++, when given the following problem statement:
“Given an integer array representing the height of each stack of coins and the number of coin stacks, calculate the minimum number of straight lines that pass through all the coins (minimum number of steps to collect these coins).”
Pitch
It's a different question and can be used to practice for interview questions!

/assign


CQ.CreateFromFile issue with html attributes with epmty values which are converting into unsupported formtat.

Hi, empty html attbutes are converting in to unsupported format
Example:
<div itemscope="" itemtype="http://schema.org/Product" class="">

is parsed by csQuery as
<div itemscope itemtype="http://schema.org/Product" class>

which is causing problem in generating page markup in asp-net . Please help to fix this issue .

Well. For HTML it's totally valid format.
It's standard behavior of RenderAttribute() method inside FormatDefault class. There is no setting to disable this, and you can't override this method, because it's protected, but not virtual(which is little strange). You can override RenderElementInternal() method to format attributes output differently. Or you can implement your own IOutputFormatter from scratch.


Refactor Old token cleanup related code in identity-inbound-auth-oauth

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


[BUG]  Compiled 3.1.1 version STILL missing JSON files and [log] when trying to create model

Bug Description
Compiled version missing JSON files when trying to create model.
Steps to Reproduce
Outline the steps to replicate the issue:
Open Applio - follow steps at https://docs.applio.org/get-started/training/
Actual Results
Messages - "Failed to train model..."

Move Applio to a non-privileged repository (downloads, desktop...) and verify your dataset

I've moved to desktop and Downloads trying the compiled version.  I have the exact same issue.  Tried with .2.0 and 3.1.1

FIXED (sort of).  Running from Downloads folder (not ideal but functional), Extracted all features before starting training.
Any chance to get this installed as a regular program that runs on the C drive?

I see you misunderstood a few things:

You need to complete all the steps (Preprocess and Extract) before starting the training process.
Applio is written in Python and cannot be compiled into a standalone program.


[FEA] Upgrade Utilities to Python 3.10

Is this a new feature, an improvement, or a change to existing functionality?
Change
How would you describe the priority of this feature request
High
Please provide a clear description of problem this feature solves
Morpheus containers are currently built on Python 3.8.x - this version is losing support across the Python community and in general is ready to be sunset.
Describe your ideal solution
We should update Morpheus containers to Python 3.10 - this version is fully supported by RAPIDS, and the rest of the pydata community.
Describe any alternatives you have considered
No response
Additional context
Depends on

[ ] https://github.com/nv-morpheus/MRC/pull/317
[ ] https://github.com/nv-morpheus/Morpheus/issues/881

Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I have searched the open feature requests and have found no duplicates for this feature request

It's possible the utilities repo won't need to be updated to support Python 3.10

If it doesn't need it - please close this issue as Not Planned - Thanks!


Replace words with racial connotation (use allowlist and blocklist as an alternative)

PR Summary
This does not replace all words with a racial connotation because one word is the setting name of the PSAvoidUsingCmdletAliases rule. Therefore an alternative setting name is being added, whilst allowing the current one to still work. The idea is that we give users time to adapt in the next version but completely remove the setting with a racial connotation in the version after that.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

My only worry here is that this is a public configuration key, so that changing its name will break existing configurations

Oh I see from your description that this is an alternative!

Yes, it is an alternative/alias for the existing settings but once a new version of pssa is released with that, which would give people time to adapt I am tempted to remove the original setting name completely in the following release but that's a discussion for another day, which will probably not happen until in 6 months time....


#640

Add: Test cases for RuleHandleFactory.
Fix: Return null when got a null object of RpcTypeEnum.

Codecov Report

Merging #647 (e9328c2) into master (e5b1064) will increase coverage by 0.61%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #647      +/-   ##
============================================
+ Coverage     45.45%   46.07%   +0.61%
- Complexity      787      797      +10
============================================
  Files           224      224
  Lines          5341     5343       +2
  Branches        591      591
============================================
+ Hits           2428     2462      +34
+ Misses         2685     2653      -32
  Partials        228      228

Impacted Files
Coverage Δ
Complexity Δ

...oul/common/dto/convert/rule/RuleHandleFactory.java
62.50% <100.00%> (+62.50%)
3.00 <2.00> (+3.00)

...mara/soul/common/constant/RuleHandleConstants.java
50.00% <0.00%> (+50.00%)
1.00% <0.00%> (+1.00%)

...ava/org/dromara/soul/common/enums/RpcTypeEnum.java
61.53% <0.00%> (+61.53%)
1.00% <0.00%> (+1.00%)

...org/dromara/soul/common/enums/LoadBalanceEnum.java
100.00% <0.00%> (+100.00%)
1.00% <0.00%> (+1.00%)

...l/common/dto/convert/rule/impl/SofaRuleHandle.java
100.00% <0.00%> (+100.00%)
1.00% <0.00%> (+1.00%)

.../common/dto/convert/rule/impl/DubboRuleHandle.java
100.00% <0.00%> (+100.00%)
1.00% <0.00%> (+1.00%)

...common/dto/convert/rule/impl/DivideRuleHandle.java
100.00% <0.00%> (+100.00%)
1.00% <0.00%> (+1.00%)

...n/dto/convert/rule/impl/SpringCloudRuleHandle.java
100.00% <0.00%> (+100.00%)
1.00% <0.00%> (+1.00%)

Continue to review full report at Codecov.

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


Remove keti alias mention from README

I think that in the README there is a leftover from the official kubectl Oh-My-ZSH plugin.

thanks! <3


[BUG] Resource graph query throws Microsoft.Azure.Management.ResourceGraph.Models.ErrorResponseException

Describe the bug
Calling resourceGraphClient.Resources throws ErrorResponseException.
Expected behavior
No exception should be thrown. I can run the same query from PowerShell and it works.
Search-AzGraph -Query 'Resources | project name, type | limit 5'

Actual behavior (include Exception or Stack Trace)
Stach trace:
Microsoft.Azure.Management.ResourceGraph.Models.ErrorResponseException
  HResult=0x80131500
  Message=Operation returned an invalid status code 'BadRequest'
  Source=Microsoft.Azure.Management.ResourceGraph
  StackTrace:
   at Microsoft.Azure.Management.ResourceGraph.ResourceGraphClient.<ResourcesWithHttpMessagesAsync>d__48.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   at Microsoft.Azure.Management.ResourceGraph.ResourceGraphClientExtensions.<ResourcesAsync>d__1.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.Azure.Management.ResourceGraph.ResourceGraphClientExtensions.Resources(IResourceGraphClient operations, QueryRequest query)
   at ConsoleAppAzureServices.Program.<RunResourceGraphQuery>d__1.MoveNext() in C:\Users\N16263.NEWDAY\source\repos\linuxvm-msi-keyvault-arm-dotnet\ConsoleAppAzureServices\ConsoleAppAzureServices\Program.cs:line 38

  This exception was originally thrown at this call stack:
    [External Code]
    ConsoleAppAzureServices.Program.RunResourceGraphQuery(Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProvider) in Program.cs

To Reproduce
Steps to reproduce the behavior (include a code snippet, screenshot, or any additional information that might help us reproduce the issue)

Unzip ConsoleAppAzureServices.zip
Build & debug

Environment:
Details on attached csproj.

Thanks for reporting the issue. I will follow up.

Hi @realrubberduckdev your sample code seemed to have misspelled "Resources". Fixed it and I got the correct response.

Closing the issue for now. Feel free to reopen if you find it not working.

@isra-fel Wow! Thanks a lot, it works for me now and apologies for this bug, unsure how such a small mistake went unnoticed.


ULP support for esp32-s3 (IDFGH-7531)

Is your feature request related to a problem? Please describe.
I want to use the RiskV ULP on a esp32-s3 chip. I tried to run the ulp_riscv/ds18b20_onewire example, but it failes with the following error: "ULP temporarily unsupported on ESP32-S3, running sleep + ULP risks causing permanent damage to chip"
Describe the solution you'd like
Please implement ULP support for esp32-s3. Do you have a time estimation on when support will be available?
Describe alternatives you've considered
None.
Please give as many details as you can. Include suggestions for useful APIs or interfaces if relevant.
This commit is referencing Fix in-progress: DIG-160.
I don't know what that means, though.

Hi,
The fix for the digital issue mentioned was merged yesterday, and we have a MR in-review for re-enabling ULP support on S3. If everything goes smoothly it should be merged by the end of the week.


Ruby: ignore RuboCop remote inherited config files

Reasons for making this change:
RuboCop config files support an inherit_from directive.
When one inherits from a remote URL, a local version is download. For example: .rubocop-https--my-remote-config.com.
Links to documentation supporting these rule changes:
From RuboCop's docs

The optional inherit_from directive can contain a full url to a remote file. This makes it possible to have common project settings stored on a http server and shared between many projects.

The remote config file is cached locally and is only updated if:

The file does not exist.
The file has not been updated in the last 24 hours.
The remote copy has a newer modification time than the local copy.

Given this, is seems appropriate for git to ignore this file.

@sshaw thanks!


How to allow line breaks in news article description?

Hello,
We're using RSS for our video game development patch notes and announcements and I'm wanting to allow line breaks in the body/description of the article. Right now it strips them and replaces with a space. I've been digging thru the files for a while and can't seem to make sense of where they are being stripped, so that I can intervene and ask it to instead convert to \n so that Discord will show a line break when it's printed.
Any help will be appreciated. Thank you!

My RSS Feed:
<rss version="2.0">
  <channel>
    <title>Legends of Ultima: Patch Notes</title>
    <link>https://news.legendsofultima.online</link>
    <description>Legends of Ultima: Patch Notes</description>
    <language>en-us</language>
<EMAIL_ADDRESS><EMAIL_ADDRESS>    <copyright>2019</copyright>

  <item><title>PVP Balance Pass</title><description><![CDATA[:nauseated_face: Poisoning Changes
- Will now only block 50% of the healing received when poisoned.
- When curing with potions, bandages or spells if the first try fails each subsequent try up to 3 total will see the chance raise by it's base value. - Each type of curing is separate, a fail on a spell cure will not add to the chances of curing next using a potion.
- A regular cure potion has a 25% chance to cure greater poison, after the first fail it would be 50% and after the second fail it would be 75% on the third try.
- This means a greater cure potion will have a 100% chance to cure a greater poison on the second try.

:sake: Potions
- All potions now share a 2 second global cooldown.

:syringe: Bandages
- Chance to slip when moving increased]]></description><link>http://news.legendsofultima.online/</link><author>Nek</author><pubDate>Wed, 20 Mar 2019 08:35:48 +0000</pubDate></item></channel>
</rss>

My feed config: {   "name": "Bot Testing",   "id": "557858490786250763",   "sources": {     "-1646290076newslegendsofultimaonline>36782": {       "title": "Untitled",       "link": "http://news.legendsofultima.online/patchnotes.xml",       "channel": "557858490786250765",       "addedOn": "2019-03-20T10:05:21.219Z",       "embeds": [         {           "title": "{title}",           "description": "{description:newline}",           "author_name": "Legends of Ultima: Patch Note",           "timestamp": "{date}",           "url": "http://news.legendsofultima.online",           "footer_text": "Written by: {author} @ {date}",           "footer_icon_url": "https://cdn.discordapp.com/icons/369023244038045697/cc6674edd991beb6239d83f28d44b732.png",           "author_icon_url": "https://cdn.discordapp.com/icons/369023244038045697/cc6674edd991beb6239d83f28d44b732.png"         }       ],       "message": "{empty}",       "regexOps": {         "description": [           {             "name": "newline",             "search": {               "custom": true,               "flags": "g",               "regex": "\\s(\\[(?:Fixed|Changes|New)| *- )|\\*-- Delivered by Feed43 service\\*"             },             "replacementDirect": "\n$1"           }         ]       }     }   } }

Is the feed link available to test? I will take a look at it later today, but normally HTML line breaks , or lists should be converted to new lines

Thank you! It's http://news.legendsofultima.online/patch notes.xml
On Wed, Mar 20, 2019, 8:19 AM synzen<EMAIL_ADDRESS>wrote:

Is the feed link available to test? I will take a look at it later today,
but normally HTML line breaks
, or lists should be converted to new lines
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/synzen/Discord.RSS/issues/98#issuecomment-474824935,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AfqdRBZvxIfOLS3b4d8NxmsULfRPwrdJks5vYjV0gaJpZM4b-4VU
.

Or rather http://news.legendsofultima.online/patchnotes.xml
On Wed, Mar 20, 2019, 1:16 PM Nicholas<EMAIL_ADDRESS>wrote:

Thank you! It's http://news.legendsofultima.online/patch notes.xml
On Wed, Mar 20, 2019, 8:19 AM synzen<EMAIL_ADDRESS>wrote:

Is the feed link available to test? I will take a look at it later today,
but normally HTML line breaks
, or lists should be converted to new lines
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/synzen/Discord.RSS/issues/98#issuecomment-474824935,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AfqdRBZvxIfOLS3b4d8NxmsULfRPwrdJks5vYjV0gaJpZM4b-4VU
.

No problem,

there doesn't appear to be any new lines or line breaks in the xml. If you have control over the feed contents, it would be best if you formatted it with HTML, such as <br />

Much better! Thank you so much for your guidance. :)


Functional: Fix for InlineLambdas (or rather RemapSymbolRefs) Bug

Description
Fixes a failure of RemapSymbolRefs (and thus InlineLambdas) when a SymRef appears directly in a lambda body. Bug found by @tehrengruber in FVM code.
Requirements
Before submitting this PR, please make sure:

[x] You have run the code checks, tests and documentation build successfully
[x] All fixes and all new functionality are tested and documentation is up to date
[x] You looked at the review checklist

Additionally, if this PR contains code authored by new contributors:

[x] All the authors are covered by a valid contributor assignment agreement,
signed by the employer if needed, provided to ETH Zurich
[x] The names of all the new contributors have been added to an updated
version of the AUTHORS.rst file included in the PR

bors try


chore(destroy): add current path . as the default path

Signed-off-by: Triple-Z<EMAIL_ADDRESS>closed #420

This PR will have the following outputs.
$ ~/Code/envd/bin/envd destroy --help
NAME:
   envd destroy - destroys the envd environment

USAGE:
   envd destroy [command options] [arguments...]

OPTIONS:
   --name value, -n value  Name of the environment
   --path value, -p value  Path to the directory containing the build.envd (default: .)

BTW, maybe down is a better word than destroy:

docker-compose uses it.
down is the antonym for up.
destroy is easy to typo :(

Thanks for your contribution! :tada: :+1:

@all-contributors Please add @Triple-Z for his code contributions!


Error regenerating certs: Error copying ca.pem to machine dir

Not sure what's going on here, but the regenerating certs action is failing because of an issue in libmachine/provision/utils.go:
$ docker-machine regenerate-certs overlay
Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Error copying ca.pem to machine dir: open : no such file or directory

cc @ehazlett Seen anything like this before?  It's rendering my machine unusable.

I know what's behind this now: in the recent changes to ConfigureAuth, I moved away from passing in AuthOptions, due to the fact that they are passed in when you invoke Provision.  So, the struct is blank, since with regenerating the certs we do not actually call Provision first.  The obvious/hacky way to fix is to create a method SetAuthOptions which allows you to do this directly... I am not sure how to handle it elegantly.  If we had an idempotent Provision method (we are not really too far off), it might be OK to just call it directly, but as of right now we don't.  I might end up removing the append to config file code we have now and just call Provision directly.  It will be a little more overhead but not too bad.

OK, I'm going to go ahead and fix the newline invalidating hashes issue with the certs while I'm at it.

Ah makes sense.  Thanks!


Optimize workflow execution engine

The current implementation has some issues/miss implementations that degrade system performance for larger/more complex logic.
Known issues

[ ] execution stack traces: since they blindly append, they quickly grow out of control especially when processing large loops (iterating a couple thousand records). The stack trace will need to become more limited to not kill the server.
[ ] execution state storing: state gets flushed to the database. It's done every once in a while but this still may pose some bottle necking since DB writes are slower in comparison.
[ ] pkg/expr is memory heavy: some quick bottlenecks prove the pkg/expr package is resource heavy due to it heavily relying on string manipulation.

Potential issues

[ ] heavy mutex locks: typed values have a bunch of locks since they're pointers living in a parallel world. Not sure how much of an impact they have since these locks barely ever block so it might be whatever.
[ ] Excessive logging: all the logs are good for development/debugging but they might just add strain on the system since some of these logs do operations over strings which are slow to use

Benchmarks & Analysis
Simple workflow with sequence iterator
Sequence of 10k iterations:
goos: darwin
goarch: arm64
pkg: github.com/cortezaproject/corteza/server/tests/workflows
Benchmark_bench_exec_base-12                   1<PHONE_NUMBER> ns/op<PHONE_NUMBER> B/op 39866614 allocs/op

no. 1 bottleneck is with the state change handler; primarily JSON marshalling

Without stateChangeHandler
Same iterator but the state change handler turned off
goos: darwin
goarch: arm64
pkg: github.com/cortezaproject/corteza/server/tests/workflows
Benchmark_bench_exec_base-12                   1<PHONE_NUMBER> ns/op        179357032 B/op   1040858 allocs/op

No. 1 bottle neck in this case is expression evaluation. pkg/expr does a bunch of operations over strings which would be slow so this makes sense and would need to be addressed.

Added a utility to traverse expression paths
goos: darwin
goarch: arm64
pkg: github.com/cortezaproject/corteza/server/pkg/expr
BenchmarkPath-12        14496174                75.33 ns/op            0 B/op          0 allocs/op

Applying the expression traversal utility to expr.Assign; we go from
goos: darwin
goarch: arm64
pkg: github.com/cortezaproject/corteza/server/pkg/expr
BenchmarkAssign-12    	 1811497	       662.7 ns/op	    4368 B/op	       6 allocs/op

to
goos: darwin
goarch: arm64
pkg: github.com/cortezaproject/corteza/server/pkg/expr
BenchmarkAssign-12    	 9167824	       133.1 ns/op	       0 B/op	       0 allocs/op

9167824/1811497 ~= 5.06

Without stateChangeHandler
Same iterator but the state change handler turned off and expressions tweaked
goos: darwin
goarch: arm64
pkg: github.com/cortezaproject/corteza/server/tests/workflows
Benchmark_bench_exec_base-12                   1<PHONE_NUMBER> ns/op        54809432 B/op     930611 allocs/op

Timewise, we're about the same; memory consumption though, is ~3.2x less (179357032/54809432 ~= 3.2)

The seeming bottleneck now would be with var/state management.
Per run we're using up 50MB which isn't that bad (I think).

Looking at some CPU timings, we see this:

This would suggest the bottleneck is due to excessive locking/unlocking.
My guess would be due to typed values (since they all have locks)

Looking at execution traces there are larger holes between the benchmark runs; investigating if this is a scheduling thing

Tested on some other benchmark and that one looks fine... I can't figure out exactly why this happens but everything points to how we utilize routines and channels under the hood.
Mutex profile is empty so that shouldn't be the problem.

One set of holes is caused by sonyflake (since it can only generate 255 IDs per 10ms)
The second is caused by some ticker which waits for workflows to complete (it waits x ms which causes the big holes between the test runs).
Sonyflake issue was fixed by running a few generators in routines and utilizing a channel to receive generated IDs in one go.
The other one was caused by leaving a debug interval value.
With all this in place it now looks like this:

goos: darwin
goarch: arm64
pkg: github.com/cortezaproject/corteza/server/tests/workflows
Benchmark_bench_exec_base-12<PHONE_NUMBER>8 ns/op         5532122 B/op      93417 allocs/op

Temporarily moving to product backlog to do some profiling on DAL


Add a merge of the config in order not have to copy the whole theme o…

Add map-merge to the theme config in order to overwrite only partial of the config instead of having to copy the while object

This is a very smart idea! I'll get it merged ASAP. Thanks! 👍


ChartTLS: TLS grpcs calls via gateway to nodes

Currently uses external LoadBalancer service and TLS is handled by the HAProxy server with TCP passthrough to the Node.


Initial commit for snake,water & Gun game

🛠 Issue (Number):
Closes #342
Description
It is a Snake,water &gun game which is played between the user and the computer where the computer chooses a random option and thus decides who wins the game.
Type of change

[x ] New feature (non-breaking change which adds functionality)

Checklist:

[x ] I have made this from my own
[ x] I have taken help from some online resourses
[x ] My code follows the style guidelines of this project
[x ] I have performed a self-review of my own code
[x ] I have commented my code, particularly in hard-to-understand areas
[x ] The title of my pull request is a short description of the requested changes.

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

i have added readme.md file please review it

Hi @Keegan-20 everything looks good, awesome work, but just a suggestion, could you please add a bit of Markdown formatting to make the README a bit more readable, i.e., Appropriate headings for each section with proper styling + bullet points for describing rules/steps + other stuff.
Here's a guide to Markdown syntax, in case you want to refer to: https://www.markdownguide.org/basic-syntax/

Thank You @abhilipsasahoo03  for the article i have done the necessary formating.Please Review it.

Thank you😊

The background is not working
Fix the issue

 The background is not working Fix the issue

i have fixed the issue please review the same


save (not saveAs) does not display the filename on save

When you open an existing file and save with "save", and not "saveAs", is says "saving to undefined" in the top right corner instead of telling the filename.

Hmm, I cannot reproduce. What file path are you trying to save? Node/npm version?

Aha, since I removed the default keybinding for save I have not tested it. I can confirm now after applying the changes described in #151 to ~/.slap/config. Will be fixed soon!

Closed. This fix will be included in the next release of slap!


Write and deploy set_new_batch_run_session_id.ps1

Created the table batch_run_sessions, now needs to get the code working. Needs a UUID column too.

Done!    WOW


chore: bump bootstrap-icons, @types/react-native versions

@omaryoussef Thank you for this! Could you update to use lockfile version 1? I'd like to keep this PR focused just on bumping the dependencies.

Closing, as I've bumped the versions.


Handle General MultipartExceptions

Synopsis
Sometimes Spring MVC and WebFlux decide to throw MultipartException for multipart requests. For example, if the endpoint supposed to be a multipart one but the request isn't, then Spring throws this general exception.

Closed by #88