Simplify curryN

I've always felt that there was something off with R.curryN but my last stab at it resulted in only minor modifications.
This PR introduces an internal _curryN as a base for the external curryN. The internal function has a slightly different signature. The new internal function is half the size of the old curryN and completely avoids using _slice.
I've also used for loops just to provocate. I think the idea of always using while loops is silly. It's like always using reduce and forbidding map. And the kind of "consistency" that is achieved by doing so is just as harmful. Code becomes less expressive and harder to read and understand because you're using a more general construct when a more specific one would capture the desired control flow better.
Here is the new _curryN written with while loops:
module.exports = function _curryN(length, recieved, fn) {
  return function() {
    var combined = [];
    var combinedIdx = -1; // What! Minus one? But that's not really where we begin indexing
    var argsIdx = 0;
    var left = length;
    while (++combinedIdx < recieved.length) { // Stuffing increment and condition check into one statement :( :( :(
      var val = recieved[combinedIdx];
      combined[combinedIdx] = val === __ && argsIdx < arguments.length ? arguments[argsIdx++] : val;
      if (combined[combinedIdx] !== __) { --left; }
    }
    while (argsIdx < arguments.length) {
      combined[combinedIdx] = arguments[argsIdx];
      if (combined[combinedIdx] !== __) { --left; }
      combinedIdx++; argsIdx++; // Huh!? For-loops have a well defined location for such increments
    }
    return left <= 0 ? fn.apply(this, combined) : arity(left, _curryN(length, combined, fn));
  };
});

I will change this PR to use while loops if requested to do so :)

I prefer for loops rather than while loops in many cases because they group the boilerplate for managing the loop index. I don't like our var idx = -1; while (++idx < list.length) { ... } pattern as it requires setting the index variable to -1 initially rather than 0.
On a similar note, I'm opposed to the use of ++ and -- in most cases. The existence of both prefix and postfix forms is a source of confusion, and the prefix forms are syntactic sugar for += 1 and -= 1 respectively. Were we permitted to use for loops and Array.prototype.push we could remove most or all occurrences of ++ and -- (both prefix and postfix).

part of the reason i started collaborating on eweda way back when was because i hate for loops so much. this lib is no longer my playground, and hasn't been for a while, so i won't waste energy fighting for.  it's an implementation detail. I'll just throw up in my mouth a little bit every time i see one in the codebase.

part of the reason i started collaborating on eweda way back when was because i hate for loops so much.

I don't understand this when the alternative is while loops. The way I see it almost all iterations are captured more cleanly with a for loop.

De gustatibus non est disputandum.

Are you ok with the for loops @CrossEye? I know you don't like them as well.
I'm still willing to take them out.

I'm more than willing to disputandum about gustatibus.  :-)
I actually have less objection, I think, to the for-loops themselves than @buzzdecafe does.  But I would prefer to keep our source code consistent.  (Yes, I know the Emerson quote, thank you.)  I was the one who started us down the while-loop path, based both on very ancient memories of when while-loops were at least marginally faster than for-loops and on a mild distaste for the for-loop syntax.
I still have a distaste for that syntax.  It's somewhat mild, but quite real.  I feel we've conditioned ourselves to accept an ergonomically unfit syntax rather than build a syntax designed to help us.  Compare any of these to the C-style for-loops the Javascript has inherited:
for x in range(1, 11):
    print x

for x in 1..10
   puts x
end

(loop for x from 1 to 10
    do (print x))

All these feel clean and readable.  Of course they're not as powerful and flexible (well, LISP is, but only by becoming more convoluted) but they express the common case so much more nicely.
I do appreciate the concern @davidchambers has about starting the loop iteration at -1.  I don't really like that either.  And, while I don't share his objection to ++ and/or --, I would have no problems with giving up that construct.  But I am loathe to switch to for-loops.
I would have no problem at all, though changing universally from this style:
function map(fn, list) {
  var idx = -1, len = list.length, result = [];
  while (++idx < len) {
    result[idx] = fn(list[idx]);
  }
  return result;
};

to this one:
function map(fn, list) {
  var idx = 0, len = list.length, result = [];
  while (idx < len) {
    result[idx] = fn(list[idx]);
    idx+= 1;
  }
  return result;
};

So, yes, I would rather do this with while-loops.  But I wouldn't at all mind switching the style of while loops if that would make others (anyone besides David?) happier.

And, while I don't share [David's] objection to ++ and/or --, I would have no problems with giving up that construct.

#1164

@CrossEye

But I would prefer to keep our source code consistent.

As I wrote before: "It's like always using reduce and forbidding map. And the kind of "consistency" that is achieved by doing so is just as harmful." It's like always using the hammer in the name of consistency.
I certainly agree with you that the for loops you posted from other languages are more readable. But you made no argument for why JavaScript while loops are preferable to JavaScript for loops. I have a few reasons for the opposite:

for loops are more compact. They take fewer lines. And, less importantly, fewer characters.
for loops have well defined locations for initialization, end condition and increment. This makes them more straightforward to write and easier to read (because there's a fixed location for these things). If we where using for loops there would be no discussion about which style to use because the for loops themselves dictates a common style.

I'll just repost this diagram that @davidchambers posted because I think it demonstrates very clearly the problem with how we use while loops.
This is a while loop:
<x>;
while (<y>) {
  <a>;
  <z>;
}

And this is the equivalent for loop:
for (<x>; <y>; <z>) {
  <a>;
}

Notice first of all that the for loop is 2 lines shorter! That in itself is nice. But the important difference is that in the for loop the meaning and the location of the various <*>s is dictated by the for loop! Almost every programmer will be immediately familiar with what the various parts do and where they are.
On the other hand the location of the various things in the while loop is arbitrary and invented by us.
The strictness that the for loop enforces makes it easier to parse for the programmer! There are less moving parts.

Although I will buy arguments from brevity, only for equally clear code.  And my take is that for is simply not as clear.  What you see as something equally familiar to all developers, I see as something similar to http://underscorejs.org/#sortedIndex: too much complexity masquerading as flexibility.
First of all, you only mention one of the three for syntaxes the language now has:
    for (initializers; tests; incrementers) { ...}
    for (name in obj) { ... }
    for (prop of iterator) { ... }

Then you have to consider whether to use var or let inside the statement, or whether to do it beforehand:
    for (var i = 0; i < arr.length; ++i) { ... }
    for (let i in arr) { ... }

    var ctr, arr = getData(), len = arr.length;
    for (ctr = 0; ctr < len; ctr++) { ... }

Then you need to deal with the fact that not only are the three sections of the ;-separated syntax version optional, two of them allow for multiple phrases:
    for (var idx = 0, matches = 0;
         idx < arr.length && matches <20;
         idx++, matches += isMatch(idx) ? 1 : 0) { ... }
    for (;val; val--) { ... }
    for (; --current; ) { ... }

This is not simply a matter of crazy remote possibilities:  All these were found in the recent projects from a developer we all know:
    for (var i = 0; i < arguments.length; ++i) { ... }
    for (; orderNextIdx >= 0; --orderNextIdx) {...}
    for (operation in delta) {
        for (key in delta[operation]) { ... }
    }
    for(;j=list[i++];) { ... }

So yes, I'm still mostly opposed to for-loops, although my objection might not be as strong as the foregoing makes it sound.

First of all, you only mention one of the three for syntaxes the language now has:

Even though they begin with the same keyword those are all different constructs that are easy to tell apart.

Although I will buy arguments from brevity, only for equally clear code.

That we agree on! But I think for is clearer ;)

Then you have to consider whether to use var or let inside the statement, or whether to do it beforehand:

Where to declare the variable. That is an issue JavaScript developers face all the time independent of whether or not they use for-loops. I personally prefer to only put the var inside the for loop if it's inside a function where the index is the only one being declared.

Then you need to deal with the fact that not only are the three sections of the ;-separated syntax version optional, two of them allow for multiple phrases:

I don't accept that argument. In JavaScript the comma operator can be used everywhere a statement is expected. for-loops and while-loops are on equal grounds here.
while (idx < len, 'what', 15, 'going on', Math.min(idx, 0), true) {
  // Wow! Aren't while loops bad?
}

This is not simply a matter of crazy remote possibilities.

Yes it is. You can write horrible code with both for and while loops. It is unfair to compare worst-possible-for-loop-usage with best-possible-while-loop-usage. If, on the other hand, you compare for- and while-loops on equal terms the conclusion is that for loops are harder to screw up. Why? Because the construct itself dictates where you should put <x>, <y>, <z> and <a>. This guarantees consistency. Not only across Ramda – but across all of JavaScript. With while loops the individual programmer will have to decide where to put <x>, <y>, <z> and <a>. Then you're certain that you will not get something consistent across code bases.
The above is also why the for loop is clearer! Since the for loop is consistent across JavaScript (and even other languages) it is very easy and mentally untaxing to parse. You immediately know where to look for <x>, <y>, <z> and <a>. With while loops you first have to figure out where this particularly project choose to put those things. A splendid example of this issue is the recent reordering of <x>, <y>, <z> and <a> in Ramda. With for-loops that wouldn't even have been possible.
And FWIW, in the example code you posted the only usage of for I don't like is for(;j=list[i++];) { ... } – that is essentially a while loop and thus a while loop would indicate the intend more clearly. But I guess the for loop was used as a size optimization (a while loop can always be replaced with a smaller for variant).

Arguments in favor of one or the other terrible loop syntax strike me as a waste of energy. for and while are really quite close. That said, the reason for loops are inferior is not just that they are a vulgar display of explicit iteration. A for loop is how a computer "thinks". There is nothing human about it whatsoever. It is pure, technical prose, that bends the person to the tool. A while loop is not much better. But any amount better is still better.
To my mind the arguments is purely aesthetic.
Now I'm done. Carry on.

@paldepin: I think you're misunderstanding what I'm suggesting here.  I'm not arguing for while.  I'm arguing against for.  I believe for is overcomplicated, and does not do a good job of simply describing developer intent.
I do think while is simpler, but that's not the point I had been making, only that for is pretty horrible.  Here I'll try to defend while as a better alternative to for.
When you make this argument,
for (<x>; <y>; <z>) {
  <a>;
}

<x>;
while (<y>) {
  <a>;
  <z>;
}

You are presupposing the structure of for (or of one of the for syntaxes.)  If I were to start from the definition of while
while (<c>) {
  <s>
}

And then map that back onto for, I would get the bizarre version of for that you didn't like:
for ( ; <c> ; ) {
  <s>
}

I don't think that really proves much, either way.  Nor do particular individual examples, such as
while (getNextToken() !== null) { ... }

But they do serve to show that there are things more easily done with one than the other.
But speaking of the definitions, the MDN definitions of the two forms of while are both substantially simpler than any of the definitions of the three forms of for.  I think that says something important about their relative complexities.
People have been quoting a great deal here lately from the Zen of Python, and I think three of its lessons are quite important:

Explicit is better than implicit.

If we explicitly perform any index initialization in a very clear and open fashion without burying it inside some looping construct, I think we gain something.

Simple is better than complex.

while tests a condition and repeated processes a statement/block so long as the conditions is truthy.  for initializes your loop counters, tests a conditions, processes a statement/block so long as its truthy, and then updates the loop counters.  (And by specifying loop counters, I'm actually oversimplifying this a bit.)  Clearly while -- as a statement -- is simpler.  We can also discuss the code we write that uses while, realizing that adding back initialization and incrementing will change the balance somewhat.  But I will argue that generally, building on simpler pieces is simpler.

There should be one-- and preferably only one --obvious way to do it.

while is clearly the more general of the two constructs, as you can model any for as a while, but the reverse is substantially more difficult, perhaps impossible.  And since we might need these features, we will need to allow while statements.  If we disallow for statements, it helps make more obvious how to code your functions.

And FWIW, in the example code you posted the only usage of for I don't like is ...

I would hope you wouldn't mind that code too much!  It's all taken from top projects on your Github page.  My point was simply that for really does get used in all these ways.  And I really have seen many examples in the real world of multiple initialization statements in a single block.  I've never that I can recall seen a comma operator in a while condition.

I think you're misunderstanding what I'm suggesting here. I'm not arguing for while. I'm arguing against for. I believe for is overcomplicated, and does not do a good job of simply describing developer intent.

Yes. I was misunderstanding you. I thought you where arguing for why for is worse than while.

You are presupposing the structure of for (or of one of the for syntaxes.)

No. I'm showing how while loops would look in our code base compared to how for loops would look. I'm arguing specifically that for loops are better at iterating lists.

But they do serve to show that there are things more easily done with one than the other.

Yes. That is a great example of when while is preferable.

But speaking of the definitions, the MDN definitions of the two forms of while are both substantially simpler than any of the definitions of the three forms of for. I think that says something important about their relative complexities.

while loops are simpler. No doubt about that. But not by much. The description of the for loop on MDN is still quite brief.

If we explicitly perform any index initialization in a very clear and open fashion without burying it inside some looping construct, I think we gain something.

No no no! Nothing can be more explicit than putting index initialization inside a syntax construct that dictates where to put the index initializations. When I read the before mentioned MDN article about for I know where to find the index initialization in all for loops. How can putting something at a location where all developers will expect it and immediately understand it be "burying"?
What you're suggesting is putting the initialization in some (to the language) arbitrary position where it only has a meaning because you assign it one (and that location was a different one yesterday).

We can also discuss the code we write that uses while, realizing that adding back initialization and incrementing will change the balance somewhat. But I will argue that generally, building on simpler pieces is simpler.

Why is building on a simpler piece necessarily simpler? When you at all the additional complexity of the for loop to the while loop you are left with identical complexity. You have the exact same number of statements. If the while loop actually let us iterate a list with fewer statement I would be all over it. But it doesn't.

while is clearly the more general of the two constructs, as you can model any for as a while, but the reverse is substantially more difficult, perhaps impossible.

No. As I've mentioned before a for loop can express the same (and always in fewer characters). But, let's rephrase your statement into using reduce and map:

reduce is clearly the more general of the two constructs, as you can model any map as a reduce, but the reverse is substantially more difficult, perhaps impossible. And since we might need these features, we will need to allow reduce statements. If we disallow map statements, it helps make more obvious how to code your functions.

Do you still agree? I think having a rich (but not too rich vocabulary) is very important when programming. It makes it possible to communicate ones intend better. The for loop is specifically designed for iterating over an array and thus communicates that intend better than a while loop.
I don't buy the "while is simpler" argument. True, while is simpler. That is why one should use it when only the limited power of while is required. for captures more complexity. But for iterating over a list with an index (the case we are discussing) it captures the right amount of complexity. for loop is a tool that fits the job perfectly. Sure, you can add a bunch of statements to while and achieve a solution as well. But don't insist on using the hammer when we're not dealing with a nail. The problem at hand is iterating an index and while does not let us arrive at a simpler solution.

I would hope you wouldn't mind that code too much! It's all taken from top projects on your Github page. My point was simply that for really does get used in all these ways.

Haha! I didn't recognize the code. Where is the last line from? That is surely a mistake.

I've never that I can recall seen a comma operator in a while condition.

That because while is to simple that you instead add extra statements before or inside the while loop.

Yes. I was misunderstanding you. I thought you where arguing for why for is worse than while.

I do think that, but only because I believe the JS for-loop is so horrid.  That's what I was arguing.
Where functions like map abstract away iterator initialization, bounds-checking, and incrementing, and where the Python, Ruby, and LISP syntaxes above make these concerns declarative, the C-style loop makes you implement all these blocks, structure your code around its notion of how they should be organized, and then ensure that you don't muck about with those iterator indices it has claimed as its own.  In short, to understand code in a for-loop, I have to play JS interpreter.
Here's a simple example:  a loop that iterates three times, with {1, 2, 3, 4, ...} representing the order in which each step is run.  In each of the samples, mentally (or even better, by pointing) walk through the sequence of events:
for (<x> {1}; <y> {2, 5, 8, 11}; <z> {4, 7, 10}) {
  <a>; {3, 6, 9}
}
{12}

<x>; {1}
while (<y>) {2, 5, 8, 11} {
  <a>; {3, 6, 9}
  <z>; {4, 7, 10}
}
{12}

To me, the latter one flows much more smoothly.  The steps of what is supposed to be an imperative block of code runs top to bottom, the flow interrupted only by jumping back to the beginning of the loop, and one final jump out of the loop.  (The do-while structure wouldn't even have that last jump.)
In the for-loop version, you can build up the right rhythm to follow the steps, but it certainly doesn't feel as natural.  It's worse if some of the ;-separated sections are missing, because of course the work has to be done, and therefore it's being done somewhere else (as part of <a>, obviously), but the mental model becomes more problematic.
And there is further complexity in the fact that the same keyword is used for two other unrelated -- although similar to one another -- structures.  for-in-loops and for-of loops overload the symbol for with very little benefit.  The reason that Ramda signatures are not overloaded is because we find such to be an unwarranted source of complexity.  for-loops come across to me the same way.

I'm arguing specifically that for loops are better at iterating lists.

Right, and I'm arguing that for-loops are so generally bad that we wouldn't want them at all, even if in using them for iterating lists we might reduce line-count.

If we explicitly perform any index initialization in a very clear and open fashion without burying it inside some looping construct, I think we gain something.

No no no! Nothing can be more explicit than putting index initialization inside a syntax construct that dictates where to put the index initializations.

Well yes, we could become more explicit still, with some imaginary syntax:
    var i = 0;
    loopBegin:
        if (i >= arr.length) goto loopEnd
        // do something useful
        goto loopBegin
    loopEnd:

But we've long-since grown accustomed to seeing this style of coding as wrong.  We're trying to play compiler/interpreter in our own source code here, not abstracting up to a useful level.  To me for-loops in Javascript are just like that.

When I read the before mentioned MDN article about for I know where to find the index initialization in all for loops. How can putting something at a location where all developers will expect it and immediately understand it be "burying"?

I'm really trying to make the distinction between simple and easy.  Simple is "less intertwined", easy is "more familiar".  Where while loops ignore any considerations besides repetition and bounds testing and  where the Python, Ruby, and LISP implementations abstract them so that the user doesn't need to consider them, one Javascript for-loop syntax intertwines the notion of iterator initialization and iterator incrementing with what might be seen as the more  fundamental parts of looping.  Worse, the other two formats, which are almost more like puns on the name for than shared ideas, actually act much more like their Python, et. al., peers, so Javascript can't even make up its mind about what the important parts of looping really are.  The fact that these loops are familiar to developers is not much of a selling point.  Mutation is familiar to developers, OO is familiar to developers.  All sorts of familiar things are pretty awful.

What you're suggesting is putting the initialization in some (to the language) arbitrary position where it only has a meaning because you assign it one (and that location was a different one yesterday).

No, I'm suggesting that we don't use for-loops.  Since while is the only other game in town, I feel as though we're stuck with it.  I'm not particularly concerned with where we put initialization, or even whether it's always required.  I like the change made to stop intializing our counters to -1, but if we found some other way to do the initialization when it's needed, it wouldn't bother me at all.  The fact that it's not always the more familiar way is way, way down on my list of concerns.

But, let's rephrase your statement into using reduce and map:

reduce is clearly the more general of the two constructs, as you can model any map as a reduce, but the reverse is substantially more difficult, perhaps impossible. And since we might need these features, we will need to allow reduce statements. If we disallow map statements, it helps make more obvious how to code your functions.

Do you still agree?

I absolutely would if map were significantly more complex than reduce

I think having a rich (but not too rich vocabulary) is very important when programming. It makes it possible to communicate ones intend better. The for loop is specifically designed for iterating over an array and thus communicates that intend better than a while loop.

No, no, no!  The for loop is not specifically designed for iterating over an array, or it would be be better designed.  LISP, Ruby, and Python proved that it's quite possible.  The for loop is designed to be a general-purpose looping construct, a close-to-the-metal gloss on a looping pattern used in assembly programming.
To me, this is way past the edge, not exactly of too rich, but definitely of too complex.

I don't buy the "while is simpler" argument. True, while is simpler. That is why one should use it when only the limited power of while is required. for captures more complexity. But for iterating over a list with an index (the case we are discussing) it captures the right amount of complexity.

Well, I'm not arguing particularly that while-loops are good, only that for-loops are bad enough to banish them altogether.  Since we still have while-loops available, that's what we're stuck using.  If the language offered a better construct, we would use that.  If, for instance, the for-of-loop was the only one available in JS, I would unhesitatingly prefer that, as it captures the correct level of abstraction.

I would hope you wouldn't mind that code too much! It's all taken from top projects on your Github page. My point was simply that for really does get used in all these ways.

Haha! I didn't recognize the code. Where is the last line from? That is surely a mistake.

synceddb/client/synceddb.js
I had really been hoping to find an example with comma operators inside the for-loops, which is part of what make them so awful to me.  But from the little investigating I did, you don't use that construct.  It is one I've seen far too often, though.

I've never that I can recall seen a comma operator in a while condition.

That because while is to simple that you instead add extra statements before or inside the while loop.

To me that's a big plus!

Okay, that's it from me for now.  Feel free to continue to try to convince me.  But this message was already repetitive, and I'm just likely to get more and more and more and more and more repetitive (see?) if I continue this.  I will respond to this sub-thread only if I find that you or someone else is starting to change my mind.
We do need to put this question to bed soon.  I know that @davidchambers would prefer to at least ease the ban on for-loops, and I know that @buzzdecafe would prefer never to have to look at a for-loop again, and would probably rather to never have to discuss them again either.  I'm not sure what @raine thinks.    Anyone else have input here?
My feeling for the specific case which brought this long discussion on is that for the moment, consistency should still trump.  But I'm more than willing to listen to arguments about this too.

To me, the latter one flows much more smoothly.

While interesting that is not how I read for nor while loops. I don't execute them in my head in that way. I read them from top to bottom once.

No, no, no! The for loop is not specifically designed for iterating over an array, or it would be be better designed. LISP, Ruby, and Python proved that it's quite possible. The for loop is designed to be a general-purpose looping construct, a close-to-the-metal gloss on a looping pattern used in assembly programming.

It is specifically made to capture a looping pattern where one initializes a starting value, declares an end condition and an incrementation.

To me, this is way past the edge, not exactly of too rich, but definitely of too complex.

Instead of focusing so much about whether for loops or while loop I think you should look more at the complexity of the resulting code.

To me that's a big plus!

To me it's a big disadvantage. Having these things contained inside the syntax construct adds structure.

synceddb/client/synceddb.js

I didn't write that :) It's a tiny dependency that I decided to copy directly inside the source code.

My feeling for the specific case which brought this long discussion on is that for the moment, consistency should still trump. But I'm more than willing to listen to arguments about this too.

Consistency in this regard only reduces our vocabulary and thus how precisely we can express ourself in code.
Anyway, when I get the time I'll rebase this PR and switch to while loops.

synceddb/client/synceddb.js

I didn't write that :) It's a tiny dependency that I decided to copy directly inside the source code.

Ahh, I only searched through some of your repos for for.  No wonder you didn't recognize it!

I've now taken the for-loops out of this PR.

:herb:

Well, there is a performance penalty, especially in Firefox.  I don't know how large.  At some point we need to measure this stuff.  Or get input from @megawac.  :smile:

:tada:

At some point we need to measure this stuff.

sure, we can always circle back and optimize certain paths. for now we should worry about the :horse: and the cart can wait. (disappointed there is no :cart: emoji)

Well, there is a performance penalty, especially in Firefox. I don't know how large. At some point we need to measure this stuff. Or get input from @megawac.  :smile:

Arity unwrapping (probably through metadata) would provide a huge boost

hey @megawac did you want me to merge your meta pr into meta branch? or can you re-pr vs meta branch instead?
and i think meta could have a lot of other benefits, including reduced stack size, which means more comprehensible debugging, a space to store function sigs, and possibly even source code. I think there is a lot of potential there.
Sorry for hijacking the thread. carry on.

Can you rebase the meta branch on the pr? I currently don't have proper
internet access (coffee shop life)
On Jun 12, 2015 3:57 PM, "Michael Hurley"<EMAIL_ADDRESS>wrote:

hey @megawac https://github.com/megawac did you want me to merge your
meta pr into meta branch? or can you re-pr vs meta branch instead?
and i think meta could have a lot of other benefits, including reduced
stack size, which means more comprehensible debugging, a space to store
function sigs, and possibly even source code. I think there is a lot of
potential there.
Sorry for hijacking the thread. carry on.
—
Reply to this email directly or view it on GitHub
https://github.com/ramda/ramda/pull/1155#issuecomment-111599383.

i feel your pain. i'll give it a shot.
:coffee:


TabView: Tab opening animation not as good as Chromium Edge

On a surface level, this is basically the same as #1511, but for when tabs are opened. In Chromium Edge, the tabs seem to "slide in", increasing their width smoothly from 0 to (some tab width) as the tab is added to the view. In the Microsoft.UI.Xaml.2.3.191217003 release being used by the Windows Terminal currently, the tab view seems to reserve the entire width of the new tab immediately, then the tab "fades in" to the space reserved for it.
This can be seen pretty readily in the XAML Controls Gallery app (as well as the Windows Terminal).
/cc @DHowett-MSFT

@stmoy TabView uses the theme transitions currently. We could possibly re-visit this once we move to ItemsRepeater where we have better options to customize the animations.

@zadjii-msft this will likely get rolled into #1332


Skip interaction test

The current interaction test is less informative.

I'm sorry for noisy wrong pull-request.


Plugin changelog is not shown without install_plugins cap.

https://github.com/szepeviktor/wordpress-website-lifecycle/blob/383e73edcab65d04c727edbc036d673508a8d6b5/mu-plugins/_core-disallow-updates.php#L15
@johnbillion Could it be that showing changelog on the Plugins page needs install_plugins cap.?
Link: "View version 3.23.2 details"

Sorry, you are not allowed to access this page.

Is it a core bug?

Yes that could well be a bug

Here it is. Even for install_plugins_pre_plugin-information.
https://github.com/WordPress/WordPress/blob/afd60dd8a467eb8620b2ce32277b9ce8b6248c15/wp-admin/plugin-install.php#L18-L20

A work-around
document.querySelectorAll(".thickbox.open-plugin-details-modal[href*='section=changelog']").forEach(anchor => anchor.classList.add("hidden-field"));


Fix Compile error on Desktop, Update Readme

Fixes a incredibly small compile error caused by desktop using a using statement that is only available when compiling for android,
also removed a bullet point from the Readme as the Android port done by Beyley and daCyuubi is now complete.
(also speaking of bullet points, im currently planning to potentially write a whole mapping guide on how to get everything set up and how to map for osu!stream so that might soon be coming)

Let me know via an issue or email if you need any help with the mapping tools beyond the provided google doc guide.

ill let you know if thats the case, although i think by reading through the code and said google doc ill find everything ill need


First Launch Not Working

I just give Photino a try and I couldn't even run it:
PS C:\Programming Projects\Photino-Applications\Photino-App> dotnet run
C:\Programming Projects\Photino-Applications\Photino-App\HelloPhotino.NET.csproj : error NU1202: Package Photino.NET 1.1.6 is not compatible with net50 (.NETFramework,Version=v5.0). Package Photino.NET 1.1.6 supports: netstandard2.1 (.NETStandard,Version=v2.1)
C:\Programming Projects\Photino-Applications\Photino-App\HelloPhotino.NET.csproj : error NU1202: Package Photino.NET 1.1.6 is not compatible with net50 (.NETFramework,Version=v5.0) / win7-x86. Package Photino.NET 1.1.6 supports: netstandard2.1 (.NETStandard,Version=v2.1)

The build failed. Please fix the build errors and run again.

Any idea what going on?
Thanks in advance!

@KiddoV This is almost certainly an issue with installing .NET through a snap/package manager. Please see the link under Dependencies on this page for instructions on how to do a manual install of the framework. .NET 5 just doesn't like to run sandboxed!

@MikeYeager Sorry, I tried as the page said but still not working... same error...

@KiddoV We just had another look at the error messages you posted and noticed Win7-x86 in on of the lines. Are you running on a 32bit OS? Currently, we only support 64bit. We have not gotten around to trying to compile for 32 bit yet.

@MikeYeager Yes I'm running it on Window 10 - 64bit. I don't know why it is output as "win7-x86". Clearly it is Win10 - 64bit.

@KiddoV Thanks for the info. It's clearly a NuGet issue, but I don't know why you're getting it. The folder structure is a bit unusual for the HelloPhotino.NET project, but that shouldn't be an issue. What does running 'dotnet restore' output? Also, can you open the .csproj file in an editor and paste its contents here? Thanks.

@MikeYeager
dotnet restore
MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.

.csproj
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <Platforms>AnyCPU;x64</Platforms>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Photino.NET" Version="1.1.6" />
  </ItemGroup>

  <ItemGroup>
    <None Update="wwwroot\**">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
  </ItemGroup>

</Project>

Here you go!

@KiddoV Thank you for the info. The project file looks great. We will keep digging to find an answer for the NuGet issue.

Photino v2 has been released. Please update to the new version and give it a try. Let us know if you're stull encountering that issue.


[PE-D][Tester C] Cannot return back to previous state with Find

It is not possible to return to the original client list after a find command, resulting in major issues.

Undo-ing action does not restore the original list back.

It is not possible to select any clients from this point forward. The user is essentially forced to restart.

In AB3, the command List is used to restore all clients back after a find command. Can consider using this implementation.

Labels: severity.High type.FeatureFlaw
original: junianob/ped#4

Find does not modify the data of the client in the application, it only uses a filtered list. Hence, undo won't work, we have clarified this in the user guide.


Updated classes Record and Contacts

Added methods for class Record:
Added method next for class Contacts

better use remove() method on self.phones rather than overwriting the whole list.
how exactly next works? what is sorted_data?


Expose new metrics for memory usage in the container.

The metric "mem_kmem_usage_bytes" is the total kernel memory usage by
processes in the cgroup in bytes.
The metric "mem_kmem_tcp_usage_bytes" is the total memory usage for TCP
buffers in bytes.

I don't think we turn on kmem accounting yet in Mesos containerizer.
I remember in old kernels, you need to set kmem.limit_in_bytes once to enable kmem accounting. I am not sure about the new kernel behavior.
Also, we need to be careful on bugs like this on old kernels if we turn on kmem accounting
https://github.com/opencontainers/runc/issues/1725

We've been running with this patch at Twitter since February and we're getting kmem metrics.
The mentioned bug is interesting, we've only been running with 4.9 and later.

I am not sure if the kernel behavior has changed or not in newer kernels. For example:
https://github.com/opencontainers/runc/blob/7139b61f7fdb904d0acb8db825709aa8d2d2ef36/libcontainer/cgroups/fs/memory.go#L70
You'll have to write memory.kmem.limit_in_bytes to enable kmem accounting
So if kmem accounting is not enabled, i don't know what will happen if you read the data from memory.kmem.usage_in_bytes. Let me do some testing on my CentOS 7 default kernel (3.10)

Looks like on CentOS 7 (3.10.0-693.5.2.el7.x86_64). If kmem accounting is not enabled, the memory.kmem.limit_in_bytes will always show 0. And reading memory.kmem.slabinfo will give Input/output error
I think we should probably add an agent flag to control the enabling of kmem accounting feature, and only report stats if kmem accounting is enabled.

@fcuny We prefer reviewboard for non trivial changes.

@fcuny were you going to continue this work on ReviewBoard?


The build environment should set C.UTF-8 by default

See original issue on GitLab
In GitLab by [Gitlab user @jjardon] on Feb 20, 2018, 14:38
Or you will get warnings/errors like this one:
Warning: You are using 'ANSI_X3.4-1968' which is not a Unicode-compatible locale.
You might see errors if you use UTF-8 strings as filenames, as strings, or as file contents.
Please switch to a UTF-8 locale for your platform

In GitLab by [Gitlab user @jjardon] on Feb 20, 2018, 14:42
changed title from The build environment should set UTF-8 by default to The build environment should set {+C.+}UTF-8 by default

In GitLab by [Gitlab user @tristanvb] on Feb 20, 2018, 14:54
I think we set the only locale which is known to exist for sure, e.g. either "C" or "POSIX" in the build environment; we certainly do not set "ANSI_X3.4-1968" - are you sure this is from the build environment and not from buildstream itself running in a "ANSI_X3.4-1968" locale ? BuildStream itself, because of python3 weirdness, has a hard requirement on UTF-8 encoding.
If you have build elements which require custom things beyond the very basic essentials; like UTF-8 support, just in order to build; should those environment settings not be setup in a custom way for that project or specific element even ? I would think so.

In GitLab by [Gitlab user @tristanvb] on Feb 20, 2018, 14:57
Right, currently we set the neutral locale C by default via LC_ALL.
A project can overwrite this with the following in project.conf:

environment:
  LC_ALL: en_US.utf8

Unfortunately, there is also not any language neutral utf8 locale either, so you would depend on your runtime providing exactly en_US for this to work (but as the project author, at least you would know that it's there).

In GitLab by [Gitlab user @jjardon] on Feb 20, 2018, 15:47
C.UTF-8 is supported by Fedora and Debian, in case you don't have any locale at all installed, see https://bugzilla.redhat.com/show_bug.cgi?id=902094
If this is not possible to implement, maybe we could default to en_US.utf8 by default? I think UTF-8 is something very basic we should expect to work nowadays

In GitLab by [Gitlab user @tristanvb] on Feb 20, 2018, 17:26
By the referred bug report, it looks like something quite custom that debian, and now fedora are doing.
This doesnt sound like a great candidate for a default value, what happens when you try to use C.UTF-8 on a system that doesnt have this ?
On the other hand, C locale exists afaik, probably since LC_ALL was a recognized environment variable, or possibly before, so seems much more safe.

In GitLab by [Gitlab user @tristanvb] on Feb 20, 2018, 17:28
Oh and to clarify:

If this is not possible to implement

It is most certainly not, ever possible to implement from a BuildStream point of view; because BuildStream must not make any assumptions about the payload of what is getting built inside sandboxes.
I'm already reluctant to live with the few assumptions we make, e.g. we assume that on linux, a null device belongs in /dev and not in /usr/share/devices; while device tree layout is apparently POSIX, it's more correct to not have to assume POSIX compliance.

In GitLab by [Gitlab user @tristanvb] on Feb 21, 2018, 08:48
This could have a mention perhaps in a user guide if anywhere.
The tricky problem here, is that we should be documenting BuildStream in the BuildStream documentation, we should not get into the business of educating people how to build and integrate specific operating systems, this is a huge knowledge base that varies in many ways from one operating system to another.
FWIW, it looks like this is already handled in the gnome-build-meta repository (this repository happens to know there is an en_US.UTF-8 locale and sets it up), I dont believe I set this up as a workaround for the mentioned meson issue; but rather so that programs behave better in a bst shell environment.

In GitLab by [Gitlab user @jjardon] on Feb 21, 2018, 13:37
Yeah, seems its present in gnome-build-meta at https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/project.conf#L63
We are going to do the same in our project too: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/122/diffs , but I guess this will affect to any project with components built with meson

In GitLab by [Gitlab user @tristanvb] on Feb 24, 2018, 14:16
I'm gonna wontfix close this, as I think its better to not make assumptions about the runtime people are building.

In GitLab by [Gitlab user @tristanvb] on Feb 24, 2018, 14:16
closed


fix: remove gene following call for logged out experience

The type of this PR is: Fix

This PR solves DIA-845
Description

I think if the purpose of it is just to get rid of the extra request instead of scrapping the data from the page to use with FollowGeneButton we can just use the fragment directly since it depends on gene data already and then remove this query renderer element.

Yeah that sounds like a plan!

@egdbear - can we be sure to write proper PR descriptions? Linking out to JIRA and providing titles alone doesn't supply enough context within the github / repo ecosystem for future devs to understand the change.

@egdbear - can we be sure to write proper PR descriptions? Linking out to JIRA and providing titles alone doesn't supply enough context within the github / repo ecosystem for future devs to understand the change.

of course, sorry this was already discussed on the slack thread, will add the description!

Thanks, yah, I try to think about PRs as artifacts best viewed 3-5 years in the future. At that point nobody will know what slack convo something referenced, and JIRA might be gone, and so on and so forth. So Github should remain canonical as the source of truth 🙏


Calibration and interpretation of log_scale parameter is poor

Hi! a quick update on the emcee convergence issue. I have the following situation:

I am working with flux-calibrated data
I have a stellar model with flux computed at the surface of the star
I am trying to fit for the log_scale parameter and use that to calculate the radius

The problem however is that within the spectrum model code, the log_scale is scaling the normalized emulator interpolated spectrum (mean flux) to match the flux calibrated data flux, and so the best log_scale doesn't fall within physically realistic radius values.
        # Only rescale flux_mean and flux_std
        if "log_scale" in self.params:
            scale = np.exp(self.params["log_scale"])
            fluxes[-2:] = rescale(fluxes[-2:], scale)

Additionally, say for example if my raw model flux (computed at the surface of the star) is about 10-20 dex higher than the flux calibrated data, and I use an optimum log_scale that visually works well to match the two, then the emcee posteriors for all best fit parameters appeared flat. The same happens when I do not fit for log_scale and simply let it autoscale (the following code). I understand this huge scaling offset between data and model is contributing massively to the covariance matrix.
        # Renorm to data flux if no "log_scale" provided
        if "log_scale" not in self.params:
            factor = _get_renorm_factor(self.data.wave, flux, self.data.flux)
            flux = rescale(flux, factor)
            X = rescale(X, factor)

The only situation where I get well constrained posteriors for all parameters is when I  scale up the flux calibrated data to roughly match the level of the stellar model flux at the surface of the star before performing the fit.
This is an example of the retrieved Teff, both when I fit for a visually good log_scale with appropriate priors and also when I do not fit for log_scale at all and let it autoscale.

This is an example of the same retrieved Teff, where I again fit for a visually good log_scale and also when I do not fit for log_scale at all, only here I've modified the input flux calibrated data to roughly match the level of the model flux at the surface of the star. Of course this is not the desired way to do this if I'm looking to properly solve for the radius of the object.

I'm wondering if this version of the code stores the flux scaling value somewhere before everything gets normalized inside the emulator? Maybe I could call that value and use it within the spectrum model code to specifically fit for a log((R/d)^2)? Thanks!
Originally posted by @iyera22 in https://github.com/iancze/Starfish/issues/136#issuecomment-819817356

So the automatic rescaling finds the ratio of integrated flux between the data and the model, its roughly equivalent to
factor = np.trapz(data, wl) / np.trapz(model, wl)
return model * factor

I would recommend running this (or calling the _get_renorm_factor function manually) and using that as a starting point.
As for the interpretability of the log_scale parameter, I'm not really sure what you are doing. I have never used calibrated spectra myself and I'm not actively doing spectroscopy anymore, so it's beyond my knowledge, unfortunately. Perhaps @iancze can help explain?

I'm wondering if there might be a units issue going on here.
(Obviously) for the comparison both data and model should be in the same units. When dealing with non-flux calibrated spectra, it's easy to wrap any pre-factors for distance scale back into the normalization constant. This can also obscure more subtle points like the different sampling density if one spectrum is in counts/pixel and the other is in ergs/s/cm^2/A for example, and would also paper over any possible bugs in Starfish.
We used flux-calibrated spectra for the 2015 paper, so in principle this is definitely possible. But that solution w.r.t. the distance scaling was fairly hacky, so hopefully we (Miles) managed to fix it with the emulator improvements. To dig into what's going on, I would hold off on full-sampling for the moment, and try to bound the problem with some debugging data

What are the units of your flux-calibrated spectra?
If you integrate up all the flux (+ a possible bolometric correction), do you recover a synthetic photometric magnitude that makes sense compared to existing data?
Given an estimate of stellar parameters, does Starfish return a model spectrum that makes sense (maybe Miles can point to an example here just querying a spectrum w/out needing to sample)? Are there any functional differences between the code that produces a single spectrum vs. how the sampling loop is implemented? Is it possible we're missing a conversion factor in one of the routines?

@iyera22 you are absolutely right that getting log_scale in the ballpark is the most important thing for doing the sampling correctly. Hopefully we can converge to the answer/bug solution quickly by bounding it w/ these examples. It's possible Starfish is doing the renormalization incorrectly relative to the emulator. The emulator source code is here for reference.

Sure, thank you!

I'm working with ergs/cm2/s/cm units for my flux-calibrated data
Yes, upon integrating the flux I can go back and get a photometric magnitude that compares to the data I'm working with.
A single call of the SpectrumModel object gives a model spectrum that looks reasonable in shape, and it appears to be scaled to match the flux calibrated data. So of course even a grid point model spectrum doesn't match a SpectrumModel call as the interpolated model is scaled to match the data.

Whether I include a log_scale parameter or not it uses either of the two code snippets I mentioned in my post above so I believe it is still scaling the mean flux calculated from the emulator to match the data first and then completing the reconstruction with the weights. I also think this is the same when implementing the sampling loop, I don't see a major difference overall.
So if I use a log_scale, that is again calling the rescale function from transforms.py that is essentially scaling up the mean flux from the emulator or simply using a factor value to calculate the offset between the mean emulator flux and the data following the code snippet from Miles' post above. I wonder if the 'true' scaling value is recorded somewhere before everything gets normalized within the emulator? I think after that point the SpectrumModel object only refers to the eigenspectra and the mean flux that is coming out of the emulator and so perhaps that initial scaling from the raw model spectrum flux gets forgotten somewhere?
Upon checking the emulator source code it is consistent in that the only outputs there are the eigenpectra, weights and the mean flux (+mean std). I was hoping maybe if this were modified to spit out the offset between the mean / normalized emulator interpolated spectrum from the original raw model flux from the grid (at the surface of the star) then I could add that to the log_scale parameter called within the Spectrum Model code when calculating the 'true offset' between the model and the data.

I believe it is still scaling the mean flux calculated from the emulator to match the data first and then completing the reconstruction with the weights

to be clear, the log_scale is a purely multiplicative factor. In the current modeling code you see it is only applied to flux_mean and flux_std, but then later you'll find
flux = (weights @ eigenspectra) * flux_std + flux_mean

so we can do some mental algebra and see that rescaling just the mean and std has the exact same effect as scaling the flux after reconstructing from the eigenspectra
flux = factor * ((weights * eigenspectra) * flux_std + flux_mean)
# is equivalent to
flux = (weights * eigenspectra) * (flux_std * factor) + (flux_mean * factor)

This happens every time inside the model evaluation (calling model()), which is what is called by the log-likelihood code (which is what is called by the built-in optimize code), so there is no opportunity for inconsistency there.

I was hoping maybe if this were modified to spit out the offset between the mean / normalized emulator interpolated spectrum from the original raw model flux

For my undergrad research we used unnormalized data like I mentioned, so the current model is basically set up as either "you fit log_scale fully" or "you never fit log_scale". My advice is still to manually alter log_scale to taste (using diagnostics with model.plot()) or manually calculate the ratio (or integrated flux ratio) between emulator.flux_mean and your data and use that as a starting point.

Hi, thanks for the clarification,

Ok, so the factor term (manually calculated or not, using log_scale) is the ratio between the integrated fluxes of
(a) mean flux from the emulator (flux_mean)
vs
(b) the flux calibrated data spectrum (self.data.flux inside the SpectrumModel class), correct?
(as the emulator normalizes my original model grid spectra to 1 to remove any ‘uninteresting correlations’ as shown here:)
(inside emulator.py)

        fluxes = np.array(list(grid.fluxes))
        # Normalize to an average of 1 to remove uninteresting correlation
        fluxes /= fluxes.mean(1, keepdims=True)

so is log_scale here really log(R^2/D^2)? What I am looking for is the ratio between the non-normalized grid model flux (my original model grid + model spectra for interpolated parameter values before the normalization in the emulator occurs) Vs the flux calibrated data (observed star) as that scaling will be helpful to calculate (R/D)^2 to get constraints on the radius. Am I missing something?

The other issue I’m having is that if I do not bother to fit the log_scale at all (say I fit only for Teff, logZ, logg), this is the scenario:  For example, if the integrated flux of my stellar grid model spectra at the surface of the star is roughly of order 1e13, and the integrated flux of my flux calibrated data is of order 1e-7 both in same physical units (ergs/s/cm2/cm), running the two through Starfish (with a properly converged emulator object, and then calling a SpectrumModel object and defining rough Teff, logZ, logg values and running that through MAP & emcee where the log_scale gets automatically calculated using the _get_renorm_factor function and the model spectra gets scaled accordingly to match the data) then I get badly constrained posteriors as shown above.
-->The fits work fine ONLY when I go the opposite way (modify my data spectrum and not the model) where I do not modify the model spectrum at all, and instead scale up my flux calibrated data spectrum by a constant value to roughly match the level of the raw grid model spectra at the stellar surface (i.e. scaling up from the data spectrum from 1e-7 to 1e13) and then run both through Starfish without fitting for log_scale (where it would autoscale the normalized emulator model to now match the artificially scaled data i.e to 1e13 order of magnitude), then I get well constrained posteriors. Does this mean that in the former case the huge scaling difference between the original data spectrum (of order 1e-7) and original grid model spectrum (of order 1e13) is causing the covariance matrix to blow up despite log_scale autoscaling everything before computing the likelihood? Would you have an idea of what might be the issue here? I'm happy to send out my spectrum model+emulator with my grid model files separately to debug if needed.

I am somewhat set for now, as I'm currently following the ‘opposite approach’ where I un-dilute my flux calibrated data spectrum by a constant value so it matches the order of magnitude of my original model grid spectrum at the surface of the star and then perform the starfish sampling, not fitting for log_scale (and let it autoscale). This hacky way seems to work fine for a couple of targets I’ve tried and for the purposes of my work for now, but I hope there would be a more straightforward way of solving for the radius from the starfish fits in a future upgrade? Thanks!

Okay, I think I've fully got my head wrapped around the problem-
When you create an emulator from a grid it becomes unitless because of https://github.com/iancze/Starfish/blob/fceb6cc41ddec569c95e4157c8406c0b586f6140/Starfish/emulator/emulator.py#L286
so log_scale cannot be interpreted physically.
I think the easiest way to resolve this would be to add an option to Emulator.from_grid to skip this normalization. @iancze do you remember if the emulator can perform alright without this pre-processing step?

Based on my discussion with @iyera22 in a separate slack channel several days ago, I think the issue of log_scale might have something to do with the emulator.absolute_flux parameter or self.flux_scalar in the update_Theta() function of star_class.py:
https://github.com/gully/Starfish/blob/fe9879b67a12ddd1a101cf07c60de25bdb46a705/Starfish/emulator.py#L142
This was initially suggested by @gully in his mix_model_omega2 branch - see detailed discussions here: https://github.com/iancze/Starfish/issues/38
If we would like to keep this feature for the new Starfish version -
When updating the Theta parameters during fitting, the physical parameter Omega should be thereby scaled by such a flux_scalar factor (interpolated at the current grid parameters) to produce the "correct" fluxes for reconstructed spectra. For example,
https://github.com/zjzhang42/Starfish/blob/eeed1f05370282ad6117f591871cd596d2711a8e/scripts/star_class.py#L346
Hope this helps.

Thank you both! Yea that would be a helpful feature, although I'm wondering how significant the correlation can be if not normalized within the emulator reconstruction? How much would that affect the covariance matrix?

Re: Miles' point about normalization: The PHOENIX spectral grid is provided in units of intensity at the stellar surface (if my memory serves me correctly) so there is intrinsically a very large change in amplitude from say 3200K to 7000K. While in theory you might be able to construct an emulator directly on the unnormalized spectra, it would make the PCA decomposition very inefficient. The largest variation in an unnormalized grid is due to the amplitude differences, so several PCA terms would need to be devoted to absorbing this amplitude change. That's the main reason why the each spectrum is normalized to 1 mean before PCA.
One solution to this is to keep track of the amplitude term as a function of Teff, logg, Z, etc... as the emulator is being constructed, and create a smooth interpolator object for these normalizations. Then, when the emulator reconstructs spectra, the amplitude normalization can be applied after the fact. I remember @gully and I had discussed this at some point, but I forget if we ever actually implemented it, and how that factored into Miles' rewrite. Hence the confusing issue we now have! My apologies for loosing track of this!
As it stands, it looks like the physical interpretation of log_scale is incorrect... it's merely a nuisance parameter. I think the suggestion by @zjzhang42 sounds like a reasonable approach to produce correct fluxes.
In the end, though, this is probably only worth it if you are additionally fitting photometry simultaneously with the spectra via synthetic photometry. Spectrophotometric flux calibration uncertainties are in general worse than photometric calibration uncertainties. So, unless you are fitting to additional photometric points, I would think that the estimate of stellar radius that comes from fitting spectra alone will have a significant uncertainty attached to it.

I agree with everything @iancze said!  I already implemented the interpolation of flux scalars as a term flux_scalars, which is implemented my (undocumented) mix_model_omega2 branch, and maybe slightly more legibly in the application to Brown Dwarf spectra that I wrote with Mark Marley and that has ZJ applied in recent publications:
https://github.com/gully/jammer-Gl570D
And to reiterate what Ian said, the principal application for this feature is either if you have (accurate) flux calibrated spectra or photometry, you're simultaneously fitting photometry, or you're fitting a mixture model of two spectra and the relative fluxes matter as in Gully-Santiago et al. 2017..

In fact, Appendix A of Gully-Santiago et al. 2017 lays out the math for the implementation, see text starting with:

The reason for standardizing the flux is a matter of practicality: the number of PCA eigenspectra components in the spectral emulator scales steeply with the pixel-to-pixel variance of...

We tweaked the implementation since then to improve the accuracy for high dynamic range of temperatures.

The interpretation of log_scale was previously noted as depending on the use case in #37

Thank you all, this is definitely helpful and yes I agree with @iancze and @gully I am in fact working with flux calibrated spectra (hopefully accurate enough), so I am hoping this flux_scalar value can help me get the radius.

Thanks all, I'm trying to revisit this issue, I have a question for @gully, I'm trying to test out the implementation from your branch especially 'star_marley.py' (I hope I'm looking in the right place, I'm a bit lost) and I needed clarification on which Starfish version is needed to support this. I gather the emulator.py file that includes the interpolation for the flux_scalar value is in version 2.0? could you confirm? I was also wondering I don't see a function to train the emulator in that version, could I get more guidance on how to get started? What's a more efficient way to include log omega in the sampling with v.3.0?

Specifically, what I'm looking for is something similar to the example implementation of brown dwarf low res data that you mentioned and that @zjzhang42 has demonstrated in his paper, by fitting for log_omega as an additional physical parameter. Is there a branch compatible with v3.0 that includes this?

@iyera22  the functionality Gully mentioned is not compatible with v0.3 of Starfish (yet).

Hi @iyera22, I spoke with @zjzhang42 and he plans to make his version of my version of Ian's version of Starfish public. Lol, that's a lot of versions...  @mileslucas 's version (v0.3) is incompatible with my version, and by extension ZJ's version.  It looks like Miles is working to rectify these two versions.  It sounds like you should connect with ZJ to get the brown dwarf version working, or wait for Miles' extended version.  Does that address your question?

@gully @zjzhang42 that's great to hear. Perhaps it makes sense for me to migrate iancze/Starfish to a Github organization like Starfish-dev/Starfish, and give you all maintainer access? I think it would be really great for the long-term health of the package if we could centralize development around forks and pull requests back to a single repository.

Maybe!  I'd say let's wait for ZJ's version to appear so we can see what differences there are?  Or maybe we're talking about other bigger/broader scope and experimentation?
I've thought of making a new code that's a microservice for programmatic access to synthetic spectral models, some of which is implemented in Starfish already.  The core Starfish functionality could be the spectral emulation and likelihood functions, with an abstraction layer for the raw model access.  I'm not completely sold on this idea, just a thought I had recently... the resulting surgery on Starfish might cause other unintended consequences.  But my point is that Starfish supporting the model access, the emulator, and the likelihood could be cut into pieces to make the code more sustainable, and a microservice for raw model access may be easier to maintain and extended for new entrants.

Thank you! That would be tremendously helpful! I look forward to the release of @zjzhang42 's version and this potential new flexible version.

@gully I'm on board with the idea of splitting Starfish into smaller, more maintainable modules focused on specific use cases, not unlike the exoplanet-dev organization. I think the grid access, emulator, and likelihood are great examples to draw the line, and something like a starfish-dev organization would be a great way to centralize all of this.
@mileslucas already did a lot of legwork to make everything more modular in v0.3, and I would envision this as building on that to its logical conclusion. This would also make it easier to rewrite, say, the likelihood component to be autodiff capable.
But I think even before that, centralizing around a single Starfish-dev organization would help coordinate development efforts.

Ah I understand the proposition now, making a GitHub organization.  Yeah, sure I think that's a great idea.  Loosely affiliated collections of packages can be stuck there too.  And experimental new versions can be stuck there too.
Also yes, autodiffable (or if someone has the guts to write out the analytical derivatives) is the way to go.  One issue may be making the interpolation and resampling step autodiffable.  I tried several times to figure this out and a few of those worked with different tradeoffs.  But anyways that's a completely different issue unrelated to this one.

I just notice that most of the Starfish scripts I used and modified are already in my branch: https://github.com/zjzhang42/Starfish/tree/ZJ_BD_v0 And I strongly agree that we should merge all these branches into a solid single package.
To illustrate how to combine all these separate scripts to complete a spectral fitting, I could provide the yaml and bash scripts as examples. All these would probably come after July, as I am now overwhelmed by an upcoming PhD defense.


Add @GraphQLRootContext injection of graphql.GraphQLContext

Changes:

RootContextInjector support for injection of graphql.GraphQLContext added
ArgumentInjectionTest test for graphql.GraphQLContext injection added

Fixes #405

@kaqqao bumping so it won't be forgotten

@GoodforGod Thanks!


[ISSUE] DeviantArt Token Refresher Seems to Be Broken

Current Behavior
It seems like the backend token refresher broke since v1.4.2.
Expected Behavior
Refresh the tokens with the PostgreSQL server
Steps To Reproduce

Run any of the DA Cmds
Get the OAuth2 expired reason

Environment

OS: Ubuntu 20.04.03 LTS on Windows 10 Pro
Python Version: 3.10.2
pip version: 21.3.1
pipenv version: 2022.1.8
Found on Discord?: Yes

Anything else?
pretty sure i broke it by replacing it with the stream methods instead. That may be the reason why it is broke
Is there an existing issue for this?

[X] I have searched the existing issues

Most likely since the functions are coroutines, it may not be called correctly (I've tested this separately and it doesn't seem to be an issue). Could be that it's not able to send the http request

May need to switch to a class based approach. This way we can use methods instead of functions

seems like it's something to do with discord.ext.tasks not working (meaning that pycord is not working as needed)

It seems like the issue is on uvloop....

it seems like uvloop screws up the discord.ext.tasks module, so im moving the DeviantArt Token Refresher cog to a separate script and docker container


PLC0414 false positive for stubs

PLC0414 should not be applied to .pyi. Explicit re-exports are a valid convention to indicate that a type is meant to be exposed as re-exported, and isn't just used in the stub for typing reference.
https://github.com/python/typeshed/blob/main/CONTRIBUTING.md#conventions

Imports in stubs are considered private (not part of the exported API) unless:

they use the form from library import name as name (sic, using explicit as even if the name stays the same); or
they use the form from library import * which means all names from that library are exported.

For example:
from ._modules import controller as controller, event as event, gui as gui, memory as memory, savestate as savestate

It looks like Pylint does flag these in .pyi files so this would be a deviation.
I'm actually kind of surprised this rule exists at all any more. Isn't explicit re-export part of the de facto public / private standard used by type checkers? E.g., see Pyright.

Pylint does not support type stubs: https://github.com/PyCQA/pylint/issues/4987

Ah yeah. I mean, we definitely could disable this rule in .pyi files. It's just that the logic could also apply to .py files. But if no one would ever want this enforced in a .pyi file (but some would want it enforced in .pyi files), then I'd err on the side of disabling it in .pyi files.

Figured why not fix, better than flagging the .pyi files.


Refgenie digets

What is the final refgenie digest algorithm?

Once this is solved, we can upload the data under the new digests to S3.


Fix the cirq to stim conversion for circuits with tagged operations

In particular, tagged loops will make following check fail
if isinstance(op, cirq.CircuitOperation):
        self.process_circuit_operation_into_repeat_block(op)
        continue

Since the conversion function seems to be ignoring the tags, I simply untagged them at the beginning of the loop and let everything else proceed with the same current assumption of untagged operations.

General suggestion, is there a place we can add a test for this? Something simple with a CircuitOperation checking for these TICKs that fails before this change? Just for good practice.


"alternate" vs "alternative"

Hi, I think it's a bit unfortunate that this extension uses the word "alternate" to describe a different location one can choose to access data from. "alternative" is more widely understood to describe choice between options - "alternate" is an Americanism and it might even be considered incorrect to use "alternate" to describe choice rather than substitution in the US.
Using "alternate" in this context seems to be a chiefly American thing, while British English (and I believe Australian English and other English varieties) would use "alternative". For BE speakers, "alternate" means "to happen or exist one after the other repeatedly" or "every other". By no means it is better to prioritise BE over AE but I'd argue that "alternative" would be more universally understood by the global English language community to express choice between options as AE also knows and uses "alternative" at least as a noun in this context (as an adjective, "alternate" might be preferred over "alternative" in the US?). It is noteworthy however that the Grammarist, writing from an AE POV, maintains that "[a]n alternate is something or someone that serves in place of another. An alternative is a second option that does not replace the first." - in which case "alternate" would be considered incorrect even in the US since we're talking about choice here (the article goes on to state that the corresponding adjectives have the same difference in meaning).
I know this is nitpicky and I'm not saying "alternative" is clearly preferable over "alternate" or that a somewhat established STAC extension should be changed now. But maybe take this comment as a suggestion to be mindful of such differences for future extensions. STAC is not an American extension but to be used by a global community that speak different varieties of English as their first or second language. Additionally, I'm not even sure if "alternate" would be appropriate to use in formal AE. Maybe it's just me but as someone more familiar with BE I wasn't even aware "alternate" could mean "alternative" in the US and not just "every other".
Additional sources:

Cambridge Dictionary alternative/alternate
Collins Dictionary: What is the difference between alternate and alternative

I agree that alternative is likely easier to understand. Unfortunately, the IANA relation type is also called "alternate" and it is used throughout multiple extensions and specifications now so it's unlikely a switch to "alternative" is viable.


Update WVD references to AVD

Update WVD references to AVD.

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

ID: fb9a6dfb-2853-20fc-bd6c-2f636945b328
Version Independent ID: 60586381-2d76-32bc-8e44-342ee36ada1c
Content: Onboard Windows multi-session devices in Azure Virtual Desktop
Content Source: microsoft-365/security/defender-endpoint/onboard-windows-multi-session-device.md
Product: w10
GitHub Login: @Dansimp
Microsoft Alias: dansimp

@ncdlloyd Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/8747
Once the author approves, the changes will be live.
Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @ncdlloyd Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Spearbit3: fix upgradeable gas size

Description
https://github.com/connext/nxtp/issues/2155

Type of change

[ ] Docs change / dependency upgrade
[ ] Configuration / tooling changes
[ ] Refactoring
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Requires changes in customer code

High-level change(s) description - from the user's perspective

Related Issue(s)
https://github.com/connext/nxtp/issues/2155
https://github.com/spearbit-audits/connext-nxtp/pull/3
Fixes
Related pull request(s)

Fixed in https://github.com/connext/nxtp/pull/2342


Behavior of arraySegment.ToArray() has changed

I was using Enumerable.ToArray(this IEnumerable) on an ArraySegment, which calls ArraySegment.GetEnumerator(). This did not throw any exception when the underlying array is null, so ToArray() would return an empty array.
Now that ArraySegment has its own ToArray() function, my code is calling that one (with no code change on my part). ArraySegment.ToArray() throws an exception when called with a null underlying array.
I can work around this, but is this considered a breaking change?

This issue was moved to dotnet/corefx#19799


Feature request: Display of current preset name

Hi,
it would be nice, if the current preset name could be displayed on the main screen, as you can’t see, which preset currently is saved to a channel.
A plus would be, if the preset name could be preselected, when saving the preset, after making changes to it. Currently this only works, when selecting the preset in the preset tab first, but not, when selecting a channel and then saving the preset.
Regards
TullyMore
Devices and versions:
Android 13 on Samsung Galaxy A52s 5G
Android 8.1.0 on Samsung Galaxy Tab A (2016)
Mightier Amp v0.9.6 with all permissions granted

Added in 0.9.8

Hi,
thanks for your ongoing efforts. Will check on issues #53, #54 and # 55 when I find the time. Great job as always!
Regards
TullyMore

Hi,
the current preset name is shown now, which is really nice. Unfortunately it's not visible in landscape mode as the row with the bluetooth sign isn't shown.
Regards
TullyMore

On many devices the controls in landscape mode are very squished even without the bar on top. That's why the bar is integrated into the side bar.

Just use the arrow to expand it.

I had the chance to test the app with a few tablets and it turns out that on some of them, the app switches to some kind of portrait mode, even though they are in landscape mode. However, the app bar is missing in this 3rd mode. I think this happens only on very high-density screens, and there's more than enough space for the app bar. I'll look into adding it for this mode.
Just to confirm it's the same thing. When you say you don't have the app bar, is the app looking the same as in portrait mode - with the tabs on the bottom, or is it looking like the screenshot from my previous post - with a sidebar?

Hi,
it's looking like in you screenshot on all of my devices.
Android 13 on Samsung Galaxy A52s 5G
Android 8.1.0 on Samsung Galaxy Tab A (2016)
Android 7.1.2 on Nexus 7
Mightier Amp v0.9.6

The new version will display the full title bar and tabs on the bottom in landscape mode if there's enough screen space to fit everything vertically. This should be the case for most tablets. Phones will use the interface from the screenshot above.

Hi,
works great and looking good on my Tablet. Great job!
regards
TullyMore

Hi,
enjoying my holidays and spending my time with the Mighty Air.
Showing the preset works fine, when the preset is selected from the editor tab. Alas, when you select any of the stored presets on channels 1 to 7, the name isn't shown. Any chance to fix that?
regards
TullyMore

Hi,
could I ask again for implementing the feature I mentioned in my last comment?
It would be nice to see the name of the current preset, that is stored on a channel. Currently it's only shown, when loading a preset via the presets tab. Ideally this would also work, when selecting a channel using the channel button on the Mighty Air.
As a plus, the current preset then would be pre-selected when saving it, after making changes to it.
regards
TullyMore


vae.py

ValueError: The model cannot be compiled because it has no loss to optimize.

ValueError                                Traceback (most recent call last)
 in
5 vae = VAE(encoder, decoder)
6 vae.compile(optimizer=keras.optimizers.Adam())
----> 7 vae.fit(mnist_digits, epochs=30, batch_size=128)
/opt/conda/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in fit(self, x, y, batch_size, epochs, verbose, callbacks, validation_split, validation_data, shuffle, class_weight, sample_weight, initial_epoch, steps_per_epoch, validation_steps, validation_freq, max_queue_size, workers, use_multiprocessing, **kwargs)
641         max_queue_size=max_queue_size,
642         workers=workers,
--> 643         use_multiprocessing=use_multiprocessing)
644
645   def evaluate(self,
/opt/conda/lib/python3.6/site-packages/tensorflow/python/keras/engine/training_arrays.py in fit(self, model, x, y, batch_size, epochs, verbose, callbacks, validation_split, validation_data, shuffle, class_weight, sample_weight, initial_epoch, steps_per_epoch, validation_steps, validation_freq, **kwargs)
630         steps=steps_per_epoch,
631         validation_split=validation_split,
--> 632         shuffle=shuffle)
633
634     if validation_data:
/opt/conda/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in _standardize_user_data(self, x, y, sample_weight, class_weight, batch_size, check_steps, steps_name, steps, validation_split, shuffle, extract_tensors_from_dataset)
2388           target_tensors=target_tensors,
2389           run_eagerly=self.run_eagerly,
-> 2390           cloning=self._cloning)
2391
2392     # In graph mode, if we had just set inputs and targets as symbolic tensors
/opt/conda/lib/python3.6/site-packages/tensorflow/python/training/tracking/base.py in _method_wrapper(self, *args, **kwargs)
456     self._self_setattr_tracking = False  # pylint: disable=protected-access
457     try:
--> 458       result = method(self, *args, **kwargs)
459     finally:
460       self._self_setattr_tracking = previous_value  # pylint: disable=protected-access
/opt/conda/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in compile(self, optimizer, loss, metrics, loss_weights, sample_weight_mode, weighted_metrics, target_tensors, distribute, **kwargs)
335
336       # Creates the model loss and weighted metrics sub-graphs.
--> 337       self._compile_weights_loss_and_weighted_metrics()
338
339       # Functions for train, test and predict will
/opt/conda/lib/python3.6/site-packages/tensorflow/python/training/tracking/base.py in _method_wrapper(self, *args, **kwargs)
456     self._self_setattr_tracking = False  # pylint: disable=protected-access
457     try:
--> 458       result = method(self, *args, **kwargs)
459     finally:
460       self._self_setattr_tracking = previous_value  # pylint: disable=protected-access
/opt/conda/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in _compile_weights_loss_and_weighted_metrics(self, sample_weights)
1492       #                   loss_weight_2 * output_2_loss_fn(...) +
1493       #                   layer losses.
-> 1494       self.total_loss = self._prepare_total_loss(masks)
1495
1496   def _prepare_skip_target_masks(self):
/opt/conda/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in _prepare_total_loss(self, masks)
1593       if total_loss is None:
1594         if not self.losses:
-> 1595           raise ValueError('The model cannot be compiled '
1596                            'because it has no loss to optimize.')
1597         else:
ValueError: The model cannot be compiled because it has no loss to optimize.

I also met this issue with tensorflow 2.1, but fixed it by updating to 2.2
However,  there is a warning:
WARNING:tensorflow:AutoGraph could not transform <bound method VAE.train_step of <main.VAE object at 0x7f8319e7da90>> and will run it as-is.
Please report this to the TensorFlow team. When filing the bug, set the verbosity to 10 (on Linux, export AUTOGRAPH_VERBOSITY=10) and attach the full output.

I encountered this issue using TF 2.1.0. Please update the example - some environments are still using TF 2.1.0 and older versions. For instance see conda's offering TD 2.1.0 for Windows here:

Hi,
Please upgrade to the latest Keras/ Tensorflow version
You can use Keras using Tensorflow import as below.
import tensorflow as tf
input_layer = tf.keras.Input(shape=[100])

Let us know if you still face any error in latest version. Thanks!


Side Inputs + Blob Store Backups - Part 2 - Allow bulk restore from blob store for side input stores

Feature: Allow bulk restore from blob store for side input stores. If a blob store state backend is available, side input store restores can be sped up significantly by bulk-restoring initial state from the blob store, and only using the Kafka side input topic to catch up on the delta since last checkpoint.
Additional Context for Reviewers:

Side inputs RunLoop and regular Task RunLoop are separate and commit independently.
SideInputTask commit flushes the the side input store and writes the SIDE-INPUT-OFFSETS file in the store directory, but does not create a store checkpoint or upload it to the state backend.
This SIDE-INPUT-OFFSETS file is used during side input restore to determine the starting offset in the side input topic.
Regular Task commit creates store checkpoints, uploads them to the state backends, and saves the resulting store StateCheckpointMarker in the task checkpoint, but currently does not copy the SIDE-INPUT-OFFSETS file to the checkpoint directry.

Changes:
This is a follow up to #1654 and #1655

Copy the SIDE-INPUT-OFFSETS file (if exists) to the side input store checkpoint directory created during regular Task commit, so that it can be backed up along with the side input store contents and used during restore for incremental catchup. This copying needs to be done under process-wide synchronization to avoid data corruption, since the two RunLoops are currently completely independent of each other and do not coordinate/synchronize their commits, and there are no atomic file copy APIs.
If a blob store state backend factory is configured for side input stores, use it to do an inital bulk restore in ContainerStorageManager before starting the incremental restore and consumption from side input topics.

Tests: Added new integration tests to verify BlobStoreStateBackend functionality in general, and the new BlobStoreStateBackend + Side Inputs functionality in particular.

cc @mynameborat @shekhars-li for review.


feat(router): generate absolute URI from router

Adds an extra boolean argument to router.generate to specify whether or not to generate an absolute URI.
Fixes #88.

Note - this depends on changes in history (https://github.com/aurelia/history/pull/7) and history-browser (https://github.com/aurelia/history-browser/pull/22).

I'm removing core-js as a hard dependency and using our own aurelia-polyfills as a dev dependency when they are needed for tests. This will let the developer decide what they want in the end, with a favor towards our own which will be the minimum requirement...allowing it to be smaller and faster.
Keep up the good work guys. Let's get this and the other two related improvements wrapped up and in as soon as we can.

Coverage increased (+0.1%) to 68.331% when pulling 6c46826524e8cabd70c9828daa243b5b9eb5bc81 on jedd-ahyoung:router-get-origin into 13dcd60d143f1be43f1ad72aca6756f8a72785ff on aurelia:master.


coqtail tried parsing at old version of document

currently, the parsing api only supports parsing at the tip of the document.
you wanted to parse at: 2479 but the current tip is: 2492

I have the session open still

Can't reproduce


debug windows

The Windows package was blank, trying to debug that...

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@gillins this is what I get locally on my Windows machine:
[90/92] Linking CXX shared library bin\spatialindex_c-64.dll
BoundsQuery.cc.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
   Creating library bin\spatialindex_c-64.lib and object bin\spatialindex_c-64.exp
Generating code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\datastream.cc(108) : warning C4702: unreachable code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\datastream.cc(110) : warning C4702: unreachable code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\datastream.cc(111) : warning C4702: unreachable code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\src\capi\sidx_api.cc(194) : warning C4702: unreachable code
Finished generating code
[91/92] Linking CXX executable bin\test-tprtree-Exhaustive.exe
Exhaustive.cc.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
Generating code
c:\users\filipe\miniconda3\conda-bld\libspatialindex_1558386853387\work\test\tprtree\exhaustive.cc(193) : warning C4702: unreachable code
Finished generating code
[92/92] Linking CXX executable bin\libsidxtest.exe
main.cc.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
Generating code
Finished generating code
[0/1] Install the project...
-- Install configuration: "Release"
CMake Error at src/cmake_install.cmake:36 (file):
  file cannot create directory: C:/Program Files/spatialindex/lib.  Maybe
  need administrative privileges.
Call Stack (most recent call first):
  cmake_install.cmake:37 (include)

I'm re-starting the CIs here to see if we can revive the logs. (I did not know that Azure removed logs 😱)

I guess it was a simple fix due to my oversight in the original PR in the first place. Merging this.


Format code option does nothing

Hi, first off thank you for the wonderful php intellisense plugin.
I tried the format code option, but doesn't seem to show any effect on the file. Is there anything i am missing out on ?
Operation System: OSX
VS Code:  1.5.3
PHP Intellisense: 0.0.9

It would help if you could show the file you are trying to format.

I tried it on a sample php files from the twig library trying to mess up the indentation. Doesn't work with that. Below is the link to a sample gist.
Link

@aga5tya
I just tried the gist and everything worked as expected.
I have the same configuration as you, except that I am running Windows 10.

Do you have any other PHP formatter installed?

Did you select the text before formatting? That is a feature that is currently not supported by this plugin.

@felixfbecker I tried with a fresh copy of vs code with only intellisense plugin installed. Still does not work. Any specific logs i can share up? Are you on OSX ?
@MadHed I tried both ways, not sure what is causing the issue. Let me check on a linux OS and see if it works there.

Don't highlight the code :)

@felixfbecker  Thank you! That solved it. I could not get it done earlier since some portion or variable was always highlighted in mine, But shouldn't this work with highlights as it would help me format only certain portion of the code as necessary and not everything at once always.

It currently is very opinionated about where you should have empty lines and where not
https://github.com/felixfbecker/php-language-server/issues/29
https://github.com/felixfbecker/php-language-server/pull/35


Calling any logging from JS Code won't trigger the LogEntryAdded event

Hi guys,
tab.enable_runtime();
tab.enable_log();
tab.enable_debugger();

tab.add_event_listener(Arc::new(move |event: &Event| {
  match event {
     Event::LogEntryAdded(evt) => {
       println!(">> JS LOG : [{:?}] {:?}", evt.params.entry.level, evt.params.entry.text);
     }
     _ => { }
  }
}));

let jcode = r#"
(async () => {
  console.log("Just info log")
  console.warn("Some warning")
  console.error("Still nothing")
})();
"#;

let code = match tab.evaluate(jcode, true) {
  Ok(code) => code,
  Err(err) => return err.to_string(),
};

Calling any logging from JS Code like this won't trigger the LogEntryAdded event. I'm using the latest version.

Same issue here. There's a reference to the solution in an old issue, though it didn't appear in the discussion.
https://github.com/rust-headless-chrome/rust-headless-chrome/issues/277#issue-1056648093
Here's what worked for me:
tab.enable_runtime().unwrap();
tab.add_event_listener(Arc::new(move |event: &Event| match event {
    Event::RuntimeConsoleAPICalled(event) => {
        println!(
            ">> JS LOG : [{:?}] {:?}",
            event.params.Type,
            event
                .params
                .args
                .get(0)
                .unwrap()
                .value
                .as_ref()
                .unwrap()
                .as_str()
                .unwrap()
        );
    }
    _ => {}
}))
.unwrap();

let jcode = r#"
(async () => {
  console.log("Just info log")
  console.warn("Some warning")
  console.error("Still nothing")
})();
"#;

let code = match tab.evaluate(jcode, true) {
  Ok(code) => format!("{code:?}"),
  Err(err) => return err.to_string(),
};

Same issue here. There's a reference to the solution in an old issue, though it didn't appear in the discussion. #277 (comment)
Here's what worked for me:
tab.enable_runtime().unwrap();
tab.add_event_listener(Arc::new(move |event: &Event| match event {
    Event::RuntimeConsoleAPICalled(event) => {
        println!(
            ">> JS LOG : [{:?}] {:?}",
            event.params.Type,
            event
                .params
                .args
                .get(0)
                .unwrap()
                .value
                .as_ref()
                .unwrap()
                .as_str()
                .unwrap()
        );
    }
    _ => {}
}))
.unwrap();

let jcode = r#"
(async () => {
  console.log("Just info log")
  console.warn("Some warning")
  console.error("Still nothing")
})();
"#;

let code = match tab.evaluate(jcode, true) {
  Ok(code) => format!("{code:?}"),
  Err(err) => return err.to_string(),
};

Hi mate,
Thank you. That is mostly solved the issue. Although seems like it has some finicky details that needs to be further handled.
Seems like the pairing with existing chrome runtime installed will cause so many troubles too. Like with the latest chrome the headless flag are not working anymore. I did saw there is a notice from the popup when its non headless saying that some of the parameters is causing issues like this one. Its indeed causing stability issue like fetching API abruptly ended without returning proper error code.

Anyhow thank you so much for the help. Seems like the project are not quite active. It will be hard to maintain it for production. Quite sad that this is probably the only solution for rust at least for now.

Glad I could help you. If you get stuck again then maybe give chromiumoxide a try.

Glad I could help you. If you get stuck again then maybe give chromiumoxide a try.

Sure will try and take a look at that project.


Manual Links are Broken

The manual seems to have disappeared from the website, rendering all links to it - both on GitHub and on the website navbar - broken.
https://deno.land/manual

Thanks, fixed now.


Group mini-crud elements in panels (or similar solution)

:+1:

https://github.com/anavel/crud/pull/32


chore: add 1.30 into presubmit versions

Fixes #N/A
Description
Adds 1.30 into the presubmit versions to test and changes the goveralls version to 1.30.x
How was this change tested?
make presubmit
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.04%) to 78.158%

Files with Coverage Reduction
New Missed Lines
%

pkg/controllers/provisioning/scheduling/nodeclaim.go
2
89.13%

pkg/controllers/node/termination/terminator/eviction.go
2
89.09%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
8266

Relevant Lines:
10576

💛  - Coveralls


[@svelteui/core]: add PasswordInput component

Description
Added PasswordInput component.

Before submitting the PR, please make sure you do the following

[x] Read the Contributing guide
[x] Prefix your PR title with [@svelteui/core], [@svelteui/actions], [@svelteui/motion], [@svelteui/core], [core], or [docs].
[x] Include a description of the changes made in the PR description and in the commit messages.
[x] Include screenshots/videos of the changes made.
[x] Verify that the linter and tests are passing, with yarn lint and yarn test or just run yarn prepush.

Note that in the disabled state, we still have the visibility toggle unlike in Mantine. I could not find a way to conditionally render a slot in Svelte.

Thank you for this amazing contribution! :raised_hands: :partying_face:


Expose min_value/max_value when min/max for row group is empty

Hello,
Would it make sense to expose the min_value/max_value of the statistics of a row group when min/max (deprecated fields) are not set?
See: https://github.com/jorgecarleitao/arrow2/issues/1236 for some more details / test case.
Kind regards,
Martijn

I think it would.  Would you mind opening a JIRA?  Are you interested in contributing a patch?

Are you interested in contributing a patch?

Guidance on what (and where) to adjust would be necessary.

Sorry for the late reply.

Guidance on what (and where) to adjust would be necessary.

I would guess this is something in https://github.com/apache/arrow/blob/545b4313d6db2dfcc4ea0aa4ac23785d64450e1d/cpp/src/parquet/metadata.cc but haven't had a chance to look deeply.


Permissions should not be dropped when the same notebooks is shared

https://stackoverflow.com/questions/58027230/getting-error-only-bindings-and-etag-fields-may-be-set-on-using-gsutil-iam-se

https://cloud.google.com/storage/docs/gsutil/commands/acl