Missing warning when incorrectly calling a setter on a dynamic variable that's initialized

Consider this case:

I would have expected a warning or at least a hint because I'm trying to call data.markdown = but the setter doesn't exist.
Here's the definition of the class:

If I add the type annotation to data then I get the warning.

Errors and warnings are generated based on the static type, and the static type of 'data' is 'dynamic', hence, no warning. That said, we should produce a hint corresponding to the warning.
Alternatively, once strong mode is supported we'll be doing type inference that will cause the warning to be generated, and that might be sufficient.

Ah, interesting. So does that mean the only way to get full errors and warnings is to use type annotations for every variable?

Alternatively, once strong mode is supported we'll be doing type inference that will cause the warning to be generated, and that might be sufficient.

Strong mode FTW!

So does that mean the only way to get full errors and warnings is to use type annotations for every variable?

Yes. Dart can be used as an untyped language, in which case you don't get bothered with pesky errors and warnings. It can also be used as a strongly typed language, if you add type annotations everywhere, in which case you'll get most of the errors and warnings you expect (modulo the fact that it has an unsound type system). Or it can be used as a combination of both, which is what the style guide, for example, recommends.
Strong mode does two things. It makes the type system more sound and it infers types in some situations. But these advantages come with a cost: some constructs that are allowed in Dart will produce errors or warnings in strong mode. Personally, I think it's worth the cost, but not everyone will agree.

thanks for the explanation. Looking forward to more feedback from analysis of the code. Using var + being told when I did the wrong thing? Sign me up.

I still think it would be nice to make a distinction: Treat var x; as an
explicit indication that the type of the variable x is dynamic and we
don't want to hear about it's relation to the type system (as specified).
Some other syntax (maybe ? x;) could then mean that this variable is
intended to have a type annotation, but we wish to have it inferred.
With that, it makes sense to throw a type error in checked mode if that
inferred type is violated (assuming that the inference mechanism doesn't
prevent that, e.g., because the type is inferred from the initialization
expression rather than from the entire scope of the variable). It would
also make sense for an IDE to give programmers a notification when some
editing operation changes the inferred type of some variable (even though
that's of course potentially "anywhere in the world", we could get notified
of all the known cases).
On Sat, Aug 8, 2015 at 2:01 AM, Seth Ladd<EMAIL_ADDRESS>wrote:

thanks for the explanation. Looking forward to more feedback from analysis
of the code. Using var + being told when I did the wrong thing? Sign me up.
—
Reply to this email directly or view it on GitHub
https://github.com/dart-lang/sdk/issues/24023#issuecomment-128863791.

--
Erik Ernst  -  Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

It would also make sense for an IDE to give programmers a notification when some editing operation changes the inferred type of some variable ...

Do you have an example of when you'd like to see this? My intuition is that this would be annoying. Consider the following example:
var found = new List();

I don't want to be told if I change this to:
var found = new HashSet();

I also don't think I'd want to be told if I initialize a variable with an invocation of a method and then later change the return type of the method.
What problem are you thinking of that this kind of notification would solve?

Hello Brian,
On Mon, Aug 10, 2015 at 3:49 PM, Brian Wilkerson<EMAIL_ADDRESS>wrote:

It would also make sense for an IDE to give programmers a notification
when some editing operation changes the inferred type of some variable ...
Do you have an example of when you'd like to see this? My intuition is
that this would be annoying.

The underlying motivation is that inference may give rise to program
elements which are both significant and invisible, and that's a dangerous
combination. It is especially sinister if changes that are seemingly remote
can may your code invalid, and you never notice that anything has changed.
But you're probably right, my remark above sounds too aggressive. There are
lots of ways to turn up and down the "volume", though.
Worst case, we'd have a modal popup that stops the world until you type
your password twice, backwards. ;) A dimly colored squiggly line under a
word is much less noisy. Even more softly, programmers could have the
option to browse and search the history of such changes (anything showing a
diff could allow programmers to browse other things than just the textual
modifications, including modifications of inferred type annotations).
So we can always discuss what the right "volume level" should be; my point
is just: please allow programmers to notice this kind of phenomenon.
In some cases we get it for free: Assume that we have a rather strictly
typed piece of code containing var x = foo(); (preferably, but
hypothetically: ? x = foo();), and assume that inference makes this
declaration work as if we had written T x = foo();. If we are using the
expression x.y somewhere and T declares a y then a change (of foo,
somewhere else) that makes it work like S x = foo(); where S does not
declare such a member gives rise to a warning.
But if S does define a y that has an entirely different meaning than in
T, or if S == dynamic, or if there is a warning but it simply takes a
while before we get around to it, so we have no idea that the warning was
caused by the change to the return type of foo, then it would be nice to
have the option to keep an eye on the actual set of declarations affected
by this change, that is, including the ones where the change is implicit.

Consider the following example:
var found = new List();
I don't want to be told if I change this to:
var found = new HashSet();
Right. This isn't actually an implicit change, because the change in
inferred type is correlated with an editing operation in the affected
declaration itself. Having done that, it would be rather natural to look
into warnings in the scope of found immediately, and fix them.

However, even in this situation it might be helpful to be able to compare
the "before" and "after" type of found in order to understand the
consequences for usages of found. That could be an additional level of
information available at those use sites, indicating that found.add(..)
is now an entirely different operation, because of the different semantics
of lists and sets (so the example with T, S, and y above is not
totally unrealistic ;-).

I also don't think I'd want to be told if I initialize a variable with an
invocation of a method and then later change the return type of the method.

Sure? Not even softly?  ;-)
best regards,
--
Erik Ernst  -  Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

I haven't heard about "strong mode" before. Can anyone point me to the docs for it?
I don't think we need another syntax for inferred var (Erik used "?"). We already have a "dynamic" and a "var". Let's just add a "--no-implicit-dynamic" to the analyzer and make it such that the analyzer complains if it cannot infer the type of a "var" variable. Users can simply escape to "dynamic" if the type is really dynamic.
Erik's suggestion that the "?" is replaced with an inferred type is the simplest approach. I think the analyzer can go as far as it wants to make it less restrictive. There should be no reason that a variable can't be reused (with a different type) as long as the analyzer rechecks at every assignment that all subsequent uses are typed correctly.

I haven't heard about "strong mode" before. Can anyone point me to the docs for it?

Strong mode is the name of the type system being developed for DDC. It's documented here: https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md.

There should be no reason that a variable can't be reused (with a different type) as long as the analyzer rechecks at every assignment that all subsequent uses are typed correctly.

Agreed. That's what the analyzer currently does.
But strong mode actually prohibits that use case. The type is inferred at the point of origin and then isn't allowed to change. But note that the user has to opt in to strong mode; it won't be imposed on them.

But if S does define a y that has an entirely different meaning than in T, or if S == dynamic, or if there is a warning but it simply takes a while before we get around to it, so we have no idea that the warning was caused by the change to the return type of foo, then it would be nice to have the option to keep an eye on the actual set of declarations affected by this change, that is, including the ones where the change is implicit.

Sure, but I don't think that Dart code has enough information in it for us to be able to figure out that the y defined in S doesn't have the same semantics as the y in T. For this case, strong mode won't go as far as you might want, but it's better than checked (or production) mode and not worse.

I also don't think I'd want to be told if I initialize a variable with an
invocation of a method and then later change the return type of the method.

Sure? Not even softly?  ;-)

The example you gave is fairly abstract. I guess what I'm looking for is a "here's the code I had, here's the change I made, and here's the problem it caused without my getting any notification" kind of description.
The reason I want something fairly concrete is because there's a high cost to false positives. People tend to ignore or remove warnings that have a lot of false positives; worst case, they start ignoring all warnings because they can't get rid of only the ones they don't want. Before adding a feature like this I'd want to know that we have a low (or zero :-) probability of false positives. But as it stands, I think there's a fairly high probability of false positives. Understanding concrete use cases helps me formulate the rule in a way that eliminates false positives.
So, yes, I'd rather have no warnings for these cases than false positives.

On Mon, Aug 10, 2015 at 5:36 PM, Florian Loitsch<EMAIL_ADDRESS>wrote:

I haven't heard about "strong mode" before. Can anyone point me to the
docs for it?
I don't think we need another syntax for inferred var (Erik used "?"). We
already have a "dynamic" and a "var".

What worries me is simply that it is a breaking change to say that var x = e; is the same thing as T x = e; when T is the static type of the
expression e. Also, programmers who wish to use a dynamic style wouldn't
want to use the style 'dynamic x = e;everywhere. But new syntax (e.g.,?
x = e;`) could have the new semantics.

Let's just add a "--no-implicit-dynamic" to the analyzer and make it such
that the analyzer complains if it cannot infer the type of a "var"
variable. Users can simply escape to "dynamic" if the type is really
dynamic.
Erik's suggestion that the "?" is replaced with an inferred type is the
simplest approach. I think the analyzer can go as far as it wants to make
it less restrictive.

Inference has the "syntactic sugar" effect in many languages; in Scala, for
instance, var x = []; is a List[Nothing], and you will fail if you try
to put anything into it, so this really works as if we had written
List[Nothing] x = [];. I guess being less restrictive here means using
the inferred type for IDE completion etc., but not considering the variable
to have the inferred type as its type annotation. As long as we are only
talking about IDE behavior and not program behavior, we can of course do
whatever we want.
best regards,
--
Erik Ernst  -  Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

Also, programmers who wish to use a dynamic style wouldn't want to use the style 'dynamic x = e;` everywhere.

Agreed, but that just means that they don't want to use strong mode.

But new syntax (e.g., ? x = e;) could have the new semantics.

Yes, but one of the design goals for DDC was to not require language changes. Of course, you could write a DEP proposal to add the new syntax. :-)

I guess being less restrictive here means using the inferred type for IDE completion etc., but not considering the variable to have the inferred type as its type annotation.

Actually, no. The inferred type is taken to be the static type for the purpose of generating errors and warnings.

As long as we are only talking about IDE behavior and not program behavior, we can of course do whatever we want.

Strong mode does not change the run-time behavior of Dart code. It does change the behavior of the command-line analyzer as well as IDE support, and as noted above changes the errors and warnings that are produced by using the inferred type as if it were the static type. But again, if users don't like it they don't have to use it.

On Mon, Aug 10, 2015 at 5:57 PM, Brian Wilkerson<EMAIL_ADDRESS>wrote:

I haven't heard about "strong mode" before. Can anyone point me to the
docs for it?
Strong mode is the name of the type system being developed for DDC. It's
documented here:
https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md.
There should be no reason that a variable can't be reused (with a
different type) as long as the analyzer rechecks at every assignment that
all subsequent uses are typed correctly.
Agreed. That's what the analyzer currently does.
But strong mode actually prohibits that use case. The type is inferred at
the point of origin and then isn't allowed to change. But note that the
user has to opt in to strong mode; it won't be imposed on them.

I believe this mixes two different scenarios: (1) The type of variable x
declared as var x = e; (or ? x = e;) is T, by inference, and some
editing operation changed it to a different type S; and (2) The type T
of variable x declared as var x = e; is obtained by inference that
takes the entire scope of x into account, even though the declaration
(including an initializing expression) of x indicates a different type
S. I wouldn't expect strong mode to prohibit (1), it's hard to see how it
could do that. But (2) embeds a different meaning of the phrase "the type
of this variable has changed", so that's a different topic.
The approach where a declared variable is associated with multiple
different types, depending on the location in the code (that is, depending
on flow analysis) is a separate topic. With that approach we cannot hope to
talk about "the type annotation" for a variable, because that concept is
bound to the declaration and it doesn't allow for more than one type (even
a union type is too unspecific: we don't know where each summand applies).
But I tend to think that such an approach is too costly to make explicit:
It's fine that a tool performs the flow analysis and provides type
consistency feedback (as in "I don't think there is a y on x here").
So that's not the kind of inference I want to push into the syntax; it's
only the kind where each variable gets just one type in its entire scope,
we just don't want to bother to use the keyboard (and maybe doing some
busywork looking up declarations) in order to make that single type
explicit.
But I think it's useful to use the keyboard to explicitly indicate that the
type is inferred.

But if S does define a y that has an entirely different meaning than in T,
or if S == dynamic, or if there is a warning but it simply takes a while
before we get around to it, so we have no idea that the warning was caused
by the change to the return type of foo, then it would be nice to have
the option to keep an eye on the actual set of declarations affected by
this change, that is, including the ones where the change is implicit.
Sure, but I don't think that Dart code has enough information in it for us
to be able to figure out that the y defined in S doesn't have the same
semantics as the y in T.

That's not hard! ;-)
The point is that we (can choose to) take nominal types seriously: If y
in S and y in T have no declarations in common (that is, a static
lookup for the two y features in S, T and their supertypes find sets
of declarations that do not overlap). With that there is no need for magic,
we just note that there is no reason to assume that the two y features
mean the same thing because no such commonality was ever expressed by the
programmers.

For this case, strong mode won't go as far as you might want, but it's
better than checked (or production) mode and not worse.
I also don't think I'd want to be told if I initialize a variable with an
invocation of a method and then later change the return type of the method.
Sure? Not even softly? ;-)
The example you gave is fairly abstract. I guess what I'm looking for is a
"here's the code I had, here's the change I made, and here's the problem it
caused without my getting any notification" kind of description.

You gave that example: Changing found from a List to a Set changed
the semantics of add anywhere in the scope of found (and, by extension,
anywhere that object flows dynamically). Don't you ever want to inspect
that kind of change before you commit to it?

The reason I want something fairly concrete is because there's a high cost
to false positives.

True, but that's again a matter of "volume". We can make those things very
soft-spoken, yet available if needed.

People tend to ignore or remove warnings that have a lot of false
positives; worst case, they start ignoring all warnings because they can't
get rid of only the ones they don't want.

That's a piece of experience that I fully recognize and respect.

Before adding a feature like this I'd want to know that we have a low (or
zero :-) probability of false positives. But as it stands, I think there's
a fairly high probability of false positives. Understanding concrete use
cases helps me formulate the rule in a way that eliminates false positives.
So, yes, I'd rather have no warnings for these cases than false positives.

I believe that this is an entirely new category of diagnostics (it is
concerned with editing operations rather than static entities such as
libraries or programs), and in that sense we don't have so much to compare
with (and there is no way it would be made part of the language spec,
because it is concerned with static entities). So the formal concept of a
'warning' is too heavy.
But just like completion can be used by programmers, even though it relies
on an analysis where type annotations are trusted, "changes in inferred
types" browsing could be used by programmers who are busy refactoring some
code and curious about the correctness of some step in this process. Nobody
forces one or the other upon you.
best regards,
--
Erik Ernst  -  Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

On Mon, Aug 10, 2015 at 6:47 PM, Brian Wilkerson<EMAIL_ADDRESS>wrote:

Also, programmers who wish to use a dynamic style wouldn't want to use the
style 'dynamic x = e;` everywhere.
Agreed, but that just means that they don't want to use strong mode.

But they can't make the choice: If they write code in a reusable library,
and they used var, and they want the dynamic type treatment at runtime,
then they cannot rely on everybody else to not use strong mode in a context
that includes their library.

But new syntax (e.g., ? x = e;) could have the new semantics.
Yes, but one of the design goals for DDC was to not require language
changes. Of course, you could write a DEP proposal to add the new syntax.
:-)

Will do.

I guess being less restrictive here means using the inferred type for IDE
completion etc., but not considering the variable to have the inferred type
as its type annotation.
Actually, no. The inferred type is taken to be the static type for the
purpose of generating errors and warnings.

But errors and warnings are in the spec, and they are associated with the
behavior of programs in checked mode, so I cannot see how those concepts
can be used unless it is implied that an inferred type is actually
considered to be the type annotation, in which case my worries about the
need for the dynamic x = e; style in dynamic code are reinforced. With ? x = e; we can let ? stand for the inferred type, consistently and
strictly.

As long as we are only talking about IDE behavior and not program
behavior, we can of course do whatever we want.
Strong mode does not change the run-time behavior of Dart code.

Doesn't it catch things like this?:
List xs = [1, 2];
List ys = xs;  // OK statically (by covariance), and of course
dynamically.
ys[0] = "Hello";  // Fails because [1, 2] is inferred to mean [1, 2].
xs[0].gcd(42);  // .. or: Fails, because xs "shouldn't contain a String"
In the last line, my expectation is that "it's not strong enough" to fail
because "Hello" does not have a gcd method, it should fail earlier than
that. This is the reason why I don't write "Fails because of a
NoSuchMethodError during the invocation of gcd". But standard Dart
semantics will proceed all the way to NoSuchMethodError, because xs
is allowed to refer to a List<dynamic>, and a List<dynamic> is allowed
to contain a String.
best regards,
--
Erik Ernst  -  Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

Changing found from a List to a Set changed the semantics of add anywhere in the scope of found (and, by extension, anywhere that object flows dynamically).

Not from my perspective. The only semantic I had in mind for add was that after the method add was invoked, the method contains would return true. Granted, the add in List and the add in Set differ in semantics in other ways, but not that way. I don't know how, using static analysis, to know whether the semantics I care about are the same or not.

Don't you ever want to inspect that kind of change before you commit to it?

Of course! In fact, I want to inspect that kind of change before I make it. I look at uses of found to understand whether the semantic change will break the code or not, and only change the type once I'm convinced that it's safe.

But they can't make the choice: If they write code in a reusable library, and they used var, and they want the dynamic type treatment at runtime, then they cannot rely on everybody else to not use strong mode in a context that includes their library.

True, but they also can't rely on everybody else to not use checked mode in a context that includes their library. I'm not sure how this is any different.
And if I'm writing code and using strong mode to help catch problems earlier in the dev cycle, then I'd want to know if a library I was using violated strong mode because I'd seriously question whether it was safe for me to use it.
All DDC is doing here is adding another level of checking. Just as checked mode is stronger than production mode, strong mode is stronger than checked mode.

On Mon, Aug 10, 2015 at 8:07 PM, Brian Wilkerson<EMAIL_ADDRESS>wrote:

Changing found from a List to a Set changed the semantics of add anywhere
in the scope of found (and, by extension, anywhere that object flows
dynamically).
Not from my perspective. The only semantic I had in mind for add was that
after the method add was invoked, the method contains would return true.
Granted, the add in List and the add in Set differ in semantics in other
ways, but not that way. I don't know how, using static analysis, to know
whether the semantics I care about are the same or not.

Of course, we couldn't expect a tool to know which semantic distinctions we
have in mind for any particular purpose, but my point is that we don't need
that kind of magic: The phenomenon that I propose watching for (possibly
giving notifications about, possibly stashing away in a data structure for
the programmer to browse if needed) is when an editing operation causes a
rebinding of a name

to a declaration which is unrelated to its previous binding according to
the nominal typing structure. It could also be detected relative to a diff
between two versions in a version control system, etc.etc.
If we detect that phenomenon then we can help programmers track down the
unwanted rebindings. This can be useful because the associated semantic
disruptions might otherwise easily sneak under the radar, especially when a
number of links in the dependency chain are invisible due to type
inference, and especially when the affected code is far away from the piece
of code that was actually modified.

Don't you ever want to inspect that kind of change before you commit to it?
Of course! In fact, I want to inspect that kind of change before I make
it. I look at uses of found to understand whether the semantic change
will break the code or not, and only change the type once I'm convinced
that it's safe.

In many situations it might be quicker (and still reasonable) to just make
the change and check whether there are any of those nominal rebindings, and
use that when making the decision: "Should I keep this change, or should I
press 'Undo'?"

But they can't make the choice: If they write code in a reusable library,
and they used var, and they want the dynamic type treatment at runtime,
then they cannot rely on everybody else to not use strong mode in a context
that includes their library.
True, but they also can't rely on everybody else to not use checked mode
in a context that includes their library. I'm not sure how this is any
different.

If your code runs in checked mode and no TypeErrors are thrown then your
code will run identically in production mode.
If your code throws a TypeError in checked mode and it is caught and
handled then all bets are off wrt checked/production mode alignment, so we
basically don't want that.
But adding yet another a subtly different semantics doesn't improve on that
situation. In particular, it is a new source of subtle inconsistencies if
var x = e; sometimes means dynamic x = e; and sometimes means T x = e;, especially when running in checked mode.
(Yes, it's common to say "but nobody does that", but I'm not totally
convinced, and in particular I don't want to push the situation in the
direction of "but nobody does that, because you never know what it will
do").

And if I'm writing code and using strong mode to help catch problems
earlier in the dev cycle, then I'd want to know if a library I was using
violated strong mode because I'd seriously question whether it was safe for
me to use it.

There could very well be cases where code which is unsafe on the surface
happens to be very carefully crafted (following a discipline which cannot
be expressed or recognized by the type system). For instance, a
_Future<T> has a field _resultOrListeners which will surely have
difficulties passing strong mode compilation, but it wouldn't be easy for a
substantial set of programs to avoid depending on 'dart:async'. So we
probably don't want to force strong mode upon all parts of our programs,
even in an organizational setting where strong mode coding is the standard.
However, I think the important point here is that semantic inconsistencies
among different "kinds of Dart" are dangerous, and interpreting var as
T in some declarations, or creating an instance of List<int> when
evaluating [1] (not <int>[1]) in some initializing expressions are
examples of this kind of inconsistencies. One Dart is better than three! ;^)

All DDC is doing here is adding another level of checking. Just as checked
mode is stronger than production mode, strong mode is stronger than checked
mode.

Stronger checking can be reconciled with an existing language semantics if
there is a very simple story (e.g., "a program P executed in language L
resp. in language L' will proceed in lockstep---that is, the heaps remain
isomorphic and externally visible actions are identical---until they both
terminate identically, or L' at some step terminates with a type error and
L continues", leaving some required fixes in case of non-determinism
implicit). That's what I'm asking for, e.g., via ? x = e; rather than via
reinterpretation of var x = e;.
best regards,
--
Erik Ernst  -  Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

Hello again,
I was [just] answering email, but looking again this is of course an 'Area-Analyzer' issue, which means that the discussion has been spiraling out of scope for a while. Sorry about having contributed generously to that development.  ;-)
I guess the more general topics should be discussed on a mailing list (e.g<EMAIL_ADDRESS>or<EMAIL_ADDRESS>instead.

This discussion ranged fairly widely, not sure I have all of the threads in my head at once, but a couple of thoughts.

Local variables and top level variables are different, and we may want different inference behavior for them.  In particular, the discussion about inference changing the API is not relevant to local variables.  My general inclination is to be much more conservative about inference for things which have non-local uses.

DDC currently will infer a type for local variables based on the initializer.  As noted, this may cause errors to show up if the variable is used at different types later in the method.  We could be (and may experiment with) doing something a bit smarter here, but we want what we are doing to be predictable and understandable.

I believe it is possible to add inference for local variables in an entirely backwards compatible way that would introduce no additional errors or warnings to any code (including dynamic code, and including broken code).  This can be done by simply doing any form of inference you choose, but allowing dynamic to be inferred as the concrete type.  Any code that could be typed before can still be typed, since dynamic is always a choice.  This reduces the error checking benefits, but still provides code completion benefits.  In this way, it's more like the analyzers "propagated type".  I don't advocate this, but mention it as a point in the design space, in part because of the next point.

Having syntax to ask for inference would be very nice.  I'd also like to see this for generic parameters (e.g List<?>, or List<>).  It occurs to me that if we go this route, it would be useful to treat "var x" as I describe above (that is, "infer the best type for x that allows the program to be typed, including dynamic as an option"), while treating "var? y" as "infer the best non-dynamic type for y".  The point being that this would allow the inference engine to take advantage of inference results for x when they are available, instead of requiring it to treat x as dynamic for the purposes of inference (even when x has a perfectly consistent and inferable type).

This issue seems to be outdated with Dart 2 falling into place.


allow redirect of gateway root to console URL

interested in comments.. will this break anything the gateway is currently doing?

@apoland after talks with @carabasdaniel I opened https://github.com/aserto-dev/topaz/pull/329 that should not require any changes in service-host. If that PR seams ok, we can close this one.


Interactive commands

Description

Allow input from interactive commands such as mdspell (https://github.com/armano2/node-markdown-spellcheck). This package for example offers a selection for miss-spelled words. Lint staged does not allow input or prints output from the package, thereby running for ever.
Steps to reproduce

Install lint-staged, husky and https://github.com/armano2/node-markdown-spellcheck (for now, maintained fork)

Configure lint-staged.config.js:
module.exports = {
  "*.md": "mdspell"
}

Configure husky with pre-commit hooks.

Stage and Commit a markdown file with a miss-spelling: This sentence is wrrong

lint-staged runs forever because mdspell is waiting for user input

Debug Logs

expand to view
 lint-staged:bin Running<EMAIL_ADDRESS>+0ms
  lint-staged:bin Options parsed from command-line: {
  allowEmpty: false,
  concurrent: true,
  configPath: undefined,
  debug: true,
  maxArgLength: 65536,
  quiet: false,
  relative: false,
  shell: false
} +2ms
  lint-staged Loading config using `cosmiconfig` +0ms
  lint-staged Successfully loaded config from `ABCD/lint-staged.config.js`:
  lint-staged {
  lint-staged   '**/*.md': [ 'textlint --fix', 'mdspell -n' ]
  lint-staged } +41ms
  lint-staged:cfg Validating config +0ms
Running lint-staged with the following config:
{
  '**/*.md': [
    'textlint --fix',
    'mdspell -n'
  ]
}
  lint-staged:run Running all linter scripts +0ms
  lint-staged:resolveGitRepo Resolving git repo from `ABCD` +0ms
  lint-staged:resolveGitRepo Deleting GIT_DIR from env with value `undefined` +1ms
  lint-staged:git Running git command [ 'rev-parse', '--show-toplevel' ] +0ms
  lint-staged:resolveGitRepo Resolved git directory to be `ABCD` +52ms
  lint-staged:resolveGitRepo Resolved git config directory to be `ABCD/.git` +1ms
  lint-staged:git Running git command [ 'diff', '--staged', '--diff-filter=ACMR', '--name-only' ] +53ms
  lint-staged:run Loaded list of staged files in git:
  lint-staged:run [
  lint-staged:run   'CONTRIBUTING.md',
  lint-staged:run   'docs/deployment.md',
  lint-staged:run   'docs/development.md',
  lint-staged:run   'docs/interfaces.md',
  lint-staged:run   'docs/remote-publishing.md',
  lint-staged:run   'docs/setup.md',
  lint-staged:run   'docs/style-guide.md',
  lint-staged:run   'docs/test-protocol.md'
  lint-staged:run ] +115ms
  lint-staged:chunkFiles Resolved an argument string length of 563 characters from 8 files +0ms
  lint-staged:chunkFiles Creating 1 chunks for maxArgLength of 65536 +0ms
  lint-staged:gen-tasks Generating linter tasks +0ms
  lint-staged:gen-tasks Generated task:
  lint-staged:gen-tasks {
  lint-staged:gen-tasks   pattern: '**/*.md',
  lint-staged:gen-tasks   commands: [ 'textlint --fix', 'mdspell -n' ],
  lint-staged:gen-tasks   fileList: [
  lint-staged:gen-tasks     'ABCD/CONTRIBUTING.md',
  lint-staged:gen-tasks     'ABCD/docs/deployment.md',
  lint-staged:gen-tasks     'ABCD/docs/development.md',
  lint-staged:gen-tasks     'ABCD/docs/interfaces.md',
  lint-staged:gen-tasks     'ABCD/docs/remote-publishing.md',
  lint-staged:gen-tasks     'ABCD/docs/setup.md',
  lint-staged:gen-tasks     'ABCD/docs/style-guide.md',
  lint-staged:gen-tasks     'ABCD/docs/test-protocol.md'
  lint-staged:gen-tasks   ]
  lint-staged:gen-tasks } +3ms
  lint-staged:make-cmd-tasks Creating listr tasks for commands [ 'textlint --fix', 'mdspell -n' ] +6ms
  lint-staged:task cmd: textlint +1ms
  lint-staged:task args: [ '--fix' ] +1ms
  lint-staged:task execaOptions: { preferLocal: true, reject: false, shell: false } +0ms
  lint-staged:task cmd: mdspell +1ms
  lint-staged:task args: [ '-n' ] +0ms
  lint-staged:task execaOptions: { preferLocal: true, reject: false, shell: false } +0ms
Preparing... [started]
  lint-staged:git Backing up original state... +0ms
  lint-staged:git Backing up merge state... +0ms
  lint-staged:file Reading file `ABCD/.git/MERGE_HEAD` +0ms
  lint-staged:file Reading file `ABCD/.git/MERGE_MODE` +1ms
  lint-staged:file Reading file `ABCD/.git/MERGE_MSG` +0ms
  lint-staged:file File `ABCD/.git/MERGE_HEAD` doesn't exist, ignoring... +11ms
  lint-staged:file File `ABCD/.git/MERGE_MODE` doesn't exist, ignoring... +1ms
  lint-staged:file File `ABCD/.git/MERGE_MSG` doesn't exist, ignoring... +1ms
  lint-staged:git Done backing up merge state! +16ms
  lint-staged:git Running git command [ 'ls-files', '--deleted' ] +112ms
  lint-staged:git Running git command [
  'stash',
  'save',
  '--include-untracked',
  '--keep-index',
  'lint-staged automatic backup'
] +113ms
  lint-staged:git Restoring merge state... +1s
  lint-staged:git Done restoring merge state! +1ms
  lint-staged:git Running git command [ 'ls-files', '--others', '--exclude-standard' ] +1s
  lint-staged:git Running git command [ 'stash', 'list' ] +86ms
  lint-staged:git Running git command [
  'diff',
  '--binary',
  '--unified=0',
  '--no-color',
  '--no-ext-diff',
  '--patch',
  '--output=ABCD/.git/lint-staged_unstaged.patch',
  'stash@{0}',
  '-R'
] +159ms
  lint-staged:git Done backing up original state! +487ms
Preparing... [completed]
Running tasks... [started]
textlint --fix [started]
textlint --fix [completed]
mdspell -n [started]

Environment

OS: Arch Linux
Node.js: v13.3.0
lint-staged: 10.0.8

I don't think this is currently possible because we're using Listr, which takes over the CLI rendering.
Further, since tasks run concurrently by default, multiple interactive commands would compete for the input.
Supporting interactive tasks would thus require a new cli renderer, and possibly running tasks serially.

I remember having an issue about it already but I’m on my phone now. Just search for it.

I was thinking about a flag to mark specific commands as interactive. These would not be run concurrently.
I’ll go check out listr if they have an issue or PR about interactive in-between steps.
Ps: I’ve searched through the issues, but I couldn’t find an interactive input one (sorry if I missed it).

Listr Input https://github.com/SamVerschueren/listr/issues/32

There's also this spiritual successor to listr https://github.com/cenk1cenk2/listr2
I'll try it out to see how well it works

It's quite nice. I've just created a publish pipeline with inputs (with the built-in enquirer) + enquirer plugins (https://www.npmjs.com/package/enquirer-editor - entire editor window) with a small tweak.
It's also backwards compatible with listr and looks and behaves almost the same.
I might try looking into a PR to see if lint-staged would work with it.

That would be amazing!

Listr2 is coming in the linked PR. After that task input is a possible feature. It would imply a concurrency of 1, though.


BugFix: Refined CPU Validation per Libvirt Guidelines

What this PR does
Refined CPU Validation per Libvirt Guidelines
Issue:
Libvirt validation fails when a CPU model is usable
by QEMU but lacks features listed in
/usr/share/libvirt/cpu_map/[CPU Model].xml on a node.
Resolution:
Nodes are now labeled with a CPU model only if all
features listed in the corresponding cpu_map XML file
are present and the model is usable by QEMU.
This prevents validation issues caused by missing features.
Libvirt's Recommendation:
Libvirt advises against using its internal data files for
feature validation.
As recommended, we're exploring the use only Libvirt's API
to identify usable CPU models, avoiding direct cpu_map
file dependency.
New Approach:
To avoid the validation error mentioned above we will disable
some of the features in the /usr/share/libvirt/cpu_map/[CPU Model].xml files:

disable svm for Opteron_G2 to avoid:
https://bugzilla.redhat.com/show_bug.cgi?id=2122283
disable mpx for Skylake, Cascadelake, and Icelake to avoid:
https://gitlab.com/libvirt/libvirt/-/issues/304

These features are disabled only if not explicitly required by the user,
allowing broader CPU model support when svm or mpx features are absent.

Fixes #
Opteron_G2 CPU model IS not supported when svm is absent.
Cascadelake, Icelake and Skylake are not supporetd when mpx features is absent.
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

/cc @xpivarc @vladikr

/approve
@xpivarc as you've requested. wrt #11407 Can you please take a look?

I left one comment about the internal API that I have not think about before, apologies. In theory we could drop the API all together and just encode this change into converter for now.

Yes, like i mentioned here

I left one comment about the internal API that I have not think about before, apologies. In theory we could drop the API all together and just encode this change into converter for now.

I'm only worried that it might create an inconsistency later - in one version the code was in one place and then it suddenly moved to another (also tests, etc.. ).

/lgtm

Small note about the PR description:

Will do

I think we can unhold this @Barakmor1

/unhold

/cherry-pick release-1.2

/cherry-pick release-1.1


Error while parsing "src/lib.rs"  expected const or mut

#[swift_bridge(swift_repr = "struct")]
pub struct DiscordRPCAgent {
    client: Client,
    thread: Option<*Thread>
}

I'm trying to use Option<> in my struct but it doesn't let me

Hey.
This is a Rust compile time error, not a swift-bridge error.
*Thread is invalid Rust syntax.
The Rust compiler is seeing this and suggesting that you might either mean *const Thread or *mut Thread.
I'm assuming that you don't actually want either of those though.
It seems like you really want Option<Thread> (without the *)?

Closing since that should fix it. Feel free to re-open if you still have issues.
Cheers!

Thanks for the swift reply!


TURBO_BOOST breaks vga color

Hi,
I have noticed that enabling the TURBO_BOOST define breaks the correct colors display on the flash_stream sample vga_mode_640x480_60 .
Without TURBO_BOOST, the number is crisp and the blue gradient is perfect.
With TURBO_BOOST, a blue gradient turns to like 64 color dithered green.
Also, white blobs are leaking red pixels to the right.
Are these artifacts usually caused by vga timing error?
Thank you.

just a guess but looks like it's related to set_sys_clock_khz() ... see other examples below
https://github.com/raspberrypi/pico-playground/blob/e551a2d7606a468b00299e408ab44e62947926f9/scanvideo/mandelbrot/mandelbrot.c#L277
https://github.com/raspberrypi/pico-playground/blob/f0ce80c9d282b45fd1a3f882d92bce17bea4826d/scanvideo/sprite_demo/sprite_demo.c#L174

Looks like set_sys_clock_khz(300000, true); fixes the flash stream demo.


feat: allow specific description for CLI options

What kind of change does this PR introduce?
Feature

add cliDescription -  Sometimes we need specific descriptions for CLI options, for example when we are deprecating a CLI option only in favor of another

https://github.com/webpack/webpack-dev-server/pull/4091
https://github.com/webpack/webpack-dev-server/pull/4098

add negatedDescription - webpack-cli creates a negative flag for each boolean flag, it uses negatedDescription property for description if available.

Did you add tests for your changes?
Yes

Does this PR introduce a breaking change?
No

What needs to be documented once your changes are merged?
It is for internal usage, nothing to be documented.

@sokra, thanks for the update.

Thanks


Add gRPC testing docs

Added the "Writing scripts" section in the left navigation bar.
Added the following pages under the "Writing scripts" section

"Scripting in gRPC request"
"Writing tests"
"Test examples" and
"Postman Sandbox API"
pages under the "Test scripts" section.

To Do:

Add GIFs

A few additional things:

Reference to Testing in grpc-request-interface.md and using-grpc-request.md
Fixes to broken links throughout grpc-docs
Update to #message in grpc-request-interface.md


Representation Encrypted Number

Good Morning,
I want to create a script in which the input are the Encrypted number and not the plaintext. I want to realize a simple sum. How can represent the Encrypted Number through int type? Is possible to encode o to serialize the ciphertext in order to give it like input?
Thank you very much!

@subzero210 Have a look at the examples in https://github.com/google/fully-homomorphic-encryption/tree/main/transpiler/examples/simple_sum, which does an encrypted sum of two integers


[BUG] Unable to force drain the node

Describe the bug
Follow the manual test step, create a 1 replica deployment with a 3 replicas Longhorn volume. And the volume is attached to N1.
I'm unable to force drain the N1, it keeps shown the pod disruption budget error.
error when evicting pods/"instance-manager-r-ae5c0a46" -n "longhorn-system" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pods/"instance-manager-e-12eb5d96" -n "longhorn-system" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

To Reproduce

Deploy a cluster contains 3 worker nodes N1, N2, N3.
Create a 1-replica deployment with a 3-replica Longhorn volume. The volume is attached to N1.
Write some data to the volume and get the md5sum.
Force drain N2.kubectl drain --force <node-name> --delete-emptydir-data --grace-period=10 --ignore-daemonsets

Expected behavior
The force drain should succeed.
Follow the same steps on Longhorn v1.2.0, force drain the node succeed.
Log
longhorn-manager-czqrw longhorn-manager time="2021-09-22T06:46:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"jenting-longhorn-worker-1\", UID:\"e0a9c480-268c-49e5-b893-e60b528a2f0c\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"56253561\", FieldPath:\"\"}): type: 'Normal' reason: 'Schedulable' Node jenting-longhorn-worker-1 is cordoned"
longhorn-manager-wmgqp longhorn-manager time="2021-09-22T06:46:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"jenting-longhorn-worker-1\", UID:\"e0a9c480-268c-49e5-b893-e60b528a2f0c\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"56253561\", FieldPath:\"\"}): type: 'Normal' reason: 'Schedulable' Node jenting-longhorn-worker-1 is cordoned"
longhorn-manager-dsg7p longhorn-manager time="2021-09-22T06:46:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"jenting-longhorn-worker-1\", UID:\"e0a9c480-268c-49e5-b893-e60b528a2f0c\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"56253561\", FieldPath:\"\"}): type: 'Normal' reason: 'Schedulable' Node jenting-longhorn-worker-1 is cordoned"
longhorn-manager-wmgqp longhorn-manager time="2021-09-22T06:46:58Z" level=debug msg="Requeue longhorn-system/jenting-longhorn-worker-1 due to conflict: Operation cannot be fulfilled on nodes.longhorn.io \"jenting-longhorn-worker-1\": the object has been modified; please apply your changes to the latest version and try again"
longhorn-manager-dsg7p longhorn-manager time="2021-09-22T06:46:58Z" level=debug msg="Requeue longhorn-system/jenting-longhorn-worker-1 due to conflict: Operation cannot be fulfilled on nodes.longhorn.io \"jenting-longhorn-worker-1\": the object has been modified; please apply your changes to the latest version and try again"
longhorn-manager-dsg7p longhorn-manager time="2021-09-22T06:46:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"jenting-longhorn-worker-1\", UID:\"e0a9c480-268c-49e5-b893-e60b528a2f0c\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"56253561\", FieldPath:\"\"}): type: 'Normal' reason: 'Schedulable' Node jenting-longhorn-worker-1 is cordoned"
longhorn-manager-wmgqp longhorn-manager time="2021-09-22T06:46:58Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"jenting-longhorn-worker-1\", UID:\"e0a9c480-268c-49e5-b893-e60b528a2f0c\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"56253561\", FieldPath:\"\"}): type: 'Normal' reason: 'Schedulable' Node jenting-longhorn-worker-1 is cordoned"
longhorn-manager-dsg7p longhorn-manager time="2021-09-22T06:46:58Z" level=debug msg="Requeue longhorn-system/jenting-longhorn-worker-1 due to conflict: Operation cannot be fulfilled on nodes.longhorn.io \"jenting-longhorn-worker-1\": the object has been modified; please apply your changes to the latest version and try again"
longhorn-manager-wmgqp longhorn-manager time="2021-09-22T06:46:58Z" level=debug msg="Requeue longhorn-system/jenting-longhorn-worker-1 due to conflict: Operation cannot be fulfilled on nodes.longhorn.io \"jenting-longhorn-worker-1\": the object has been modified; please apply your changes to the latest version and try again"

Environment:

Longhorn version: v1.2.1-rc1

cc @shuo-wu

After checking Jenting's environment, there is an orphan engine process inside an engine instance manager pod that blocks the
corresponding node drain.
Otherwise, the drain & PDB works as expected:

When there are multiple replicas for the volumes, draining the nodes that contain replicas only should succeed.
When the workload pod is running on the draining node, the draining will be blocked for a while since Kubernetes & Longhorn need to spend some time moving the pod & the volume to another node. Once all volumes are detached from the node, the PDB for the engine instance manager will be deleted then the draining should succeed.

With a fresh install cluster + longhorn, I'm unable to reproduce the force drain failed issue.
Close it.

Thanks @shuo-wu n @jenting . But any possible reason causing an orphan engine process?

But any possible reason causing an orphan engine process?

We have not checked it yet. Let's revisit it after the release. I had asked Jenting to retain the cluster.


Download multiple supplemental files (e.g. tables)

Some papers contain links to tables, which can be downloaded with a selector output to table.csv. However they need naming (e.g. table1.csv, table2.csv...) otherwise they overwrite and end with a single file (the last).

Cannot create subdirectories:
    "csv1": {
      "selector": "//a[@id='CSVdownloadButton'][1]",
      "attribute": "href",
      "download": {
        "rename": "tables/table1.csv"
      }
    },

hangs...


ngrok: send the UserAgent when authenticating

This brings it in-line with ngrok-go
Resolves #81

Current dependencies on/for this PR:

main

PR #83   👈

This comment was auto-generated by Graphite.


Skip Jupyter notebook tests

Skips currently flaky screen diff tests on master

Coverage increased (+2.6%) to 81.778% when pulling 77616a77d0a3e1de1a4fa236e4dab661fc61157a on ajd/skip-tests into 9bb4c5cbc096a5d31105369d1a8fe223e3b1c2d9 on master.


Using data "confluent_schema_registry_cluster" with aliased provider failing

I am trying to convert the example at examples/configurations/single-event-types-proto-schema-with-alias to use the new approach to defining environments and schema registry, but it fails for me.
I changed the environment and schema registry resources to look like this:
resource "confluent_environment" "staging" {
  display_name = "Staging"
  stream_governance {
    package = "ESSENTIALS"
  }
}

data "confluent_schema_registry_cluster" "essentials" {
  environment {
    id = confluent_environment.staging.id
  }
}

Then I changed the provider to look like this:
provider "confluent" {
  # https://developer.hashicorp.com/terraform/language/providers/configuration#alias-multiple-provider-configurations
  alias = "schema-registry"

  schema_registry_id            = data.confluent_schema_registry_cluster.essentials.id
  schema_registry_rest_endpoint = data.confluent_schema_registry_cluster.essentials.rest_endpoint
  schema_registry_api_key       = confluent_api_key.env-manager-schema-registry-api-key.id
  schema_registry_api_secret    = confluent_api_key.env-manager-schema-registry-api-key.secret
}

Running terraform apply fails the first time with this error:
│ Error: error reading Schema Registry Clusters: there are no SR clusters in "env-xxxxxx" environment
│
│   with data.confluent_schema_registry_cluster.essentials,
│   on main.tf line 52, in data "confluent_schema_registry_cluster" "essentials":
│   52: data "confluent_schema_registry_cluster" "essentials" {

Running it a second time, it fails with this:
│ Error: All 4 schema_registry_api_key, schema_registry_api_secret, schema_registry_rest_endpoint, schema_registry_id attributes should be set or not set in the provider block at the same time
│
│   with provider["registry.terraform.io/confluentinc/confluent"].schema-registry,
│   on main.tf line 19, in provider "confluent":
│   19: provider "confluent" {

If I run this: terraform apply -target=confluent_api_key.env-manager-schema-registry-api-key then things get better - that creates the API key and then I can run terraform apply to create everything else.

@lmeadors thanks for creating this issue!
I suspect it's a general terraform issue where it requires all provider inputs to be known beforehand (i.e., passed as module variables or hardcoded), and in your scenario, confluent_api_key.env-manager-schema-registry-api-key.id = "". I'd recommend refactoring your code to use a module instead, to ensure these attributes aren't empty.

The provider not having the api key is somewhat incidental.
The bigger issue (in my mind, anyway) is that current example fails on the first application of it. I think that means that the environment resource is reporting that is all done and created before it actually is.
That in turn makes the data block fail to find the schema registry created by the environment resource falsely reporting that there are no SR clusters in "env-xxxxxx" environment, and the recovery from that failure is unintuitive.
It would be great if the environment returned the schema registry id (if defined) or that the data block to get the SR tried harder to find it. :D
I am not disagreeing that a more modular approach would be better (and I ended up refactoring my code to be that way), but rather that the example should either work as is or demonstrate the best practice.

the example should either work as is

💯
Could you share the example URL so we could update it?

I started with this:
https://github.com/confluentinc/terraform-provider-confluent/tree/master/examples/configurations/single-event-types-proto-schema-with-alias
Then applied the changes mentioned here:
https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/guides/version-2-upgrade

I would be happy to send a PR later this week if needed.


v3/teams/{teamId}/conversations returning 403 ServiceError Unknown

Steps to reproduce
Seeing errors with code ServiceError and message Unknown when calling v3/teams/{teamId}/conversations API. Started a few hours ago. Tested it out with several teams and getting the same error for all of them.
Expected behavior
We'd expect the message to be sent
Actual behavior
RestError: Unknown
Error details
Full error returned:
2024-04-15T18:41:54.503372270Z RestError: Unknown
2024-04-15T18:41:54.503390371Z     at new RestError (/node_modules/@azure/ms-rest-js/dist/msRest.node.js:2480:28)
2024-04-15T18:41:54.503396371Z     at /node_modules/@azure/ms-rest-js/dist/msRest.node.js:3687:37
2024-04-15T18:41:54.503406972Z     at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
2024-04-15T18:41:54.503428172Z   code: 'ServiceError',
2024-04-15T18:41:54.503432773Z   statusCode: 403,
2024-04-15T18:41:54.503437073Z   request: WebResource {
2024-04-15T18:41:54.503441573Z     streamResponseBody: false,
2024-04-15T18:41:54.503445973Z     url: 'https://smba.trafficmanager.net/amer/v3/teams/{TEAM_ID_HERE}/conversations',
2024-04-15T18:41:54.503450473Z     method: 'GET',
2024-04-15T18:41:54.503454773Z     headers: HttpHeaders { _headersMap: [Object] },
2024-04-15T18:41:54.503459174Z     body: undefined,
2024-04-15T18:41:54.503463374Z     query: undefined,
2024-04-15T18:41:54.503467574Z     formData: undefined,
2024-04-15T18:41:54.503472074Z     withCredentials: false,
2024-04-15T18:41:54.503476374Z     abortSignal: undefined,
2024-04-15T18:41:54.503480574Z     timeout: 0,
2024-04-15T18:41:54.503484874Z     onUploadProgress: undefined,
2024-04-15T18:41:54.503489175Z     onDownloadProgress: undefined,
2024-04-15T18:41:54.503493475Z     proxySettings: undefined,
2024-04-15T18:41:54.503497675Z     keepAlive: undefined,
2024-04-15T18:41:54.503501875Z     agentSettings: undefined,
2024-04-15T18:41:54.503506175Z     redirectLimit: undefined,
2024-04-15T18:41:54.503510475Z     operationSpec: {
2024-04-15T18:41:54.503520876Z       httpMethod: 'GET',
2024-04-15T18:41:54.503525176Z       path: 'v3/teams/{teamId}/conversations',
2024-04-15T18:41:54.503529576Z       urlParameters: [Array],
2024-04-15T18:41:54.503533776Z       responses: [Object],
2024-04-15T18:41:54.503538076Z       serializer: [Serializer]
2024-04-15T18:41:54.503542377Z     }
2024-04-15T18:41:54.503546677Z   },
2024-04-15T18:41:54.503550877Z   response: {
2024-04-15T18:41:54.503555177Z     body: '{"error":{"code":"ServiceError","message":"Unknown"}}',
2024-04-15T18:41:54.503560077Z     headers: HttpHeaders { _headersMap: [Object] },
2024-04-15T18:41:54.503564677Z     status: 403
2024-04-15T18:41:54.503568878Z   },
2024-04-15T18:41:54.503573178Z   body: undefined
2024-04-15T18:41:54.503577378Z }

I've confirmed that the error is coming from the following method. We've tried it with both the optional teams id param:
             try {    teamChannels = await TeamsInfo.getTeamChannels(context); } catch(err) {     console.log('error in getting teams channels')     console.log(err) }
try {    teamChannels = await TeamsInfo.getTeamChannels(context, context.activity.channelData.teamsTeamId); } catch(err) {     console.log('error in getting teams channels')     console.log(err) }
Both return the following:
2024-04-16T13:57:39.763599244Z error in getting teams channels
2024-04-16T13:57:39.766050531Z RestError: Unknown
2024-04-16T13:57:39.766074232Z  {
2024-04-16T13:57:39.766133434Z   "name": "RestError",
2024-04-16T13:57:39.766140634Z   "code": "ServiceError",
2024-04-16T13:57:39.766145834Z   "statusCode": 403,
2024-04-16T13:57:39.766150635Z   "request": {
2024-04-16T13:57:39.766155435Z     "streamResponseStatusCodes": {},
2024-04-16T13:57:39.766160335Z     "url": "https://smba.trafficmanager.net/amer/v3/teams/19%3AQD_Odb-mcvY4MUZyHrNYdm5VoNKgj7vSfDfqdO_Rlok1%40thread.tacv2/conversations",
2024-04-16T13:57:39.766165535Z     "method": "GET",
2024-04-16T13:57:39.766176136Z     "headers": {
2024-04-16T13:57:39.766181036Z       "_headersMap": {
2024-04-16T13:57:39.766185736Z         "authorization": "REDACTED",
2024-04-16T13:57:39.766190536Z         "user-agent": "core-http/3.0.4 Node/v14.21.3 OS/(x64-Linux-<IP_ADDRESS>-1.cm2)"
2024-04-16T13:57:39.766195536Z       }
2024-04-16T13:57:39.766199736Z     },
2024-04-16T13:57:39.766204237Z     "withCredentials": false,
2024-04-16T13:57:39.766209037Z     "timeout": 0,
2024-04-16T13:57:39.766229037Z     "requestId": "fc38fe88-27cf-446f-83c4-14159da00556"
2024-04-16T13:57:39.766234038Z   },
2024-04-16T13:57:39.766238538Z   "details": {
2024-04-16T13:57:39.766243138Z     "error": {
2024-04-16T13:57:39.766247638Z       "code": "ServiceError",
2024-04-16T13:57:39.766252338Z       "message": "Unknown"
2024-04-16T13:57:39.766257038Z     }
2024-04-16T13:57:39.766261639Z   },
2024-04-16T13:57:39.766266139Z   "message": "Unknown"
2024-04-16T13:57:39.766270739Z }
We've confirmed the error is present with botbuilder v4.16.0 and the latest botbuilder v4.22.2

Also running into this issue on botbuilder (v3.30.0). @carolinedpena thanks for opening!

Hello @carolinedpena - Thanks for raising your query.
Could you please share the repro steps and code snippets so that we can quickly check and investigate on this?

Hi @ChetanSharma-msft - we're encountering this error in 2 different scenarios where we are using the TeamsInfo.getTeamChannels method. First, we are sending an adaptive card to the user and crafting a deep link to that message. The variable ref in the block below is a conversation reference that was retrieved earlier in the user's interaction with the bot. The userChannelTeamId on the body object as well:
`
try {
const messageId = await context.sendActivity(assignmentCard);
    let channelName: any;
    let channelId: any;

    // get teams aad id
    const teamsDetails = await TeamsInfo.getTeamDetails(context, body.userChannelTeamId);
    const teamsAadId = teamsDetails.aadGroupId;

    if (!ref.conversation.name) {
      const channelObj = await TeamsInfo.getTeamChannels(context, body.userChannelTeamId)
      channelId = ref.conversation.id;

      if (ref.conversation.id.includes(";")) {
        channelId = ref.conversation.id.split(";")[0]
      }

      const channelN = channelObj.find(channel => channel.id === channelId);

      channelName = channelN?.name
    } else {
      channelName = ref.conversation.name
    }

    // check if message is a reply to an existing discussion thread and extract the parent id if it is
    let parentId = '';

    if (context.activity.conversation.id.includes('messageid')) {
        parentId = context.activity.conversation.id.split(';')[1].split('=')[1];
    }

    // creating discussion thread url to save to assignments table
    discussionThreadURL = `https://teams.microsoft.com/l/message/${channelId}/${messageId?.id}?tenantId=${context.activity.conversation.tenantId}&groupId=${teamsAadId}&parentMessageId=${parentId.length > 0 ? parentId : messageId?.id}&teamName=${body.userChannelTeamName}&channelName=${channelName}&createdTime=${messageId?.id}`;

    context.activity.id = activityId;
    context.activity.conversation = conversation;

`
Second, we are trying to determine what kind of bot interaction is occurring based on where a bot is being mentioned:
`
// bot is either being mentioned in a sales channel or a management channel
const teamChannels = await TeamsInfo.getTeamChannels(context, context.activity.channelData.teamsTeamId);
const channelArr = teamChannels.filter(channel => channel.id === context.activity.channelData.teamsChannelId);
    if (channelArr[0].name?.toLowerCase().includes("assignments") || channelArr[0].name?.toLowerCase().includes(" approvals")) {
        return "managementChannelMention"
    } else {
        return "salesChannelMention"
    }

`
As mentioned above, this error just began occurring yesterday afternoon. The code above was working before.

Hello, we're experiencing the same issue, and our customers are being blocked from carrying out their tasks. Is it possible to expedite the investigation/resolution on the Microsoft side? Please and thank you!

Hello Everyone,
Sorry for delay in response.
We will look into it and let you know the updates.

@carolinedpena - We apologize for the delay. We have tested this on our side, and everything appears to be functioning correctly. Could you please confirm if you are still experiencing the issue?


Fix git ignore

Currently .gitginore is completely broken. There are also some generated sources under source control.
This pull request:

Fixes .gitignore
Removes Idea and Eclipse files from .gitignore because they are workstation-specific and should be ignored globally
Removes generated sources

@SergeyKemaev please review

Looks ok


feat(engine/phases): drop-references: accept ?

The drop references phases constrained the input language to be question mark free, but it did not make any sense

I actually cannot: this is a type-level only change. This phase used to have a too strong "precondition" for no reason. This PR allows backends to apply this phase a bit earlier, basically.


Hello World | 且听风吟

https://singingkettle.github.io/2017/07/16/hello-world/

ok,it's test

test

test

ok

test

ok


Add cls (Clear Screen) alias to zsh aliases

This is always a super handy command to have available!

On a Mac you can just press apple + k

Right, but this isn't a keyboard shortcut, it's a command. One that I personally have used since the old dos/command prompt days so it's just kinda burned into muscle memory for me. Brings me back. :-)

Yeah; I'm squarely in the cmd+k group myself (for the same sort of muscle memory you have, ha!), but I'll go ahead and merge this; pretty useful to have.


UNMET PEER DEPENDENCY<EMAIL_ADDRESS>UNMET PEER DEPENDENCY<EMAIL_ADDRESS>

I have issues installing react-toolbox and eventually making bundles with browserify. Here is what I get during installation:
$ npm install --save react-toolbox
npm WARN install Couldn't install optional dependency: Unsupported
<EMAIL_ADDRESS>c:\Users\user\node\app
├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
npm WARN EPEERINVALID<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm WARN EPEERINVALID<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm WARN EPEERINVALID<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.

And when I try to make a bundle I get this error:
[ERROR][vendorsd task]:  Cannot find module './style' from 'c:\Users\user\node\app\node_modules\react-toolbox\lib\dropdown'
[ERROR][vendorsd task]:  Cannot find module './style' from 'c:\Users\user\node\app\node_modules\react-toolbox\lib\input'

What do all those errors and warnings mean? How to solve them?
I neither have those packages in my package.json nor have them in /node_modules. So how can it be UNMET PEER DEPENDENCY if there is no even such a package installed.
They are listed as devDependencies of react-toolbox. Why doesn't react-toolbox install them?

If I'm not wrong, this is an npm 3 issue that it's not directly related to React Toolbox. Also, if you are trying to get a build using browserify, be aware that we give no support. For now, if you want to use react toolbox, you should use webpack (which I think is not a problem though). It would be great if somebody create a test with browserify, sadly right now I don't have the time to do so :(

I'm closing since this kind of issue is not related to toolbox but npm!

if you are trying to get a build using browserify, be aware that we give no support. For now, if you want to use react toolbox, you should use webpack

This is pretty disappointing for those who already have working apps with configured browserify build system. It means if we want to utilize react-toolbox in the app, we must switch everything to webpack environment. Don't even know what might be faster, find ways to use react-toolbox with browserify or learn webpack and recreate build system.

Sorry about that. I have no experience with browserify so I think that the best way to provide support is if anybody with experience can get a configuration working with css modules. The only reasons why we are supporting webpack is because to prepend custom configuration variables we need a loader and because of css modules. But as far as I know there is a demo of css modules with browserify so I think it's perfectly possible

I'm getting the same errors & I'm using Webpack:
+-- UNMET PEER DEPENDENCY<EMAIL_ADDRESS>+-- UNMET PEER DEPENDENCY<EMAIL_ADDRESS>+-- UNMET PEER DEPENDENCY<EMAIL_ADDRESS>|| ~15.3.0

react-toolbox includes those packages in its "peer dependencies". However, peer dependencies are no longer supported in npm 3.x that comes with nodejs 6.x. You either need to install those packages manually or use nodejs 4.x instead, until this is fixed.

UNMET PEER DEPENDENCY<EMAIL_ADDRESS>|| ~15.3.0

{
  "name": "test-custom-react-scripts",
  "version": "0.0.1",
  "private": true,
  "devDependencies": {
    "custom-react-scripts": "0.0.13"
  },
  "dependencies": {
    "google-map-react": "^0.20.0",
    "immutability-helper": "^2.0.0",
    "react": "^15.3.2",
    "react-dom": "^15.3.2",
    "react-toolbox": "^1.2.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  }
}

node -v: v6.1.0
npm -v: 3.8.6

Peers should be installed manually guys. They are peers because you may need that dependency installed just once as it happens with react. Am I right?


not working

File "load.py", line 4, in
from zeenode.config import auth, prefix, nitro_sniper, giveaway_sniper
ModuleNotFoundError: No module named 'zeenode'

...


Sept updates

@krknopp I've replied to all of your comments in https://github.com/YCloudYUSA/yusaopeny_docs/pull/56/commits/60a77fa31cccc9ae87b642a6418fdfaf99ceb99f. Great feedback, thank you. I hope this helps.


Can't check nginx X-Forwarded-Proto from $_SERVER['HTTP_X_FORWARDED_PROTO']

I can see http instead https on createAbsoluteUrl. I try to find source of problem...
What steps will reproduce the problem?
server {
listen 443 ssl;
location / {
proxy_pass http://some.ip:someport;
proxy_set_header   Host $http_host;
proxy_set_header   X-Real-IP $remote_addr;
proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
}
...
}
server {
listen someport;
...
location ~ .php$ {
include fastcgi.conf;
fastcgi_pass   php:9000;
}
}
where fastcgi.conf is standard nginx config
What is the expected result?
isSecureConnection check $_SERVER['HTTP_X_FORWARDED_PROTO']
What do you get instead?
var_dump(\Yii::$app->request->isSecureConnection);
var_dump(\Yii::$app->request->headers->get('X-Forwarded-Proto', null));
var_dump($_SERVER['HTTP_X_FORWARDED_PROTO']);

bool(false) NULL string(5) "https"
Additional info

Q
A

Yii version
dev

PHP version
7.3.5

Operating system

https://github.com/yiisoft/yii2/issues/16264
So... I can add into my config something like
[
    'components' => [
        'request' => [
            'csrfParam' => '_csrf-backend',
            'trustedHosts' => [
                '<IP_ADDRESS>/24',
            ],
        ],
...
]

Just a note when if you configure this: you may need to login and logout the user or delete the session, since the returnUrl might be stored with the wrong scheme in the session.


GO:0005471 parent

http://www.ebi.ac.uk/QuickGO/GTerm?id=GO:0005471#term=ancchart
the parent "purine ribonucleotide... looks incorrect.

Also ATP and ADP  transmembrane transporters have both
nucleotide and nucleotide parentage. Should it be only  nucleotide (with phosphate)?
(note to self, to prevent redundant inferred annotation  request ATP and ADP transmembrane transport)

This is a ChEBI issue:

Needs to be fixed there https://github.com/ebi-chebi/ChEBI/issues
Can you submit a ticket?
CC @hdrabkin

Just checking that you did not mean me to submit the ticket here (as I'm not sure what the Chebi issue is).

https://github.com/ebi-chebi/ChEBI/issues/3224
If ChEBI is fixed, the fix will propagate automatically to all affected GO terms.  Until then, there's not really anything that GO can do to fix.


feat: reduce cache file size

Create a script for rewriting the LMDB database to minimize its size

https://github.com/kriszyp/lmdb-js/issues/205

Problems when copying the database caused by: kriszyp/lmdb-js#205

btw., have you tried testing it with some older version of the lmdb (I would try with 2.5.X and 2.6.X) and a newer version of node.js (19? - if that's really an issue with a V8, maybe it's solve in a version the newer node versions are using?)


chore (indexer): Fix break statements

Bug Report
Setup
CometBFT version (use cometbft version or git rev-parse --verify HEAD if installed from source):
main, v1.x, v0.38.x, v0.37.x
Description
In many places within the kv indexer we have loops that should be interrupted when the enclosing context is completed. The code however does not break from the loop, rather just from the select.
This was partially fixed by @melekes  in https://github.com/cometbft/cometbft/issues/2647 but still remains in some places.
It is present in older versions as well so should probably be backported to all the versions that are still supporting non critical bug fixes.

Is this issue the same as https://github.com/cometbft/cometbft/issues/3544?

Ah @alesforz was faster. Duplicate of #3544


staging is not 100% robust

Description
It's a bit of an unusual use-case, but I've been tracking diffs in source control, and staging them bit by bit. This works fine in emacs magit, but I think neogit's hunk parsing is getting confused by the hunks in the git operation itself and the hunks in the diff that we are source controlling and which are unrelated.
Neovim version
NVIM v0.5.1
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Operating system and version
fedora 34
Steps to reproduce
first version, s.diff
diff --git a/lua/neogit/buffers/common.lua b/lua/neogit/buffers/common.lua
index 504ed37..cfa8a2d 100644
--- a/lua/neogit/buffers/common.lua
+++ b/lua/neogit/buffers/common.lua
@@ -22,6 +22,7 @@ M.Diff = Component.new(function(diff)
     local content = map(range(hunk.diff_from + 1, hunk.diff_to), function(i)
       return diff.lines[i]
     end)
+    -- test

     return {
       header = header,

second version, s2.diff
diff --git a/lua/neogit/buffers/common.lua b/lua/neogit/buffers/common.lua
index 504ed37..96bc74f 100644
--- a/lua/neogit/buffers/common.lua
+++ b/lua/neogit/buffers/common.lua
@@ -10,6 +10,7 @@ local filter = util.filter
 local intersperse = util.intersperse
 local range = util.range

+-- test3
 local M = {}

 local diff_add_matcher = vim.regex('^+')
@@ -31,6 +32,7 @@ M.Diff = Component.new(function(diff)

   return col.tag("Diff") {
     text(diff.kind .. " " .. diff.file),
+    -- test2
     col.tag("HunkList")(map(hunk_props, M.Hunk))
   }
 end)

We want to track these files in source control.
If you save both these files on disk, as /tmp/s.diff and /tmp/s2.diff, then do...
git init
cp /tmp/s.diff s.diff
git add s.diff
git commit -m "first version"
cp /tmp/s2.diff s.diff
nvim -nu minimal.lua
:Neogit

Then in neogit go over Unstaged changes->Modified s.diff, press tab, go over the line that says "--- add/lua/neogit..." then press s to stage the hunk.
Expected behavior
The hunk gets staged.
Doing the same thing in magit in emacs stages without problem.
Actual behavior
Neogit displays Git error (128).
Minimal config
vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvim/site]])
local package_root = "/tmp/nvim/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup({
    {
      "wbthomason/packer.nvim",
      {
        "TimUntersberger/neogit",
        requires = {
          { "nvim-lua/plenary.nvim" },
          { "sindrets/diffview.nvim" },
        },
        config = function()
          print("loaded neogit")
          require("neogit").setup()
        end,
      },
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  })
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing neogit and dependencies.")
  vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
require("packer").sync()

I also use fine grained staging bit by bit and magit indeed is very very useful for this.

Do you mean line wise staging? You can visually (v-line, press capital V) select some limited within junk and stage them with s.


Fonts are not installing from context menu

Description
Whenever I try to install a single font or multiple fonts, the  Install option in right-click context menu doesn't work.

Steps To Reproduce

Select a font type file such as ttf & otf
Right-click -> More -> Install
Nothing happens & the font was not installed

"Install for all users" doesn't work too
Expected behavior
I should be able to install the font. This dialog should appear

Files Version
<IP_ADDRESS>
Windows Version
10.0.22621.1
Relevant Assets/Logs
N/A

You will need to upload the logs files directly to github. You can get them in files settings > about > open log folder.

In my testing it works fine: the dialog does not appear but the font is added to c:\windows\fonts.

A single font file works but when you try to select multiple files and choose 'Install', only the first highlighted font will be installed

I can confirm that this is still happening.
debug_fulltrust.log
debug.log


Fix(nodejs): major vulnerabilitys

This PR will be fixed most of the vulnerabilities for some npm packages that contain it
CVE that was fixed:
ejs:
CVE-2021-42740
CVE-2022-29078
express/qs:
CVE-2022-24999
json5:
CVE-2021-44906
CVE-2022-46175
pac-resolver:
CVE-2021-23406
semver:
CVE-2022-25883
word-wrap:
CVE-2023-26115

#525
#559


#2 Add ping method

fixed lint issue

Looks good, @kousikmitra, thanks 🙏  May I ask you to add payload as an optional parameter and forward it to the event initializer? Something like:
def ping(self, payload: typing.Optional[bytes] = None) -> None:
        event = wsproto.events.Ping(payload)
        self._send_event(event)

Looks good, @kousikmitra, thanks 🙏 May I ask you to add payload as an optional parameter and forward it to the event initializer? Something like:
def ping(self, payload: typing.Optional[bytes] = None) -> None:
        event = wsproto.events.Ping(payload)
        self._send_event(event)

done, changed the func signature to ping(self, payload: bytes = b"")  as Ping doesn't take None

done, changed the func signature to ping(self, payload: bytes = b"")  as Ping doesn't take None

Indeed, perfectly right! LGTM!
@all-contributors add @frankie567 for maintenance, @kousikmitra for code

Yes, but now, @all-contributors add @kousikmitra for code


Support instance update for MySQL

Add support for updating MySQL All-In-One or DBMS Only instances.

Yep.


Property 'hot' does not exist on type 'NodeModule' error & fix

Not sure if you can do anything about this once I've installed the framework and I do prototype -> npm install I get the following error
Property 'hot' does not exist on type 'NodeModule'
I fixed it by doing npm i -D @types/webpack-env
https://stackoverflow.com/questions/40568176/webpack-typescript-module-hot-does-not-exist/44146354
perhaps you could add this as a dev dependency
or you could add a common error & fix section

Sorry for the late response. I have a fix for this. I'll post here again when it's published.

Basically it's because we need to reference webpack-env in the tsconfig.json.

Ok thanks for explaining

Fixed in v0.1.27. (Just re-generate the prototype.)


Expose query metadata in PostgresRowSequence

Currently the functions that return PostgresRowSequence have no way of reporting back the metadata of the query.
This PR exposes the metadata through the collectWithMetadata() and consume(onRow:) methods.

@fabianfett I've thought a bit more about this and possibly we might want to have another type that wraps PostgresRowSequence in the next major version at least? so we can expose more stuff in the response. Not only the metadata, but maybe even the connection properties? Or who knows what.
I don't have an immediate use-case for connection properties but it looks like some lost info. Maybe someone finds a value in them although they can also be individually queried.

I'd love this addition! I have queries that should update exactly 1 row. I'd like to check that the update was successful, but I can't check without the metadata. (These queries currently don't return the row itself.)

I'm not a fan of the proposed API changes: They either get everything into memory, or they force users to consume the rows synchronously. I consider both bad options.

I honestly don't think this is a problem. We're not really taking any options away.

However I do have an alternative in mind:

To be honest this looks better, at least at the first glance. So I'd be happy to move this way.


Build binary for arm64

This is an attempt to build goss for arm64 so we can run it on Graviton2 machines on AWS.
It fixes https://github.com/aelsabbahy/goss/issues/722.
It adds a Makefile target for release/goss-linux-arm64 alongside release/goss-linux-arm, release/goss-linux-amd64 etc.
Note, that this results in the released assets being changed slightly going forward: goss-linux-arm will be a 32-bit ARM binary and goss-linux-arm64 will be a 64-bit ARM binary.
Other changes
I also changed install.sh a little because the current implementation actually builds for the wrong architecture: when uname -m returns aarch64 it should use GOARCH=arm64 instead of the currently used GOARCH=arm which results in a 32-bit binary.
I also added arm64 to the 64-bit if-statement because that's what is returned on the arm-based Macbooks.
In order to also support 32-bit ARM in install.sh I matched on aarch32 but I don't know if that's correct. I believe that wouldn't work on, e.g. Raspberry Pis, because I think they return something like armv7 or so. I didn't prioritize it here because the current implementation didn't do the right thing anyways.
/cc @tnaroska because you created the original issue
/cc @garyschulte because you have built for arm64 as well

Thank you for submitting this PR:

Can you split the install.sh change to a separate PR. This way I can publish the new binaries prior to install.sh update.

What are the implications of aarch64 moving from arm -> arm64 in the install script? Is it broken today, does this introduce a breaking change?

I'm still working on this feature on my end. I'll follow up here as soon as possible.

@ekelali Thanks for the suggestion to split the PR. I wasn't sure about the purpose of install.sh but it looks like it's not relevant to the release process.
It should be much easier to get this merged now since it will only add one more binary and shasum to each release, not touching anything else.

Note, that this results in the released assets being changed slightly going forward: goss-linux-arm will be a 32-bit ARM binary and goss-linux-arm64 will be a 64-bit ARM binary.

This was actually a wrong comment by me. goss-linux-arm is already a 32-bit ARM binary (like it should) and this PR adds a goss-linux-arm64 64-bit ARM binary alongside it. So the releases are backwards compatible.
I'll clarify the changes to install.sh in a separate PR.

@aelsabbahy Would you mind creating a release that includes the arm64 binaries?

@aelsabbahy Thanks! 🤗

Thank you for the contribution, greatly appreciated!


Support generating a README from a Plugin

Output - https://github.com/danger/danger/blob/lint/dsl_docs.md
This PR is mergable, but the work to make the DSL docs a nicer read is on, I must have waster 2-3 hours now on trying to make a table like this work, but restricting all code samples to a tiny amount of chars didn't fly in the end.
Need to think a bit about how to display the methods overall, but I'm happy with where it is ATM.

          1 Warning

:warning:
.gemspec modified

  Generated by :no_entry_sign: danger

Thanks @segiddins 👍


Update README.md

Add info for contacting Sketchfab to set up the API integration.

Thanks, LGTM, but I'd like @mikeskydev to confirm, since he's done this a few times :-)


Resharper

Hey Volkan! Hope everything is going well in your part of the world. Hey so I wanted to give you some information on something by jetbrains called resharper. It's an amazing (and I mean AMAZING) visual studio extension that I use that helps with code readability, tips on what something should be or look like. Its basically intellisense on steroids. There's so much it can do. While the price for it is about $120 a year, it's free for open source projects. And as your engine grows, I highly recommend you get this. Seriously it's simply amazing.
Go take a look at jetbrains resharper. If you have any question let me know. At least sign up for the free trail so you can see the amazing Ness that comes from resharper and .net cover.
I just wanted you to know this because I figured it could help out, alot! And we all want to see the Serenity Engine grow :)
William

Wednesday I'll the Serenity code through the resharper and .net cover and .net memory profiler and I'll post the results of you would like me to.

ReSharper is awesome

Thanks a lot for suggestion. I know that tool, but i have different opinions on that one. First of all, it takes Visual Studio to crawl. Also, it messes with my key bindings even if i tell it not to. Yeah there is an option that doesnt actually work which couldnt be fixed by them for ten years straight. I think its an overrated tool, a toy made for rookies.

Dunno which version you've used, but in my experience, they fixed the performance problems years ago (~2008 when I first tried it, it was unusable)

I don't know, some of my teammates uses it and a solution with 250 projects (no i didn't design it :), loading takes 10 times more, so they turn off Resharper, load solution, unload most of projects then turn it on etc. I might be sometimes overreacting but messing with my shortcuts is unforgivable :-)

I'm acting similar towards notebook producers who remove home end page down page up keys from their models, because Apple or some other genius did so

solution with 250 projects
Well...yeah. I'm going to put much of the blame on Visual Studio remaining 32-bit for this rather than Resharper, but still. Good news is you soon won't need to reference 250 projects which will speed VS tremendously but you'll still keep the ability to step into them.

messing with my shortcuts is unforgivable
Agreed


Add Workspace Nav 0.0.6

I gather that this is the suggested way to get an update of a plugin into the plugin manager. Perhaps it might be possible to cut out manual steps by having a script that retrieved tags from git and added them to the plugin manager where they fit the pattern x.y.z?

There is a script:  /script/submit-plugin.rb


Allow aborting an exit event

This addresses the first point in #814.
I am not sure how to handle the second scenario in the issue as integration is moved into the closure

thanks!


[7.x] Add support for 'dot' notation for json() in HTTP Client Response

This add simple support for 'dot' notation in HTTP Client Response json() method, like in HTTP Request json() method.
It's make easier to get a specific data from a JSON response, or use a default value if the key is missing.
// Before
$data = $response->json()['data']['key'] ?? null;
$data = $response['data']['key'] ?? null;

// After
$data = $response->json('data.key');

The current behavior is the same when no arguments are provided.

I think was proposed already, but rejected because it breaks things for people who actually want to use a key with a dot in.

I think was proposed already, but rejected because it breaks things for people who actually want to use a key with a dot in.

I used the code from Illuminate\Request::json() to have consistency but the data_get() could just be replaced with Arr::get() which will check that the key don't exists before checking for dot notation so it will not break people who actually want to use a key with a dot in


Cannot be used for browsers

Describe the bug
The website cannot use the newest version of modelina, because of the dependency typescript-json-schema as it uses ts-node which out of the box is not compatible with CommonJS.
Expected steps to solve
Might be as easy as:

Add a specific website example we can use as test to ensure it always works going forward.
My assumption is that we can add a configuration to the tsconfig.json file to solve this: https://github.com/TypeStrong/ts-node/issues/935#issuecomment-913179458

hint for the test:

we do it already in parser -> https://github.com/asyncapi/parser-js/blob/master/test/browser_test.js
puppeteer is the key, but I've heard Microsoft has alternative project that gets some attention, so maybe you wanna use it
simple HTML https://github.com/asyncapi/parser-js/blob/master/test/sample_browser/index.html
and then just npm script that starts the server before starting test -> https://github.com/asyncapi/parser-js/blob/master/package.json#L22 using start-server-and-test package

not expert in TS, but yeah, if simple config won't work, you can always switch to parser approach where we bundle browser compatible version of the parser

Solved in https://github.com/asyncapi/modelina/pull/843


Fix true_divide with dtype argument

Fix #2059

jenkins, test this please.

Jenkins CI test (for commit 5e53c6cfd59cfa4d67a45eb2fdcbd8f7ad1c5a51, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

How does this fix work?

for op in ops[::-1]:  # the trick to avoid using small type

In most cases, the largest type is chosen from the reverse order.

@okuta
I think we talked offline about implementing this in a different way. Is that correct?

Jenkins CI test (for commit 5e53c6cfd59cfa4d67a45eb2fdcbd8f7ad1c5a51, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

jenkins, test this please.

Jenkins CI test (for commit c7e3e17c334fb72fe52cc1283f4d7b061f2d8fac, target branch master) failed with status FAILURE.

jenkins, test this please.

Jenkins CI test (for commit 3f2c86a88e72a6ff46c36645b4baeae216c2da8a, target branch master) succeeded!

jenkins, test this please.

Jenkins CI test (for commit 9cadaa28aa3f49e05409cad31e86d6082e7de11d, target branch master) succeeded!

I updated.

I fixed.
jenkins, test this please.

Jenkins CI test (for commit d656d4f03ac4f289f94f8a77554d07537827edee, target branch master) failed with status FAILURE.

Jenkins, test this please

Jenkins, test this please

Jenkins CI test (for commit cf201d83dfa64eef08abf6f8b4367e6a9cf904a9, target branch master) failed with status FAILURE.

Can you resolve conflict?

Jenkins, test this please

Jenkins CI test (for commit 798e638358c5853b1d30609e406371a2df712890, target branch master) succeeded!


Add SwaggerContext trait used by swagger-codegen middleware

This change adds the SwaggerService trait to swagger-rs, this trait is used by swagger middlewares.

Looks fine as far as it goes.
I was expecting SwaggerService to include C: Has<AuthData> + Has<Authorization> + Has<XSpanID>, since that's what AddContext adds. Would this not simplify the code? Any reason not to?
And is there any advantage to defining Has<AuthData> + Has<Authorization> + Has<XSpanID> as trait SwaggerBaseContext or something like that?

Thanks for the contribution. The code looks sensible.
Two things:

It looks as if SwaggerService is destined for use by middlewares. How will future middleware authors know how to use it?
(a minor point about testing that I'll make in the associated swagger-codegen PR)

@bjgill Hi Ben, I've added some rust doc for SwaggerService, please can you have another look?

Released as 1.0.1


Propagate known pytest failure/skip reasons to pytest summary

In #858, there was some confusion on what an xfailed test meant and why the unit test suit was still considered passing. This PR adds the -rxXs flag to PyTest calls (via nox) so that skips and excepted failure reasons (if they were provided) are reported in the test summary:
pytest tests/unit -rxXs
===================================================== test session starts ======================================================
platform linux -- Python 3.13.0, pytest-8.3.3, pluggy-1.5.0
rootdir: /home/jhkennedy/Documents/Code/contributing/earthaccess
configfile: pyproject.toml
plugins: anyio-4.6.2.post1, cov-6.0.0
collected 46 items

tests/unit/test_api.py ..                                                                                [  4%]
tests/unit/test_auth.py ...                                                                                [ 10%]
tests/unit/test_collection_queries.py ...........                                                                        [ 34%]
tests/unit/test_deprecations.py ..                                                                                [ 39%]
tests/unit/test_formatters.py ..                                                                                [ 43%]
tests/unit/test_granule_queries.py ............                                                                          [ 69%]
tests/unit/test_results.py ........                                                                                [ 86%]
tests/unit/test_services.py ..                                                                                [ 91%]
tests/unit/test_store.py ..x                                                                                [ 97%]
tests/unit/test_uat.py .                                                                                [100%]

=================================================== short test summary info ====================================================
XFAIL tests/unit/test_store.py::test_earthaccess_file_getattr - Expected failure: Reproduces a bug (#610) that has not yet been fixed.
================================================ 45 passed, 1 xfailed in 10.81s ================================================

I've also updated the error message to clarify what's happening in the pytest summary.
I don't think there's much value to a changelog entry here, so I've not added one; happy to add one is anyone things otherwise.

Pull Request (PR) draft checklist - click to expand

[x] Please review our
contributing documentation
before getting started.
[x] Populate a descriptive title. For example, instead of "Updated README.md", use a
title such as "Add testing details to the contributor section of the README".
Example PRs: #763
[x] Populate the body of the pull request with:

A clear description of the change you are proposing.
Links to any issues resolved by this PR with text in the PR description, for
example closes #1. See
GitHub docs - Linking a pull request to an issue.

[x] Update CHANGELOG.md with details about your change in a section titled
## Unreleased. If such a section does not exist, please create one. Follow
Common Changelog for your additions.
Example PRs: #763
[x] Update the documentation and/or the README.md with details of changes to the
earthaccess interface, if any. Consider new environment variables, function names,
decorators, etc.

Click the "Ready for review" button at the bottom of the "Conversation" tab in GitHub
once these requirements are fulfilled. Don't worry if you see any test failures in
GitHub at this point!

Pull Request (PR) merge checklist - click to expand
Please do your best to complete these requirements! If you need help with any of these
requirements, you can ping the @nsidc/earthaccess-support team in a comment and we
will help you out!

[ ] Add unit tests for any new features.
[ ] Apply formatting and linting autofixes. You can add a GitHub comment in this Pull
Request containing "pre-commit.ci autofix" to automate this.
[ ] Ensure all automated PR checks (seen at the bottom of the "conversation" tab) pass.
[ ] Get at least one approving review.

📚 Documentation preview 📚: https://earthaccess--865.org.readthedocs.build/en/865/

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 70.01%. Comparing base (2f49c08) to head (07e2d85).
Report is 70 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #865      +/-   ##
==========================================
- Coverage   73.88%   70.01%   -3.87%
==========================================
  Files          31       23       -8
  Lines        2003     1511     -492
==========================================
- Hits         1480     1058     -422
+ Misses        523      453      -70

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Variables ARGS* just returns the first argument / parameter

MODSEC-429: When i try to readout the GET / POST arguments / parameters via ARGS, ARGS_NAMES, ARGS_GET, ARGS_GET_NAMES, ARGS_POST, ARGS_POST_NAMES ModSecurity responses only with the first argument / paramter.
Example:
GET: url?arg1=value1&arg2=value2 --> only arg1 or value1 are observed by modsecurity
POST: arg1=value1&arg2=value2 --> only arg1 or value2 are observed by modsecurity
I thougt i can readout all arguments / values of GET / POST via the variables ARGS*. ModSecurity returns a string of the first value but not a array with all values.
Is this normal?

@victorhora has this been solved has the LUA interface been updated to support this? otherwise why was this closed?

@csanders-git, In addition to @rcbarnett comment above you can see on page 249 from @dune73 book:
"It’s also possible to retrieve more than one variable at once, but for that you use the m.getvars() function (note the additional s in the name)"
This looks like it solved the issue for the user.
The issue was also closed because of no further activity after 5 years. If there's something else you need in relation to this issue, feel free to add a comment or open a new issue.


Update README to use CDN Image

Done. Looking at this, is it worth adding a test to the website to ensure the Discord link could be clicked? If I'm honest, I didn't even realise we were testing for that kind of stuff!

Looking at this, is it worth adding a test to the website to ensure the Discord link could be clicked? If I'm honest, I didn't even realise we were testing for that kind of stuff!

Is really overkilling. I'm just maintaining the tests as is, no updating them since long time ago. We've accepted some new features without tests.
In fact, I've rewritten the whole website in Rust, see it at https://wasm.simpleicons.org (the repo is https://github.com/mondeja/simple-icons-website-rs) to add proper tests, better performance and the rest of features that are missing here.


feat(promise): add new package @suspensive/promise

related #65
Rename @suspensive/react-await -> @suspensive/promise and we want to merge this feature in @suspensive/react
Initiate with @SEOKKAMONI

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.18%. Comparing base (f1a3962) to head (201845f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1063      +/-   ##
==========================================
+ Coverage   84.15%   84.18%   +0.02%
==========================================
  Files          50       51       +1
  Lines         549      550       +1
  Branches      117      118       +1
==========================================
+ Hits          462      463       +1
  Misses         82       82
  Partials        5        5

Components
Coverage Δ

@suspensive/react
97.03% <ø> (ø)

@suspensive/react-query
75.28% <ø> (ø)

@suspensive/react-query-4
0.00% <ø> (ø)

@suspensive/react-query-5
0.00% <ø> (ø)

@suspensive/jotai
0.00% <ø> (ø)

@suspensive/promise
100.00% <100.00%> (∅)

@suspensive/react-await
100.00% <ø> (ø)

@suspensive/react-image
80.39% <ø> (ø)