implement a DFA matcher

One of the reasons why RE2/C++ is so fast is because it has two implementations of regex matching: a limited DFA matcher (no sub-capture support) and a full NFA simulation. This crate has the latter, but not the former.
Adding a DFA matcher should be an implementation detail and shouldn't require any public facing changes.
This is a pretty involved project. I hope to find time to do this some day, but if someone else wants to tackle it, I'd be happy to help mentor it. (Part of this will be figuring out how to handle the regex! macro. Do we replicate the DFA there too like we do the NFA?)

I'll do it!
@BurntSushi recommends that I look into an existing DFA engine by @carllerche.
I'll be starting by getting familiar with the code in this repo and RE2.

Feel free to ping me on IRC or wherever if you want to talk about carllerche/automaton

Here's a summary of some research I've done and my intended next steps.
TL;DR
The algorithms that @carllerche uses in carllerche/automaton make a different time/space tradeoff than that made by RE2 and rust-lang/regex so far. For now, I recommend that we keep modeling rust-lang/regex after RE2 and use the same method of lazy DFA construction used in RE2 rather than incorporate Carl's work. However, using Carl's work to construct a DFA at compile time with the regex! macro could be a killer future enhancement.
A Comparison of rust-lang/regex, RE2, and carllerche/automaton
I consulted The Dragon Book and Russ Cox's blog series on implementing RE2 for background on algorithms for constructing and simulating automata. I'll refer to algorithms by numbers given to them in the Dragon Book for anyone who wants to take a closer look.

RE2: Construct an NFA from a preprocessed regex using Thompson's construction (Dragon 3.3). Then, use the "Two Stacks" algorithm (Dragon 3.4) to simulate the NFA. It is also possible to use Two Stacks to simulate an equivalent DFA. Unlike backtracking NFA simulators, Two Stacks maintains a list of current NFA states and advances them in lockstep. Each list of NFA states is essentially one state of an equivalent DFA. By caching these lists, RE2 lazily constructs a DFA.

rust-lang/regex: It uses the same approach as RE2, except it does not have lazy DFA construction built on top of Two Stacks. Right now, only NFA simulation is implemented.

carllerche/automaton: Given an automaton, possibly an NFA, convert to a DFA using "subset construction" (Dragon 3.2). Then, walk the state graph to prune it. Finally, minimize the graph (using Dragon 3.6). Once you have a DFA, it is straightforward to simulate it in time proportional to the length of the target string.

Tradeoffs: Let r be the length of a regex and x be the length of a target string. Constructing a DFA ahead of time (as Carl does) requires O(rx) space. Lazily construction requires O(r) space (bearing in mind that we need to allocate a constant amount of space for the cache). Lazy DFA construction requires more computation than executing a pre-constructed DFA, but it is still O(x). So the algorithms that Carl has implemented take a fundamentally different approach than do the algorithms of RE2.

Next Steps
I say we keep modeling rust-lang/regex after RE2 and implement lazy DFA construction rather than ahead-of-time DFA construction. I see this as taking two big steps:

Implement DFA simulation.
Work out when to call on the DFA simulator and when to call on the NFA simulator depending on the question the client is asking (Is there a match? Where is the match? etc.).

Compilation of a regex into VM instructions would be unchanged.
However, the ahead-of-time approach could still be useful. Constructing a DFA at compile time with the regex! macro would be crazy cool. But I think that can wait :smile:.
Questions
@carllerche: I know you and @BurntSushi were talking about folding in carllerche/automaton. Am I misunderstanding anything? Does this seem reasonable to you?
Also, many thanks to @BurntSushi for being so helpful to this Rust newbie.

@WillEngler Sounds good to me! w.r.t. to regex!, that can be separately engineered, but its future is certainly exciting! :-)
(My new branch has some basic support for picking a matching engine on-the-fly, but the DFA is a bit more complicated since it can be beneficial to run the DFA first and then the NFA to find submatch boundaries. But this doesn't have to be in the first pass! A simple match-only DFA seems like a good initial goal to shoot for.)

@WillEngler sounds accurate. My goal was to target the case of optimizing runtime at the expense of compile time with the assumption that it is easy to build the regex once at boot so trading off compile time vs. execution time is desirable.

Great! Then I'll get to work on a match-only DFA.

DFA Sitrep
I don't have anything to show for this week. If last week was about learning the theory of DFA construction, this week was about learning the implementation details. I traced and annotated Russ Cox's educational bounded-memory DFA implementation and his production implementation. I also followed @BurntSushi's major refactoring (#91) as I learned more about rustlang/regex's internals.
Expect to see some action in WillEngler/regex this week.
(Is this proper Github etiquette? I thought it would be helpful to give an update because I haven't shipped anything this week.)

@WillEngler Updates are really good, particularly when you're still getting your bearing. If you share info with others, then you can benefit from their experience! In any case, sounds like you're on the right track. :D

@WillEngler Oh, and please don't feel pressure to "ship" stuff!

@BurntSushi Thanks, I needed that :smile:. I saw you contribute so many great additions so quickly in the refactor and I got a little intimidated. But as a beginner, it's unreasonable to expect myself to move that fast.
Onwards!

@BurntSushi I'm going down the rabbit hole of UTF-8 encoding and would like to make sure I'm going in the right direction.
As I understand it, each DFA state will need a collection of pointers to other DFA states in order to form a graph. We want to know the number of pointers when we allocate the DFA state. Obviously, one pointer per UTF-8 codepoint isn't viable.
RE2's approach is to maintain a 256-bit bitmap during compilation that records borders between character classes that are treated identically. Then, when constructing the DFA engine, it creates a mapping from [0, 255] -> [0, num_character_classes]. This map is used to pick the right pointer when walking/lazily constructing the graph. Here's an example from Russ Cox:

A regexp looking for a[abc] would have four byte ranges -- 0 to 'a'-1,
'a', 'b' to 'c', and 'c' + 1 to 0xFF.

RE2 gets away with only caring about 256 values by compiling multi-byte UTF-8 codepoints into mini-automata. (I think. I haven't scrutinized that part of the code enough to fully grasp it.)
Given Rust's approach to Unicode, it doesn't seem natural to compile codepoints down to their bytes. So here is the approach I'm imagining:

During construction of the DFA engine, construct a mapping from [0, max_unicode_value] -> [0, num_character_classes] by looking at the OneChars and CharRangess in each instruction in the compiled program.
Each DFA state will be initialized with an array of num_character_classes pointers to other DFA.

I have one major reservation. In RE2, the number of possible character ranges is bounded above at 256. In the approach I described, the upper bound is the number of Unicode codepoints. Are there use cases that would have many (say, > 1000) character classes and cause the size of the pointer array to blow up? And overall, does this approach seem reasonable?

@WillEngler I was actually thinking about this problem a couple mornings ago, but I hadn't gotten a chance to write up my thoughts. Thank you for bringing it up!
My first thought is this: we shouldn't let the way Rust handles strings influence how matching engines are written. In particular, if it is easier to write a faster engine byte-by-byte instead of character-by-character, then we should do that. If we expose the same interface that we do today, then we can assume UTF-8 input (which is rather convenient). Doing this will, as you pointed out, require changing a fair bit so that UTF-8 decoding is built into the automaton generated by the compiler. The RE2 code to do this doesn't look that bad. I think this also means that we could collapse the Char and Ranges instructions into one, after some small re-factoring on how case insensitivity is handled.
My second thought is that this could potentially introduce some problems in corner cases. For example, consider the \b instruction. It requires one character look-behind. In a byte matching engine, this could be up to 4 bytes. It is Unicode aware in this crate, but it is not in RE2. I would like to preserve this property, not only because it seems correct but because a regression on Unicode support would not be nice. I don't know if it is problematic to implement this in the DFA. If it is, then I would choose "DFAs cannot be used with regexes that have a \b" over "change \b to not be Unicode aware." I'm not entirely sure whether this plays nicely with existing matching engines either. My hope is that it can just do what it does today: decode the previous character at the current input position. If the previous character is not valid UTF-8 decoding, then that instruction would simply fail at that position.
My third thought is that you should not take my thoughts for gospel. I am not saying, "to get a DFA implemented, we must switch to byte matching engines." :-) For example, if it is easier to ignore \b for now, then we can simply bar the DFA from running on any regexes with a \b instruction.
OK, with that out of the way, I'll actually respond to your thoughts. :-)

As I understand it, each DFA state will need a collection of pointers to other DFA states in order to form a graph. We want to know the number of pointers when we allocate the DFA state. Obviously, one pointer per UTF-8 codepoint isn't viable.

Yes! One thing I would consider if I were you is the choice of whether to actually use a pointer or not. My suspicion is that using pointers might require use of unsafe (or Rc) to manage multiple ownership, since you'll have multiple paths to the same state in the DFA. Instead, you might consider storing the states sequentially in memory (e.g., Vec<State>), and refer to them by index. This preserves a nice single-ownership scheme. (I used this representation in my Aho-Corasick implementation.) Another nice property of this is that you might not need the "class" indirection because you could use a much smaller "pointer" type. e.g., You could declare that the DFA is limited to 65,536 states, which would yield an overhead of 512 bytes per state, which, to be fair, is still more than the ~256 bytes per state used in Cox's formulation. (This is better than Cox's worst case, but I can't imagine the worst case happening too often.)
On an unrelated note... When I first published regex, I had the phrase "UTF-8 codepoint" in the public docs in several places. Shortly thereafter, someone submitted a pull request changing this to "Unicode codepoint." I hadn't realized the distinction until that point, but the correction was useful because it forced me to think more carefully about Unicode the abstraction and Unicode the implementation. (To get really pedantic, the regex crate operates on Unicode scalar values, since Rust strings do not permit surrogate codepoints!) Because I found this distinction useful, I'd like to pay it forward to you. :-)

RE2 gets away with only caring about 256 values by compiling multi-byte UTF-8 codepoints into mini-automata. (I think. I haven't scrutinized that part of the code enough to fully grasp it.)

This is my understanding as well. I understand it at a high level. I think I'd need to work through an example or two before I'd really get it.

I have one major reservation. In RE2, the number of possible character ranges is bounded above at 256. In the approach I described, the upper bound is the number of Unicode codepoints. Are there use cases that would have many (say, > 1000) character classes and cause the size of the pointer array to blow up? And overall, does this approach seem reasonable?

Hmm. So I think terminology is getting a bit conflated here. The term "character class" has a well-defined meaning in regex land, but here, I think you're using it to refer to a specific implementation detail. (How about, "state character class"?) If so, I think that is a problem. e.g., Consider \pL[a\pL]. In that regex, every character in the Unicode class \pL will need its own state character class. This is quite large!
I haven't been able to come up with a way to work around this without either moving to byte matching or making unacceptable sacrifices in memory usage. :-/
(Go's regexp package---which uses the same character based engines that we use---has a nice trick similar to this in its one pass NFA engine. It's effectively the same as your state character class idea, but it's pushed down into each state. So in the main matching loop, it has to do a binary search over the classes---which are ranges of bytes---in order to get the next state. However, it is only able to do this because it has determined the that regex is one pass. Namely, given a position in the input, there is at most 1 possible next state that can lead to a match.)

@BurntSushi A lot to chew over here!

For example, consider the \b instruction. It requires one character look-behind. In a byte matching engine, this could be up to 4 bytes. It is Unicode aware in this crate, but it is not in RE2.

I hadn't considered that. The Unicode-unaware behavior seems really unintuitive. I had to go look at RE2 again to convince myself that it would act so strangely.

I would like to preserve this property, not only because it seems correct but because a regression on Unicode support would not be nice. I don't know if it is problematic to implement this in the DFA. If it is, then I would choose "DFAs cannot be used with regexes that have a \b" over "change \b to not be Unicode aware." I'm not entirely sure whether this plays nicely with existing matching engines either. My hope is that it can just do what it does today: decode the previous character at the current input position. If the previous character is not valid UTF-8, then that instruction would simply fail at that position.

I'm in complete agreement.

Hmm. So I think terminology is getting a bit conflated here. The term "character class" has a well-defined meaning in regex land, but here, I think you're using it to refer to a specific implementation detail. (How about, "state character class"?) If so, I think that is a problem. e.g., Consider \pL[a\pL]. In that regex, every character in the Unicode class \pL will need its own state character class. This is quite large!

Overloading "character class" is definitely a bad idea :) . \pL[a\pL] does indeed blow up the idea of state character classes, but not as badly as you claim (I think). As I understand it, there would only be one state character class per consecutive group of letters. So the uppercase Cyrillic letters Я and Д would be in the same state character class because they are members of a group of consecutive Unicode codepoints that are treated identically in this regex. The one exception is that a would be a separate state character class from b - z.  In any event, that's an enormous amount of state character classes (see RSC's diagram of the mini-automaton that comes from compiling \p{Lu}). Still, the distinction isn't entirely academic because the same reasoning applies to "byte ranges", RSC's term for groups of bytes that are treated identically in a regex and thus receive one DFA pointer per range.

My third thought is that you should not take my thoughts for gospel.

Of course :)

I am not saying, "to get a DFA implemented, we must switch to byte matching engines." :-) For example, if it is easier to ignore \b for now, then we can simply bar the DFA from running on any regexes with a \b instruction.

On that note, here is how I think I ought to go forward.

I experiment with byte matching as implemented in re2/compile.cc. At first, I blithely ignore the fact that /b won't behave as it should.

Once I have something working, I find a way to make look-arounds Unicode aware again. I don't think that will be too hard (famous last words). I hope that after implementing the naive version, it will be clear how to work it in.

It will be instructive for me to make an experimental feature in the compiler so that I can understand that part of the crate better. Also, it helps that this will be a task with a comparatively low surface area. I can have a small victory to feel chuffed about before tackling the DFA engine proper.
Sound reasonable?
Miscellaneous thoughts:

... the correction was useful because it forced me to think more carefully about Unicode the abstraction and Unicode the implementation ...

Thanks for paying that forward! I always appreciate being corrected on terminology.

Go's regexp package---which uses the same character based engines that we use---has a nice trick similar to this in its one pass NFA engine.

Interesting. I'll have to take a look. The Go implementation might be easier for me to use as a reference than the C++ implementation.

Yes! One thing I would consider if I were you is the choice of whether to actually use a pointer or not. My suspicion is that using pointers might require use of unsafe (or Rc) to manage multiple ownership, since you'll have multiple paths to the same state in the DFA. Instead, you might consider storing the states sequentially in memory (e.g., Vec), and refer to them by index.

Thanks for that suggestion! Tips on how to write effective Rust are always welcome.

I think everything sounds good. If you wanted to try out your state transition character class idea before byte based matching engines, then I'd support that too. (This will get you to DFA-land faster.)
OK, so here are my thoughts on byte based matching engines.

Most of the work is going to be in the compiler. Borrowing ideas from RE2 is good.
There will be some work in the existing matching engines. My hope is that you can replace OneChar and CharRange with ByteRange (same as RE2). I'm worried that \b may still be tricky, but it does seem like my idea above (attempting a decoding) should work.
Case insensitivity is going to jump up and bite you. Right now, all character classes are normalized to their simple case foldings. For example, given (?i)[a-zA-Z], it will be translated to [a-z] with the casei flag set. To match, the input character has to be case folded first. In order to support byte ranges, you can't operate at the Unicode character level, so you'll need to change this normalization process so that all cases are represented. In other words, case folding becomes part of the automaton! It will use more memory, but I'm not that concerned about it. (I frankly shouldn't have designed it this way in the first place.)

You might choose to ignore (3) and hope that I can do it in a timely manner. :-)

Sounds good! Ideally, I'll handle case insensitivity myself. But as for doing things in a timely manner, I'm more likely to be the slow one :)

Btw. have you checked the "Regen" Regex engine?
Homepage: http://sinya8282.github.io/Regen/
Github: https://github.com/sinya8282/regen
It uses JIT and parallerization, but according to this paper[1], even without them, it manages to outspeed RE2 with a considerable marginal.
[1] (Sorry, Japanese only) http://www.is.titech.ac.jp/~sassa/papers-written/shinya-regen-postergenkou-PROSYM12.pdf

@golddranks No, this is the first I've heard of it. Thanks for the links!
I would need to take a lot of time to understand their approach because I don't know the first thing about JIT compilation. So I'm going to make a note to myself to revisit this later.
(It also doesn't help that I can't read Japanese. I'm having a hard enough time right now learning Spanish!)

@golddranks Thanks! But I fear that without an English description of the work they've done, it will be hard to benefit from it. JITing and parallelization seem like optimizations that come after initial work on a DFA is done. :-)

Progress Report
I'm chugging away at the byte matching engine. The trickiest part has been deciphering laconic bit-twiddling code like this to figure out what approach RE2 took. I've made some decent progress. I have pieces of a module that can take in a character range and spit out byte ranges that are ready to become instructions. So far, that means splitting ranges along the length of their UTF-8 encoding and further splitting them so that each range shares the same leading bytes. It doesn't work yet. I still need to write up tests and do some serious debugging. And some design changes are probably in order.
There is much left to do after that! Here is the order I want to tackle things:

Fitting a new instruction type into the main compiler loop.
Getting lookarounds to work.
Case folding.
Optimizations. For example, RE2 caches byte suffixes, but I've put that off for now.

@WillEngler Looks great so far! Case folding could get tricky, as you'll need to make modifications to regex-syntax I think. (You will cause existing tests to fail, which will have to be fixed.)
Otherwise, yes, putting off optimizations like caching is good. Make it work. Make it right. Make it fast. :-)

@WillEngler It looks like rsc also wrote a DFA in Go with byte instructions like in RE2. Here's the UTF-8 automaton code: https://github.com/google/codesearch/blob/master/regexp/utf.go

@BurntSushi Thanks for bringing that up. I've been banging my head against the C++ version, so it'll be helpful to see it from a different perspective.

@BurntSushi I said I was hoping to get

Fitting a new instruction type into the main compiler loop
Getting lookarounds to work.

working by this Sunday. That was pure hubris. Here's my true status:
In RE2, rune* compilation is mostly handled in a big, recursive function with a lot of side effects that mutate the compiler. I was following that approach, but I had a hard time reasoning about all of the state transformations. And when I thought about how I would write tests for it, I cried a little.
So I'm taking a different tack now. The module I'm working on exposes one main function: RuneRange::to_br_tree that compiles a rune range to an intermediate form, a BRTree (ByteRangeTree). A BRTree is a binary tree where each node either contains a ByteRange or a split into two branches. So it's pretty close to what the compiled instructions will look like.
As a result, the rune compiler module consists mostly of pure and almost-pure functions that should (hopefully) be straightforward for me to test and debug. Also, I like how it keeps the innards of compiler.rs away from rune compilation. The downside, of course, is that the indirection of BRTree sacrifices performance. If the performance hit proves to be intolerable, it shouldn't be too tough to do it rsc's way later.
Now I'm working to get rune -> BRTree working and presentable. When I finish, I think that will be a nice milestone for a code review (if you would be so kind @BurntSushi).
(*) Ken Thompson and friends like calling Unicode scalar codepoints "runes." I like it, but it isn't commonly used. If you think it will cause more confusion than it's worth, I can not use "rune" in the codebase.

Sounds great. I've also found RE2's compiler difficult to follow. Pulling out the byte range stuff so it can be tested sounds fantastic. As long as performance stays reasonable (even on large Unicode classes), then I'm happy. Make sure to test it on debug builds too. When I first introduced regex-syntax, the case folding code was pretty reasonable on release builds, but it was gratuitously slow on debug builds.
RE rune: I like rune too (being a gopher myself), but the Rust ecosystem unfortunately doesn't use that terminology, so it's probably best to avoid it in the code. Something like cp, or cpoint or codepoint or point or scalar should be fine. (Ignoring the subtle distinction between codepoint and scalar value... sigh)

Thanks, I wouldn't have thought to give special attention to debug builds. And roger, I'll get rid of rune.

Update: getting really close to having a working ScalarRange ->.byte_range::Tree compiler.
The structure of the new module is about where I want it. The one big roadblock left is in some helper functions I've written to test it. As a QuickCheck property, I assert that the transformation from a ScalarRange to a byte_range::Tree is invertible. That is, given a ScalarRange, you can convert it to a Tree and then convert the Tree back to the same ScalarRange. QuickCheck is finding examples where my Tree -> ScalarRange function is overflowing the stack. Fortunately, ScalarRange -> Tree (the important direction) isn't causing trouble. Nor is QuickCheck finding examples where the property doesn't hold (so far). Also, unit test coverage is decent.

@WillEngler Awesome! For Tree -> ScalarRange, you might want to try using an explicit stack if you care enough about passing that test.
Hmm, looking at the code, the Tree data type is scaring me a little. Is that intended to be embedded in Inst? Or is it an intermediate data structure? If the former, my hope was to encode the tree in terms of existing instructions (like Split, which is I think how RE2 does it). In particular, it would replace both the Char and Ranges instructions. If the latter, then that is unfortunately pretty heavyweight, but I think I'd be willing to live with it for now.

@WillEngler Do you have a sense for how big Tree gets?

@BurntSushi Thanks for the feedback.

For Tree -> ScalarRange, you might want to try using an explicit stack if you care enough about passing that test.

Yep, I got that done this afternoon. Now Tree::to_scalar_range() is big and ugly, but it works.

the Tree data type is scaring me a little.

Hehehe

Is that intended to be embedded in Inst? Or is it an intermediate data structure? If the former, my hope was to encode the tree in terms of existing instructions (like Split, which is I think how RE2 does it). In particular, it would replace both the Char and Ranges instructions. If the latter, then that is unfortunately pretty heavyweight, but I think I'd be willing to live with it for now.

I intended it as an intermediate data structure. Trying to look at it with fresh eyes, I see what you mean about it being heavyweight. I like the idea of encoding it directly in terms of the existing instructions rather than defining an entirely new type that the compiler needs to worry about and then break down. I'm pretty sure you suggested that before, but it's only really clicking now that I'm knee-deep in the problem.
I would much rather make big changes than go for a solution that is merely "liveable". So if it sounds good by you, I'd like to gut Tree and encode directly into the existing instructions. It won't have been effort wasted; I'm now confident that the fiddly bit-twiddling logic works as intended.

Do you have a sense for how big Tree gets?

It can get real big. More detailed answer forthcoming, but for now I'll say that suffix caching will help a lot.

It can get real big.

I see. I think that's enough of a reason to say, "Yeah, don't use it as an intermediate data structure."
With that said, you may find it more satisfying to mush on, get the instruction set updated and work on the matching engines. Then circle back around and fix up the Tree code. Up to you though. :-)

I see. I think that's enough of a reason to say, "Yeah, don't use it as an intermediate data structure."

I'm with you. I got wrapped up and couldn't see the forest for the... well, you know.

With that said, you may find it more satisfying to mush on...

As much as I love a good mush, it would drive me nuts to leave this module in a sloppy state. So I'll put off matching for a bit longer.

@WillEngler As a heads up, I've made some progress on this issue. In particular, a crate for generating UTF-8 ranges from scalar values: http://burntsushi.net/rustdoc/utf8_ranges/ I also have a basic DFA construction work (using utf8-ranges), although it doesn't have zero-width assertions or match priority (because they aren't really necessary in this particular context): https://github.com/BurntSushi/fst/blob/master/src/regex/dfa.rs --- Still lots of work to do before it's in good enough shape for regex though.
Also, I know @jneem has been doing a lot of work in this space, including possibly getting word boundaries working in a DFA. I'm not sure what their plans are though!

Yes, I do have word boundaries working in a DFA (and my proof-of-concept fork integrating it into this crate passes all the tests). But I'm taking the offline-compilation approach (maybe similar to the one of @carllerche), and my compilation times are pretty terrible right now, especially after incorporating the utf8_ranges crate to go from a char-based machine to a byte-based machine.

Thanks for the heads-up @BurntSushi! (And good timing: I've settled in after some big life changes and I'm able to carve out time for Rust again) I'll check out the progress that you and @jneem have made and try to figure out where I can be of help.

Nope, I was wrong. I still don't have the time to make an impact here. Thanks a million @BurntSushi for guiding me. I regret I didn't contribute much in return. I will return to Rust some day!

@WillEngler No regrets, please. :-) You actually made quite a large impact. At least for me personally, I learned a lot from our exchanges because you forced me to give more thought to DFAs than I had previously! I look forward to working with you in the future!


--config arguments appears to be ignored by cargo nextest

It appears that nextest ignores config flags specified as per https://doc.rust-lang.org/cargo/reference/config.html#command-line-overrides
Example: If I run
        cargo --config 'build.rustflags = [...]' test

it works as expected, and sets rustflags to the specified flags while building the test targets. However, changing test to nextest run causes the --config arg to be ignored.
I saw several other config-related issues have been opened, but this one seems to be distinct from those. If not, I apologize!

Thanks for the report! I believe if you pass in --config before nextest run it'll get eaten up by Cargo (this is honestly a bug in upstream Cargo I think, --config doesn't get passed down to plugins).
Instead, use this command:
        cargo nextest run --config 'build.rustflags = [...]'

which should work.

Oh hey that worked perfectly! Thanks so much!

@mystenmark I've reported this as https://github.com/rust-lang/cargo/issues/11031.


Request Instructions

How do you extract files from sources such as .minigsf or .vgz?  Further clarification in the instructions would make it easier.

I use towave for SNES and NES music, not sure if it'd work for those formats.

Super Mario RPG is an SNES game.
From: "vince94"<EMAIL_ADDRESS>To: "jimbo1qaz/corrscope"<EMAIL_ADDRESS>Cc: "Supremeoverlord3"<EMAIL_ADDRESS>"Author"<EMAIL_ADDRESS>Sent: Wednesday, August 7, 2019 2:17:47 PM
Subject: Re: [jimbo1qaz/corrscope] Request Instructions (#302)
I use towave for SNES and NES music, not sure if it'd work for those formats.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub , or mute the thread .

So yeah, I don't know what .minigsf or .vgz is, but SNES soundtracks are stored in the SPC file format, which towave supports.

Okay, so how do you use Corrscope to split files? .minigsf are Gameboy Advance files and .vgz covers a wide range of Yamaha music such as the YM3812, the PC88 and PC98 sound chips, arcade sound chips, and the Sega Mega Drive sound chips.
From: "vince94"<EMAIL_ADDRESS>To: "jimbo1qaz/corrscope"<EMAIL_ADDRESS>Cc: "Supremeoverlord3"<EMAIL_ADDRESS>"Author"<EMAIL_ADDRESS>Sent: Tuesday, August 20, 2019 1:41:41 PM
Subject: Re: [jimbo1qaz/corrscope] Request Instructions (#302)
So yeah, I don't know what .minigsf or .vgz is, but SNES soundtracks are stored in the SPC file format, which towave supports.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub , or mute the thread .

Corrscope doesn't split files, it's a program that visualizes WAVs. towave creates multiple WAVs based on various chip music formats, maybe that's what you're thinking of?
The workflow is this:
-Take the source/chiptune file you want to visualize. This is your SPC, minigsf, etc.
-Drop it into towave, generating individual WAV files for each channel
-Open corrscope and import all of the WAVs
-Render the final video

i was considering adding integration for a splitter. However I never ended up adding it.

towave (Windows build) is old and doesn't support fadeout.
I forked towave to vgmsplit (Windows build) with a better CLI than towave. However it currently links to mpyne's libgme which can't split Genesis PSG.
kode54's multidumper (Windows build) has a similar feature-set to vgmsplit and can split Genesis PSG, but is Windows-only (works under Wine).

None of the above support ripping different tracks in parallel on different CPU cores (though that should be easy to add).
I think they all use an inaccurate NES engine (though accurate SNES) engine.
None of the above support gsf/Sappy splitting, nor n64, etc.

Oh, so Towave is needed. That doesn't do anything with .minigsf. I am at a total loss as to how Colby Trimble did it.
From: "vince94"<EMAIL_ADDRESS>To: "jimbo1qaz/corrscope"<EMAIL_ADDRESS>Cc: "Supremeoverlord3"<EMAIL_ADDRESS>"Author"<EMAIL_ADDRESS>Sent: Wednesday, August 21, 2019 7:52:38 PM
Subject: Re: [jimbo1qaz/corrscope] Request Instructions (#302)
Corrscope doesn't split files, it's a program that visualizes WAVs. towave creates multiple WAVs based on various chip music formats, maybe that's what you're thinking of?
The workflow is this:
-Take the source/chiptune file you want to visualize. This is your SPC, minigsf, etc.
-Drop it into towave, generating individual WAV files for each channel
-Open corrscope and import all of the WAVs
-Render the final video
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub , or mute the thread .

https://www.youtube.com/watch?v=gxUy73q8Agw

I FINALLY GOT AGBPLAY TO BUILD AFTER ABOUT A DOZEN REINSTALLS OF CYGWIN, I AM MORE POWERFUL THAN EVER BEFORE

he uses agbplay

Thanks! I'll look into that.
From: "jimbo1qaz"<EMAIL_ADDRESS>To: "jimbo1qaz/corrscope"<EMAIL_ADDRESS>Cc: "Supremeoverlord3"<EMAIL_ADDRESS>"Author"<EMAIL_ADDRESS>Sent: Wednesday, August 21, 2019 10:34:27 PM
Subject: Re: [jimbo1qaz/corrscope] Request Instructions (#302)
https://www.youtube.com/watch?v=gxUy73q8Agw
I FINALLY GOT AGBPLAY TO BUILD AFTER ABOUT A DOZEN REINSTALLS OF CYGWIN, I AM MORE POWERFUL THAN EVER BEFORE
he uses agbplay
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub , or mute the thread .

Colby Trimble built using cygwin, and the resulting binary depends on cygwin.
https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin

MSYS2 provides a minimal shell required to run autotools and other build systems which get the source for software from the Internet from different repositories, configure them and build them.

Maybe you could try building using mingw-w64 (install using either mingw-builds or via msys2).
https://github.com/git-for-windows/git/wiki/The-difference-between-MINGW-and-MSYS2

MSYS2's runtime is \usr\bin\msys-2.0.dll. It is an implicit dependency of all MSYS2 executables (most of which live in \usr\bin). This runtime provides emulation for all POSIX functionality enjoyed e.g. by Linux software.
The POSIX emulation is slow.

Aw man, why can't they just make this simple?
From: "jimbo1qaz"<EMAIL_ADDRESS>To: "jimbo1qaz/corrscope"<EMAIL_ADDRESS>Cc: "Supremeoverlord3"<EMAIL_ADDRESS>"Author"<EMAIL_ADDRESS>Sent: Thursday, August 22, 2019 7:46:28 PM
Subject: Re: [jimbo1qaz/corrscope] Request Instructions (#302)
Colby Trimble built using cygwin, and the resulting binary depends on cygwin.
https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin
MSYS2 provides a minimal shell required to run autotools and other build systems which get the source for software from the Internet from different repositories, configure them and build them.
Maybe you could try building using mingw-w64 (install using either mingw-builds or via msys2).
https://github.com/git-for-windows/git/wiki/The-difference-between-MINGW-and-MSYS2
BQ_BEGIN
MSYS2's runtime is \usr\bin\msys-2.0.dll. It is an implicit dependency of all MSYS2 executables (most of which live in \usr\bin). This runtime provides emulation for all POSIX functionality enjoyed e.g. by Linux software.
The POSIX emulation is slow.
BQ_END
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub , or mute the thread .


Use normals from Unity meshes

Import normals from Unity mesh into vertex attributes during Merge, and export them in SetInMeshFilter

Great thanks!
Quick note about performances: I think that this:
verts[i].attributes["normal"] = new FloatAttributeValue(unityNormals[i]);

is not as efficient as that:
var normal = verts[i].attributes["normal"].asFloat().data
normal[0] = unityNormals[i].x;
normal[1] = unityNormals[i].y;
normal[2] = unityNormals[i].z;

because it saves an allocation per point. Merging anyway cause I agree that 1. there are some parts of the code where I do 'new's that could be optimized like this and 2. the API is not as comfortable in the second case. Maybe adding a method fromVector(Vector3 v) to FloatAttributeValue could be a good start.


missing LICENSE file

Hello, I noticed there's no open source license file in this repo. I'm guessing it should be the Apache license that's in most of the other activitypods repos (another issue is those files don't have the copyright holder information filled in near the bottom).

Thanks for the reminder, it has been added ! https://github.com/activitypods/mastopod/blob/master/LICENSE


TestForwarderTestSuite/TestCombinations/Ip/Kernel/Wireguard  is unstable

TestForwarderTestSuite/TestCombinations/Ip/Kernel/Wireguard  is unstable
Build
https://github.com/networkservicemesh/cmd-forwarder-vpp/runs/4342269191?check_suite_focus=true

@NikitaSkrynnik
we still have :0 port here: https://github.com/networkservicemesh/cmd-forwarder-vpp/runs/4342269191?check_suite_focus=true#step:5:3674
Could you please take a look?

May be related to https://github.com/networkservicemesh/cmd-forwarder-vpp/pull/410

Fixed by https://github.com/networkservicemesh/cmd-forwarder-vpp/pull/418


Install Failure on Windows 10 (R Package from CRAN)

install.packages("feather")
Installing package into ‘C:/Users/BSP/Documents/R/win-library/3.2’
(as ‘lib’ is unspecified)
Package which is only available in source form, and may need compilation of
C/C++/Fortran: ‘feather’
Do you want to attempt to install these from sources?
y/n: y
installing the source package ‘feather’
trying URL 'https://cran.rstudio.com/src/contrib/feather_0.0.1.tar.gz'
Content type 'application/x-gzip' length 49068 bytes (47 KB)
downloaded 47 KB
Loading required package: datasets
Loading required package: utils
Loading required package: pryr

installing source package 'feather' ...
** package 'feather' successfully unpacked and MD5 sums checked
** libs

*** arch - i386
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c RcppExports.cpp -o RcppExports.o
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c feather-read.cpp -o feather-read.o
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c feather-types.cpp -o feather-types.o
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c feather-write.cpp -o feather-write.o
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c feather/buffer.cc -o feather/buffer.o
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c feather/feather-c.cc -o feather/feather-c.o
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c feather/io.cc -o feather/io.o
feather/io.cc:18:0: warning: "NOMINMAX" redefined [enabled by default]
c:\rbuildtools\3.3\gcc-4.6.3\bin../lib/gcc/i686-w64-mingw32/4.6.3/../../../../include/c++/4.6.3/i686-w64-mingw32/bits/os_defines.h:46:0: note: this is the location of the previous definition
g++ -m32 -std=c++0x -I"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/include" -DNDEBUG -I.   -I"C:/Users/BSP/Documents/R/win-library/3.2/Rcpp/include" -I"d:/RCompile/r-compiling/local/local323/include"     -O2 -Wall  -mtune=core2 -c feather/metadata.cc -o feather/metadata.o
feather/metadata.cc:29:7: error: expected nested-name-specifier before 'FBString'
feather/metadata.cc:29:7: error: 'FBString' has not been declared
feather/metadata.cc:29:16: error: expected ';' before '=' token
feather/metadata.cc:29:16: error: expected unqualified-id before '=' token
feather/metadata.cc:32:7: error: expected nested-name-specifier before 'ColumnVector'
feather/metadata.cc:32:7: error: 'ColumnVector' has not been declared
feather/metadata.cc:32:20: error: expected ';' before '=' token
feather/metadata.cc:32:20: error: expected unqualified-id before '=' token
feather/metadata.cc:178:3: error: 'ColumnVector' does not name a type
feather/metadata.cc: In member function 'feather::Status feather::metadata::TableBuilder::Impl::Finish()':
feather/metadata.cc:146:5: error: 'FBString' was not declared in this scope
feather/metadata.cc:146:14: error: expected ';' before 'desc'
feather/metadata.cc:148:7: error: 'desc' was not declared in this scope
feather/metadata.cc:154:9: error: 'desc' was not declared in this scope
feather/metadata.cc:156:27: error: 'columns_' was not declared in this scope
feather/metadata.cc:157:34: error: unable to deduce 'auto' from ''
feather/metadata.cc: In member function 'void feather::metadata::TableBuilder::Impl::add_column(const flatbuffers::Offsetfeather::fbs::Column&)':
feather/metadata.cc:173:5: error: 'columns_' was not declared in this scope
feather/metadata.cc: In constructor 'feather::metadata::TableBuilder::TableBuilder()':
feather/metadata.cc:190:5: error: type 'feather::metadata::TableBuilder' is not a direct base of 'feather::metadata::TableBuilder'
make: *** [feather/metadata.o] Error 1
Warning: running command 'make -f "Makevars" -f "C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/etc/i386/Makeconf" -f "C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/share/make/winshlib.mk" CXX='$(CXX1X) $(CXX1XSTD)' CXXFLAGS='$(CXX1XFLAGS)' CXXPICFLAGS='$(CXX1XPICFLAGS)' SHLIB_LDFLAGS='$(SHLIB_CXX1XLDFLAGS)' SHLIB_LD='$(SHLIB_CXX1XLD)' SHLIB="feather.dll" OBJECTS="RcppExports.o feather-read.o feather-types.o feather-write.o"' had status 2
ERROR: compilation failed for package 'feather'

removing 'C:/Users/BSP/Documents/R/win-library/3.2/feather'
Warning in install.packages :
running command '"C:/Users/FREAKA~1/DOCUME~1/R/R-32~1.5/bin/x64/R" CMD INSTALL -l "C:\Users\BSP\Documents\R\win-library\3.2" C:\Users\FREAKA~1\AppData\Local\Temp\Rtmp8QDO0Z/downloaded_packages/feather_0.0.1.tar.gz' had status 1
Warning in install.packages :
installation of package ‘feather’ had non-zero exit status

The downloaded source packages are in
‘C:\Users\BSP\AppData\Local\Temp\Rtmp8QDO0Z\downloaded_packages’

Unfortunately feather is only supported in R >3.3.0 on windows (that's the first version to gain the C++ support that we need)

Thanks, all is well with the upgrade install.


fix: infinite recursion in empty folder with hide_root_node = true

fixes #714
the second commit is to avoid this from potentially happening in other edge cases

On the recursive loop topic, I would add these thoughts:
I think it is technically just looking for the closest parent which is a directory, so 256 is a very high number. The parents that are not directories are really just things like grouped files.
That being said, the correct way to fix this is to find the missing condition(s) that should break out of the recursion. Something like "if node is nil or node == prior_node".
Also, if we wanted a safety just in case we mess up the base case for the recursion, the line number of the buffer is technically the max possible number of levels that you could travel upwards in a tree. You could use that and it would work correctly as an escape hatch.

commands.lua

Addressed

its probably just better to do a bit of string checking at that point to ensure there is something to append to _empty_message

There might be a bug with the original line 1168, but I don't think that's what's causing this bug. AFAIK the issue was either that skip_node removes the folder node completely so get_folder_node is unable to find the folder node, or that the _empty_message node was not a child of the folder node, so I let the parent node display the empty message and that fixed the issue. I tried altering the original _empty_message node (e.g. the snippet below) but all it ended doing was creating a new file in foo_empty_message/<file_name> instead of what should have been foo/<file_name>, I wonder if we should just make the id state.path instead and call that a day.
  if sourceItems then
    -- normal path
    if is_empty_with_hidden_root then
      local nodeData = {
        id = state.path .. "_empty_message",
        name = "(empty folder)",
        type = "message",
        level = 0,
        is_last_child = true,
      }
      local node = NuiTree.Node(nodeData, {})
      sourceItems[1].children = {node}
    end
    local nodes = create_nodes(sourceItems, state, level)
    draw(nodes, state, parentId)
  else

@miversen33 I'm not sure if you have permission to review or not. If you do have permission to approve and merge, I'll trust your review and you can proceed as you see fit.

Also, can you please update the merge target to nvim-neo-tree:v2.x? I believe we don't merge into main on this repo

CONTRIBUTING.md seems to say otherwise: https://github.com/nvim-neo-tree/neo-tree.nvim/blob/v2.42/CONTRIBUTING.md#branching

Pull Requests, however, should go to the main branch

btw, should I keep a clean commit history and force push, or just keep all the commits?

@figsoda  Good catch! My bad :) I can't answer the second question, that is up to @cseickel

btw, should I keep a clean commit history and force push, or just keep all the commits?

It's up to you. Most of the time I would just do a squash commit anyhow. If you had taken care to make a beautiful line up of well crafted commits with clean messages, I would rebase to preserve that, but that's really only needed in a large refactor.
Most PRs should just end up as a single squashed commit when merged, so I wouldn't change anything.

sounds good, I will just keep the commit history then since it will still make sense in a single commit


Replace version drop-down with version field

If it wasn't too difficult, would it make sense to replace the version dropdown with a version field that can be filled in by users ... then it might not be required to  make a jadeite release to coincide with every gemstone release  ... i suppose this probably would make sense to go along with clientlibs support, since the user would download a new clientlib (or internal dev create new directory in clientlibs and copy libs there manually) and not need to rely on a jadeite release to provide the new libs ... just thinking out loud :)
Originally posted by @dalehenrich in https://github.com/GemTalk/Jadeite/issues/859#issuecomment-825941858

This is do-able. Would like to discuss sometime as one nice thing about the current setup is that client libs don't need to be considered during login, currently.

The drop-down is convenient, and less error-prone than typing a version number. Perhaps the drop-down could be built automatically from the versions actually in the library directory?


⚠ Unifi Controller has degraded performance

In 35aea77, Unifi Controller (https://unifi.vflits.com/) experienced degraded performance:

HTTP code: 200
Response time: 11970 ms

Resolved: Unifi Controller performance has improved in d0f2a77 after 21 minutes.


make sure that VarIntLen can be inlined

Codecov Report

Merging #2080 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2080      +/-   ##
==========================================
+ Coverage   85.56%   85.56%   +0.01%
==========================================
  Files          99       99
  Lines        7221     7224       +3
==========================================
+ Hits         6178     6181       +3
  Misses        762      762
  Partials      281      281

Impacted Files
Coverage Δ

internal/utils/varint.go
73.77% <100%> (+1.36%)
: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 2133d01...f885462. Read the comment docs.


Add a resync window, allow for longer codes to be used

The main changes in this pull request are to add a resync window and to allow for longer codes to be used (configurable through a PAM option).
In addition to that, some of the other commits include:

Add PAM options for window sizes.
Add a base32 utility program, and support for padding when encoding and decoding.
A few other changes, including addressing potential bugs found through static anlysis and turning on addition compiler warnings.

This change is

The commit logs will have the details of each change, but please let me know if you would prefer me to split this into multiple pull requests.

Fyi, I'm following up with authorized signers at my company regarding the CLA.  I'll comment again once that is sorted out.

My company, Two Sigma, has signed the CLA and has added me to the tsos-google-contributors group.

Thanks for all the comments.  I'm a bit swamped with other things at the moment, but I'll take a look at all of them in a few days.

Stay off my phone!!!!
Carmen Slattery
On Feb 10, 2016 3:27 PM, "Eric Haszlakiewicz"<EMAIL_ADDRESS>wrote:

Thanks for all the comments. I'm a bit swamped with other things at the
moment, but I'll take a look at all of them in a few days.
—
Reply to this email directly or view it on GitHub
https://github.com/google/google-authenticator/pull/525#issuecomment-182588848
.

I updated hawicz/google-authenticator with changes which I believe should address all the comments on the original changesets (https://github.com/hawicz/google-authenticator/tree/pullreq1).  It looks like this pull request got updated automatically, even though it still says I only added commits back in September.

I have manually merged a bunch of these changes. Mostly the ones that have nothing to do with the others.
I'm a bit lost in all my comments (I incorrectly commented on the commits instead of the file changes in the github interface, adding to the confusion), but I think there are still commits in the pull request that fix things from earlier commits in the same pull request.
The -Werror one seems unnecessary though. I can get the same effect with just make CFLAGS="-Werror -Wall"

Please do not ignore my problems. Regarding same thing again and again

Please my google accounts 2 step verification is off so no verification to the next part... Backup code problem. Please proved that backup code

My all gmail accounts is same problem with that mobile phone.... Every day my gmail accounts trying to get the chance of the day

Is this still active?

Understandably I no longer remember how far I got on this. Which part of the pull request are you missing?

I was just trying to help move this PR forward as it is unclear (to me at least) what more needs to be done.  At the very least it needs a rebase.

Yeah there's lots left to merge from this pull request. Rebasing it is quite a bit of work and since I don't need it and nobody else has asked for it I'm not prioritizing it.
I'd accept someone else doing it though, and sending patches.

Спасибо за ваш запрос. Похоже, что это может быть вашим первым вкладом в проект с открытым исходным кодом Google, и в этом случае вам нужно будет подписать лицензионное соглашение участника (CLA).
Пожалуйста, посетите https://cla.developers.google.com/, чтобы подписать.
После того как вы подписались, пожалуйста, ответьте здесь (например I signed it!), и мы проверим. Благодарю.

Если вы уже подписали CLA, возможно, у нас нет вашего имени пользователя GitHub или вы используете другой адрес электронной почты. Проверьте свои существующие данные CLA и убедитесь, что ваша электронная почта установлена в ваших git коммитах .
Если вы подписали CLA как корпорация, пожалуйста, сообщите нам название компании.

I signed

Closing due to lack of interest from anyone, and the fact that the code has been moved to the google/google-authenticator-libpam repo


[OSE-300] Credential applications can be cancelled

Overview
After a credential application is submitted, an operation is returned. This PR adds the ability to cancel the operation related to that application.
Description
All operations can be cancelled, as long as they aren't marked as done.
How Has This Been Tested?
Added a simple unit test to the service endpoint.
Checklist
Before submitting this PR, please make sure:

[x] I have read the CONTRIBUTING document.
[x] My code is consistent with the rest of the project
[x] I have tagged the relevant reviewers and/or interested parties
[x] I have updated the READMEs and other documentation of affected packages

Codecov Report

Merging #234 (41c17e4) into main (a138310) will decrease coverage by 1.12%.
The diff coverage is 70.37%.

:exclamation: Current head 41c17e4 differs from pull request most recent head ba5409b. Consider uploading reports for the commit ba5409b to get more accurate results

@@            Coverage Diff             @@
##             main     #234      +/-   ##
==========================================
- Coverage   25.93%   24.80%   -1.13%
==========================================
  Files          28       31       +3
  Lines        2738     2919     +181
==========================================
+ Hits          710      724      +14
- Misses       1911     2076     +165
- Partials      117      119       +2

Impacted Files
Coverage Δ

pkg/service/operation/submission/submission.go
0.00% <ø> (-17.65%)
:arrow_down:

pkg/service/operation/storage.go
21.27% <70.37%> (ø)

pkg/service/operation/model.go
0.00% <0.00%> (ø)

pkg/service/operation/service.go
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


add channeltype and channelstatus

here are some information about ChannelType and ChannelStatus：
ChannelTypeFree                    = 0
ChannelTypeNovice                = 1
ChannelTypeNoviceLowKAD   = 2
ChannelTypeClan                    = 3
ChannelTypeBigCity                = 4
ChannelTypeActive                  = 5 //only open for active
ChannelStatusBusy              = 0
ChannelStatusNormal         = 1

and i found something about InHostIngame_RoundEnd packet：
{
winningTeamNum uint8
terWins uint8
ctWins uint8
type uint8             //maybe i think
if type !=0 {          // more data
hostID     uint32
unk00      uint32
}
}


gnome-shell: add missing python3 deps for gnome-shell-extension-tool

Things done

[x] Tested using sandboxing (nix-build --option build-use-chroot true or nix.useChroot on NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

This commits adds missing python3 deps for gnome-shell-extension-tool to run.
Fix #14651

/cc @lethalman

It works like this. I'm trying to remove the line --prefix GI_TYPELIB_PATH : "$GI_TYPELIB_PATH" because I'm not sure if it's necessary.

I have the impression this line is not necessary.

I have the impression this line is not necessary.

I'll try without it.

@DamienCassou Removed, it was indeed not needed.

Thanks.


Add link for gentleman-logger

Thanks for creating an awesome software!
I creates a simple plugin, gentleman-logger for logging requests and responses.
I would like to add this plugin to README 😃

Looks nice, thank you!


Support time intervals for scale.nice

Supersedes vega/vega#966.

Related: https://github.com/vega/vega/issues/970

Fixed and released in vega-encode v2.0.1. Fixes handling of time interval specifiers for scale nice and axis/legend tickCount. Both interval strings (e.g., "year" or "month") and interval objects (e.g., {"interval": "year"} or {"interval": "month", "step": 3} are supported.
Note that scale nice only modifies the scale domain, nothing else. To change the ticks that are generated, you must use an interval specification for the axis/legend tickCount property.


Allow assigning choice adventures to string values

For example this can enable the usage of
choices: { 1435: () => `1&heyscriptswhatsupwinkwink=${monster.id}` }

for Leading Yourself Right to Them

Thanks!


File Formats requiring optional parameters

Version:
0.25.11
I create a basic file_format as per: https://registry.terraform.io/providers/chanzuckerberg/snowflake/latest/docs/resources/file_format
With just the mandatory values.
Here is my version:
"PARQUET_RAW" = {
name            = "PARQUET_RAW"
comment         = "PARQUET file format"
database        = "RAW"
schema          = "SHARED"
format_type     = "PARQUET"
}
resource "snowflake_file_format" "file_formats" {
provider    = snowflake.system_admin
depends_on  = [snowflake_database.databases, snowflake_schema.schemas]
for_each    = local.file_formats
name        = each.value.name
comment     = each.value.comment
format_type = each.value.format_type
database    = each.value.database
schema      = each.value.schema
}
Expected behavior
First run everything works as expected.
Second run, TF fails and wants me to provide optional params
snowflake_file_format.file_formats["PARQUET_RAW"] will be updated in-place
~ resource "snowflake_file_format" "file_formats" {
- compression                    = "AUTO" -> null
id                             = "RAW|SHARED|PARQUET_RAW"
name                           = "PARQUET_RAW"
# (22 unchanged attributes hidden)
}
So... I add compression to fix this issue, but then I get a new issue where it wants the next optional param defined
How can I set a very basic set of file_formats with just the mandatory params?
Want to set this:
locals {
file_formats = {
"AVRO_RAW" = {
name            = "AVRO_RAW"
comment         = "Avro file format"
database        = "RAW"
schema          = "SHARED"
format_type     = "AVRO"
}
"CSV_RAW" = {
name            = "CSV_RAW"
comment         = "CSV file format"
database        = "RAW"
schema          = "SHARED"
format_type     = "CSV"
}
"JSON_RAW" = {
name            = "JSON_RAW"
comment         = "JSON file format"
database        = "RAW"
schema          = "SHARED"
format_type     = "JSON"
}
"ORC_RAW" = {
name            = "ORC_RAW"
comment         = "ORC file format"
database        = "RAW"
schema          = "SHARED"
format_type     = "ORC"
}
"PARQUET_RAW" = {
name            = "PARQUET_RAW"
comment         = "PARQUET file format"
database        = "RAW"
schema          = "SHARED"
format_type     = "PARQUET"
}
"XML_RAW" = {
name            = "XML_RAW"
comment         = "XML file format"
database        = "RAW"
schema          = "SHARED"
format_type     = "XML"
}
}
}
and run this:
resource "snowflake_file_format" "file_formats" {
provider    = snowflake.system_admin
for_each    = local.file_formats
name        = each.value.name
comment     = each.value.comment
format_type = each.value.format_type
database    = each.value.database
schema      = each.value.schema
}

I am also getting changes to optional parameters I never set on a subsequent plan. I thought it was also worth noting that the values Terraform says the attributes are being changed from are not necessarily the real values in the Snowflake DB. For example, if I show my file_format in the Snowflake console, I see {"TYPE":"CSV","RECORD_DELIMITER":"\n",... in the format_options. But Terraform is saying that the record delimiter is currently set to an "end of transmission" character, not the newline character it is actually set to:
# snowflake_file_format.csv_custom will be updated in-place
  ~ resource "snowflake_file_format" "csv_custom" {
      - binary_format                  = "HEX" -> null
      - compression                    = "AUTO" -> null
      - date_format                    = "AUTO" -> null
      - encoding                       = "UTF8" -> null
      - escape                         = "NONE" -> null
      - escape_unenclosed_field        = "\\" -> null
      - field_delimiter                = "," -> null
        id                             = "EXAMPLE|EXAMPLE|CSV_CUSTOM"
        name                           = "CSV_CUSTOM"
      - record_delimiter               = <<-EOT

        EOT -> null
      - time_format                    = "AUTO" -> null
      - timestamp_format               = "AUTO" -> null
        # (23 unchanged attributes hidden)
    }

For now, I have created the work around by telling Terraform not to track changes. Something like
lifecycle {     ignore_changes = [       binary_format,       compression,       date_format,       encoding,       escape_unenclosed_field,       field_delimiter,       record_delimiter,       time_format,       timestamp_format,       skip_byte_order_mark,       validate_utf8     ]   }

Any updates on this issue, we are also getting this error. Even for parameter VALIDATE_UTF8 which is obsolete now.
Error: error updating file format validate_utf8 on DB|SCHEMA|FILE_FORMAT: 001008 (22023): SQL compilation error:
│ invalid value [false] for parameter 'VALIDATE_UTF8'


lidar_perception can't work in 5.0.0

We appreciate you go through Apollo documentations and search previous issues before creating an new one. If neither of the sources helped you with your issues, please report the issue using the following form. Please note missing info can delay the response time.
System information

**OS Platform and Distribution ( Ubuntu 14.04):
**Apollo installed from (source):
*Apollo version (5.0)

Steps to reproduce the issue:
when I use cyber_launch start /apollo/modules/perception/production/launch/perception.launch to run perception model,The following problems arise， i use VLP-16 and Leopard camera.

you need to ensure LidarObstacleSegmentation model_configs is in /apollo/modules/perception/production/conf/perception/lidar/modules/lidar_obstacle_pipeline.config

you need to ensure LidarObstacleSegmentation model_configs is in /apollo/modules/perception/production/conf/perception/lidar/modules/lidar_obstacle_pipeline.config

thanks you are right ，I modified the DAG file earlier


Add input so we can paste a github url

Similarly, allowing browsing via a GitHub repository root folder?

allowing browsing via a GitHub repository root folder?
We'll add that when we fix #49


ZeroMQ export connector

Duplicate functionality found in the Java export client and export distro services to allow for export to a ZeroMQ endpoint

Moved this back to Delhi, but it could get moved back even further.


Update hyperkube image from v1.9.2 to v1.9.3

Starting conformance tests...

Erm.
+ ./build/build-image.sh
[1075570.543824] golang[6]: rm -rf _output
[1075572.142557] golang[6]: /bin/bash: terraform: command not found
[1075572.142999] golang[6]: Makefile:33: recipe for target 'check' failed
[1075572.143288] golang[6]: make: *** [check] Error 1

Related to https://github.com/kubernetes-incubator/bootkube/pull/883 @rphillips ?

Looks like make release now causes the check target to be run, which assumes terraform is present. This isn't the case in our build/release image https://github.com/kubernetes-incubator/bootkube/blob/master/build/build-release.sh#L9. Is this an oversight or have I missed something?

Thoughts? https://github.com/kubernetes-incubator/bootkube/pull/896

Great, I can rebase on that and check if it fixes conformance tests.

[1089952.518669] golang[6]: [ 4124.711759] golang[6]: Feb 15 22:38:05.912: INFO: Running AfterSuite actions on node 1
[1089952.518936] golang[6]: [ 4124.711969] golang[6]: Ran 148 of 710 Specs in 3105.534 seconds
[1089952.519138] golang[6]: [ 4124.712194] golang[6]: SUCCESS! -- 148 Passed | 0 Failed | 0 Pending | 562 Skipped PASS


Proper error handling and responses by controllers

I initially thought that if you send a response in Express that it would return from the function, but that is incorrect. I was therefore getting errors in certain circumstances where it was complaining that I was trying to set headers that have already been sent (essentially, the code was trying to send multiple responses to one request). Unfortunately, the bad example that I set was also followed by teammates in other routes.
We need to go through our controllers and make sure that responses are only sent in one place for each route and that if an error occurs earlier in the code, that it is thrown/handled properly. I briefly looked into this and it sounds like if an error is thrown in a synchronous function, Express will catch the error automatically. However, if an error is thrown in an asynchronous function, you must pass the error to the next function.
From there, the error is sent to an error handler. If a custom error handler is not created, the error will go to the default error handler, which will essentially pass along the error message and set the status to 500 (unless the error also provides a status code) and send the response to the user.
At the very least we should be passing our errors to next and letting the default error handler do its thing. We might also consider writing our own custom error handlers.

I started remedying this situation, along the following lines:

Created an HttpError class under a new models directory that we can use to pass along custom errors.
Created a custom error handler at the end of index.js, that either uses the statuses and messages we set on the HttpError object, or sends an unknown error.
Modified the main functions I was mostly responsible for by, in the catch statements, logging the error (for development), and passing  a custom HttpError along to next with a relevant message and status code (for the clients).

I didn't add custom error handling to every helper function because, I think, that will be caught by the main functions.


Move wait_q.h/timeout_q.h to be internal kernel headers

wait_q.h and timeout_q.h are not a public header and should not be exposed as such. Move it back to kernel/include and change code to not use it.

kernel: move timeout_q.h to kernel/includ
arch: remove wait_q.h include
kernel: move wait_q.h header to be internal

sof seems to depend on zephyr/timeout_q.h

sof seems to depend on zephyr/timeout_q.h

yep, this needs to be fixed...  @lyakh  @kv2019i  can you please take a look and see how you can drop this dependency on this header and API which is an internal zephyr kernel API. Sorry about the confusion.

yep, this needs to be fixed... @lyakh @kv2019i can you please take a look and see how you can drop this dependency on this header and API which is an internal zephyr kernel API. Sorry about the confusion.

@lyakh @kv2019i You may be able to find inspiration for the conversion in commit 7f7201f79ba6cfcf3070ec1cd38265754b1b5c8b

SOF side change under review at https://github.com/thesofproject/sof/pull/8146 . We had a very specific case where we needed to call z_abort_timeout() on "timer->timeout" directly -- discussion now ongoing whether we can simply replace with k_timer_stop() or is there something stop does that causes as problems (and maybe something that needs to be kept in public interface of the timer).


Why the<EMAIL_ADDRESS>don't support node 9..

I was install<EMAIL_ADDRESS>in window 10 and node 9.10.1
Got a error message:

<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "6.* || 8.* || >= 10.*". Got "9.10.1"

NPM package sane refers to another project: https://github.com/amasad/sane This one provides sane-cli package and has nothing to do with sane npm package.

Thanks 😊


How to capture text portion of liked posts?

I have run TumblrThree on my likes a few times now in different configurations. I have selected all of the meta options and the dump crawler data option. And yet it successfully downloads images and pictures but there is no txt or json file to be found anywhere. Is it stored outside the blog folder or something? Or is it not possible to download the actual liked posts?

It's not possible (yet), hence there is no option for it.
Someone has to take the time and implement it. There are/were already numerous issues opened for this, for example #175, #338, #292, #232.


[Enhancement] Possibility to resize the rect of VideoController

From the documentation:
/// 1. You can limit size of the video output by specifying `width` & `height`.
///    By default, both `height` & `width` are `null` i.e. output is based on video's resolution.

Currently, I initialize the video with 640x360, but I find the need to use a smaller resolution when the video is resized (192x144). Would it be possible to change the height and width of the VideoController?
I tried to create different video controllers with different resolutions, but it seems that the second controller isn't created if one controller is already initialized. It also crashes when the second controller is initialized. Is that by design?

This is going to be fairly large time investment with no real benefits to our most customers. I'll re-evaluate in future.
Implementation, logic changes & most importantly ensuring stability etc. can be challenging.
Most users aren't passing any width or height anyway.

I agree with implementing it, I need it for my application too.
Reducing the size of textures reduces CPU and GPU consumption (it makes sense), which I need to play 4K videos on my old MacBook without the fans burning out ^^

This is going to be fairly large time investment with no real benefits to our most customers.

In fact, I think it can be done relatively quickly, by adding a setter that overrides the width and height values passed as optional parameters when creating VideoOutput.
When these values are non-null, the render size is then "fixed":
https://github.com/alexmercerind/media_kit/blob/03d8a702d5c0600e94548fd68a6b71c1485a0e49/media_kit_video/common/darwin/Classes/VideoOutput.swift#L131-L141
If, when rendering, a different size is found, the texture is resized:
https://github.com/alexmercerind/media_kit/blob/03d8a702d5c0600e94548fd68a6b71c1485a0e49/media_kit_video/common/darwin/Classes/VideoOutput.swift#L111-L117
@alexmercerind  I copied the logic of what you did for Linux and Windows.
(I forgot to rename the width and height variables to requiredWidth and requiredHeight like for Linux and Windows).
I will create a pull request to experiment with this for macOS and iOS.

I will still stand by my point that this is an overkill. Sure, I will do it for Windows & Linux (now that PR is here).
Being able to pass an initial texture size was already a good feature which no other existing packages offer. We are very good from feature & performance standpoint. My biggest concern is stability, I aim to not touch video embedding code too much in future. Every slight change can result in major issues e.g. threading, rendering, syncing, invalid memory access etc.
A good amount of time needs to be given to the testing afterwards. I aim for those in future (if possible). Let's land this pull request after next release. I want to release API refactor, track selection & macOS/iOS support in this version.

I copied the logic of what you did for Linux and Windows.

It's good to have same degree of similarity. Thanks!


docker: avoid additional apt packages by --no-install-recommends

Description
This will help we keep the image not too heavy that caused by those
additional, suggestion apt packages.
Only install the packages we explicitly want.
Checklist

[ ] I have updated tests where applicable.
[ ] I have added an entry to the CHANGELOG.

Interesting... in this case, gosu doesn't have any suggested packages, which shouldn't make any difference, I'll take a look...

The Coverage CI is just flaky, this seems good. Thanks!

Looks so, thanks!


[#4751] Update library

thrift 0.10.0 -> 011.0
spotbug 3.1.3 -> 3.1.8-SNAPSHOT

Codecov Report

Merging #4756 into master will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4756      +/-   ##
==========================================
- Coverage   40.48%   40.42%   -0.06%
==========================================
  Files        2570     2570
  Lines       78296    78296
  Branches    10642    10642
==========================================
- Hits        31695    31652      -43
- Misses      43711    43757      +46
+ Partials     2890     2887       -3

Impacted Files
Coverage Δ

...ookeeper/exception/PinpointZookeeperException.java
28.57% <0%> (-28.58%)
:arrow_down:

...uster/zookeeper/exception/ConnectionException.java
0% <0%> (-28.58%)
:arrow_down:

.../cluster/zookeeper/ZookeeperExceptionResolver.java
0% <0%> (-26.93%)
:arrow_down:

...p/pinpoint/rpc/client/WriteFailFutureListener.java
56.25% <0%> (-18.75%)
:arrow_down:

...rp/pinpoint/rpc/control/ControlMessageDecoder.java
64.28% <0%> (-14.29%)
:arrow_down:

...vercorp/pinpoint/rpc/packet/ClientClosePacket.java
55.55% <0%> (-11.12%)
:arrow_down:

.../pinpoint/rpc/client/PinpointClientHandshaker.java
60% <0%> (-5%)
:arrow_down:

...r/zookeeper/ZookeeperClusterDataManagerHelper.java
78.18% <0%> (-3.64%)
:arrow_down:

...cluster/zookeeper/ZookeeperClusterDataManager.java
65.3% <0%> (-3.41%)
:arrow_down:

...java/com/navercorp/pinpoint/rpc/DefaultFuture.java
72.5% <0%> (-1.67%)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

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


Inherit model properties from super classes

Is your feature request related to a problem? Please describe.
When you look to the last section: I wish that B had the id field as well. Currently, this doesn't seem to be the case. It can lead to reduction of boilerplate code and better maintainability.
I can imagine scenarios where you don't want to inherit these properties. In this case one could add an Annotation on the inheriting class like: @DoNotInheritModelProperties
Describe the solution you'd like
See above
Describe alternatives you've considered
See above.
Additional context
´´´
class A extends Model {
@Column
int id;
}
class B extends A {}
´´´

Because of the way inheritance works in java (fields aren't actually inherited to the child class, they only exist on the parent class) this would probably break the current implementation. I thought of this before because you sometimes have quite similar models and might want to inherit fields from a base class. This is something we should consider when rebuilding/decoupling the query builder.


fetchurl: enable TLS verification when credentials are used

Description of changes
This change ensure the credentials cannot be leaked in a MITM attack. Note that this change might break some existing deployments if the users tries to fetch resources on endpoints with invalid certificates. The impacted users will have the following choices:

fix the endpoint providing the resource.
override SSL_CERT_FILE to either disable the verification (not recommended) or to set it to a path including their CA certificate.

We probably should enable the TLS verification in all cases (like it is the case for fetchgit) but doing it this way allows us to quickly provide a fix for the main issue. I will open a PR against staging after this to do that.
No functional changes are expected in nixpkgs since there is no usage of netrcPhase.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/security-advisory-unsafe-handling-of-credentials-in-pkgs-fetchurl/52767/1

We probably should enable the TLS verification in all cases (like it is the case for fetchgit) but doing it this way allows us to quickly provide a fix for the main issue.

Do we still plan to do that?

Yes, I still plan to do that. I just have been a bit too short on time recently.


Implements results filtering for raycastAll and raycastFirst

Fixes #5143
Fixes #5161

[x] Requires #5179 to be merged first as raycastFirst entity & custom filtering requires raycastAll results to be sorted.
[x] Requires #5181 result as it might be breaking the raycastFirst with filters.

Implements filtering for raycastAll and raycastFirst through a new options parameter. It includes filtering from collision group, collision mask, entity tags and custom function.
Changes to RigidBodyComponentSystem public API:

raycastFirst(start, end, options)
raycastAll(start, end, options)

Options declares as follow for filters:
{
    filterCollisionGroup: 0,
    filterCollisionMask: 0,
    filterTags: [ ],
    filterCallback: (entity) => !!entity
}

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

This is cool. I'm thinking that this PR could benefit from using the @example tag to show some different patterns for calling the raycast function and apply the different types of filters. I found it non-obvious as to how you'd write a tags-based query for example.

Thanks for your feedback @willeastcott, here's a new commit with the examples for tags filtering as well as callback filtering, including one with both to make sure users understand that it's an AND filtering and not an OR filtering when applying multiple filters.

Yay - another great addition! Thanks. 🙏

I believe this PR created an issue here: https://github.com/playcanvas/engine/issues/5367


[CHORE]: Organise and refactor custom tag widgets.

What is the chore?

UsersTagBaseForm needs a query filter in the choices widget.


Azure: Create ansible user via unattend

Ansible provisioning should happen with a different user than "vagrant" because it needs to change the password for the vagrant user, which causes WinRM authentication issues.

Fixed in PR #465


Dotnet update

PR Summary

PR Context

PR Checklist

[ ] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[ ] Summarized changes
[ ] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[ ] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[ ] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[ ] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:

[ ] Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
(which runs in a different PS Host).

[ ] Issue filed:

[ ] Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.

[ ] Issue filed:

[ ] Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).

[ ] Issue filed:

[ ] Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[ ] Issue filed:

And not any of the PR checklist items have been filled out.  It would be better to submit focused PR's e.g. one for changes to the README.md. And another for changes to the SubsystemManger.cs.  And another for the addition of Windows 7 32-bit zip files.

Close this PR as it doesn't honor the PowerShell pull request template.


Customize shape of Slide Toggle component

Describe the bug
I Expected that slide toggle looks can be customized. but I checked and cannot find any configuration which can change height of the component. I tried even density set to -4 is not working on slide toggle.
Expected behavior
I think so some of the styling of slide toggle should be available. Like color, height, width etc

Hi Hitish99. Sorry about the late reply. It's interesting that the slide toggle is not affected by the density setting.
In terms of additional styling options, the Angular component doesn't seem provide any options for doing so.

One workaround is to see to include a CSS stylesheet and try to avoid override the slide toggle styling. This can be done by including a stylesheet through the page object. The stylesheet will need to hosted on a separate server. Or you can mount a FastAPI server and host the stylesheet from there.
I'm not 100% sure how much styling you can override though. Haven't tried.
If have any questions on how to specify a stylesheet from the page object or to mount a server with mesop, those should be in our docs here: https://google.github.io/mesop/. You can use the search bar to find those pages.

Going to close this issue. The Angular components API for slide toggle doesn't offer any API for modifying color, height, width. So that prevents us from exposing those styling adjustments.
Best options for now:

Try to add a stylesheet to override those styles
Create a custom web component to create a custom slide toggle.


Error (1): We encountered a JSON web token error, which is likely not an issue with Salesforce CLI. Here’s the error: structuredClone is not defined

Summary
trying this command sfdx auth:jwt:grant, I recieve this error:
Error (1): We encountered a JSON web token error, which is likely not an issue with Salesforce CLI. Here’s the error: structuredClone
Steps To Reproduce
I execute a script in where I try to atuthenticate to my org using this command:
sf org login jwt --client-id "$CONSUMER_KEY" --jwt-key-file "JWT/server.key" --username "$USERNAME"
Expected result
Successfully authorized USERNAME with org ID OrgId
Actual result
Error (1): We encountered a JSON web token error, which is likely not an issue with Salesforce CLI.   See https://github.com/forcedotcom/cli/issues/1985


has_many stopped working if field names are identical

After updating to version v1.21.10, the models stopped working:
type Document struct {
	ID uint `gorm:"column:id;primarykey;"`
	OwnerID uint
	OwnerType string
	Users []*User `gorm:"foreignkey:OwnerID"`
}

type User struct {
	ID uint `gorm:"column:id;primarykey;"`
	Email string
	Password *string `json:"-"`
	OwnerID *uint
	Owner   *Document
}

Error: invalid field found for struct models.Document's field Users, need to define a valid foreign key for relations or it need to implement the Valuer/Scanner interface
In v1.21.9 and earlier, this bug was not observed. I guess the last fix did something.
In the Document model, the OwnerID field has nothing to do with the OwnerID field from the User model. They just have the same name, which is causing the problem. Renaming the OwnerID field in the Document model resolves the issue.
Originally posted by @yushulgin in https://github.com/go-gorm/gorm/issues/4343#issuecomment-842335955

I have a fix ready for this. sending a PR soon.

@jinzhu Submitted a PR, please take a look :)

PR merged and issue fixed


relative sourcemap paths or absolute filepaths without URL

I have seen this issue: https://github.com/webpack/webpack/issues/238, but can't get this to work.
I've tried:

plugins: [
    new webpack.SourceMapDevToolPlugin(
        '[file].map', null,
        "[absolute-resource-path]", "[absolute-resource-path]")
]

and 2)
plugins: [
    new webpack.SourceMapDevToolPlugin(
        '[file].map', null,
        "../[resource-path]", "../[resource-path]")
]

These are the actual source URL's that chrome shows (which is the one I should match in my IDE):
setup 1): https://local.myapp.com/js/builds/F:/wamp/www/app/jsx/MyApp.jsx
setup 2): https://local.myapp.com/js/F:/wamp/www/app/jsx/MyApp.jsx
I would like it to be just: F:/wamp/www/app/jsx/MyApp.jsx OR https://local.myapp.com/whatever/MyApp.jsx
either would work for me, but I can't seem to get the right setup to get such output

try to add the file:/// protocol.

If still relevant, please re-open the question at Stack Overflow. Thanks.


Support development of BCP-002-02 "Distinguishing Information for NMOS Node and Device Resources"

I also took the opportunity to pin the revision of nmos-js like nmos-cpp.

@garethsb Thanks...


Add hboost thread as dependency to resolve linking error

Fix to a new linking error on Mac OSX that's just started happening:
Undefined symbols for architecture x86_64:
  "hboost::this_thread::interruption_point()", referenced from:
      hboost::condition_variable::wait(hboost::unique_lock<hboost::mutex>&) in ParmFactory.cc.o
      hboost::condition_variable::do_wait_until(hboost::unique_lock<hboost::mutex>&, timespec const&) in ParmFactory.cc.o
  "hboost::detail::get_current_thread_data()", referenced from:
      hboost::detail::interruption_checker::interruption_checker(_opaque_pthread_mutex_t*, _opaque_pthread_cond_t*) in ParmFactory.cc.o
ld: symbol(s) not found for architecture x86_64

On investigation, it seems that it's coming from introducing HOM_AutoLock in #463 which itself uses UT_TaskLockT which uses boost::thread.

Good catch. This is something I left out, but might be nice to put comments next to each of these deps as to why they're necessary. i.e. RAY for mantra points procedural, regex for vector merge and thread for HOM/UT_TaskLockT.

Yeah, would be nice to have. I'm just going to merge this as-is because the master branch is broken for Mac right now, but we can come back and document this bit better...
(Note that I didn't include a comment in the release notes because this is merely a fix to the spare data PR which was very recent).


Adding SlickGrid plugin

Hey
Im trying to integrate the auto width plugin posted by John Ranger:
https://github.com/volkanceylan/Serenity/wiki/Slickgrid-AutoColumn-resize
but i get "Object doesn't support this action" on this line:
let autoSize = new Slick.AutoColumnSize(true);
Intelisense picks up AutoColumnSize but when i debug and look at Slick object AutoColumnSize is not there. Seems as if its not picking it up. I did generate t4.
i have a feeling like the new .d.ts file is not getting compiled or something.
Any ideas why this is happening?
thanks for any help to come :)

I had a feeling it was something like that but had no idea where to look. Still getting used to this whole shabang.
it worked.. thanks!!!

Still having an issue on this.
After overriding :
protected createSlickGrid(): Slick.Grid {
var grid = super.createSlickGrid();
        // Full Row Selection
        grid.setSelectionModel(new Slick.RowSelectionModel());

        // Columns auto resize
        let autoSize = new Slick.AutoColumnSize(true);
        grid.registerPlugin(autoSize);

        return grid;
    }

Pb rises when you have a column picker button. If you click on OK (even without changing anything), grid is displayed again but with NO REFRESH (so all columns remains not auto resized).
is there a way to refresh grid after this Event ? (quitting column picket dialog box)


More CLI utils

Add new cli utils:

A command to get a verification key from a signing key.
Another command to get a non-extended verification key from an
extended verification key.
New cli command to make a new cert issue counter from scratch.

bors merge


docs: update architecture.md

:tada: This PR is included in version 3.22.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


the Named Slots have not work in router-view

Version
2.2.6
Reproduction link
https://jsfiddle.net/johonz/nuuyjuwk/3/
Steps to reproduce

insert some els in router-view,and set property 'slot'
use slot tag in router views

html

  <router-view>

      The Slot A

      The Slot B

      the Slot C

  </router-view>

javascript:
const Home = {
  template: '
'
      '
question:the Named Slots have not effect in router-view
'
     	'
the named slots below:
'
     	'<slot name="a"></slot>'
      '<slot name="b"></slot>'
      '<slot name="c"></slot>'
      'why empty?'
      '
'
}
const router = new VueRouter({
  history: false,
  routes: [{
    path: '/',
    component: Home
  }]
});

new Vue({
  el: '#app',
  router: router
})

example:https://jsfiddle.net/johonz/nuuyjuwk/3/
What is expected?
the named slot can support in router-view
What is actually happening?
it cause the slot can't show in router views

That's expected because there're no named slots on the router-view component. You should check the docs for more help or ask questions on the forum or StackOverflow.

Technically this should work since router-view is just a functional component that renders the inner route component. Needs more investigation, but should probably be posted to the vue-router repo instead.

Well, it's true that since scopedSlots are passed in the data object the can be passed down while slots is an argument. Maybe slots should be included in the data object in functional components?
http://jsfiddle.net/ukfdwukg/

This has been addressed in<EMAIL_ADDRESS>Technically, it is expected behavior for functional components to not forward named slots downwards, but it is a useful behavior for <router-view> so we enabled it.

I cannot seem to understand how named slots should be used along with router-view. I know this is part of the router, but there is nothing on this topic there. @yyx990803 can you provide with some details please?
Thanks in advance!


Error decoding audio buffer on Mac Safari/iOS

Edit: Think we figured it out - it ended up being the source of the mp3 itself where it appears safari/iOS can't handle decoding certain sample rates (48 khz for instance). Switching that to 44.1 khz seems to have fixed this.
I'm using wavesurfer in a NextJS application and currently getting an error (Direct message from wavesurfer: Error decoding audiobuffer) when trying to load the waveform/audio on iOS devices as well as Mac Safari. As a result, it never hits the ready state or finishes loading the audio. I've tried switching the backend option to MediaElement or MediaElementWebAudio and it seems to have some progress, where the wavesurfer is able to process the audio, hit the ready state, and have audio controls like play/pause. But the wavesurfer visuals never load when I use that method and the same error decoding audiobuffer is still hit.
I've tried previously suggested methods for iOS issues like #2182 but they haven't helped. Would really appreciate any context on the potential error or any suggestions. Thank you!
Wavesurfer.js version(s):
5.0.1
Browser and operating system version(s):
iOS Chrome v87.0.4280.163
Mac Safari v13.1.3
Code needed to reproduce the issue:
`
const xhr = {
cache: 'default',
mode: 'cors',
method: 'GET',
credentials: 'same-origin',
};
  const wavesurferInstance = WaveSurfer.create({
    container: waveformRef?.current,
    // backend: 'MediaElementWebAudio',
    audioContext: context || null,
    audioScriptProcessor: processor || null,
    waveColor: theme.color.brand.light24,
    progressColor: theme.color.brand.base,
    cursorColor: theme.color.brand.base,
    barWidth: 3,
    barRadius: 3,
    cursorWidth: 0,
    interact: interact,
    scrollParent: false,
    responsive: true,
    height,
    barGap: 3,
    plugins: interact
      ? [
          CursorPlugin.create({
            showTime: true,
            opacity: 1,
            color: theme.color.brand.base,
            width: rem(2),
            customShowTimeStyle: {
              'background-color': theme.color.brand.base,
              color: theme.text.alt.primary,
              padding: theme.spacing.spacing3,
              'border-radius': theme.radius.sm,
              'font-size': rem(16),
            },
            formatTimeCallback: (time) =>
              formatSongLength(Math.floor(time)),
          }),
        ]
      : [],
    xhr,
  });`

Edit: Think we figured it out - it ended up being the source of the mp3 itself where it appears safari/iOS can't handle decoding certain sample rates (48 khz for instance). Switching that to 44.1 khz seems to have fixed this.

Godo to hear, closing.


Telegram2Logstash?

and hello again, it's me :) I tried to use your development to send a message to elasticsearch via logstash
instead of the elasticsearch address, I put the logstash address (use http input), but I get an error:
The client noticed that the server is not Elasticsearch and we do not support this unknown product
if you use TCP (or HTTP) input, then the connection to the logstash is lost after 10 seconds and in the data received from telegram, the message field is null:
Accept-Encoding: identity
accept: application/vnd.elasticsearch+json; compatible-with=8
Host: <IP_ADDRESS>:1234
connection: keep-alive
Content-Length: 137
content-type: application/vnd.elasticsearch+json; compatible-with=8
PUT /telegram/_doc/1 HTTP/1.1
user-agent: elasticsearch-py/8.3.3 (Python/3.9.7; elastic-transport/8.4.0)
x-elastic-client-meta: es=8.3.3,py=3.9.7,t=8.4.0,ur=1.26.12
{"timestamp":"2022-03-01T19:49:05+00:00","sender":{"username":null},"chat":"MyChat","message":null}

could you tell me how i can send messages from telegram to logstash with Telegram2Elastic? or you know any Telegram2Logstash development

As I'm simply using the official Elasticsearch Python module, which only supports talking to an Elasticsearch endpoint, there is no way in using something different between or instead of Elasticsearch like Logstash.
I guess the client looses the connection as it does not get the correct response from Logstash as it is not meant to be used as an Elasticsearch endpoint.
It shouldn't be too hard to also support other endpoints. I will have a look.

I've rewritten the whole code to allow adding different output types.
As of now, the following output types are implemented:

Elasticsearch: Write to an Elasticsearch instance just like before
File: Write per message JSON lines into any file (i.e. to be picked up by Filebeat or Logstash)
TCP: Send messages as JSON string to any TCP socket (i.e. to be received using the "tcp" input in Logstash)

I just did some testing for the File and TCP outputs, but didn't test anything with Logstash or Elasticsearch yet. That's still something I have to do before releasing a new version.

Thanks for your answers.

Usually, it should work to specify "json" as codec in the tcp input:

input {
  tcp {
    port => 12345
    codec => json
  }
}

But I didn't test that yet.

Good point about the multiple hosts for the Elasticsearch connection. I will update the code to support multiple hosts.

I also already saw the issue about the AttributeError while reading messages from channels. I will fix it.

I already thought about renaming the project to something like "Telelog" or something like that as it will change into a way where it uses Telegram messages and send it to any output to log those messages.

Good news: I can reproduce the issue with the listen mode.
Bad news: I don't know what's wrong.
I've debugged the code down to the actual event handler which doesn't seem to be triggered at all. Adding a simple print(event) into the handler method doesn't print anything once a new message is available:
async def handler(event):
    print(event)

Manually adding the event handler with add_event_handler() also has no effect. I guess I have to dig a bit deeper...

Found the issue quicker than I thought it would take.
Getting the loop from asyncio.get_event_loop() instead of asyncio.new_event_loop() fixes the issue.
I've changed that to asyncio.new_event_loop() as starting the event loop with a loop retrieved from asyncio.get_event_loop() results in showing deprecation warnings "There is no current event loop". But unfortunately, this resulted in not listening for events which is kind of weird.

Yes, it should be fixed.

Hopefully, all known bugs are now a thing of the past.
I've just released version 2.0 of the application.
Note: I've renamed the output elastic to elasticsearch as it sounds better.