math/rand: rand.Float64 is not purely uniform

The current implementation (as of Go 1.5) of rand.Float64 is:
func (r *Rand) Float64() float64 {
  f := float64(r.Int63()) / (1 << 63)
  if f == 1 {
    f = 0
  }
  return f
}

As the mantissa of a Float64 is on 52 bits, there are a lot of numbers (2^11 ?) that were initially mapped to 1 that will effectively become 0. The Float64() method therefore does not preserve the uniform property of the underlying Int63() method.
This is related to issues https://github.com/golang/go/issues/4965 and https://github.com/golang/go/issues/6721 .
A better alternative, even if this implies to trade numbers under machine epsilon against uniformity comes from the prototypical code of Mersenne Twister 64 at http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c :
/* generates a random number on [0,1)-real-interval */
func (r *Rand) Float64() float64 {
    return (float64(r.Int63()) >> 10) * (1.0/9007199254740992.0)
}

/* generates a random number on (0,1)-real-interval */
func (r *Rand) Float64Open() float64 {
    return (float64(r.Int63())  >> 11) + 0.5) * (1.0/4503599627370496.0)
}

An interesting consequence is that this preserves symmetry around 0.5. It's also quite a bit faster on my machine, as the if statement of the original algorithm deteriorate performance significantly (not entirely sure why).

There is a comment in the source code:
    // A clearer, simpler implementation would be:
    //  return float64(r.Int63n(1<<53)) / (1<<53)
    // However, Go 1 shipped with
    //  return float64(r.Int63()) / (1 << 63)
    // and we want to preserve that value stream.

That's an interesting comment, but the consequence of those choices is a non uniform distribution, where 0 and numbers near 0 are over-represented.

A quick test of
// Float64 returns, as a float64, a pseudo-random number in [0.0,1.0).
func (r *Rand) Float64() float64 {
	// Change from Go 1 -- make results be uniform.
	return (float64(r.Int63() >> 10)) * (1.0 /<PHONE_NUMBER>740992.0)
}

// Float32 returns, as a float32, a pseudo-random number in [0.0,1.0).
func (r *Rand) Float32() float32 {
	// Change from Go 1 -- make results be uniform.
	return (float32(r.Int63() >> 39)) * (1.0 / 16777216.0)
}

shows a non-uniform distribution of the LSB -- it is 25% 1, instead of 50% 1.

Isn't it wrong to look at the LSB for floating point numbers?
Floating point numbers are not evenly distributed, there are much more of them near 0 than near 1. This is why truncation to 53 bits (the mantissa) is necessary to have a uniform distribution.

As I understand it, staring with a 53-bit integer and then dividing it by 2-to-the-53 means that there are floating point numbers that will occur with probability zero.  Any "random" value less than 1/2 (252/253) will not have its LSB set, for example.  I think this is also a flaw in the original algorithm, but for a smaller set of FP numbers.
I don't actually know what is officially "right" here because I am not an expert, but right now neither of these algorithms is doing much for me.  I recall from some earlier work that one way to do this is to take a 64-bit random number, split it into 12 and 52-bit parts, stuff 52-bits into mantissa, and then count leading zeroes on the 12-bit part to derive your exponent.  If the 12-bit part is all zero, pull more 64-bit random numbers till you get one that is not zero or till you hit (about, up to fenceposts) 1024 of them in which case you call it zero, and use the number of leading zeroes to derive your exponent.  Since you'd only do second RNG call 1 time out of 4096, this could be plenty efficient since it involves no FP ops at all (though we might hope that multiplication and division by powers of two would be very efficient).
I am somewhat creeped out that both algorithms are guaranteed not to hit certain FP values.

I would not worry about not hitting certain FP values, especially since FPs are not uniformly distributed by nature (much more towards 0 than towards 1). What's important is that the FP values generated have a uniform distribution. If you restrict yourself to the 53 bits, then the FP numbers are uniformly spaced in (0,1), so it's easy to grasp that the FP generator has to be uniform if the underlying integer generator is uniform. Yes you loose the small numbers around 0 (less than machine epsilon) but there is no way to be uniform and keep those.
Maybe it's not a very good argument, but I would trust Matsumoto and the official Mersenne-Twister implementation as he is a very prominent researcher in the area.

maybe this paper could help understanding the idea of uniform random floating point numbers:
http://www.doornik.com/research/randomdouble.pdf

Anybody doing Monte-Carlo simulations will want the Matsumoto like behavior. I don't really see any other use case for a Float64 function than Monte-Carlo simulations.
If backward compatibility is an issue, a Float53() function would be nice

Any particular reason not to instead use
// Float64 returns, as a float64, a pseudo-random number in [0.0,1.0).
func (r *Rand) Float64() float64 {
    // Change from Go 1 -- make results be uniform.
    return float64(r.Int63()) * 1.0842021724855043e-19
}

Provenance of funny constant: https://play.golang.org/p/FSkOkffu_2
This gets you uniformity, and hits more floating point numbers.
It does however sometimes cause a 1eps deviation from the former value
stream.

look at the comment from stemar94, 0 is underrepresented under this algo. You just can't hit more random points and have a uniform distribution appropriate for simulation.

The value stream argument seems to be winning at this end (i.e., I floated the possibility of an RNG that differed by 1eps in many instances, and that was judged to be not worth the trouble), but I agree that the wrap-back from 1 overrepresents 0, by I think a factor of 1<<9 for Float64 and 1<<38 for Float32 -- I may have a fencepost error in my exponents, the derivation is that the highest two values for Float64 are 1 and 1-1/(1<<53), there are 1024 points between them in the integer random stream, and each point gets half, versus a single point for 1/(1<<63) and 0.  Wrapping 1 to 0 maps 512 points from the integer stream to 0, which is a substantial overrepresentation, and egregiously so for Float32.
To (mostly) preserve the value stream, it appears that the least-awful method is to replace the zero substitution with try-another-number.  It benchmarked the same, though of course this was just a microbenchmark.
I don't understand the claim that zero is overrepresented.  The Mersenne twister RNG will generate 1/(1<<53) and 0 both at p=1/(1<<53), this algorithm generates 1/(1<<63) and 0 both at p=1/(1<<63).  In both cases the probability of zero and its nearest neighbor are the same (and p(0) is lower in this algorithm because all of the points between 0 and 1/(1<<54) get hits, where in Mersenne twister they instead round to zero).

At this point I don't believe we should change the value stream generated by (*Rand).Float64 in any significant way. The split of rand.Source (the source of non-determinism) from rand.Rand (the algorithms on top) means that people expect that only rand.Source might differ from release to release. If people use the same rand.Source output as input to rand.Rand, they expect to get the same outputs. rand.Rand should not itself be a source of non-determinism, not even from release to release, if at all possible.
When the implementation of (*Rand).Float64 returned 1, that was obviously a mistake and in contradiction to the docs, so it merited a breaking change.
The implementation of (*Rand).Float64 is not perfect. My apologies. But I believe it's not awful enough to merit a breaking change.
The if f == 1 { return 0 } fix is also not perfect. Again, my apologies. But even here I'm not convinced it's awful enough at this point to merit a breaking change.
We may be able to loop and grab another value, but I'm not even convinced that's necessary at this point.
More generally, the specified API for (*Rand).Float64 is incomplete. All it says is “Float64 returns, as a float64, a pseudo-random number in [0.0,1.0) from the default Source.” It says nothing about uniformity, which is good, because floating point numbers themselves are not uniformly distributed in [0, 1).
In practice, if you care deeply about the properties of your random floating-point numbers, you should probably write your own wrapper around r.Int63() instead of depending on unspecified details of a library implementation.

Thanks rsc, this makes perfect sense. And this is what I actually ended up doing. The only thing I am left wondering is what are the use cases for this Random.Float64 method?

The change does not really improve uniformity that much. Again, as there are more floating points near zero, the outcome will be skewed towards zero with probability 1/2^11.
The change suggests a confusion in the definition of uniformity. Hitting all floating point numbers with equal probability doe not necessarily mean uniform, because of the over representation of numbers close to zero. So the fix continues the same mistake, just make things on average a bit slower, and will be useless for Quasi random number generators.

@fabienlefloch I disagree. Yes, there are more floating-point numbers near zero, but they are selected less often, so it works out. By "uniform" here we mean that after x = rand.Float64(), as much as possible, x < k with probability k, for all k in [0, 1]. I spent a while calculating Pr(x < k) analytically for the various fixes, and the current implementation seems to me quite close, certainly far closer than one in 2^11. I'd be happy to see an analysis disproving that though.

@rsc Why would they be selected less often near 0?
It is not so easy to find a simple concrete example with a real random number generator however, as most won't lead quickly to integer numbers that translate to float64 < machine epsilon. Worse if you try to compute an average with Monte-Carlo, you will need a decent sample size, so it's likely to take way too much time to test naively.
But if you assume that you have a RNG that gives you 1,2,3,4,5 on one side and 2^63-1,2^63-2,2^63-3,2^63-4,2^63-5 on the other side, you can see that the average number of hits in (0,2^-53] is going to be larger than the number of hits in [1-2^53,1) (actually in this case it's going to fall all in (0,2^-53]).

Here are the graphs I created in November: https://swtch.com/randdist.html.
Make your browser wide enough to see four in each row.
The first row is the original behavior, that could return 1 sometimes. The
Pr(rand.Float64() < 1) in that system was not 1.0: it could return 1
sometimes, and the red line does not get to the top of the rightmost graph.
The second row is the "corrected" behavior, which returns 0 too often. The
Pr(rand.Float64() < 1) in that system is 1.0, but overall Pr(rand.Float64()
< x) was much larger than x for small values of x. You can see this most
clearly in the second graph on the row, where the red line is nowhere near
the blue line. In general quantization means it can't be a perfect match,
but you'd want to see it dipping down to the blue line on occasion, or even
crossing.
The third row is the new resampling behavior, which I argue does not return
0 nor values close to 0 too often. Again there is quantization, but the red
y=Pr(rand.Float64() < x) tracks the blue line y=x quite nicely. To me, the
graphs show that the systematic bias of the first row and the different
systematic bias of the second row are both gone.
Russ

Would this test program perhaps be helpful?  It computes 100 billion random float32s, and bins them by negative-power-of-two-less-than-or-equal (i.e., (1,0.5] ends up in bin 1 ) for bins 1-64.
package main

import (
	"fmt"
	"math/rand"
)

func main() {
	var a [65]uint64
	for i := 0; i < 1024; i++ { // 2**10
		for j := 0; j < 128*1024*1024; j++ { // 2**27
			r := rand.Float32()
			var k int
			for k = 0; r < 1.0 && k < 64; k++ {
				r = r + r
			}
			a[k]++
		}
		fmt.Printf("%d", a[1])
		for k := 2; k < 65; k++ {
			fmt.Printf(", %d", a[k])
		}
		fmt.Println()
	}
}

I ran this for over 100 minutes, the last printed line was:
44090360930,<PHONE_NUMBER>9,<PHONE_NUMBER>9,<PHONE_NUMBER>,<PHONE_NUMBER>,<PHONE_NUMBER>, 688902792, 344456207, 172220997, 86117788, 43060011, 21523345, 10767229, 5378922, 2691381, 1346071, 673490, 336577, 168029, 84082, 42097, 21159, 10498, 5206, 2604, 1265, 645, 336, 200, 85, 42, 25, 14, 4, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
The reason points near zero are selected less often is by construction.  If we start with points uniform on [0,2**63-1], full-precision division by 2**63 preserves uniformity, each with probability P0 = 1/2**63.  If we then round those to a 53-bit mantissa, the probabilities of [0,2**53)/2**63 remain unchanged (=P0); they are exactly representable and there is no rounding.  Consider the mapping of points 2**53+k for smallish k.  For even k the point is exactly representable and the value appears in the FP64 stream, but for odd k the value must be rounded. 1->0, 2=2, 3->4, 4=4, 5->4, 6=6, 7->8, 8=8, 9->8, 10=10 etc.
So on the one hand, I see an interesting glitch in uniformity, in that for k = 2, 6, 10, ...  p(2**53+k) = P0 but for k = 4, 8, 12, ...  p(2**53+k) = 3*P0 because of round-to-nearest-zero-if-tie.  (I modified the program above to test this and it appeared right away.  Similarly, the old unfixed code starts dumping hits into the last bucket right away for rand.Float32).
For larger powers of two, the difference in even and odd probabilities diminishes.  For p(2**54+k) two bits must be dropped and the winners will be k=0,4,8,12,16.  Rounding to the respective values of k:
0: -1, 0,1,2 (-1 = 2**54-1 == 2**53 + 2**53 - 1)
4: 3,4,5
8: 6,7,8,9,10
12: 11,12,13
i.e., instead of 4*P0, alternating between 3*P0 and 5*P0, and for p(2**55+k) , 7 and 9 instead of 8, etc. all the way to p(2**62+k) where the probabilities will be 1023 and 1025*P0 instead of 1024*P0.
Here's a demo of the 1:3 ratio between odds and evens:
package main

import (
	"fmt"
	"math"
	"math/rand"
)

const (
	p53 = float64(1<<53) / (1 << 63)
	p54 = float64(1<<54) / (1 << 63)
)

func main() {
	var even uint64
	var odd uint64

	for j := 0; j < 128*1024*1024; j++ { // 2**27
		r := rand.Float64()
		if p53 < r && r < p54 {
			i := math.Float64bits(r)
			if i&1 == 1 {
				odd++
			} else {
				even++
			}
		}
	}
	fmt.Printf("odd,even=%d,%d\n", odd, even)
}

To your original worry/complaint, notice that in general each time half the points drop out, the probability of the remaining points being chosen increases by a factor of two on average.  In the data above, you'd expect to see a glitch, if any, occurring between bucket 10 and bucket 11, and there is none (I checked).
It's a bit of a shame we can't do this in RTZ FP mode; it would, however change the stream of bits from the RNG and perhaps cause some sadness.

I did not have time yet to produce a simple example to illustrate uniformity.
I don't fully understand why golang wants to reinvent the wheel on this subject, while every single researcher on the topic uses the same techniques to produce random float64 from integers (see Matsumoto, L'Ecuyer, etc.).

The difficulty is that the wheel was reinvented differently, and then there is a strong desire to retain exact compatibility with older releases.  There were clear bugs in the original that had to be fixed, so they were fixed.  If you can demonstrate a bug, that greatly increases the odds that it will be fixed.


spotless insists on corrupting the apache license

Description
When pushing changes to CI spotless runs and tries to rewrite the Apache License (especially it lowercases license from Apache License -- I don't personally care about two spaces after a period...)
Specifically, consider:
https://github.com/apache/logging-log4j2/blob/c173bfe8f0e0446efde4060d6b16c29625e0ca6c/.gitattributes
@@ -1,17 +1,17 @@
 # Licensed to the Apache Software Foundation (ASF) under one or more
-# contributor license agreements.  See the NOTICE file distributed with
+# contributor license agreements. See the NOTICE file distributed with
 # this work for additional information regarding copyright ownership.
-# The ASF licenses this file to You under the Apache License, Version 2.0
+# The ASF licenses this file to You under the Apache license, Version 2.0
 # (the "License"); you may not use this file except in compliance with
-# the License.  You may obtain a copy of the License at
+# the License. You may obtain a copy of the License at
 #
 #      http://www.apache.org/licenses/LICENSE-2.0
 #
 # Unless required by applicable law or agreed to in writing, software
 # distributed under the License is distributed on an "AS IS" BASIS,
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
+# See the license for the specific language governing permissions and
+# limitations under the license.

Configuration
Version: [Log4j version]
Operating system: [OS and version]
ubuntu-latest
JDK: [JDK distribution and version]
Logs
I have ~50 logs from spotless and a bunch of them force these changes. I also have a run where spotless stopped yelling once I applied these changes.
Reproduction
Touch a file that has an apache license and trigger spotless via CI

@jsoref,
That is quite unexpected, since we configured Spotless to only check Java files:
        <configuration>
          <ratchetFrom>HEAD~31</ratchetFrom>
          <java>
            <licenseHeader>
              <file>checkstyle-header.txt</file>
            </licenseHeader>
            <trimTrailingWhitespace />
            <endWithNewline />
            <indent>
              <spaces>true</spaces>
              <spacesPerTab>4</spacesPerTab>
            </indent>
            <importOrder>
              <order>java,org,com,\#</order>
            </importOrder>
          </java>
        </configuration>

The text of the license corrected by Spotless is exactly what checkstyle-header.txt contains. Probably we should double-check that file.

Please ignore that I picked the first file in the commit and focus on the content change itself.

When pushing changes to CI spotless runs and tries to rewrite the Apache License

I addition to feedbacks in https://github.com/apache/logging-log4j2/pull/1320/, I'm looking here. Where can I found some CI job logs/CI job configuration ? (Some/Most unexpected changes do not happen when running spotless through mvn locally.)

Each log can be found attached to a run: https://github.com/check-spelling/logging-log4j2/actions/workflows/build.yml
The configuration can be found wherever it hides.

https://github.com/check-spelling/logging-log4j2/actions/runs/4309638154/jobs/7517255769#step:4:6336
I see an spotless report around src/main/java/org/apache/logging/log4j/flume/appender/FlumeAvroManager.java. it looks legitimate to me.
The build by CI is configured in: https://github.com/apache/logging-log4j2/blob/2.x/.github/workflows/build.yml#L79
However, I still do not underatand :

When pushing changes to CI spotless runs and tries to rewrite the Apache License

Do you have an example of the job (e.g. an URL ?) where the CI does write the header?
About given commit, the committer is yourself @jsoref , not the CI:

https://github.com/apache/logging-log4j2/commits/c173bfe8f0e0446efde4060d6b16c29625e0ca6c/.gitattributes

If the issue is in local, and not the CI: what's your command reproducing this faulty header @jsoref ?

@blacelle  I don't suppose you can join the ASF Slack? There are ~50 runs of spotless, and you could review them all, or you could take my word for the fact that if I hadn't changed the header in java files in the same manner, spotless spotless would have failed and this spotless was clearly forcing me to do so. And if I was picking the wrong spelling in the java files, then spotless would have corrected me. The fact that it isn't complaining about my changes to the java files should be evidence enough that spotless suggested the wrong thing.
I'm a drive-by contributor (currently on a mobile phone) and you're asking me to do extra work. That's not very nice. I gave you more than enough information to collect the information you needed. If you need further assistance, I'm happy to provide it via Slack.

I don't suppose you can join the ASF Slack?

Yes. Any instructions?

There are ~50 runs of spotless, and you could review them all, or you could take my word for the fact that if I hadn't changed the header in java files in the same manner, spotless spotless would have failed and this spotless was clearly forcing me to do so. And if I was picking the wrong spelling in the java files, then spotless would have corrected me. The fact that it isn't complaining about my changes to the java files should be evidence enough that spotless suggested the wrong thing.

I would be happy to review logs of such a case. Or a reproduction scenario.

I'm a drive-by contributor (currently on a mobile phone) and you're asking me to do extra work. That's not very nice.

 I'm not asking you to do anything, out of providing information so that I can help.

I gave you more than enough information to collect the information you needed.

I've not been able to spot a relevant log, or a reproduction scenario.

If you need further assistance, I'm happy to provide it via Slack.

I need assistance to provide assistance (this is my very first comment on this repository...). Let's pursue this in Slack, after you provided me the details to get into it.

https://github.com/check-spelling/logging-log4j2/actions/runs/4300307860/jobs/7496386113
Caused by: org.apache.maven.plugin.MojoExecutionException: The following files had format violations:
    src/test/java/org/apache/logging/log4j/core/time/internal/format/FastDateParserSDFTest.java
        @@ -1,18 +1,18 @@
         /*
         ·*·Licensed·to·the·Apache·Software·Foundation·(ASF)·under·one·or·more
        -·*·contributor·license·agreements.··See·the·NOTICE·file·distributed·with
        +·*·contributor·license·agreements.·See·the·NOTICE·file·distributed·with
         ·*·this·work·for·additional·information·regarding·copyright·ownership.
        -·*·The·ASF·licenses·this·file·to·You·under·the·Apache·License,·Version·2.0
        +·*·The·ASF·licenses·this·file·to·You·under·the·Apache·license,·Version·2.0
         ·*·(the·"License");·you·may·not·use·this·file·except·in·compliance·with
        -·*·the·License.··You·may·obtain·a·copy·of·the·License·at
        +·*·the·License.·You·may·obtain·a·copy·of·the·License·at
         ·*
         ·*······http://www.apache.org/licenses/LICENSE-2.0
         ·*
         ·*·Unless·required·by·applicable·law·or·agreed·to·in·writing,·software
         ·*·distributed·under·the·License·is·distributed·on·an·"AS·IS"·BASIS,
         ·*·WITHOUT·WARRANTIES·OR·CONDITIONS·OF·ANY·KIND,·either·express·or·implied.
        -·*·See·the·License·for·the·specific·language·governing·permissions·and
        -·*·limitations·under·the·License.
        +·*·See·the·license·for·the·specific·language·governing·permissions·and
        +·*·limitations·under·the·license.
         ·*/
         package·org.apache.logging.log4j.core.time.internal.format;

    src/test/java/org/apache/logging/log4j/core/StrictXmlConfigTest.java

This job is for the merge commit of https://github.com/check-spelling/logging-log4j2/pull/3
Given PR has individual commits on many files. Fact is these files are not clean accordingly to spotless, as their licenseHeader is broken.
It is OK in Log4J2 main repo, as these files have not been modified since a long-time. In given job, spotless complains about:

src/test/java/org/apache/logging/log4j/core/appender/routing/RoutingAppenderWithPurgingTest.java

Given file has not been modified since september 2022: https://github.com/apache/logging-log4j2/blob/2.x/log4j-core-test/src/test/java/org/apache/logging/log4j/core/appender/routing/RoutingAppenderWithPurgingTest.java
September 2022 looks pretty recent. Why did Spotless did not clean this file earlier?
Spotless is configured with <ratchetFrom>HEAD~31</ratchetFrom> (https://github.com/apache/logging-log4j2/blob/2.x/pom.xml#L1542) which means a file is cleaned only between HEAD (i.e. current code) and HEAD~31: with Log4j2 configuration, spotless always clean any files which has changed since the latest 32 commits.
We see this parameter was previously different:

https://github.com/apache/logging-log4j2/commit/8c441a3c19b01ee1f43e05732eec8680e6d70e12

Requesting Spotless to process the 32 latest commits is quite recent (November 2022).
Before that :

https://github.com/apache/logging-log4j2/blame/b36a1334806c58e84a33df49167f975d748d103b/pom.xml#L1302

        <!-- Check only files modified since 2022-10-01 -->
        <ratchetFrom>3164c0dac25df0205498c683f9d5ae5ad34015bd</ratchetFrom>

Before that: no Spotless. Hence, files modified before November 2022 are keen to have bad formattings (it is the whole purpose of Spotless). And such files will need to be properly formatted (according to the rules configured into Spotless) by the next committer.
As you modify many file @jsoref, I suspect you are expected to clean the style of each of the files.
I believe this could/should be documented in https://github.com/apache/logging-log4j2/blob/2.x/CONTRIBUTING.md (@ppkarwasz ).

Hope this makes the situation clearer. @jsoref You may drop spotless alltogether in your forks, and re-enable when submitting the PR (after applying mvn spotless:apply, as these broken headers are expected to be fixed by your PR as the first committer since Spotless is activated).

@blacelle  https://infra.apache.org/slack.html it's easiest to just set up an Apache account first if you don't already have one, but if not, we can try to invite you.

@jsoref Please invite benoit.lacelle solven.eu

@jsoref, @blacelle,
We are open to all propositions that improve user experience (CleanThat, Spotless, Github Actions). Can you move this discussion to the<EMAIL_ADDRESS>mailing list (cf. mailing lists).
This is certainly a subject that interest the whole team and the sun never sets on the Log4j Team...

@ppkarwasz: so, @blacelle identified the content which I believe is buggy. It's just:
https://github.com/apache/logging-log4j2/blob/main/checkstyle-header.txt
I'm inclined to copy the content from: https://github.com/apache/superset/blob/e0d976dcca1420162a73dd8e97ebe157af4b1545/setup.py#LL1-L16
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements.  See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership.  The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License.  You may obtain a copy of the License at
#
#   http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
# KIND, either express or implied.  See the License for the
# specific language governing permissions and limitations
# under the License.

into that file and then reenforce this license text across the entire codebase (which would essentially involve undoing any license damage that spotless has been enforcing since it was enabled).
I've picked the file arbitrarily, the same content can be found here:
https://github.com/apache/echarts/blob/baa57b0aecb3a5d81327762cf6eba275cb9c8798/src/echarts.ts#L2-L17
https://github.com/apache/airflow/blob/0d3d0e2e746dd07ab04752800f0cb7f860f6ac46/chart/values.yaml#L1-L16
To pick a couple of items that are in the pinned repositories in https://github.com/apache
Some of the pinned repositories use a different line length, but their content is equivalent:
https://github.com/apache/kafka/blob/27548707dd8f2324d27335edc922ae88d78d86ed/raft/src/main/java/org/apache/kafka/snapshot/FileRawSnapshotReader.java#L2-L15

Apparently the canonical text can be retrieved from https://www.apache.org/legal/src-headers.html#headers (and a quick glance shows it matches what I've quoted).


CMake config script does not export the sol2::sol2 target

Somewhere between the v4.0.0-alpha tag and the tip of the develop branch, the CMake config script have been changed, so the target created for sol2 in the generated sol2-targets.cmake is no longer sol2::sol2, but just sol2. Was this intended?
I think this used to be done by the line below, which is no longer in the CMakeLists.txt
set_target_properties(sol2
	PROPERTIES
	EXPORT_NAME sol2::sol2)

Sorry, duplicate of https://github.com/ThePhD/sol2/issues/1304.


cannot get my php lnd to work

Hello everyone, Am new to LND. Am trying to test out amazing and awesome projects on Lighting Network.
source https://github.com/rstmsn/php-lnd
I have downloaded the project and When I run index.php from my xampp server on windows, am facing this error below
Fatal error: Uncaught Exception: Macaroon not found. in C:\xampp\htdocs\proj3\classes\lnd.class.php:112
Stack trace: #0 C:\xampp\htdocs\proj3\index.php(7): lnd->loadMacaroon('../../admin.mac...') #1 {main}
 thrown in C:\xampp\htdocs\proj3\classes\lnd.class.php on line 112

Please where do I get or generate this missing Macaroon. Again is there some instance that I need to set. Am running xampp
on windows for php
Thanks

@areaboy  You need to ask for help on that repo, it doesn't belong to this Github LND site. But if you are running a LND node on windows, the macaroon files should be in directory C:\Users\username\AppData\Local\Lnd\data\chain\bitcoin\testnet  for testnet. For mainnet just replace testnet with mainnet.

@molxyz Thanks for responding. please where do I download and install this LND node. Any docs helps on that. hoping to hear from you.

@areaboy  You are on LND official repo, and here's the guide how to install lnd:  https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md
There's also LND slack where you can get help faster if you want to join:
https://join.slack.com/t/lightningcommunity/shared_invite/enQtMzQ0OTQyNjE5NjU1LWRiMGNmOTZiNzU0MTVmYzc1ZGFkZTUyNzUwOGJjMjYwNWRkNWQzZWE3MTkwZjdjZGE5ZGNiNGVkMzI2MDU4ZTE

Thanks


Add possibility to disable rounding

Hi,
I'm no expert in color spaces so what I say might have some knowledge gaps.
Would it be possible to add an option to disable rounding when exporting values ?
I'm working on a postcss plugin similar to postcss-color-mod-function and I have to perform multiple color space conversions that make it lose precision on each conversion.
For example
Starting with an RGB color, converting to HWB to increase blackness, then back to a colord object.
I might misunderstand a few features or not get that they exist but I feel that by doing so I'm losing information in between calculations.
As an example : toHwb() could have an optional toHwb(rounded?: boolean = true) argument
I'm ready to contribute that Pull Request if that's something you're interested in.

Hi! Could you please provide some examples of your color modifications?

Hi! Sorry for the delay (the renovation is killing my schedule).
I think I can try adding options: { round: true/false } option to all toRgb, toHsl, toHvs and other methods to make it possible to use libraries inside of other libraries like yours.
Hope it won't affect the library size much.

Hi, no worries, we all have a life outside of open source :D
I have seen that other libraries have a "precision" argument where they can just give a number and the rounding is done using that.
For now I don't need that feature anymore but I think it could still be a useful feature in the future for others

This would be a great addition. We have a color array that has alpha values in 1/16th intervals like:

0.9375
0.6875
0.5625

It's difficult for a new developer to intuitively realize that they're looking at 1/16th intervals because after switching to colord the values look like:

0.938
0.688
0.563

Rather than "rounding" being a boolean, it would be preferable if it was to a specific precision, with a default of 0
toHslString({ precision: 2 })

because for example in the browser, Firefox will convert #0008 to hsla(0, 0%, 0%, 0.53), but the actual alpha value is 0.5333333333333333. In order to reproduce browser-like behavior, we need precision 2.
and extra credit to strip insignificant zeroes by default but provide an option:
toHslString({ precision: 2, keepInsignificantZeroes: true })


Expose ProcessStartKey

Description of the feature, modification, idea or suggestion
System informer should have a column that displays the ProcessStartKey when available. We already have an API for this. And when the driver is enabled it will return the OS-driven start key before the syscall info class was exposed, it will fall back to a synthetic one managed by the driver on very old OSes:
https://github.com/winsiderss/systeminformer/blob/1cadbde537cdbcc56e7b870c5dea58b0cc4aa30f/phlib/native.c#L14789-L14823
A note here, there is also ProcessSequenceNumber but that is already conveyed in the ProcessStartKey. So displaying both is realistically unnecessary.
Proposed implementation details (optional)
Column in the process tree should display the process start key from PhGetProcessStartKey.

Both ProcessSequenceNumber and ProcessStartKey values are also exposed as part of PROCESS_TELEMETRY_ID_INFORMATION which is available as early as Windows 10 1507 (compared to 1803 for the ProcessSequenceNumber info class).

Nice, I'll add this as a fallback.


Todo and fixme cleanup

Most TODOs from the code can either be deleted, done quickly or should reference the corrosponding issue. This PR should leave as few TODOs as possible so that the code quality becomes a little more acceptable

This should reduce the number of TODOs and FIXMEs by a bit, add the issue numbers where applicable and also implement some smaller TODOs.
Just requires some testing before merging the PR


Erroneous Credentials insertion

According to OVIP12, getCredentialsRef should return "the transaction id with which the Credentials were inserted" and "the Keccak256 hash of the credentials".
However, currently the transaction hash is not stored during insertCredentials. For retrieval, the first return value from above is just the encoded version of the second return value.
How is it possible to retrieve the credentials themselves like this?

Smart contracts are implemented correctly - ovip-0012 was not updated correctly => solved by https://github.com/OpenVASP/ovips/commit/7088efa3dfadd4efa95995199ecc6e3283a18fdc

Then how are the credentials actually fetched? Di I have to go through the event logs?


Update to @azure/identity 4.*

Hey @sschwinn-fdot ,
would you mind to update the dependency @azure/identity to 4.*. to get rid of some vulnerabilities? I have tested it localy and it seems not to break anything. Since it is only npm audit fix --force I have not created a pull request.
Best regards,
Andreas

Done.
Note that this upgrade to the @azure/identity package may make it incompatible with projects that use typescript versions lower than 4.5.


Cannot resolve

Error:(34, 13) Failed to resolve: com.github.delight-im:Android-SimpleLocation:v1.0.1

yah i cant get it to work with kotlin either.

Did you modify both build.gradle files, as shown in the README?
You have to add the repository in the root build.gradle. This is important!
I don’t think it’s related to Java vs. Kotlin.

I face the same problem although i've put maven { url "https://jitpack.io" }

yeah in kotlin i got this error too . how plsisss


nk3 test: Add --deny-skipped option

This patch adds an option to the nk3 test subcommand that causes one or more skipped tests to fail the test run.  This can be used in production to make sure that all selected tests are actually executed.
Open questions:

Should --all automatically activate this flag?

Changes

Add --deny-skipped flag to nk3 test.

Checklist

[x] tested with Python3.9
[x] signed commits
[ ] updated documentation (e.g. parameter description, inline doc, docs.nitrokey)
[x] added labels

Test Environment and Execution

OS: Debian 11
device's model: NK3AM
device's firmware version: v1.3.1

Should --all automatically activate this flag?

IMO yes, this is what I expect from it.
Why to introduce --deny-skipped additionally?

--all decides which tests are executed, and --deny-skipped how the results are interpreted.  The reasoning behind the skipped state is that we don’t want to indicate failures to end users that are not really a failure.


Tooltip Menu Shown behind Status Bar / Notch

This might be related to #19954
Steps to Reproduce

Create TextField and put it on the top side of the screen. Wrap it with SafeArea
Type some text then tap and hold it until tooltip menu appear

Expected Result
Tooltip menu appears below TextField, avoiding notch and status bar

Actual Result
Tooltip menu taking space behind notch / status bar, even after I use SafeArea to wrap everything (see first screenshot)

This happened on both iOS and Android
flutter doctor -v Output
(dont mind the license status, it's related to issue where I need to execute sdkmanager update)
$ flutter doctor -v
[✓] Flutter (Channel beta, v1.0.0, on Mac OS X 10.14.1 18B75, locale en-ID)
    • Flutter version 1.0.0 at /Users/iqbal/dev/flutter
    • Framework revision 5391447fae (7 days ago), 2018-11-29 19:41:26 -0800
    • Engine revision 7375a0f414
    • Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

[!] Android toolchain - develop for Android devices (Android SDK 28.0.3)
    • Android SDK at /Users/iqbal/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /Users/iqbal/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    ✗ Android license status unknown.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.1, Build version 10B61
    • ios-deploy 1.9.4
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 31.1.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[✓] VS Code (version 1.29.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.21.1

[✓] Connected device (1 available)
    • iPhone XR • FD82670D-E505-4E7B-834A-DC428D7DE457 • ios • iOS 12.1 (simulator)

! Doctor found issues in 1 category.

Related to #3945

This is a dupe of https://github.com/flutter/flutter/issues/3945. The third comment there mentions that these positions should be avoided.


RequestStream Tests

Based aynchronous and asynchronous requestStream tests.

and fixed Flowables::range to match other ReactiveX implementations. it is {start, count} not {start, end}

Interesting.


Export all BDD functions for "require interface"

From my research in #2997, the "require interface's" exports are still missing:

specify (alias of it)
xspecify (alias of xit)
xdescribe (can use context.suite.skip on the TDD side of the ||)
context (context.context in this code; alias of describe)
xcontext (alias of xdescribe)

It appears that the BDD functions are exported using || to separate BDD and TDD functions they're taken from, basically preferring to take the BDD functions but exporting the TDD functions under BDD names as a fallback, if I've understood the code correctly.
So, each of these should take from the BDD function with the same name; the ones marked "alias of" another should take from the same TDD function as the ones they're aliases of.
These additions don't need tests added unless #2982 is resolved first; if #2982 is resolved first then the added functions should be added to the new/improved test that resolves #2982.

hi. I'm interesting for this issue.
I understand that in lib/mocha.js at line 296~ 309
specific function are omitted and exported function(BDD, TDD) not work as a fallback.
Is that correct?


Keep running when rmlst.fasta is empty

 2019-10-15 11:55:36  Beginning analysis of sample SRR1371311...    2019-10-15 11:55:36  Checking for cross-species contamination...    2019-10-15 11:55:57  Extracting conserved core genes...    2019-10-15 11:56:04  Quality trimming...    2019-10-15 11:56:06  Detecting contamination...  Traceback (most recent call last):   File "/home/bioinfo/miniconda3/envs/confindr/bin/confindr.py", line 11, in <module>     load_entry_point('confindr==0.7.0', 'console_scripts', 'confindr.py')()   File "/home/bioinfo/miniconda3/envs/confindr/lib/python3.6/site-packages/confindr_src/confindr.py", line 1150, in main     confindr(args)   File "/home/bioinfo/miniconda3/envs/confindr/lib/python3.6/site-packages/confindr_src/confindr.py", line 975, in confindr     use_rmlst=args.rmlst)   File "/home/bioinfo/miniconda3/envs/confindr/lib/python3.6/site-packages/confindr_src/confindr.py", line 699, in find_contamination     pysam.faidx(os.path.join(sample_tmp_dir, 'rmlst.fasta'))   File "/home/bioinfo/miniconda3/envs/confindr/lib/python3.6/site-packages/pysam/utils.py", line 75, in __call__     stderr)) pysam.utils.SamtoolsError: 'samtools returned with error 1: stdout=, stderr=[faidx] Could not build fai index /media/30tb_raid10/data/brucella/raw_reads/sra_2019-09-20_confindr/SRR1371311/rmlst.fasta.fai\n'
Is it possible to change the program so it continues to the next sample when the rmlst.fasta file is empty? Also maybe add something about it in the report? Love the tool btw!

I've updated ConFindr to 0.7.3 on bioconda, and I think the new version addresses your issue.


release v0.3.0

release notes -
Warning: updating between minor versions of this plugin will re-provision machines on existing managed cluster. See the Ignition schema output section in the readme for more information

Render Ignition Configs at Ignition 2.2.0
Update ct to v0.8.0
Add snippets field, a list of Container Linux Configs additively appended to the Container Linux Config in content

cc: @dgonyeo @dghubble

github is showing those commits in the wrong order. release v0.3.0 is last in git.

You can get 2.2.0 Ignition configs with the ct v0.8.0 release I made recently, not sure if it's worth bumping to that for this.

Doing a git rebase with the --ignore-date flag should put them in the right order (github is trash at this)

I think it's worth updating, since we have to release a new minor version every time we bump the ignition spec, so we might as well be on the latest when we do I think.

have to update the tests to work with v2.2


Charts in Extensions

Is there any way that we can add charts to our extensions? Control add-ins are not currently supported, is there a plan to add support for that or provide some other means of supporting charts?

Add-in support is on our backlog having a high priority.

Here is the add-in topic more discussion / information :)
#475 #276 #124 #146


RuntimeError,data type

Hi there,
Thanks for your great work, I tried your example,but it occurred:
x1 = (x0 + 1).clamp(max=shape[1]-1)
RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cuda:0 and cpu! (when checking argument for argument max in method wrapper_CUDA_clamp_Tensor)

Same problem


running balance

@yegor256 Thanks for the contribution! You've earned +20 points for this. Please, keep them coming. Your running balance is +160.


Change data capture with Oracle express

Hi, i try to use the google group e-mail but it does not work.
I would like to know if Using DataBus with Oracle Express is possible.

Hi @Maatary, I am closing this issue for now. Please do let us know how your experiments with oracle express went :).


Run error

./gradlew print -PprintArgs="-config $CONF/config.yaml -spec $CONF/pdf_extract.json -output $CONF/out.pdf"
=>
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512M; support was removed in 8.0
Defining custom 'build' task when using the standard Gradle lifecycle plugins has been deprecated and is scheduled to be removed in Gradle 3.0
:core:print
Erreur : impossible de trouver ou charger la classe principale org.mapfish.print.cli.Main
:core:print FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':core:print'.

Process 'command '/usr/lib/jvm/java-8-openjdk-amd64/bin/java'' finished with non-zero exit value 1

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED
Total time: 5.454 secs

Is it that commit who introduce the error?
https://github.com/mapfish/mapfish-print/commit/49149f6676b271214ce56d91c0a124eaf7d67b20#diff-26fb43127aab27a5a6df14164a6f424a


How to change the lock screen wallpaper?

interesting question.. I tried but couldn't find it :/ maybe someone else would have better clue; I guess the image is in system framework, which will be difficult to change

thank you very much.  i have changed the lock screen wallpaper.
copy the framework-res.apk to computer,  then replace the "res/drawable-mdpi-v4/im_digitalpaper_stamp.png" file by winrar.

=.= ok sounds good


RSpec/StubbedMock should offer some rationale

Related issue: #1061
I've experienced the problem described in #1061 (where the implementation changes and there is a dangling stub) but I fail to see the point of the default (currently only) configuration of this cop.
It seems quite opinionated and should provide some example of a problem which it prevents.
Kind of like these cops do:

https://docs.rubocop.org/rubocop/1.27/cops_lint.html#lintconstantdefinitioninblock
https://docs.rubocop.org/rubocop/1.27/cops_lint.html#linteachwithobjectargument

Some cops also link to the ruby style guide, which in turn provides the rationale, but I don't see how this cop corresponds to anything in the style guide.
Many cops are self-explanatory and there may not be any rationale for them other than consistency, but I don't think that applies to this one.

Original ticket. PR that introduced RSpec/StubbedMock.
A notable comment from lead RSpec maintainer on this topic:

Just a personal opinion (which may or may not be shared with my other rspec team members) but this cop should be disabled by default it's very much a personal opinion that creates extra code for people, and rubocop tends to give the impression that something is "recommended best practise" which this isn't.

There is nothing in the RSpec Style guide regarding this, but it's not uncommon:

I could only find 23 cops that enforce style guide guidelines. (out of ~100)

It is common to introduce new cops and enable them in major versions, but with an exception:

Occasionally, some new cops will be introduced as disabled by default. Usually, this means that we believe that the cop is useful, but not for everyone. Typical cases might be the enforcement of programming styles that are not very common in the wild, or cops that yield too many false positives (so you’d run them manually from time to time, instead of running them all the time).

programming styles that are not very common

I can't comment on that as I don't have this information on hand. We can harvest https://github.com/pirj/real-world-rspec to find out.
Off the top of my head, I can think of:
expect(User).to receive(:destroy).and_return(true)
expect(UserCreatorService.create_user).to eq(true)

Changing this to allow in some cases would hinder to detect the mistake (destroy vs create).
Are you up for research to gather legitimate use cases for expect(...).to receive(...).and_..., or otherwise put such spec examples to shame and add a rationale to the cop and a guideline to the style guide?

@odinhb Ping

Sorry, we disabled this cop really quickly, so it's no longer bothering me. :sweat_smile:
We discussed it a bit internally, and my coworker mentioned a rule (although I don't know this rule's rationale) which states there should only be a single expectation per test. Apparently this cop kinda aligns with this rule, as expecting a message to be received in addition to stubbing it to return something means there are multiple expectations. This is recommended by some other test frameworks as well and perhaps most interestingly, the rspec style guide also mentions it:
https://rspec.rubystyle.guide/#expectation-per-example
However, this style guide also says you can have multiple expectations per test if you use aggregate failures.
Personally, this is how I write most of my specs, instead of getting caught up in refactoring the spec setup.
I feel the style guide entry conflicts with this cop being enabled by default. This cop seems to be about keeping a single expectation per spec, because using expect().to receive would mean your test expects multiple things (since you will probably have a regular expectation at the bottom of the example).
I'm not sure what more research there is to do. It looks to me like the pull request you linked contained enough dissenting voices that it should've been disabled by default.
I might check out the real world rspec repo, but I'm not sure what I'll find there or if it'll be of any use, and I think I'll struggle to provide rationale for a cop I disagree with.
I wrote this issue with the hope that someone else could provide some rationale, so I could maybe learn something. As JonRowe said, RuboCop cops leave the impression that something is best practice, but this doesn't seem to be that.

there should only be a single expectation per test

This rule is outdated. For the context:

an updated guideline
PR relaxing the guideline
a comment from Myron, long-time RSpec maintainer

the style guide entry conflicts with this cop being enabled by default

Not really. The cop is more about allowing vs expecting messages with a configured response.
Even if you stick with "one expectation per example" rule, the following code won't trigger RSpec/MultipleExpectations offence:
allow(foo).to receive(:bar).with(42).and_return("hello world") # setup - doesn't count
expect(foo).to receive(:bar).with(42) # make an expectation
subject.exercise # excercise

Though it will if you both make an expectation on both the received message (:bar with 42), and the result returned by e.g. subject.excercise, RSpec/MultipleExpectations will trigger.

enough dissenting voices that it should've been disabled by default

As per RuboCop's practice:

Occasionally, some new cops will be introduced as disabled by default. Usually, this means that we believe that the cop is useful, but not for everyone. Typical cases might be the enforcement of programming styles that are not very common in the wild, or cops that yield too many false positives

❔  the cop is useful, but not for everyone
❌  enforcement of programming styles that are not very common - can't comment on that. I believe we did some analysis of real-world-rspec, but I can't quickly find it
❌  yield too many false positives

RuboCop and RuboCop RSpec provide cops with configurable styles, and every so often those styles are opposite. They are enabled by default. It doesn't mean the default enforced style is the one everyone should use. E.g. RSpec/ExpectChange:
      # @example `EnforcedStyle: block`
      #   # bad
      #   expect { run }.to change(Foo, :bar)
      #
      #   # good
      #   expect { run }.to change { Foo.bar }
      #
      # @example `EnforcedStyle: method_call`
      #   # bad
      #   expect { run }.to change { Foo.bar }
      #
      #   # good
      #   expect { run }.to change(Foo, :bar)

We usually enable cops to make them visible.

RuboCop is extremely flexible and most aspects of its behavior can be tweaked via various configuration options.

It's up to those who use RuboCop and its extensions to configure it to meet their style.
RuboCop is a tool, not an opinionated linter dictating its rigid defaults, even though some cops are tightly linked to style guide guidelines.
Occasionally, we change cops' default enforced styles, but this is a rare case. See one such discussion as an example.

someone else could provide some rationale

We encourage contributions, but typically people scratch their itch, and expecting someone else to fill in the gaps doesn't work.
It would certainly be fantastic if every cop is linked to a style guide guideline, and those guidelines and "independent" cops provided rationales and reasoning. But the amount of work to be done is beyond the current maintainers' capacity to be done in a reasonable time.
If you feel that you are personally interested in contributing a rationale for this cop - you are very welcome. Otherwise, I'm inclined to close the ticket, as this is a more generic problem than just one cop, and it's unlikely that someone would take this over with nearly 100 other open tickets.

We encourage contributions, but typically people scratch their itch, and expecting someone else to fill in the gaps doesn't work.

If you feel that you are personally interested in contributing a rationale for this cop - you are very welcome. Otherwise, I'm inclined to close the ticket, as this is a more generic problem than just one cop, and it's unlikely that someone would take this over with nearly 100 other open tickets.

I don't know what the rationale is. That's why I opened this issue: someone should know why this cop exists. Otherwise it implies that the cop is arbitrary.
I'm not expecting this issue to be solved quickly, and I don't understand the rush.

As per RuboCop's practice: <...snip>

What do the question marks and X'ses mean? I don't entirely follow this section.

It's up to those who use RuboCop and its extensions to configure it to meet their style.

RuboCop is a tool, not an opinionated linter dictating its rigid defaults

It doesn't mean the default enforced style is the one everyone should use. E.g. RSpec/ExpectChange:

I understand wanting to ease the maintenance burden, but good defaults are important. The configurability of RuboCop is great, but the defaults it ships with still imply something. That's the reason I created this issue in the first place: I'd been searching for rationale because this cop was enabled by default, yet it seemed offensively arbitrary to me and I could not find anything other than prescriptive statements.
You quoted someone earlier who was pointing out the exact same thing:

A https://github.com/rubocop/rubocop-rspec/pull/226#issuecomment-256210884 from lead RSpec maintainer on this topic:

Just a personal opinion (which may or may not be shared with my other rspec team members) but this cop should be disabled by default it's very much a personal opinion that creates extra code for people, and rubocop tends to give the impression that something is "recommended best practise" which this isn't.

A quick and cheap solution is to disable this specific cop.
However, fixing the broader issue of every cop not having rationale starts by providing rationale for one cop at a time, so my preference would be to leave this issue here as a discussion, an admission of sorts that this cop has no rationale. If no one knows anything then that implies that the cop is entirely arbitrary.

I don't know what the rationale is

If this cop doesn't fit your project's style - turn it off in your .rubocop.yml.

A quick and cheap solution is to disable this specific cop.

Same as above.

fixing the broader issue of every cop not having rationale starts by providing rationale for one cop at a time, so my preference would be to leave this issue here as a discussion, an admission of sorts that this cop has no rationale

You are welcome to open a broader issue, add a checklist and send PRs. Adding clarity to cops' descriptions and the style guide is very much appreciated. I must confess, I gave up on the idea of restoring references to old discussions for the style guide.

someone should know why this cop exists. Otherwise it implies that the cop is arbitrary

It is arbitrary and disabled if it suggests uncommon practices, or is yields too many false positives.
Do you have evidence of those two?
Please feel free to reopen this ticket if it turns out that there's a noticeable number of expect(...).to receive(...).and_* cases if popular public codebases, or the cop yields many false positives.
I clearly see your point, but it is based on an incorrect assumption that the default configuration is ideal and fits everyone.


Disable UnnecessaryInnerClass for tests

In junit inner classes are a way to structure test contexts.

What do you think about https://github.com/detekt/detekt/pull/4509?

#4509 could be a real fix


Can I use mgc extracted from WORLD?

First of all, thanks for your amazing code.
When I read the paper https://arxiv.org/pdf/1810.11946.pdf, I found it used 60 dim MGC extracted by WOLRD.

Acoustic features, including 60 dimensions of Melgeneralized cepstral coefficients (MGCs) [18] and 1 dimension of F0, were extracted from the 48 kHz waveforms at a frame shift of 5 ms using WORLD [19].

And in the config file project/01-nsf/hn-nsf/config.py, it becomes 80 dim mel spec.
Can I use the feature described in paper?
Thanks in advance.

Hello,
Sorry for the confusion.
Both can be used, as long as they are acoustic features.
And they are compared in this extended study https://arxiv.org/pdf/1904.12088.pdf
I didn't put the MGC of WORLD because it is too troublesome: license, compiling of WORLD and SPTK, script for MGC ...
Mel-spectrogram is simple to implement and requires no additional dependency.
It is good to repository here.
Note that WORLD and SPTK have Python wrappers, https://pypi.org/project/pyworld/, https://pypi.org/project/pysptk/.
Hope the message helps

@TonyWangX many thanks to your kind response.

@TonyWangX I tried to use WORLD feature and it works, thank you.
And when I try to do inference, I found the speed is a little bit slow.
By using CPU, I got:

Start inference (generation):
Generating 0,010662,0,42400,0, time: 3.906s
Generating 1,020517,0,58800,0, time: 5.644s

While when it comes to GPU, the time cost is much faster:

Start inference (generation):
Generating 0,010662,0,42400,0, time: 0.410s
Generating 1,020517,0,58800,0, time: 0.048s

Is this on GPU?
Thanks in advance.

Hello,
Yes, Table 3 is the result on GPU (P100).
CPU is slow, see this notebook https://github.com/nii-yamagishilab/project-NN-Pytorch-scripts/blob/master/tutorials/s3_checkspeed_cpu.ipynb.
FYI:
Table 3 in the paper is obsolete now since our project has been moving on for a while.

Table 3 is the result using the old CUDA-implementation of NSF.
There, the CUDA code used to have two working modes:

memory-save mode: "hard" release and allocation memory for long utterances;
normal mode: no memory release / allocation for short utterances.
Memory-save mode  was necessary for long utterances that require huge amount of GPU memory.
Memory-save mode was slow because of the "hard" GPU memory release / allocation.

For new CUDA-implementation https://github.com/nii-yamagishilab/project-CURRENNT-scripts,
there is only one fast memory mode:

fast memory-save mode: dynamic release and allocation memory
This is fast because we don't need multiple times of GPU memory allocation / release.

For Pytorch implementation, the Pytorch code automatically manages the GPU memory,
and I didn't do further tuning on the generation speed.

@TonyWangX Thanks. Now I finished all iterations and the abs result is really amazing.


Updated StateClassWrapper with fixes, a little rough in places but currently working.

@DevronB was this ready to merge? I can't remember where we left it.

I think it's good enough to merge as a potential fallback/dirty checking concept.


New Feature: More robust support for adding collections of recipients

Currently the EmailBuilder does not support adding a list of recipients either as collection of Recipient or as comma/semicolon separated list of address.
Also the from and replyTo builder methods should support whole Recipient objects instead of just name and email address.

Added API:
Email email = new EmailBuilder()
   .to("10@candyshop.org;11<EMAIL_ADDRESS>   .cc("10@candyshop.org;11<EMAIL_ADDRESS>   .bcc("10@candyshop.org;11<EMAIL_ADDRESS>   .build();

One or more addresses without names allowed separated by comma or semicolon. Similar addition for 1 from and replyTo (but for single only addresses).

Released in v4.2.0.


Use new Rig v0.11.0 API functions.

This commit migrates to the new place-and-route wrapper introduced in Rig
v0.11.0 which automatically reserves non-idle cores allowing easier use of
profiling tools.
Unfortunately I don't know how to run the live-hardware tests (and don't have a board to hand anyway) so these changes merely pass the basic test suite and seem to make sense to me. Sorry!

Cheers, I'll have a look tomorrow.

Thank you!


ROX-14975: Move baseline definition up earlier in process

Description
FFF test
A detailed explanation of the changes in your PR.
Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

/retest

Abandoning this PR, as we have to address an underlying issue in our Codebase that likely resolves this.


I am getting "Access not allowed..." error with UploadFile()

When i am trying to upload a file, i am getting "Access not allowed. USERNAME tried to violate upload privileges" error. I can't get through this :/. I can upload file via FileZilla with same credentials.
I am getting exception at UploadFile method. Can you help me?
My code is;
            FtpClient client = new FtpClient("_ServerAdress_");
            client.Credentials = new NetworkCredential("UserName", "Password");
            client.Connect();
            client.UploadFile(@"C:\Users\anil.ekmekci\Desktop\9_0_25_Test\DBUPDATE\CMas1.M80", "/9_0_25_Test/DBUPDATE/CMas1.M80");
            client.Disconnect();

Please paste the full logs from FluentFTP and from Filezilla so we can compare.

Hi,
I can solve the problem with comparing FluentFTP and FileZilla logs.
I set the same parameters with the FileZilla sets and it worked.
Thank you for the hint :).


No need to check for type in RDF::URI()

Coverage increased (+0.04%) to 90.954% when pulling 18e8d4a7b3e086b0b075e9bd0a0b1aa7fd2758ba on jcoyne:no_type_check into 5aa80826bd77262535e31c113b2a3add50c14ace on ruby-rdf:develop.

Coverage increased (+0.04%) to 90.954% when pulling 18e8d4a7b3e086b0b075e9bd0a0b1aa7fd2758ba on jcoyne:no_type_check into 5aa80826bd77262535e31c113b2a3add50c14ace on ruby-rdf:develop.

Coverage increased (+0.04%) to 90.954% when pulling 18e8d4a7b3e086b0b075e9bd0a0b1aa7fd2758ba on jcoyne:no_type_check into 5aa80826bd77262535e31c113b2a3add50c14ace on ruby-rdf:develop.

Looks good. RDF::URI#to_uri just returns self anyhow.