Safely generating L2 blocks based purely on L1 blockdata

// see also discussion here*
Current State of L2s
In general, the nature of a rollup is such that the L2 state can be entirely defined by the L1 blocks.  That is, all possible L2s can be expressed by state transitions taking the form f(old_l2_state, new_l1_block) -> new_l2_state.
In reality, most (all?) rollups today do not act on raw blockdata, but instead use an L1 smart contract to store a hash of the calldata sent to a system contract during L1 block execution. This function lived in OVM_CanonicalTransactionChain for our v1, for example. Here's where Arbitrum does it as well.
The Ideal
Our goal of EVM equivalence should make the idea of acting on raw L1 block data more feasible. In reality, a committment to input calldata is already stored within the L1 blockhash itself, and we could use this as the verification source during the fraud proof.  This has been proposed by @lightclient and others. It would give us optimal gas costs, and also set us up for ETH2p1, in which the place that calldata is submitted to will not have any smart contract capabilities.
Problem Statement
The above post proves that it's feasible to give the L2 virtual machine access to some get_l1_blockhash(number) function.  However, it does not tell us how we can safely use it. Geohot has proposed one way to use this blockhash in a very generalized form: give the L2 VM a function, effectively a "get_known_preimage(bytes32 hash)", which allows it to recover the preimage of a hash into memory. The L2 VM could use this to unpack the block body from the block hash, then unpack the transaction root's children from that, and so on, until it unpacks the relevant transaction data itself.
However, there is a problem: the preimages, even if known off-chain, may be too big to do any verification on-chain.  For example, imagine that a block gaslimit was entirely filled with a massive, single transaction (identified by txhash) to a dummy account.  It should be clear that there is no way to verify the get_known_preimage(txhash) step on-chain, because there's not enough gas. How should we deal with this?
Solution 1: Upper bound on preimage sizes
The most obvious solution to this is just to enforce a maximum preimage size that can be successfully loaded into memory by the L2 VM.  This would mean that get_known_preimage returns null_bytes32 if the real preimage.length > UPPER_BOUND.
To detect this on-chain, an honest party would just allow their challenger to run out of time on the dispute game because it is impossible to prove anything else. This is the easiest to implement, but it has the downside that the fraud proofs can no longer validate arbitrary L1 blocks -- only those below some size constraint.
Solution 2: Secondary game on preimage chunks
The keccak algorithm itself can be broken down into smaller individual steps which each ingest a word of the input into a constant-sized state.  So another solution is to have the two parties submit the preimage they claim is correct in smaller chunks as calldata.  Once all are submitted, then they can play a bisection game on the hash substeps to prove that their preimage will result in the requested hash.  This adds complexity, but does allow us to validate arbitrary L1 blocks in their entirety.

@ben-chain dope writeup!
Is there a really simple way to explain why the keccak in Solution 2 has to be a sub-game as opposed to being a part of the normal execution trace? I just don't feel like I have really good intuitions there. Here's my best shot:
It is because of what @protolambda calls "state poisoning" - this happens when state is loaded into the machine without the ability to disprove its validity. The reason why you cannot disprove the first chunk's state access is because the validity of that state access is actually dependent on the final hash that is computed. Then you can retroactively say "that was an invalid chunk".
The part of this that I feel hazy about is whether it is helpful to determine where you disagree in the hash chunking process, and then afterwards post all the data.
Random ideas

Like can you figure out "Hey you and I disagree about chunk #3" and we can do that in the main dispute game. And then afterwards we create a very small sub-game where you execute a single chunk.
Or maybe you write the VM in such a way that any input can be supplied but then the VM actually goes back and checks it's own state afterwards. Like you prove the L1 BLOCKHASH (this is trusted state), and then you load in a bunch of untrusted state into the VM, and then afterwards the VM itself verifies the untrusted state against the trusted state and panics if it doesn't match up. I guess that means you can find a disagreement in VM execution but that disagreement is not provable directly which complicates the game. And I guess it could be the case that this concept of "untrusted" and "trusted" state is exactly why you want the subgame in the first place. You need deterministic execution to find your first provable disagreement, but then you drop into this sub game and by rolling up all of the chunks you make the computation provable. Ok yeah I see why you need to roll it up. Freaking creating a rollup in a rollup to dispute a super large preimage is insane but definitely does make sense and I do think we should do it. It's really quite a confusing concept but a 🔥 idea. It's super important that we're not limited by calldata size.

@ben-chain can we write this in a way such that it is non-interactive? IMO that would simplify it conceptually a lot. Non-interactive but expensive.

It is because of what @protolambda calls "state poisoning" - this happens when state is loaded into the machine without the ability to disprove its validity.

This is the right intuition, yes.  The problem with trying to "find out where you disagree" is that an attacker will always try to disagree at the first chunk, devolving the game into rolling up the entire thing.

It's super important that we're not limited by calldata size.

@karlfloersch this statement isn't obviously true to me, but perhaps I'm missing something?
I can't think of many on-chain applications that in practice would depend on being able to receive 30MM gas worth of call data. Until recently they were all making do with more like 13MM on L1 anyways.
IMO, implementing an on-chain sponge function (as fun as it sounds!) is a major endeavour in itself, if it is essential to the mission of creating an EVM equivalent ORU then we must do it. But if it results in something like a 20% to 30% increase in maximum TxData size, I'm less certain of it's value.

this statement isn't obviously true to me, but perhaps I'm missing something?

It's less about the feature and more about protocol complexity. We have the choice of highly encapsulated complexity (implement a pre-image verifier for any size preimage) vs leaky complexity across multiple parts of our protocol. We need to add logic in Geth to reject txs over a specific size, make preimage oracle to return nil for large preimages, and add a special step in our dispute game to handle resolutions which timeout. Our last codebase we suffered death by 1,000 cut corners that bloated protocol complexity beyond belief.
Some other places where I'm afraid of complexity popping up:

It becomes difficult to detect whether a deposit can actually be processed by the L2. Ben mentioned this before but you basically emit an enormous amount of zero bytes as an event and then deposit. If the receipt becomes too large then the fraud proof will skip the deposit but the contract has no way to know that it was skipped, so we gotta add some extra logic into our deposit watcher. This also might have other downstream effects.
It is the only fraud proof step where a timeout actually produces a value. That means that theoretically you could have a preimage that is small, let the game timeout, and then it'll be "validly" interpreted as nil. This is a weird property and may be able to be used in tricky ways.

TLDR: 1) I agree that supporting large txs is not a feature that users are clamoring for; however 2) using this timeout approach while it seems simple I think it actually introduces gnarly complexity.

Okay thanks for humoring me again on the call. I think I understand the interactive game over the commitment chain now. So if my understanding is correct, I can cause an otherwise valid chain to rollback at any point during the fraud proof period:
Suppose I submit the rollup transition A -> B with some input I. This is unequivocally a valid transition. At some later point, I initialize a fraud proof. I claim A -> B occurred with input I' and I attest to a sequence computation C that  shows I' is input. Of course this is impossible because I is actually the input. However, if I in my proposer role agree with challenger me that C proves I' is the input, then the transition A -> B is fraud proved in the context of I'. This would almost certainly cause a rollback to A.
It seems likely that this could be used to double spend since most people won't wait for rollup finality, only L1 finality.

Ah I forgot that each interaction needs to disputable. I think in that case my example doesn't work, because one honest party could dispute my fraudulent fraud proof.

It becomes difficult to detect whether a deposit can actually be processed by the L2. Ben mentioned this before but you basically emit an enormous amount of zero bytes as an event and then deposit. If the receipt becomes too large then the fraud proof will skip the deposit but the contract has no way to know that it was skipped, so we gotta add some extra logic into our deposit watcher. This also might have other downstream effects.

Yep, IMO this is the worst part of the complexity -- I think fundamentally this forces us to choose between:

Having two L1->L2 pathways:

a trustedReceiptEnqueue which must only be called when users know the transaction receipt will be bounded in size (i.e. no arbitrary events are possible from untrusted contracts)
an untrustedStoreEnqueue which does 2 SSTORES (one to bump a nonce, another to store hash(messageData)) and a standalone preimage indexer which allows us to call getPreimage(messageHash)

Losing the efficiency and always requiring 2 SSTOREs per L1->L2 message.

With unlimited preimage sizes, you might also imagine a world in which L2 contracts can pay to "subscribe" to all L1 events of a given address/topic. I think this is fundamentally impossible without that.

This decision changes the implementation of the deposit feed. If we can load large preimages, then the deposit feed is a contract which just emits events. If we cannot load large preimages, then the deposit feed much enforce the size of the deposit data is small and store the hash of the deposit.

Trying to reformulate the whole thing, and adding some new insights at the end, based on semi-recent team conversations, but adding a new way to operationalize it that is all new.

In the new design, we run the fraud proof on a run of Geth that validates an epoch worth of blocks. The fraud proof consists of a dispute game where both parties converge on a single step whose execution they disagree on. At this stage, it is necessary to seed the preimage oracle with the preimages of any data accessed by the contested instruction. These data could be:

Geth program data, proved against a merkleized execution state.
L1 header properties, proven against a L1 block hash
a deposit, proven against the receipt hash (itself proven against a L1 block hash)

We would compile Geth to MIPS (or some similar minimal instruction set). Above, (1) is a MIPS instruction, while (2) and (3) map to "special" instructions (the "preimage oracle") to access the fraud proof program's input (data in some L1 block).
The trouble is case (3), because an entry in the receipt trie comprises all log entries for the transaction. A contract that submits a deposit could first emit a huge log filled with 0, which would exceed what can be held in a block's worth of calldata.
(Side note, we can't store deposits in calldata because we want to let contracts submit deposits, and only EOA can produce "top-level" transactions.)
As Karl says just above, a possibility is simply to check the size of deposits and store their hash.
The other option is to somehow enable to submit the proven receipt trie entry in multiple stages. This is what all the talk about decomposing the hash function is about.
The good news (and this is the new insight) is that this could be fairly easy.
Instead of having a "special instruction" that fetches the deposit directly, we could implement the proving logic for the deposit in our modified Geth directly and instead the special instructions are used to fetch the pre-seeded proof inputs (i.e. the multiple chunks of the receipt entry + the rest of the merkle proof + the deposit being proven).
Keccak is most definitely a hash function where the input can be supplied incrementally. So we would first compute the hash of the entry (after verifying it contains the deposit), then proceed to validate the rest of the fraud proof.
Because of the magic of the dispute game, we won't actually need to perform most of these steps. In fact, at worst, both parties will be forced to disagree on a single chunk of the receipt entry.
And we will be able to reuse a Go implementation of Keccak instead of implementing it onchain (though it must be said, it's surpisingly not quite that bad).

The problem is not the computation, but the authentication, of input data. There is no way to proof the input to the hash-function is correct unless you can verify it against the output in the same step of the dispute. Rollups work because the inputs are all already authenticated: the hash function incrementally computes the output over trusted memory. But when loading new pre-images, the input is not authenticated, and has to be consumed in one go to establish that it's the correct input to use. See "state-poisoning" for earlier thoughts on this.
To solve the computation you can indeed do a rollup-like multi-step computation of the keccak hash, and dispute steps in-between, but the problem is that the input data itself is never authenticated. Determining the contents of the very first step, when you only have the final output hash to trust the input, is not possible.
You could try reverse the execution of the steps, by presenting the last chunk of data and checking it matches the output when combined with the internal hashing state, and then working your way back all the chunks. But that's not secure in this case, since keccak is not following a Merkle–Damgård construction like sha256.

Running all the computation on-chain works, but it's very costly (a full L1 block or more!), so let's consider the alternatives as well.

One other approach is to do a fraud-proof over the thing that generated the large pre-image (L1 execution) at the same time (execute the L1 source block before executing the derived L2 block(s)). Then keep the receipt (or whatever large input) in the authenticated memory, to avoid using the pre-image oracle for it later.
The pros:

Arbitrary large receipt data can be consumed
Can work for any L1 data, not just receipts
Introspection in L1 EVM is possible, if we ever need something more advanced than a receipt

The cons:

The fraud-proof will have to be updated whenever the L1 EVM updates

Or another alternative is to merkleize receipts in some better way on L1, and see if it can be adopted during the Merge (transactions are already going to be merkleized nicely, and will be accessible through a binary merkle proof via the beacon-block hash-tree-root)

Been thinking about this over the weekend, finally took the time to write it out. I think this works, but I'd appreciate a review in case I missed something.
The Issue
When executing the single execution step during a fault proof, it is necessary to prove the input to the execution step. This could include:

Part of a transaction from a sequencer block (posted by the sequencer as batch calldata).
Part of transaction from a deposit block (emitted as an event by the deposit contract).
Part of the EVM state (e.g. balances, storage slots).
Part of the fault proof program state (i.e. program memory).

The problem occurs in (2): all log entries generated by a transaction are concatenated before being hashed for inclusion in the receipts Merkle tree. A malicious actor could emit huge log entries before making a deposit, hence resulting in a hash pre-image that is too large to post on-chain as calldata.
See here for some numbers, a byte of log data costs 8 gas, meaning it could result in ~3.75MB of data. Assuming none of these bytes are 0, this would take two full blocks worth of calldata to post on chain. This is much too large/expensive.
Note that this problem does not occur in (1), since we can limit the batch size at the protocol level (define larger batches as invalid), nor in (3) as slots are only 256 bits, nor in (4) as we are free to define how we Merkleize program state.
The Nice Solution
First, we can prove the hash of receipt Merkle tree entry using the usual Merkle proof mechanism but cut short to not prove the data, but only its hash.
The problem is then: how to prove a chunk of the hashed input without posting the whole input on-chain.
The Keccak (SHA-3) hashing algorithm can be decomposed as the repeated application of a function (let's call it f) over the constant-size internal state and a chunk of input.
Let's call the input (the receipt entry) I and let's slice it into blocks whose size is a multiple of the SHA-3 block size (1088 bits): I0, I1, ..., In (we'll probably need to allow the last block to be up to twice as big and run f twice for it).
Then the hash can be represented by:
I -[SHA3]-> H

(i.e. SHA3(I) = H), or by:
S0 -[f]-> S1 -[f]-> ... Sn -[f]-> H
I0 /      I1 /          In /

i.e. f(S0, I0) = S1 (etc) where S1, ..., Sn are the intermediate internal states of SHA3 and S0 is the initial state.
The two participants they can post all intermediate states they think leads to the hash. If they agree, any single chunk of input Ix can be proven by verifying f(Sx, Ix) == Ix+1 on chain.
"All internal states" might be too big in practice, but they can post a commitment to them instead. Then, they can play a bisection game on this commitment to find the last intermediate state they agree on.
If the participants disagree on some intermediate state, we take Sy the last intermediate state they agree in (or H if they don't agree on Sn). Then both participants have to provide Sy-1 and Iy-1 such that f(Sy-1, Iy-1) == Sy can be verified  by running f on chain.
If f has preimage resistance (which I think is the case but we should get a cryptography expert to look over this), then there is no way for the participants to find different values of Sy-1 that satisfy the equation, hence one of the two parties must fail the check (or fail to answer) and be slashed as a result.

@norswap Regarding the nice solution, splitting up the hash function: Some hash-functions have this feature natively:  Merkle–Damgård construction.
Unfortunately I don't believe SHA-3 is one of those (iirc @ben-chain asked a friend to confirm when we discussed this option in November)

Yes, it uses the sponge construction. Reading about it right now, it seems clear it's not a simple repeated application of a function, but it almost is (the key difference is that there are two functions, one for the "absorption phase" and one for the "squeeze out phase", where the squeeze function does not take further input and does not xor).
It's not quite clear to me that the proposed scheme can't work. In fact, I'd say it has to work, but the concern is the degree of attack resistance: i.e. if you can reverse/find collisions for every step (function application), then you can find a collision for the whole hash, which is obviously not possible at present. But maybe it is too expensive to find a full hash collision, but cheap enough to find a collision for a single step.

Unlike other rollup execution (repeated function application), this is not on top of prior authenticated data. We only have the output, and repeat the steps by showing the supposed pre-state and applying the function to see if it matches the output we already authenticated.
Finding collisions on an intermediate input can be a lot easier, depending on the hash function design. Since part of the security of the full hashing may be derived from the output being unique to a certain starting state of the hash function, which we don't have to show if we only present a collision for an intermediate step that connects with the expected output.

Yup, that's exactly what I meant! Remains to figure out what the actual security here is.

Okay, so I spent some time thinking about this, and I've convinced myself it isn't possible.
The reason is actually pretty interesting. Turns out what I called f (warning: it's not what the litterature calls f) is reversible. This is actually great: if you agree on a suffit of all internal states, you can always prove the input that you disagree upon. The problem is that if you don't agree on the last internal state, you cannot retrieve (or even commit to) that state from the hash, as it is essentially truncated from it (and so finding collisions is trivial).


Chore/merge master

关联的Issues (Related Issues)

close
改动 (Proposed Changes)

附注 (Additional Info)

自查清单 (Checklist)
在你认为本 PR 满足被审阅的标准之前，需要确保 / Before you mark the PR ready for review, please make sure that:

[ ] 符合Venus项目管理规范中关于PR的相关标准 / The PR follows the PR standards set out in the Venus project management guidelines
[ ] 具有清晰明确的commit message / All commits have a clear commit message.
[ ] 包含相关的的测试用例或者不需要新增测试用例 / This PR has tests for new functionality or change in behaviour or not need to add new tests.
[ ] 包含相关的的指南以及文档或者不需要新增文档 / This PR has updated usage guidelines and documentation or not need
[ ] 通过必要的检查项 / All checks are green

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/v1.9.0-pre-rc1@a884651). Click here to learn what that means.
The diff coverage is n/a.

Additional details and impacted files

@@                    Coverage Diff                    @@
##             release/v1.9.0-pre-rc1     #289   +/-   ##
=========================================================
  Coverage                          ?   54.45%
=========================================================
  Files                             ?       69
  Lines                             ?     7055
  Branches                          ?        0
=========================================================
  Hits                              ?     3842
  Misses                            ?     2912
  Partials                          ?      301

Flag
Coverage Δ

unittests
54.45% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.


Can't find module within modulesDirectories

webpack config:
resolve: {
    modulesDirectories: [
      "package_modules",
      "/path/to/app",
      "node_modules"
    ],
]

Option resolve.root is not defined.
Files tree:
/app
|- lib
|   \- index.js
|
\- my_package
      |- package_modules
      |     \- lib
      |          \- index.js
      |
      |- subfolder
      |     \- file_in_subfolder.js
      |
      \ - file_in_package.js

lib/index:
export const foo = "foo";
my_package/package_modules/lib/index:
export const bar = "bar";
my_package/file_in_package:
import * as obj from "lib";
console.log("lib in package root:", obj);

my_package/subfolder/file_in_subfolder:
import * as obj from "lib";
console.log("lib in package subfolder:", obj);

In console I have:
> lib in package root: { bar: "bar" }
> lib in package subfolder: { foo: "foo" }

Is it correct? I expected that it will be { bar: "bar" } in both cases.
Changing import path to lib/index does not help.

It is correct.

So it works not exactly like node_modules does? I can't understand the logic.

modulesDirectories should not contain absolute paths. /path/to/app is wrong inside of moduleDirectories. /path/to/app should be inside of resolve.root or resolve.fallback.

Ok, got it.
My idea was to achieve following resolution order: modulesDirectories => app root => node_modules (to ensure that node_modules never overrides local app modules). It seems that the most correct solution will be to create one more package_modules folder at app root.

It seems that the most correct solution will be to create one more package_modules folder at app root.

yep, that's the best solution with webpack 1.
with webpack 2 modulesDirectories root and fallback were merged into modules:
    modules: [
      "package_modules",
      "/path/to/app",
      "node_modules"
    ]

Wow :+1:
From this moment I'm waiting for stable webpack 2 release  much more)

Playing with webpack 2 (2.1.0-beta.4), I implemented files structure as in topic and modules config as you described above. It works brilliant.
Then, I renamed lib folder to constants folder everywhere in my files tree.
And my build crashed with this:
ERROR in ./~/constants-browserify/constants.json
Module parse failed: /path/to/project/node_modules/constants-browserify/constants.json Unexpected token (2:12)
You may need an appropriate loader to handle this file type.
| {
|   "O_RDONLY": 0,
|   "O_WRONLY": 1,
|   "O_RDWR": 2,
 @ ./src/index.js 5:17-37

After some debugging, I found the rule: everything from node_modules with -browserify suffix takes precedence before local modules. Other node_modules – no, I tried several. -browserify ones – yes.
Please explain what's going on here.

Actually, same happens even with the most simple configuration.
/
|- src
|  |- index.js
|  \- constants.js
\- webpack.config.js

src/index.js:
console.log(require("constants"));

src/constants.js:
module.exports = { foo: "foo" };

webpack.config.js:
module.exports = {
	entry: "index.js",

	output: {
		filename: "build.js"
	},

	resolve: {
		modules: [
			__dirname + "/src"
		]
	}
};

node_modules are not included to resolve.modules at all. And still build fails with
ERROR in ./~/constants-browserify/constants.json
Module parse failed: /path/to/app/node_modules/constants-browserify/constants.json Unexpected token (2:12)
You may need an appropriate loader to handle this file type.
| {
|   "O_RDONLY": 0,
|   "O_WRONLY": 1,
|   "O_RDWR": 2,
 @ ./src/index.js 1:12-32

add the json-loader

How json-loader will prevent bundling external package constants-browserify instead of my own module constants.js?

constants-browserify is is trying to load /path/to/app/node_modules/constants-browserify/constants.json... And webpack doesn't understand that until you have the right loader for that file type (.json)... Just as if something was trying to load a *.lessor *.jpg file
That is not related to the first problem you posted. So I suggest installing json-loader to get past this

@eisisig @sokra Once again: in this example webpack is configured to search for modules only in /path/to/app/src, and node_modules are not included at all. So require("constants") in app module must resolve to /path/to/app/src/constants.js, isn't it?
And, anyway, I don't require constants-browserify in my code, I require just constants – why name
constants-browserify considered matching this request?

That is not related to the first problem you posted

Should I post this as separate issue?

@jeron-diovis I have encountered exactly the same problem. It's weird that webpack tries to import node_modules/constants-browserify/constants.json and not my local constants/index.js. When i change folder name from constants to whatever, it works as it should be. Did you perhaps solve your problem?

@sqal Nope, I have no idea what to do with this except of, yes, renaming the folder.
As I noticed above, it's reproducible not only for constants, but for all whatever-browserify modules.
So I'm just still waiting while @sokra come and explain us what's going on.

Can you try against current webpack 2 rc? It handles JSON now.

@bebraw same issue here with<EMAIL_ADDRESS>

@valerybugakov Any chance for a repository to study to confirm the issue?

I can create one later today. But maybe you know a way to ignore this module in the client code?

@valerybugakov Ok. There are things like module.noParse, but I would need to see some code to say more.

@bebraw Short version of what I have right now:
import { ENTITIES } from 'constants';

it's transpiled into
var _constants = __webpack_require__("./node_modules/constants-browserify/constants.json");

And webpack config:
// some imports and env stuff here...

module.exports = {
  stats,
  devServer: {
    stats,
    hotOnly: true,
    contentBase: path.join(__dirname, 'dev')
  },

  devtool: dev ? 'eval' : false,

  entry: [
    path.join(__dirname, '../index.web.js')
  ],

  output: {
    filename: 'bundle.js'
  },

  module: {
    rules: [
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: [
          path.resolve(__dirname, '../src'),
          path.resolve(__dirname, '../node_modules/react-native-vector-icons'),
          path.resolve(__dirname, '../node_modules/react-native-drawer'),
          path.resolve(__dirname, '../node_modules/react-native-popup-dialog'),
          path.resolve(__dirname, '../node_modules/react-native-modalbox'),
          path.resolve(__dirname, '../node_modules/react-native-flip-card'),
          path.resolve(__dirname, '../node_modules/react-native-snap-carousel'),
        ],
        options: { cacheDirectory: true },
      },
      {
        test: /\.(gif|jpe?g|png|svg|tff)$/,
        loader: 'url-loader',
        options: { name: '[name].[hash:16].[ext]' }
      },
      {
        test: /\.ttf$/,
        loader: 'file-loader', // or directly file-loader
        include: [
          path.resolve(__dirname, '../node_modules/react-native-vector-icons'),
          path.resolve(__dirname, '../src/assets/icons'),
        ]
      },
      {
        test: /\.worker.js$/,
        loader: 'worker-loader',
        options: { inline: true }
      },
      {
        test: /\.glsl$/,
        loader: 'shader-loader'
      },
    ],
  },

  resolve: {
    extensions: ['.js', '.web.js'],
    alias: {
      'react-native': 'react-native-web',
    },
    modules: [
      path.resolve(__dirname, '../src'),
      path.resolve(__dirname, '../node_modules'),
    ],
  },

  plugins,
};

  module: {
    noParse: /constants-browserify/,
  },

Didn't help :(
Got same the transpilation result.

@valerybugakov Why import { ENTITIES } from 'constants'; instead of import ENTITIES from 'constants'; or import * as ENTITIES from 'constants';?

@bebraw actually there're more destructured variables import { ENTITIES, STICKY_CATEGORIES, ... } from 'constants';

@valerybugakov Ok, basically this feels like a JSON and ES6 module syntax specific problem. Could you open a separate issue with a little example we can run? You can also try the old require syntax to confirm. Perhaps some handling is missing.

@bebraw Ok, let me try require.

@bebraw no, same result:
const constants = require('constants')
// transpiled into
var constants = __webpack_require__("./node_modules/constants-browserify/constants.json");

@valerybugakov Ah... I understand better now. You basically want to inline the result (var constants = { ENTITIES: ..., STICKY_CATEGORIES: ... }), right? Importing might not be the way then. Look up solutions like DefinePlugin. You could perform a literal replacement like that through them.

Lol, I found a workaround, but will open an issue with example later.
    alias: {
      'react-native': 'react-native-web',
      'constants': path.resolve(__dirname, '../src/constants'),
    },

@bebraw I think DefinePlugin has a little bit different purpose, I use it to define environment variables. In constants.js I have lots of string/array exports (similar to Redux action types).
export const ENTITIES = ['some', 'entities', 'here', ...]
export const STICKY_CATEGORIES = [...]

@valerybugakov Yeah, DefinePlugin would be sketchier for sure. Reading back, maybe import { ... } from 'constants'; should have been import { ... } from 'browserify-constants';, but I'l know more after you open that issue.

@bebraw yeah, will do that. Thanks for helping out :)

@bebraw done

What is the status of this issue?
Is this a final recommended solution?


Search partially works

I'm submitting a ...

[x] bug report
[ ] feature request
[ ] support request

General infomration
Prerequisites

[x] Are you running the latest version?

Description
Search for certain strings not possible
Steps to Reproduce

go to search
enter "life"
get an error msg

Expected behavior: list movies that match the entered string
Actual behavior: nothing but an exception
Context (Environment)
Installation

[ ] I installed the plugin via zip from the Releases page
[x] I´m using the Netflix Repo
[ ] I´m using a different source (Please tell which)

Operating System

[ ] Linux (x86/x64)
[ ] OSX (x86/x64)
[x] Windows (x86/x64)
[x] Linux (ARM)
[ ] Android

Additional informatin on the environment
For ARM: LibreELEC
For Windows official Kodi installation
Debug log
http://sprunge.us/nzgdlw

Funny adding a useless space: "life " does work

First of all: I do not have any knowledge of python but:
According to the stacktrace the problem encounters in: resources/lib/KodiHelper.py starting at Line 440
            if video['type'] == 'movie':                 # it´s a movie, so we need no subfolder & a route to play it                 isFolder = False                 maturity = video.get('maturity', {}).get('level', 999)                 needs_pin = (True, False)[**int()** >= 100]                 url = build_url({                     'action': 'play_video',                     'video_id': video_list_id,                     'infoLabels': infos,                     'pin': needs_pin})                 view = VIEW_MOVIE                 content = CONTENT_MOVIE             else:                 # it´s a show, so we need a subfolder & route (for seasons)                 isFolder = True                 params = {                     'action': actions[video['type']],                     'show_id': video_list_id                 }                 params['pin'] = (True, False)[**int(video.get('maturity', {}).get('level', 1001))** >= 1000]
The first marked code snippet seems to me that there is missing something like int(maturity)
and the second snippet is the statement which caused my stacktrace

Sorry Duplicate: https://github.com/asciidisco/plugin.video.netflix/issues/365
I will have a look at 0.14


Feature/resource manager

Fix #3708

Hi Everyone - This PR is coming from DNN Corp. We are open sourcing a new module to be used in the DNN Platform named Resource Manager. This module has a modern way to manage folder and files in DNN. The feature-set matches that of Digital Asset Management with some limitations. The PR has been approved for submission by DNN's CEO, Andy Tryba.
Enjoy!

@valadas @bdukes How do we want to manage this?  Accept the PR as-is and submit follow-on PR's for missing features/enhancements?
I'm seeing some verbiage and things that I'd like to clean up.  For example, the spelling of Behavior is using the European styling and I would prefer to match current styles etc.

I think the main problem now is it is not building which will block other PRs is we merge it as is and need more time to make it build...
I would maybe:

Create a feature branch for it
On that branch, fix the build
On that branch adjust the manifest so it is locked with 9.7.0 version but the same name as the current on (so it can be an in place replacement)
Ensure the build scripts package it as .resources instead of .zip

That will allow us to have it live on develop and be an optional replacement for people who are happy with it as it stands, then we can improve it and when we get feature parity (folder settings and stuff) it will simply replace our old one by default just by removing the old one and adjusting our build scripts to package it as a zip

Ok, what's the best way to do that?

Branch off of develop now
Rebase this PR to that new branch
Approve the PR?

Then continue working?

Hmm, let me merge the latest changes from 9.6.0 into develop, release 9.6.0 and then we branch a feuture branch, sounds good?

I just made changes to fix the items mentioned by @valadas, waiting for the CI building result.

Awesome, thanks @ash @zyhfish @mitchelsellers
I just created a branch for it called feature/resource-manager so we can work on that in isolation (pun intended). It fired up a new build but should be the same thing. I need to go to bed, approving and ready to merge as soon as built.


Flynn on ARM (Scaleway)

Scaleway offers dedicated ARM servers for just €2.99/month which is crazy cheap and pretty powerful with quad cores and 2GB RAM. It seems like an ideal platform to build a resilient cloud and I was hoping to do so with Flynn for simplicity.
Flynn doesn't currently run on ARM so this is my :+1: for that to hopefully become possible.

Flynn is unmaintained and our infrastructure will shut down on June 1, 2021. See the README for details.


fix: use backstage fetch api instead of the default fetch for node js

Fork of this PR in KPhoen repo
https://github.com/K-Phoen/backstage-plugin-announcements/pull/180
Checklist:

[X] I have updated the necessary documentation
[X] I have signed off all my commits as required by DCO
[X] My build is green

Hey @cursedcoder, will you add a changeset, please?


Port (cloud.gov) Zendesk content to new instance by July 30

In order to retain our support activity history, we want historical Platform activity migrated from cloud-gov-old.zendesk.com to cloud-gov.zendesk.com.
Acceptance Criteria

[ ] GIVEN I am logged into cloud-gov.zendesk.com as an Agent
WHEN I look at issues
THEN I see all expected Platform support activity from before June 2022 is present.

Security considerations
Only content will be migrating. Settings for the new instance were part of a previous migration.
Implementation sketch

[ ] Can we pay Zendesk to do this for us?
[ ] If not, can we pay a contractor to do this for us?
[ ] If not, can we use a community-provided tool?
[ ] If not, can we write our own migration using the Zendesk API?
[ ] Delete the cloud-gov-old.zendesk.com account.

As of 7/28/2022: Brain Cell (Zendesk migration people) are getting started on Zendesk migration today! Additionally, Zendesk has extended access to our old account for 30 days to ensure we can get the migration done.

As of 8/2/2022: Had a meeting with the team from BrainSell, are requesting access to admin login information for both instances of old cloud gov Zendesk instance and federalist Zendesk instance. Scheduled to have next meeting to start the migration process at 11 am Thursday 8/4/2022.

@ArsHaider can this be closed?

@ArsHaider can this be closed?

William, it has already been completed successfully. I will close this ticket, thank you!


Very large interactive graphics in Science 2

Where to find the issue
https://www.coronawarn.app/en/science/2021-07-08-science-blog-2/#51-distribution-by-district
Describe the issue
https://www.coronawarn.app/en/science/2021-07-08-science-blog-2/#51-distribution-by-district contains a large (5.5 MB) interactive graph ("Fig. 6: EDUS participants by 3-digit postcode and district.").
This shows as a poor performance score with Lighthouse "Avoid enormous network payloads" and prevents migration to Node 16 because Panini cannot process the amount of data and it produces an error:
Error: Panini: rendering error occured.
RangeError: Maximum call stack size exceeded

See also https://github.com/corona-warn-app/cwa-website/issues/2155#issuecomment-998550089 in "Website migration steps for Nodejs 16"
Steps to reproduce
Performance report
Execute:

npm install lighthouse -g
lighthouse https://www.coronawarn.app/en/science/2021-07-08-science-blog-2/ --view

Note very low performance score of 16 and diagnostic "Avoid enormous network payloads".
Panini issue
On Ubuntu, execute:

nvm install lts/gallium
nvm use lts/galliumshows Now using node v16.13.1 (npm v8.1.2)
npm ci
npm run buildPanini fails with

'pages' errored after xx s
Error: Panini: rendering error occured.
RangeError: Maximum call stack size exceeded

To revert after test:

nvm use lts/fermium
npm ci
npm run build

Suggested change
Remove "Fig. 6: EDUS participants by 3-digit postcode and district." https://www.coronawarn.app/en/science/2021-07-08-science-blog-2/#51-distribution-by-district as an interactive graph and leave only the static graph.

@MikeMcC399
FYI https://github.com/corona-warn-app/cwa-website/pull/2278

Thanks to @brifemu for the PR!

PR #2278 solves the issue with Panini, which was a gating factor for migration to Node 16 (see #2155).

The PR does not solve this performance point. There is still 5MB of data transported to the user's browser. I'm not sure how important this is in practice. Mobile devices already receive only the static graphs.

I am closing this issue now, since the major problem with Panini is solved.
Embedding the graph data for the interactive graphs into the index.md / index_de.md source files affects all the science blogs, so this should be addressed separately if it is found to be causing a general problem for users.


Build a Web application for SEA billing report

Describe the issue
A billing front-end for Sid or Julian to self-serve.
Currently the billing reports are generated through Command Line Interface (CLI) which makes it difficult for non technical users to run. Moreover, the output files are in HTML format that can be viewed by a browser.
This ticket is to create a Web application for billing reports that allows the user to generate reports for their respecting accounts for a reporting period (Year/Month) and view the reports through the same UI. Main users of this application are Cloud Pathfinder Product Owner and/or Scrum Master, as well as Product Owners of other teams who have a tenant in SEA Landing Zone (LZ2).
Which Sprint Goal is this issue related to?
Goal 2
The 'Milestone' description (created in ZenHub) should clearly list Sprint Goals. This section should indicate which 'goal' this issue is related to.
Additional context
Add any other context, attachments or screenshots
Definition of done
Secure Web application that satisfies following requirements:

Utilizes billing report back-end that was delivered as part of ticket#677
Accessible through a public URL under BCGov domain
RBAC with 2FA enabled

Tenant PO's can view their own tenant accounts only
Cloud Pathfinder users can select individual tenants or all tenants to generate billing report for

Provides historical and current month billing reports

Not relevant anymore


Improve functions signature using union types and mixed

Pull Request Test Coverage Report for Build 845454165

17 of 17 (100.0%)  changed or added relevant lines in 10 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 842854781:
0.0%

Covered Lines:
2966

Relevant Lines:
2966

💛  - Coveralls


List of repositories on github

Display on the sidebar the list of wejustdevelop repositories on github.

Working on it!


[glib] Fix x64-linux-dynamic build

This PR fixes build failure with x64-linux-dynamic triplet.
For https://github.com/microsoft/vcpkg/issues/25668

Thanks!


proposal: helm install/upgrade CRD only

While reading the documentation about the CRDs best practices I have detected a corner case.
Let say that I am a cluster administrator and that I want to install a chart from an open source community, for example the kube-prometheus-stack
The mentioned chart is built to be installed with the method 1: automatic install of all resources (CRDs before the other manifests)
Now lets imagine I want to use the method 2 separate installation for CRDs and the other manifests
To achieve this I was thinking to execute something like the following:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# Helm
helm install prometheus-crds prometheus-community/kube-prometheus-stack --version 15.4.4 --only-crds
# ...
# Here install any resources that use the prometheus CRD (for example ServiceMonitors)
# ...
helm install prometheus-stack prometheus-community/kube-prometheus-stack --version 15.4.4 --skip-crds

Hi @Jimmy-Newtron. We ask that any proposals to the project be written up as a Helm Improvement Proposal. Have a look at the Contributing guide for next steps. Thanks!

Issues that are labeled feature or proposal must write a Helm Improvement Proposal (HIP). See Proposing an Idea. Smaller quality-of-life enhancements are exempt.

I think that in this case the problem statement is perfectly clear in the first message description and we are in the second case

Smaller quality-of-life enhancements are exempt.

@bacongobbler what will be the next step in this case?
I am not really a contributor today and I have not such possibility in the short term.

Sorry for the confusion here. Quality-of-life enhancements are defined more as formatting cleanups on output, new compiler targets, code refactors, etc. Proposing a new feature to Helm's codebase needs to take into consideration other proposals as well as the existing features available, which is why I suggested writing a HIP.


OpenFeign interface endpoint - PathVariable annotation was empty on param 0.

Describe the bug
Please provide details of the problem, including the version of Spring Cloud that you
are using.
It is my first time facing this and it is kind of confusing. Every time where I have used @PathVariable, I just matched the /{parameter} with the actual parameter on the method so I wouldn't have to do it like this @PathVariable("parameter") Integer parameter, but instead I would do it like @PathVariable Integer parameter for /{parameter}, but when doing the same thing while using OpenFeign there was an error saying " PathVariable annotation was empty on param 0." which is not really true because I have annotated my parameter as a @PathVariable.
This fails and throws 'PathVariable annotation was empty on param 0.'
@FeignClient(name = "fraud-service")
public interface FraudClient {

    @GetMapping("api/v1/fraud-check/{customerId}")
    FraudCheckResponse isFraudster(@PathVariable Integer customerId);

}

This works, correct me if I am wrong but when specifying the method parameter with the same name as the endpoint parameter, there is no need to specify the @PathVariable("thisHere") but I can just use @PathVariable Integer customerId without using the parenthesis on the @PathVariable to specify a value.
@FeignClient(name = "fraud-service")
public interface FraudClient {

    @GetMapping("api/v1/fraud-check/{customerId}")
    FraudCheckResponse isFraudster(@PathVariable("customerId") Integer customerId);

}

Not sure if it is a bug or just a confusion from my side but I just wanted to let you guys know and clarify it for my self as well. Have a great one guys :)

Hello @eno-lc. It should, indeed, work and, as far as I can say, it does. Please see a sample branch that works without any issues. If you're still experiencing any issues with it, please provide a minimal, complete, verifiable example that reproduces the issue.

Hi @OlgaMaciaszek, reaching out from a colleague device here. Having the same issue on a different machine as well, not sure why. I'll provide the link to a repository where you can check the following application/microservice as we get the following error:
Caused by: java.lang.IllegalStateException: PathVariable annotation was empty on param 0.
at feign.Util.checkState(Util.java:129) ~[feign-core-10.12.jar:na]
at org.springframework.cloud.openfeign.annotation.PathVariableParameterProcessor.processArgument(PathVariableParameterProcessor.java:51) ~[spring-cloud-openfeign-core-3.0.3.jar:3.0.3]
at org.springframework.cloud.openfeign.support.SpringMvcContract.processAnnotationsOnParameter(SpringMvcContract.java:299) ~[spring-cloud-openfeign-core-3.0.3.jar:3.0.3]
at feign.Contract$BaseContract.parseAndValidateMetadata(Contract.java:111) ~[feign-core-10.12.jar:na]
at org.springframework.cloud.openfeign.support.SpringMvcContract.parseAndValidateMetadata(SpringMvcContract.java:194) ~[spring-cloud-openfeign-core-3.0.3.jar:3.0.3]
at feign.Contract$BaseContract.parseAndValidateMetadata(Contract.java:62) ~[feign-core-10.12.jar:na]
at feign.ReflectiveFeign$ParseHandlersByName.apply(ReflectiveFeign.java:151) ~[feign-core-10.12.jar:na]
at feign.ReflectiveFeign.newInstance(ReflectiveFeign.java:49) ~[feign-core-10.12.jar:na]
at feign.Feign$Builder.target(Feign.java:269) ~[feign-core-10.12.jar:na]
at org.springframework.cloud.openfeign.DefaultTargeter.target(DefaultTargeter.java:30) ~[spring-cloud-openfeign-core-3.0.3.jar:3.0.3]
at org.springframework.cloud.openfeign.FeignClientFactoryBean.getTarget(FeignClientFactoryBean.java:419) ~[spring-cloud-openfeign-core-3.0.3.jar:3.0.3]
at org.springframework.cloud.openfeign.FeignClientFactoryBean.getObject(FeignClientFactoryBean.java:371) ~[spring-cloud-openfeign-core-3.0.3.jar:3.0.3]
at org.springframework.cloud.openfeign.FeignClientsRegistrar.lambda$registerFeignClient$0(FeignClientsRegistrar.java:235) ~[spring-cloud-openfeign-core-3.0.3.jar:3.0.3]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.obtainFromSupplier(AbstractAutowireCapableBeanFactory.java:1249) ~[spring-beans-5.3.13.jar:5.3.13]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1191) ~[spring-beans-5.3.13.jar:5.3.13]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:582) ~[spring-beans-5.3.13.jar:5.3.13]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) ~[spring-beans-5.3.13.jar:5.3.13]
... 42 common frames omitted
See the following repository: https://github.com/avdi-vrellaku/microservices-issue-on-empty-param-PathVariable
Clients package contains the FeignClient that I've provided in the bug description
Customer package is where the FeignClient is called
Fraud package contains the controller that is called via the feign client.

Hello @avdi-vrellaku, will take a look. Please learn how to properly format code and logs.

Hello @avdi-vrellaku @eno-lc - please provide a minimal sample, with only the modules and classes necessary to reproduce your issue.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

I know this is old and closed. Just wanted to leave this here, to help anyone searching for this error.
https://github.com/OpenFeign/feign/issues/2337


Thermals and Undervolt

Hi. I'm wondering if it is possible to run intel-undervolt on gamer-OS?
The system installs and runs very well on a 2019 HP-Omen laptop, but I couldn't find a way to adjust for thermals.
On both Linux and Windows I've gotten around it running hot by undervolting the cpu and limiting the clock speed.

Can you adjust the values as needed in the BIOS?

Can you adjust the values as needed in the BIOS?

Thanks for the reply.
Sadly no. HP Omen gaming laptops a have locked down bios.
Instead they use a software based undervolt in their 'Omen Command Center' for 2019/2020 models.
I've been using intel-undervolt from the repo in Manjaro, (does the same thing as throttlestop/XTU.)
But I can't see any way to install it on gamer-OS.
Shame. it runs incredibly well otherwise, so I thought I'd ask.

Thanks for the reply.
Sadly no. HP Omen gaming laptops a have locked down bios.
Instead they use a software based undervolt in their 'Omen Command Center' for 2019/2020 models.
I've been using intel-undervolt from the repo in Manjaro, (does the same thing as throttlestop/XTU.)
But I can't see any way to install it on gamer-OS.
Shame. it runs incredibly well otherwise, so I thought I'd ask.

I am including the intel-undervolt package in the next build since it is so tiny.

I am including the intel-undervolt package in the next build since it is so tiny.

This is great news! Made my day. Thanks so much for your help :)

This is great news! Made my day. Thanks so much for your help :)


document traefik proxy server with Minio

@harshavardhana can you assign this to me. 😄

Can be closed via https://github.com/minio/cookbook/pull/87#pullrequestreview-15944


Crash on MC1.20.1

Describe the bug
Minecraft fails to launch with error:
java.lang.RuntimeException: Could not execute entrypoint stage 'client' due to errors, provided by 'bettergrass'
See Logs below
To Reproduce

Install MC1.20.1, LWJGL 3.3.1, and Fabric Loader 0.15.11.
Install Mods Fabric API, YetAnotherConfigLib, and FabricBetterGrass
Launch Minecraft

Expected behavior
Minecraft should launch to main menu
Screenshots
Desktop (please complete the following information):

OS: Windows 10
Minecraft 1.20.1
Fabric Loader 0.15.11
Mods [Fabric API 0.92.2+1.20.1, YetAnotherConfigLib 3.5.0+1.20.1-fabric]
Version 1.013+1.20.6

Additional context
Logs - https://mclo.gs/hwob90x

To add, the issue only seems to be occurring with my MC1.20.1 Fabric instance. My MC1.20.6 and MC1.21 Fabric setups seem to be working with this mod.

The crash was caused due to an incompatibility with Java 17; Java 21 worked fine.
Thanks for letting me know!

This looks wrong:
def targetJavaVersion
if ("${project.version}".contains("1.20"))
    targetJavaVersion = 17
else
    targetJavaVersion = 21

Mojang (unfortunately) did the Java transition on a minor version, MC1.20.5, not on 1.21.
MC1.20.4 and earlier use 17, MC1.20.5 and up use 21.


SparkCommandBuilder does not support scriptLocation

Although it is possible to submit a Spark command with a script location, this is not achievable through the SDK.

Yes this is a very common use case when using the qubole-sdk. I think I can raise a PR for this, should be an easy fix.


remove underscore separator from display name

Signed-off-by: Jonathan Holloway<EMAIL_ADDRESS>

Codecov Report

Merging #377 (a53d7f0) into main (6d18f82) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #377   +/-   ##
=======================================
  Coverage   25.97%   25.97%
=======================================
  Files          31       31
  Lines        2922     2922
=======================================
  Hits          759      759
  Misses       2069     2069
  Partials       94       94

Continue to review full report at Codecov.

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

/lgtm


Error prone documentation

Lot of errors in the documentation, quality of Microsoft is decorating day by day  $SCALE_SET_NAME author forgot to append $ in the document.

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

ID: 3b81a147-db1c-b92f-88d1-6dd0991a72fe
Version Independent ID: f5a2c949-498f-5848-d89c-031d1a757120
Content: SSH into Azure Kubernetes Service (AKS) cluster nodes - Azure Kubernetes Service
Content Source: articles/aks/ssh.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

@imsauravroy007 Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate. We will update you accordingly.

@mlearned Can you please check and add your comments on this doc update request as applicable

Thank you @imsauravroy007 for the feedback.
We've updated the article to address your feedback and the changes should be available soon.


best practice for invoking menu cmds

sorry for using your issues as a discussion board but ...
how do you recommend invoking a menu command? I'm doing something like below, not sure if it's very pythonic, or if it might be worth adding to the core library a way to associate menu options with their functions.

# cmdname, function-ptr
menu_opts = {
    'timeslice': timeslice,
    'webapp': webapp,
    'split_sessions': split_sessions,
    'quit': quit
}

def run_cmd(opt):
    """exec related anon func"""
    # print('menu_opts', menu_opts)
    cmd = menu_opts[opt]
    cmd()

No worries.
There was another library out there that explicitly did this behavior - paired menu options to functions, and invoked the functions, but at the time I wrote this lib, I wanted something simpler, that would allow you to do the same thing with little fuss, but would also allow you to just access the raw menu option chosen, if you wanted that.
I got an email with what must've been your first draft of this issue, that also included some CLI input... I've used pimento like this myself, and this is what I've done:
def run():
    menu_opts = ...
    choices = menu_opts.keys()
    user_choice = get_from_args(choices) or get_from_menu(choices)
    menu_opts[user_choice]()

...where get_from_args gets the choice from the CLI invocation arguments, if any, otherwise returns something falsey like None, and get_from_menu uses pimento to present a menu and return the option.
For more complex CLI's with lots of arguments, I will generally tell a user in the help text that an argument is required, check if it was set, and then if not, present a menu.
In other cases I prefer something like dispatcher(get_from_menu(options)), because it's cleaner at the caller level than what the above boils down to (menu_opts[get_from_menu(menu_opts.keys())]()), and inside dispatcher you can call functions that take arguments, further parse the menu choice, etc.  Depends on what you need and personal preferences at that point, though, I think.

One of the big things I cared about when I wrote this lib, though, was that you don't always want to run a function when you present a menu.  A menu presented for "choose a color" is just going to pass that color into another function - it's not going to call a do_it_with_red or do_it_with_blue function, it's just going to call do_it(color=chosen_color).
So I wanted a menu that would just return a choice to me, and I'm probably going to keep it that way.
Although... I could see adding a few more functions to the top level API, like dispatch_menu or dict_menu that just wrapped some of these calls up.  I admit your use case is common (like I said, I've done it several times, too), so I could see adding a new function to make it simpler.

while formalizing the data structs, a way to have simple menu numbers,
and allow one-key choice of them (without return) would be good.
1 tex
2 rugs
3 socks

could you make this a separate issue?  Also, what about lists longer than 9 items?  to allow choice without hitting enter requires unique input - would you want leading 0's 000 - 999, or just disallow the non-return selection for longer lists?

new ticket made.


Support DiscreteNorm in scatter plot colorbars

Resolves #144. Now ax.scatter() accepts the exact same keyword arguments used to generate a DiscreteNorm as methods like ax.contourf() and ax.pcolormesh() -- if it detects that you passed an array of data values for the c argument.

Decided to also throw in a bar plot bugfix in this PR -- it turns out #156 did not entirely solve the issues with grouped bar positions

...and added a bugfix for the qt backend, because the examples I tested this on kept triggering recursive paint errors. Turned out that when setting the figure size after adding new panels to the figure (e.g. after making colorbars with ax.colorbar(m, loc='left')), this figure resize was triggering the canvas pre-processor, which triggered the tight layout algorithm and another figure resize, etc., etc. Added a breakout condition in the preprocessor that prevents this.


Live Preview doesn't seem to work in Edit mode

Had a huge shock this morning when I was presented with the option for Live Edit mode and I enabled the option.
All my notes were now empty, except for the title.
When switching to Preview mode everything was fine again, content was not lost.
Confirmed through VSCode, nothing was lost.
Switching to default theme [or another theme] showed everything as expected, switching back to Notation gave the same issue again.

Same issue. Seems like it will work briefly if I disable then enable the Notation theme, but as soon as I open a new note I can't see any of the content while in Live Edit mode.

same issue here!

Same issue T_T

I found a temporary solution: comment the 730-732 lines in css:
/* .workspace-leaf-content[data-type=markdown] .view-content {
  height: auto;
} */

and everything will be fine again.

I found a temporary solution: comment the 730-732 lines in css:
/* .workspace-leaf-content[data-type=markdown] .view-content {
  height: auto;
} */

and everything will be fine again.

Thanks for this! Worked like a charm.


How to charge based on multi-attribute product data with Chargify and MongoDB

Draft: https://docs.google.com/document/d/1OCFh_TXjQmScrurJsRvUXSjbmw-o6ix_i8AiCCpuSUo/edit?usp=sharing


Update Set-CsTeamsMeetingPolicy.md

adding attribute to policy with description to enable third party API

@tomkau i have been reading the documentation for a week. i do not understand how to solve the conflict. could you help solve it and teach me how to solve conflicts in the future? thank you.

Closing as changes are already in article.


Feature requests for troubleshooting crashes in exported projects

Preamble: I just shipped my first Godot game (nine months of work). I still consider myself a Godot noob. I learned a lot about the differences between running-from-source vs. exporting, which often result in opaque crash errors at runtime.
Based on my experience (still troubleshooting unresolved crashes), I would like to suggest two feature requests:

Console logs. The output of the Godot console (which appears only in debug exports) is extremely invaluable to finding/fixing issues. Without it, you just have a stack dump. Can you please add a way to get these from exports?

Perhaps exported games could automatically redirect the log to a temporary file on-disk, so at least if someone complains about  a crash, you have some data. Optionally, you can delete or keep the file between runs.

One-click run-as-export. Right now, I work alone (no QA team/process/etc.) so I don't ever export/run my app, because it takes long (set up the export profile, export, wait, launch game). Ideally, the editor could include a single push-button "export and run" option to make this frictionless.

This could be optimized - eg. always run the first configured export, or (like Visual Studio) show a list of available profiles, or always run an export that's fast and gives good error information (HTML5?)
For beginners, this would make it much easier to prevent crashes even before they're committed.

You can enable file logging by going in Project Settings -> Logging -> File Logging and enabling it.

is similar (but not identical) to https://github.com/godotengine/godot/issues/5257.

You can enable file logging by going in Project Settings -> Logging -> File Logging and enabling it.

Does this make logs when you export your game, too? If so, this is awesome.
I would then amend my request: this should be turned on by default. I would guess many of us don't know about this and would benefit from it being on by default.

I'm not sure about enabling it by default. This could cause user data directories to become huge when error messages are spammed, which may happen during project development.

This could cause user data directories to become huge when error messages are spammed, which may happen during project development.

This can be easily mitigated by truncating the log file when you launch your game.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Tasks that occur every 30 seconds

Hi @jamesisaac
I'm working with background geolocation and need it to run a check every 30 seconds to check if the user is in a certain location and send a push. I set the "priod" to 60, but nothing happens when the app goes to background.
Is it possible to work this way with your library?

Hi there,
Both iOS and Android enforce a minimum period of 15 minutes on the type of scheduling used by this library.
For your use case, I'd recommend something more purpose-built, like this:
https://github.com/transistorsoft/react-native-background-geolocation

@jamesisaac Is the 15 min limitation due to iOS/Android policies or purely out of courtesy?


chore: adaptations to nightly-2024-03-11

I've looked through all the changes, and everything (except for questions about List.merge) looks good to me.

!bench

Something terrible happened in injective resolutions

!bench

Something terrible happened in injective resolutions

It's still on overall improvement on instructions (very minor) and wall-clock, so we don't need to hold on this, right?

Don’t hold. It is probably something silly. Looking now

Added comment with label

🤦♂


gateway requests reaching ui handler to fail gracefully

closes #1575

Codecov Report

Merging #1578 (add195d) into master (f02489c) will increase coverage by 0.07%.
The diff coverage is 55.55%.

@@            Coverage Diff             @@
##           master    #1578      +/-   ##
==========================================
+ Coverage   39.08%   39.15%   +0.07%
==========================================
  Files         167      167
  Lines       13591    13596       +5
==========================================
+ Hits         5312     5324      +12
+ Misses       7506     7499       -7
  Partials      773      773

Impacted Files
Coverage Δ

api/ui_handler.go
31.57% <0.00%> (-8.43%)
:arrow_down:

api/serve.go
94.73% <100.00%> (+0.14%)
:arrow_up:

gateway/sig/v4.go
75.12% <100.00%> (ø)

pyramid/tier_fs.go
60.69% <0.00%> (+2.18%)
:arrow_up:

config/logger.go
75.00% <0.00%> (+10.71%)
:arrow_up:

Continue to review full report at Codecov.

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


Incorrect "What's Next" Video

I apologize, I am not sure where else to elevate issues with the videos
URL of codelab
https://developer.android.com/courses/pathways/android-basics-compose-unit-6-pathway-1#codelab-https://developer.android.com/codelabs/basic-android-kotlin-compose-sql
In which task and step of the codelab can this issue be found?
The "What's next?" video
Describe the problem
The "What's next" video is incorrect. It is currently the video also found in the "Get Data from the Internet" pathway of Unit 5
Additional information
Include screenshots if they would be useful in clarifying the problem.
Both videos are linked to : https://www.youtube.com/watch?v=mQBQATHQgSc

Hello @cjparent,
The issue that you presented to us is extremely important, and I thank you for bringing it to our attention. The videos will be updated soon with the correct links.


shift.js

Anyone any idea where shift.js has moved to, the github repo is not there anymore and I can't seem to find any information on it by Googling- strangely enough. I would like to use Handlebars with Tower- and investigating if Shift.js would be the way to go about it.
Thanks!
Marco

Moved to https://github.com/viatropos/mint.js, updated the link on the main site.

There's a broken link on the README too.


Added multiple features in a specification ForkJoinSpec to verify the…

… fork join behavior

Pull Request Test Coverage Report for Build 4134

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.08%) to 69.378%

Files with Coverage Reduction
New Missed Lines
%

cassandra-persistence/src/main/java/com/netflix/conductor/dao/cassandra/CassandraMetadataDAO.java
2
59.59%

Totals

Change from base Build 4132:
0.08%

Covered Lines:
12341

Relevant Lines:
17788

💛  - Coveralls


Some future requests

Thank you for this nice component! Very simple and useful.
But during working with it, I've found some things I'd like to see later:

Please, add slot supporting to the '.input-box' element.
For example, to include svg icon via 'use x-link'.
Sometimes we need to add a custom class name to the '.checkbox-component' element (parent tag), not only to the nested 'input'.
Thanks again!

Yes, it can be useful. I can do in the next days but if you want to make a PR I agree.

Vue injects classes defined at the component in the root element, for example:

<checkbox class="my-awesome-class">
Check me
</checkbox>

Renders to:
<div class="checkbox-component my-awesome-class">
    [...]
</div>

I really appreciate ideas for improvement, thank you.

Thank you! I feel that you will do this faster than me.
Sorry for the 2nd point, really didn't know, that's cool!

Slot ready! Check out https://github.com/mariomka/vue-checkbox-radio/commit/6a2c49090d56819d37ccff6779fc30daf712d7f9


requirement to work

Its worth noting, that in order for this to work, Anonymous job creation needs to be enabled.  If you are using Matrix-based security and this is disabled 403 will be returned (asking for login).

I forgot to add, this is assuming you are using the Matrix Authorization Strategy Plugin.


Please invite me to the GitHub Community Organization

Name
ten-captain
Discord Username (if applicable)
No response
Additional Context
Hi nice to meet you.
I would like to be part of the awesome community.

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."


fix typos

@JasSuri : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @JasSuri - This pull request was opened in the public repo. PMs should work in the private repo, per the Microsoft Docs contributor guide. Would you make this content update in the private repo instead? Thank you! We'll close this PR.


How can I add multiple menus?

I cannot add multiple menus to polybar because if I have more than one only one gets openned.

You can't. Currently you can only have a single menu module per bar, as is also noted on the Wiki (otherwise they'll interfere with each other).
I think this is because when the module sends the menu-open-* command, polybar can't tell to which menu it should send it, so you can only have a reliable menu, if you have at most one menu module, so polybar always sends the command to the right module.

OK. Thank you for the quick response.


Moved repository from Travis to GitHub Actions

Personally, I think the best course of action for this would be reverting the most recent commit

@dherrada This is failing for a documentation build issue and it was already failing, though it may have been hard to tell because what looks like a typo in the cookiecutter setup broke the link to Travis. It's here:
https://travis-ci.com/adafruit/Adafruit_CircuitPython_CPython
Can you give more detail about why you were suggesting reverting the most recent commit?

@siddacious Prior to the most recent commit, the only issues were pylint issues in the docstring of adafruit__cpython.py. In fixing the pylint issues, I messed up some of the rst which caused it to fail.

@dherrada ah! I see what you mean. Ya, go ahead and revert the TODO changes

@siddacious Ok. Will rebase in 1 sec


allow geo filesets to be editable in UI

Closes #1134.
Hyrax uses simple_form, which requires these initializers: https://github.com/projecthydra-labs/hyrax/tree/1e504c200fd9c39120f514ac33cd42cd843de9fa/lib/generators/hyrax/templates/config/initializers
Added missing form partial.
Redirect geo works to fileset show page rather than file manager since geoworks doesn't use it.

Coverage remained the same at 99.973% when pulling 184dbd94c6ec16abb005ec9b3eb0dba1a8b70cac on geo-form-partial into e66eb75274375f4fc20bb826c2be9c823aabe1f9 on master.

I'm surprised the initializers was an issue - I thought hydra-editor had all that stuff as part of it

I was able to get this to work without the simple_form initializer, but I did need the simple_form_bootstrap initializer.
A few other things:

The versions tab on the edit page should be removed since we aren't versioning files.
The "Share With" section on the permissions tab should be removed.

Coverage remained the same at 99.973% when pulling 244abc7ff32ba823004abcb0a1b099e821cfd1e1 on geo-form-partial into e66eb75274375f4fc20bb826c2be9c823aabe1f9 on master.


Example (or tips) for using age() in defining a cohort within atttrition()?

I'm interested in applying inclusion criteria "is at least 18 at index"
I bet I want to leverage the age() function (https://github.com/OHDSI/Capr/blob/fa03ba051993380a3c69a3b5a6c23273a2cdc390/R/attributes-op.R#L328-L343), but I'm struggling a bit to figure out how to use it in an example
I looked at the examples in https://ohdsi.github.io/Capr/articles/Examples.html but didn't find one. Also couldn't seem to find one anywhere else in the repo.
Any tips? Thanks!!

I just found some relevant documentation in https://ohdsi.github.io/Capr/articles/capr_objects.html, I'll keep learning and post an answer if I can solve it!

@pa-nathaniel thanks for your question. you have indeed found a bug. If you want to observe the attrition based on age you can add the age as a demographic criteria to a group. This is what happens in ATLAS. I need to add a container that holds the demographic criteria to apply it to the group. A group must take in a criteria class. Code would look as such:
library(Capr)

  t1dConceptSet <- cs(descendants(195771), name = "T1D")

  cd <- cohort(
    entry = entry(
      t1dConceptSet,
      observationWindow = continuousObservation(priorDays = 365L),
      primaryCriteriaLimit = "All"
    ),
    attrition = attrition(
      'atLeast18' = withAll(
        demographic(age(gte(18L))) # function to add
      )
    )
  )

Ah interesting, I thought I had solved it yesterday evening by doing something like the code below.  Would this not do it?
library(Capr)

 t1dConceptSet <- cs(descendants(195771), name = "T1D")

 cd <- cohort(
    entry = entry(
      t1dConceptSet,
      observationWindow = continuousObservation(priorDays = 365L),
      primaryCriteriaLimit = "All"
    ),
    attrition = attrition(
     "At least 18 at entry" = withAll(
      atLeast(
        1,
        conditionOccurrence(
          t1dConceptSet,
          age(gte(18)), firstOccurrence()
        )
      )
  )

If you are using age as an attribute to a condition this is indeed correct. However, circe allows you to use a demographic attribute as a point of attrition. This is not covered in Capr v2 and needs to be added.

Ah great glad I wasn't too far off, thanks!


Copyright infringement of Adobe AGL

In the README you stated that the glyphs name are from Adobe AGL, but AGL is a BSD licensed document, therefore modifications should retain the disclaimer and copyright notice according to BSD 3-clause license.
I am doing Debian packaging for the package glyphsLib which includes a file generated from your repository, but Debian requires files to be built from source.

Is the addition to the readme file sufficient?

I think that's sufficient, though IANAL.

Since you are packaging this, it would be also helpful to explicitly tag releases so both upstream glyphsLib and its Debian package can refer clearly to the same revision of the data files.
If they were not in sync, they would end up producing different outputs and that’s not good.

You can just push a git tag from time to time, or even simply create github releases directly from the website, which will also create a git tag for you.


fix: dashboard settings to set correct columns and rows

Overview
This PR is for ticket #2313  and to correctly display columns and rows and it includes

widget selection is now updates with columns and rows changes
widget width and height will reset back to default when the columns and rows are reduced to less the widget width and height and set max value again and will persist the x & y values as 0

Verifying Changes
settings-update.webm
Then open the website http://localhost:8080 to run the doc site.
Legal
This project is available under the Apache 2.0 License.

The fix for the issue 2313 is coming in separate PR. this change is not fully resolves the issue, so closed this cause of some conflicts.


Move TimeStore definition and implementations outside of cache module

This PR moves the definition and implementations of TimeStores outside of the cache package, along with related references.
Sidenote: There might be confusion between store.gcStore and utils.gcstore.GCStore

Can one of the admins verify this patch?

ok to test

LGTM

Added you to the jenkins server. PRs should be built automatically henceforth.


Update affiliation process

This PR updates the usage of the affiliation-address model:

review of features
a bit of training data correction
update the models
using clusteror for decoding the labeled result (much simpler and clean)
optional PDF coordinates for affiliation structure in the resulting TEI XML

For best results, use  the Deep Learning model, which gives significantly more accurate recognition.

Still to do:

update documentation for affiliation coordinates,
consider coordinates for sub-structures of the affiliation orgName and address elements (country, etc.)
tests

coverage: 39.845% (-0.1%) from 39.959%
when pulling c776e3c1b149e2e0f4a30458c6e8f3cc1dbf1901 on update-affiliation
into 6bd974d4c4f0db99904525ba12dc064c10052536 on master.


Add module to manage datasets

This PR creates a module to manage datasets — locally and remotely. The novelties are basically described in serenata_toolbox/datasets/__init__.py, but as a PR message I should highlight ~four~ five things:

This PR replaces tinys3 (used by the main repo) and uses boto3 instead because tinys3 uses requests under the hood and requests is unable to upload large files to S3 (more than 10MB).
This PR requires the dependencies to be reinstalled (i.e. drop tinys3 and install boto3) — this changed is in setup.py.
This PR enables the toolbox to upload files, so we need to setup our credentials for that: one has to copy config.ini.example as config.ini and set them (this is documentes in the new version of the README.md).
When merged we can update serenata-de-amor/src/backup_datasets.py to use this module instead.

UPDATE

There are no tests for the async methods in the Downloader module — once merged I'll open an Issue for that.

We added new features, broke none. Is version it version 7.6.2 or 7.5.2? (cc @jtemporal)

referring to #34 this new features a considered a major change, so version bump to: 8.0.0 🎉

Yay, thanks! Version bumped ; )

I'll test this one later today 🎉

Also some how this is happening:

when I know that the data dir is not empty:

did I do something wrong here?

This is weird. I cannot reproduce this here unfortunately. Would you mind pairing so I try to debug what's happening there?

Would you mind pairing so I try to debug what's happening there?

You know I love pairing =D count me in!

Also some how this is happening […] when I know that the data dir is not empty

Fixed by 30c464e

Everything seems to be in order here =) merging 🎉


[release/3.1] Fix macOS PAT flow for internal non-authenticated builds

I wanted to take previously source-built artifacts from https://dev.azure.com/dnceng/internal/_build/results?buildId=807228&view=results, but the macOS leg failed due to auth issues. The auth json looks like this, literally, and gets a 401:
...
{
  "endpoint":"https://pkgs.dev.azure.com/dnceng/_packaging/dotnet3.1-internal-transport/nuget/v3/index.json",
  "username":"optional",
  "password":"$(dn-bot-dnceng-artifact-feeds-rw)"
}
...

This is because dn-bot-dnceng-artifact-feeds-rw is not defined in that particular build definition. AzDO leaves the entire variable substitution expression when it doesn't match any varaible, then we pass it in directly:
    InternalPackageFeedPatEnv: $(dn-bot-dnceng-artifact-feeds-rw)
...
    - bash: ...
      env:
        internalPackageFeedPat: $(InternalPackageFeedPatEnv)

On Linux, we actually inject this value into a shell script rather than using the task env setting. This means that bash is evaluating it, so the $() syntax means it's a subshell. The subshell fails to find a command dn-bot-dnceng-artifact-feeds-rw and gives no output. This assigns an empty string value to the PAT variable, which disables auth:
-e internalPackageFeedPat=$(dn-bot-dnceng-artifact-feeds-rw)

This is convoluted and probably only worked by coincidence in the first place, but it's trivial to change the macOS side to match the Linux side, and that's a very localized fix, so I figure it's reasonable to just do that. I added a comment to the yaml to explain what's going on here for the future.
I have a build running with this change here: https://dev.azure.com/dnceng/internal/_build/results?buildId=807484&view=results

Some flakiness in tooling setup. Hasn't impacted any of the macOS jobs, both are green now.
Mock official build CentOS 7 Offline:
+ /src/eng/common/build.sh ...
Downloading 'https://dot.net/v1/dotnet-install.sh'
curl: (35) Network file descriptor is not connected

Mock official build Fedora 30 Online:
+ /src/eng/common/build.sh ...
Downloading 'https://dot.net/v1/dotnet-install.sh'
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to dot.net:443

PR validation, Fedora 30 Offline Portable:
+ /src/eng/common/build.sh ...
Downloading 'https://dot.net/v1/dotnet-install.sh'
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to dot.net:443

Similar to the errors in https://github.com/dotnet/runtime/issues/34015, but this is occurring even before dotnet-install.sh is downloaded. In https://github.com/dotnet/runtime/issues/34015, retries seem like the only solution, so maybe we need them at the Arcade script level here.

Merging past CI: the affected jobs (just macOS) already completed successfully. I want to get started on an internal non-authenticated build to get the previously source-built artifacts to finish off the 3.1.108 release, where this change will be running in a build that goes to completion, so I'll catch any potential ultra-strange problems there.

I want to get started on an internal non-authenticated build to get the previously source-built artifacts to finish off the 3.1.108 release.

I looked again, and it turns out that the macOS job isn't used to produce previously source-built artifacts, so this was unnecessary. Nice to have the build running green for the future though, I suppose. 😄


Scripted strips quotation marks from commands

steps
sbt version: any
problem
If you add, say, > set Compile / excludeFilter := "Bar.scala" || "Baz.scala", to a scripted file, the quotation marks are stripped and the command definition doesn't work.
expectation
The quotation marks are not stripped.

A work around that I stumbled across for this is to put the value in parenthesis:
> set Compile / excludeFilter := ("Bar.scala") || ("Baz.scala")


chore(changelog): remove changelog entry

Removed last entry from public changelog as the change is a chore on docs and not relevant on operational level.

Thee I was thinking I finally made a Changelog worthy contribution :cry:
LGTM


how to do command enter and preventing enter from being sent to code editor?

tried this to no avail
        onKeyDown={(e) => {
          if (e.key == "Enter" && (e.ctrlKey || e.metaKey)) {
            onSubmit(e);
            return false;
          }
        }}

onKeyDown={(event) => {
+  event.preventDefault();
  console.log(">>>>");
}}

@TheBuilderJR https://codesandbox.io/embed/https-github-com-uiwjs-react-textarea-code-editor-issues-144-4yvoij?fontsize=14&hidenavigation=1&theme=dark

I was looking at this package, and got the same issue. Linked codesandbox doesn't work for me (using Firefox/Linux (Pop!))
Enter events will still be sent and be added to the CodeEditor. The same onKeyDown eveent on a  normal textarea works as expected though. So might be an issue with how onKeyDown is implemented on the CodeEditor?

https://github.com/uiwjs/react-textarea-code-editor/blob/dedfb991228e9f6687b33d70b81a6e3de300553e/src/index.tsx#L95-L99
onKeyDown={(event) => {
+  event.preventDefault();
  console.log(">>>>");
+  return true
}}

@aleda145 Maybe it can solve your problem

https://github.com/uiwjs/react-textarea-code-editor/blob/dedfb991228e9f6687b33d70b81a6e3de300553e/src/index.tsx#L95-L99
onKeyDown={(event) => {
+  event.preventDefault();
  console.log(">>>>");
+  return true
}}

@aleda145 Maybe it can solve your problem

It doesn't work :/, same problem. Also tried adding event.stopPropagation();, didn't help either. My enter event is still sent to the codeEditor, creating a new line.
The following textArea works as expected for me
<textarea
  onKeyDown={(event) => {
    event.preventDefault();
  }}
></textarea>

Let me know if there anything you want from me to debug this!
Great package, I still use it! :star:
I wanted it to run a SQL query on shift+Enter and not create a new line. But changed to ctrl+space instead, works just as well :smile: !

Running into the same issue -- the event cannot be stopped. Any update here?

Same issue.Any update?

https://github.com/uiwjs/react-textarea-code-editor/blob/dedfb991228e9f6687b33d70b81a6e3de300553e/src/index.tsx#L95-L99
onKeyDown={(event) => {
+  event.preventDefault();
  console.log(">>>>");
+  return true
}}

@aleda145 Maybe it can solve your problem

Maybe I don't understand what it means, haven't solved the problem yet?
@emptycrown @Haiqi-Wu @aleda145


metavision_driver: 1.0.6-1 in 'rolling/distribution.yaml' [bloom]

Increasing version of package(s) in repository metavision_driver to 1.0.6-1:

upstream repository: https://github.com/ros-event-camera/metavision_driver.git
release repository: https://github.com/ros2-gbp/metavision_driver-release.git
distro file: rolling/distribution.yaml
bloom version: 0.11.2
previous version for package: 1.0.3-1

metavision_driver
* Package should now contain Prophesee default plugins
* Contributors: Bernd Pfrommer

Holding for an upcoming Rolling sync


New library module

Description
Like discussed in #298, we would like to create a new library module for centralizing the public API of Kotools Types.
This new module, depending on the internal module introduced in the issue #299, should support the same platforms of the root project and should have a dedicated integration workflow for testing it on every change in it.
It should also have the same Gradle plugins of the root project.
Dependencies
This issue is blocked by the following ones:

[ ] #299

Checklist

[ ] Create the library module with sample code in it.
[ ] Test the sample code.
[ ] Create a dedicated integration workflow.
[ ] Check the generated documentation of the new module.
[ ] Generate the public API binaries of the new module.
[ ] Document the new module with a README presenting which tasks to run.
[ ] Update the Unreleased section in CHANGELOG.

See https://github.com/kotools/types/discussions/298#discussioncomment-7786493 for more details.


Click the analyze button, no response.

It seems to need some updates, there is no way to analyze the video now

You need to download the new version of yt-dl. Worked for me (as it seems right now).

Surely he is right, it works fine if I keep the original yt-dlp in the same directory.

Had the same issue, Plusader's suggestion fixed the issue. (Windows 11) Make sure yt-dlp-gui.exe is in the same directory as yt-dlp  and ffmpeg.exe. As per the Instructions in the wiki under heading: "Use yt-dlp-gui"
yt-dlp-gui Wiki: https://github.com/kannagi0303/yt-dlp-gui/wiki/Getting-Started

Thanks guys, it worked out!