luke-jr

diff --git a/chrome/browser/ui/views/page_info/page_info_view_factory.cc b/chrome/browser/ui/views/page_info/page_info_view_factory.cc
index 7fb6575d7f..d85d189a8c 100644
--- a/chrome/browser/ui/views/page_info/page_info_view_factory.cc
+++ b/chrome/browser/ui/views/page_info/page_info_view_factory.cc
@@ -294,6 +294,7 @@ const ui::ImageModel PageInfoViewFactory::GetPermissionIcon(
       break;
     case ContentSettingsType::JAVASCRIPT:
     case ContentSettingsType::JAVASCRIPT_JIT:
+    case ContentSettingsType::JAVASCRIPT_OPTIMIZER:
       icon = show_blocked_badge ? &vector_icons::kCodeOffChromeRefreshIcon

luke-jr

diff --git a/chrome/browser/ui/views/page_info/page_info_view_factory.cc b/chrome/browser/ui/views/page_info/page_info_view_factory.cc
index 8870181e11..38bb8e5508 100644
--- a/chrome/browser/ui/views/page_info/page_info_view_factory.cc
+++ b/chrome/browser/ui/views/page_info/page_info_view_factory.cc
@@ -278,6 +278,7 @@ const ui::ImageModel PageInfoViewFactory::GetPermissionIcon(
                                 : &vector_icons::kPhotoChromeRefreshIcon;
       break;
     case ContentSettingsType::JAVASCRIPT:
+    case ContentSettingsType::JAVASCRIPT_JIT:
       icon = show_blocked_badge ? &vector_icons::kCodeOffChromeRefreshIcon

luke-jr

diff --git a/chrome/app/chromium_strings.grd b/chrome/app/chromium_strings.grd
index 62900c285f..d2609cbd12 100644
--- a/chrome/app/chromium_strings.grd
+++ b/chrome/app/chromium_strings.grd
@@ -2290,6 +2290,12 @@ Permissions you've already given to websites and apps may apply to this account.
       <message name="IDS_SETTINGS_SITE_SETTINGS_JAVASCRIPT_OPTIMIZER_ALLOWED_SUB_LABEL" desc="Sub-label for the enabled option of the JavaScript optimizer content setting.">
         Chromium runs faster and features that use JavaScript should work as designed (recommended)
       </message>
+      <message name="IDS_SETTINGS_SITE_SETTINGS_JAVASCRIPT_JIT_DESCRIPTION" desc="Description of the JavaScript JIT content setting.">
+        V8 is Chromium’s JavaScript and WebAssembly engine used to improve site performance

luke-jr

--- a/src/script/interpreter.cpp
+++ b/src/script/interpreter.cpp
@@ -504,6 +504,14 @@ bool EvalScript(std::vector<std::vector<unsigned char> >& stack, const CScript&
                     return set_error(serror, SCRIPT_ERR_MINIMALDATA);
                 }
                 stack.push_back(vchPushValue);
+                if ((flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) && opcode == OP_FALSE) {
+                    auto pc_tmp = pc;
+                    opcodetype next_opcode;
+                    valtype dummy_data;

luke-jr

diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
index d82e596e60e..396c18c5bf8 100644
--- a/src/rpc/blockchain.cpp
+++ b/src/rpc/blockchain.cpp
@@ -1416,6 +1416,11 @@ static RPCHelpMan gettxspendingprevout()
                     },
                 },
             },
+            {"options", RPCArg::Type::OBJ, RPCArg::Optional::OMITTED_NAMED_ARG, "",
+                {

luke-jr

diff --git a/configure.ac b/configure.ac
index f969e707293..1c33cbc3a38 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1372,14 +1372,24 @@ if test x$build_bitcoin_cli$build_bitcoind$bitcoin_enable_qt$use_tests$use_bench
   if test x$TARGET_OS != xwindows; then
     PKG_CHECK_MODULES([EVENT_PTHREADS], [libevent_pthreads >= 2.0.21],, [AC_MSG_ERROR([libevent_pthreads version 2.0.21 or greater not found.])])
   fi
-fi
 

luke-jr

With v22.0, we changed a few parts referencing a number of gigabytes, with the assumption that anything referring to "0 GB", "1 GB", "2 GB", "10 GB", "1000 GB", and so on are always translated the same in every language. Specifically, the strings affected at this time are "%n GB of free space available", "(of %n GB needed)", and "(%n GB needed for full chain)"

Reviewing actual translations prior to the change, however, it appears that may not be the case. In some languages, "1 GB" was preferred to use a non-digit number (eg, "one", "un", or such), and others appear to use different words around the amount. Not being familiar with any of these languages, I am not sure if these were intentional differences, or translator mistakes.

Please contact me if you are aware of any language(s) that would benefit from being able to translate these or similar messages differently based on the number of GB referenced. Even if there is an inferior "count-neutral" translation possible, if being able to have it count-specifi

luke-jr

With v22.0, we changed a few parts referencing a number of gigabytes, with the assumption that anything referring to "0 GB", "1 GB", "2 GB", "10 GB", "1000 GB", and so on are always translated the same in every language. Specifically, the strings affected at this time are "%n GB of free space available", "(of %n GB needed)", and "(%n GB needed for full chain)"

Reviewing actual translations prior to the change, however, it appears that may not be the case. In some languages, "1 GB" was preferred to use a non-digit number (eg, "one", "un", or such), and others appear to use different words around the amount. Not being familiar with any of these languages, I am not sure if these were intentional differences, or translator mistakes.

Please contact me if you are aware of any language(s) that would benefit from being able to translate these or similar messages differently based on the number of GB referenced. Even if there is an inferior "count-neutral" translation possible, if being able to have it count-specifi

luke-jr

[bitcoin-dev] Making soft forks pluggable
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011487.html

[Friday, October 09, 2015] [8:50:48 AM] <Luke-Jr>	CodeShark: btw, I was thinking of the softfork plugin thing a bit ago also, so sounds good to me :P
[Friday, October 09, 2015] [8:50:57 AM] <CodeShark>	:)
[Friday, October 09, 2015] [8:51:14 AM] <Luke-Jr>	maybe harder than it seems though in practice
[Friday, October 09, 2015] [8:52:04 AM] <CodeShark>	I have some ideas for how to do it...but if we're going to be doing a bunch of refactors after 0.12 is released, I figure this is a good area on which to focus :)
[Friday, October 09, 2015] [8:53:24 AM] <CodeShark>	we don't want to have to backport each individual soft fork perpetually...and it might actually be easier to backport the plugin thing
[Friday, October 09, 2015] [8:53:57 AM] <aj>	be easier to backport pluggable soft forks once the plugin thing exists too, presumably
[Friday, October 09, 2015] [8:54:14 AM] <CodeShark>	yes, of 

luke-jr

import sys

sizes = []
count = 0

for line in sys.stdin:
	fields = line.split()
	tx_count = int(fields[3])
	if tx_count < 16:
		continue