Addition of 43 Closure faults

These 43 faults were omitted during the original creation of Defects4J as they were large patches. We have elected to include them now.

FYI - update from yesterday's conversation. TravisCI still failed due to the flaky Mockito relevant tests, but the Closure elements of this are passing. I think we could merge. Double check and let me know if it's fine.

Hi @Greg4cr, thanks for the pull request. Were these new 43 faults reported after D4J v0.0.1? If not, any clue why weren't they include in v0.0.1?
And, btw, did you manually minimise the source patches, e.g., removed any cosmetic changes? At first glance they look minimal to me, but I would have to check in detail each one to be sure.

@jose These 43 defects are part of an ongoing project with @rjust on patch minimization. They were rejected from D4J v0.0.1 for being likely impure patches containing both cosmetic and bug-fixing changes. We have decided to manually minimize them and include them now to add examples to D4J that were not largely-minimal in the first place. @rjust is also working on manually minimizing the initially-rejected faults for Chart, Lang, Math, and Time as part of the same project.
I have manually minimized these to remove cosmetic changes, and they should be in good shape. Of course, additional minimalization is welcome if you spot any obvious changes to make.

cool, I wasn't aware of such project on patch minimization.

@jose Not a problem!

Hi @Greg4cr,
I've just found an interesting case that I would like to discuss with you.
Although the test case com.google.javascript.jscomp.GraphColoringTest::testDeterministic (or com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic) is considered as a non-valid failing test case by D4J and therefore it is discarded for bugs 98, 99, 100, 101, 102, 103, 104, and 105; it is considered (according to your data) as a triggering test case for bugs 156, 157, 158, 160, 161, 162, 163, 164, 165, 166, 167, 168, and 169.
In order to check whether it is indeed a triggering test case I ran it on the fixed version of those bugs:
$ /tmp
$ pid=Closure
$ for bid in 156 157 158 160 161; do \
     rm -rf "$pid-${bid}f" && \
     $D4J_HOME/framework/bin/defects4j checkout -p "$pid" -v "${bid}f" -w "$pid-${bid}f" && \
     cd "$pid-${bid}f" && \
     $D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic; \
     cd /tmp; done
$ for bid in 162 163 164 165 166 167 168 169; do \
     rm -rf "$pid-${bid}f" && \
     $D4J_HOME/framework/bin/defects4j checkout -p "$pid" -v "${bid}f" -w "$pid-${bid}f" && \
     cd "$pid-${bid}f" && \
     $D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.GraphColoringTest::testDeterministic; \
     cd /tmp; done

com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic does fail when executed on the fixed version of bugs 156, 157, 158, 160, and 161; and com.google.javascript.jscomp.GraphColoringTest::testDeterministic fails when executed on the fixed version of bugs 162, 163, 164, 165, 166, 167, 168, and 169. Should not both test cases be considered as a non-valid failing test case and therefore be included in the defects4j/framework/projects/Closure/failing_tests/__revision_id__ file?
PS: Either com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic or com.google.javascript.jscomp.GraphColoringTest::testDeterministic might also fail when executed on the fixed version of other Closure bugs (i.e., 134-176), I haven't check that yet.
--
Best,
Jose

Interesting. I didn't know it was excluded on other earlier Closure
revisions. I left in all tests that the bug mining infrastructure gave me
that weren't clear problems like classpath issues.
In this case, I think your analysis and suggestion make sense. Feel free to
exclude those two tests. I'm on my phone now, so I haven't checked, but
hopefully this doesn't break anything major.
Let me know if you want me to look at anything and I can in the morning
from an actual computer.
On Sun, Sep 30, 2018, 10:55 PM José Campos<EMAIL_ADDRESS>wrote:

Hi @Greg4cr https://github.com/Greg4cr,
I've just found an interesting case that I would like to discuss with you.
Although the test case
com.google.javascript.jscomp.GraphColoringTest::testDeterministic (or
com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic)
is considered as a non-valid failing test case by D4J and therefore it is
discarded for bugs 98, 99, 100, 101, 102, 103, 104, and 105; it is
considered (according to your data) as a triggering test case for bugs 156,
157, 158, 160, 161, 162, 163, 164, 165, 166, 167, 168, and 169.
In order to check whether it is indeed a triggering test case I ran it on
the fixed version of those bugs:
$ /tmp
$ pid=Closure
$ for bid in 156 157 158 160 161; do
rm -rf "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j checkout -p "$pid" -v "${bid}f" -w "$pid-${bid}f" &&
cd "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic;
cd /tmp; done
$ for bid in 162 163 164 165 166 167 168 169; do
rm -rf "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j checkout -p "$pid" -v "${bid}f" -w "$pid-${bid}f" &&
cd "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.GraphColoringTest::testDeterministic;
cd /tmp; done
com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic
does fail when executed on the fixed version of bugs 156, 157, 158, 160,
and 161; and
com.google.javascript.jscomp.GraphColoringTest::testDeterministic fails
when executed on the fixed version of bugs 162, 163, 164, 165, 166, 167,
168, and 169. Should not both test cases be considered as a non-valid
failing test case and therefore be included in the
defects4j/framework/projects/Closure/failing_tests/revision_id file?
PS: Either
com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic
or com.google.javascript.jscomp.GraphColoringTest::testDeterministic
might also fail when executed on the fixed version of other Closure bugs
(i.e., 134-176), I haven't check that yet.
--
Best,
Jose
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rjust/defects4j/pull/167#issuecomment-425777149, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB0-SkYfbg5UTfcnLO4gdKKXsHKdihPdks5ugYQegaJpZM4Vgk95
.

Just reread - if these are failing on both the fixed version and faulty
version, I don't know why they were indicated as trigger tests in the first
place. They, in theory, either passed on the fixed version on my machine,
or were ignored on the fixed version. Don't know off the top of my head
what happened.
On Sun, Sep 30, 2018, 11:03 PM Gregory Gay<EMAIL_ADDRESS>wrote:

Interesting. I didn't know it was excluded on other earlier Closure
revisions. I left in all tests that the bug mining infrastructure gave me
that weren't clear problems like classpath issues.
In this case, I think your analysis and suggestion make sense. Feel free
to exclude those two tests. I'm on my phone now, so I haven't checked, but
hopefully this doesn't break anything major.
Let me know if you want me to look at anything and I can in the morning
from an actual computer.
On Sun, Sep 30, 2018, 10:55 PM José Campos<EMAIL_ADDRESS>wrote:

Hi @Greg4cr https://github.com/Greg4cr,
I've just found an interesting case that I would like to discuss with you.
Although the test case
com.google.javascript.jscomp.GraphColoringTest::testDeterministic (or
com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic)
is considered as a non-valid failing test case by D4J and therefore it is
discarded for bugs 98, 99, 100, 101, 102, 103, 104, and 105; it is
considered (according to your data) as a triggering test case for bugs 156,
157, 158, 160, 161, 162, 163, 164, 165, 166, 167, 168, and 169.
In order to check whether it is indeed a triggering test case I ran it on
the fixed version of those bugs:
$ /tmp
$ pid=Closure
$ for bid in 156 157 158 160 161; do
rm -rf "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j checkout -p "$pid" -v "${bid}f" -w "$pid-${bid}f" &&
cd "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic;
cd /tmp; done
$ for bid in 162 163 164 165 166 167 168 169; do
rm -rf "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j checkout -p "$pid" -v "${bid}f" -w "$pid-${bid}f" &&
cd "$pid-${bid}f" &&
$D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.GraphColoringTest::testDeterministic;
cd /tmp; done
com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic
does fail when executed on the fixed version of bugs 156, 157, 158, 160,
and 161; and
com.google.javascript.jscomp.GraphColoringTest::testDeterministic fails
when executed on the fixed version of bugs 162, 163, 164, 165, 166, 167,
168, and 169. Should not both test cases be considered as a non-valid
failing test case and therefore be included in the
defects4j/framework/projects/Closure/failing_tests/revision_id file?
PS: Either
com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic
or com.google.javascript.jscomp.GraphColoringTest::testDeterministic
might also fail when executed on the fixed version of other Closure bugs
(i.e., 134-176), I haven't check that yet.
--
Best,
Jose
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rjust/defects4j/pull/167#issuecomment-425777149, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB0-SkYfbg5UTfcnLO4gdKKXsHKdihPdks5ugYQegaJpZM4Vgk95
.

Got it. Both test cases (com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic and com.google.javascript.jscomp.GraphColoringTest::testDeterministic) do not fail when I use Java-8, neither on the fixed or buggy version. Is there any chance you ran the bug-mining on Java-8 and then the analysis of the triggering test cases on Java-7? That could explain why they were considered triggering test cases and not failing test cases.
I'm going to automatically regenerate the failing_tests, trigger_tests, relevant_tests, and loaded_classes files using the original patch and Java-7, and I will then manually review whether the patches you minimised are indeed minimal. We should be good to merge this after that.
---8<----
I might have found another (potential) issue. :-/
The patch file of bugs 152 and 156 includes non java files. Due to that, the modified_classes/152.src and modified_classes/156.src include non java classes names.
152.src.patch
diff --git a/src/com/google/javascript/jscomp/parsing/ParserConfig.properties b/src/com/google/javascript/jscomp/parsing/ParserConfig.properties
index 9285339d..a7493162 100644
--- a/src/com/google/javascript/jscomp/parsing/ParserConfig.properties
+++ b/src/com/google/javascript/jscomp/parsing/ParserConfig.properties
@@ -26,10 +26,8 @@
 // The version of the compiler that we're currently building.
 // Should be formatted as:
 // Version# (Revision XXX)
-compiler.version = HEAD

 // The datestamp of the compiler that we're currently building.
-compiler.date = NOW

 // A comma-delimited list.
 jsdoc.annotations =\

This change does not seem related to the bug, i.e., the list of triggering test cases is the same either with or without this change.
156.src.patch
diff --git a/src/com/google/javascript/jscomp/js/runtime_type_check.js b/src/com/google/javascript/jscomp/js/runtime_type_check.js
index 87c94834..fdb7c09d 100644
--- a/src/com/google/javascript/jscomp/js/runtime_type_check.js
+++ b/src/com/google/javascript/jscomp/js/runtime_type_check.js
@@ -97,13 +97,13 @@ jscomp.typecheck.prettify_ = function(expr) {
  * @private
  */
 jscomp.typecheck.getClassName_ = function(expr) {
-  var className = void 0;
+  var className = undefined;
   if (typeof expr == 'object' && expr && expr.constructor) {
     className = expr.constructor.name;
     if (!className) {
       var funNameRe = /function (.{1,})\(/;
       var m = (funNameRe).exec(expr.constructor.toString());
-      className = m && m.length > 1 ? m[1] : void 0;
+      className = m && m.length > 1 ? m[1] : undefined;
     }
   }
   return className;

This change does seem related to the bug, i.e., if I remove it from the patch I get a different number of triggering test cases.
@rjust, is this something we would consider as correct? Or, does this reveal an issue in the bug-mining process?

I am pretty sure I did everything in Java 8 and later verified that I got
the same trigger tests in Java 7 (it took me some time to find a copy of
JDK7 to install), so that's a little strange. In any case, go ahead.
If I recall correctly, the non-Java files were needed in the patch to
correctly compile those two versions.
On Mon, Oct 1, 2018, 6:58 AM José Campos<EMAIL_ADDRESS>wrote:

Got it. Both test cases (
com.google.javascript.jscomp.graph.GraphColoringTest::testDeterministic
and com.google.javascript.jscomp.GraphColoringTest::testDeterministic) do
not fail when I use Java-8, neither on the fixed or buggy version. Is there
any chance you ran the bug-mining on Java-8 and then the analysis of the
triggering test cases on Java-7? That could explain why they were
considered triggering test cases and not failing test cases.
I'm going to automatically regenerate the failing_tests, trigger_tests,
relevant_tests, and loaded_classes files using the original patch and
Java-7, and I will then manually review whether the patches you minimised
are indeed minimal. We should be good to merge this after that.
---8<----
I might have found another (potential) issue. :-/
The patch file of bugs 152 and 156 includes non java files. Due to that,
the modified_classes/152.src and modified_classes/156.src include non
java classes names.
152.src.patch
diff --git a/src/com/google/javascript/jscomp/parsing/ParserConfig.properties b/src/com/google/javascript/jscomp/parsing/ParserConfig.properties
index 9285339d..a7493162 100644
--- a/src/com/google/javascript/jscomp/parsing/ParserConfig.properties
+++ b/src/com/google/javascript/jscomp/parsing/ParserConfig.properties
@@ -26,10 +26,8 @@
// The version of the compiler that we're currently building.
// Should be formatted as:
// Version# (Revision XXX)
-compiler.version = HEAD
// The datestamp of the compiler that we're currently building.
-compiler.date = NOW
// A comma-delimited list.
jsdoc.annotations =\
This change does not seem related to the bug, i.e., the list of triggering
test cases is the same either with or without this change.
156.src.patch
diff --git a/src/com/google/javascript/jscomp/js/runtime_type_check.js b/src/com/google/javascript/jscomp/js/runtime_type_check.js
index 87c94834..fdb7c09d 100644
--- a/src/com/google/javascript/jscomp/js/runtime_type_check.js
+++ b/src/com/google/javascript/jscomp/js/runtime_type_check.js
@@ -97,13 +97,13 @@ jscomp.typecheck.prettify_ = function(expr) {

@private
*/
jscomp.typecheck.getClassName_ = function(expr) {

var className = void 0;

var className = undefined;
if (typeof expr == 'object' && expr && expr.constructor) {
className = expr.constructor.name;
if (!className) {
var funNameRe = /function (.{1,})(/;
var m = (funNameRe).exec(expr.constructor.toString());

 className = m && m.length > 1 ? m[1] : void 0;

 className = m && m.length > 1 ? m[1] : undefined;

}
}
return className;

This change does seem related to the bug, i.e., if I remove it from the
patch I get a different number of triggering test cases.
@rjust https://github.com/rjust, is this something we would consider as
correct? Or, does this reveal an issue in the bug-mining process?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rjust/defects4j/pull/167#issuecomment-425867496, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB0-Sr9mFK9PMx8ZyO1ei8I-_csKof-_ks5ugfVFgaJpZM4Vgk95
.

Hi @Greg4cr,
Quick question, did you use google-code issues tracker or github issues tracker?
--
Best,
Jose

Rene gave me the original commitdb when I gathered these, so I don't know what was used.
@rjust - can you answer @jose's question?

Rene gave me the original commitdb when I gathered these, so I don't know what was used.

In that case it's very likely he used google-code issues tracker.

Hi @Greg4cr,
While re-running the bug-mining framework on these 43 issues I found that the following bugs were annotated as Type-Enhancement and not as Type-Defect, as expected. Therefore, they are not mined by the latest version of the bug-mining framework.

D4J ID
Issue id
Buggy commit
Fixed commit

152
74
d00fc0c64dba6762b649f9690cd52c68b849e118
fe58a5d1750bab2c5d1d0ef16102c1000e761bd8

159
143
c9e89727dc8063d087d28e42629606f4fd74a6e5
465282f1ca28a208b06c47b55fd292d4631c55da

162
116
8ff053c723ec20f5b8e1e9e87164bbd657f7d2ca
3ce4716848eb71b6e78a4545a2cc0c27e74a29b3

163
126
b347ce3a71e23a4ab92dc0a6c07d43e2f497c953
a70a7c599e53a7752cf4b9e6e82b4408c3c4c04b

To keep things consistent I would say we should not mine the above 4 bugs. @Greg4cr, @rjust please let me know what you think.
--
Best,
Jose

I can see both sides of this. On one hand, these four are explicitly
labeled as enhancements, so perhaps they should be omitted.
However, the reason I can also see the other side is that we are about to
look at a large number of systems that also potentially violate this
pattern.
The new projects in the other pull request also break this "rule", not
necessarily because they have defects marked as enhancements, but because
several of the new projects do not use tags at all. I think this might be
true already for the Mockito bugs as well.
Systems like JacksonCore do not use labels like "Bug", so in mining such
systems, I didn't use the default query and instead ignored tags
completely. It is possible that we will have enhancements in those
examples, but they are not tagged as such.
We should decide how much tags matter at some point. Given that the other
rules are being enforced - trigger tests, bug reports - it may make some
sense to consider these to still be "issues" that are being addressed.
I'm curious about your opinion. We could take a policy of omitting bugs
explicitly labeled as enhancements and not worry about ones that lack
explicit labels. However, I thought this was worth discussing further.
On Tue, Feb 5, 2019, 2:09 AM José Campos<EMAIL_ADDRESS>wrote:

Hi @Greg4cr https://github.com/Greg4cr,
While re-running the bug-mining framework on these 43 issues I found that
the following bugs were annotated as Type-Enhancement and not as
Type-Defect, as expected
https://github.com/rjust/defects4j/blob/master/framework/bug-mining/download-issues.pl#L117.
Therefore, they are not mined by the latest version of the bug-mining
framework.
D4J ID Issue id Buggy commit Fixed commit
152 74
https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-74.json
d00fc0c64dba6762b649f9690cd52c68b849e118
fe58a5d1750bab2c5d1d0ef16102c1000e761bd8
159 143
https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-143.json
c9e89727dc8063d087d28e42629606f4fd74a6e5
465282f1ca28a208b06c47b55fd292d4631c55da
162 116
https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-116.json
8ff053c723ec20f5b8e1e9e87164bbd657f7d2ca
3ce4716848eb71b6e78a4545a2cc0c27e74a29b3
163 126
https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-126.json
b347ce3a71e23a4ab92dc0a6c07d43e2f497c953
a70a7c599e53a7752cf4b9e6e82b4408c3c4c04b
To keep things consistent I would say we should not mine the above 4 bugs.
@Greg4cr https://github.com/Greg4cr, @rjust https://github.com/rjust
please let me know what you think.
--
Best,
Jose
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rjust/defects4j/pull/167#issuecomment-460535258, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB0-Sv_Lz7j8Mad4vTUCpT7njcyHLeW6ks5vKS4ngaJpZM4Vgk95
.,

We could take a policy of omitting bugs explicitly labeled as enhancements and not worry about ones that lack explicit labels.

It does sounds a reasonable approach.
FYI, I've just noticed that Closure-95 (issue id 66) from the official D4J database was also reported as Type-Enhancement...

I would recommend keeping the existing defect.
On Tue, Feb 5, 2019, 3:43 PM José Campos<EMAIL_ADDRESS>wrote:

We could take a policy of omitting bugs explicitly labeled as enhancements
and not worry about ones that lack explicit labels.
It does sounds a reasonable approach.
FYI, I've just noticed that Closure-95 (issue id 66
https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-66.json)
from the official D4J database was also reported as Type-Enhancement...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rjust/defects4j/pull/167#issuecomment-460795797, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB0-SqrPgR7mn3UmtJrxaSFCqyNzv2Mqks5vKezbgaJpZM4Vgk95
.

@jose and @Greg4cr I am in favor of bringing these Closure issues in as they are for two reasons. First, this is consistent with how the other Closure bugs were mined. Second, the issues labeled as enhancement are still reproducible issues and the distinction between feature and bug is not always clear. D4J now links the actual issue, so as long as the features are clearly labeled, a user can decide whether to include or exclude them. For example, a proper feature request with valid triggering tests seems to be a valuable resource for synthesis research.

That seems reasonable to me.
On Tue, Feb 5, 2019, 11:33 PM René Just<EMAIL_ADDRESS>wrote:

@jose https://github.com/jose and @Greg4cr https://github.com/Greg4cr
I am in favor of bringing these Closure issues in as they are for two
reasons. First, this is consistent with how the other Closure bugs were
mined. Second, the issues labeled as enhancement are still reproducible
issues and the distinction between feature and bug is not always clear. D4J
now links the actual issue, so as long as the features are clearly labeled,
a user can decide whether to include or exclude them. For example, a proper
feature request with valid triggering tests seems to be a valuable resource
for synthesis research.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rjust/defects4j/pull/167#issuecomment-460898206, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB0-SuSCqojpO_DBi7nCaRVmjzziP7DPks5vKlsZgaJpZM4Vgk95
.

FYI - @jose - there are 20 flaky trigger tests for Closure 156. They all have "Compiler Error" messages and do not fail on TravisCI and some other machines. They also have nothing to do with the actual fault, unlike the two "real" trigger tests for that bug. I have removed them again, and left the two real trigger tests.

Oh, I didn't notice that. Thanks @Greg4cr. Should not we move those ones to Closure/dependent_tests?

Hmm, if those test cases are not true triggering test cases, why were not they considered (by the bug-mining framework) failing_tests in the first place?

@jose Sorry about that, forgot. I just added them to dependent_tests.

@jose - I think they do meet the condition of passing on the fixed version and failing on the faulty version in isolation, but I'm not entirely sure why.  We can investigate further if you want.
We discussed these awhile back, and dropped them because of the fact they are flaky and not clearly related (the two remaining trigger tests are named after the issue).

@jose - I think they do meet the condition of passing on the fixed version and failing on the faulty version in isolation, but I'm not entirely sure why. We can investigate further if you want.

Ok. They might fail on the faulty version due to some configuration changes... I will have a look at that later today.

Got it. I completely forgot to run the get_trigger.pl script after I copied over your minimal patches. In fact, none of those 20 test cases fail on the minimal buggy version. I will rebuild the metadata later.

Thanks! Please also remove the change I made to the dependent tests file.

Hi,
While I was performing some extra sanity checks I noticed that some triggering test cases started to fail due to other reasons after the minimization, i.e., same set of triggering test cases but different exceptions. I think our minimization sanity checks were not as complete as their are now and we didn't catch that.
@Greg4cr, I've just reverted the patches of the problematic ones and would be great if you could please try to re-minimize patches of Closure-156, 163, 172 using the existing minimize-patch script?
--
Best,
Jose

I am having an interesting issue with trying to minimize these. When I run the minimize-patch script for any of these three bugs (as well as 155, which I accidentally tried), I have 1-2 tests that always fail:
--- com.google.javascript.jscomp.CrossModuleMethodMotionTest::testTwoMethods
--- com.google.javascript.jscomp.CrossModuleMethodMotionTest::testClosureVariableReads3
I am using the Java 7 version you linked me to yesterday. Any ideas on why I have these new test failures? Did you run into these?
The stack trace for both are below:
output.txt
I could work around these by blocking them, but am curious if you've had similar issues or if there is some obvious issue on my local machine.

I can only reproduce that if I use Java-8. Could you please double check whether you are indeed using Java-7? To run stuff on Java-7 I usually do the following:
$ export JAVA_HOME=/home/jose/bin/jdk1.7.0_80
$ export PATH="$JAVA_HOME/bin:$PATH"

Java-7
$ java -version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

$ $D4J_HOME/framework/bin/defects4j checkout -p Closure -v 155b -w Closure-155b
$ cd Closure-155b

$ $D4J_HOME/framework/bin/defects4j compile
Running ant (compile)...................................................... OK
Running ant (compile.tests)................................................ OK

$ $D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.CrossModuleMethodMotionTest::testTwoMethods
Running ant (compile.tests)................................................ OK
Running ant (run.dev.tests)................................................ OK
Failing tests: 0

$ $D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.CrossModuleMethodMotionTest::testClosureVariableReads3
Running ant (compile.tests)................................................ OK
Running ant (run.dev.tests)................................................ OK
Failing tests: 0

$ $D4J_HOME/framework/bin/defects4j test
Running ant (compile.tests)................................................ OK
Running ant (run.dev.tests)................................................ OK
Failing tests: 6
  - com.google.javascript.jscomp.PeepholeFoldConstantsTest::testFoldTypeof
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput0
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput1
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput2
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput3
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput4

Six trigger tests as expected.
Java-8
$ java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

$ $D4J_HOME/framework/bin/defects4j checkout -p Closure -v 155b -w Closure-155b
$ cd Closure-155b

$ $D4J_HOME/framework/bin/defects4j compile
Running ant (compile)...................................................... OK
Running ant (compile.tests)................................................ OK

$ $D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.CrossModuleMethodMotionTest::testTwoMethods
Running ant (compile.tests)................................................ OK
Running ant (run.dev.tests)................................................ OK
Failing tests: 1
  - com.google.javascript.jscomp.CrossModuleMethodMotionTest::testTwoMethods

$ $D4J_HOME/framework/bin/defects4j test -t com.google.javascript.jscomp.CrossModuleMethodMotionTest::testClosureVariableReads3
Running ant (compile.tests)................................................ OK
Running ant (run.dev.tests)................................................ OK
Failing tests: 1
  - com.google.javascript.jscomp.CrossModuleMethodMotionTest::testClosureVariableReads3

$ $D4J_HOME/framework/bin/defects4j test
Running ant (compile.tests)................................................ OK
Running ant (run.dev.tests)................................................ OK
Failing tests: 8
  - com.google.javascript.jscomp.CrossModuleMethodMotionTest::testTwoMethods
  - com.google.javascript.jscomp.CrossModuleMethodMotionTest::testClosureVariableReads3
  - com.google.javascript.jscomp.PeepholeFoldConstantsTest::testFoldTypeof
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput0
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput1
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput2
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput3
  - com.google.javascript.jscomp.SourceMapTest::testGoldenOutput4

That was my problem. I had switched java/javac, but forgot to change my JAVA_HOME variable. Working as expected now.

@jose - All three are reminimized. There is a very minor change to the stack traces in all trigger tests:
'''
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
'''
However, the actual exceptions are the same now.

@rjust @jose Shall we merge?

How are the new Closure bugs ordered in the commit-db?

@rjust - They are 144 - 176.

Right, but it seems that the commit-db for these bugs is not ordered in any particular way. Shouldn't the new bugs be ordered chronologically (old to new)?

That was what I would have expected.
The order is based on the commit-db you provided originally. I attached it here. Was there an early point in the project where batches of bugs were added non-chronologically? Maybe from different regex or something?
commit-db.txt

It's possible that the list of candidates was in no particular order (or in a weird one), but the promote script should take care of this while re-enumerating the bug IDs. Is this updated commit-db generated by the promote script? If not, should we run it through this script?

That would be the issue. I did all of this work before the existence of the current promote script.

That makes sense. Let's put these in the right order, and then we are good to go.

Bugs are reordered.

How are the new Closure bugs ordered in the commit-db?

The new mined bugs are ordered as they appear (as fixed) in the commit history, from the oldest to the newest.

The new mined bugs are ordered as they appear (as fixed) in the commit history, from the oldest to the newest.

@jose - This is not actually true for these bugs. The reason for this is that the bug mining framework was NOT used to create the commit-db for the new Closure bugs. Rather, an old commit-db was used, from when Defects4J was first created. This commit-db was not sorted in the same way that newly mined projects would be.
As a result, the bugs were not actually ordered. Rather, there were two broad groupings:

Bugs 134 - 169 represent bugs from roughly 2009-2011, and are ordered from newest to oldest.
Bugs 170 - 176 represent a new group from 2013. These are mostly ordered from newest to oldest, except that 170 and 171 were in the wrong order.

My latest commit reorders all of these, sorted chronologically from oldest to newest. This is why the metadata has changed. The individual bugs have the same metadata they used to, the order has just shifted.

@jose - This is not actually true for these bugs. The reason for this is that the bug mining framework was NOT used to create the commit-db for the new Closure bugs. Rather, an old commit-db was used, from when Defects4J was first created. This commit-db was not sorted in the same way that newly mined projects would be.

But I believe I rebuilt the commit-db using the latest version of the bug mining framework...

hmm, something is not right in the bug-mining framework. according to the git log, the issue 74 was fixed in 2010 and issue 791 was fixed in 2012... :-/
let me try to re-generate the commit_db.

But I believe I rebuilt the commit-db using the latest version of the bug mining framework...

You may have, but it did not change the order in the commit-db. I just compared the commit-db to the old one I used initially, and the ordering is the same. If you run git log on the fix commits, you would see that the ordering is not chronological.
Fix Commit Dates (from before my last commit):
Date: Fri Oct 19 16:41:16 2012 +0000
Date: Fri Aug 10 19:49:41 2012 +0000
Date: Thu Aug 2 22:05:42 2012 +0000
Date: Wed Aug 1 23:56:31 2012 +0000
Date: Mon May 21 15:58:30 2012 +0000
Date: Tue Feb 7 18:37:27 2012 +0000
Date: Tue Dec 6 19:03:54 2011 +0000
Date: Tue Sep 6 23:59:07 2011 +0000
Date: Tue Aug 2 19:34:59 2011 +0000
Date: Fri May 27 17:34:04 2011 +0000
Date: Thu Apr 14 17:48:58 2011 +0000
Date: Wed Apr 6 18:16:30 2011 +0000
Date: Mon Apr 4 21:26:33 2011 +0000
Date: Tue Mar 29 23:46:31 2011 +0000
Date: Sat Mar 26 00:16:46 2011 +0000
Date: Mon Feb 28 16:08:39 2011 +0000
Date: Thu Dec 9 20:58:52 2010 +0000
Date: Thu Oct 28 02:03:31 2010 +0000
Date: Fri Sep 17 19:56:20 2010 +0000
Date: Tue Sep 14 00:41:11 2010 +0000
Date: Fri Aug 6 02:38:20 2010 +0000
Date: Thu Jul 15 21:01:20 2010 +0000
Date: Fri Jul 9 23:02:36 2010 +0000
Date: Wed Jul 7 22:14:18 2010 +0000
Date: Fri Jun 25 23:56:52 2010 +0000
Date: Wed Jun 23 00:19:37 2010 +0000
Date: Wed Apr 7 18:34:02 2010 +0000
Date: Tue Apr 6 06:58:16 2010 +0000
Date: Thu Mar 25 15:58:20 2010 +0000
Date: Tue Mar 23 05:51:47 2010 +0000
Date: Mon Mar 22 22:55:34 2010 +0000
Date: Thu Mar 18 23:07:23 2010 +0000
Date: Thu Mar 18 22:51:03 2010 +0000
Date: Tue Mar 16 22:53:04 2010 +0000
Date: Fri Feb 5 18:31:28 2010 +0000
Date: Fri Jan 8 21:41:36 2010 +0000
Date: Sun Nov 3 15:55:39 2013 -0500
Date: Mon Nov 4 10:58:43 2013 -0800
Date: Sat Sep 28 15:18:56 2013 -0400
Date: Tue Aug 20 11:15:56 2013 -0700
Date: Mon Jul 15 16:05:31 2013 -0700
Date: Tue Jun 18 02:52:07 2013 -0700
Date: Wed Apr 17 13:47:23 2013 -0700
Fix Commit Dates (after changes):
Date: Fri Jan 8 21:41:36 2010 +0000
Date: Fri Feb 5 18:31:28 2010 +0000
Date: Tue Mar 16 22:53:04 2010 +0000
Date: Thu Mar 18 22:51:03 2010 +0000
Date: Thu Mar 18 23:07:23 2010 +0000
Date: Mon Mar 22 22:55:34 2010 +0000
Date: Tue Mar 23 05:51:47 2010 +0000
Date: Thu Mar 25 15:58:20 2010 +0000
Date: Tue Apr 6 06:58:16 2010 +0000
Date: Wed Apr 7 18:34:02 2010 +0000
Date: Wed Jun 23 00:19:37 2010 +0000
Date: Fri Jun 25 23:56:52 2010 +0000
Date: Wed Jul 7 22:14:18 2010 +0000
Date: Fri Jul 9 23:02:36 2010 +0000
Date: Thu Jul 15 21:01:20 2010 +0000
Date: Fri Aug 6 02:38:20 2010 +0000
Date: Tue Sep 14 00:41:11 2010 +0000
Date: Fri Sep 17 19:56:20 2010 +0000
Date: Thu Oct 28 02:03:31 2010 +0000
Date: Thu Dec 9 20:58:52 2010 +0000
Date: Mon Feb 28 16:08:39 2011 +0000
Date: Sat Mar 26 00:16:46 2011 +0000
Date: Tue Mar 29 23:46:31 2011 +0000
Date: Mon Apr 4 21:26:33 2011 +0000
Date: Wed Apr 6 18:16:30 2011 +0000
Date: Thu Apr 14 17:48:58 2011 +0000
Date: Fri May 27 17:34:04 2011 +0000
Date: Tue Aug 2 19:34:59 2011 +0000
Date: Tue Sep 6 23:59:07 2011 +0000
Date: Tue Dec 6 19:03:54 2011 +0000
Date: Tue Feb 7 18:37:27 2012 +0000
Date: Mon May 21 15:58:30 2012 +0000
Date: Wed Aug 1 23:56:31 2012 +0000
Date: Thu Aug 2 22:05:42 2012 +0000
Date: Fri Aug 10 19:49:41 2012 +0000
Date: Fri Oct 19 16:41:16 2012 +0000
Date: Wed Apr 17 13:47:23 2013 -0700
Date: Tue Jun 18 02:52:07 2013 -0700
Date: Mon Jul 15 16:05:31 2013 -0700
Date: Tue Aug 20 11:15:56 2013 -0700
Date: Sat Sep 28 15:18:56 2013 -0400
Date: Sun Nov 3 15:55:39 2013 -0500
Date: Mon Nov 4 10:58:43 2013 -0800

Interestingly, the old Closure bugs are not entirely chronological either, if you go by the git log.

I've just re-executed the bug-mining framework and it does build a similar commit_db file. The only difference is:
Current commit_db file
...
175,d6eebf3357f6f06b44cefbe55aabeab5bf25216e,aeed47f424d93d9ff82e0782fca53259829362b1,1056,https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-1056.json
176,94623ace4074dea70ffdde117a2d5e11c76de5fa,038da2119223818ee1c56eaf600a583f755f9b30,1101,https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-1101.json

vs. commit_db file generated by the bug-mining framework
...
175,94623ace4074dea70ffdde117a2d5e11c76de5fa,038da2119223818ee1c56eaf600a583f755f9b30,1101,https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-1101.json
176,d6eebf3357f6f06b44cefbe55aabeab5bf25216e,aeed47f424d93d9ff82e0782fca53259829362b1,1056,https://storage.googleapis.com/google-code-archive/v2/code.google.com/closure-compiler/issues/issue-1056.json

Issue 1056 was fixed on Nov 3 15:55:39 2013 (aeed47f424d93d9ff82e0782fca53259829362b1), and issue 1101 was fixed on Nov 4 10:58:43 2013 (038da2119223818ee1c56eaf600a583f755f9b30). (Please note that there are two other commits from Oct 1 2013 that also mention issue 1101). Although issue 1056 was fixed a day before issue 1101, its fix message appears after in the repository history, only on Nov 18 2013.

Interesting. I'm willing to go with your version of the 175/176 ordering then.

@Greg4cr could you please make that change?

@jose - done.

Thanks @Greg4cr. @rjust, any other question/comment?


new sample script to update site logo and thumbnail across associated sites within a hub site

Good Morning @reshmee011 - great sample, thank you for sharing, this will be live shortly 🎉😁


remove embedded virtualenv

virtualenv is LGPL, it must be removed from the project.
This means that py<3.7 will now have a system requirement on virtualenv, but that's not so bad - practically all of
py<3.7 is py2, which is much closer to actual deprecation in vfx now. We will abort with an error if virtualenv cannot
be imported in this case.
Note related ticket #1348 - not sure specifically what's going on here, but let's just fall back to virtualenv if venv cannot be
imported, that seems more robust.
Related Issues/PRs

#1348

https://lfscanning.org/reports/aswf/rez-2022-06-10-b01cab7b-ff86-4d95-9353-3af77d08c868.html

What we could do is use the zipapp provided by virtualenv. We would just have to download it during install time.

Download at install time can be a dealbreaker for firewalled corps/studios.
On Sat, Oct 22, 2022 at 3:46 PM Jean-Christophe Morin <
@.***> wrote:

What we could do is use the zipapp
https://virtualenv.pypa.io/en/20.15.1/installation.html#via-zipapp
provided by virtualenv. We would just have to download it during install
time.
—
Reply to this email directly, view it on GitHub
https://github.com/AcademySoftwareFoundation/rez/issues/1349#issuecomment-1287895431,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPOE3UV6M6NH5RBJL62A63WERAB5ANCNFSM536RYOCA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

We could add a flag to disable the virtualenv download.

Looks like virtualenv uses an MIT license now -- https://github.com/pypa/virtualenv/blob/main/LICENSE


Add file encoding

Add EncodingUtil that encodes/decodes data using base64
Update read/write file functionality of FileUtil to implement the encoding scheme

Codecov Report

Merging #240 (258ce25) into master (344a4ae) will increase coverage by 0.31%.
The diff coverage is 93.33%.

@@             Coverage Diff              @@
##             master     #240      +/-   ##
============================================
+ Coverage     45.54%   45.85%   +0.31%
- Complexity      368      372       +4
============================================
  Files            89       90       +1
  Lines          1943     1956      +13
  Branches        195      197       +2
============================================
+ Hits            885      897      +12
- Misses          980      981       +1
  Partials         78       78

Impacted Files
Coverage Δ
Complexity Δ

...java/seedu/budgetbaby/commons/util/EncodeUtil.java
88.88% <88.88%> (ø)
4.00 <4.00> (?)

...n/java/seedu/budgetbaby/commons/util/FileUtil.java
46.15% <100.00%> (+9.79%)
3.00 <2.00> (ø)

Continue to review full report at Codecov.

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


Nested subcommands limit is needed

If output is suppressed nested commands are executed without some limits

Fixed using time limit mechanism


Gazebo SITL simulation build fail in macOS

Describe the bug
I am not able to successfully build and run sitl simulation on gazebo due to some errors. Probably because of opencv 4.0.1 dependency.
Environment
MacOS Mojave 10.14.3
Brew packages upgraded.
firmware: master branch
To Reproduce
Steps to reproduce the behavior:

Checkout master branch
build with command make px4_sitl gazebo_standard_vtol

Expected behavior
Firmware must be built and gazebo should be opened.
Log Files and Screenshots
px4-build-error-mac.log

You need to downgrade OpenCV to version 3 or bellow.


Fixed machine info page and revamped

If user has time :

if user doesn't have time:

There seems to be a conflict for MachineInfo.js


Add support for extraction black-lists in myDIG

Add ability to associate black-list glossaries with fields.
We discussed with @GreatYYX about including the blacklists in the field editor similar to the way that spacy rules can be added. It would be more uniform to use glossaries, but either way is fine as long as the data gets into myDIG.
When a field black list is uploaded, myDIG will query elastic search to retrieve all the pages that contain the bad extractions and put them in the kafka topic so that they get reprocessed. myDIG should remove the KG from the document before adding to the kafka topic.
myDIG needs to save the black-lists as glossaries, eg <fieldname>-blacklist.txt so that ETK can find them an load them.
ETK should reprocess the document from scratch, and after extraction, check the black lists and lower the confidence of the blacklisted extractions to a low number, eg, 0.1. The offending extractions should not be removed as we may need to bring them back if we remove them by mistake.

Assigning to both @saggu and @GreatYYX as there is work from both.

the work on etk side is already complete.


Feature/rename atmos

This is a cleanup PR.  No functional changes.
closes #428

@jhamman Done reviewing - looks good, don't really have comments...


 I may chime in later when not on mobile, but I suggest you take another look at your own code.

You want to partition the saves into transactions, 1000 per save sounds right, but test it.
But what you don't want do to is to create 699999 you don't need.
So in your original code, replace this:
tx.From("epg").Save(&item)

with:
tx.Save(&item)

And move the "bucket selector" out of the loop:
tx := db.From("epg")
tx, _ = tx.Begin(true)

Or something like that. You are sloppy with your error handling, and there is a one-off error in the transaction commit logic, but I guess that is outside the scope of this question.

@spx I am closing this since the problem comes from the implementation rather than from Storm itself. If you still encounters write performance and think we can improve Storm don't hesitate opening again please


Update the example of the multiple terms aggregation by muliple orders.

Description
Update the example of the multiple terms aggregation.
Issues Resolved
Closes #7037
Checklist

[x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

I suggest we don't remove the original example, but add a new one.  Because if it needs only 1 order, it could use original one.  If we change document like this way, it could confuse the old order style is not supported.  But it is not true, it can support both one order with {...} or multiple order with [...].

I suggest we don't remove the original example, but add a new one. Because if it needs only 1 order, it could use original one. If we change document like this way, it could confuse the old order style is not supported. But it is not true, it can support both one order with {...} or multiple order with [...].

I got your point, but the current document is not correct. I am trying to fix it to make it accurate.

@bowenlan-amzn - What are your thoughts on this?

#7037

Please refer to the update in PR: https://github.com/opensearch-project/OpenSearch/pull/13400

@bowenlan-amzn - What are your thoughts on this?

Please refer to the update in PR: https://github.com/opensearch-project/OpenSearch/pull/13400

Hi @dblock - Can you please comment with your thoughts? Thanks.

The current example is incorrect, if I understand correctly it has to be an array of orders, even with 1 order. There's no point in having an array of 1 and then another example with an array of 2, is there?

The current example is incorrect, if I understand correctly it has to be an array of orders, even with 1 order. There's no point in having an array of 1 and then another example with an array of 2, is there?

As far as I know, there is no example of array in the offical doc.

The current example is incorrect, if I understand correctly it has to be an array of orders, even with 1 order. There's no point in having an array of 1 and then another example with an array of 2, is there?

@dblock As current official document, the multi-term example is as below:
GET sample-index100/_search
{
  "size": 0,
  "aggs": {
    "hot": {
      "multi_terms": {
        "terms": [{
          "field": "region"
        },{
          "field": "host"
        }],
        "order": {"max-cpu": "desc"}
      },
      "aggs": {
        "max-cpu": { "max": { "field": "cpu" } }
      }
    }
  }
}

@Zhikai-VM wants to revise it as:
GET sample-index100/_search
{
  "size": 0,
  "aggs": {
    "hot": {
      "multi_terms": {
        "terms": [{
          "field": "region"
        },{
          "field": "host"
        }],
        "order": [ {"max-cpu": "desc"}, {"max-mem": "asc"}]
      },
      "aggs": {
        "max-cpu": { "max": { "field": "cpu" } },
        "max-mem": { "min": { "field": "mem"}}
      }
    }
  }
}

to keep the official document accordance with this PR: https://github.com/opensearch-project/OpenSearch/pull/13400

Hi @dblock , what do you think about this? I prefer to use an array for the 'order' field. We can pass one order or multiple orders in this field.

This looks good to me, can we merge @hdhalter ?

Thanks @dblock @bowenlan-amzn!


Asuswrt not showing any devices on 0.82.1.

Home Assistant release with the issue: 0.82.1

Last working Home Assistant release (if known): 0.81.6
Operating environment (Hass.io/Docker/Windows/etc.): Docker

Component/platform: Asuswrt device tracker

Description of problem: All device tracker entities show not_home whether they are connected or not. Reviewing debug logs shows several commands fail with error code 127 (command not found) although running these commands in an ssh terminal succeeds and provides expected output.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
- platform: asuswrt
  host: <IP_ADDRESS>
  protocol: ssh
  username: !secret router_user
  password: !secret router_pass
  track_new_devices: false
  consider_home: 180

Traceback (if applicable):
2018-11-15 13:42:51 INFO (MainThread) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-11-15 13:42:51 DEBUG (MainThread) [asyncssh] [conn=0, chan=16] Set write buffer limits: low-water=16384, high-water=65536
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=16] Requesting new SSH session
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=16]   Command: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=16] Received exit status 0
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=16] Received channel close
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=16] Channel closed
2018-11-15 13:42:51 DEBUG (MainThread) [asyncssh] [conn=0, chan=17] Set write buffer limits: low-water=16384, high-water=65536
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=17] Requesting new SSH session
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=17]   Command: arp -n
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=17] Received exit status 127
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=17] Received channel close
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=17] Channel closed
2018-11-15 13:42:51 DEBUG (MainThread) [asyncssh] [conn=0, chan=18] Set write buffer limits: low-water=16384, high-water=65536
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=18] Requesting new SSH session
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=18]   Command: ip neigh
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=18] Received exit status 127
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=18] Received channel close
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=18] Channel closed
2018-11-15 13:42:51 DEBUG (MainThread) [asyncssh] [conn=0, chan=19] Set write buffer limits: low-water=16384, high-water=65536
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=19] Requesting new SSH session
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=19]   Command: cat /var/lib/misc/dnsmasq.leases
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=19] Received exit status 0
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=19] Received channel close
2018-11-15 13:42:51 INFO (MainThread) [asyncssh] [conn=0, chan=19] Channel closed

Additional information:
My current Asus setup is an RT-AC88U as my main router with an RT-AC68U connected over ethernet backhaul using AiMesh.

Also having this issue. RT-AC3200
Logs:
2018-11-15 20:55:39 INFO (MainThread) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=196] Requesting new SSH session
2018-11-15 20:55:39 INFO (MainThread) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=196] Requesting new SSH session
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=196] Command: for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=196] Received exit status 0
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=196] Received channel close
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=196] Channel closed
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=197] Requesting new SSH session
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=197] Command: arp -n
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=197] Received exit status 127
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=197] Received channel close
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=197] Channel closed
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=198] Requesting new SSH session
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=198] Command: ip neigh
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=198] Received exit status 127
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=198] Received channel close
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=198] Channel closed
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=199] Requesting new SSH session
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=199] Command: cat /var/lib/misc/dnsmasq.leases
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=199] Received exit status 0
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=199] Received channel close
2018-11-15 20:55:39 INFO (MainThread) [asyncssh] [conn=0, chan=199] Channel closed

I also have the same problem when I update to homeassistant 0.82.1 (RT-AC68U)
versions
(homeassistant) jun0813@droidbox:~/homeassistant$ pip list | grep "homeassistant|aioasuswrt"
aioasuswrt              1.1.6
homeassistant           0.82.1
logs:
2018-11-16 08:27:37 INFO (MainThread) [homeassistant.components.device_tracker.asuswrt] Checking Devices
2018-11-16 08:27:37 DEBUG (MainThread) [asyncssh] [conn=0, chan=12] Set write buffer limits: low-water=16384, high-water=65536
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=12] Requesting new SSH session
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=12]   Command: for dev in nvram get wl_ifnames; do wl -i $dev assoclist; done
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=12] Received exit status 0
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=12] Received channel close
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=12] Channel closed
2018-11-16 08:27:37 DEBUG (MainThread) [asyncssh] [conn=0, chan=13] Set write buffer limits: low-water=16384, high-water=65536
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=13] Requesting new SSH session
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=13]   Command: arp -n
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=13] Received exit status 127
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=13] Received channel close
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=13] Channel closed
2018-11-16 08:27:37 DEBUG (MainThread) [asyncssh] [conn=0, chan=14] Set write buffer limits: low-water=16384, high-water=65536
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=14] Requesting new SSH session
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=14]   Command: ip neigh
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=14] Received exit status 127
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=14] Received channel close
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=14] Channel closed
2018-11-16 08:27:37 DEBUG (MainThread) [asyncssh] [conn=0, chan=15] Set write buffer limits: low-water=16384, high-water=65536
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=15] Requesting new SSH session
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=15]   Command: cat /var/lib/misc/dnsmasq.leases
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=15] Received exit status 0
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=15] Received channel close
2018-11-16 08:27:37 INFO (MainThread) [asyncssh] [conn=0, chan=15] Channel closed

Duplicate of #18281

@zetaphoenix Sorry. Opened this issue because#18281 was closed after the last PR.

fixed 0.83

@Bahnburner
Completely reasonable. I just wanted to link the two issues as the appeared to be the same root cause and a majority of the testing and discussion was on the other issue.

any way to fix it sooner? by replacing files or something? thank You.

Revert back to 0.81.6: sudo pip3 install homeassistant==0.81.6

I also need to revert until this is fixed but there aren't any instructions for reverting Hass.io. @hulkhaugen does that work on hass.io?

Sorry, I'm not sure but I don't think so. I use virtualenv.

To revert hassio, ssh into your system and use the command:
hassio ha update -o version=0.81.6

Thank you I'll give it a go.

It worked like a charm! Thank You!

@adas4190 @captainnapalm To revert hassio, ssh into your system and use the command:
hassio ha update -o version=0.81.6

Had the same issue.  The above solution worked for me.

@adas4190 @captainnapalm To revert hassio, ssh into your system and use the command:
hassio ha update -o version=0.81.6

Had the same issue. The above solution worked for me.

I've just downgraded the version and the solution has worked for me too.

I was banging my head against a brick wall over this...
I could ssh to the router and the commands were working. I put the file permissions at 777. The logs showed HA was connecting to the router. Nothing seemed to work.  :sob:
So very glad to finally find this issue. Looking forward to 0.83!

Have you tested this in 0.83?

I just tried the latest pre-release 0.83.0b1 and asuswrt setup completely fails now.
2018-11-27 10:59:57 ERROR (MainThread) [homeassistant.setup] Error during setup of component asuswrt
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/setup.py", line 145, in _async_setup_component
    hass, processed_config)
  File "/usr/src/app/homeassistant/components/asuswrt.py", line 48, in async_setup
    conf = config[DOMAIN]
KeyError: 'asuswrt'

I get the same error and traceback as above in 0.83.0b3

Its no longer a platform, its an component

Boom! that works nicely. Thanks @kennedyshead
For others, you can see the docs here:
https://github.com/home-assistant/home-assistant.io/blob/next/source/_components/asuswrt.markdown

Ah thanks. It seems I now have to provide a port (23) when using telnet, as it defaults to 22. I'm also experiencing issue #18735 but it looks like that should be resolved in an upcoming release.


remove Javaland card

Description

Urgency

[ ] Blocker
[x] High
[ ] Medium

Requirements

Test all commands and procedures.
Build content locally and test for formatting/links.
Add redirects to dcos-website/redirect-files.
Change all affected versions (e.g. 1.7, 1.8, and 1.9).
See the contribution guidelines.

Why was the entire event removed? Isn't there a slide deck, video, or something we can link to?
It's sadly common for conference and event websites to go offline after the event, or be removed in anticipation of the event for the next year. We'll be deleting a lot of our event participation history if our policy is to remove them just because the link is gone.

I just don't think people will scroll that far back in the queue (this was
from March, so it's like 10 clicks back). It's still captured in a JIRA
ticket. Once the Event pages ship we'll start posting resources going
forward, but until then I don't think really old event cards are worth
saving. It's an ever expanding amount of effort to keep them up to date,
and we'll probably have to delete old ones anyway so the website doesn't
get infinitely large. :) We can discuss more in our stand up?
On Fri, Sep 8, 2017 at 8:08 AM, Elizabeth K. Joseph <
<EMAIL_ADDRESS>wrote:

Why was the entire event removed? Isn't there a slide deck, video, or
something we can link to?
It's sadly common for conference and event websites to go offline after
the event, or be removed in anticipation of the event for the next year.
We'll be deleting a lot of our event participation history if our policy is
to remove them just because the link is gone.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dcos/dcos-website/pull/1427#issuecomment-328129527,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARPo9ZElU4XukuW9AjBeuzL7NlNyAKG7ks5sgVhhgaJpZM4PQqQZ
.

--
Judith Malnick
DC/OS Community Manager
310-709-1517


Stop on error during install check

The inline script wasn't stopping on errors, so I'm using
a real bash script. Here's hoping it works better.

Looks weird but the failure is good. Means that it's working, we need to fix the publish for helm and azure too. Onwards!


add offline_patch script

What type of PR is this?

/kind feature
What this PR does / why we need it:

add script  to create a offline patch file

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

/lgtm


Thank you!

[Enter feedback here]
This is much better than the previous version. Thank you for the updates!

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

ID: 17d27a0d-c072-8c9f-7e31-3de60bee9ae8
Version Independent ID: e0c09794-e712-19ff-cb9f-12648d60d4f6
Content: Asynchronous programming in C#
Content Source: docs/csharp/programming-guide/concepts/async/index.md
Product: dotnet-csharp
Technology: csharp-async
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Thank you for the compliments @robauer
Closing as kudos.


Rolling resatrt only possible when cluster is green

The operator implements rolling restart for the pods i.e. if there are any changes, the operator will manually restart the pods so that the latest changes are reflected.
Before we do attempt to restart, we are checking the cluster health to be green and if it is not then we don't proceed with the restart. But in some cases, it might be such that the cluster health can only be fixed via some changes to the CR and to the pods but since we don't all restarting without green health, the operator is stuck forever to wait for green health and the new updates are never picked up.
I think the operator should check for the availability of certain number of nodes (maybe data nodes) rather than checking for health or maybe a flag to allow restart even with yellow health.

Where there is no persistent storage this could potentially lead to data loss.  Perhaps there could be a field where we allow a user to choose thresholds for continuing with a restart.


[AG Grid] v2 draft ag grid docs

uitk #582
[AG-Grid]
Documentation

Made some minor updates and approved.


End to End Machine learning with Snowflake and Dataiku - No Knoema Labor Data Atlas in MarketPlace

Describe the bug
I'm doing the tutorial 'End to End Machine learning with Snowflake and Dataiku
https://quickstarts.snowflake.com/guide/end_to_end_machine_learning_with_dataiku/index.html#3
Step 4 - Load into SnowFlake
section - 5 - Adding unemployment data from Marketplace.
I can't find an option for Knoema Labor Data Atlas in the MarketPlace

@JRabida, see https://github.com/Snowflake-Labs/sfquickstarts/issues/990#issuecomment-1909121883

Closing issue, duplicate of #990 commented above.
Thank you, @stevewithington


kube_config.py is unable to merge configs when one of configs has removed all contexts

  File \"/home/myuser/.local/lib/python3.6/site-packages/kubernetes/config/kube_config.py\", line 664, in load_kube_config
    persist_config=persist_config)
  File \"/home/myuser/.local/lib/python3.6/site-packages/kubernetes/config/kube_config.py\", line 620, in _get_kube_config_loader_for_yaml_file
    kcfg = KubeConfigMerger(filename)
  File \"/home/myuser/.local/lib/python3.6/site-packages/kubernetes/config/kube_config.py\", line 574, in __init__
    self.load_config(path)
  File \"/home/myuser/.local/lib/python3.6/site-packages/kubernetes/config/kube_config.py\", line 592, in load_config
    self._merge(item, config.get(item, {}), path)
  File \"/home/myuser/.local/lib/python3.6/site-packages/kubernetes/config/kube_config.py\", line 597, in _merge
    for new_item in add_cfg:
TypeError: 'NoneType' object is not iterable

when:
KUBECONFIG=/home/myuser/.kube/config:/home/myuser/.kube/microk8s.config

and for example one of them defines null contexts:
contexts: null

It happens when
kubectl config delete-context microk8s

is invoked and there is no context left in kube config file.
Fix proposal add if:
    def _merge(self, item, add_cfg, path):
        if add_cfg is not None:
          for new_item in add_cfg:

around
https://github.com/kubernetes-client/python-base/blob/a2d1024524de78b62e5f9aa72d34cb9ea9de2b97/config/kube_config.py#L596

/assign @palnabarun

Hi, I also encounter this issue with error like:
  File "/Users/weininghu/.pyenv/virtualenvs/kafka-topic-manager/3.7.8/lib/python3.7/site-packages/kubernetes/config/kube_config.py", line 672, in _merge
    for new_item in add_cfg:
TypeError: 'NoneType' object is not iterable

Is this issue being working on?

I'm also getting this error
    def _merge(self, item, add_cfg, path):
>       for new_item in add_cfg:
E       TypeError: 'NoneType' object is not iterable

../../venv/lib/python3.7/site-packages/kubernetes/config/kube_config.py:672: TypeError


Hangman Game Project

The user first has to input their names and then, will be asked to guess any alphabet. If the random word contains that alphabet, it will be shown as the output(with correct placement) else the program will ask you to guess another alphabet. Users will be given 10 turns(can be changed accordingly) to guess the complete word.
Fix #88
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Add resources in the README present at root. Don't create a separate README
Change folder name to HANGMAN_GAME
add some screenshots of the outputs in the folder


reboot doesn't honor disk encryption setting in earlier tinkerbell action during EKS anywhere cluster creation for bare metal

What happened:
I try to introduce disk encryption in EKS anywhere cluster for bare metal as follows:
I try to setup the the disk encryption for directory like /var in a tinkerbell action (right before tinkerbell action reboot).
Everything looks good in following areas:

/dev/mapper/ has cryption target name "sda1_crypt"
/etc/fstab maps "/var" to "/dev/mapper/sda1_crypt" with type "ext4"
/etc/crypttab maps target "sda1_crypt" to partition "/dev/sda1", which is consistent with output of "fdisk -l"

Only interesting thing is that, after command "cryptsetup luksOpen /dev/sda1 sda1_crypt" in the tinkerbell action, dummy file /etc/crypttab is not generated (if we run the command in command line, we will see /etc/crypttab shows up with a comment line).
However, tinkerbell action "reboot" doesn't ask for passphrase, and after reboot, all the cryption setting mentioned above disappears.
What you expected to happen:
I expected reboot will ask for encryption passphrase, and after reboot, the encryption settings will stay
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

EKS Anywhere Release:
EKS Distro Release:

@jacobweinstock thanks for your explanation.
Do you plan to make the change so we can get consistent experience with HookOS and later the OS installed on the disk w.r.t /dev especially /dev/mapper, and also reboot asking for passphrase, and the config in /etc ?
My full Tinkerbell workflow is in the EKS anywhere machine template, the main ones are the last 2, "partition_cmds" and "reboot":
    tasks:
    - actions:
      - environment:
          COMPRESSED: "true"
          DEST_DISK: /dev/sda
          IMG_URL: <urlprefix>/ubuntu-2004-efi-eksa-sp-kube-v1.26.7.gz
        image: public.ecr.aws/eks-anywhere/tinkerbell/hub/image2disk:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-15
        name: stream-image
        timeout: 2400
      - environment:
          CONTENTS: |
            datasource:
              Ec2:
                metadata_urls: <urls>
                strict_id: false
            manage_etc_hosts: localhost
            warnings:
              dsid_missing_source: off
          DEST_DISK: /dev/sda2
          DEST_PATH: /etc/cloud/cloud.cfg.d/10_tinkerbell.cfg
          DIRMODE: "0700"
          FS_TYPE: ext4
          GID: "0"
          MODE: "0600"
          UID: "0"
        image: public.ecr.aws/eks-anywhere/tinkerbell/hub/writefile:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-15
        name: add-tink-cloud-init-config
        timeout: 90
      - environment:
          CONTENTS: |
            network:
              config: disabled
          DEST_DISK: /dev/sda2
          DEST_PATH: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
          DIRMODE: "0700"
          FS_TYPE: ext4
          GID: "0"
          MODE: "0600"
          UID: "0"
        image: public.ecr.aws/eks-anywhere/tinkerbell/hub/writefile:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-15
        name: disable-cloud-init-network-capabilities
        timeout: 90
      - environment:
          CONTENTS: |
            datasource: Ec2
          DEST_DISK: /dev/sda2
          DEST_PATH: /etc/cloud/ds-identify.cfg
          DIRMODE: "0700"
          FS_TYPE: ext4
          GID: "0"
          MODE: "0600"
          UID: "0"
        image: public.ecr.aws/eks-anywhere/tinkerbell/hub/writefile:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-15
        name: add-tink-cloud-init-ds-config
        timeout: 90
      - environment:
          BLOCK_DEVICE: /dev/sda2
          CHROOT: "y"
          CMD_LINE: apt -y update && apt -y install openssl
          DEFAULT_INTERPRETER: /bin/sh -c
          FS_TYPE: ext4
        image: public.ecr.aws/eks-anywhere/tinkerbell/hub/cexec:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-41
        name: install-openssl
        timeout: 90
      - environment:
          BLOCK_DEVICE: /dev/sda2
        image: armadaeksatest.azurecr.io/disk_action:v0.1
        name: partition-cmds
        timeout: 120
      - environment:
          BLOCK_DEVICE: /dev/sda2
          FS_TYPE: ext4
          CHROOT: "y"
          DEFAULT_INTERPRETER: "/bin/sh -c"
          CMD_LINE: "useradd --password $(openssl passwd -1 tinkerbell) --shell /bin/bash --create-home --groups sudo tinkerbell"
        image: public.ecr.aws/l0g8r8j6/tinkerbell/hub/cexec:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-v0.0.0-dev-build.2301
        name: "create-user"
        timeout: 90
      - environment:
          BLOCK_DEVICE: /dev/sda2
        image: <prefix>disk_action:v0.1
        name: partition-cmds
        timeout: 120
      - name: "reboot"
        image: public.ecr.aws/eks-anywhere/tinkerbell/hub/reboot:6c0f0d437bde2c836d90b000312c8b25fa1b65e1-eks-a-15
        timeout: 90
        volumes:
          - /worker:/worker
      name: mgmt02
      volumes:
      - /dev:/dev
      - /dev/console:/dev/console
      - /lib/firmware:/lib/firmware:ro
      worker: '{{.device_1}}'
    version: "0.1"


[pravega-operator] Issue 26: Updating Pravega operator CRD

Signed-off-by: anishakj<EMAIL_ADDRESS>Change log description
Updating pravega operator CRD to include influxdb secret
Purpose of the change
Fixes #26
What the code does
Updated the CRD to include  new spec field
How to verify it
Able to install operator charts
Checklist
(Place an '[x]' (no spaces) in all applicable fields)

[x] PR title starts with the name of the chart followed by the issue number (e.g. [bookkeeper-operator] Issue XX: "Description")
[ ] Verified output of helm lint
[x] Changes have been tested manually

Changes LGTM
@anishakj could you file another issue for fixing the linting error?

Raised issue https://github.com/pravega/charts/issues/39 to track this


Support for replacing a policy of a certain type in HTTP pipeline

For future investigation:
Should we have a getPolicyName() method here to allow for replacing a policy in a default pipeline? This can be a default method where the names are just uuids.
Default pipeline created by the generator:
Policy Name -> Policy instance
Retry -> RetryPolicy
Authentication -> BearerTokenAuthenticationPolicy
Redirect -> RedirectPolicy
Logging -> HttpLoggingPolicy
Convenience layer/customer can replace one or more policies above without having to recreate the whole pipeline. Here we use the getPolicyName() method to find if it already exists in the default pipeline and should be replaced.
Retry -> RetryPolicy
Authentication -> MyCustomAuthPolicy
Redirect -> MyCustomRedirectPolicy
Logging -> HttpLoggingPolicy

My proposal is to start by not generating any addPolicy APIs, and then consider a more comprehensive API in future releases. For example, one option might be: https://gist.github.com/JonathanGiles/90ebc2be0ac27523d4df9bbbdc7d1d86
If we agree on this, the action item would be to ask @srnagar to not generate addPolicy methods on builders for now.

Closing this in favour of an uber method over in #39841


REPLACE INTO take 2

@sougou this just rebases what I did previously onto current master.  I'm going to take a quick look at making it PASS_DML like we discussed. Will that automatically work for RBR, or do we need to add that too?

Added PASS_DML, and I see that the RBR check is already in there

I feel like I could remove the unsharded check now with PASS_DML, right?

The endtoend I added for replace are failing because of the PASS_DML/RBR check -- the endtoend tests are not run with RBR.  I'm wondering if PASS_DML really need endtoend tests since we aren't modifying or interacting with the query at all. Otherwise, how to make endtoend optionally use RBR

@sougou replaced the tests. I couldn't find an example in tabletserver_test, those seemed mostly related to tablet execution. Instead i did the test in query_executor.


Tracking datasets for each run

Not a bug, more of a feature request: it would be awesome if we could track the dataset (features) for each run/execution.

What do you mean exactly? We recommend logging your datasets, feature names, etc as parameters so that they get tracked that way. This also makes it easy to rerun your project on new data, which will be useful in the future.


feature request on makesum and makecompose

Description
PathEffectFactory.MakeSum()
PathEffectFactory.MakeCompose()

this should be implemented in great use of help 👍

these look so beautiful :)
I think you can build these path effects manually, we do provide you with the APIs for it that would also be available on CanvasKit, namely the ContourMeasureIter API,
Here are some examples:
https://www.youtube.com/watch?v=PfCQEA72ljU
https://www.youtube.com/watch?v=7SCzL-XnfUU
And in this intro, the path at the beginning is computed using ContourMeasureIter: https://www.youtube.com/watch?v=3p3NI1yIgcM
If you would like to go the road of making the contribution to canvaskit directly (we did made some in the past), I could provide you with the instructions on how to do it.


Update to current SendGrid heroku env name

Just tried and Heroku sets it now up with SENDGRID_USERNAME

I could be wrong, but I don't think if this change is needed if you are following the steps in the readme on setting up Sendgrid.  See my comment at https://github.com/sahat/hackathon-starter/issues/625
I think you may have used the Heroku add-in workflow for adding SendGrid instead of the steps outlined in readme.md.
From the readme.md:

Go to https://sendgrid.com/user/signup
Sign up and confirm your account via the activation email
Then enter your SendGrid Username and Password into .env file

Ah I see, okay good point! Thanks for taking the time!


Speedy username to unable to authenticate to database

No matter how much I tried using the docker compose file for MariaDB and Postgres as listed, the user Speedy could not connect to the database from reading the docker logs. Source: https://docs.speedtest-tracker.dev/getting-started/installation/installation
Could this please be checked?
This solution worked for me:
https://gist.github.com/luckman212/40ff0a827c12007c8c79ff275d390767
Also the "version  3.4" line is deprecated. Please remove as it throws up errors when running the compose file.

If you changed the username or password after starting the containers initially it wont be correct as the username and password for the database user are set on the first startup.
Delete the database volume, change the password and then start the containers again.


fix: update command args to be exact one

Signed-off-by: Cindy<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
fix: update command args to be exact one
Ⅱ. Does this pull request fix one issue?

none
Ⅲ. Describe how you did it
fix a line of code.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

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

LGTM. I think the change makes sense. Thanks a lot for your fix. @cindy1764

Codecov Report

Merging #822 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master     #822   +/-   ##
=======================================
  Coverage   14.49%   14.49%
=======================================
  Files         112      112
  Lines        6728     6728
=======================================
  Hits          975      975
  Misses       5675     5675
  Partials       78       78

Impacted Files
Coverage Δ

cli/update.go
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Update add-storage-space.md

For problem https://github.com/MicrosoftDocs/OfficeDocs-O365ITPro/issues/355, Plan E2 and E4 have been removed from the article as they don't exist now so buying storage doesn't applicable on this.

It is correct as originally written because some customers still have those old plans.


[PE-D][Tester B] Typo in example for delete meeting

Should be deletepersonfrommeeting 1 instead of deletepersonfrommeeting1

Labels: type.DocumentationBug severity.Low
original: RachelChua/ped#12

fixed in #136


Visibility into release scheduling process

When I deploy a release, it is unclear to me how the subsequent release scheduling process works. I typically SSH into my device and run docker ps repeatedly until I see that my change has taken effect.
It would be nice to have some visibility into the status of the scheduling process.

Visibility into the state of services is something we definitely need more of. This is a high priority issue for us and we're going to work on it soon!

Bump ... on my Device Overview, none of my running services are being displayed?
Also ... you ought to considering tightening up the page layouts ... having to scroll to the bottom of the Device Overview to see services doesn't make sense ... that is one of the most important things I want to see.

Closing this issue since this project appears to be abandoned.


docker compose with minio

Any chance that this can be added to the repo ?
https://github.com/nhost/hasura-storage/tree/main/build/dev/docker
The docker compose uses a docker out of each folder.
The root make file does all the hard work..

You should remove aws access and aws secret default values ;-)


fix prettier

[x] read the CONTRIBUTING guidelines
[ ] raised a GitHub issue or discussed it on the projects chat beforehand
[ ] added unit tests
[ ] added integration tests
[ ] updated documentation if needed
[ ] updated CHANGELOG.md

I was too fast when merging #1893, forgot to run prettier.

merged!


Bug 1175070 - Fixes AVM1 ActionEquals2 behavior.

Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1175070
SWF spec defines ActionEquals2 behavior be the same as defined in ECMA-262 Section 11.9.3.

/botio test

Reference tests: FAILED
Trace log: http://areweflashyet.com:8081/aa3e54818ad5624/reftrace.log

Infra errors. See #2333 and Bug 1193595
r? @tschneidereit

I added quite a few comments below. In a way the most important change I'd request is to change the step comments. It's hard to compare the implementation with the spec if I have to translate the step names in my head all the time.
However, I also think that it'd make a lot of sense to at least do some things to speed this up. This isn't premature optimization because we know that this is going to be one of the hottest functions in the whole engine, sadly. (No, AS1/2 devs don't use strict equality all that often.)
(I also realized that we have a bug in alToNumber, because the empty string results in 0 in JS, not in NaN. Will send a PR to fix that.)
Cancelling review for now.

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, 7 unresolved discussions, all commit checks successful.

src/avm1/interpreter.ts, line 311 [r1] (raw file):
Please add a link to the section of the spec.

src/avm1/interpreter.ts, line 312 [r1] (raw file):
Perhaps "Coerces x and y to the same type and returns true if they're equal, false otherwise."?

src/avm1/interpreter.ts, line 315 [r1] (raw file):
By "steps 1-13" you mean step 1 with its sub-steps, right? If so, please change to "Step 1 can ...". As it is right now, the reader has to count out the sub-steps.
Also, please store the typeof results in vars at the beginning and use them everywhere below. The compiler might do it for you, but it'll at least take a bit, whereas it's straight-forward to do manually.

src/avm1/interpreter.ts, line 318 [r1] (raw file):
Same here: please change these to "Steps 2,3", and also fix the numbering below.

src/avm1/interpreter.ts, line 322 [r1] (raw file):
Given how extremely hot this function is going to be, it might make sense to inline the relevant parts of alToNumber here and below. For this case, the inlining would be return x === (y === '' ? (context.swfVersion < 5 ? 0 : NaN) : +y).

src/avm1/interpreter.ts, line 328 [r1] (raw file):
No need to use alToNumber here: it's 100% functionally identical to just using +x.
What's more, would return +x === alToNumber(context, y) not also be the same? It's be a huge load faster, that's for sure. Same in the next step.

test/swfs/avm1/operations/actionequals2.swf.trace, line 9 [r1] (raw file):
Additional tests that'd make sense:
false == {valueOf: function(){return false}}
true == {valueOf: function(){return true}}
Also, similar things with toString.

Comments from the review on Reviewable.io

Addressed almost of comments, except typeof optimization

Review status: 1 of 5 files reviewed at latest revision, 2 unresolved discussions, some commit checks pending.

src/avm1/interpreter.ts, line 316 [r1] (raw file):
No really, it's steps in the ecmascript 262 version 3 specification.
Per IRC, we agree to not cache typeof x just yet. However I can change that if needed.

src/avm1/interpreter.ts, line 326 [r1] (raw file):
actionequals2 is not present in swf < 5

Comments from the review on Reviewable.io

Very nice. r=me with the remaining feedback addressed. The '' to number coercion being the most important. A test for that would be nice.

Reviewed 4 of 4 files at r2.
Review status: all files reviewed at latest revision, 4 unresolved discussions, all commit checks successful.

src/avm1/interpreter.ts, line 311 [r2] (raw file):
Didn't see this last time around, but the header should contain the spec version: "EcmaScript 3, Section ..." (And no, the "Ecma" in "EcmaScript" isn't all upper-case, don't ask me.)

src/avm1/interpreter.ts, line 315 [r1] (raw file):
Oh, ok. That makes me realize that the comment should contain the spec version.

src/avm1/interpreter.ts, line 322 [r1] (raw file):
That's excellent. It means that just using + is never correct, though: JS engines convert '' to 0, AVM1 to NaN :(

src/avm1/interpreter.ts, line 334 [r2] (raw file):
Clever!

Comments from the review on Reviewable.io

/botio test


Blog post link returns page not found

Blog post link -- https://blogs.msdn.microsoft.com/gyan/2014/09/02/event-hubs-receiver-epoch/|
returns page not found error.
Update with latest link please!

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

ID: 78479c3a-c7b1-e27c-b390-107ba95d0fac
Version Independent ID: 75219d0f-6fa7-0991-7fc0-bfe59e4c1da6
Content: What is Azure Event Hubs Event Processor Host and why use it
Content Source: articles/event-hubs/event-hubs-event-processor-host.md
Service: event-hubs
GitHub Login: @ShubhaVijayasarathy
Microsoft Alias: shvija

@ShubhaVijayasarathy the link to a blog post in this section is broken, could you take a look:
https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-event-processor-host#shut-down-gracefully

I am also looking for that content.

@ShubhaVijayasarathy Any news on this?  The link is still dead.  It looks like much of the information was replicated at https://blog.csdn.net/iamlihongwei/article/details/53486928 if the blogs.msdn.microsoft.com content is not recoverable.

Worked with @ShubhaVijayasarathy to publish content in the article:
https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-event-processor-host#epoch

#please-close


Zone Type Question (Zones vs Regions)

I'm currently expanding RDE's script to include detection for the country side region. The game uses this zone in dispatch.meta so I was hoping it would be listed in the natives somewhere.
<ZoneType>VEHICLE_RESPONSE_COUNTRYSIDE</ZoneType>
So far the only way I've seen to do this is by naming all the zones within the country side region individually since there's multiple zones within this region. I've seen the enum list to do this. I was hoping for a more "clean" method to detect the country side region instead of bundling zones together otherwise it'll be more tedious for me to set it up.
It would be awesome if there was something like this (Game.player.IsInCountryside) as a check. I've searched natives and haven't found anything resembling that however.
As a side note I plan to do something like this with the ocean at some point as well so an ocean region detection method would be neat. It's difficult to specify something to only spawn in ocean waters. Maybe zone types could be combined into regions or maybe there's an easier way to do this?

Update:
Upon further investigation I think I may have found something concerning the ocean region.
int GET_ZONE_FROM_NAME_ID(char *zoneName) // 0x98CD1D2934B76CC1 0x8EC68304 //'zoneName' corresponds to an entry in 'popzone.ipl'.
Here is a list of zones per the 'popzone.ipl'
http://pastebin.com/E58Tz7VL
According to this information PacificOcean = OCEANA
So I attempted to do something like this:
if (Function.Call(Hash._0x98CD1D2934B76CC1, player.Character, OCEANA))
But I get multiple errors telling me "OCEANA" has no reference.
Maybe I'm on to something and then again maybe I'm not. I'd really not like to be calling coords for so many areas especially since there's sub zones within zones. Would be a lot more simple if I could use the zone names instead of coords.
Has anyone of you tried to set up something like this?

Update#2:
Wanted to report some progress on determining regions.
There is currently only two regions that can be used: Countryside and City
Here is the code:
                            uint MapArea;                             MapArea = Function.Call<uint>(Hash.GET_HASH_OF_MAP_AREA_AT_COORDS, Game.Player.Character.Position.X, Game.Player.Character.Position.Y, Game.Player.Character.Position.Z);                             if (MapArea ==<PHONE_NUMBER>) //4005646697 = city hash                                 UI.Notify("Player is at map hash name city");                             if (MapArea == Game.GenerateHash("countryside"))                                 UI.Notify("Player is at map hash name countryside");                 else                                 UI.Notify(MapArea.ToString());
Sadly no way to specify the Ocean region..... hopefully there is a way though.

Update#3:
Using the following I was able to find the ocean region:
uint ZoneName;
ZoneName = Function.Call(Hash.GET_NAME_OF_ZONE, Game.Player.Character.Position.X, Game.Player.Character.Position.Y, Game.Player.Character.Position.Z);
UI.Notify(ZoneName.ToString());
using (System.IO.StreamWriter write = new System.IO.StreamWriter("nativeTesteroutput.txt", true))
write.WriteLine(ZoneName.ToString());
Someone could use this and find other zone hashes if hey want :)
For those who want just the ocean region here you go:
ZoneName == 385094880 //OCEAN


Getting "error sending request for url" AzureError when writing very large deltatable to Azure Gen 2

Environment
Delta-rs version:
This happens on both 0.18.1 and 0.16.1, I haven't tested anything else.
Environment: Python 3.11

OS: Windows 10

Bug
What happened:
When writing an extremely large deltalake file (30000 total partition folders) to Azure Gen 2, I keep getting the following:
OSError: Generic MicrosoftAzure error: Error after 0 retries in 30.0027383s, max_retries:10, retry_timeout:180s, source:error sending request for url (url_here): operation timed out

This error happens regardless of what engine (I tested both Rust and PyArrow) and regardless of Deltalake version (I tried 0.18.1 and 0.16.1), I run the following call after creating an extremely large dataframe via pd.concat:
            write_deltalake(
                table_or_uri=f"url_here",
                data=data, # Extremely large pandas dataframe
                storage_options={options_here},
                mode="overwrite",
                partition_by=partition_scheme,
                engine="rust"
            )

My deltatable contains millions of rows, however this should not be an issue to write to the deltalake so I am not sure why exactly I am getting this error at all. When it comes to writing very small deltalakes (1000s of rows) its fine, what exactly can be the cause and solution to this?
Everything works, including concatenation, it just errors when I try writing the DF.
What you expected to happen:
For  the write to be successful regardless of how long it takes.
How to reproduce it:
Most likely need to get an extremely large deltatable of millions of rows (gb of data) and try performing a write to Azure Gen 2.
It should be important to note the error message I gave is when I tried PyArrow, Rust is similar except it performs 10 retries, I dont know why azure wont even retry. I am using abfss in my url when going to Azure Gen 2

After further investigating, this error propagates actually depending on the partition I chose to partition the table by, why is that? One of the partition schemes I chose was in total 267 partitions, the next scheme I chose had over 30k+, my problem here is why is this the case? Why is my choice of partition_by affecting this? It should be error free regardless of the number of partitions or the time I need to wait.

You can pass in storage_options, {"timeout": "120s"}

Through further looking into the data, I do not believe the data has anything to do with this error @ion-elgreco however possibly the number of partitions might be an issue, with the assumption of 30k+ partitions, can deltalake even handle that? If so, is there a possibility that write_deltalake is trying to write to partitions before even making the partition folder?

@ion-elgreco Would it be an issue if I try making partitions that are of timestamp?

calling write_deltalake() with a URL means that the writer has to first read the transaction log/open the table first. Are you able to construct a DeltaTable()` reliably on this URL? I'm still uncertain on how we might write a test reproduction case here

calling write_deltalake() with a URL means that the writer has to first read the transaction log/open the table first. Are you able to construct a DeltaTable()` reliably on this URL? I'm still uncertain on how we might write a test reproduction case here

Yes, making the delta table is fine.

@rtyler I have come up with a solution in the meantime, it seems like (atleast with the data I have) deltalake simply cant handle writing all the partitions at once, so I simply write in batches, meaning I essentially get a few thousand dataframes (4096 is what I used for testing), pd.concat them all, and write them essentially as a batch, and go on to the next batch and so on and this is fast enough for my purposes.

@rtyler I have come up with a solution in the meantime, it seems like (atleast with the data I have) deltalake simply cant handle writing all the partitions at once, so I simply write in batches, meaning I essentially get a few thousand dataframes (4096 is what I used for testing), pd.concat them all, and write them essentially as a batch, and go on to the next batch and so on and this is fast enough for my purposes. I am not exactly sure if deltalake can handle writing 10k+ partitions at a time, as writing 31k resulted in the error I was originally getting.

We need to take a deeper look at this. Can you provide a sample data frame with similar characteristics


Issues with TVars parsing

I was trying to make a decapode where nothing else was pointing into the TVar variable Ḣ but I ran into an issue where for some reason, both the Ḣ I declared and an auto-generated Ḣ, which is the actual TVar here, were created.
DecaTest10 = quote
  A::Form0{X}
  B::Form0{X}
  C::Form0{X}
  Ḣ::Form5{X}
  H::Form5{X}

  A == b(B)
  A == c(C)
  ∂ₜ(H) == Ḣ
end

Test10 = SummationDecapode(parse_decapode(DecaTest10))

SummationDecapode{Any, Any, Symbol} with elements Var = 1:6, TVar = 1:1, Op1 = 1:3, Op2 = 1:0, Σ = 1:0, Summand = 1:0
┌─────┬───────┬──────┐
│ Var │  type │ name │
├─────┼───────┼──────┤
│   1 │ Form0 │    A │
│   2 │ Form0 │    B │
│   3 │ Form0 │    C │
│   4 │ Form5 │    Ḣ │
│   5 │ Form5 │    H │
│   6 │ infer │    Ḣ │
└─────┴───────┴──────┘
┌──────┬──────┐
│ TVar │ incl │
├──────┼──────┤
│    1 │    6 │
└──────┴──────┘
┌─────┬─────┬─────┬─────┐
│ Op1 │ src │ tgt │ op1 │
├─────┼─────┼─────┼─────┤
│   1 │   2 │   1 │   b │
│   2 │   3 │   1 │   c │
│   3 │   5 │   6 │  ∂ₜ │
└─────┴─────┴─────┴─────┘

So I decided to delete my Ḣ since it wasn't being used, but now it won't compile since I didn't declare Ḣ, even though it's not being used.
DecaTest10 = quote
  A::Form0{X}
  B::Form0{X}
  C::Form0{X}
  H::Form5{X}

  A == b(B)
  A == c(C)
  ∂ₜ(H) == Ḣ
end

Test10 = SummationDecapode(parse_decapode(DecaTest10))

KeyError: key :Ḣ not found
Stacktrace:
 [1] getindex(h::Dict{Symbol, Int64}, key::Symbol)
   @ Base .\dict.jl:498
 [2] reduce_term!(t::Decapodes.Var, d::SummationDecapode{Any, Any, Symbol}, syms::Dict{Symbol, Int64})
   @ Decapodes c:\Users\19542\Documents\GitHub\Decapodes.jl\src\Decapodes2\language.jl:69
 [3] eval_eq!(eq::Eq, d::SummationDecapode{Any, Any, Symbol}, syms::Dict{Symbol, Int64})
   @ Decapodes c:\Users\19542\Documents\GitHub\Decapodes.jl\src\Decapodes2\language.jl:114
 [4] SummationDecapode(e::Decapodes.DecaExpr)
   @ Decapodes c:\Users\19542\Documents\GitHub\Decapodes.jl\src\Decapodes2\language.jl:186
 [5] top-level scope
   @ c:\Users\19542\Documents\GitHub\Decapodes.jl\test\Decapodes2\rewrite.jl:526

I suspect that this occurs because we assumed that "floating" variables without edges pointing into them, like Ḣ, would have exactly one operation leading into them.

The following example helps explain why auto-generating a Var like Ḣ is sometimes necessary. These two Decapodes should encode the same physics:
Exp = quote
  A::Form0{X}
  H::Form0{X}
  Ḣ::Form0{X}

  ∂ₜ(H) == Ḣ
  Ḣ == f(A)
end

Imp = quote
  A::Form0{X}
  H::Form0{X}

  ∂ₜ(H) == f(A)
end

That is, the update variable for H is explicit in Exp and implicit in Imp. When we create a Decapode, there must be an intermediary variable that we can set both sides of this equation equal to.
When we solve this issue, we can either make the parsing code more sophisticated, or make the pre-processing of a Decapode more sophisticated. We prefer this second option whenever possible for a few reasons. We want to be able to use as much declarative-style Catlab machinery as possible, and writing bug-free parsing code is tough.

Closed by #95


Align extended Boolean parsing with Elasticsearch

As it stands, the boolean parsing in ES-Hadoop checks for values true, on, yes, and 1, with all other values being false. Elasticsearch defines it's logic as false, off, no, and 0, with all other values being true.
This means the ES-Hadoop is biased towards parsing booleans as false, whereas Elasticsearch is biased towards parsing booleans as true. For instance, if a field is mapped as a boolean, and a document with the value "blah" is indexed, in Elasticsearch, this would be treated as a true value, whereas in ES-Hadoop's extended boolean parsing, we would treat this as a false value.

Additionally, Elasticsearch will directly treat any numeric field as a potential boolean, with any floating point values coerced to integral types and all non zero integral values being true and all zero integral values being false.