has match but not send  mail，mail is right

[root@produce-120 elastalert]# python3 -m elastalert.elastalert --verbose --rule ./example_rules/my_rule.yaml  1 rules loaded INFO:elastalert:Starting up INFO:elastalert:Disabled rules are: [] INFO:elastalert:Sleeping for 59.999925 seconds INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 15:02 CST to 2020-05-27 15:17 CST: 73 / 73 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 15:17 CST to 2020-05-27 15:32 CST: 144 / 144 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 15:32 CST to 2020-05-27 15:47 CST: 84 / 84 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 15:47 CST to 2020-05-27 16:02 CST: 31 / 31 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 16:02 CST to 2020-05-27 16:17 CST: 104 / 104 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 16:17 CST to 2020-05-27 16:32 CST: 50 / 50 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 16:32 CST to 2020-05-27 16:47 CST: 118 / 118 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 16:47 CST to 2020-05-27 17:02 CST: 51 / 51 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 17:02 CST to 2020-05-27 17:17 CST: 88 / 88 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 17:17 CST to 2020-05-27 17:32 CST: 68 / 68 hits INFO:elastalert:Queried rule Example frequency rule from 2020-05-27 17:32 CST to 2020-05-27 17:36 CST: 9 / 9 hits INFO:elastalert:Background configuration change check run at 2020-05-27 17:37 CST INFO:elastalert:Disabled rules are: [] INFO:elastalert:Sleeping for 59.999881 seconds WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_rule_execution (trigger: interval[0:01:00], next run at: 2020-05-27 17:37:49 CST)" skipped: maximum number of running instances reached (1) WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_pending_alerts (trigger: interval[0:01:00], next run at: 2020-05-27 17:38:34 CST)" skipped: maximum number of running instances reached (1) INFO:elastalert:Background configuration change check run at 2020-05-27 17:38 CST INFO:elastalert:Disabled rules are: []

Yelp/elastalert is no longer maintained. Please use jertel/elastalert2.
https://github.com/jertel/elastalert2


Update Key Vault documentation

We need to update the Key Vault documentation in a few places:

[ ] Authentication in Samples: Our samples should show the use of Managed Identity instead of Service Principals with Client Secrets as the default authentication method. We can still show how to use the former for scenarios where the use of Managed Identity is not possible.
[ ] Cryptographic operations using CBC and CBCPAD: We should make it clear that there are some considerations to have when using these algorithms for local cryptographic operations using our clients:

We should add a notice similar to the following:

Microsoft recommends you not use CBC without first ensuring the integrity of the ciphertext using an HMAC, for example. See https://docs.microsoft.com/dotnet/standard/security/vulnerabilities-cbc-mode for more information.

When it comes to a user provided IV, we should make it clear that if they pass their own IV, they need to make sure they use a cryptographically random, non-repeating IV. Here's an example:

Optional initialization vector (IV). If you pass your own IV, make sure you use a cryptographically random, non-repeating IV. If null, a cryptographically random IV will be choosing using {RandomNumberGenerator | whatever cryptorng your language provides}.

You can refer to this Java PR for the second item (CBC crypto).


foreach pass-by-reference leads to "Avoid using undefined variables such as '$item' which will lead to PHP notices" error

PHPMD version: 2.8.1, 2.8.0, 2.8.0-beta.2, 2.8.0-beta.1
PHP Version: 7.2.26
Installation type: composer
Operating System / Distribution & Version: Ubuntu 18.04.3 LTS

Current Behavior
Foo.php
<?php

class Foo
{
    public function bar(array $array)
    {
        foreach ($array as &$item) {
            $item++;
        }
        return $array;
    }
}

Result:
$ vendor/bin/phpmd Foo.php text cleancode && echo "Success"
/home/user/project/Foo.php:7  Avoid using undefined variables such as '$item' which will lead to PHP notices.
/home/user/project/Foo.php:8  Avoid using undefined variables such as '$item' which will lead to PHP notices.

Expected Behavior
$ vendor/bin/phpmd Foo.php text cleancode && echo "Success"
Success

Steps To Reproduce:
See the example above
Checks before submitting

[x] Be sure that there isn't already an issue about this. See: Issues list
[x] Be sure that there isn't already a pull request about this. See: Pull requests
[x] I have added every step to reproduce the bug.
[x] If possible I added relevant code examples.
[x] This issue is about 1 bug and nothing more.
[x] The issue has a descriptive title. For example:  "JSON rendering failed on Windows for filenames with space".

Patch for this bug
diff --git a/src/main/php/PHPMD/Rule/CleanCode/UndefinedVariable.php b/src/main/php/PHPMD/Rule/CleanCode/UndefinedVariable.php
index dd90665..110daaf 100644
--- a/src/main/php/PHPMD/Rule/CleanCode/UndefinedVariable.php
+++ b/src/main/php/PHPMD/Rule/CleanCode/UndefinedVariable.php
@@ -18,6 +18,7 @@
 namespace PHPMD\Rule\CleanCode;

 use PDepend\Source\AST\ASTVariable;
+use PDepend\Source\AST\ASTUnaryExpression;
 use PDepend\Source\AST\State;
 use PHPMD\AbstractNode;
 use PHPMD\Node\AbstractCallableNode;
@@ -138,6 +139,10 @@ class UndefinedVariable extends AbstractLocalVariable implements FunctionAware,
             foreach ($foreachStatement->getChildren() as $children) {
                 if ($children instanceof ASTVariable) {
                     $this->addVariableDefinition($children);
+                } elseif ($children instanceof ASTUnaryExpression) {
+                    foreach ($children->getChildren() as $refChildren) {
+                        $this->addVariableDefinition($refChildren);
+                    }
                 }
             }
         }

Awesome, this could be a very good alternative until it get fixed in PDepend.

Since I have too many forks already I prefer if you could apply the patch yourself.

No problem I will add it and few tests.

Merged, you can test it requiring "phpmd/phpmd": "dev-master" it will be released in 2.8.3.

This is still an issue in 2.9.0
foreach ($data as $k => &$row) {   // error triggered here
    $row['foo'] = 'bar';                         // and here
}


Incorrect work of [ReferencePicker] with generic inheritance

Same setup as in the ReferencePicker example except we move abstract classes to a parent script:

Everything works well, but as soon as we make a generic version out of our classes-holders:

Whenever the reference picker arrow is clicked, nothing happens and a NullRef exception is thrown pointing to the line 31 in "ReferencePickerAttributeDrawer" (I guess "realType" is null).
Interestingly, if we move only one abstract class to the ParentScript - everything will work as intended.

Hi,
Interesting, I believe this is a new feature from Unity that I didn't notice.
What's your Unity version?
When I test on 2022.3.14.f1, it shows nothing (no arrow picker at all) with a different error. The script is as you provided:
// ParentScript.cs
namespace SaintsField.Samples.Scripts.IssueAndTesting.Issue.Issue112
{
    public class ParentScript<T>: MonoBehaviour
    {
        [Serializable]
        public abstract class Base1Fruit { }

        [Serializable]
        public abstract class Base2Fruit: Base1Fruit { }
    }
}

// ChildScript.cs
namespace SaintsField.Samples.Scripts.IssueAndTesting.Issue.Issue112
{
    public class ChildScript: ParentScript<float>
    {
        [Serializable]
        public class Apple: Base2Fruit { }

        [Serializable]
        public class Orange: Base2Fruit { }

        [SerializeReference, ReferencePicker] public Base2Fruit item;
    }
}

Inspector:

Error:

The field ...ChildScript.item has the [SerializeReference] attribute applied, but is of type ....ParentScript.Base2Fruit<System.Single>, which is a generic instance type. This is not supported. You must create a non-generic subclass of your generic instance type and use that as the field type instead.

Removing ReferencePicker gives the same error, which means the error came from Unity rather than SaintsField.
So providing your unity version is appreciated.

Tested on Unity 6000.0.25f1 and 6000.1.0a4 (SaintsField 3.9) with the same result.
Thanks

Hi
This bug has been fixed in 3.9.1, please have a try.


get-pip.py got no attribute 'PROTOCOL_SSLv3' error

The AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3' is showed when running get-pip.py. The problem is that the requests package in get-pip.py is old one which expects ssl.PROTOCOL_SSLv3 exists. However, this is not the case because SSLv3 is insecure now and distro likes Debian remove it from OpenSSL using OPENSSL_NO_SSLv3. This behavior is compliance with official Python document, and requests upstream had fix not to assume ssl.PROTOCOL_SSLv3 exists.
Please help to update the content of get-pip.py so that the error will not happen, thanks.

PR #142 should fix this I believe.

:thumbsup:

This is no longer an issue in https://github.com/poise/poise-python as get-pip.py is not bundled.


Persistent queue

Hi and nice project! Just wondering any queue mechanism in place if there is an overload traffic to outgoing sms and also to save to disk in case of system crash.
Thanks.

Yes, this is resolved through the local SQLite database. If the web interface received sendsms requests (threaded through webserver), the data is always stored into the database first. Afterwards a thread is triggered and this thread will process the SMS from database until there are no new SMS to send. If the server dies during this process the unsend SMS will be processed as usual after restart. Database entries will be deleted automatically after 90 days (configurable).

Thank you for such a descriptive reply.

No problem :)


Selection problem

If the selection is outside of the filtering it's a problem,
because everything will be unselected.

Just a small mistake, but it should be possible to choose not just the first element in the list :roll_eyes:


Update to GitHub for Mac version 200

Please don't update the version in the metadata or version specific info in the changelog. We will update those on release.

Sorry about that! I have now removed the metadata.rb and CHANGELOG.md changes.

Thanks. I wonder if this is a fool's errand though, given how quickly GitHub iterates on updating their software versions? That's one reason why this is an attribute - end consumers of this cookbook can set this to the desired version they want to install. Personally I use this recipe to install once and then let the automatic updater widget do its thing.


Broken link in AppEnginePlatformWarning

The AppEnginePlatformWarning link is currently broken. Should be: http://urllib3.readthedocs.io/en/latest/reference/urllib3.contrib.html

Yup, looks wrong to me, want to file a PR to fix it?

Can be closed? :)


Fix rebus handling in JSONtoXD

This is ready for review. The core problem was that the split insertion code in JSONtoXD assumed there was only a single rebus in the JSON metadata, so we'd end up with junk in the clues list in the resulting XD. I fixed things up and added better test coverage.

Yeah, this all makes sense to me, nice digging


doc/Interesting-Taps-&-Branches: rename to Interesting-Taps-&-Forks

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew tests with your changes locally?

This document lists Tigerbrew and Linuxbrew as interesting forks, not branches (they used to be "Interesting Branches (aka forks)" but that changed in b745546), so "Interesting Taps & Branches" is a more fitting title.
The term "branches" is also presumably confusing to folks with a shallow understanding of GitHub and/or git who may not realize how GitHub forks and git branches are related.

By the way, I wonder if it's really a good idea to have an ampersand (&) in the title and filename. It used to be part of a wiki page title which is fine, but maybe we could sanitize it a bit when putting it on every user's filesystem?

Makes sense, thanks!


coldstorage work

new --thaw-from option for seed will be used instead of the --secrets option
operational token display name inherits from original token
static resources support tagging in cold storage (see #82 for rest)

Looks good 👍


Add template for opam file

to make the package unavailable on unsupported architectures. See https://github.com/ocaml/opam-repository/pull/25074#discussion_r1485946922 for reference.

Unfortunately dune-project does not support the available flag (afaik), so you need to rely on a manual template for that.

absolute 🐐! thanks for the PR @mseri ✨


Panoramic Image

Hi,
a short question that how can I obtain the panoramic image (combining image from all cameras) from the dataset?
By the way, I am curious about the specific types of the lidars, and regarding the properties, what are the major differences between mid-range and short-range lidars?
Thanks.

You can write your own code to combine all the 5 images in each frame in the dataset generate panoramic image.  We do not have code to do that in this repo.
You can try out our tutorial and explore mid-range/short-range lidars. In short, they have different ranges.

@gogojjh
How is going on you Panoramic Image reconstruction?
Indeed, this dataset is suitable for Panoramic Image reconstruction.


Question about Yocto testing/integration.

Hi,
I found in commit history that this driver was tested with Yocto. Can I borrow original recipe from somewhere?
I created one by myself but I ran in problem that cmake cannot find python executable (find_program). Not sure what is wrong, mine recipe looks like this:
DESCRIPTION = "VK driver for the Raspberry Pi (Broadcom Videocore IV)"

inherit cmake python3-dir python3native

LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=0e9db807e4f1ed14373059c8499d5f82"

SRC_URI = "git://github.com/Yours3lf/rpi-vk-driver.git"
SRCREV = "39bb5f20e39185bf41a636a238437d55dc6ded5a"

PV = "1.0+git${SRCPV}"
S = "${WORKDIR}/git"

OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH"

Thanks for making this driver, I'm exited to try it out :-)
Bartłomiej

@jwinarske can you please help me out here?

@Yours3lf Thanks for mentioning @jwinarske. I found original recipe in his meta-flutter layer (recipe: rpi-vk-driver.bb). I think I know now how to progress with my problem :) thanks.
@jwinarske Maybe it's worth to submit your layer here - https://layers.openembedded.org/. I'll borrow rpi-vk-driver.bb recipe to my meta-retro with comment about original place and author :-)


Debugger via VM evaluates constructor argument instead of class member

Refiling https://github.com/Dart-Code/Dart-Code/issues/5363 here after discussion between @DanTup and @bkonyi
Describe the bug
In some scenarios (see reproduction below), the debugger shows the wrong (a stale, previous) value of a class field.  This can make debugging super confusing, since the actual behavior of the code doesn't match what the debugger is showing.
To Reproduce
Here's a simple piece of code that reproduces the issue.
class A {
  List list;
  A(this.list) {
    this.list = [3];

    print(list);
  }
}

void main() {
  A([1, 2]);
}

If you put a breakpoint on the print statement, you'll see two values of list depending on whether it is preceded by this..
With mouse-over on list in the print statement:

With mouse-over on this.list, which is the same variable:

You can also see something similar going on in the variables window:

The pattern appears to be related to the constructor containing this. referencing a field of the class, then whether or not further references to that variable include this. or not controls whether you get the latest or a stale value for that variable.
The output of the program is as expected:
[3]

Expected behavior
Variable values shown by the debugger match reality and are consistent, regardless of whether an unnecessary this. is included.
Screenshots
(see above)
Please complete the following information:
You can run the Dart: Collect Diagnostic Information command from the VS Code command palette (F1) to easily capture this information or provide it manually.

Operating System and version: Windows 11 + WSL
VS Code version: 1.95.3
Dart extension version: v3.102.0
Dart/Flutter SDK version: 3.5.4 (stable) (None) on "linux_x64", no Flutter
Target device (if the issue relates to Flutter debugging):

See details below:

Workspace Environment
Dart Code extension: 3.102.0

App: Visual Studio Code
App Host: desktop
Remote: wsl
Host Kind: wsl
Version: linux 1.95.3

Workspace type: Dart (LSP)
Workspace name: thislist [WSL: Ubuntu]

Dart (3.5.4): /usr/lib/dart
Flutter (undefined): undefined (No device)

Output from 'dart info'
/usr/lib/dart/bin/dart info
If providing this information as part of reporting a bug, please review the information
below to ensure it only contains things you're comfortable posting publicly.
General info

Dart 3.5.4 (stable) (None) on "linux_x64"
on linux / Linux <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024
locale is C.UTF-8

Project info

sdk constraint: '^3.5.4'
dependencies:
dev_dependencies: lints, test

FYI @derekxu16. Also cc @alexmarkov who might have some insights as to scoping.

Parameter (local variable) list should be hidden according to the language specification:

Initializing formals constitute an exception to the rule that every formal parameter
introduces a local variable into the formal parameter scope (9.2). When
the formal parameter list of a non-redirecting generative constructor contains
any initializing formals, a new scope is introduced, the formal parameter ini-
tializer scope, which is the current scope of the initializer list of the constructor,
and which is enclosed in the scope where the constructor is declared.

It looks like front-end is not taking this rule into account when deciding if list is a reference to a parameter or a field during expression evaluation.
/cc @johnniwinther

Is it the case that the same name could be either in the same frame? For example:
class A {
  final String foo;
  final String bar;
  A(String foo)
      : foo = '',       // foo 1
        bar = foo;      // foo 2
}

Something I mentioned in another issue is that it might be useful if we can provide a line/col instead of a string expression. It also solves some other issues like:
var aaa = 'one';
f() {
  var aaa = 'two';
  debugger();
}

If you stop at debugger() and hover over aaa on the first line, you'll get two if we only evaluate for the current frame using the name. VS Code/DAP does give us the line/col, so it could be nice if we could instead "evaluate the expression at line 1 column 5"?

Although, using line/col only works for hovers, and won't fix this issue if you type list into the Debug Console/watch window... so probably even if we did that, there's a fix needed here (although what to do in the initializer case noted above - assuming it was valid - I'm not sure).

@jensjoha The normal encoding of the AST does support the special scoping of variables from initializing formals so the error might be introduced when we compute the scope from the AST.

Thank you for your report and for the reproduction.
This is certainly a corner-case that we have not thought about.
What happens is this:
Compiling this (slightly modified) file:
import "dart:developer";

class A {
  List list;
  A(this.list) {
    list = [3];
    debugger();
    print(list);
  }
}

void main() {
  A([1, 2]);
}

results in this kernel file:
library;
import self as self;
import "dart:core" as core;
import "dart:developer" as dev;

import "dart:developer";

class A extends core::Object {
  field core::List<dynamic> list;
  constructor •(core::List<dynamic> list) → self::A
    : self::A::list = list, super core::Object::•() {
    this.{self::A::list} = core::_GrowableList::_literal1<dynamic>(3);
    dev::debugger();
    core::print(this.{self::A::list}{core::List<dynamic>});
  }
}
static method main() → void {
  new self::A::•(core::_GrowableList::_literal2<dynamic>(1, 2));
}

where we see that the constructor A(this.list) is rewritten as A(List<dynamic> list) : this.list = list, super().
Now, when compiling the body of the constructor it knows that list refers to this.list, but then
a) The VM just shows the locals that it has where it is paused (which includes list);
b) the expression compilation doesn't do anything special for constructors, so when
c) the VM says "compile list inside the class A in a situation where we have a local list, then
d) the expression compilation just finds list as the local.
As at least @johnniwinther and I have talked about many times, expression compilation is not really - and shouldn't really be - "Dart" - it is and should be something different and/or more.
Being able to - in a debug context - get one's hands on whatever was given as an argument might be useful. It might also be confusing. I don't know what the best thing to do here is, nor - assuming we can come up with a best thing - if it would be worth the effort.

Thanks for the explanation of the underlying reason for this behavior.
Expanding the capabilities of the debugger expressions to view more than what dart code directly could access seems like an interesting concept.  For example, I often wish I had unrestricted access to private variables of objects via debug expressions -- dart code doesn't have access, but the debugger does already via the UI.  However, the ability to write (somewhat) complex Dart expressions in the debug console is invaluable (e.g. I often will use .where or .map on collections to help debug in the console).  Adding the ability to declare temporary debug-only variables, similar to the Python debugger, could be cool too.
Regardless, the "proper" behavior in this context seems obvious to me: this.list and list should be reference the same thing in the debugger (and the same thing as the actual compilation/execution).  There are all sorts of contexts where a prior value of a variable has changed after some lines have executed, and I'm not sure why getting "one's hands on whatever was given as an argument" is worth an exception.  If it's so important, people can save the value in another variable or set a breakpoint earlier to see it.  The reasoning of why this bug exists doesn't justify the confusing behavior, since to the programmer there is only one variable.
Regarding "if it would be worth the effort," I think fixing this seems extremely valuable and important.  Debug tooling when switching to a new language takes some getting used to, and many people will instinctively go to the debugger to understand why their code isn't working, especially if they are new to Dart.  Seeing the wrong value in a variable in the debugger leaves developers confused and frustrated and may altogether dissuade them from sticking with Dart if they have alternatives under consideration.   There's a huge difference between thinking the debugger is practically perfect vs. thinking the debugger shows the wrong information in some contexts.  If people don't trust what the debugger is showing them, then they might start regressing to print statement debugging.


Overlapping profiles in duqtools plot config.yaml

Plots are the same for different runs with in duqtools plot config.yaml.
This happens in duqtools plot, but not in streamlit dash.py for some reason. I think the  imas DBEntry updates the numpy arrays in memory some how, and we keep a reference. One solution to try would be to copy the numpy arrays instead.

The problem is that the fields were initialized as class variables instead of instance variables.


Bug/fix stories

Changes proposed in this Pull Request:

Fix UserMenu in toolbar story
Remove weird shadow from with nav rail story
Update themes to<EMAIL_ADDRESS>New lock file

Deployed here:
https://pxblue-angular-library.web.app/

Let's not merge this in just yet, let's update to 6.0.3 first.

Dev is now using the latest themes, this PR can go in now.


play store version outdated? warning android 10

The play store version is from 2018, but the f-droid version is from June 2020.
I could not notice any problems, but k9 gives me a warning about possible incompatibility on android 10.
Is there a reason why the version in the play store was not updated?

See https://k9mail.app/2020/06/01/Whats-Up-With-K-9-Mail


Microsoft.CommonLanguageServerProtocol.Framework contains a proprietary License.txt

https://github.com/dotnet/dotnet/blob/826dcac6ef3a34e4e41042fb1112995fe1f21609/src/roslyn/src/Features/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/License.txt says:
1. INSTALLATION AND USE RIGHTS.
You may install and use any number of copies of the software to use solely with
Visual Studio Community
Visual Studio Professional
Visual Studio Enterprise
Visual Studio Code
...
In addition, you may not
...
* share, publish, rent, or lease the software; or
...

Should we remove Microsoft.CommonLanguageServerProtocol.Framework and subdirectories from the VMR?

[Triage] @oleksandr-didyk - Can you take this one?  TIA.

The package has quite a few references throughout roslyn, not sure we can just baseline it from the VMR (just in case tried it - the build fails miserably).
I'll contact the maintainers and consult them on the best approach here

https://github.com/dotnet/roslyn/issues/68781

Tracking issue on roslyn side - https://github.com/dotnet/roslyn/issues/68463
From conversations with the roslyn team we know that they are looking into possibly updating the license for the package in question and would let us know as soon as they have something concrete

I believe this was fixed by https://github.com/dotnet/roslyn/pull/68942

I believe this was fixed by dotnet/roslyn#68942

Great to hear, thank you for letting us now!

Closing as the change with removing the license has made it into the VMR with https://github.com/dotnet/dotnet/commit/7c263ce947cb4e46fee5f13e9ece6b93038d09af

@omajid Just to confirm, the only issue was with this Microsoft.CommonLanguageServerProtocol.Framework license (which has been corrected). You aren't seeing any other licensing issues, correct?

You aren't seeing any other licensing issues, correct?

Yes. I ran a scan on dotnet/roslyn and I don't see our tooling complain about any other files in roslyn.


Update examples for s3 bucket notifications and sqs queue policies

Description of your changes

Made BucketNotification.s3 uptestable
Made QueuePolicy.sqs uptestable
Test both sqs and sns notifications in BucketNotification.s3

Addresses a comment someone made in slack about having problems with bucket notifications
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

/test-examples="examples/s3/v1beta1/bucketnotification.yaml"

/test-examples="examples/v1beta1/sqs/queuepolicy.yaml"

/test-examples="examples/sqs/v1beta1/queuepolicy.yaml"

The failing uptest run was just because I typo'd the example name.

Commits merged into #1213 to help test that change to sqs queue policy


[KYUUBI #4038][FOLLOWUP] Use globalSparkContext

Why are the changes needed?

Use globalSparkContext to simplify the code.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Thanks, merging to master


Cypher injection API

HIVE developers (@bherr2 ) request cypher injection API to enable rapid development of queries which will be then possibly requested as APIs - consider on test version or some such but not on prod?

For those would-be black hat hackers, these databases themselves are at base configured as deployed read-only so only security risk this induces is tying up memory causing denial of service which one can do anyway to most any service. So don't bother trying to destroy the data via cypher injection. Thanks.

@computationdoc Can we close this? I don't really understand it. In any case, I think that the better approach is to document a use case and then ask us to develop an endpoint that satisfies the use case.


Some recipes are missing

The recipes of 4 Crucibles and Substrate & Advanced Substrate Casing are missing, making CVD Unit and Nanofab impossible to build :(

As this mod is still in pre-alpha development, most machines and related blocks are missing recipes. Upon alpha release, expect them to exist. Until then, you will have to wait.


prevent removing waypoint if it is unnecessary

Details

prevent removing waypoint if it is unnecessary
Fixed Issues

$ https://github.com/Expensify/App/issues/50176
PROPOSAL: https://github.com/Expensify/App/issues/50176#issuecomment-2392236572
Tests

Go to FAB > Submit expense > Distance
Add three waypoints
Swap two waypoints
Verify that the waypoints are changed correctly

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Go to FAB > Submit expense > Distance
Add three waypoints
Swap two waypoints
Verify that the waypoints are changed correctly

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/user-attachments/assets/4742c6ff-fee8-4177-974b-eef13cfdda88

Android: mWeb Chrome
https://github.com/user-attachments/assets/3a986c04-94da-48ab-ba28-e77f08303b3c

iOS: Native
https://github.com/user-attachments/assets/cdf03242-64b3-44b5-87e9-3294754006e3

iOS: mWeb Safari
https://github.com/user-attachments/assets/0ad8cc5c-de03-487a-b743-5201ae23f74b

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/aeb318ba-fab6-4ad0-b5c9-3907487dd031

MacOS: Desktop
https://github.com/user-attachments/assets/36b475f4-952a-4bd3-8e9f-b6c218a5c58e

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

I'm not sure if this is related to this or not, but on iOS when we swap the locations, there is a jerk before the locations reach to the correct positions.
https://github.com/user-attachments/assets/3b92b8a7-d8f3-40cc-89c6-66860f5e59b9

@nkdengineer The iOS video you uploaded does not test the scenario mentioned in this issue. Please make sure to upload the correct videos of all the platforms.

@Beamanator @jasperhuangg This issue should not be a blocker IMO. If you agree, feel free to merge!

@allroundexperts At the time I test with native, I can't swap the waypoint. I faced this bug that you mentioned above.

I don't feel like that bug is related to these changes, seems fine to merge this as is.

@allroundexperts I updated the video. We need to hold on the waypoint for a few second then we can swap.

Same same - to me, as long as the waypoints end up in the correct locations & not duplicating one of the waypoints & the API requests aren't dupe'd, i agree we're g2g 👍

Something has been wrong with the PR Reviewer checklist check today, going to go ahead and merge with it failing, the checklist is very clearly posted above.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

working well for me in staging!


cannot connect marketplace

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: Version: 1.60.0 (Universal)
OS Version: mac os big sur 11.4

Steps to Reproduce:

open Extensions
input someone plugin
get Error message: cannot connect marketplace

got the same problem...

got the same problem...

got the same problem...

i find it happen to mac os，windows vs code works well~~~

got the same problem in Windows

got the same problem

/duplicate
https://github.com/microsoft/vscode/issues/132634


Ignore missing waiver files

Fixes https://github.com/chef-cookbooks/audit/issues/413

Thank you for the reviews, merging and releasing v7.2.1 with this fix in


Add failfast mode

Commit adds new command line option, -K, that aborts all running jobs after first failed job.
This implements #2083.

Reporting on the current status of this PR:
On Linux, it works flawless! The build stops on first error, which is great! Very nice work!
On Windows, it stops on first error, but I do get a terminal prompt:
6 errors generated.
ninja: build stopped: interrupted by user.
Terminate batch job (Y/N)?

I am running ninja inside CMD, which in turn has been started from Cygwin bash. I am not certain whether CMD, Cygwin or bash have an effect on this. The prompt seems to originate from CMD, so maybe the kill signal should not be passed to CMD?

As I read some userexchange discussions, this message on Windows CMD is "by design". :-( https://superuser.com/a/35701/982937

Yep, after some googling I was also under the impression that CTRL-C is not really awesome for these kind of things.

Do you have any suggestions how to continue here?

Well, I'm really no expert, but sending CTRL-C to oneself seems anyways a "hard" way to end the whole process tree. Are these even separate processes or "just" threads, or even something else? What other ways does Win32 provide to kill them? Do we even need to kill, or can we just send an "interrupt" signal and catch that on the receiving side to exit the processes?

Hello @emmenlau !
I'd love to finish this.
Finally was able to spent some more time to inspect ninja source code, and I've noticed that regular Clear() function done in build.cc is actually sending signals to its children, so decided to give it a try.
Could you try the newest change I've just uploaded?
If that does not work, my only suggestion would be to enable this feature only for posix systems, until there will be someone who could help with Windows case.
In my company we already use patched ninja for some time with very good results (cha-ching!).

Awesome @kuchara , this works very nicely on Windows! I have not tested Linux and MacOSX yet, but the change looks very promising! Great work!


Error when a trade was made at 71 -> 64 in paper mode.

I think the issue is when the buildOptionSymbol is called loses sync with sending that string to the TK api. start the call to get the latest stock quote from inside the buildoptionsymbol call.

Fixed..i think.


Prince of Persia: The Two Thrones Freezing on capture

Describe the bug

When trying to capture a scene the game freezes and doesn't create a capture
bridge-remix-9789379, dxvk-remix-626bcc0
RTX 2070 Super
Driver 536.99
Patch 1.3 (Steam)

Attach logs!

NvRemixBridge.log
d3d9.log
POP3_d3d9.log
PrinceOfPersia_d3d9.log

Expected behavior
For a capture file to be made

Its working on me
https://media.discordapp.net/attachments/364145250773762050/1143872498522398731/image.png
https://media.discordapp.net/attachments/364145250773762050/1143872673743638600/image.png

@DoomDude531 Can you please confirm that this works for you?

It seems to work now.


[DO NOT REVIEW] Performance testing minification

With https://github.com/microsoft/monaco-editor/pull/3356 running on the playground, this sort of thing is now possible for us to do. Going to try running without and with minification enabled.

@typescript-bot perf test this

esbuild vs esbuild + minify:
 Here they are:

Metric
esbuild
esbuild + minify
Delta
Best
Worst

Angular - node (v18.10.0, x64)

Memory used
341,514k±0.01%
337,835k±0.01%
-3,680k-1.08%
337,692k
337,904k

Parse Time
1.55s±0.74%
1.54s±0.53%
-0.01s-0.32%
1.53s
1.56s

Bind Time
0.53s±0.76%
0.53s±0.84%
-0.00s-0.19%
0.52s
0.54s

Check Time
3.98s±0.63%
3.99s±0.32%
+0.01s+0.18%
3.96s
4.02s

Emit Time
4.28s±1.18%
4.24s±0.83%
-0.04s-0.96%
4.19s
4.35s

Total Time
10.34s±0.66%
10.30s±0.37%
-0.04s-0.43%
10.23s
10.42s

Compiler-Unions - node (v18.10.0, x64)

Memory used
190,228k±0.86%
184,994k±1.13%
-5,234k-2.75%
182,138k
187,957k

Parse Time
0.61s±1.01%
0.61s±1.01%
0.00s 0.00%
0.60s
0.62s

Bind Time
0.33s±1.12%
0.32s±0.92%
-0.00s-1.23%
0.32s
0.33s

Check Time
4.98s±0.30%
5.03s±0.53%
+0.05s+1.00%
4.97s
5.10s

Emit Time
1.52s±1.38%
1.52s±1.16%
-0.01s-0.59%
1.47s
1.55s

Total Time
7.44s±0.46%
7.47s±0.30%
+0.04s+0.51%
7.41s
7.51s

Monaco - node (v18.10.0, x64)

Memory used
321,779k±0.01%
318,112k±0.02%
-3,667k-1.14%
318,007k
318,212k

Parse Time
1.16s±1.07%
1.19s±1.62%
+0.03s+2.33%
1.14s
1.23s

Bind Time
0.50s±1.55%
0.48s±0.83%
-0.02s-4.01%
0.47s
0.49s

Check Time
3.85s±0.47%
3.83s±0.47%
-0.03s-0.70%
3.79s
3.88s

Emit Time
2.25s±1.11%
2.24s±0.43%
-0.02s-0.71%
2.21s
2.26s

Total Time
7.77s±0.59%
7.73s±0.29%
-0.04s-0.53%
7.68s
7.78s

TFS - node (v18.10.0, x64)

Memory used
285,602k±0.26%
281,120k±0.16%
-4,482k-1.57%
280,759k
282,888k

Parse Time
0.96s±1.38%
0.96s±1.34%
-0.00s-0.31%
0.93s
0.99s

Bind Time
0.45s±0.82%
0.44s±0.51%
-0.01s-1.12%
0.44s
0.45s

Check Time
3.80s±0.72%
3.80s±0.71%
+0.00s+0.11%
3.74s
3.87s

Emit Time
2.18s±0.96%
2.18s±0.98%
+0.00s+0.05%
2.14s
2.24s

Total Time
7.39s±0.64%
7.38s±0.46%
-0.00s-0.07%
7.32s
7.47s

material-ui - node (v18.10.0, x64)

Memory used
429,619k±0.01%
426,112k±0.02%
-3,507k-0.82%
425,969k
426,239k

Parse Time
1.32s±0.71%
1.36s±0.71%
+0.04s+2.95%
1.34s
1.38s

Bind Time
0.47s±3.41%
0.40s±1.44%
-0.07s-15.07%
0.39s
0.41s

Check Time
10.15s±0.88%
10.09s±0.61%
-0.06s-0.64%
9.96s
10.21s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
11.94s±0.74%
11.85s±0.54%
-0.10s-0.80%
11.72s
11.99s

xstate - node (v18.10.0, x64)

Memory used
522,440k±0.02%
511,592k±0.01%
-10,848k-2.08%
511,479k
511,786k

Parse Time
1.91s±0.43%
1.90s±0.31%
-0.00s-0.16%
1.89s
1.92s

Bind Time
0.73s±1.97%
0.73s±3.06%
-0.00s-0.14%
0.68s
0.78s

Check Time
1.04s±0.57%
1.03s±0.43%
-0.02s-1.53%
1.02s
1.04s

Emit Time
0.05s±6.42%
0.05s±0.00%
-0.00s-5.66%
0.05s
0.05s

Total Time
3.74s±0.54%
3.71s±0.73%
-0.03s-0.75%
3.64s
3.77s

Angular - node (v16.17.1, x64)

Memory used
340,881k±0.02%
337,220k±0.02%
-3,661k-1.07%
337,043k
337,286k

Parse Time
1.88s±0.34%
1.86s±0.37%
-0.02s-1.17%
1.84s
1.87s

Bind Time
0.64s±0.56%
0.65s±0.73%
+0.00s+0.47%
0.64s
0.66s

Check Time
5.12s±0.49%
5.13s±0.33%
+0.01s+0.20%
5.10s
5.18s

Emit Time
5.08s±0.82%
5.03s±0.70%
-0.05s-1.06%
4.97s
5.13s

Total Time
12.73s±0.50%
12.67s±0.33%
-0.07s-0.52%
12.60s
12.79s

Compiler-Unions - node (v16.17.1, x64)

Memory used
189,060k±0.66%
184,753k±0.62%
-4,307k-2.28%
183,675k
187,218k

Parse Time
0.79s±1.13%
0.78s±0.63%
-0.01s-1.27%
0.77s
0.79s

Bind Time
0.41s±1.15%
0.41s±0.54%
-0.00s-0.48%
0.41s
0.42s

Check Time
5.98s±0.39%
6.01s±0.60%
+0.03s+0.42%
5.95s
6.10s

Emit Time
1.91s±0.83%
1.92s±0.84%
+0.01s+0.37%
1.89s
1.97s

Total Time
9.10s±0.32%
9.12s±0.42%
+0.02s+0.24%
9.02s
9.22s

Monaco - node (v16.17.1, x64)

Memory used
321,038k±0.01%
317,414k±0.01%
-3,624k-1.13%
317,351k
317,477k

Parse Time
1.41s±0.68%
1.40s±0.60%
-0.01s-0.50%
1.38s
1.42s

Bind Time
0.59s±0.75%
0.60s±0.83%
+0.00s+0.68%
0.59s
0.61s

Check Time
4.86s±0.66%
4.85s±0.31%
-0.01s-0.29%
4.82s
4.88s

Emit Time
2.73s±0.83%
2.72s±0.56%
-0.01s-0.48%
2.69s
2.76s

Total Time
9.59s±0.56%
9.56s±0.26%
-0.02s-0.24%
9.52s
9.64s

TFS - node (v16.17.1, x64)

Memory used
284,216k±0.15%
280,321k±0.02%
-3,894k-1.37%
280,105k
280,375k

Parse Time
1.20s±1.59%
1.16s±1.15%
-0.04s-3.24%
1.14s
1.20s

Bind Time
0.54s±1.34%
0.54s±0.89%
-0.00s-0.92%
0.53s
0.55s

Check Time
4.79s±0.30%
4.76s±0.62%
-0.03s-0.65%
4.71s
4.84s

Emit Time
2.72s±2.40%
2.73s±2.30%
+0.01s+0.29%
2.63s
2.86s

Total Time
9.26s±0.65%
9.19s±0.74%
-0.07s-0.73%
9.08s
9.42s

material-ui - node (v16.17.1, x64)

Memory used
428,993k±0.02%
425,352k±0.01%
-3,640k-0.85%
425,284k
425,541k

Parse Time
1.62s±0.46%
1.66s±1.13%
+0.04s+2.59%
1.64s
1.73s

Bind Time
0.52s±1.12%
0.48s±1.02%
-0.03s-6.38%
0.47s
0.49s

Check Time
11.65s±0.76%
11.56s±0.41%
-0.09s-0.77%
11.47s
11.70s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
13.79s±0.66%
13.71s±0.36%
-0.08s-0.57%
13.62s
13.85s

xstate - node (v16.17.1, x64)

Memory used
520,028k±0.01%
509,136k±0.00%
-10,892k-2.09%
509,077k
509,170k

Parse Time
2.31s±0.39%
2.30s±0.40%
-0.01s-0.35%
2.28s
2.32s

Bind Time
0.84s±1.53%
0.79s±0.73%
-0.05s-5.60%
0.78s
0.81s

Check Time
1.37s±0.86%
1.36s±0.60%
-0.01s-0.44%
1.35s
1.39s

Emit Time
0.06s±0.00%
0.06s±0.00%
0.00s 0.00%
0.06s
0.06s

Total Time
4.58s±0.57%
4.52s±0.31%
-0.06s-1.40%
4.48s
4.55s

Angular - node (v14.15.1, x64)

Memory used
334,464k±0.01%
330,812k±0.01%
-3,652k-1.09%
330,753k
330,859k

Parse Time
2.04s±0.57%
2.04s±0.47%
+0.00s+0.20%
2.02s
2.06s

Bind Time
0.70s±0.64%
0.70s±0.52%
+0.01s+0.86%
0.70s
0.71s

Check Time
5.51s±0.41%
5.49s±0.82%
-0.02s-0.29%
5.42s
5.64s

Emit Time
5.33s±0.68%
5.29s±0.92%
-0.04s-0.73%
5.21s
5.46s

Total Time
13.57s±0.41%
13.53s±0.62%
-0.04s-0.32%
13.42s
13.76s

Compiler-Unions - node (v14.15.1, x64)

Memory used
182,415k±0.02%
179,124k±0.41%
-3,291k-1.80%
178,734k
182,090k

Parse Time
0.89s±0.45%
0.89s±0.38%
+0.00s+0.22%
0.89s
0.90s

Bind Time
0.46s±1.03%
0.46s±0.72%
-0.00s-0.65%
0.45s
0.47s

Check Time
6.31s±0.45%
6.30s±0.45%
-0.01s-0.19%
6.25s
6.35s

Emit Time
2.06s±1.11%
2.05s±0.78%
-0.01s-0.63%
2.01s
2.09s

Total Time
9.73s±0.43%
9.70s±0.39%
-0.03s-0.31%
9.64s
9.79s

Monaco - node (v14.15.1, x64)

Memory used
315,985k±0.01%
312,189k±0.01%
-3,795k-1.20%
312,120k
312,235k

Parse Time
1.57s±0.45%
1.56s±0.88%
-0.01s-0.51%
1.54s
1.60s

Bind Time
0.64s±1.10%
0.64s±0.63%
0.00s 0.00%
0.63s
0.65s

Check Time
5.22s±0.49%
5.21s±0.45%
-0.01s-0.15%
5.18s
5.26s

Emit Time
2.90s±0.81%
2.88s±0.92%
-0.02s-0.83%
2.83s
2.95s

Total Time
10.33s±0.45%
10.29s±0.47%
-0.04s-0.38%
10.19s
10.41s

TFS - node (v14.15.1, x64)

Memory used
281,050k±0.01%
277,330k±0.01%
-3,720k-1.32%
277,262k
277,409k

Parse Time
1.34s±1.73%
1.31s±0.51%
-0.03s-2.10%
1.29s
1.32s

Bind Time
0.59s±0.50%
0.59s±1.15%
+0.00s+0.51%
0.59s
0.62s

Check Time
5.09s±0.57%
5.08s±0.43%
-0.01s-0.27%
5.04s
5.12s

Emit Time
3.07s±1.12%
3.01s±0.83%
-0.05s-1.79%
2.97s
3.07s

Total Time
10.09s±0.61%
10.00s±0.40%
-0.09s-0.90%
9.95s
10.11s

material-ui - node (v14.15.1, x64)

Memory used
424,374k±0.00%
420,820k±0.01%
-3,554k-0.84%
420,774k
420,870k

Parse Time
1.87s±0.54%
1.86s±0.51%
-0.01s-0.75%
1.84s
1.88s

Bind Time
0.53s±0.56%
0.53s±0.63%
-0.00s-0.38%
0.52s
0.54s

Check Time
12.08s±0.56%
12.09s±0.52%
+0.00s+0.02%
11.96s
12.23s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
14.49s±0.46%
14.48s±0.42%
-0.01s-0.08%
14.35s
14.63s

xstate - node (v14.15.1, x64)

Memory used
508,162k±0.00%
497,435k±0.01%
-10,727k-2.11%
497,385k
497,513k

Parse Time
2.64s±0.40%
2.63s±0.33%
-0.01s-0.57%
2.61s
2.65s

Bind Time
0.85s±1.02%
0.82s±0.36%
-0.03s-3.07%
0.82s
0.83s

Check Time
1.48s±0.58%
1.48s±0.64%
-0.01s-0.40%
1.46s
1.50s

Emit Time
0.07s±0.00%
0.07s±0.00%
0.00s 0.00%
0.07s
0.07s

Total Time
5.05s±0.43%
5.00s±0.30%
-0.05s-0.91%
4.97s
5.04s

System

Machine Namets-ci-ubuntu
Platformlinux 5.4.0-126-generic
Architecturex64
Available Memory16 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

Hosts

node (v18.10.0, x64)
node (v16.17.1, x64)
node (v14.15.1, x64)

Scenarios

Angular - node (v18.10.0, x64)
Angular - node (v16.17.1, x64)
Angular - node (v14.15.1, x64)
Compiler-Unions - node (v18.10.0, x64)
Compiler-Unions - node (v16.17.1, x64)
Compiler-Unions - node (v14.15.1, x64)
Monaco - node (v18.10.0, x64)
Monaco - node (v16.17.1, x64)
Monaco - node (v14.15.1, x64)
TFS - node (v18.10.0, x64)
TFS - node (v16.17.1, x64)
TFS - node (v14.15.1, x64)
material-ui - node (v18.10.0, x64)
material-ui - node (v16.17.1, x64)
material-ui - node (v14.15.1, x64)
xstate - node (v18.10.0, x64)
xstate - node (v16.17.1, x64)
xstate - node (v14.15.1, x64)

Summary

Benchmark
Name
Iterations

Current
51153
10

Baseline
51153
10

esbuild vs esbuild + minify + keepNames:
 Here they are:

Metric
esbuild
esbuild + minify + keepNames
Delta
Best
Worst

Angular - node (v18.10.0, x64)

Memory used
341,514k±0.01%
339,292k±0.03%
-2,222k-0.65%
338,999k
339,439k

Parse Time
1.55s±0.74%
1.60s±0.88%
+0.05s+3.23%
1.57s
1.64s

Bind Time
0.53s±0.76%
0.53s±1.09%
+0.00s+0.19%
0.52s
0.54s

Check Time
3.98s±0.63%
4.46s±0.33%
+0.47s+11.93%
4.43s
4.49s

Emit Time
4.28s±1.18%
4.32s±0.62%
+0.04s+0.86%
4.27s
4.40s

Total Time
10.34s±0.66%
10.91s±0.39%
+0.56s+5.42%
10.84s
11.02s

Compiler-Unions - node (v18.10.0, x64)

Memory used
190,228k±0.86%
187,201k±1.01%
-3,027k-1.59%
183,303k
188,972k

Parse Time
0.61s±1.01%
0.63s±0.80%
+0.01s+2.29%
0.61s
0.63s

Bind Time
0.33s±1.12%
0.33s±0.89%
+0.01s+1.84%
0.33s
0.34s

Check Time
4.98s±0.30%
5.43s±0.49%
+0.45s+9.02%
5.37s
5.49s

Emit Time
1.52s±1.38%
1.57s±1.15%
+0.04s+2.69%
1.54s
1.61s

Total Time
7.44s±0.46%
7.94s±0.45%
+0.51s+6.79%
7.87s
8.04s

Monaco - node (v18.10.0, x64)

Memory used
321,779k±0.01%
319,422k±0.06%
-2,358k-0.73%
319,194k
320,137k

Parse Time
1.16s±1.07%
1.18s±1.02%
+0.03s+2.33%
1.16s
1.21s

Bind Time
0.50s±1.55%
0.48s±1.16%
-0.02s-4.21%
0.47s
0.49s

Check Time
3.85s±0.47%
4.29s±0.44%
+0.43s+11.18%
4.25s
4.32s

Emit Time
2.25s±1.11%
2.24s±0.72%
-0.01s-0.62%
2.21s
2.27s

Total Time
7.77s±0.59%
8.19s±0.22%
+0.42s+5.46%
8.15s
8.22s

TFS - node (v18.10.0, x64)

Memory used
285,602k±0.26%
282,727k±0.23%
-2,876k-1.01%
281,968k
284,126k

Parse Time
0.96s±1.38%
0.96s±2.01%
+0.00s+0.10%
0.93s
1.03s

Bind Time
0.45s±0.82%
0.45s±0.76%
+0.00s+0.22%
0.44s
0.45s

Check Time
3.80s±0.72%
4.29s±0.65%
+0.49s+12.82%
4.23s
4.37s

Emit Time
2.18s±0.96%
2.21s±0.84%
+0.03s+1.19%
2.17s
2.25s

Total Time
7.39s±0.64%
7.90s±0.39%
+0.51s+6.97%
7.86s
7.96s

material-ui - node (v18.10.0, x64)

Memory used
429,619k±0.01%
427,462k±0.01%
-2,157k-0.50%
427,381k
427,625k

Parse Time
1.32s±0.71%
1.39s±0.93%
+0.07s+5.00%
1.36s
1.42s

Bind Time
0.47s±3.41%
0.46s±3.93%
-0.01s-1.70%
0.44s
0.51s

Check Time
10.15s±0.88%
10.44s±0.55%
+0.29s+2.89%
10.34s
10.60s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
11.94s±0.74%
12.30s±0.41%
+0.35s+2.96%
12.18s
12.42s

xstate - node (v18.10.0, x64)

Memory used
522,440k±0.02%
515,160k±0.01%
-7,280k-1.39%
515,072k
515,308k

Parse Time
1.91s±0.43%
2.00s±0.49%
+0.09s+4.77%
1.98s
2.02s

Bind Time
0.73s±1.97%
0.70s±1.17%
-0.04s-4.78%
0.68s
0.72s

Check Time
1.04s±0.57%
1.09s±0.34%
+0.05s+4.89%
1.09s
1.10s

Emit Time
0.05s±6.42%
0.06s±0.00%
+0.01s+13.21%
0.06s
0.06s

Total Time
3.74s±0.54%
3.85s±0.35%
+0.11s+2.97%
3.83s
3.88s

Angular - node (v16.17.1, x64)

Memory used
340,881k±0.02%
338,704k±0.02%
-2,176k-0.64%
338,550k
338,776k

Parse Time
1.88s±0.34%
1.93s±0.89%
+0.05s+2.88%
1.90s
1.97s

Bind Time
0.64s±0.56%
0.64s±0.87%
-0.01s-0.93%
0.63s
0.65s

Check Time
5.12s±0.49%
5.64s±0.41%
+0.51s+9.97%
5.59s
5.68s

Emit Time
5.08s±0.82%
5.10s±0.47%
+0.01s+0.26%
5.05s
5.15s

Total Time
12.73s±0.50%
13.30s±0.26%
+0.57s+4.48%
13.23s
13.38s

Compiler-Unions - node (v16.17.1, x64)

Memory used
189,060k±0.66%
185,970k±0.59%
-3,090k-1.63%
184,970k
188,278k

Parse Time
0.79s±1.13%
0.79s±1.45%
+0.01s+0.89%
0.77s
0.81s

Bind Time
0.41s±1.15%
0.41s±0.72%
-0.00s-0.24%
0.41s
0.42s

Check Time
5.98s±0.39%
6.44s±0.53%
+0.46s+7.69%
6.38s
6.54s

Emit Time
1.91s±0.83%
1.93s±0.46%
+0.01s+0.68%
1.90s
1.94s

Total Time
9.10s±0.32%
9.58s±0.49%
+0.48s+5.27%
9.49s
9.70s

Monaco - node (v16.17.1, x64)

Memory used
321,038k±0.01%
318,670k±0.01%
-2,368k-0.74%
318,606k
318,717k

Parse Time
1.41s±0.68%
1.42s±0.71%
+0.02s+1.35%
1.41s
1.46s

Bind Time
0.59s±0.75%
0.60s±1.14%
+0.00s+0.68%
0.59s
0.62s

Check Time
4.86s±0.66%
5.35s±0.55%
+0.49s+10.14%
5.30s
5.42s

Emit Time
2.73s±0.83%
2.75s±1.21%
+0.02s+0.62%
2.69s
2.85s

Total Time
9.59s±0.56%
10.12s±0.59%
+0.53s+5.56%
10.03s
10.28s

TFS - node (v16.17.1, x64)

Memory used
284,216k±0.15%
281,502k±0.02%
-2,714k-0.95%
281,335k
281,577k

Parse Time
1.20s±1.59%
1.19s±1.68%
-0.02s-1.33%
1.14s
1.25s

Bind Time
0.54s±1.34%
0.55s±4.95%
+0.01s+1.85%
0.53s
0.66s

Check Time
4.79s±0.30%
5.30s±0.52%
+0.52s+10.77%
5.27s
5.40s

Emit Time
2.72s±2.40%
2.83s±1.86%
+0.11s+4.07%
2.71s
2.93s

Total Time
9.26s±0.65%
9.88s±0.62%
+0.62s+6.64%
9.69s
10.00s

material-ui - node (v16.17.1, x64)

Memory used
428,993k±0.02%
426,764k±0.01%
-2,229k-0.52%
426,704k
426,884k

Parse Time
1.62s±0.46%
1.69s±0.57%
+0.07s+4.19%
1.67s
1.71s

Bind Time
0.52s±1.12%
0.52s±1.19%
+0.00s+0.39%
0.51s
0.53s

Check Time
11.65s±0.76%
11.99s±0.53%
+0.34s+2.92%
11.87s
12.14s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
13.79s±0.66%
14.20s±0.43%
+0.41s+2.97%
14.07s
14.34s

xstate - node (v16.17.1, x64)

Memory used
520,028k±0.01%
512,814k±0.02%
-7,214k-1.39%
512,657k
513,042k

Parse Time
2.31s±0.39%
2.40s±0.37%
+0.10s+4.25%
2.39s
2.43s

Bind Time
0.84s±1.53%
0.85s±1.09%
+0.01s+0.95%
0.82s
0.86s

Check Time
1.37s±0.86%
1.43s±0.42%
+0.06s+4.16%
1.41s
1.44s

Emit Time
0.06s±0.00%
0.07s±0.00%
+0.01s+16.67%
0.07s
0.07s

Total Time
4.58s±0.57%
4.74s±0.31%
+0.16s+3.56%
4.72s
4.78s

Angular - node (v14.15.1, x64)

Memory used
334,464k±0.01%
332,332k±0.01%
-2,132k-0.64%
332,248k
332,395k

Parse Time
2.04s±0.57%
2.08s±0.55%
+0.05s+2.26%
2.06s
2.11s

Bind Time
0.70s±0.64%
0.70s±0.57%
+0.00s+0.14%
0.69s
0.71s

Check Time
5.51s±0.41%
6.00s±0.47%
+0.49s+8.86%
5.96s
6.07s

Emit Time
5.33s±0.68%
5.37s±0.69%
+0.04s+0.68%
5.29s
5.46s

Total Time
13.57s±0.41%
14.15s±0.31%
+0.57s+4.20%
14.05s
14.25s

Compiler-Unions - node (v14.15.1, x64)

Memory used
182,415k±0.02%
180,075k±0.01%
-2,339k-1.28%
180,027k
180,144k

Parse Time
0.89s±0.45%
0.91s±0.77%
+0.02s+2.02%
0.90s
0.93s

Bind Time
0.46s±1.03%
0.46s±0.80%
-0.01s-1.51%
0.45s
0.46s

Check Time
6.31s±0.45%
6.74s±0.50%
+0.43s+6.79%
6.67s
6.81s

Emit Time
2.06s±1.11%
2.07s±0.60%
+0.01s+0.39%
2.04s
2.09s

Total Time
9.73s±0.43%
10.18s±0.47%
+0.45s+4.66%
10.09s
10.29s

Monaco - node (v14.15.1, x64)

Memory used
315,985k±0.01%
313,546k±0.01%
-2,438k-0.77%
313,518k
313,585k

Parse Time
1.57s±0.45%
1.57s±0.33%
0.00s 0.00%
1.56s
1.58s

Bind Time
0.64s±1.10%
0.64s±0.53%
-0.00s-0.31%
0.63s
0.64s

Check Time
5.22s±0.49%
5.67s±0.47%
+0.45s+8.66%
5.64s
5.76s

Emit Time
2.90s±0.81%
2.90s±0.74%
-0.00s-0.17%
2.85s
2.96s

Total Time
10.33s±0.45%
10.78s±0.31%
+0.45s+4.32%
10.68s
10.84s

TFS - node (v14.15.1, x64)

Memory used
281,050k±0.01%
278,586k±0.01%
-2,465k-0.88%
278,530k
278,638k

Parse Time
1.34s±1.73%
1.30s±0.45%
-0.03s-2.40%
1.29s
1.32s

Bind Time
0.59s±0.50%
0.59s±0.84%
-0.01s-1.01%
0.58s
0.60s

Check Time
5.09s±0.57%
5.57s±0.39%
+0.48s+9.34%
5.53s
5.62s

Emit Time
3.07s±1.12%
3.05s±0.90%
-0.02s-0.52%
2.99s
3.13s

Total Time
10.09s±0.61%
10.51s±0.47%
+0.42s+4.18%
10.41s
10.63s

material-ui - node (v14.15.1, x64)

Memory used
424,374k±0.00%
422,229k±0.00%
-2,145k-0.51%
422,213k
422,263k

Parse Time
1.87s±0.54%
1.92s±0.60%
+0.05s+2.61%
1.90s
1.95s

Bind Time
0.53s±0.56%
0.53s±0.63%
-0.00s-0.38%
0.52s
0.54s

Check Time
12.08s±0.56%
12.42s±0.41%
+0.34s+2.79%
12.29s
12.51s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
14.49s±0.46%
14.87s±0.39%
+0.38s+2.62%
14.73s
14.98s

xstate - node (v14.15.1, x64)

Memory used
508,162k±0.00%
501,208k±0.01%
-6,954k-1.37%
501,144k
501,257k

Parse Time
2.64s±0.40%
2.75s±0.51%
+0.11s+4.05%
2.72s
2.79s

Bind Time
0.85s±1.02%
0.82s±0.46%
-0.03s-3.89%
0.81s
0.82s

Check Time
1.48s±0.58%
1.53s±0.49%
+0.05s+3.44%
1.52s
1.55s

Emit Time
0.07s±0.00%
0.07s±0.00%
0.00s 0.00%
0.07s
0.07s

Total Time
5.05s±0.43%
5.17s±0.27%
+0.12s+2.42%
5.16s
5.22s

System

Machine Namets-ci-ubuntu
Platformlinux 5.4.0-126-generic
Architecturex64
Available Memory16 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

Hosts

node (v18.10.0, x64)
node (v16.17.1, x64)
node (v14.15.1, x64)

Scenarios

Angular - node (v18.10.0, x64)
Angular - node (v16.17.1, x64)
Angular - node (v14.15.1, x64)
Compiler-Unions - node (v18.10.0, x64)
Compiler-Unions - node (v16.17.1, x64)
Compiler-Unions - node (v14.15.1, x64)
Monaco - node (v18.10.0, x64)
Monaco - node (v16.17.1, x64)
Monaco - node (v14.15.1, x64)
TFS - node (v18.10.0, x64)
TFS - node (v16.17.1, x64)
TFS - node (v14.15.1, x64)
material-ui - node (v18.10.0, x64)
material-ui - node (v16.17.1, x64)
material-ui - node (v14.15.1, x64)
xstate - node (v18.10.0, x64)
xstate - node (v16.17.1, x64)
xstate - node (v14.15.1, x64)

Summary

Benchmark
Name
Iterations

Current
51153
10

Baseline
51153
10

Minifying provides a slight speedup, but keeping the names for stack traces makes it a good bit slower.

@typescript-bot perf test this

esbuild vs esbuild + minifyWhitespace:
 Here they are:

Metric
A
B
Delta
Best
Worst

Angular - node (v18.10.0, x64)

Memory used
341,514k±0.01%
339,949k±0.02%
-1,566k-0.46%
339,736k
340,051k

Parse Time
1.55s±0.74%
1.55s±0.53%
+0.01s+0.39%
1.54s
1.57s

Bind Time
0.53s±0.76%
0.53s±1.09%
+0.00s+0.19%
0.52s
0.55s

Check Time
3.98s±0.63%
4.02s±0.71%
+0.04s+0.90%
3.97s
4.09s

Emit Time
4.28s±1.18%
4.31s±0.86%
+0.02s+0.56%
4.23s
4.41s

Total Time
10.34s±0.66%
10.41s±0.52%
+0.07s+0.64%
10.29s
10.51s

Compiler-Unions - node (v18.10.0, x64)

Memory used
190,228k±0.86%
188,754k±0.87%
-1,474k-0.77%
184,320k
190,079k

Parse Time
0.61s±1.01%
0.61s±0.85%
0.00s 0.00%
0.60s
0.62s

Bind Time
0.33s±1.12%
0.33s±0.91%
+0.00s+0.61%
0.32s
0.33s

Check Time
4.98s±0.30%
5.00s±0.69%
+0.03s+0.56%
4.94s
5.09s

Emit Time
1.52s±1.38%
1.53s±0.79%
+0.00s+0.13%
1.49s
1.55s

Total Time
7.44s±0.46%
7.47s±0.40%
+0.03s+0.43%
7.41s
7.55s

Monaco - node (v18.10.0, x64)

Memory used
321,779k±0.01%
320,266k±0.01%
-1,513k-0.47%
320,145k
320,363k

Parse Time
1.16s±1.07%
1.17s±1.18%
+0.01s+0.69%
1.13s
1.19s

Bind Time
0.50s±1.55%
0.48s±1.08%
-0.02s-3.61%
0.47s
0.49s

Check Time
3.85s±0.47%
3.83s±0.54%
-0.02s-0.65%
3.79s
3.89s

Emit Time
2.25s±1.11%
2.24s±0.88%
-0.01s-0.53%
2.21s
2.29s

Total Time
7.77s±0.59%
7.72s±0.42%
-0.05s-0.62%
7.67s
7.80s

TFS - node (v18.10.0, x64)

Memory used
285,602k±0.26%
283,872k±0.25%
-1,730k-0.61%
282,931k
285,236k

Parse Time
0.96s±1.38%
0.96s±1.50%
-0.01s-0.52%
0.93s
1.00s

Bind Time
0.45s±0.82%
0.45s±1.35%
-0.00s-0.22%
0.43s
0.46s

Check Time
3.80s±0.72%
3.80s±0.72%
+0.01s+0.13%
3.75s
3.87s

Emit Time
2.18s±0.96%
2.19s±0.78%
+0.01s+0.41%
2.15s
2.23s

Total Time
7.39s±0.64%
7.39s±0.40%
+0.00s+0.07%
7.34s
7.45s

material-ui - node (v18.10.0, x64)

Memory used
429,619k±0.01%
428,025k±0.01%
-1,594k-0.37%
427,982k
428,086k

Parse Time
1.32s±0.71%
1.33s±0.63%
+0.00s+0.38%
1.31s
1.35s

Bind Time
0.47s±3.41%
0.43s±2.61%
-0.05s-9.55%
0.40s
0.45s

Check Time
10.15s±0.88%
10.16s±0.75%
+0.01s+0.09%
10.02s
10.38s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
11.94s±0.74%
11.91s±0.68%
-0.03s-0.28%
11.77s
12.14s

xstate - node (v18.10.0, x64)

Memory used
522,440k±0.02%
517,850k±0.01%
-4,591k-0.88%
517,718k
517,995k

Parse Time
1.91s±0.43%
1.90s±0.25%
-0.01s-0.52%
1.89s
1.91s

Bind Time
0.73s±1.97%
0.77s±3.80%
+0.04s+5.60%
0.71s
0.82s

Check Time
1.04s±0.57%
1.04s±0.72%
-0.01s-0.67%
1.02s
1.05s

Emit Time
0.05s±6.42%
0.05s±0.00%
-0.00s-5.66%
0.05s
0.05s

Total Time
3.74s±0.54%
3.76s±0.64%
+0.02s+0.45%
3.70s
3.80s

Angular - node (v16.17.1, x64)

Memory used
340,881k±0.02%
339,395k±0.01%
-1,486k-0.44%
339,333k
339,470k

Parse Time
1.88s±0.34%
1.87s±0.54%
-0.01s-0.64%
1.85s
1.90s

Bind Time
0.64s±0.56%
0.64s±0.46%
-0.00s-0.31%
0.64s
0.65s

Check Time
5.12s±0.49%
5.13s±0.70%
+0.01s+0.14%
5.06s
5.25s

Emit Time
5.08s±0.82%
5.10s±1.11%
+0.02s+0.37%
4.97s
5.27s

Total Time
12.73s±0.50%
12.74s±0.63%
+0.01s+0.07%
12.61s
13.01s

Compiler-Unions - node (v16.17.1, x64)

Memory used
189,060k±0.66%
186,829k±0.61%
-2,232k-1.18%
185,712k
189,255k

Parse Time
0.79s±1.13%
0.78s±0.71%
-0.00s-0.51%
0.77s
0.79s

Bind Time
0.41s±1.15%
0.41s±0.88%
+0.00s+0.24%
0.41s
0.42s

Check Time
5.98s±0.39%
5.96s±0.54%
-0.02s-0.37%
5.89s
6.02s

Emit Time
1.91s±0.83%
1.90s±0.81%
-0.02s-0.89%
1.86s
1.92s

Total Time
9.10s±0.32%
9.05s±0.36%
-0.04s-0.48%
8.99s
9.14s

Monaco - node (v16.17.1, x64)

Memory used
321,038k±0.01%
319,502k±0.01%
-1,537k-0.48%
319,410k
319,560k

Parse Time
1.41s±0.68%
1.41s±0.48%
+0.00s+0.07%
1.40s
1.43s

Bind Time
0.59s±0.75%
0.59s±0.68%
-0.00s-0.17%
0.58s
0.60s

Check Time
4.86s±0.66%
4.84s±0.42%
-0.02s-0.47%
4.80s
4.89s

Emit Time
2.73s±0.83%
2.69s±0.37%
-0.03s-1.21%
2.67s
2.72s

Total Time
9.59s±0.56%
9.53s±0.22%
-0.05s-0.56%
9.50s
9.59s

TFS - node (v16.17.1, x64)

Memory used
284,216k±0.15%
282,466k±0.02%
-1,750k-0.62%
282,267k
282,523k

Parse Time
1.20s±1.59%
1.20s±0.84%
+0.00s+0.08%
1.19s
1.24s

Bind Time
0.54s±1.34%
0.54s±0.74%
-0.00s-0.55%
0.53s
0.55s

Check Time
4.79s±0.30%
4.78s±0.34%
-0.01s-0.25%
4.73s
4.81s

Emit Time
2.72s±2.40%
2.72s±1.95%
+0.00s+0.04%
2.65s
2.84s

Total Time
9.26s±0.65%
9.25s±0.59%
-0.01s-0.15%
9.17s
9.37s

material-ui - node (v16.17.1, x64)

Memory used
428,993k±0.02%
427,351k±0.01%
-1,642k-0.38%
427,308k
427,402k

Parse Time
1.62s±0.46%
1.63s±0.68%
+0.01s+0.43%
1.61s
1.65s

Bind Time
0.52s±1.12%
0.50s±0.95%
-0.01s-2.71%
0.49s
0.51s

Check Time
11.65s±0.76%
11.55s±0.25%
-0.10s-0.88%
11.47s
11.61s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
13.79s±0.66%
13.68s±0.20%
-0.11s-0.81%
13.61s
13.75s

xstate - node (v16.17.1, x64)

Memory used
520,028k±0.01%
515,367k±0.01%
-4,661k-0.90%
515,242k
515,594k

Parse Time
2.31s±0.39%
2.29s±0.33%
-0.02s-0.87%
2.27s
2.30s

Bind Time
0.84s±1.53%
0.83s±1.83%
-0.01s-0.71%
0.81s
0.86s

Check Time
1.37s±0.86%
1.36s±0.55%
-0.01s-0.66%
1.35s
1.38s

Emit Time
0.06s±0.00%
0.06s±0.00%
0.00s 0.00%
0.06s
0.06s

Total Time
4.58s±0.57%
4.54s±0.46%
-0.04s-0.79%
4.50s
4.59s

Angular - node (v14.15.1, x64)

Memory used
334,464k±0.01%
332,936k±0.00%
-1,528k-0.46%
332,894k
332,968k

Parse Time
2.04s±0.57%
2.03s±0.66%
-0.00s-0.15%
2.02s
2.08s

Bind Time
0.70s±0.64%
0.70s±0.57%
+0.00s+0.43%
0.69s
0.71s

Check Time
5.51s±0.41%
5.50s±0.48%
-0.01s-0.18%
5.45s
5.55s

Emit Time
5.33s±0.68%
5.27s±0.52%
-0.06s-1.14%
5.21s
5.35s

Total Time
13.57s±0.41%
13.50s±0.20%
-0.07s-0.55%
13.44s
13.56s

Compiler-Unions - node (v14.15.1, x64)

Memory used
182,415k±0.02%
180,830k±0.02%
-1,585k-0.87%
180,737k
180,882k

Parse Time
0.89s±0.45%
0.89s±0.63%
-0.00s-0.34%
0.88s
0.90s

Bind Time
0.46s±1.03%
0.46s±0.65%
-0.00s-1.08%
0.45s
0.46s

Check Time
6.31s±0.45%
6.30s±0.65%
-0.01s-0.19%
6.23s
6.40s

Emit Time
2.06s±1.11%
2.05s±0.52%
-0.01s-0.24%
2.04s
2.08s

Total Time
9.73s±0.43%
9.70s±0.43%
-0.02s-0.26%
9.61s
9.80s

Monaco - node (v14.15.1, x64)

Memory used
315,985k±0.01%
314,429k±0.01%
-1,556k-0.49%
314,381k
314,475k

Parse Time
1.57s±0.45%
1.57s±0.64%
+0.00s+0.13%
1.56s
1.60s

Bind Time
0.64s±1.10%
0.64s±0.47%
-0.00s-0.16%
0.63s
0.64s

Check Time
5.22s±0.49%
5.21s±0.46%
-0.01s-0.25%
5.18s
5.27s

Emit Time
2.90s±0.81%
2.89s±0.54%
-0.02s-0.62%
2.85s
2.93s

Total Time
10.33s±0.45%
10.30s±0.28%
-0.03s-0.28%
10.25s
10.38s

TFS - node (v14.15.1, x64)

Memory used
281,050k±0.01%
279,537k±0.01%
-1,514k-0.54%
279,445k
279,591k

Parse Time
1.34s±1.73%
1.33s±1.93%
-0.01s-0.67%
1.30s
1.41s

Bind Time
0.59s±0.50%
0.59s±0.80%
-0.00s-0.34%
0.58s
0.60s

Check Time
5.09s±0.57%
5.10s±0.59%
+0.00s+0.04%
5.05s
5.17s

Emit Time
3.07s±1.12%
3.06s±0.66%
-0.01s-0.39%
3.02s
3.12s

Total Time
10.09s±0.61%
10.07s±0.56%
-0.02s-0.20%
9.99s
10.25s

material-ui - node (v14.15.1, x64)

Memory used
424,374k±0.00%
422,825k±0.00%
-1,549k-0.37%
422,785k
422,849k

Parse Time
1.87s±0.54%
1.87s±0.53%
-0.00s-0.05%
1.86s
1.90s

Bind Time
0.53s±0.56%
0.53s±0.84%
-0.00s-0.75%
0.52s
0.54s

Check Time
12.08s±0.56%
12.06s±0.22%
-0.02s-0.18%
11.99s
12.12s

Emit Time
0.00s±0.00%
0.00s±0.00%
0.00s NaN%
0.00s
0.00s

Total Time
14.49s±0.46%
14.46s±0.22%
-0.03s-0.19%
14.38s
14.53s

xstate - node (v14.15.1, x64)

Memory used
508,162k±0.00%
503,591k±0.01%
-4,571k-0.90%
503,530k
503,661k

Parse Time
2.64s±0.40%
2.63s±0.68%
-0.01s-0.42%
2.59s
2.68s

Bind Time
0.85s±1.02%
0.82s±0.58%
-0.03s-2.95%
0.81s
0.83s

Check Time
1.48s±0.58%
1.48s±0.60%
-0.01s-0.40%
1.46s
1.50s

Emit Time
0.07s±0.00%
0.07s±0.00%
0.00s 0.00%
0.07s
0.07s

Total Time
5.05s±0.43%
5.01s±0.32%
-0.04s-0.81%
4.97s
5.06s

System

Machine Namets-ci-ubuntu
Platformlinux 5.4.0-126-generic
Architecturex64
Available Memory16 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

Hosts

node (v18.10.0, x64)
node (v16.17.1, x64)
node (v14.15.1, x64)

Scenarios

Angular - node (v18.10.0, x64)
Angular - node (v16.17.1, x64)
Angular - node (v14.15.1, x64)
Compiler-Unions - node (v18.10.0, x64)
Compiler-Unions - node (v16.17.1, x64)
Compiler-Unions - node (v14.15.1, x64)
Monaco - node (v18.10.0, x64)
Monaco - node (v16.17.1, x64)
Monaco - node (v14.15.1, x64)
TFS - node (v18.10.0, x64)
TFS - node (v16.17.1, x64)
TFS - node (v14.15.1, x64)
material-ui - node (v18.10.0, x64)
material-ui - node (v16.17.1, x64)
material-ui - node (v14.15.1, x64)
xstate - node (v18.10.0, x64)
xstate - node (v16.17.1, x64)
xstate - node (v14.15.1, x64)

Summary

Benchmark
Name
Iterations

Current
51153
10

Baseline
51153
10

No surprise, removing whitespace doesn't seem to change execution time in any meaningful way (but, does save us on space!)


Documentation For Whitelist Usage

  # This list determines which outside domains can communicate with the AMS API.  Use '*' for wildcard.
  config.cors_whitelist = 'http://localhost:4200'

from the source code, how do i add my heroku app? Comma separated?

In most cases, you'll want to lock this to your environment ("localhost" for dev, "production.com" for prod), so I'd recommend passing it in from your secrets.yml or ENV.
I think there's some problems with actually listing multiple values (with the spec, not spree_ams, but I need to do some more research on that.
As it's an API anyway, its not bad practice to just do '*' and open it up to requests from anywhere.

again placing it in the notebook

On Jun 23, 2015, at 10:36 AM, Hugh Francis<EMAIL_ADDRESS>wrote:
In most cases, you'll want to lock this to your environment ("localhost" for dev, "production.com" for prod), so I'd recommend passing it in from your secrets.yml or ENV.
I think there's some problems with actually listing multiple values (with the spec, not spree_ams, but I need to do some more research on that.
As it's an API anyway, its not bad practice to just do '*' and open it up to requests from anywhere.
—
Reply to this email directly or view it on GitHub https://github.com/hhff/spree_ams/issues/22#issuecomment-114528281.

If you'd like to submit a PR documenting the feature a bit better, I'd love that!

Confirmed that:
There can only be one Access-Control-Allow-Origin response header, and that header can only have one origin value. Therefore, in order to get this to work, you need to have some code that:

Grabs the Origin request header.
Checks if the origin value is one of the whitelisted values.
If it is valid, sets the Access-Control-Allow-Origin header with that value.
I don't think there's any way to do this solely through the web.config.

Therefore, in its current iteration we can only accept a single value, or *

Made an issue to allow this: #24


allow setting update_setting_interval = 0

if user does not want to spend time on evaluation of objective currently there is no other way than selecting a very large update_objective_interval.
https://github.com/vais-ral/CCPi-Framework/blob/master/Wrappers/Python/ccpi/optimisation/algorithms/Algorithm.py#L124

closed by #674


[stable/aerospike] Add load balancer source ranges

What this PR does / why we need it:
It add support to setup k8s service loadBalancerSourceRanges in order to restrict access for LoadBalancer Service.
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/ok-to-test

Done @paulczar

/lgtm


Fix regression on system page preventing save with blank DNS servers

Introduced in f700dc9 for ticket #5915.
Fixes ticket #5916.
Blank DNS slots will always cause the count check to return false so you can't save the page with less than 3 DNS servers listed.

Before this pull request can be accepted you must first sign a CLA as described at https://www.pfsense.org/about-pfsense/#cla. Please read for more details.

I apologise for not having the ICLA signed beforehand. I have rectified this.

Thanks


twitch randomly stopped working

https://hastebin.com/buxatipihi.lua
When i check the stream link myself it works fine.

update it only does this somethimes when i rejoin the channel it starts working

Appears broken on FredBoat as well on 1.2.44

#75

Fix merged.


Replace explicit generic type with diamond operator

Hello @igor-suhorukov
Thanks for the patch!
There are several issues that has to be resolved prior merge:

Please, edit PR description. Use format IGNITE-XXXX: Ticket description.
Where: "IGNITE-XXXX" is the Jira ticket you trying to resolve with this patch.
"Ticket description" = Replace explicit generic type with diamond operator

Please, resolve conflicts with master

You should edit ~/src/ignite/idea/ignite_codeStyle.xml, ~/src/ignite/idea/ignite_inspections_teamcity.xml to enable corresponding inspection. So we would check future patches with it.


Unable to run hello world app in Linux device

Steps to Reproduce
When I run the flutter demo app after selecting a device as Linux  I am getting the following error.
I am using Ubuntu 16.04.7 LTS
Logs
CMake Error at /snap/flutter/91/usr/share/cmake-3.10/Modules/CMakeTestCXXCompiler.cmake:45 (message):
  The C++ compiler

    "/snap/flutter/current/usr/bin/clang++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /sirius/work/rabhil/hello_flutter/build/linux/x64/debug/CMakeFiles/CMakeTmp

    Run Build Command:"/snap/flutter/current/usr/bin/ninja" "cmTC_c6f8a"
    [1/2] Building CXX object CMakeFiles/cmTC_c6f8a.dir/testCXXCompiler.cxx.o
    [2/2] Linking CXX executable cmTC_c6f8a
    FAILED: cmTC_c6f8a
    : && /snap/flutter/current/usr/bin/clang++    -L/snap/flutter/current/usr/lib/gcc/x86_64-linux-gnu/8 -L/snap/flutter/current/usr/lib/x86_64-linux-gnu -lblkid -lgcrypt -llzma -lpthread -L/snap/flutter/current/usr/lib/ CMakeFiles/cmTC_c6f8a.dir/testCXXCompiler.cxx.o  -o cmTC_c6f8a   && :
    /snap/flutter/current/usr/lib/x86_64-linux-gnu/libgcrypt.so: undefined reference to<EMAIL_ADDRESS>    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    ninja: build stopped: subcommand failed.
<details>
<summary>Logs</summary>

[✓] Flutter (Channel stable, 2.2.1, on Linux, locale en_US.UTF-8)
[✗] Android toolchain - develop for Android devices
    ✗ Unable to locate Android SDK.
      Install Android Studio from: https://developer.android.com/studio/index.html
      On first launch it will assist you in installing the Android SDK components.
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup for detailed instructions).
      If the Android SDK has been installed to a custom location, please use
      `flutter config --android-sdk` to update to that location.

[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[!] Android Studio (not installed)
[✓] VS Code (version 1.58.2)
[✓] Connected device (2 available)

! Doctor found issues in 2 categories.

Same with #81882.
Solve in here

HI @abhilashraju
This is a duplicate of https://github.com/flutter/flutter/issues/81882, please follow the comment link above
Closing as duplicate of https://github.com/flutter/flutter/issues/81882


Add Variable parsing

With current version of companion variables go a big boost and seem quit useful to enable variable parsing so variables could be used as values or inside of addresses for the OSC modul.
This seems to be a functionality that the base companion application provides that need to be implemented by the modules.

This is supported but developers have to implement it on a per-field basis. this.parseVariables(string, cb);
https://github.com/bitfocus/companion/issues/1248#issuecomment-706811208

(source of the parseVariables function)
https://github.com/bitfocus/companion/blob/master/instance_skel.js#L218
If i can provide any assistance for getting this working let me know.

Hello,
Can you add support to variables for the Path, and not just the Arguments?
For Companion, if you want to change the text or color of an item, you need to use /style/text/[PAGE]/[BUTTON] "New Text" or /style/bgcolor/[PAGE]/[BUTTON] 255 255 255
I need to be able to more dynamically update a button based on a variable. I have it set so when I click a button it stores that button's coords, then I have a pallette of colored buttons, so that when I click "Red", it colors the last button I pressed. But in order to do that, I need to use variables in the Path.

@estilles should I open a new issue for the above?

No need @spiderjjr45. I'll be adding it on the same PR.

Any updates on that feature?


DMR: Replicate DMR functionality with nginx

As an ARCHITECT
I WANT to have a version of DMR running on NGINX
SO that I can evaluate feature parity
Acceptance Criteria

[x] error code sent back in header when proxying fails
[x] demo solution to team

https://github.com/buerokratt/DMR-Nginx/pull/1


Texture frame with zero width/height

Hello, I was wondering what is the reason of considering a texture frame with zero width or height invalid, and not updating the UVs when such a frame is set.
https://github.com/pixijs/pixi.js/blob/873b65041bd3a5d173b0e0e10fa93be68bc033d9/packages/core/src/textures/Texture.js#L548
I've implemented a simple progress bar using this and occasionally when the progress immediately drops to zero the bar remains stuck in the previous state. Removing the width/height check seems to fix the problem for me, without causing any other issues.

Is there a reason you’re animating the Texture’s frame and not the Sprite’s scale/width?

Is there a reason you’re animating the Texture’s frame and not the Sprite’s scale/width?

I think he crops image without using masking, this it pretty cheap and easy way. BUT framw.width = 0 and frame.height = 0 is  inlegal state.

Yes I'm using the frame as a rectangular mask as it seemed like the easiest way. Also as I understand the usual mask approach would be more expensive and sprite's scale/width would stretch the image instead of masking/cropping.
There are probably a number of ways I could work around this for the purposes of a progress bar, so this more of a question regarding the zero width/height case in general.
The issue I'm having doesn't seem to affect any recent versions of PIXI, since I'm guessing invalid textures are not rendered (in my case they were rendered with outdated UVs), so really just a question for sanity of an old fork.

Wait, how actually does it stay in that state when do you change width later? Any ideas?

I've put together a minimal example
var renderer = new PIXI.WebGLRenderer(400, 400);
renderer.backgroundColor = 0;
document.body.appendChild(renderer.view);

const graphics = new PIXI.Graphics();
graphics.beginFill(0xffffffff);
graphics.drawRect(0, 0, 2, 2);
graphics.endFill();

const sprite = new PIXI.Sprite(renderer.generateTexture(graphics));
sprite.width = 200;
sprite.height = 50;
sprite.x = 200;
sprite.y = 200;
sprite.anchor.set(0.5);

const stage = new PIXI.Container();
stage.addChild(sprite);

renderer.render(stage);

const frame = sprite.texture.frame;
frame.width = 0;
sprite.texture.frame = frame;

renderer.render(stage);

Now that I have this, it seems like I lied, it does affect latest v4.
The project I'm working on is stuck with v4.4.4 though.
jsfiddle with v4.8.8

try calling sprite.texture._updateUvs(); after you set new frame width

if _updateUvs() helps, we can close this issue, because I'm certain that there wont be fix like that in v4.x  . We rewrote it in v5, if people want to get more comfortable, they can spend time moving app to new version.

Sure _updateUVs() helps, but I went with removing the width/height check instead, so I was expecting some scolding on that approach, if anyone has in mind what the check is for.
And yes, feel free to close if it's too much to fix in v4.


PMID:9755169 continued

decreased transcription during mitotic M phase

decreased transcription during mitosis FYPO:0006544
(with the usual synonyms)
edit file: d26618813367cdb5eb8ea7c72e4438b9125f4833
release: edd3546b44d2d90d034d2c5f642828a6774de4dc


Line Chart Missing

Hi All,
Was the line chart purposefully removed, or is this a bug that someone could try and help with?  I found it super useful!

Looks fixed now!


[WIP] Cluster call fix

This PR is a work in progress. It aims to remove the call to cluster made for a first level clusterwise analysis and replace it with python/nibabel functions.
This update was done in pair programming with @cmaumet.

As discussed by email, the voxel-space to subject-space transformation currently does not set up the origin. To do so, the code will have to be updated like in this snippet (from http://nipy.org/nibabel/coordinate_systems.html#applying-the-affine):
>>> import nibabel as nib
>>> import numpy as np
>>> import numpy.linalg as npla
>>> img = nib.load('filtered_func_data.nii.gz')
>>> voxToWorld = img.affine
>>> M = voxToWorld[:3, :3]
>>> abc = voxToWorld[:3, 3]
>>> M.dot([19, 40, 18]) + abc

where [19,40,18] are the voxel-space coordinates we want to transform.
(@TomMaullin: I've a slightly updated your comment above)

Hi @cmaumet ,
This PR has now been updated with the intercept fix you found. If the tests pass should we merge it or did you also want to address the peaks table in this PR?
(@cmaumet ah sorry yes! I should have put that)

Cool! We need to find a way to amend the tests so that they pass before we merge. What would you suggest? Note: can you first have a look at my comment above and see if this helps?

Sure I will address your above comment first thing tomorrow morning! Once this has been addressed, if the tests are still failing, the simplest fix to me would seem to be to either just manually change the coordinates in the ground truth file for the tests that are failing (e.g. change the coordinates here ), so long as we are agreed the errors are only caused by rounding errors and not something more serious, or replace the entire ground truth files with an updated version. I am happy to do either - replacing the whole file makes more sense to me but just changing the text might be a lot easier on my VM!

Maybe we can add the peak table in here as well since the piece of code we removed was also producing this file? How does this sound to you?

Ah right, I didn't realize we had deleted the piece of code that originally produced this file - where was it originally produced?

either just manually change the coordinates in the ground truth file for the tests that are failing (e.g. change the coordinates here ), so long as we are agreed the errors are only caused by rounding errors and not something more serious, or replace the entire ground truth files with an updated version. I am happy to do either - replacing the whole file makes more sense to me but just changing the text might be a lot easier on my VM!

+1 to modify only the coordinates. The ground truth files were generated semi-manually and replacing them completely could inadvertently introduce changes that we don't really want.

Ah okay, I didn't realize we had deleted the piece of code that originally produced this file - where was it originally produced?

The call to FSL's cluster (cf. here) was actually generating both the cluster and the peak table.

@TomMaullin: if you can rebase on master, some of the PEP8 issues above will disappear as thay have been addressed in #134.

If the tests still fail, +1 to modify only the coordinates. The ground truth files were generated semi-manually and replacing them completely could inadvertently introduce changes that we don't really want.

Ah okay, yes sure! I will do this and make a PR to nidmresults-examples!

The call to FSL's cluster (cf. here) was actually generating both the cluster and the peak table.

Ah right I see... so would the output for the voxel table in first level clusterwise analysis also only be in voxel space at the moment?

@TomMaullin: if you can rebase on master, some of the PEP8 issues above will disappear as thay have been addressed in #134.

Ah okay, yes sure. I have merged master but not rebased yet. I can't remember... when I rebase do we lose this conversation on the PR?

Hi @cmaumet ,
In regards to the currently missing peak mm table I am a little confused... the datapack fsl_full_examples001 is a first level clusterwise analysis, which is the use case we have edited here, and it's ground truth file clearly contains peak mm coordinates (see here for example).
However, following our edits here, in the Travis logs we are getting no errors saying that these coordinates are missing. If we have removed the only code that creates the peak subject space mm table, I am confused as to how the Travis tests haven't reported this error. Could it be that the voxel mm table should already exist anyway?

Ah okay, yes sure! I will do this and make a PR to nidmresults-examples!

Great! Can you make sure that we always have the same number of digits for the coordinates? Currently we have mixed numbers, e.g. [-56.35, -41.3, 16.45].

Ah right I see... so would the output for the voxel table in first level clusterwise analysis also only be in voxel space at the moment?

Yes exactly. Similarly to what we had for clusters, we have the peak table in standardised space and in voxel space but not in subject space: cf. https://github.com/incf-nidash/nidmresults-examples/tree/master/fsl_thr_clustfwep05.

Ah okay, yes sure. I have merged master but not rebased yet. I can't remember... when I rebase do we lose this conversation on the PR?

Okay, a merge is fine. We don't loose discussion when rebasing but the commits are modified so comments on the code (e.g. a code review) can be hidden. But not need to do this anymore since you already merged master in.

If we have removed the only code that creates the peak subject space mm table, I am confused as to how the Travis tests haven't reported this error. Could it be that the voxel mm table should already exist anyway?

Is it possible that you still have lmax_zstat1_sub.txt from a previous run of the tests? Can you check in test/data/nidmresults-examples/fsl_full_example001?

Great! Can you make sure that we always have the same number of digits for the coordinates? Currently we have mixed numbers, e.g. [-56.35, -41.3, 16.45].

Ah yes sure! I'll do this.

Is it possible that you still have lmax_zstat1_sub.txt from a previous run of the tests? Can you check in test/data/nidmresults-examples/fsl_full_example001?

This is happening on Travis, so there can't be a file from a previous run unless one has accidentally been included in the nidmresults-examples repository.

Actually, nevermind I have been able to get a Peak coordinate error locally... not sure why this isn't happening on Travis.

This is happening on Travis, so there can't be a file from a previous run unless one has accidentally been included in the nidmresults-examples repository.

It can also happen on Travis because to avoid downloading the data again and again, we are using a cache to save data from one run to the next (cf here]).

It can also happen on Travis because to avoid downloading the data again and again, we are using a cache to save data from one run to the next (cf. here).

Oh wow! I didn't realise you could do this - does this reduce the git lfs usage then?

Oh wow! I didn't realise you could do this - does this reduce the git lfs usage then?

Yes, exactly. In the first weeks we were using these test data on Travis CI we exploded our git-lfs quota just by submitting a couple of pull requests...

Yes, exactly. In the first weeks we were using these test data on Travis CI we exploded our git-lfs quota just by submitting a couple of pull requests...

Ah thank you! I didn't realize you could do this! I have the same problem with another repo!

Hi @cmaumet ,
I have updated the code to recreate the voxel table and I have updated the nidmresults-examples repository here. I think the tests now all pass (I tried on a clean setup) but I am still wary. Let me know if everything seems correct to you.

@TomMaullin: Thanks for all this! Can you update the .travis.yml to run against your updated branch of nidmresults-examples? See https://github.com/incf-nidash/nidmresults-fsl/blob/master/.travis.yml#L34 (you will also have to add a remote linked to your fork of nidmresults-examples).
This way we can check if the tests pass of Travis or not.

Hi @cmaumet ,
I am having some trouble updating the tests to use my local branch instead of the incf-nidash/master branch. I am unsure how the caching on the repo works... do my edits on the .travis.yml seem correct to you?

Hi @TomMaullin. That's a good start! You also need to set the NIDM_EX_BRANCH variable in https://github.com/incf-nidash/nidmresults-fsl/blob/master/.travis.yml#L11: NIDM_EX_BRANCH=CoordinateUpdate and to change origin into TomMaullin in https://github.com/TomMaullin/nidmresults-fsl/blob/510ea08d10fa65d183d7680d33bd2e8550c6c0bd/.travis.yml#L36 and https://github.com/TomMaullin/nidmresults-fsl/blob/510ea08d10fa65d183d7680d33bd2e8550c6c0bd/.travis.yml#L39. Best thing would be to create a new variable NIDM_EX_REMOTE and set it to TomMaullin (so that later on we can easily set it back to origin.
To give you a bit of context on this. When we started to use git-lfs, it was not super robust and we were often getting timeout errors. This means that we had to try and download the data multiple times before it finally worked. This is what the travis_retry git reset --hard origin/${NIDM_EX_BRANCH} are doing. We might be able to remove those but let's keep that for another PR. Let me know if that makes more sense.

Hi @cmaumet ,
Ah okay I see now yes! Thank you! The tests now pass - ready to merge when you are!

Cool! Now that we have confirmation that the tests pass, let's merge step-by-step:

Review and merge your PR updating the test data at: https://github.com/incf-nidash/nidmresults-examples/pull/105
Once this is done we can change again the .travis.yml in the current PR to run against master of nidmresults-examples.
Review and merge current PR.

This will ensure that we are in a stable state when we merge.

Okay, sure! I am unsure though, are you merging #105 on nidmresults-examples or am I?

I've just reviewed https://github.com/incf-nidash/nidmresults-examples/pull/105.

Hi @cmaumet , This PR has now been updated to work with the 3 significant figures in nidmresults-examples. After the PR on nidmresults-examples has been merged I am happy to merge this when you are!

Hi @TomMaullin! That's great! Thank you! I've just merged the companion PR: incf-nidash/nidmresults-examples#105.
Can you update the current .travis.yml to run against master of nidmresults-examples. Once this is done, let's wait for the tests to complete and happy to merge!

Hi @cmaumet ,
This has now been done and the tests pass! I shall now merge!


updateThingSpeakInterval doesn't function

For some reason changing this value doesn't seem to affect the update rate.
I think this is an issue of the version of the Ethernet library used.

Can you show me the complete line and what you are changing it to? Thanks.


Rename extension config

bors r+
🤖

Finally 😆.

Finally 😆.

@lnicola Should we post this change in "Anouncements: Client Changes" too ?

@lnicola Should we post this change in "Anouncements: Client Changes" too ?

@edwin0cheng not really -- this is vscode-specific, and we maintain that. That issue is primaraly for maintainers of other clients.

@edwin0cheng not really -- this is vscode-specific, and we maintain that. That issue is primaraly for maintainers of other clients.

There are still references to the old setting in docs/{dev/README.md,user/manual.adoc}

There are still references to the old setting in docs/{dev/README.md,user/manual.adoc}


Add logging instead of print

Description:

Problem:
We should have the same approach for logging as I did with fintwit-bot, so we can have an info mode and a debug mode. A debug mode is only used for the developers and the info mode is what the users should see.

Solution:
Replace all prints with logging.info and add a few logging.debug for VRAM, RAM use etc.

Prerequisites:
None

Tasks:

Add logging

Additional context
Add any other context or screenshots about the feature request here.

The logging should also keep track of pc stats like:

Used RAM and VRAM

https://stackoverflow.com/questions/938733/total-memory-used-by-python-process

Maybe also show the loading progress of the fasttext model, as that takes the longest


Feature: Limit downloading to certain file extensions with pattern

A nice option would be to restrict the downloading (but not the visiting) of content with a certain extension. For example, running suckit <url> --extensions "mp[3-4]" would only download MP3 and MP4 files using a regex

Hey @CohenArthur I'd like to work on this!

Sure ! Thanks a lot @creativcoder

@creativcoder I think it would be nice to also add a form of "exclusion" to exclude some file types, using a regex as well. We can open a separate issue or you can work on it as well if you want

Exclude as in not visit the links? Sure, will add that as well!

As in visit the links to find more links, but do not download the files