Real FFT?

Thanks for this great crate!
It would be great to have a faster way for doing a real to complex fft (such as from time to frequency domain), which is a very common use case.
It would approximately halve the computation time compared to doing it via a complex to complex fft.
https://www.dspguide.com/ch12/1.htm
For my use case I need to replace another fft crate (which uses cmake) because I want to cross compile to mac os, and I only need the real to complex fft for pow2 size.

I needed the same thing and ended up making this: https://crates.io/crates/realfft
It's a simple wrapper of RustFFT that does real to complex fft, and complex to real ifft. And yes it runs about twice as fast.

Thanks for this great crate as well :smile:
Just want to mention that this was maybe up next after this AVX stabilization (https://github.com/awelkie/RustFFT/issues/4#issuecomment-646829960), crossing fingers.
In any case, I'm using realFFT for my project as well, just thought it'd be great to have this directly in the RustFFT crate :)

Thanks for this great crate as well :smile:
Just want to mention that this was maybe up next after this AVX stabilization (https://github.com/awelkie/RustFFT/issues/4#issuecomment-646829960), crossing fingers.
In any case, I'm using realFFT for my project as well, just thought it'd be great to have this directly in the RustFFT crate :)

Once 5.0 is out, I plan to turn my attention to RustDCT for a little while. I don't think I'll be implementing much AVX stuff there, but I at least want to get it compiling with 5.0, and using the same scratch space setup that rustfft uses.
After that, I can start looking into real-only FFTs.
What sort of API do you exactly need for a real-only FFT? What's the application? Do you need access to complex numbers on one side of the FFT, but not the other? Or is it real-only on both sides?

Once 5.0 is out, I plan to turn my attention to RustDCT for a little while. I don't think I'll be implementing much AVX stuff there, but I at least want to get it compiling with 5.0, and using the same scratch space setup that rustfft uses.
After that, I can start looking into real-only FFTs.
What sort of API do you exactly need for a real-only FFT? What's the application? Do you need access to complex numbers on one side of the FFT, but not the other? Or is it real-only on both sides?

I think these two are by far most common use cases:

Transform to get spectrum of real valued data. Needs real-to-complex fft.
Transform real valued data, modify the spectrum, and transform back to real-valued data. Needs real-to-complex fft and complex-to-real ifft.

For even lengths, it's possible to use a complex-to-complex (i)fft of half the length, but I haven't found any such trick for odd lengths. That means that odd length real fft will most likely be much more work.
The existing implementations in other libraries do things in a few ways.
Let's start with a 6 element long real vector: [x0r, x1r, x2r, x3r, x4r, x5r]
The simple approach of just converting it to complex becomes: [(x0r, 0), (x1r, 0, (x2r, 0), (x3r, 0), (x4r, 0, (x5r, 0)]
FFT:in x becomes: [(X0r, X0i), (X1r, X1i), (X2r, X2i), (X3r, X3i), (X4r, X4i), (X5r, X5i)]
Because x was real, this becomes a bit simpler: [(X0r, 0), (X1r, X1i), (X2r, X2i), (X3r, 0), (X2r, -X2i), (X1r, -X1i)]
The last two values are redundant, so let's remove them: [(X0r, 0), (X1r, X1i), (X2r, X2i), (X3r, 0)]
Starting from here, I have seen these different solutions:

Return this complex vector, [(X0r, 0), (X1r, X1i), (X2r, X2i), (X3r, 0)]. Advantage: easy to understand, can be directly multiplied with another spectrum (for convolution etc). Downside: Stores two zeros, means output is longer than input.
Put X3r in the place of X0i:  [(X0r, X3r), (X1r, X1i), (X2r, X2i)]. Advantage: same length as input (can be used for in-place transforms). Downside: can't be directly multiplied, can be confusing.
(worst one!) Just squeeze out the zeros: [(X0r, X1r), (X1i, X2r), (X2i, X3r)]. Advantage: same length as input (can be used for in-place transforms). Downside: can't be directly multiplied, highly confusing.

I think in-place real-to-complex/complex-to-real transforms are a bad idea, as it means the complex values of the spectrum have to be split and stored as separate real values in the input vector. In RealFFT I went with option 1, and only out-of-place transforms.
As a starting point I would propose to add the same functionality as RealFFT has:

Only even lengths
Only out-of-place transforms
"Easy" data order
Change the direction enum to a transform type enum with variants C2CForward, C2CInverse, R2CForward, C2RInverse

I think these two are by far most common use cases:

Transform to get spectrum of real valued data. Needs real-to-complex fft.
Transform real valued data, modify the spectrum, and transform back to real-valued data. Needs real-to-complex fft and complex-to-real ifft.

For even lengths, it's possible to use a complex-to-complex (i)fft of half the length, but I haven't found any such trick for odd lengths. That means that odd length real fft will most likely be much more work.
The existing implementations in other libraries do things in a few ways.
Let's start with a 6 element long real vector: [x0r, x1r, x2r, x3r, x4r, x5r]
The simple approach of just converting it to complex becomes: [(x0r, 0), (x1r, 0, (x2r, 0), (x3r, 0), (x4r, 0, (x5r, 0)]
FFT:in x becomes: [(X0r, X0i), (X1r, X1i), (X2r, X2i), (X3r, X3i), (X4r, X4i), (X5r, X5i)]
Because x was real, this becomes a bit simpler: [(X0r, 0), (X1r, X1i), (X2r, X2i), (X3r, 0), (X2r, -X2i), (X1r, -X1i)]
The last two values are redundant, so let's remove them: [(X0r, 0), (X1r, X1i), (X2r, X2i), (X3r, 0)]
Starting from here, I have seen these different solutions:

Return this complex vector, [(X0r, 0), (X1r, X1i), (X2r, X2i), (X3r, 0)]. Advantage: easy to understand, can be directly multiplied with another spectrum (for convolution etc). Downside: Stores two zeros, means output is longer than input.
Put X3r in the place of X0i:  [(X0r, X3r), (X1r, X1i), (X2r, X2i)]. Advantage: same length as input (can be used for in-place transforms). Downside: can't be directly multiplied, can be confusing.
(worst one!) Just squeeze out the zeros: [(X0r, X1r), (X1i, X2r), (X2i, X3r)]. Advantage: same length as input (can be used for in-place transforms). Downside: can't be directly multiplied, highly confusing.

I think in-place real-to-complex/complex-to-real transforms are a bad idea, as it means the complex values of the spectrum have to be split and stored as separate real values in the input vector. In RealFFT I went with option 1, and only out-of-place transforms.
As a starting point I would propose to add the same functionality as RealFFT has:

Only even lengths
Only out-of-place transforms
"Easy" data order
Change the direction enum to a transform type enum with variants C2CForward, C2CInverse, R2CForward, C2RInverse

There's a #4: fftw's R2HC format

There's a #4: fftw's R2HC format

Oh, didn't see that one. Not sure which one is worst then, my #3 or the R2HC format...

Oh, didn't see that one. Not sure which one is worst then, my #3 or the R2HC format...

I've been using FFTS until now, The Fastest Fourier Transform in the South (it's faster than FFTW), specifically I've been using the 1d real function for real-to-complex FFT:
https://github.com/linkotec/ffts/blob/2c8da4877588e288ff4cd550f14bec2dc7bf668c/include/ffts.h#L96

The output of a real-to-complex transform is N/2+1 complex numbers,
where the redundant outputs have been omitted.

@ejmahler @HEnquist See also this: https://www.smcm.iqfr.csic.es/docs/intel/mkl/mkl_manual/fft/fft_PackedFormats.htm
There are 3 ways to pack the complex output in-place into the input slice, to avoid allocations:
CCS, Pack and Perm.
CCS uses 2 more elements ([1] and [n+1], which are 0) so it can't be used to write the output back into the input slice.
Pack and Perm use exactly as many elements as the input, but if you compare the indices at which the output for an input ends up, Pack is easier to misuse, because the (R, I) pairs are not at even indices.
IMO, Perm makes the most sense because it uses exactly as many elements as the input and the i-th complex output is at the index 2*i, with the only exception that R[n/2] is stored at index 1.

I've been using FFTS until now, The Fastest Fourier Transform in the South (it's faster than FFTW), specifically I've been using the 1d real function for real-to-complex FFT:
https://github.com/linkotec/ffts/blob/2c8da4877588e288ff4cd550f14bec2dc7bf668c/include/ffts.h#L96

The output of a real-to-complex transform is N/2+1 complex numbers,
where the redundant outputs have been omitted.

@ejmahler @HEnquist See also this: https://www.smcm.iqfr.csic.es/docs/intel/mkl/mkl_manual/fft/fft_PackedFormats.htm
There are 3 ways to pack the complex output in-place into the input slice, to avoid allocations:
CCS, Pack and Perm.
CCS uses 2 more elements ([1] and [n+1], which are 0) so it can't be used to write the output back into the input slice.
Pack and Perm use exactly as many elements as the input, but if you compare the indices at which the output for an input ends up, Pack is easier to misuse, because the (R, I) pairs are not at even indices.
IMO, Perm makes the most sense because it uses exactly as many elements as the input and the i-th complex output is at the index 2*i, with the only exception that R[n/2] is stored at index 1.

I can just mention that the RealFFT crate is now updated to use RustFFT 5.0.

For my use case I convert a real to complex then take the magnitude of the first half the resulting output.
        // Switch to Complex input
        for i in 0..FFT_LEN {
            self.0[i].re = input[i];
            self.0[i].im = 0.0;
        }
        FFT_FULL.process_with_scratch(&mut self.0[..], &mut self.1[..]);

        // Calculate the magnitude
        for i in 0..FFT_LEN/2 {
            input[i] = self.1[i].norm();
        }

Where Self is
/// FFT from the `rustfft` crate
pub struct RsFft(Box<[Complex32; FFT_LEN]>, Box<[Complex32; FFT_LEN]>);

When I last bench marked with rustfft 4.0, IPP (using the ipp-sys crate) was much faster for that I used the functions
ippsFFTFwd_RToPerm_32f then ippsMagnitude_32fc. But it complicated the build a lot so I didn't use it by default, I suspect if rust-fft had equivalent to ippsFFTFwd_RToPerm_32f, it would probably now be fast enough for me to drop ipp.

For my use case I convert a real to complex then take the magnitude of the first half the resulting output.
        // Switch to Complex input
        for i in 0..FFT_LEN {
            self.0[i].re = input[i];
            self.0[i].im = 0.0;
        }
        FFT_FULL.process_with_scratch(&mut self.0[..], &mut self.1[..]);

        // Calculate the magnitude
        for i in 0..FFT_LEN/2 {
            input[i] = self.1[i].norm();
        }

Where Self is
/// FFT from the `rustfft` crate
pub struct RsFft(Box<[Complex32; FFT_LEN]>, Box<[Complex32; FFT_LEN]>);

When I last bench marked with rustfft 4.0, IPP (using the ipp-sys crate) was much faster for that I used the functions
ippsFFTFwd_RToPerm_32f then ippsMagnitude_32fc. But it complicated the build a lot so I didn't use it by default, I suspect if rust-fft had equivalent to ippsFFTFwd_RToPerm_32f, it would probably now be fast enough for me to drop ipp.

The main thing I dislike with the inplace solutions is that they all offer very poor ergonomics since they need to store complex values in a real vector. The advantages of the Complex type are lost.
@Cocalus what lengths are you typically using? Can they be odd? How much faster was ipp?

The main thing I dislike with the inplace solutions is that they all offer very poor ergonomics since they need to store complex values in a real vector. The advantages of the Complex type are lost.
@Cocalus what lengths are you typically using? Can they be odd? How much faster was ipp?

The in place solutions are great if you can hide the ugliness behind an API
I kind of wish we could do something like return a boxed iterator over the
complex output, so we don’t actually need storage for it.
Specifically returning a boxed iterator isn’t great because of the
allocation, but are there any applications where lazily generating the
complex output would be useful? Or for C2R, taking an iterator as a
parameter
On Thu, Jan 7, 2021 at 12:32 AM Henrik Enquist<EMAIL_ADDRESS>wrote:

The main thing I dislike with the inplace solutions is that they all offer
very poor ergonomics since they need to store complex values in a real
vector. The advantages of the Complex type are lost.
@Cocalus https://github.com/Cocalus what lengths are you typically
using? Can they be odd? How much faster was ipp?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ejmahler/RustFFT/issues/28#issuecomment-755967612,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAI2M6SMVOZAFBMEIFIQAWTSYVWSTANCNFSM4VMWGMWQ
.

The in place solutions are great if you can hide the ugliness behind an API
I kind of wish we could do something like return a boxed iterator over the
complex output, so we don’t actually need storage for it.
Specifically returning a boxed iterator isn’t great because of the
allocation, but are there any applications where lazily generating the
complex output would be useful? Or for C2R, taking an iterator as a
parameter
On Thu, Jan 7, 2021 at 12:32 AM Henrik Enquist<EMAIL_ADDRESS>wrote:

The main thing I dislike with the inplace solutions is that they all offer
very poor ergonomics since they need to store complex values in a real
vector. The advantages of the Complex type are lost.
@Cocalus https://github.com/Cocalus what lengths are you typically
using? Can they be odd? How much faster was ipp?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ejmahler/RustFFT/issues/28#issuecomment-755967612,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAI2M6SMVOZAFBMEIFIQAWTSYVWSTANCNFSM4VMWGMWQ
.

I was using 4096, I think IPP only supports powers of two. I retested with my case of real to magnitudes at 4096. In my benchmark IPP 2019 is about 5.5x faster than RustFFT 5.0. With 10000 iterations and only initializing the FFTs once (plan_fft_forward + ippsFFTInit_R_32f), rustfft took 175ms and IPP took 31ms.
RustFFT has to move things into and out of the real buffer on top of twice as the effective FFT size. So adding a Real API should probably fix a decent chunk of that difference. The IPP magnitude calculation is also vectorized which probably helps. I could probably upload the hacked together benchmark if some wants to poke at it, but I think you need to register an email with intel to download IPP.

I was using 4096, I think IPP only supports powers of two. I retested with my case of real to magnitudes at 4096. In my benchmark IPP 2019 is about 5.5x faster than RustFFT 5.0. With 10000 iterations and only initializing the FFTs once (plan_fft_forward + ippsFFTInit_R_32f), rustfft took 175ms and IPP took 31ms.
RustFFT has to move things into and out of the real buffer on top of twice as the effective FFT size. So adding a Real API should probably fix a decent chunk of that difference. The IPP magnitude calculation is also vectorized which probably helps. I could probably upload the hacked together benchmark if some wants to poke at it, but I think you need to register an email with intel to download IPP.

Have you looked at the RealFFT crate? At 4096 the fft should be about twice as fast, and you can skip the conversion to complex.

Have you looked at the RealFFT crate? At 4096 the fft should be about twice as fast, and you can skip the conversion to complex.

To explain my earlier comment in more detail:
The core values of rust are performance, safety, productivity. The ideal real FFT API would have all three.
I think we're all uncomfortable with the "keep the data inplace and do some weird trick to pack the results" output formats because it would heavily sacrifice productivity.
I think it also hurts safety. Users will have to write loops with random array access to pull data out of the packed formats - and in my experience, it's easy to write loops like that correctly, but hard to write them in a way that avoids bounds checks. Many users will feel tempted to write things like get_unchecked().
So we're talking about doing the half-complex output instead - but I think that also hurts productivity and safety, just less so. Users wonly have to remember a bizarre layout, but as I think about it, I think we're asking the average RustFFT user too much if we ask them to remember "we omit the last n/2 - 1 elements of the array, if you want them, iterate from element 1 to element n / 2 - 1 in reverse order and negate them all".
So why not make the default output be the full complex array? Do the reversal and negation ourselves, and return a size-N array instead of size-N/2+1, so that the caller doesn't have to remember the exact specifics of which subsection of the array to reverse.
Once we have that idea, my next thought is, how often do callers need the output in an array? In the case of RustDCT, you compute the DCT2 with an inner real-only FFT. Once you have the full complex output, you do some extra processing anyways, and the final output is just real numbers. So you never actually store the complex output, you only keep it around long enough to compute the real output, and then throw away the complex output.

To explain my earlier comment in more detail:
The core values of rust are performance, safety, productivity. The ideal real FFT API would have all three.
I think we're all uncomfortable with the "keep the data inplace and do some weird trick to pack the results" output formats because it would heavily sacrifice productivity.
I think it also hurts safety. Users will have to write loops with random array access to pull data out of the packed formats - and in my experience, it's easy to write loops like that correctly, but hard to write them in a way that avoids bounds checks. Many users will feel tempted to write things like get_unchecked().
So we're talking about doing the half-complex output instead - but I think that also hurts productivity and safety, just less so. Users wonly have to remember a bizarre layout, but as I think about it, I think we're asking the average RustFFT user too much if we ask them to remember "we omit the last n/2 - 1 elements of the array, if you want them, iterate from element 1 to element n / 2 - 1 in reverse order and negate them all".
So why not make the default output be the full complex array? Do the reversal and negation ourselves, and return a size-N array instead of size-N/2+1, so that the caller doesn't have to remember the exact specifics of which subsection of the array to reverse.
Once we have that idea, my next thought is, how often do callers need the output in an array? In the case of RustDCT, you compute the DCT2 with an inner real-only FFT. Once you have the full complex output, you do some extra processing anyways, and the final output is just real numbers. So you never actually store the complex output, you only keep it around long enough to compute the real output, and then throw away the complex output.

I on the other hand definitely prefer the half-complex format. My main use case is processing of audio data, doing stuff like convolution. Then I have a real valued signal, and a real valued impulse response that I want to convolute. So I transform them both, multiply the complex results, and transform back. Using the half-complex format means I have half as many coefficients to multiply and store.
I think that most people who know they could use a Real2Complex fft in their application already have a good understanding of how ffts work, and have no problem with the half-complex format (as long as it doesn't use any weird packing tricks of course). But it would make sense to provide some conventient way of filling in the second half of the data when someone needs the full result.
Another thought, if Real2Comples fft returns the full complex result, what should the Complex2Real ifft do? Ignore half of the data? Or assert that it's conjugate symmetric?  Neither seems very attractive..

I on the other hand definitely prefer the half-complex format. My main use case is processing of audio data, doing stuff like convolution. Then I have a real valued signal, and a real valued impulse response that I want to convolute. So I transform them both, multiply the complex results, and transform back. Using the half-complex format means I have half as many coefficients to multiply and store.
I think that most people who know they could use a Real2Complex fft in their application already have a good understanding of how ffts work, and have no problem with the half-complex format (as long as it doesn't use any weird packing tricks of course). But it would make sense to provide some conventient way of filling in the second half of the data when someone needs the full result.
Another thought, if Real2Comples fft returns the full complex result, what should the Complex2Real ifft do? Ignore half of the data? Or assert that it's conjugate symmetric?  Neither seems very attractive..

Yeah, the point about convolution makes sense.

Although - an implicit part of the Complex-To-Real, even with the redundant elements omitted, is that the imaginary part of the first and last value is 0. Presumably if you do any sort of convolution involving multiplying with a complex number, your inout to C2R is going to have a nonzero imaginary component. How does that affect the output?

Doing convolution that way only works when both the signals are real. Then they both have zeros in those places of their transforms, and the zeros stay also after element-wise complex multiplication of the two transforms.

Would it ever make sense to do a R2C where the inner FFT is inverse? Or only forward?
Would it ever make sense to do a C2R where the inner FFT is forward? Or only inverse?

I think only forward R2C and inverse C2R are useful in practice. I have never seen the other two (fftw doesn't have them for example) and I can't think of any reason for ever using them.

I think only forward R2C and inverse C2R are useful in practice. I have never seen the other two (fftw doesn't have them for example) and I can't think of any reason for ever using them.

I did some investigation on why it's so hard to find non-even real FFT algorithms:
In order to compute a real FFT, you basically have to apply Mixed Radix, or rader's, or bluestein's. But like, a "Real FFT" version of those algorithms. You have to just derive a version of the algorithm that manually cuts out the wasted work.
Size 2 is a special case, because it takes advantage of the fact that you can compute 2 real FFTs in parallel, with one set of real data in the reals, and the other FFT in the imaginaries. You can completely recover the separate outputs of the two FFTs with a O(n) postprocess. So the algorithm in the PR and elsewhere is basically merging a butterfly2 step (for the 2 parallel FFTs) with the parallel FFT postprocess.
For any non-even number, we'd need mixed radix algorithm, raders, bluesteins, butterflies, planning, the works.
Having to switch back and forth between the real array and the "n / 2 + 1" array seems like a nightmare, but apparently a real-only FFT is trivially convertible to a transform called a "Discrete Hartley Transform", which is real-only, has all the same algorithms, etc, but with the advantage that all the outputs are the same size.
So my current thinking is to make a new planner specifically for real FFTs, and put all this stuff in there. It can have a FFT planner internally if we find that it can speed things up to use an actual FFT, but otherwise, it'll stay off in its own little Discrete Hartley World.

I did some investigation on why it's so hard to find non-even real FFT algorithms:
In order to compute a real FFT, you basically have to apply Mixed Radix, or rader's, or bluestein's. But like, a "Real FFT" version of those algorithms. You have to just derive a version of the algorithm that manually cuts out the wasted work.
Size 2 is a special case, because it takes advantage of the fact that you can compute 2 real FFTs in parallel, with one set of real data in the reals, and the other FFT in the imaginaries. You can completely recover the separate outputs of the two FFTs with a O(n) postprocess. So the algorithm in the PR and elsewhere is basically merging a butterfly2 step (for the 2 parallel FFTs) with the parallel FFT postprocess.
For any non-even number, we'd need mixed radix algorithm, raders, bluesteins, butterflies, planning, the works.
Having to switch back and forth between the real array and the "n / 2 + 1" array seems like a nightmare, but apparently a real-only FFT is trivially convertible to a transform called a "Discrete Hartley Transform", which is real-only, has all the same algorithms, etc, but with the advantage that all the outputs are the same size.
So my current thinking is to make a new planner specifically for real FFTs, and put all this stuff in there. It can have a FFT planner internally if we find that it can speed things up to use an actual FFT, but otherwise, it'll stay off in its own little Discrete Hartley World.

That's not a final plan obviously, but seeing how many different classes are going to be involved, I think it shouldn't be a part of the main planner.
Given that we're going to almost double the code size, we might even want to split it into a separate crate entirely.

That's not a final plan obviously, but seeing how many different classes are going to be involved, I think it shouldn't be a part of the main planner.
Given that we're going to almost double the code size, we might even want to split it into a separate crate entirely.

This explains a lot, thanks!
I'm guessing a DHT would not be able to directly reuse very much of the code in RustFFT(?). Then it makes more sense to put it in a separate crate, RustDHT perhaps?
Then the question is what to do about the Real FFTs. Another separate crate on top of RustDHT?
This would then be an argument for keeping also the R2C stuff separate from RustFFT.
Building the DHT will be a pretty long term project. What to do in the meanwhile? One easy fix that I think is still better than nothing, is to provide R2C/C2R for odd lengths by just using C2C of the same length. This would at least mean there is a single interface that works for all lengths, even if there is no speed advantage for the odds. I could add this to RealFFT for now, and include the optimizations from https://github.com/ejmahler/RustFFT/pull/50.

This explains a lot, thanks!
I'm guessing a DHT would not be able to directly reuse very much of the code in RustFFT(?). Then it makes more sense to put it in a separate crate, RustDHT perhaps?
Then the question is what to do about the Real FFTs. Another separate crate on top of RustDHT?
This would then be an argument for keeping also the R2C stuff separate from RustFFT.
Building the DHT will be a pretty long term project. What to do in the meanwhile? One easy fix that I think is still better than nothing, is to provide R2C/C2R for odd lengths by just using C2C of the same length. This would at least mean there is a single interface that works for all lengths, even if there is no speed advantage for the odds. I could add this to RealFFT for now, and include the optimizations from https://github.com/ejmahler/RustFFT/pull/50.

And even if it's not faster, there would be added convenience of not having to keep track of the redundant part of the complex output

And even if it's not faster, there would be added convenience of not having to keep track of the redundant part of the complex output

Yes the convenience itself makes it worth having it. Are you adding this in RustFFT now-ish? If yes I won't do anything more to RealFFT, just mark it as deprecated once this is done.

Yes the convenience itself makes it worth having it. Are you adding this in RustFFT now-ish? If yes I won't do anything more to RealFFT, just mark it as deprecated once this is done.

It will be a while, i recommend porting it to realfft

It will be a while, i recommend porting it to realfft

Maybe it makes sense to take inspiration from FFTS? https://github.com/linkotec/ffts
It's faster than FFTW.
The ffts_init_1d_real function does exactly what we need.

Maybe it makes sense to take inspiration from FFTS? https://github.com/linkotec/ffts
It's faster than FFTW.
The ffts_init_1d_real function does exactly what we need.

From what I can tell, it's using the same trick as us: https://github.com/linkotec/ffts/blob/2c8da4877588e288ff4cd550f14bec2dc7bf668c/src/ffts_real.c#L407
I don't see anything that would help with odd length real ffts.
The documentation of FFTS is pretty thin, but I think its main algorithms are only for powers of two. For anything else it uses Bluesteins. If that is true, it might be faster for powers of two, and the (quite few) special cases where the fastest solution is Bluestein. For everything else it will most likely be quite a bit slower.

From what I can tell, it's using the same trick as us: https://github.com/linkotec/ffts/blob/2c8da4877588e288ff4cd550f14bec2dc7bf668c/src/ffts_real.c#L407
I don't see anything that would help with odd length real ffts.
The documentation of FFTS is pretty thin, but I think its main algorithms are only for powers of two. For anything else it uses Bluesteins. If that is true, it might be faster for powers of two, and the (quite few) special cases where the fastest solution is Bluestein. For everything else it will most likely be quite a bit slower.

I made a big rewrite of RealFFT: https://github.com/HEnquist/realfft/pull/7
It now behaves a lot more like RustFFT, with a planner that reuses ffts. And whenever it makes sense it uses the same function names as RustFFT. It also includes the optimiztions from https://github.com/ejmahler/RustFFT/pull/50
Finally it also supports odd lengths, by just using a complex fft of the same length and hiding the conversions.

I made a big rewrite of RealFFT: https://github.com/HEnquist/realfft/pull/7
It now behaves a lot more like RustFFT, with a planner that reuses ffts. And whenever it makes sense it uses the same function names as RustFFT. It also includes the optimiztions from https://github.com/ejmahler/RustFFT/pull/50
Finally it also supports odd lengths, by just using a complex fft of the same length and hiding the conversions.

I dug into FFTS, and it's even worse: If you pass in an odd size, it crashes on unaligned SSE loads. If you disable SSE, it computes the wrong output.
So yeah, they just assume your input is even without asserting it.

I dug into FFTS, and it's even worse: If you pass in an odd size, it crashes on unaligned SSE loads. If you disable SSE, it computes the wrong output.
So yeah, they just assume your input is even without asserting it.

Well that explains it. I was confused when I couldn't find any check for if the length is even. I thought I just didn't see it, didn't expect it to be missing...

Well that explains it. I was confused when I couldn't find any check for if the length is even. I thought I just didn't see it, didn't expect it to be missing...

Who uses odd FFT anyway?

Who uses odd FFT anyway?

If you're computing an even-sized FFT that isn't a power of two, then it must have at least some odd prime factors. In that case, the library you're using will need to handle odd sizes internally in order to handle the odd prime factors of your size.

If you're computing an even-sized FFT that isn't a power of two, then it must have at least some odd prime factors. In that case, the library you're using will need to handle odd sizes internally in order to handle the odd prime factors of your size.

The new RealFFT is now published on crates.io as version 1.0.0!

The new RealFFT is now published on crates.io as version 1.0.0!

Update: Ever since mentioning the discrete hartley transform, I've been working on deriving a variant of the six-step mixed radix FFT algorithm for the DHT. As far as I know, this algorithm is original research, and it was pretty tough to derive:

// Computes a DHT via the six-step mixed-radix algorithm
fn compute_dht_mixedradix(buffer: &mut [f32], width: usize, height: usize) {
    let len = buffer.len();
    let mut scratch = vec![0.0; len];

    assert_eq!(len, width * height);

    // Step 1: Transpose the width x height array to height x width
    transpose::transpose(buffer, &mut scratch, width, height);

    // Step 2: Compute DHTs of size `height` down the rows of our transposed array
    for chunk in scratch.chunks_exact_mut(height) {
        compute_dht(chunk);
    }

    // Step 3: Apply twiddle factors
    for k in 0..height {
        // we need -k % height, but k is unsigned, so do it without actual negatives
        let k_rev = subtract_mod(0, k, height);
        for i in 0..width {
            // -i % radix, but i is unsigned, so do it without actual negatives
            let i_bot = subtract_mod(0, i, width);
            let top_twiddle = compute_dft_twiddle_inverse(i * k, len);
            let bot_twiddle = compute_dft_twiddle_inverse(i_bot * k, len);

            // Instead of just multiplying a single input vlaue with a single complex number like we do in the DFT,
            // we need to combine 4 numbers, determined by mirroring the input number across the horizontal and vertical axes of the array
            let top_fwd = scratch[i*height + k];
            let top_rev = scratch[i*height + k_rev];
            let bot_fwd = scratch[i_bot*height + k];
            let bot_rev = scratch[i_bot*height + k_rev];

            // Since we're overwriting data that our mirrored input values will need whenthey compute their own twiddles,
            // we currently can't apply twiddles inplace. An obvious optimization here is to compute all 4 values at once and write them all out at once.
            // That would cut down on the number of flops by 75%, and would let us do this inplace
            buffer[i*height + k] = 0.5 * (
                  top_fwd * top_twiddle.re
                - top_fwd * top_twiddle.im
                + top_rev * top_twiddle.re
                + top_rev * top_twiddle.im
                + bot_fwd * bot_twiddle.re
                + bot_fwd * bot_twiddle.im
                - bot_rev * bot_twiddle.re
                + bot_rev * bot_twiddle.im
            );
        }
    }

    // Step 4: Transpose the height x width array back to width x height
    transpose::transpose(&buffer, &mut scratch, height, width);

    // Step 5: Compute DHTs of size `width` down the rows of the array
    for chunk in scratch.chunks_exact_mut(width) {
        compute_dht(chunk);
    }

    // Step 6: Transpose the width x height array to height x width one lst time
    transpose::transpose(&scratch, buffer, width, height);
}

Pairing this with some trivial preprocessing or postprocessing, we can use this to implement R2C and C2R:
// Computes a DFT of real-only input by converting the problem to a DHT
fn compute_r2c_via_dht(input: &mut [f32], output: &mut [Complex<f32>]) {
    assert_eq!(output.len(), input.len() / 2 + 1);

    compute_dht(input);

    output[0] = Complex::from(input[0]);

    for (k, output_cell) in output.iter_mut().enumerate().skip(1) {
        *output_cell = Complex {
            re: (input[input.len() - k] + input[k]) * 0.5,
            im: (input[input.len() - k] - input[k]) * 0.5,
        }
    }
}

// Computes a DFT of real-only output by converting the problem to a DHT
fn compute_c2r_via_dht(input: &[Complex<f32>], output: &mut [f32]) {
    assert_eq!(input.len(), output.len() / 2 + 1);

    output[0] = input[0].re;

    for (k, input_cell) in input.iter().enumerate().skip(1) {
        output[k]               = (input_cell.re + input_cell.im);
        output[output.len() - k] = (input_cell.re - input_cell.im);
    }

    compute_dht(output);
}

The hardest part was applying twiddle factors: Instead of just a pairwise multiplication like in the FFT mixed radix algorithm, you have to compute data from 4 different points that are mirrors of each other across the 2D array.
I find this interesting, because it's sort of a reflection of the postprocessing you do to convert a R2C to a DHT. In both cases, you're looping over the front of the array and the back of the array simultaneously, and meeting in the middle.
Except I didn't derive DHT mixed radix in terms of the conversion to a DFT - I derived it entirely in terms of the O(n^2) definition of the DHT. So even though the reflection doesn't show up in the O(n^2) definition of the DHT, that reflection still seems like an inherent part of the transform. The fact that the reversal shows up both in the mixed radix algorithm and the conversion to R2C reminds me of a fractal, where you zoom in and end up seeing copies of the original fractal, and it gives you sense that that shape is very important to the computation of that fractal for some reason.
Fun stuff to think about.
I know variants of rader's algorithm and bluestein's algorithm have already been derived, and i THINK good-thomas has as well, so with those 3 we have everything need to compute every DHT size.
So next steps are, before committing to using the DHT, I also want to see if I can use the Discrete Cosine Transform Type 2 as the internal transform, since that also has a pretty trivial conversion to a DFT. I'm not sure how long that research will take, but it's entirely possible that a pure mixed radix algorithm like this for the DCT isn't a good idea, in which case it may become clear pretty quickly.
After that, I'll start a new crate called RustDHT and start building it. Finally, I'll make a crate called "RustFFT-Real" which depends on RustDHT and encapsulates it all, so that the DHT is just an implementation detail of the real-valued FFT, rather than an API-guaranteed part of the process.
Finally, once RustFFT-Real is released, I can convert RustDCT to use RustDHT instead of RustFFT. Long term, I'm considering making RustFFT a wrapper crate, that pulls in 'RustFFT-Complex, RustFFT-Real, RustDHT, RustDCT, the same way that numdoes withnum-complex, num-traits` etc. So that the most convenient thing is to just depend on rustFFT, but someone who wants to improve compile times can depend on only what they need.

Update: Ever since mentioning the discrete hartley transform, I've been working on deriving a variant of the six-step mixed radix FFT algorithm for the DHT. As far as I know, this algorithm is original research, and it was pretty tough to derive:

// Computes a DHT via the six-step mixed-radix algorithm
fn compute_dht_mixedradix(buffer: &mut [f32], width: usize, height: usize) {
    let len = buffer.len();
    let mut scratch = vec![0.0; len];

    assert_eq!(len, width * height);

    // Step 1: Transpose the width x height array to height x width
    transpose::transpose(buffer, &mut scratch, width, height);

    // Step 2: Compute DHTs of size `height` down the rows of our transposed array
    for chunk in scratch.chunks_exact_mut(height) {
        compute_dht(chunk);
    }

    // Step 3: Apply twiddle factors
    for k in 0..height {
        // we need -k % height, but k is unsigned, so do it without actual negatives
        let k_rev = subtract_mod(0, k, height);
        for i in 0..width {
            // -i % radix, but i is unsigned, so do it without actual negatives
            let i_bot = subtract_mod(0, i, width);
            let top_twiddle = compute_dft_twiddle_inverse(i * k, len);
            let bot_twiddle = compute_dft_twiddle_inverse(i_bot * k, len);

            // Instead of just multiplying a single input vlaue with a single complex number like we do in the DFT,
            // we need to combine 4 numbers, determined by mirroring the input number across the horizontal and vertical axes of the array
            let top_fwd = scratch[i*height + k];
            let top_rev = scratch[i*height + k_rev];
            let bot_fwd = scratch[i_bot*height + k];
            let bot_rev = scratch[i_bot*height + k_rev];

            // Since we're overwriting data that our mirrored input values will need whenthey compute their own twiddles,
            // we currently can't apply twiddles inplace. An obvious optimization here is to compute all 4 values at once and write them all out at once.
            // That would cut down on the number of flops by 75%, and would let us do this inplace
            buffer[i*height + k] = 0.5 * (
                  top_fwd * top_twiddle.re
                - top_fwd * top_twiddle.im
                + top_rev * top_twiddle.re
                + top_rev * top_twiddle.im
                + bot_fwd * bot_twiddle.re
                + bot_fwd * bot_twiddle.im
                - bot_rev * bot_twiddle.re
                + bot_rev * bot_twiddle.im
            );
        }
    }

    // Step 4: Transpose the height x width array back to width x height
    transpose::transpose(&buffer, &mut scratch, height, width);

    // Step 5: Compute DHTs of size `width` down the rows of the array
    for chunk in scratch.chunks_exact_mut(width) {
        compute_dht(chunk);
    }

    // Step 6: Transpose the width x height array to height x width one lst time
    transpose::transpose(&scratch, buffer, width, height);
}

Pairing this with some trivial preprocessing or postprocessing, we can use this to implement R2C and C2R:
// Computes a DFT of real-only input by converting the problem to a DHT
fn compute_r2c_via_dht(input: &mut [f32], output: &mut [Complex<f32>]) {
    assert_eq!(output.len(), input.len() / 2 + 1);

    compute_dht(input);

    output[0] = Complex::from(input[0]);

    for (k, output_cell) in output.iter_mut().enumerate().skip(1) {
        *output_cell = Complex {
            re: (input[input.len() - k] + input[k]) * 0.5,
            im: (input[input.len() - k] - input[k]) * 0.5,
        }
    }
}

// Computes a DFT of real-only output by converting the problem to a DHT
fn compute_c2r_via_dht(input: &[Complex<f32>], output: &mut [f32]) {
    assert_eq!(input.len(), output.len() / 2 + 1);

    output[0] = input[0].re;

    for (k, input_cell) in input.iter().enumerate().skip(1) {
        output[k]               = (input_cell.re + input_cell.im);
        output[output.len() - k] = (input_cell.re - input_cell.im);
    }

    compute_dht(output);
}

The hardest part was applying twiddle factors: Instead of just a pairwise multiplication like in the FFT mixed radix algorithm, you have to compute data from 4 different points that are mirrors of each other across the 2D array.
I find this interesting, because it's sort of a reflection of the postprocessing you do to convert a R2C to a DHT. In both cases, you're looping over the front of the array and the back of the array simultaneously, and meeting in the middle.
Except I didn't derive DHT mixed radix in terms of the conversion to a DFT - I derived it entirely in terms of the O(n^2) definition of the DHT. So even though the reflection doesn't show up in the O(n^2) definition of the DHT, that reflection still seems like an inherent part of the transform. The fact that the reversal shows up both in the mixed radix algorithm and the conversion to R2C reminds me of a fractal, where you zoom in and end up seeing copies of the original fractal, and it gives you sense that that shape is very important to the computation of that fractal for some reason.
Fun stuff to think about.
I know variants of rader's algorithm and bluestein's algorithm have already been derived, and i THINK good-thomas has as well, so with those 3 we have everything need to compute every DHT size.
So next steps are, before committing to using the DHT, I also want to see if I can use the Discrete Cosine Transform Type 2 as the internal transform, since that also has a pretty trivial conversion to a DFT. I'm not sure how long that research will take, but it's entirely possible that a pure mixed radix algorithm like this for the DCT isn't a good idea, in which case it may become clear pretty quickly.
After that, I'll start a new crate called RustDHT and start building it. Finally, I'll make a crate called "RustFFT-Real" which depends on RustDHT and encapsulates it all, so that the DHT is just an implementation detail of the real-valued FFT, rather than an API-guaranteed part of the process.
Finally, once RustFFT-Real is released, I can convert RustDCT to use RustDHT instead of RustFFT. Long term, I'm considering making RustFFT a wrapper crate, that pulls in 'RustFFT-Complex, RustFFT-Real, RustDHT, RustDCT, the same way that numdoes withnum-complex, num-traits` etc. So that the most convenient thing is to just depend on rustFFT, but someone who wants to improve compile times can depend on only what they need.

This is really good work!
I think the num-approach is s very good idea. In the end RustFFT-Real will have many options to choose from for the inner transform. What is faster, a wrapped avx-accelerated complex fft, or something dht-based? And what if we don't have avx? That will be fun to sort out. I'm guessing that a fixed logic planner will become too complicated when all possibilities are included. An estimating one is probably easier to get right.

This is really good work!
I think the num-approach is s very good idea. In the end RustFFT-Real will have many options to choose from for the inner transform. What is faster, a wrapped avx-accelerated complex fft, or something dht-based? And what if we don't have avx? That will be fun to sort out. I'm guessing that a fixed logic planner will become too complicated when all possibilities are included. An estimating one is probably easier to get right.

Update: i've been chugging away at this over the last few weeks. I have a repo for rustDHT, although it isn't published to crates.io yet https://github.com/ejmahler/RustDHT
There's no planner or bluestein's or raders equivalent yet, I've been focusing on getting the performance for small prime factors up to where it should be.
Prime butterflies can be computed with more or less the exact same algorithm as they are on a FFT, with a manual factorization of the naive DHT matrix. Radix4 works just like RustFFT's radix4, although the twiddle factor function is more complicated.
MixedRadix in RustDHT ends up being almost the exact same speed as MixedRadix in RustFFT. My theory for this is because in the transposes, the compiler can copy both elements of a complex number with the same instruction, so it can optimize away half the instructions involved in a transpose. But you can't optimize away half the instructions of a real-valued transpose, so the real one ends up being the same instruction count as the complex one -- and thus, it takes the same amount of time.
So I'm designing the library with the notion that we won't be doing MixedRadix, ever. That also rules out PFA, because the main value of PFA is that it's mixed radix without the twiddle factors.

Agreed that these would be great additions to RustFFT. I'm also using FFT for audio processing (a VST plugin) which uses real-to-complex and complex-to-real transforms. I did some simple benchmarks and RustFFT c2c is about 1.5x-2x slower than FFTW r2c and c2r for 4096 single precision values, for double precision the difference is even bigger, RustFFT is about 3x slower.
For now I'm using RealFFT which is as fast as FFTW for single precision, and even faster for double precision, so big thanks for implementing that!
( All benchmarks run on AVX2 CPU of course)

Btw @jesnor, I just published my bindings to FFTS (Fastest Fourier Transform in the South, which is faster than FFTW) here:
https://github.com/Boscop/ffts-rs
It is very fast and computing a FFT doesn't allocate: https://github.com/Boscop/ffts-rs/blob/master/src/lib.rs#L59
(Note that the ffts crate on crates-io is not my crate, and that one allocates a Vec for each FFT computation: https://docs.rs/ffts/0.1.3/ffts/struct.FFTSPlan.html#method.execute
I had created my ffts-rs crate in 2016 but hadn't published it, so someone else also wrote bindings and published them to crates-io, but I always use my bindings because they don't allocate.
(Also the one on crates-io uses https://github.com/anthonix/ffts whereas I use https://github.com/linkotec/ffts which is usually ahead of https://github.com/anthonix/ffts and supports MSVC.)

How does ffts real-only FFT compared to the RealFFT crate?

I also wonder about non-power-of-twos in FFTS. Since it uses Bluesteins for that, I would expect it to be far slower at that than both FFTW and RustFFT.


New CasePath initializer doesn't work with optional Root

I've just noticed that CasePaths created with the new CasePath initializer are unable to extract values from an optional Root. The created CasePaths use extractHelp instead of optionalPromotedExtractHelp unlike their predecessors created with the / operator.
You can reproduce the problem by performing the following change in the testPathExtractFromOptionalRoot test from
let path: CasePath<Authentication?, String> = /Authentication.authenticated

to
let path: CasePath<Authentication?, String> = CasePath(Authentication.authenticated)

and see the test fail afterwards. I'd expect the result to be the same after the change. The behavior is the same in Xcode 13.4 and Xcode 14b2.
I'm not sure at the moment what the right course of action would be other than moving to static functions instead of the initializer and how this should be reflected in the unit tests.

Thank you @stephencelis!


Improvement: Assign tooltip to DOM element

Hello,
it would be nice if you would add the option to assign a tooltip to a custom container.
For example, if a user loads an ajax page, you could initialize tooltips dedicated for this page and add it to a container, which will be overriden when the user loads a new ajax page.
So you don't have to remove them all programmatically and the global tooltips are still there in another container.
Example init:
M.Tooltip.init(document.querySelector('.tooltipped'), {    container: document.querySelector('#material-tooltip-container') });
Regards

ä
e
e
e
e
e
e
e
e
e
e


Used on stable diffusion xl

Hello, is there any plan to support XL

Currently no, because training an SD-XL version requires much more GPU resources


Swarm.java:40-43: Implement all of the Swarm operations....

The puzzle 3-e861473a from #3 has to be resolved:
https://github.com/amihaiemil/docker-java-api/blob/9abbafd0d62e336e7326c1ee82e1cef7ea1899e2/src/main/java/com/amihaiemil/docker/Swarm.java#L40-L43
The puzzle was created by Mihai A on 28-Mar-18.
Estimate: 30 minutes, role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

@amihaiemil/z please, pay attention to this issue

@0pdd/z this project will fix the problem faster if you donate a few dollars to it; just click here and pay via Stripe, it's very fast, convenient and appreciated; thanks a lot!

Job #70 is now in scope, role is DEV

The job #70 assigned to @llorllale/z, here is why; the budget is 30 minutes, see §4; please, read §8 and §9; if the task is not clear, read this and this

@0pdd the puzzle #95 is still not solved; solved: #77.


Slight build-system tweak to better support node.

Debian doesn't have d8 packaged (sigh).

Thanks a lot! I'm considering dropping support for anything but node to simplify things, see http://groups.google.com/group/jsshaper/browse_thread/thread/c6793fcb95918e9f for more info. Feel free to chime in with your thoughts.


Build Select dynamically

Looking to build a Select that only displays 3 at a time. I think this would be a useful feature that I'd be happy to add if others would find it useful.
However I'm running into compiler issues.  I'm a beginner so apologies if I'm missing something obvious:
fn three_at_a_time() -> Result<()> {
    let mut results_iter = vec![1,2,3,4,5].iter();

    let items_per_page = 3;
    let mut selector = Select::new();
    for _ in 1..=items_per_page {
        let next = results_iter.next();
        if next.is_none() {
            selector = selector.item(next.unwrap());
        }
    }
    let _chosen = selector.interact()?;

    Ok(())
}

Error:
error[E0308]: mismatched types
  --> src/main.rs:44:24
   |
44 |             selector = selector.item(next.unwrap())
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `Select`, found `&mut Select<'_>`

Select::item takes &mut self, a mutable reference to a select instance. You specify Select as mutable, but call it as selector = selector.item(...). First off, no need to re-set the selector, as it returns a mutable reference to the same struct. It's basically the same as selector.item(...);.
Secondly, I think it would compile if you call &selector.item(...) only. The error  occurs because you assign the return type of item, which is a mutable reference, to a variable of type mut Select.

Thank you! I really thought I had attempted that, apologies.
Both selector.item(...); and &selector.item(...); work as desired 👍

Ah ye, true, the first one works as well, I forgot! Glad I could help :)


support windows

updated to support windows

Hey @batoaqaa, Thank you for your contribution. I have just tested it on my windows machine and it works pretty good.
The change and little message for exit in Piomon is needed.
I see you are still pushing some commits, let me know when you are so ill test it one more time and merge it.

I have done with commits, this is the first time for me to contribute on github, that is why you see this.
Thank you for this good plugin.
Regards,


Spike: Axios

script several requests to RIOT APIs using Axios
create a generic function for making requests to the valorant API
demo/share to discuss

Goal is to familiarize yourself with Axios, RIOT APIs and what it takes to create these requests. This should create enough questions for us to engage on. Feel free to use any other libraries you think may help, the only requirement is that you use Axios and can make requests to several end points.

Tried to frame this with some small obtainable goals, which should help bridge some gaps and get a discussion going between us.


Web2Exe breaks package.json

I found that after building the application with Web2Executable and attempting to start it no window appears, but a number of processes start in the background. They keep running until killed.
I tried with and without compression and it was the same. But my application runs fine when started from the IDE, and I've noticed that Web2Exe changes the package.json by adding a ton of stuff.
So I tried building the application as an uncompressed folder, then I overwrote the package.json there with my original one, and then the application worked properly.
It would seem that Web2Exe is adding invalid options to the package.json or something. It'd be great if it wouldn't modify it if you didn't want it to.
Since I can't easily fix the package.json when using compression, and also would have to do it for each build, for each OS.

That's very interesting. It seems like since nwjs version 0.16.1 something has changed to make the package.json invalid. If you don't need specific features from the latest releases, try exporting with nwjs 0.16.1 for now while I look into it.
There is no way, that I'm aware of, to manipulate NW.js without modifying the package.json. If you know of a way, that would be cool, but otherwise the package.json manipulation has to stay.

I've tried building with 16.1, which is my current dev-version because I'm lazy, and it still breaks. I've not tried versions prior to that but no builds I've made with 16.1 and up have worked.
Also I'm not sure what you mean by "manipulating NW.js". If you mean the settings in the gui of Web2Exe such as the name, window parameters etc I don't really need that. I configure my package.json properly manually. So unless you always need to modify it to build it I could do with an option to have it not touch it for users who'd rather write it themselves if possible.
(I don't touch anything in the App Settings or Window Settings tabs)

So you're looking for something like a "readonly" mode that doesn't modify the package.json at all? That means all you'd want to use Web2Exe for is building and not setting options?

Exactly

I figured out the problem.
Web2Exe sets window: position to "None", while valid values are null, "center" or "mouse".
I have it set to null in my own package.json, but it's being overwritten on build and set to "None" instead, as does leaving "position" out of the package.json.

That's very weird. Which version of Web2Exe are you using? Since a long time ago, I put a check in the code for that so if a value is not set or empty, no values are added to the package.json. You're certain you didn't have the window position set before opening Web2Exe? Also, are you using the GUI or the CMD version?
This is the way Web2Exe manages the package.json file:

Open a project
Load all values from the package.json and populate fields
When a field changes, write the value to the package.json. If the field changes to empty or none, remove the field from the package.json.
On export, write some Web2Exe specific project settings to the package.json, keeping any fields that were already there that weren't explicitly set by Web2Exe, and copy the package.json to the export folder.

As you can see, although Web2Exe modifies the package.json, it keeps any settings that aren't explicitly set by you and only changes NW.js fields when you change them. It shouldn't add any fields that you don't want, and if it does, that means there's a bug.
When trying to reproduce the window position is None, I could only do it if I manually set the window position to be None in the package.json before opening Web2Exe.
Note: If you change anything in the package.json while Web2Exe is open, it doesn't understand those changes, so it will blow away anything you do. If you want to modify the package.json, do it before Web2Exe is open and it will keep anything you set.

That doesn't reflect what I see at all. I'm using v0.5.3b of the GUI version. (From the file in Releases named "Web2ExeWin-v0.5.3b.zip")
Like I said, I have window position defined in my package.json with the value null (not "null").
And without touching any of the fields, just hitting "Build" a bunch of stuff is added to the package.json
I'm doing this right now:

Closing Web2Exe
Verifying that my package.json looks correct: https://gist.github.com/Forecaster/99329f5e03a1f1cf7aaf782652a8472e
Start Web2Exe & Load the project
Without clicking anything else, immediately click "Export" (It's already set to uncompressed folder)
In the output dir, the now built win64x version's package.json look like this: https://gist.github.com/Forecaster/9deac8a4662ebe404d4769073e83690d

Right. Web2Exe will put in the default options if nothing is set. I need to change that because you're right, there shouldn't be any modifications if you don't want them.
Ah, I see. That's the problem. You need to remove the position option entirely from your package.json as a workaround for now. It looks like if the position is null from the get go (same as leaving it out of the package.json), Web2Exe gets confused and changes it to "None". I can reproduce this now and I'll fix it so it doesn't happen again. I'll also try to ensure that no extra fields related to NW.js are added.

Why do you even write all those settings to it?

I'd really like a "don't touch it" option that leaves it as it was input if possible.

The reason for adding the Web2Exe options was to keep a central place for the settings to live. Truth be told, I could move those settings into a separate file, which I am planning to do because writing them in the package.json frustrates people (as you know :P). Since you brought this to my attention, I'll be working on a "don't touch it" option that leaves the package.json unmodified. I'll also make sure that options that are not touched will not be added to the package.json.

Sounds great! Thanks!
And I guess the reason why removing "position" didn't work before when I tried it was because I didn't know to restart Web2Exe after modifying the package.json

Position: null is now ignored in the latest code. I'll pump out a build after a few more issues are down.


Revert "bugdown: Process word boundaries properly in realm_filters."

This reverts commit ff90c0101c487173fd470f7dff617cbd52338962 but keeps
the test cases added.

Merged as 3ed85f4cd7a8241f56a2d91465f7ce7b6e0c6ea4 after adding a comment next to the test cases, and expanding the commit message to explain why it was reverted.  Thanks @aero31aero!


[go_router] ModalBottomSheet is not popped when using GoRouter.pop()

Steps to Reproduce

Run the sample code
Press Options button, which will open a ModalBottomSheet
On ModalBottomSheet press Go to Page 2

Expected results:
Should open Page2
Actual results:
Throws: Exception: have popped the last page off of the stack; there are no pages left to show
The reason it throws is probably showModalBottomSheet uses its own Navigator.push, when we try to pop it using GoRouter.pop GoRouter probably can't see the pushed ModalBottomSheet. If we don't use GoRouter.pop, it will work, but will not pop the BottomSheet when we press the button to go to the second page. So we will be forced to use Navigator.pop instead of GoRouter.pop, which doesn't seem appropriate, single App mixing both.
Questions:

How are we supposed to use BottomSheets and Dialogs with GoRouter
Is there a way to force GoRouter register the page pushed by showModalBottomSheet and showDialog

Code sample
import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  MyApp({Key? key}) : super(key: key);

  final GoRouter _router = GoRouter(
    routes: <GoRoute>[
      GoRoute(path: '/', builder: (_, state) => const MyHomePage()),
      GoRoute(name: 'page2', path: '/page2', builder: (_, state) => const Page2()),
    ],
  );

  @override
  Widget build(BuildContext context) {
    return MaterialApp.router(
      routeInformationParser: _router.routeInformationParser,
      routerDelegate: _router.routerDelegate,
    );
  }
}

class MyHomePage extends StatelessWidget {
  const MyHomePage({Key? key}) : super(key: key);

  void _showAccountActions(BuildContext context, GoRouter router) {
    showModalBottomSheet<void>(
      context: context,
      builder: (_) {
        return SizedBox(
          height: 150,
          child: Padding(
            padding: const EdgeInsets.all(8),
            child: ElevatedButton(
              onPressed: () {
                // If pop is commented it will work, but will not pop the BottomSheet.
                // So we will be forced to use Navigator.pop
                router.pop();
                router.pushNamed('page2');
              },
              child: const Text('Go to Page 2'),
            ),
          ),
        );
      },
    );
  }

  @override
  Widget build(BuildContext context) {
    final _router = GoRouter.of(context);
    return Scaffold(
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            ElevatedButton(
              onPressed: () => _showAccountActions(context, _router),
              child: const Text('Options'),
            ),
          ],
        ),
      ),
    );
  }
}

class Page2 extends StatelessWidget {
  const Page2({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final _router = GoRouter.of(context);
    return Center(
      child: ElevatedButton(
        onPressed: () => _router.pop(),
        child: const Text('Go back'),
      ),
    );
  }
}

Logs
[GoRouter] known full paths for routes:
[GoRouter]   => /
[GoRouter]   => /page2
[GoRouter] known full paths for route names:
[GoRouter]   page2 => /page2
[GoRouter] setting initial location /
[GoRouter] MaterialApp found

======== Exception caught by gesture ===============================================================
The following _Exception was thrown while handling a gesture:
Exception: have popped the last page off of the stack; there are no pages left to show

When the exception was thrown, this was the stack:
#0      GoRouterDelegate.pop (package:go_router/src/go_router_delegate.dart:183:7)
#1      GoRouter.pop (package:go_router/src/go_router.dart:133:32)
#2      MyHomePage._showAccountActions.<anonymous closure>.<anonymous closure> (package:test_go_router/main.dart:41:24)
#3      _InkResponseState._handleTap (package:flutter/src/material/ink_well.dart:989:21)
#4      GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:198:24)
#5      TapGestureRecognizer.handleTapUp (package:flutter/src/gestures/tap.dart:608:11)
#6      BaseTapGestureRecognizer._checkUp (package:flutter/src/gestures/tap.dart:296:5)
#7      BaseTapGestureRecognizer.acceptGesture (package:flutter/src/gestures/tap.dart:267:7)
#8      GestureArenaManager.sweep (package:flutter/src/gestures/arena.dart:157:27)
#9      GestureBinding.handleEvent (package:flutter/src/gestures/binding.dart:443:20)
#10     GestureBinding.dispatchEvent (package:flutter/src/gestures/binding.dart:419:22)
#11     RendererBinding.dispatchEvent (package:flutter/src/rendering/binding.dart:322:11)
#12     GestureBinding._handlePointerEventImmediately (package:flutter/src/gestures/binding.dart:374:7)
#13     GestureBinding.handlePointerEvent (package:flutter/src/gestures/binding.dart:338:5)
#14     GestureBinding._flushPointerEventQueue (package:flutter/src/gestures/binding.dart:296:7)
#15     GestureBinding._handlePointerDataPacket (package:flutter/src/gestures/binding.dart:279:7)
#19     _invoke1 (dart:ui/hooks.dart:170:10)
#20     PlatformDispatcher._dispatchPointerDataPacket (dart:ui/platform_dispatcher.dart:331:7)
#21     _dispatchPointerDataPacket (dart:ui/hooks.dart:94:31)
(elided 3 frames from dart:async)
Handler: "onTap"
Recognizer: TapGestureRecognizer#c2e1a
  debugOwner: GestureDetector
  state: ready
  won arena
  finalPosition: Offset(177.8, 748.3)
  finalLocalPosition: Offset(169.8, 87.4)
  button: 1
  sent tap down
====================================================================================================

go_router: ^3.0.6

flutter doctor -v
[√] Flutter (Channel stable, 2.10.4, on Microsoft Windows [Version 10.0.19044.1586], locale en-US)
    • Flutter version 2.10.4 at D:\Apps\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c860cba910 (4 days ago), 2022-03-25 00:23:12 -0500
    • Engine revision 57d3bac3dd
    • Dart version 2.16.2
    • DevTools version 2.9.2

[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at D:\Apps\Android\Sdk
    • Platform android-31, build-tools 31.0.0
    • ANDROID_HOME = D:\Apps\Android\Sdk
    • Java binary at: D:\Apps\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.11+9-b60-7590822)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[X] Visual Studio - develop for Windows
    X Visual Studio not installed; this is necessary for Windows development.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components

[√] Android Studio (version 2021.1)
    • Android Studio at D:\Apps\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.11+9-b60-7590822)

[√] IntelliJ IDEA Ultimate Edition (version 2021.1)
    • IntelliJ at D:\Apps\JetBrains\IntelliJ IDEA 2021.1
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart

[√] Connected device (4 available)
    • sdk gphone x86 64 arm64 (mobile) • emulator-5554 • android-x64    • Android 11 (API 30) (emulator)
    • Windows (desktop)                • windows       • windows-x64    • Microsoft Windows [Version 10.0.19044.1586]
    • Chrome (web)                     • chrome        • web-javascript • Google Chrome 99.0.4844.82
    • Edge (web)                       • edge          • web-javascript • Microsoft Edge 99.0.1150.52

[√] HTTP Host Availability
    • All required HTTP hosts are available

@chunhtai Any update on this issue? Or do you have a work around for this?

you can manually pop the navigator if you know which one to pop.
I don't have an update for this issue

_ModalBottomSheetRoute

It is public now in latest master in flutter

@chunhtai I just tried popping with the Nav 1.0 pop() method and it seems to be working. Could this somehow affect how Go_Router is working within my app if I try to bypass it and use the generic Navigator?
For anyone else, in my particular use case, I was navigating to another screen using a button in a bottom sheet. However, once I popped back to the original screen, the bottom sheet was still there. Now I am doing this when navigating to the other screen from the bottom sheet:
onPressed: () {
            Navigator.pop(context);
            GoRouter.of(context).push('/add-event');
          },


Revert "CRB-301 exit if min_peers is not sustained"

Reverts gluwa/Sawtooth-Core#60

@CAGS295 this PR has been part of test builds for a while. I think we should merge it, right ?


Barebones microsite

Followup on #753
Reviewed by @larsrh

Codecov Report

Merging #760 into master will increase coverage by 0.2%.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           master    #760     +/-   ##
========================================
+ Coverage    52.1%   52.3%   +0.2%
========================================
  Files         196     196
  Lines       11904   11904
  Branches     1646    1644      -2
========================================
+ Hits         6202    6226     +24
+ Misses       5702    5678     -24

Impacted Files
Coverage Δ

core/src/main/scala/spire/math/Algebraic.scala
67.47% <ø> (-0.21%)
:arrow_down:

extras/src/main/scala/spire/math/FixedPoint.scala
37.15% <0%> (-0.55%)
:arrow_down:

core/src/main/scala/spire/math/SafeLong.scala
97.29% <0%> (ø)
:arrow_up:

core/src/main/scala/spire/math/Natural.scala
65.75% <0%> (+0.6%)
:arrow_up:

core/src/main/scala/spire/math/Interval.scala
71.46% <0%> (+2.05%)
:arrow_up:

...ala/spire/math/poly/BigDecimalRootRefinement.scala
85.43% <0%> (+3.97%)
:arrow_up:

...ore/src/main/scala/spire/math/interval/Bound.scala
59.05% <0%> (+6.29%)
:arrow_up:

...rc/main/scala/spire/optional/partialIterable.scala
96% <0%> (+8%)
: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 e03aaed...bcef72c. Read the comment docs.

Yep, it was intentional to move the whole README.md to the site, as it removes some tut machinery that was checking it before.
Agree we need a barebones README.md though. Will do and merge.

Done. Waiting for @non input, as I can't publish a microsite on non/spire; right now, it's pointing to https://denisrosset.github.io/spire/ which is not ideal.
I'd love to move Spire to the typelevel umbrella -- @larsrh how would we deal with the microsite in that case?

Hmm, both of us should be able to just create a gh-pages branch in this repository, which is all that is required to create a microsite.

Let me try.

 I guess we have to activate the site in the project settings.

This is live now: https://typelevel.org/spire/


How do I prevent adding a suffix to generated GQL Document?

Hello!
So I currently want to add _t to all my types but for TypedDocumentNode I don't want to add _t to it since its not a type.
I have the config options typesSuffix: _t at the moment (which also adds it to my Document node which I don't want). Is there another configuration I could use?
i.e right now types are
for a OrgMember
OrgMember_t
OrgMemberFragment_t
OrgMemberDocument_t <-- I don't want this since I will be using this to pass into my useQuery hooks + query promises
I also noticed that if I tried a different plugin i.e typescript-react-apollo
the Document GQL are also adding a _t onto the name even though its not considered a type
OrgMemberDocument_t

Hi there! I'm moving this to graphql-codegen repo, since this is related to the plugin developed there.

Ah ok thank you!

Any updates on this?


Adding wallet security services layer

Signed-off-by: Mostafa<EMAIL_ADDRESS>Summary of Changes
This is just a service layer that will serve the following purpose:

Adding different security flows to initializing the wallet
Using Argon key derivation function (KDF) to generate wallet key from user PIN
Initializing different storage engines (Keychain/Prefs) to save generated keys/Ids

The service layer is supposed to be used within a global provider context or a reducer hook
Steps to do next in different PR

Moving wallet init from App.tsx to be initialized upon successful pin entry
Wire wallet keys with wallet config before initializing the wallet

Pull Request Checklist

[x] All commits contain a DCO Signed-off-by line (we use the DCO GitHub app to enforce this).
[x] Updated LICENSE-3RD-PARTY.md for any added dependencies or vendored components.
[x] Run prettier: npm run style-format
[] Updated documentation for changed code and new or modified features.

@MosCD3 Able to sync package.json and package-lock.json? They need to be in-sync for npm ci to work. Ty.

@jleach Done


chore(compiler): add directive extraction example

Added a fun example extracting directives on nested fields etc.

Fixes #636


Adding area calculator using Heron's formula

I would like to add a calculator for finding the area of a triangle when sides are given using Heron's Formula.

Go ahead
Deadline 24 April,2021 11:59 PM IST

Implement this under, Shapes Calculator -> Triangle ->Scalene Triangle

@sairish2001 I'm sorry I didn't saw that there is already implementation of heron's formula under scalene triangle so should I close this issue/

Yes, close it


Support various s3 configuration resource types

In #136 I added convection support for CorsConfiguration S3 bucket property. This PR takes it one step further by adding all other configuration resource types to convection.

Lifecycle Configuration
Logging Configuration
Notification Configuration
Replication Configuration
Versioning Configuration
Website Configuration

@athompson-r7 On an internal issue I noticed you mentioning:

In order to support xxx service we need to add support from the S3 Lambda Notification type.

I did that in this PR. Specifically in https://github.com/rapid7/convection/pull/137/commits/da78d738aafc65e27e9efb2aa354f0e6071f7888. 😄

@abegley-r7 and I had a discussion this morning around adding these new resource types to the DSL. He made me realise that this conversion and the #136 break backwards compatibility (we used to be able to pass in a Hash to define the properties). I'll go ahead and add the backwards compatibility layer before we make any other movements on this PR.

Lets close and reopen this against master.

Lets close and reopen this against master.

@bcall-r7 👍 will leave open until I have a chance to rebase and update for backwards compatibility. For now I want this visible (also marked as do not merge).

Actually, I think we should delete the v0.2 branch so we ensure nothing accidentally gets pushed there, and to make sure we don't have something pointed at v0.2 (like Travis or Jenkins, etc.)  Closing that branch will close this PR.

Go ahead in that case, maybe that's why I couldn't delete the branch earlier.
Sent from my iPhone
On 5 Jul 2016, at 19:06, Brandon Turner <notifications<EMAIL_ADDRESS>wrote:
Actually, I think we should delete the v0.2 branch so we ensure nothing accidentally gets pushed there, and to make sure we don't have something pointed at v0.2 (like Travis or Jenkins, etc.) Closing that branch will close this PR.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/rapid7/convection/pull/137#issuecomment-230556001, or mute the threadhttps://github.com/notifications/unsubscribe/ACDbn9rEWNaOvS7WLvRu90XUm_-zvVI_ks5qSp02gaJpZM4I_aLn.

Leaving the branch open to cherry-pick from later. We can delete it after I push up the new PR based-off of master.


move locations API logic into custom hook

This is a great little improvement!!
It seems like a good opportunity to add a test for this, too. Testing hooks is a bit weird at first, but in this case I think there's a lot of benefit to testing the hook and mocking the gapi stuff (that part will be less fun for sure, so can see an argument for moving the testing into a separate PR)
You might want to test the hook directly, which will require installing a new library I think:
https://github.com/testing-library/react-hooks-testing-library
https://react-hooks-testing-library.com/reference/api
I didn't go through this whole thing but looks like a good primer for testing hooks: https://blog.logrocket.com/a-quick-guide-to-testing-react-hooks-fa584c415407/


Up ORCID field to full 16 characters

In Django admin, the default field length is too short for ORCIDs -- it should be a few characters longer.

Try editing backend/apis/admin.py
with info from https://stackoverflow.com/questions/910169/resize-fields-in-django-admin


Topology validations with fully qualified class names

This fixes #201.
In addition the following improvements have been done:

Fail on validation class not found in class path. KTB should not preceed with processing in this case.

Please check if the PR fulfills these requirements

[x] The commit messages are descriptive
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)
[x] An issue has been created for the pull requests. Some issues might require previous discussion.

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature improvement.

What is the current behavior? (You can also link to an open issue here)
See #201.

What is the new behavior (if this is a feature change)?
See #201.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No. Removing old, now deprecated behavior, should be handled in a later commit.

LGTM! good job man! appreciate a ton your help. left only a small cosmetic comment. what do you think?

Thanks! And thank you for a quick review! Fixed the small issues.

LGTM! good job man! appreciate a ton your help. left only a small cosmetic comment. what do you think?

Thanks! And thank you for a quick review! Fixed the small issues.


angiography procedure term replaced by

angiography procedure
https://www.ebi.ac.uk/ols4/ontologies/maxo/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FMAXO_0001259
was obsoleted and "term_replaced" by therapy, but this is a diagnostic procedure and should be "term_replaced" by
angiography
https://www.ebi.ac.uk/ols4/ontologies/maxo/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FMAXO_0001259

Maybe the issue is too long ago, but it appears to be fixed as it is in the diagnostic branch. closing.


Preventing comments from getting into entries

Signed-off-by: Pablo Caderno<EMAIL_ADDRESS>Fixes issue #72
I've also removed the spaceRemover and tabReplacer since strings.TrimSpace() should get rid of either of these.

Thanks @kadern0 for this PR, I'll check it as soon as I can create a new release.

Thanks for your contribution @kadern0. I'm reviewing this, but tabReplacer and spaceRemover also takes care of extra spaces and tabs inside the lines, not only on leading and trailing characters. Could you restore that before merging?

Done!


fix issue that ip_forward can't be disabled

Before this, docker -d --ip-forward=false didn't work.
Signed-off-by: Qiang Huang<EMAIL_ADDRESS>

Except with this, if ip_forward was turned on by something other than docker, this is now going to turn it off. This would not be expected behavior to me. I would expect docker to leave the setting alone.

It will only turn ip-forward off if we set --ip-forward=false, it is always a write 0 or 1 thing, Docker don't leave the setting alone, maybe it can be easier to understand if we use something like --disable-ip-forward and leave the default as false.

ya this is kinda outside our bounds if something else had turned it on in the first place like @phemmer said may cause confusion and other thinngs running on the same server to break
I think this should be closed, because of the ramifications of us changing this on behalf of the user

@jfrazelle I think you didn't get it, @phemmer understood wrong, by default, Docker won't turn ip-forward off if someone turned it on. Docker will only turn it off if we use --ip-forward=false.
This issue first discussed here: https://github.com/docker/docker/issues/2396, then everyone agreed that we should turn ip-forward on by default, but they also said we should offer users to turn it off, but then @tianon sent the PR: https://github.com/docker/docker/pull/3801 it didn't handle disable scenario, I think that's a bug.
If we don't offer users to turn it off, if someone just want it be off, then Docker obviously impact that.

OK, I think I understand what @phemmer thought, I just think it different, because I set ip_forward off, then I run Docker, found it turn it on and can never turn it off. Because even I set --ip-forward=false, Docker didn't disable it but just leave it as it was, which is still on.
So I think we should still offer users to disable it, because ip-forward=false really doesn't look like leave it alone. WDYT?

To me --ip-forward=true means yes turn ip_forward on, and --ip-forward=false means no don't turn ip_forward on (but does not imply turning it off).
I understand the need for docker to touch the ip_forward feature when starting up, because it's necessary for docker to fully function. But that's the only time it should touch it. Docker isn't a configuration management system. If it doesn't need ip_forward to be off, then it shouldn't turn it off.
If the concern is docker leaving ip_forward on when docker isn't running, then to me the proper solution is for docker to turn it off when it exits, if docker was the one to turn it on in the first place. And even this should be controllable, as there may be multiple things on the system which need ip_forward on, and docker simply turned the feature on first.

@phemmer I don't think turn ip-forward off when Docker exits, if Docker was the one to turn it on is worthy to do. If we consider --ip-forward=false doesn't mean disable ip-forward, I can take that. Maybe just needs some docs to clarify that as https://github.com/docker/docker/pull/13205 did.


API surface and deprecation policy

Issue description
Currently there is no clear nixpkgs policy has regarding stability and deprecation. This was discussed a bit in meeting NixOS/nixpkgs-architecture-issues#12. There is also a NAT wiki article on deprecation.
Previous efforts:

https://github.com/NixOS/rfcs/pull/33
https://github.com/NixOS/rfcs/pull/127

I hope we can discuss this again.
The current problem has two aspects: on the one hand, we have no rules for reference to decide when a package can be deprecated or removed; on the other hand, our current handling of deprecation and removal is actually very crude and not automated enough.
The previous discussion of yuzu revealed this: do we really need to immediately remove packages that are obsolete but are still used by a lot of users? Can't we give them time to migrate? On the other hand, such treatment is often only available to popular software, while less popular packages are just lying there, and no one cares about them, even if some of them have been in a state of build failure for a long time.


Handle list indices in EAPI output.

On the BGP_ACL_filter_list_AS_PATH.txt test, the actions run fine but the testing is generating an error.
TypeError: list indices must be integers, not unicode
on this step.
Check Weight
[Documentation]	Check Weight
Record Output	cmd=show ip bgp ${PREFIX}
Refresh Command Output	cmd=show ip bgp ${PREFIX}
${weight1}=	Get Value	vrfs default bgpRouteEntries ${PREFIX} bgpRoutePaths 0 weight
${weight2}=	Get Value	vrfs default bgpRouteEntries ${PREFIX} bgpRoutePaths 1 weight
${result}=	Evaluate	'${weight1}' == '1000' or '${weight2}' == '1000'
Should Be True	${result}

Closed by #12


Create Landscaper Component for "Virtual Garden Cluster"

Description
Create a landscaper-conform model for the Virtual Garden Cluster Component. The model should go along with a suitable documentation about how the model is structured, including its integration into the landscape-setup.
Done Criteria

[ ] A model for the Virtual Garden Cluster has been created
[ ] Documentation about the model has been created
[ ] In landscape-setup, the new model is used

Questions

Where is the component descriptor currently build containing the images used in the virtual garden chart

Current pull requests under review:

Deployment of HVPA CRD
Deployment of secrets with certificates

Current pull requests under review:

Deployment of secrets with certificates

set to blocked for now, we will pick this up again after Daniel has finished his component and we had another sync with him. Then we have to update the component due to the various changes ...

@In-Ko should we close this?

Yes.


[refurb] Implement verbose-decimal-fraction-construction (FURB164)

Summary

Implement FURB164 in the issue #1348.
Relevant Refurb docs is here: https://github.com/dosisod/refurb/blob/v2.0.0/docs/checks.md#furb164-no-from-float
I've changed the name from no-from-float to verbose-decimal-fraction-construction.
Test Plan

I've written it in the FURB164.py.

Maybe verbose_fraction_construction?

I have thought of that, but should we incorporate Decimal as it is checks for both constructions of Decimal and Fraction?

Also I'm not very sure why cargo test for wasm is failing... Let me check on that.

It sometimes has this error. Let me re-run it to see if it resolves the issue.

Sorry for the late response and thanks for the review!


python311Packages.dtlssocket: 0.1.16 -> 0.1.18

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.dtlssocket is: Cython wrapper for tinydtls with a Socket like interface
meta.homepage for python311Packages.dtlssocket is: https://git.fslab.de/jkonra2m/tinydtls-cython
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.1.18 with grep in /nix/store/xhpg9slv25pvbkc30r4ycnnihv3yfmch-python3.11-dtlssocket-0.1.18
found 0.1.18 in filename of file in /nix/store/xhpg9slv25pvbkc30r4ycnnihv3yfmch-python3.11-dtlssocket-0.1.18

Rebuild report (if merged into master) (click to expand)

6 total rebuild path(s)

6 package rebuild(s)

First fifty rebuilds by attrpath

home-assistant-component-tests.tradfri
python311Packages.dtlssocket
python311Packages.pytradfri
python312Packages.dtlssocket
python312Packages.pytradfri

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xhpg9slv25pvbkc30r4ycnnihv3yfmch-python3.11-dtlssocket-0.1.18 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.dtlssocket https://github.com/r-ryantm/nixpkgs/archive/8a2c1e2ba19122c8ea0fc730b512336ed31f1fc7.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/8a2c1e2ba19122c8ea0fc730b512336ed31f1fc7#python311Packages.dtlssocket

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xhpg9slv25pvbkc30r4ycnnihv3yfmch-python3.11-dtlssocket-0.1.18
ls -la /nix/store/xhpg9slv25pvbkc30r4ycnnihv3yfmch-python3.11-dtlssocket-0.1.18/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

4 packages marked as broken and skipped:

python311Packages.pytradfri
python311Packages.pytradfri.dist
python312Packages.pytradfri
python312Packages.pytradfri.dist

5 packages built:

home-assistant-component-tests.tradfri
python311Packages.dtlssocket
python311Packages.dtlssocket.dist
python312Packages.dtlssocket
python312Packages.dtlssocket.dist

Maintainer pings
cc @dotlambda for testing.

Result of nixpkgs-review pr 310242 run on x86_64-linux 1

4 packages marked as broken and skipped:

python311Packages.pytradfri
python311Packages.pytradfri.dist
python312Packages.pytradfri
python312Packages.pytradfri.dist

5 packages built:

home-assistant-component-tests.tradfri
python311Packages.dtlssocket
python311Packages.dtlssocket.dist
python312Packages.dtlssocket
python312Packages.dtlssocket.dist


Add support for MethodField

Pushed up a PR for this https://github.com/localmed/pyserializer/pull/15

Pushed this in version v0.4.0


feat: provide structured logger to functions in context

Provides the fastify server's structured logger to functions via the context.

You're right, this definitely should have started with the tests.

Using the logger from the server instance worked fine, actually, but it was a bit sloppy due to the usage of the global server variable from within the onRequest hook.  It seems the right place to set that member; in the Context construction phase.  Let me know if that doesn't seem like a good idea.


Fix regression, of configurable text and code colors

THe refactor for 0.7.0, didn't actually use the the LocalContentColor where appropriate so text was always black.
I also updated the README for the new style, added a code block to the sample app, and renamed the backgroundCode to codeBackground and added codeText

Thank you very much for the PR.
The only question I had was on the renaming of the backgroundCode? What was the reasoning for this?

Thank you very much for the PR.
The only question I had was on the renaming of the backgroundCode? What was the reasoning for this?

With the current naming schema
backgroundCode
the text option for code would likely be
textCode
for consistency.
codeBackground
codeText

grouped the variables by their Markdown type of "code".   Similar to how it was pre refactor.   It seems to make more sense when typing to look for the markdown element  you want to color and have the options listed, vs looking for background then the markdown element.
Let me know if you rather I revert it.


Support apt-based installation (a modern addition to apt-get) as well as distro being detected or specified

Please place the commits relevant to this pull request into a separate branch in your repo so that only the commits related to this pull request are reflected here.

@devttys0 Sorry, forgot this PR was still open and that github automatically adds new commits to it. Is it OK if I rename the PR?

Yep!

Sorry for this PR ending up so big and with many different threads of development.
deps.sh: Support and detect Kali.
This means that Kali-users will be able to use the deps.sh-script and thus get to a full installation much easier. This implementation uses the a line from #253 and is inspired by the mentioned idea of auto-detection (with manual override supported).
deps.sh: Support and detect the modern apt-tool.
In newer debian/ubuntu-based distros, apt is the tool to install packages with, for our usage, it's mostly an aesthetic upgrade from apt-get (which confusingly is a part of the apt-package).
tests: Automated testing of some parts of the engine, using the python-api.
This enables a faster and safer testing and makes it easier to detect issues early. In the future, I hope bugs-fixes, new and improved signatures will include test-cases, so that we can ensure that we don't break anything. To avoid issues with copyright, I suggest that all signature-tests use input-vectors created by the commiter or which is distributed under a compatible license. Coverage is also reported, however no minimum is specified. Over time, it might also be useful to have code-style issues detected through nose however the current code-base requires some work before that.
travis ci: Automated testing for all updates to the branches, including to pull-request.
This means that after this (or rather, after @devttys0 enables it on travis.org), all new pull-requests will be tested against the test-cases, with reports being provided back both on the travis-website and in the pull-requests. It also means that each time a push is made to master or any other branch, tests will be run and the result will be provided on the main-page (through README.md). Reports will also be provided by email.

I've merged your changes to the SWF signature, travis testing, deps.sh, and PEP8. The only things I've not changed are the AIH0 and Intel Hex / S-record signatures. I have created a new ticket for improving the {more} tag.
I have created an account on travis-ci.org, which is pretty awesome, so thank you for that! I'll be adding new tests for critical signatures / features.


Bevy 0.10

@lecoqjacob I continued on your branch here. And updated the lib to be pretty much equal to bevy_winit's current state (mostly copy)
Wanna take a look?
I also got rid of some unnecessary things like pipeline_sync_data (user can create one if they wish to split render into many systems).

Gonna merge once the checks go through and do a release :). Thanks for pushing me to do this @lecoqjacob, wasn't too bad after all.


How to confirm that the read query goes to the slave database

It is configured with read-write separation. How to confirm that the read query goes to the slave database and the write operation goes to the master database

You can use the configuration:
sql.show: true
to show the Actual SQL

Configured, but it doesn't work，as follows  true

@zhumaoliang  Can you show your configuration?

OK，

Ok. It looks the same as the documentation.
Do you use the 4.0.0-RC2 version?
If the problem persists after reading the documentation, could you provide a sample project to github?

@zhumaoliang any update?


Undefined symbols for architecture arm64:   "OBJC_CLASS$_CrashReport"

Hello,
I'm trying to make the project on M1 Max macOS Version 13.3.
I'm getting the next error:
georgexploit@Georges-MBP honggfuzz % make
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -o honggfuzz cmdline.o display.o fuzz.o honggfuzz.o input.o mangle.o report.o sanitizers.o socketfuzzer.o subproc.o mac/arch.o mac/mach_excServer.o mac/mach_excUser.o libhfcommon/libhfcommon.a  -pthread -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lm -F/System/Library/PrivateFrameworks -framework CoreSymbolication -framework IOKit -F/System/Library/Frameworks -F/System/Library/PrivateFrameworks -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/System/Library/Frameworks -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/System/Library/PrivateFrameworks -framework Foundation -framework ApplicationServices -framework Symbolication -framework CoreServices -framework CrashReporterSupport -framework CoreFoundation -framework CommerceKit third_party/mac/CrashReport_Sierra.o
ld: warning: ignoring file third_party/mac/CrashReport_Sierra.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_CrashReport", referenced from:
      objc-class-ref in arch.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [honggfuzz] Error 1

how can I fix it?
Thanks

If you type file -b third_party/mac/CrashReport_Sierra.o, there goes your answer why it fails.

If you type file -b third_party/mac/CrashReport_Sierra.o, there goes your answer why it fails.

Thank you for the quick response,
is there a way to fix this issue or is the project not updated for apple's new chips?

no update so far since https://github.com/google/honggfuzz/issues/477

Could POSIX code work instead?
OS=POSIX make clean all
?

Could POSIX code work instead?
OS=POSIX make clean all
?

Unfortunately, now it has problems with different variable types and finding included headers that don't exist for macOS.
but thanks for the try to help

Same issue over here unfortunately. @georgexploit were you able to fix it since then ?


Temperature values

Hi, is there a way to get value of temperature for some pixel (in degree Celsius/Fahreint/Kelvin)?

Hello, sadly no attempt was made at converting the measurements in temperatures. All the calibration process is yet to be done.