Disabling debug messages?

Is there a way to disable the debug_msgs feature when using the crate?
I tried this
[dependencies.rhai]
version= "0.8.1"
default-features = false
features=[]

but I still get the messages

Aye, I will investigate this either. Who knows? Maybe we found a bug in Cargo!

yeah, or possibly in nightly rustc. Right now, I have the opposite behavior : I have the debug_msgs feature enabled, but no messages, even after cargo clean...

Right - things just got interesting.  If I create a Cargo project with a path reference to the cloned Rhai repo, then happiness - no debug output!  I change that to  "0.8.1" and I get the output that I did not ask for! So the question is, what changes in the repo since last release? (I'm on stable). Perhaps all we need is a 0.8.2 release?

To answer this question - I note 0.8.1 was on 21st Dec. The last merge on 2nd March seems to be crucial here:
diff --git a/Cargo.toml b/Cargo.toml
index 1a7eef7..16bdba5 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -12,3 +12,6 @@ include = [
     "scripts/*.rhai",
     "Cargo.toml"
 ]
+
+[features]
+debug_msgs = []
diff --git a/src/engine.rs b/src/engine.rs
index a00fbc2..4b6438d 100644
--- a/src/engine.rs
+++ b/src/engine.rs
@@ -160,7 +160,7 @@ impl Engine {
         ident: String,
         args: Vec<&mut Any>,
     ) -> Result<Box<Any>, EvalAltResult> {
-        println!(
+        debug_println!(
             "Trying to call function {:?} with args {:?}",
             ident,
             args.iter().map(|x| (&**x).type_id()).collect::<Vec<_>>()
@@ -196,7 +196,7 @@ impl Engine {
     }

     pub fn register_fn_raw(&mut self, ident: String, args: Option<Vec<TypeId>>, f: Box<FnAny>) {
-        println!("Register; {:?} with args {:?}", ident, args,);
+        debug_println!("Register; {:?} with args {:?}", ident, args);

         let spec = FnSpec { ident, args };

diff --git a/src/lib.rs b/src/lib.rs
index f03ff9d..14bc19a 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -34,6 +34,13 @@
 #![allow(warnings, unknown_lints, type_complexity, new_without_default_derive,
          needless_pass_by_value, too_many_arguments)]

+// needs to be here, because order matters for macros
+macro_rules! debug_println {
+    () => (#[cfg(feature = "debug_msgs")] {print!("\n")});
+    ($fmt:expr) => (#[cfg(feature = "debug_msgs")] {print!(concat!($fmt, "\n"))});
+    ($fmt:expr, $($arg:tt)*) => (#[cfg(feature = "debug_msgs")] {print!(concat!($fmt, "\n"), $($arg)*)});
+}
+

Note that on 0.8.1 it was actually just println!. So doing a 0.8.2 should solve our problem.

Ah, my bad, I had no idea I didn't publish a new version, haha. 0.8.2 is up
now.
2018-03-27 10:07 GMT+02:00 Steve J Donovan<EMAIL_ADDRESS>
To answer this question - I note 0.8.1 was on 21st Dec. The last merge on
2nd March seems to be crucial here:
diff --git a/Cargo.toml b/Cargo.toml
index 1a7eef7..16bdba5 100644--- a/Cargo.toml+++ b/Cargo.toml@@ -12,3 +12,6 @@ include = [
"scripts/*.rhai",
"Cargo.toml"
]++[features]+debug_msgs = []diff --git a/src/engine.rs b/src/engine.rs
index a00fbc2..4b6438d 100644--- a/src/engine.rs+++ b/src/engine.rs@@ -160,7 +160,7 @@ impl Engine {
ident: String,
args: Vec<&mut Any>,
) -> Result<Box, EvalAltResult> {-        println!(+        debug_println!(
"Trying to call function {:?} with args {:?}",
ident,
args.iter().map(|x| (&**x).type_id()).collect::<Vec<_>>()@@ -196,7 +196,7 @@ impl Engine {
}
 pub fn register_fn_raw(&mut self, ident: String, args: Option<Vec<TypeId>>, f: Box<FnAny>) {-        println!("Register; {:?} with args {:?}", ident, args,);+        debug_println!("Register; {:?} with args {:?}", ident, args);

     let spec = FnSpec { ident, args };

diff --git a/src/lib.rs b/src/lib.rs
index f03ff9d..14bc19a 100644--- a/src/lib.rs+++ b/src/lib.rs@@ -34,6 +34,13 @@
#![allow(warnings, unknown_lints, type_complexity, new_without_default_derive,
needless_pass_by_value, too_many_arguments)]
+// needs to be here, because order matters for macros+macro_rules! debug_println {+    () => (#[cfg(feature = "debug_msgs")] {print!("\n")});+    ($fmt:expr) => (#[cfg(feature = "debug_msgs")] {print!(concat!($fmt, "\n"))});+    ($fmt:expr, $($arg:tt)) => (#[cfg(feature = "debug_msgs")] {print!(concat!($fmt, "\n"), $($arg))});+}+
Note that on 0.8.1 it was actually just println!. So doing a 0.8.2 should
solve our problem.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rhai/issues/65#issuecomment-376434620,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIAzhxWwsksm1-jrbvgPbSkf9xqvTO2rks5tifM1gaJpZM4S5J7q
.

Confirmed! Works perfectly now. Thanks!

Glad I could help!
2018-03-28 11:22 GMT+02:00 jice-nospam<EMAIL_ADDRESS>
Confirmed! Works perfectly now. Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rhai/issues/65#issuecomment-376820131,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIAzh-1U5F2F6wD9-APruzeGpvqjQsfRks5ti1ZQgaJpZM4S5J7q
.


Create issue templates

Created a bug report issue template and a feature request issue template.

This is for Issue #41.

Now there is merge conflicts to resolve.
Probably as a result of adding those file manually.
See the comment in in this Issue:
https://github.com/JamieBort/Personal-Dashboard/issues/41#issuecomment-1984861544

I already have the files that I need in the fullstack branch.
There's no need complicating matters. I am going to close this pull request and delete the JamieBort-issue-template-1 branch.


feat: add PhaseReplicaLagThresholdExceeded

This commit introduces a new phase called PhaseReplicaLagThresholdExceeded. This phase is triggered when one or more replica databases lag beyond a user-defined limit compared to the primary database.
A new ReplicaLagThreshold field has been added to the Cluster spec, allowing users to define their acceptable replica lag limit. If left unspecified, the operator defaults to a 30MB lag threshold.
Partially Closes #2323

/test limit=local

/test limit=local

/test limit=local

/test limit=local

/test limit=local

/test limit=local

/test limit=local

I've had a meeting with @leonardoce and @armru about this patch. We decided that having a phase that does not change the operator's behavior is pointless. We decided to close this patch without merging, then @armru will open a new PR that will be more complete.


Fixing EnsembleModel Test Cases and Extending Usage of EnsembleModel to any Model type.

Pull Request Description
What issue does this change request address?
Closes #201
What are the significant changes in functionality due to this change request?
This alters a few test cases to not exploit a loophole in our input checking, and closes the aforementioned loophole.

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[x] 1. Review all computer code.
[x] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
[x] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
[x] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
[x] 5. If significant functionality is added, there must  be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in  XML block, the node <internalParallel> to True.
[x] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.
[x] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.
[x] 8. If an analytic test is changed/added is the the analytic documentation updated/added?

@maljovec failure in qsub

Oops! My mistake, I forgot to update the cluster tests.

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[x] 1. Review all computer code. DONE
[x] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).  n/a
[x] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.  ok
[x] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.  ok
[x] 5. If significant functionality is added, there must  be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in  XML block, the node <internalParallel> to True.  ok
[x] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.  n/a
[x] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.  #201
[x] 8. If an analytic test is changed/added is the the analytic documentation updated/added?  n/a

Job Mingw Test:win-mingw on 8937d0d : invalidated by @alfoa


Random deadlock in current master

tests/test_rpool.py::test_deadlock_kill Timeout (0:00:05)!
Thread 0x00007fff7b73f000 (most recent call first):
  File "/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/connection.py", line 383 in _recv
  File "/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/connection.py", line 416 in _recv_bytes
  File "/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/connection.py", line 216 in recv_bytes
  File "/Users/ogrisel/code/Rpool/backend/reusable_pool.py", line 312 in _empty_queue
  File "/Users/ogrisel/code/Rpool/backend/reusable_pool.py", line 299 in _help_stuff_finish
  File "/Users/ogrisel/code/Rpool/backend/reusable_pool.py", line 249 in _terminate_pool
  File "/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 185 in __call__
  File "/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/pool.py", line 496 in terminate
  File "/Users/ogrisel/code/Rpool/backend/reusable_pool.py", line 118 in terminate
  File "/Users/ogrisel/code/Rpool/tests/test_rpool.py", line 265 in test_deadlock_kill

No other thread is running.


feat(sdk): Error improvements

The error response structure defined in the OpenID4CI spec is now parsed, and the error codes defined in the spec are now passed through to the caller (with newly-defined Wallet-SDK error codes).
Fixed some places where error codes were wrapping lower-level error codes. This wrapping would cause the error parsing package to only "see" the higher-level error, which isn't as helpful for the user.
Removed some error codes that were reporting issues related to incorrect usage of Wallet-SDK. These error codes don't really serve any purpose, as these situations should only really exist during development and the end-user of an application using Wallet-SDK won't encounter them.
Added a Raw field to the parsed gomobile error type. The ToMobileError function parses the first Go API Wallet Error type it finds in the error chain into the Code, Category, and Details fields. If there were any higher-level errors above that, they get lost. Now, if these higher-level error details will be captured in the Raw field.
Improved some error code names.
Updated documentation.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.15 :tada:

Comparison is base (bb013ae) 89.14% compared to head (e10ac0c) 89.29%.

:exclamation: Current head e10ac0c differs from pull request most recent head 2d34367. Consider uploading reports for the commit 2d34367 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #491      +/-   ##
==========================================
+ Coverage   89.14%   89.29%   +0.15%
==========================================
  Files          93       93
  Lines        3509     3560      +51
==========================================
+ Hits         3128     3179      +51
  Misses        245      245
  Partials      136      136

Impacted Files
Coverage Δ

pkg/openid4ci/models.go
100.00% <ø> (ø)

cmd/wallet-sdk-gomobile/wrapper/error.go
85.18% <100.00%> (+0.56%)
:arrow_up:

pkg/internal/httprequest/httprequest.go
89.18% <100.00%> (+1.31%)
:arrow_up:

pkg/internal/issuermetadata/issuermetadata.go
88.23% <100.00%> (ø)

pkg/openid4ci/clientconfig.go
100.00% <100.00%> (ø)

pkg/openid4ci/interaction.go
87.09% <100.00%> (+1.64%)
:arrow_up:

pkg/openid4ci/issuerinitiatedinteraction.go
92.49% <100.00%> (+0.52%)
:arrow_up:

pkg/openid4vp/openid4vp.go
88.65% <100.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

about this part: "Removed some error codes that were reporting issues related to incorrect usage of Wallet-SDK. These error codes don't really serve any purpose, as these situations should only really exist during development and the end-user of an application using Wallet-SDK won't encounter them."
Developers that use our SDK will be confused in this case. I think it is better to add an additional walletError type. We have runtime and validation errors, we can add something logic error type, that will indicate improper use of SDK. This error type can have the same error code, and error category for all of them. In this case, users of our SDK can uniformly process all errors.

Note that I still return errors when the SDK is used incorrectly - the only difference now is that I'm not defining an explicit error code. There's several reasons why I believe it's better to not return an explicit error code in these cases:

Regardless of how they handle the errors from Wallet-SDK (whether they actually parse them, or they simply print out the JSON error structure), the underlying error message will be passed through, as the existing gomobile error handling/parsing code ensures that even errors that aren't using the walleterror.Error type will be passed through, just with a generic error code instead.
From what I can see, there are two main benefits to having explicit error codes are: the first is to allow the caller to detect certain errors programatically and allow them to handle them in a special way (e.g. by doing retries in some cases). The second is to allow an application an easy way to provide a short, concise error to an end-user that they can then submit in a bug report or to something like customer support, without the huge underlying error that could be confusing. In cases where the error is due to improper usage of Wallet-SDK (e.g. missing arguments, calling the wrong method, etc), neither of these cases are applicable. There's no action a caller can take can take to programatically respond to it (they just have to fix the code, perhaps by reading the docs), and the end-user should never see these error codes.
We have many, many, many places where we return errors due to improper arguments (e.g. nil args). It would be very difficult to add an error code for each one of these scenarios, and would bloat the code considerably.
For some of the improper usage scenarios, the error codes may cause the caller to "fix" them in an incorrect way. For example - one of the error codes I removed was the "PIN_REQUIRED" one. This error happens only if the caller doesn't check to see if a PIN is required first, which they should do using the pinRequired method from the SDK itself. If I return an explicit error code, that may lead to the caller using that as their mechanism to determining whether the PIN is required, which isn't the proper way to do it. So it's better to not make it easy for them to do the wrong way.

about this part: "Removed some error codes that were reporting issues related to incorrect usage of Wallet-SDK. These error codes don't really serve any purpose, as these situations should only really exist during development and the end-user of an application using Wallet-SDK won't encounter them."
Developers that use our SDK will be confused in this case. I think it is better to add an additional walletError type. We have runtime and validation errors, we can add something logic error type, that will indicate improper use of SDK. This error type can have the same error code, and error category for all of them. In this case, users of our SDK can uniformly process all errors.

Note that I still return errors when the SDK is used incorrectly - the only difference now is that I'm not defining an explicit error code. There's several reasons why I believe it's better to not return an explicit error code in these cases:

Regardless of how they handle the errors from Wallet-SDK (whether they actually parse them, or they simply print out the JSON error structure), the underlying error message will be passed through, as the existing gomobile error handling/parsing code ensures that even errors that aren't using the walleterror.Error type will be passed through, just with a generic error code instead.
From what I can see, there are two main benefits to having explicit error codes are: the first is to allow the caller to detect certain errors programatically and allow them to handle them in a special way (e.g. by doing retries in some cases). The second is to allow an application an easy way to provide a short, concise error to an end-user that they can then submit in a bug report or to something like customer support, without the huge underlying error that could be confusing. In cases where the error is due to improper usage of Wallet-SDK (e.g. missing arguments, calling the wrong method, etc), neither of these cases are applicable. There's no action a caller can take can take to programatically respond to it (they just have to fix the code, perhaps by reading the docs), and the end-user should never see these error codes.
We have many, many, many places where we return errors due to improper arguments (e.g. nil args). It would be very difficult to add an error code for each one of these scenarios, and would bloat the code considerably.
For some of the improper usage scenarios, the error codes may cause the caller to "fix" them in an incorrect way. For example - one of the error codes I removed was the "PIN_REQUIRED" one. This error happens only if the caller doesn't check to see if a PIN is required first, which they should do using the pinRequired method from the SDK itself. If I return an explicit error code, that may lead to the caller using that as their mechanism to determining whether the PIN is required, which isn't the proper way to do it. So it's better to not make it easy for them to do the wrong way.

about 3. We can just have one error for all improper usage. So it will be something like this NewImproperUsage(err error). In the end, it will translate into { "module": "general", "code": "0",  "category": "IMPROPER_USAGE", details: "..."  }. Because currently, we get UKN2-000 code and UNEXPECTED_ERROR category. It is not very clear
I will approve you PR. If you like this idea you can implement it.

I've marked it WIP to prevent merging for now


Did not download Enigma, and/or didn't start it.

I ran the yarn as per instructions, the command prompt specified 5 actionable tasks: 5 executed, but Enigma is nowhere to be seen.  Do I need to install Enigma before hand?  From your Readme, it indicated that it would be downloaded.  Upon running the yarn again I got 4 executed 1 up-to-date.  It did download and create the merged jar.  Any sort of nudge / hand holding in the right direction would be most appreciated.  Thank you.

Is the final yarn task up to date?

Unfortunately, my wife needed to take the laptop to work, so I cannot
confirm anything at the moment.  If I recall correctly, when I ran it, the
program started downloading the mc jars, once it completed that it merged
them, then gave me a warning that it was using depreciated functions and
couldn't run gradle 5.0, and then said it was done.  There was a single
line that said 5 executables, and 4 were finish and 1 was up to date.  Do
you know where it downloads enigma?  I checked in most of the files in my
yarn install, but didn't see anything that looked like it would be enigma.
On Mon, May 6, 2019, 4:16 AM liach<EMAIL_ADDRESS>wrote:

Is the final yarn task up to date?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/FabricMC/yarn/issues/675#issuecomment-489557625, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AL75HUBFSSYGIAIBDYDIZ3LPT7ZOHANCNFSM4HK6L22A
.


AFE frequent crashes when trying to open the lambda editor

I am not sure if something has changed recently, but recently it is a lottery if my lambda editor make it through the initial load. It ends up crashing the whole excel and all open excel window close.

is it a known issue?
is there any workaround to it? I don't care making it slower or downgrading it, just want to continue doing my job.

It seems that clearing the Office cache has helped: Excel Options -> Save -> Cache Settings -> Delete cached files
No issue for now.


Improve parsing documentation

Why even have the impl<F, T> Parser for F where F: FnOnce(ParseStream) -> Result<T> if you don't want people to use it? From the example I added in #557 you can see that it's far more convenient to write small parsers that way (compared to manually implementing Parse).

Also, why did you not include “The easiest way to create a ParseStream is to use the Parser trait”? It took me forever to figure that part out.

Regarding how to create a ParseStream -- I disagreed with your wording and wrote a more complete explanation in 028a7d74f2fd859dfa654a213527b3d8b1947e14.
Regarding using the Parser impl -- you are correct that I don't want people to use it. Regarding why even have it -- it is a low-level escape hatch that is necessary on rare occasions. I try never to base design primarily on "far more convenient to write." I believe data structures with a Parse impl are easier to think about, read, and document.


Auto reconnect functionality

Firstly, Thank You for the ha-menu, amazing project! I was wondering if it would be possible to implement some kind of auto reconnect functionality where the software tries to reconnect for x amount of time after losing connection to the HA? I hit the following scenario where it would be very useful to have it;
I set ha-menu to start with MacOS and it starts just fine, however, next in the queue is AdGuard which is taking a significant time to load. Due to the specifics of this software, it's causing the network connection to reset and in the result of that ha-menu gets disconnected and I have to reconnect it manually.

The app will retry on the next refresh interval which can be changed in the settings. I could make the app retry more frequently if it fails to connect, if you would be interested in that.


Shelly 1pm

Hello, I would like to know if it is possible to have Shelly 1pm integrated with your product because it also uses the consumption measurement of the devices connected to it. Thank you in advance for your work.

Please do a http://<IP_ADDRESS>/status? (replace the IP to your shelly 1PM) and post it here.

{"wifi_sta":{"connected":true,"ssid":"AirPort","ip":"<IP_ADDRESS>","rssi":-49},"cloud":{"enabled":true,"connected":true},"mqtt":{"connected":false},"time":"18:44","unixtime":1636998293,"serial":2257,"has_update":false,"mac":"84CCA8B13795","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"input"}],"meters":[{"power":455.85,"overpower":0.00,"is_valid":true,"timestamp":1637001893,"counters":[454.622, 452.746, 451.826],"total":145827}],"inputs":[{"input":0,"event":"","event_cnt":0}],"temperature":38.73,"overtemperature":false,"tmp":{"tC":38.73,"tF":101.71, "is_valid":true},"temperature_status":"Normal","ext_sensors":{},"ext_temperature":{},"ext_humidity":{},"update":{"status":"idle","has_update":false,"new_version":"20211109-130756/v1.11.7-g682a0db","old_version":"20211109-130756/v1.11.7-g682a0db"},"ram_total":50472,"ram_free":37412,"fs_size":233681,"fs_free":149345,"uptime":98544}
Thanks

It’s possible for you? Thanks


Accidentally deleted xbindkeys from Startup Applications in Gnome. Is it okay?

Is that okay? I meant to delete the app I added, but not xbindkeys. Just want to double check if crouton replies on that, or if it is okay. I've no idea how to add it back (I don't know if it was running with any number of command line args).

@trusktr,
I think a 'crouton' update should take care of it.
It's installed via the x11-common script and some custom configs are done in xbindsrc.scm.
I have both gnome & kde desktop targets in my 'zesty' chroot so I'm not sure which one created this file but here are the contents of my /etc/xdg/autostart/xbindkeys.desktop file, if it helps:
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=xbindkeys
Comment=Start xbindkeys
Exec=xbindkeys_autostart
Terminal=false
Type=Application
Categories=
GenericName=

Hope this helps,
-DennisL


[BACKLOG-9795] - Add Metadata Injection (MDI) support to the Dimension lookup/update Step - add TYPE_OF_RETURN_FIELD property

@bmorrise , @mdamour1976  please review.

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookup.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMeta.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/messages/messages_en_US.properties
  engine/test-src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMetaInjectionTest.java
  ui/src/org/pentaho/di/ui/trans/steps/dimensionlookup/DimensionLookupDialog.java

Still Broken Tests:
org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest:
:red_circle: java.lang.ClassNotFoundException
java.lang.ClassNotFoundException: org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change:  + .39%
Complexity Change:  + .51%
Instruction Change:  + .08%

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change:  + 1.01%
Complexity Change:  + 1.06%
Instruction Change:  + .17%

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.28%:small_red_triangle_down:
Line Change: -3.87%:small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Instruction Change: -.19%:small_red_triangle_down:
Line Change: -.27%:small_red_triangle_down:

org.pentaho.di.trans.steps.combinationlookup.CombinationLookupMeta

Instruction Change: -.04%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Instruction Change: -.09%:small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change:  + .81%
Complexity Change:  + .21%
Instruction Change:  + .68%
Line Change:  + .39%
Method Change: -1.53%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta.ReturnTypeCodeConverter

Complexity New Coverage: 50.00%
Instruction New Coverage: 42.86%
Line New Coverage: 50.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 1.04%
Complexity Change:  + 1.05%

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta

Instruction Change: -.06%:small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change:  + 2.35%
Complexity Change:  + 2.70%
Instruction Change:  + .18%
Line Change:  + .48%

org.pentaho.di.trans.steps.processfiles.ProcessFilesMeta

Branch Change: -3.57%:small_red_triangle_down:
Complexity Change: -2.13%:small_red_triangle_down:
Instruction Change: -.33%:small_red_triangle_down:

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -.18%:small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -.18%:small_red_triangle_down:

org.pentaho.di.trans.steps.webservices.WebServiceMeta

Branch Change:  + 1.79%
Complexity Change:  + 1.19%
Instruction Change:  + .07%

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookup.java. Found 2016. Was expecting 2017

:heavy_exclamation_mark: Copyright year is not the current year on engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMeta.java. Found 2016. Was expecting 2017

:heavy_exclamation_mark: Copyright year is not the current year on engine/test-src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMetaInjectionTest.java. Found 2016. Was expecting 2017

:heavy_exclamation_mark: Copyright year is not the current year on ui/src/org/pentaho/di/ui/trans/steps/dimensionlookup/DimensionLookupDialog.java. Found 2016. Was expecting 2017

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookup.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMeta.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/messages/messages_en_US.properties
  engine/test-src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMetaInjectionTest.java
  ui/src/org/pentaho/di/ui/trans/steps/dimensionlookup/DimensionLookupDialog.java

Newly Broken Tests:
org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMetaTest.testSerialization:
:red_circle: java.lang.RuntimeException
java.lang.RuntimeException: Error validating fieldUpdate
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.validateLoadedMeta(LoadSaveTester.java:176)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testXmlRoundTrip(LoadSaveTester.java:223)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testSerialization(LoadSaveTester.java:182)
	at org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMetaTest.testSerialization(DimensionLookupMetaTest.java:145)
Caused by: org.pentaho.di.

org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaLoadSaveTest.testSerialization:
:red_circle: java.lang.RuntimeException
java.lang.RuntimeException: Error validating dateFormatLocale
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.validateLoadedMeta(LoadSaveTester.java:176)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testXmlRoundTrip(LoadSaveTester.java:223)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testSerialization(LoadSaveTester.java:182)
	at org.pentaho.di.trans.steps.textfileinput.TextFileInputMetaLoadSaveTest.testSerialization(TextFileInputMetaLoadSaveTest.java:167)
Caused by:

Still Broken Tests:
org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest:
:red_circle: java.lang.ClassNotFoundException
java.lang.ClassNotFoundException: org.pentaho.di.ui.trans.steps.tableoutput.TableOutputDialogTest
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change: -7.14%:small_red_triangle_down:
Complexity Change: -7.69%:small_red_triangle_down:

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change:  + .39%
Complexity Change:  + .51%
Instruction Change:  + .08%

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change: -1.01%:small_red_triangle_down:
Complexity Change: -1.06%:small_red_triangle_down:
Instruction Change: -.17%:small_red_triangle_down:

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change:  + 3.28%
Line Change:  + 3.87%

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change:  + .11%

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Instruction Change:  + .09%

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change:  + .11%

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change: -4.24%:small_red_triangle_down:
Complexity Change: -4.08%:small_red_triangle_down:
Instruction Change: -11.47%:small_red_triangle_down:
Line Change: -9.16%:small_red_triangle_down:
Method Change: -5.61%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta.ReturnTypeCodeConverter

Complexity New Coverage: 50.00%
Instruction New Coverage: 42.86%
Line New Coverage: 50.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -3.12%:small_red_triangle_down:
Complexity Change: -3.16%:small_red_triangle_down:
Instruction Change: -.14%:small_red_triangle_down:
Line Change: -.37%:small_red_triangle_down:

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change:  + 2.00%
Complexity Change:  + 1.89%
Instruction Change:  + .17%

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change:  + 4.71%
Complexity Change:  + 5.41%
Instruction Change:  + .35%
Line Change:  + .97%

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change: -.14%:small_red_triangle_down:

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change:  + .08%

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -.18%:small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileFilter

Complexity Change: -9.09%:small_red_triangle_down:
Instruction Change: -9.26%:small_red_triangle_down:
Line Change: -8.33%:small_red_triangle_down:
Method Change: -9.09%:small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -12.11%:small_red_triangle_down:
Complexity Change: -5.18%:small_red_triangle_down:
Instruction Change: -30.23%:small_red_triangle_down:
Line Change: -22.72%:small_red_triangle_down:
Method Change: -3.21%:small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change:  + .18%

org.pentaho.di.trans.steps.webservices.WebServiceMeta

Branch Change:  + 1.79%
Complexity Change:  + 1.19%
Instruction Change:  + .07%

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Branch Change: -.29%:small_red_triangle_down:
Complexity Change: -.18%:small_red_triangle_down:
Instruction Change: -.05%:small_red_triangle_down:
Line Change: -.08%:small_red_triangle_down:

@AndreyBurikhin Looks like there are a couple of newly broken tests.

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookup.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMeta.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/messages/messages_en_US.properties
  engine/test-src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMetaInjectionTest.java
  ui/src/org/pentaho/di/ui/trans/steps/dimensionlookup/DimensionLookupDialog.java

Newly Broken Tests:
org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMetaTest.testSerialization:
:red_circle: java.lang.RuntimeException
java.lang.RuntimeException: Error validating fieldUpdate
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.validateLoadedMeta(LoadSaveTester.java:176)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testXmlRoundTrip(LoadSaveTester.java:223)
	at org.pentaho.di.trans.steps.loadsave.LoadSaveTester.testSerialization(LoadSaveTester.java:182)
	at org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMetaTest.testSerialization(DimensionLookupMetaTest.java:145)
Caused by: org.pentaho.di.

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change:  + .39%
Complexity Change:  + .51%
Instruction Change:  + .08%

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change:  + 1.01%
Complexity Change:  + 1.06%
Instruction Change:  + .17%

org.pentaho.di.job.entries.getpop.MailConnectionMeta

Branch Change:  + 1.00%
Complexity Change:  + 1.41%
Instruction Change:  + .30%

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.28%:small_red_triangle_down:
Line Change: -3.87%:small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Instruction Change: -.19%:small_red_triangle_down:
Line Change: -.27%:small_red_triangle_down:

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.combinationlookup.CombinationLookupMeta

Instruction Change: -.04%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Instruction Change:  + .09%

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change: -3.92%:small_red_triangle_down:
Complexity Change: -3.69%:small_red_triangle_down:
Instruction Change: -11.43%:small_red_triangle_down:
Line Change: -9.16%:small_red_triangle_down:
Method Change: -5.61%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta.ReturnTypeCodeConverter

Complexity New Coverage: 50.00%
Instruction New Coverage: 42.86%
Line New Coverage: 50.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.excelwriter.ExcelWriterStepMeta

Branch Change:  + 1.28%
Complexity Change:  + .78%
Instruction Change:  + .04%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 2.08%
Complexity Change:  + 2.11%
Instruction Change:  + .28%
Line Change:  + .74%

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change:  + 2.00%
Complexity Change:  + 1.89%
Instruction Change:  + .17%

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta

Instruction Change: -.06%:small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -2.35%:small_red_triangle_down:
Complexity Change: -2.70%:small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change:  + .07%

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change:  + .18%

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta

Branch Change: -.91%:small_red_triangle_down:
Complexity Change: -.82%:small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change:  + .18%

org.pentaho.di.trans.steps.webservices.WebServiceMeta

Branch Change:  + 1.79%
Complexity Change:  + 1.19%
Instruction Change:  + .07%

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookup.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMeta.java
  engine/src/org/pentaho/di/trans/steps/dimensionlookup/messages/messages_en_US.properties
  engine/test-src/org/pentaho/di/trans/steps/dimensionlookup/DimensionLookupMetaInjectionTest.java
  ui/src/org/pentaho/di/ui/trans/steps/dimensionlookup/DimensionLookupDialog.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change: -1.01%:small_red_triangle_down:
Complexity Change: -1.06%:small_red_triangle_down:
Instruction Change: -.17%:small_red_triangle_down:

org.pentaho.di.job.entries.ftpsget.JobEntryFTPSGet

Branch Change: -.53%:small_red_triangle_down:
Complexity Change: -.56%:small_red_triangle_down:
Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.job.entries.getpop.MailConnectionMeta

Branch Change:  + 1.00%
Complexity Change:  + 1.41%
Instruction Change:  + .30%

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change:  + 3.28%
Line Change:  + 3.87%

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Branch Change:  + 1.35%
Complexity Change:  + 1.45%
Instruction Change:  + .11%

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -.10%:small_red_triangle_down:

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Instruction Change: -.09%:small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change:  + .11%

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change:  + .04%
Complexity Change: -.33%:small_red_triangle_down:
Instruction Change:  + .19%
Line Change:  + .22%
Method Change: -1.53%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta.ReturnTypeCodeConverter

Complexity New Coverage: 50.00%
Instruction New Coverage: 42.86%
Line New Coverage: 50.00%
Method New Coverage: 50.00%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 3.12%
Complexity Change:  + 3.16%
Instruction Change:  + .14%
Line Change:  + .37%

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -1.18%:small_red_triangle_down:
Complexity Change: -1.35%:small_red_triangle_down:

org.pentaho.di.trans.steps.processfiles.ProcessFilesMeta

Branch Change:  + 3.57%
Complexity Change:  + 2.13%
Instruction Change:  + .33%

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Instruction Change:  + .08%

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change:  + .14%

org.pentaho.di.trans.steps.synchronizeaftermerge.SynchronizeAfterMergeMeta

Instruction Change: -.04%:small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change:  + .53%

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change:  + .18%

org.pentaho.di.trans.Trans

Branch Change: -.10%:small_red_triangle_down:
Complexity Change: -.14%:small_red_triangle_down:
Instruction Change: -.09%:small_red_triangle_down:
Line Change: -.11%:small_red_triangle_down:

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Complexity Change:  + .18%
Instruction Change:  + .20%
Line Change:  + .38%
Method Change:  + .49%

@bmorrise PR was updated


[BUG] [katana] tx status is ACCEPTED_ON_L2 even though tx failed

Describe the bug
A clear and concise description of what the bug is.
When running some tx that should fail in kakarot, I realized that even though the logs says that the tx failed, the status in the receipt is still ACCEPTED_ON_L2
To Reproduce
Run any tx that fails, then get_transaction_receipt. See example logs
[2023-09-05T14:05:05Z INFO  katana_core::backend::executor] Transaction received | Hash: 0x78068d5d10c8faf17112190841efd71d7db5ca8cf107b32741f57776afe591e
[2023-09-05T14:05:05Z WARN  katana_core::backend::executor] Transaction execution error: "Error in the called contract (0x06f1d4fcc236ad2b25b4526e55b015e8e01c9e42dfd90a2e466d101037491197):
    Error at pc=0:7:
    Got an exception while executing a hint.
    Cairo traceback (most recent call last):
    Unknown location (pc=0:163)
    Unknown location (pc=0:149)

    Error in the called contract (0x06f1d4fcc236ad2b25b4526e55b015e8e01c9e42dfd90a2e466d101037491197):
    Error at pc=0:31:
    Got an exception while executing a hint.
    Cairo traceback (most recent call last):
    Unknown location (pc=0:4606)
    Unknown location (pc=0:4545)
    Unknown location (pc=0:4374)
    Unknown location (pc=0:376)

    Error in the called contract (0x05c945fcd6e7ab0572fd699dab15c931ee4b154f141283767924eef26a523595):
    Error at pc=0:4551:
    Error message: Kakarot: Reverted with reason: 0

    Cairo traceback (most recent call last):
    Unknown location (pc=0:19117)
    Unknown location (pc=0:19072)
    Unknown location (pc=0:18617)
    Unknown location (pc=0:18317)
    "
[2023-09-05T14:05:05Z TRACE katana_core::backend::executor] Transaction resource usage: Steps: 725929 | Bitwise: 6299 | L1 Gas: 2448 | Pedersen: 205 | Range Checks: 27058
[2023-09-05T14:05:05Z TRACE katana_core::backend::executor] Event emitted keys=[0x99cd8bde557814842a3121e8ddfd433a539b8c9f14bf31ebf108d12e6196e9]
[2023-09-05T14:05:05Z INFO  katana_core::backend] ⛏ Block 33 mined with 1 transactions

and
$ starkli transaction-receipt 0x78068d5d10c8faf17112190841efd71d7db5ca8cf107b32741f57776afe591e --rpc http://<IP_ADDRESS>:5050
{
  "type": "INVOKE",
  "transaction_hash": "0x78068d5d10c8faf17112190841efd71d7db5ca8cf107b32741f57776afe591e",
  "actual_fee": "0x102c58092c1a800",
  "status": "ACCEPTED_ON_L2",
  "block_hash": "0x3370275bf0715ec88b91768c24eb6f54ca55648b81905d9b443e8ae3b71d918",
  "block_number": 33,
  "messages_sent": [],
  "events": [
    {
      "from_address": "0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7",
      "keys": [
        "0x99cd8bde557814842a3121e8ddfd433a539b8c9f14bf31ebf108d12e6196e9"
      ],
      "data": [
        "0x6f1d4fcc236ad2b25b4526e55b015e8e01c9e42dfd90a2e466d101037491197",
        "0x69420",
        "0x102c58092c1a800",
        "0x0"
      ]
    }
  ]
}

Expected behavior
Status should be ~REJECTED~ REVERTED post 0.12.1 update

the issue here is that the status in the receipt should be REVERTED instead of ACCEPTED_ON_L2.
this line should be modified to reflect the actual status https://github.com/dojoengine/dojo/blob/d2fce1a0d0694b164d0923b6626fc81701cb9190/crates/katana/core/src/backend/storage/transaction.rs#L216

@ClementWalter merged 0.4.0 rpc spec in #816. can you confirm if this is still an issue

Closing this as complete


What is the correct (typical) value for elasticsearch.hosts in kibana.config in kubernetes?

Query
What is the correct (or at least, typical) value for the kibana.config.elasticsearch.hosts in the helm charts for ODFE?
In the OpenDistro Helm README.md, the Example Secure Kibana Config With Custom Certs defines:
   elasticsearch.hosts: https://elasticsearch.example.com:443

This would imply a DNS hostname external to the kubernetes cluster.  However, the generated name when using the defaults, and not using custom certs, results in:
        # If no custom configuration provided, default to internal DNS
        - name: ELASTICSEARCH_HOSTS
          value: https://opendistro-es-client-service:9200

which comes from kibana-deployment.yaml: value: https://{{ template "opendistro-es.fullname" . }}-client-service:9200
Shouldn't a typical Kibana config.yml also use the internal DNS, and therefore still be opendistro-es-client-service:9200, or https://opendistro-es-client-service.default.svc.cluster.local:9200, assuming for example, default namespace?  Why would you not use the internal DNS?  Why is an external dns the example provided?
Additionally:  values.yaml shows the following:
    ## Replace with Elasticsearch DNS name picked during Service deployment
    # elasticsearch.hosts: ${ELASTIC_URL}
    # elasticsearch.requestTimeout: 360000

    ...

    # opendistro_security.cookie.secure: true
    # opendistro_security.cookie.password: ${COOKIE_PASS}

In the case of,  ${ELASTIC_URL}, I found no reference to  ELASTIC_URL in the helm charts, other than here. I assume you are just using it as a placeholder, since the README.md example provides an explicit url (see above).  However, just a few lines down, there is the ${COOKIE_PASS}, which actually comes from the secret (I think).  So I assume we literally want "${COOKIE_PASS}" here, as the actual password is in the secret.  Either I am missing something, or you are using the same notation to mean very different things, which is really confusing.
Expected Behavior
Explanation in the README.md of why the configuration is using external DNS names, or switch the example to mirror what the default installation does, in this respect.
Current Behavior
An example that makes a multi-step process less clear.
Failure Information (for bugs)
na
Relevant information
na

Having the same problem. Can we not remove the if condition around setting the ELASTICSEARCH_HOSTS env var and always set it? Then we could use it in our custom config or totally ignore it


"Unexpected end of file!" when opening a newer binary place

I'm currently writing something in C# with this library, however trying to open a binary place file made using the most recent Roblox as of writing (0.474.5.420553) just gives me "Unexpected end of file!"
I'm opening the place file with the FileName string of OpenFileDialog.
Attached is a classic baseplate game with no modifications.
Baseplate.zip

The circumstances of this bug are peculiar and could have only appeared recently.
In short it occurred because I implemented property type 29 as the ProtectedString type, but apparently this type was not canonically present in production builds. It only appeared in the Client CoreScripts model they have uploaded to the LuaAppsBot account.
As a result, the new OptionalCFrame property type is using this ID and the ProtectedString reading/writing logic is incorrectly reading the buffer for this property. In any other circumstance the unknown property would have been ignored, and I’ll be more careful not to implement property types if I can’t verify they’re actually used in a production context.

Alright hey sorry it took me so long to take care of this. The issue should be resolved.
Turns out Roblox actually corrupted this property called WorldPivotInternal which no longer exists.
I've caught everything up with the latest spec changes and features. Let me know if the latest patch fixes everything!

Will be closing this in a few days if I don't hear back.


chore: release 2.0.0

:robot: I have created a release *beep* *boop*
2.0.0 (2019-06-24)
⚠ BREAKING CHANGES

upgrade engines field to >=8.10.0 (#463)

Bug Fixes

deps: update dependency @google-cloud/common-grpc to v1 (#478) (40197e4)
deps: update dependency @google-cloud/paginator to ^0.2.0 (a25627c), closes #8203
deps: update dependency @google-cloud/paginator to v1 (#468) (ae06ec2)
deps: update dependency @google-cloud/projectify to v1 (#466) (6c6dd40)
deps: update dependency @google-cloud/promisify to ^0.4.0 (#420) (d5c2862)
deps: update dependency @google-cloud/promisify to v1 (#467) (5473fb9)
deps: update dependency arrify to v2 (e29f9aa)
deps: update dependency dot-prop to v5 (#455) (3949356)
deps: update dependency escape-string-regexp to v2 (#457) (d923b58)
deps: update dependency google-auth-library to v4 (#475) (a58547c)
deps: update dependency google-gax to ^0.26.0 (#461) (4462869)
deps: update dependency google-gax to v1 (#476) (adfeb9c)
deps: update dependency yargs to v13 (#417) (fac8d4e)
"requires_billing " should be "requires_billing" (#498) (c9f6f7e)
DEADLINE_EXCEEDED is no longer retried (c1190d3)
DEADLINE_EXCEEDED retry code is idempotent (#477) (2783944)
throw on invalid credentials (#418) (5b836fd)
docs: move to new client docs URL (#499) (acfe7c2)

Build System

upgrade engines field to >=8.10.0 (#463) (35cb71f)

Features

support apiEndpoint override (#500) (89124f6)
update the admin APIs (#485) (c76fba9)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-bigtable/releases/tag/v2.0.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


docs: remove old note indicating the Nightwatch version

Since the project is using version 1.1, I think the note can be removed.

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[x] Docs
[ ] Underlying tools
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Other information:

Closed in favour of #4537.


enhance UI - Make it responsive to various browser dimensions

Article about adding a readme component - need to test this out for the chatbot
https://medium.com/@smfurquan0712/how-to-create-live-markdown-editor-in-react-18-6dbf694cf2f5


Remove web_sys re-export

Description
Removes re-exporting the web_sys dependency from the yew crate and
removes some web_sys features that were only enabled for re-exporting.

Fixes #0000
Checklist

[x] I have run cargo make pr-flow
[ ] I have reviewed my own code
I have added tests N/A

I only wanted to remove the web_sys crate re-export, not the individual event types. If you think we should remove those too that's fine by me, I just want to make sure we don't misunderstand each other here.

I feel like we should re-export the types that are exposed in the public API. For example, event types that are used in Callbacks can be re-exported by yew::events

I just want to make sure we don't misunderstand each other here.

I did misunderstand :) and I can update this
It's probably to no benefit to remove them in hindsight, any issues with compatibility would occur even if the event types weren't re-exported by Yew - we still add them as a feature in Yew so it doesn't effect the wasm size unless Yew specifically got into the feature gate game with events which I'm not advocating for btw :)

Events are back :)


add filter by creation time

Two search tags and query keys are planned to be added: search.clusterpedia.io/since and search.clusterpedia.io/before.
The time range is closed at the front and open at the back([, )).
Three time formats will be supported for added convenience:
1、unix time（seconds\millseconds）
2、RFC3339(2006-01-02T15:04:05Z07:00)
3、UTC Date(2006-01-02)
4、UTC Datetime(2006-01-02 15:04:05)

@cleverhu LGTM, Thank you for your contribution.


Multi Files

Is it possible to run for Multiple media files at once i.e. *.mp4?

Is it possible to run for Multiple media files at once i.e. *.mp4?

Atm, here it's not possible.
I've implemented support for wildcards in my repo, but it's standalone [not for Python].


Document the internal processing limit and error out when it is hit

The current rate control code would error out once i32::MAX frames are totaled.

Coverage decreased (-0.007%) to 82.597% when pulling 0546f0f340966dec1f36c444d7d67b319baf2503 on rust-av:document-rc-limit into 62ced16be188e93b28ead37a04068bcea9c58256 on xiph:master.


Adding support for custom filters and disabling filters through CLI

Summary
This introduces two new flags:

--filter: allows the use of custom filters with the detect-secrets engine
--disable-filter: allows users to disable built-in filters, if necessary

There's quite a bit of parsing logic to grok, but essentially, it allows for both custom modules to be used as custom filters, as well as local files. For example:
detect-secrets scan --filter detect_secrets_internal_filters.ml_model.is_secret

Might be YAGNI for now, but the intention is to accommodate new filters that may not be auto added to the default set (aka any new filters created after v1)

Merged to pre-v1-launch.

Merged to pre-v1-launch.


Make callout block component dismissible (optionally)

Right now, we have 2 notification bars at the top of PyPI.io
It would be nice to allow the users to dismiss these notifications, and remember that they've been dismissed.
If someone would be willing to make a PR with a simple 'close' link, I can style the button :)

Good First Issue: This issue is good for first time contributors. If you've already contributed to Warehouse, please work on another issue without this label instead. If there is not a corresponding pull request for this issue, it is up for grabs. For directions for getting set up, see our Getting Started Guide. If you are working on this issue and have questions, please feel free to ask them here, #pypa-dev on Freenode, or the pypa-dev mailing list.

@di - I feel like I should apply the 'good first issue' label here, but I'm not sure about the complexity of adding a cookie, etc.  Can you please confirm? Thx

I should be more specific here - we don't necessarily want to make all of the notification-bars dismiss-able - just the option to dismiss them in some cases.
In the same way, it would be nice for users to be able to remove documentation information boxes (callout-block component) and for PyPI to remember this preference, e.g.

Again, we don't want to make all callout-blocks dismiss-able - just in some cases :)

So, ideally, we could add a "dismissable" controller that would hide the target element, which we could reuse for pretty much anything.

I can make a PR with the appropriate CSS styles if someone else can provide the JS :)

@aalmazan now that cryvate's started working again on that other issue, would you like to try this one?

@brainwane Sure thing. Submitted a partial PR with a quick question in #3202 .

Notification bars are now dismissible, thanks to https://github.com/pypa/warehouse/pull/3202
This issue now only relates to the callout-block component, which we'd also like the user to be able to dismiss :)

@99 is working on this!

I see this ticket is linked to a merged PR. Should we close it or is it still applicable ?


Ability to hide the quick help bar

Problem Description
It would be useful for experienced users to hide quick help bar
Proposal
Add option in section "console" like console_help_bar -> true/false

PRs welcome!

Currently working on this.

Hey @mhils can you help me get started? Where should I look for?

The relevant code is in mitmproxy.tools.console. This feature is pretty much at the very bottom of my priority list, so I won't look closer into it! Whoever wants this needs to figure it out by themselves.


Create an indexer-service framework within indexer-common

My "dream" is to be able to write an indexer service for a new data service with only a few lines of code. Think along the lines of running a single run_indexer_service function to which a few things are passed:

A function to extract receipts from incoming requests.
A function to forward incoming requests to the data service backend (e.g. graph-node, SQL database).
A status API of sorts
A cost model API of sorts

This is done as of #80. The subgraph indexer-service has been ported to this framework as well, in #104.


fix: Always surface TOP_FAQ first

:tada: This PR is included in version 2.5.6 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


path params need enum support

In 1.5.1-M1 the path parameter does not allow for enums.  It should

nice! any chances for a 1.5.3-M1 containing the enum support?
thanks, zyro

M2 is fairly close. About a week or two.

ok. will have to wait then. or are maybe snapshots published somewhere? thanks for the quick reply! zyro

You can always build a snapshot of develop_2.0 locally ;)


Discard round-to-even code?

Round-to-even in %f is not working correctly, maybe it would be best to simply discard it completely? Opinions?
  unsigned long whole = (unsigned long)value;
  double tmp = (value - whole) * pow10[prec];
  unsigned long frac = (unsigned long)tmp;
  diff = tmp - frac;

The problem is that tmp value is multiplied by pow10.
With %.1f, 0.95:
0.95 is represented as 0.94999999999999996 in binary. This should be rounded down.
But (0.95 - 0) * 10 is 9.5, exactly representable in binary and tie-decision code takes place, rounding to even and outputting "1.0".
It may be possible to fix this double-rounding (at least in some cases), but IMO it's not worth the complexity. It may be simpler to just remove  the tie-handling code and live with it

One edge case is %.0f - current rounding computation is correct and .5 is exactly representable in binary, so rounding should apply.


Evaluate the customization of paper-chip template when used within paper-chip-input

i.e.
<paper-chip-input>
 <template>
  <paper-chip removable>

   </paper-chip>
 </template>
</paper-chip-input>

I'm prone to do not implement this at the moment.
But we have to discuss this huge feature internally.


Remove GroupType

GroupType (singleSelect, multiSelect) logic can be easily implement by the user which needs to handle and update the related UI logic anyways.

[x] Remove GroupType logic.
[ ] Add an example on how to create and handle the singleSelect and multiSelect logic.

Closed by https://github.com/robertpainsi/filtering.js/commit/640625f6773a53e6e83b118adb2d1e5be530e05e


Initial version of conversion modeling on IH

@StijnKas  @yusufuyanik1  see this, first cut of implementing the IH class, plots and aggregates. Use case is monitoring conversion results, should be more general purpose however. Have a look, sprinkle in comments, and yes I'll add tests and doc later.


PWM set issue

Using a new install compile and load pigpiod -t 1
from python load library and associate local pi and issue
pi.set_PWM_range(6,500)
I assumed this would give me ~2ms pulse width increments, however measuring on a scope I get
pi.set_PWM_dutycycle(6,0)
actual pulse width 0
and 0 right up to set dutycycle 3 where I get a pulse width of 4.6us
this in itself is not an issue however -
Set Actual
4 4.7
5 9.7
6 9.7
7 9.7
8 14.69
9 14.69
10 19.68
11 19.68
12 19.68
13 24.68
Ignoring absolute values as errors in my scope measurements I would have expected to the pulse width to increment consistently.
Any ideas as to what may be going wrong ?

sudo pigpiod -t1 starts the daemon with the PCM clock (the default).
At the default 5 µs sampling rate the default PWM frequency is 800 Hz.  So each pulse happens in a 1000000/800 or 1250 µs time slot.  There are 250 steps between off and fully-on (each step equates to 1 sampling period, or 5 µs at a 5 µs sampling rate, and 1250/5 gives 250).  The figure of 250 is what I refer to as the real range.  For convenience you can map the 250 steps into a range of your choice, but there are still only 250 discrete steps.
The C library (well the code) is the definitive statement of what happens, for instance, see  http://abyz.co.uk/rpi/pigpio/cif.html#gpioSetPWMrange

Hi thanks for the swift response,  user error....
I would like to be able to use more than 250 steps - am dimming some commercial LED's whose current/versus lumen output is non-linear especially toward low duty cycles. Will have a play with the range option which may work out.
In any case thanks for a brilliant and very useful library,
/Ed

You will have to lower the PWM frequency or increase the sample rate.
I would not suggest sampling higher than every 2 µs.  Use set_PWM_frequency to lower the frequency.
Remember there are two hardware PWM channels.  pigpio programs them to have a million steps between off and fully on.  See http://abyz.co.uk/rpi/pigpio/python.html#hardware_PWM

Hi Thanks for the pointers - have had a quick play and it works much closer to what I want - I can't use the hardware capable PWM channels as have maybe 10-13 output channels I want to control.
Thanks for the pointers

Hi Joan,
Have had a play with the hardware gpio and they fit the bill - I can control the illumination in almost imperceptible steps so looks like I'll be buying a PI Compute module or two...
Many thanks for your support, and also for such a useful library
/Ed

Remember the compute modules have the same number of hardware PWM channels (2) as the other Pi's with the 40 pin expansion header.
If I remember correctly the choice of a million steps was arbitrary, it could just have easily been 10 million.  I do not know what resolution the underlying hardware/GPIO can manage.

hmm - looking at http://abyz.co.uk/rpi/pigpio/python.html#hardware_PWM indicates to me that with a Pi 2 I only can access 4 GPIO's with hardware PWM but can get another 5 with the compute module.
Am I missing something?

That's correct, however, there are only two channels.  So all GPIO connected to channel 0 will have one setting and all GPIO connected to channel 1 will have another.
The same PWM channel is available on multiple gpios. The latest frequency and dutycycle setting will be used by all gpios which share a PWM channel.

Argh - just tested and.... you are correct!. Hmm, I wonder why this is designed this way - I would have expected and desired that I could independently PWM each channel.
..back to the drawing board..

correction - expected to independently PWM each GPIO.....

You seem to have pretty tough requirements.  I suggest you post what you need from PWM in detail, e.g. number of unique channels, frequencies, and resolution on https://www.raspberrypi.org/forums/.  I reckon you will need additional hardware support. There should be people who can suggest suitable hardware.

Hi Thanks - will post my requirements - deploying  a Pi for every two lights not only is overkill but expensive!!
I may take a look at servoblaster - however I am not at heart a programmer, and your very nice library allowed me to knock something together pretty quickly - so kudos to you!
Thankyou once again for your help and assistance

How about a Pi Zero for every two lights - is that more doable? :dollar: :pound: :smile:

Hi SlySven, I had considered that, however it seemed to me a somewhat brute force approach to solving my problem! I have resolved the expansion issue by using a pair of PCA9685 I2C bus 16 channel PWM adaptors. These are stateless -so single command to each channel to set PWM duty cycle so negligible cpu load, however I then realised my next challenge was how to handle the number of required input channels-  mainly from rotary encoders which including an on-off switch would require 3 GPIO's each ...and I need ~20 channels.
So currently testing using MCP23017 -16 channel GPIO's and using an interrupt routine triggered from a hardwire to a Pi GPIO since polling 64 channels was never going to work!
Have got the bare bones working with a single adaptor, and currently refining the code to efficiently expand it to cope with the 4 adaptors I need to use.
All good fun!!

I was looking at the Compute module a short while ago - now that does have a lot more GPIO pins available (~120 I believe)! :astonished:


Fix StringParser Pex failures

Check lengths before substring
Check hex chars before TryParse'ing
int.TryParse instead of int.Parse
Fix cast bug for EOF check on streams

Remaining exception during Pex runs: \uXXXX\uYYYY with an invalid UTF-32 codepoint, try...catch?

Question: during parsing failures in an Array or Object, should value be:

null
Whatever was read up to the point of the failure

Some of the methods (TryParseAsync usually) differ in their outputs.

At this point, the arguments should be null-checked already. I don't think we need those.

I think it's best to have null.  It should work like int.TryParse (and others), where the output parameter is the default value upon failure.  Ultimately I don't think it matters because we're returning an error message. From that point, the value should be ignored and a path be built up to the error.

Can you add a unit test to cover that UTF-32 issue? We can figure it what to do from there.

I've gone and made the TryParse routines consistent. I've also added a (currently failing) unit test for the invalid UTF-32 codepoint exception.

Thanks. I'll pull it down and have a look.

I figured out a way to do it without try/catch.  I'll merge this, then apply my changes.


Standardise coding standards

Codecov Report

Merging #173 (2e93795) into master (ccb8610) will decrease coverage by 0.03%.
The diff coverage is 33.33%.

:exclamation: Current head 2e93795 differs from pull request most recent head 540bcae. Consider uploading reports for the commit 540bcae to get more accurate results

@@             Coverage Diff              @@
##             master     #173      +/-   ##
============================================
- Coverage     45.62%   45.58%   -0.04%
- Complexity      494      495       +1
============================================
  Files           129      129
  Lines          2466     2470       +4
  Branches        304      304
============================================
+ Hits           1125     1126       +1
- Misses         1252     1255       +3
  Partials         89       89

Impacted Files
Coverage Δ

...du/address/logic/commands/AddInterviewCommand.java
0.00% <0.00%> (ø)

...a/seedu/address/logic/commands/AddTaskCommand.java
0.00% <ø> (ø)

.../address/logic/commands/ClearInterviewCommand.java
20.00% <0.00%> (ø)

...seedu/address/logic/commands/ClearTaskCommand.java
0.00% <0.00%> (ø)

...address/logic/commands/DeleteInterviewCommand.java
0.00% <0.00%> (ø)

...eedu/address/logic/commands/DeleteTaskCommand.java
0.00% <0.00%> (ø)

...va/seedu/address/logic/commands/ExportCommand.java
0.00% <0.00%> (ø)

...u/address/logic/commands/FindInterviewCommand.java
40.00% <0.00%> (ø)

.../seedu/address/logic/commands/FindTaskCommand.java
0.00% <0.00%> (ø)

...va/seedu/address/logic/commands/ImportCommand.java
57.14% <0.00%> (-2.86%)
:arrow_down:

... and 11 more

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 ccb8610...540bcae. Read the comment docs.


What does GRU mean for this crate?

I know GRU is a variant of RNN in the context of neural network of machine learning. And in the original NEAT paper, the author did mention a kind of RNN, with which the game double pole is solved----the RNN here is not what we refer to in the context of machine learning, right?
But what does GRU mean in the context of NEAT for this crate? Does it mean that NEAT could generate GRU structure (like in this paper), and with which could solve non-Markov decision problem?

Hey, GRU stands for Gated Recurrent Units which I believe is the same concept as the ones explored in your paper.
In this crate, connections between neurons can evolve to have GRU gates or not.

Hey, GRU stands for Gated Recurrent Units which I believe is the same concept as the ones explored in your paper.
In this crate, connections between neurons can evolve to have GRU gates or not.

So what paper you referred to for this crate?  I do what to know more about rnn+NEAT.

This paper:
https://scholar.google.ch/scholar_url?url=https://arxiv.org/pdf/1412.3555)&hl=en&sa=X&ei=xx1tY5eeG6mSy9YPyq-I8Ak&scisig=AAGBfm1QLoqDwmIOWXtWsBrcUTdX3K7r9g&oi=scholarr
The implementation here is a bit convoluted because of the fact that we represent NNs as graphs (sparse NNs) .
Basically a connection will keep a hidden state if it is a GRU connection and will reset and update according to the paper. Weights are learned with the Genetic Algorithm.

This paper:
https://scholar.google.ch/scholar_url?url=https://arxiv.org/pdf/1412.3555)&hl=en&sa=X&ei=xx1tY5eeG6mSy9YPyq-I8Ak&scisig=AAGBfm1QLoqDwmIOWXtWsBrcUTdX3K7r9g&oi=scholarr
The implementation here is a bit convoluted because of the fact that we represent NNs as graphs (sparse NNs) .
Basically a connection will keep a hidden state if it is a GRU connection and will reset and update according to the paper. Weights are learned with the Genetic Algorithm.

The paper you mentioned is trying to compare advantages over different RNN gate units. I have no doubt that both LSTM and GRU (or other gate-based RNN units) could solve supervise problems.
What  I wonder is if these RNN units could be used to solve non-Markov decision problems.
Actually, when seeing the word RNN in the original NEAT paper, I thought the answer is yes. But after digging deep, noticing that the RNN unit is just s simple hidden recurrent connection inside the generated network,  since there is no hidden input for each decision state, the answer seems to be no?
If I understand correctly, neat-gru-rust is just replacing the original NEAT-RNN with the gru gate unit?

Yes exactly. I made this crate as part of an automated trading strategy (non Markov) and then decided to open source it .

Yes exactly. I made this crate as part of an automated trading strategy (non Markov) and then decided to open source it .

Actually, I am also interested in putting NEAT or RL for trading.  But here there are 2  basic things I need to make clear.
1.How does neat-gru(your crate) behave when choosing an action in a no Markov env?  In detail, is there a "hidden state" that produced by gru unit , and then the hidden state serves as another input for the next env state?   If this is the case, a more detailed question: does the hidden state worked as a DIRECT input for the gru-unit node?

Does the RNN-unit mentioned in the original NEAT paper run under the same mechanism as neat-gru?  Because the paper doesn't explicitly say how the hidden state is treated in the following states when using NEAT for a decision process problem.

Here the previous input as well as the hidden state are saved in RAM. This means that after calling NN::compute(), the hidden state of the neural net changes and calling NN::compute() again with the same input is very likely to yield a different result.
You can look at the interactive example on https://senges.ch as well as read the code for more details.

Thanks, I would dig into the code. By the way, do you think NEAT+GRU is good enough for trading strategy? No need for help from reinforcement learning?

Technically the NEAT algorithm is reinforcement learning. I would say that trading is a very difficult problem with many possible approaches. And you will be competing with very well resourced and insanely talented hedge funds so it is probably not enough in itself, but very worthwhile as part of a larger strategy

I have to say, if treaing NEAT as reinforcement learning, it has to mention that NEAT improves network some how less directionally.  Anyway, your answer is really good enough to me, thanks


Incorrect calculation of 7 day avg line on the graph

Issue: 7 day avg line all flat despite data
Steps: Put Yale as the county. Checkout the second and third graph
Solution: I suspect No Data is handled as 0. I think we should ignore these values from the calculation of the mean average.

Even if we exclude no data/0, which may or may not be appropriate, this calculation is wrong. There are plenty of positive values over the month, and the 7-day average should show some variation as it hits those positive values.

This is caused by the server calculation for rolling averages rounding the average for each day.
I had raised this in the original PR adding rolling averages but it looks like it was merged without any changes made: https://github.com/project-vagabond/covid-green-regional-lambdas/pull/16#discussion_r479555053
Example for Tioga:

@jackmurdoch is on the case, PR https://github.com/project-vagabond/covid-green-regional-lambdas/pull/19 is posted, approved and awaiting deployment.

We're merged on this.   Should close provided project-vagabond/covid-green-regional-lambdas#19 fixes.

I think that PR was merged and changes rolled out to prod as well. Moving to QA for review.

Looks good to me now. Next step - break out a pixel ruler and a spreadsheet and calculate the moving averages by hand! 😉


client status display information suggestion

Can client status add the information display of the coinbase receiver and the total number of delegators?

Would it be useful to have two numbers:

the total number of delegations, and
if the node is a block producer, the number of delegations to the block producer public key
?

Possible path for this:

add total number of delegations in client status (do we have the total delegated stake, too?) (Matthew says this information is cached somewhere already)
add a new command to print delegation to a particular block producer, and amount of delegated stake

Gareth's block explorer has info about particular block producers, serving as a stop-gap until we implement this

Would it be useful to have two numbers:

the total number of delegations, and
if the node is a block producer, the number of delegations to the block producer public key
?

I think it's very useful

You can also get the list of delegators using GraphQL query:
query MyQuery {
  account(publicKey: "B62q...") {
    delegators {
      publicKey
    }
  }
}

@psteckler can you please check if we still need to do something here or the ticket can be closed?


Add support for \lparen and \rparen delimiters.

Add support for \lparen and \rparen delimiters as synonyms of ( and ) respectively.
See #806.

[clabot:check]

@AlbertHilb Thanks! One more request: could you add some simple tests? https://github.com/Khan/KaTeX/blob/master/test/katex-spec.js#L1199-L1200 would be easy to add to.

Test added and spaces fixed.

Thanks again for the pull request!


replace lodash bracker import with a full path

These changes significantly reduce my webpack bundle generated when using this package. Without the path to the function all of lodash was included in my build. From 565kb down to 54kb. You could also use this https://www.npmjs.com/package/babel-plugin-lodash but since just throttle was used I thought it would be quicker with search and replace.

Awesome!


feat: read deno.jsonc for version check

Description

Similar to #37, read deno.jsonc as well for version checking
Linked Issues
Additional context

So quick thanks! @antfu


Modify the master node to communicate with the trash_localizer node

Should be something like
finished_rotation -> waiting_for_node_to_localize_trash -> navigate_to_trash -> rotation

This is done!


Window Title Bug

The window title both in the app and the task bar is constantly changing from "Facebook" to "Messenger" approximately 5 times per second. This always occurs and has happened since installation. Using Windows 7 Pro 64-bit.

Can confirm, though only happens on first login, when it "detects" sign in from an unknown location and asks me whether I want to save the browser (I have that enabled in my Account settings). When I start up the app again, the bug is gone.

I can confirm this behavior as well.  win7 x64.  after restart it no longer "flashes."

Should be resolved.
Please see https://github.com/Aluxian/Facebook-Messenger-Desktop/issues/458


makes function and class objects linewise

To me this feels like what should be the default behaviour but not sure if this should be configurable or not?

I think this would conflict with cases like this
function foo () {function bar () {}}

Maybe we can check if the object is the only one in the line.

You could make this configurable. But I guess the default should be as they are now.

@stsewd Good point!
@theHamsta Sure I can update to make it configurable. Any preference how to configure it? For example:
require'nvim-treesitter.configs'.setup {
  textobjects = {
    selection_modes = {
<EMAIL_ADDRESS>= 'v',
<EMAIL_ADDRESS>= 'V',
    },
    select = {
      ...
    },
    ...
  },
}

?
Alternatively the choices could be 'c'/'l', 'charwise'/'linewise' or all choices are supported.

@AckslD I thinks the configuration as you suggested it would be good. It would also comprise <c-v> in case anyone ever needs it.

@theHamsta I made it part of the options in b595d5d

I knew I had commented about this in some place, I created this PR to solve this same problem https://github.com/nvim-treesitter/nvim-treesitter/pull/1953, but it conditionally selects from the start of the line.

Would it make sense to have daf be charwise, and daF be linewise? I think it would be cool because of how it relates to v and V…
I guess that would require introducing function.outer.charwise and function.outer.linewise, and deprecating function.outer in favor of function.outer.charwise.

@greg0ire I think we don't need to change the query for this, can just be done as in this MR to change the type of visual selection

@theHamsta, I'd say so :)

One could consider two extensions to this, but could be done in follow-up MRs:

Have the ability to specify selection mode per filetype. For example maybe one wants functions to be likewise in python but charwise in lua.
Have the ability to specify capture and selection mode for a given keymap. This would help eg @greg0ire to map different keys for different modes but the same capture. Although this would be a bit incompatible with the current structure of the config in this branch. I wonder if we should think about this already now maybe?

I lost Internet and only sent the comment now :)

Actually regarding the first of the above two points, we could also allow selection_modes to be a function which gets passed the query_string and keymap_mode and should return 'v', 'V' or '<c-v>'. Then the user could make this decision in arbitrary complex ways but in particular decide the mode depending on the current filetype. Thoughts @theHamsta?


Feature/#599 dedicated file screen

Description:
The CourseDetail Section got completly refactored with a mat tab bar that now shows a dedicated site for files only.
Closes #599
Improvements

Download got moved from Dialog to tab bar.
A Resolver has been implemented to pre fetch the course data.

Coverage remained the same at 65.608% when pulling ba91a318cbae05a5c5f12200ed38be81d2f7cd0e on feature/#599-Dedicated-File-Screen into 276743adbebfcd59f5002cfca761f0c6f5818a5c on develop.

Pull Request Test Coverage Report for Build 2428

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 65.624%

Totals

Change from base Build 2424:
0.0%

Covered Lines:
1149

Relevant Lines:
1676

💛  - Coveralls


Add press section to main site

Include this mention:
https://www.techwire.net/code-sacramentos-citycamp-event-set-jan-10/

http://www.govtech.com/local/4-Cities-Jumpstart-Civic-Tech-Solutions-with-CityCamp.html
https://www.nooga.com/168736/two-days-on-safety-and-the-floor-is-open/
http://wutc.org/post/civic-hacking-citycampcha-conversation-catherine-bracy

Media here: https://citycampcha.com/

http://www.governing.com/topics/mgmt/cities-try-to-promote-technology-solutions-with-new-initiative.html

http://www.oaklandwatch.org/2015/01/11/geeks-hack-city-issues-at-city-camp-oakland/


RCL static web content from dynamically loaded dll (not pre referenced by consuming application)

To me it is unclear how i can make static web content available to an application which does not references during build time.
I am instead loading the RCL as an plugin at runtime.
The documentation is missing steps to configure an application to consume the library when loaded in such a way.
The documentation says 'When the RCL is built, a manifest is produced that describes the static web asset locations. The consuming app reads the manifest at runtime to consume the assets from referenced projects and packages.'
It does not say what manifest this is. Is it the 'MyApp.StaticWebAssets.xml' xml file produced by the consuming app in which the static asset paths are mapped to the absolut source paths? The behavior is different when publishing and when debugging.
When the consuming app is producing this map file at build time.
How is loading the library as a plugin with static webasset locations mapped even possible than?
It says 'When the RCL is built'. Which manifest is it? Is it embedded?

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

ID: 9fd019c7-ceb7-6ef3-26ba-6b44341b6fc5
Version Independent ID: fd116d00-0dc7-efaf-c714-34d77b345a05
Content: Reusable Razor UI in class libraries with ASP.NET Core
Content Source: aspnetcore/razor-pages/ui-class.md
Product: aspnet-core
Technology: aspnetcore-razorpages
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

This issue, of using static files (js, css) from a dynamically loaded RCL, is not yet resolved and should remain open.
I can imagine a number of reasons as to why someone wants to use razor libraries in a solution.
But the most valuable case is when a library is loaded dynamically, as a plugin. Lets say an e-Commerce solution providing a number of Tax or Shipping Charges calculation plugins or Payment plugins, for the administrator to choose from.
By resolving this issue the platform will gain a lot.

Anyway, here is my solution to the problem of dynamically loaded RCLs with static files support in case anyone wants to look at it.


Jura dependency needs to be updated to use @accordproject/ergo

When using cicero execute with the latest 0.2.48 release of @accordproject/cicero-cli the following error occurs.
Rather than fixing the dependency to Jura, the cicero-engine library should use the latest version of the Ergo compiler.
09:24:17 - error:  Error: ENOENT: no such file or directory, open<EMAIL_ADDRESS>    at Object.fs.openSync (fs.js:646:18)
    at Object.fs.readFileSync (fs.js:551:33)
    at Engine.execute (/Users/matt/.nvm/versions/node/v8.11.1/lib/node_modules/@accordproject/cicero-cli/node_modules/@accordproject/cicero-engine/lib/engine.js:249:31)
    at Template.fromDirectory.then (/Users/matt/.nvm/versions/node/v8.11.1/lib/node_modules/@accordproject/cicero-cli/lib/commands.js:123:31)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
    at Function.Module.runMain (module.js:695:11)
    at startup (bootstrap_node.js:188:16)
    at bootstrap_node.js:609:3
09:24:17 - info:

I'm not sure how to replace this.  You may want to try again with Cicero after PR #52 has been merged.

Related to this line https://github.com/accordproject/cicero/blob/294ce8e45ae7918ff3a6764e59c45b3ac1a6153a/packages/cicero-engine/lib/engine.js#L249

Fixed in #55


Do not ignore LLVM target creation errors

@jemc It fixes a segfault if the user supplies an invalid target triple, so a changelog entry would be good. The automated system should be fine, and I'll add some details in the commit message.


chore(deps): set correct version of flask_caching

SUMMARY

We need to set the highest version of flask-caching lower than v2.0.0, because it need "cachelib >= 0.9.0" since v2.0 which is not compatible with requirements of superset("cachelib>=0.4.1,<0.5").
Ref: https://github.com/pallets-eco/flask-caching/blob/v2.0.0/setup.py
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

It failed down if building with flask-caching2.0.0+.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@KNOEEE did you check if it's possible to bump cachelib to the latest version? I believe the <0.5 restriction for cachelib is mainly there because 0.4 was the most recent version at the time that the lib was last bumped, and because of semver 0.5 is not guaranteed not to introduce a breaking change over 0.4.

@KNOEEE did you check if it's possible to bump cachelib to the latest version? I believe the <0.5 restriction for cachelib is mainly there because 0.4 was the most recent version at the time that the lib was last bumped, and because of semver 0.5 is not guaranteed not to introduce a breaking change over 0.4.

No, I didn't. Maybe I can try it. If it's all good, we should set deps as cachelib>=0.9.0,<0.10.0 and flask-caching>=1.10.0, right?

I'd prefer to bump the full chain of deps if it's possible, i.e. Flask-Caching to >=2.0.1, <3 and then see what other deps need to be bumped. I'm almost wondering if we can't remove the explicit cachelib requirement, as IMO Flask-Caching is our main dep for this functionality.

Closing this since it seems like we're on "flask-caching>=2.1.0, <3", now.


[DOC] Workload management at tenant level to improve resiliency

What do you want to do?

[ ] Request a change to existing documentation
[X] Add new documentation
[ ] Report a technical problem with the documentation
[ ] Other

Tell us about your request.
With this feature admin users will be able to create the QueryGroup constructs to ensure fair resource consumption. This will apply to search workload only.
QueryGroup will have resource (CPU, JVM) level thresholds which the feature will try to enforce at all times during the lifecycle of the Opensearch process.
*Version: List the OpenSearch version to which this issue applies, e.g. 2.14, 2.12--2.14, or all.
What other resources are available? Provide links to related issues, POCs, steps for testing, etc.

@Naarcha-AWS  this might be the dev PR (RFC actually) https://github.com/opensearch-project/OpenSearch/issues/11061


Extending lines between data points when zoomed and panning

Hi,
I've implemented a "time-series" graph by basically creating a chartview with lots of intervals (where each interval is 1 minute) ie: there is a data point at interval 1 and interval 61 if they are 1 hour apart.
I've noticed when I zoom into some points and panned across that the line connecting 2 data points will extend out beyond the limits of the start/end points of the line even if the data-points have disappeared form the view port.
I have made a recording of the bug in action: http://gfycat.com/SarcasticCarefreeGalapagostortoise

Did you modify drawLinear or drawCubic? If not, could you help debugging it? Should be an issue that if the interval is wider than screen width, it cannot find proper data point to connect and leads to weird behaviour.

Hey,
I have fixed the issue, I haven't checked it into github, since I'm not too sure what the ramifications are. But below is the description of my fix:
BEFORE:
drawLinear function was getting chart entries that is inside the bounds of the view by doing the following:

internal func drawLinear(#context: CGContext, dataSet: LineChartDataSet, entries: [ChartDataEntry]) {
        ...
        var entryFrom = dataSet.entryForXIndex(_minX)
        var entryTo = dataSet.entryForXIndex(_maxX)
        ....
}

AFTER:
So I added the follow functions to ChartDataSet class to give me the entry before the first visible entry and the entry after the last visible entry.

```swift
public func entryForBeforeXIndex(x: Int) -> ChartDataEntry?
{
        var index = self.entryIndex(xIndex: x)
        if (index > -1)
        {
            return _yVals[max(0,index-1)];
        }
        return nil
}
public func entryForAfterXIndex(x: Int) -> ChartDataEntry?
{
var index = self.entryIndex(xIndex: x)
if (index > -1)
{
        return _yVals[min(index+1, _yVals.count-1)];
    }
    return nil

}
</code>
Then I changed the drawLinear function to this instead:
<code>
```swift
internal func drawLinear(#context: CGContext, dataSet: LineChartDataSet, entries: [ChartDataEntry]) {
        ...
        var entryFrom = dataSet.entryForBeforeXIndex(_minX)
        var entryTo = dataSet.entryForAfterXIndex(_maxX)
        ....
}

It'll be great, if you guys can apply the changes the library if it doesn't break anything else.

@micnguyen try it out! @kwoylie you could raise a PR and let @danielgindi has a review.

@liuxuan30 @kwoylie fix does indeed fix this issue as well as #130. The core problem at hand is when the viewport changes, the data points no longer exist and there is funny rendering issues that come with that. Admittedly, this does come at a performance hit as it's looking at a much larger range of values, but the hit is temporarily worth the frequent and visible visual glitch.

I saw this in my project :( today Seems we need a enhancement.

Well I don't see this anymore, so I guess we fixed it in a commit somewhere :-)


wrap api client to add defaults

Issue link
https://issues.redhat.com/browse/RHOAIENG-12802
What changes have been made
If the user logged in using oc login ... the self signed CA cert wasn't being picked up
Verification steps
Use oc login in a ODH cluster with self signed certs. The user should be able to create Ray Clusters without doing anything special
Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[ ] Testing is not required for this change

/retest

/retest


@types Jasmine Error ...

[at-loader] node_modules/@types/jasmine/index.d.ts:39:52
    TS1005: '=' expected.
errors
(unknown) [at-loader] node_modules/@types/jasmine/index.d.ts:39:38
    TS2371: A parameter initializer is only allowed in a function or constructor implementation.
errors
(unknown) [at-loader] node_modules/@types/jasmine/index.d.ts:39:46
    TS2304: Cannot find name 'keyof'.

Fixed problem on my end - Simple solution - https://github.com/preboot/angular2-webpack/pull/296

@misterzik How did you resolve this?

I will update the repo in a minute with the solution.