Add starting and ending separators for check_args success output

Description
This PR adds starting and ending separators to the CLI tool's output when it finds matching arguments.

Motivation and Context
This issue: #4.

How Has This Been Tested?
Tested by running cargo run for a few command-line tools: nvim, bat, zoxide, whoami.

Screenshots / Logs (if applicable)

Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (no code change)
[ ] Refactor (refactoring production code)
[ ] Other

Checklist:

[x] My code follows the code style of this project.
[ ] I have updated the documentation accordingly.
[x] I have formatted the code with rustfmt.
[x] I checked the lints with clippy.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.07 :tada:

Comparison is base (b6e64fc) 79.90% compared to head (8a0e397) 79.97%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #27      +/-   ##
==========================================
+ Coverage   79.90%   79.97%   +0.07%
==========================================
  Files          14       14
  Lines         577      579       +2
==========================================
+ Hits          461      463       +2
  Misses        116      116

Impacted Files
Coverage Δ

src/helper/args/mod.rs
98.81% <100.00%> (+0.01%)
:arrow_up:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

bors r+


allow_any_instance_of().to receive(:<method_name?>) failure

Env
 ~/git/repo/ [master] bundle exec rspec --version
RSpec 3.9
  - rspec-core 3.9.1
  - rspec-expectations 3.9.1
  - rspec-mocks 3.9.1
  - rspec-rails 3.9.1
  - rspec-support 3.9.2
 ~/git/repo [master] bundle exec ruby --version
ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-darwin21]

Error
Failures:
  1) Users Managing users POST <some_endpoint> create a user with valid params
     Failure/Error:
       allow_any_instance_of(::RBAC::Client).to receive(:build_http_client)

       RBAC::Client does not implement #build_http_client
     # /usr/local/bundle/gems/buildkite-test_collector-1.1.1/lib/buildkite/test_collector/library_hooks/rspec.rb:25:in `block (2 levels) in <top (required)>'

This looks related to https://github.com/buildkite/test-collector-ruby/issues/123 but we are already stubbing the class.
I would appreciate any help. TIA.

Nvm. Code issue. Fixed.


docs(material/form-field): prefill text prefix/suffix example for better alignment

https://github.com/angular/components/issues/21846
Note: MDC form field should hide text prefix/suffix when label is floating

The MDC form-field actually split the prefix into 2 different selectors: matIconPrefix and matTextPrefix, since coming up with a single method of styling that felt natural for both proved impossible. I don't think we need to back-port that change though, you can can add .demo-* classes to tweak the styling as needed.

Updated change to add a value instead.


Convolution inside drift and diffusion term

Hi,
I am re-implementing Neural SDE paper.
When I tried using Neural SDE with bunch of linear layers, every thing seem to be good, the train accuracy about 0.92 on valid set.
After that, I tried with convolution layers. First of all, I realize that f and g take (B,N) shape of input. So in the forward step of my network, I used torch.view method as a way to reshape flattened input into the square image. And continue feed the data through bunch of Convolution layer, and as final step, one more time, I use the torch.view method to reshape in to (B,N) shape. (Take a look below).
class ConvolutionDrift(nn.Module):
    def __init__(self, in_channel, size=32, device="cpu"):
        super(ConvolutionDrift,self).__init__()
        self.size=size
        self.in_channel=in_channel
        self.conv1 = ConcatConv2d(in_channel, 64,ksize=3,padding=1)
        self.norm1 = Norm(64)
        self.relu = nn.ReLU(inplace=True)
        self.conv2 = ConcatConv2d(64, 64, ksize=3,padding=1)
        self.norm2 = Norm(in_channel)

    def forward(self,t,x):
        bs = x.shape[0]
        out = x.view(bs, self.in_channel, self.size, self.size)
#        print(f"{out.shape}\n\n\n\n")
        out = self.conv1(t,out)
        out = self.norm1(out)
        out = self.relu(out)
        out = self.conv2(t,out)
        out = self.norm2(out)
        out = self.relu(out)
        out = out.view(bs,-1)
        return out
class ConvolutionDiffusion(nn.Module):
    def __init__(self, in_channel, size=32, brownian_size = 2, device="cpu"):
        super(ConvolutionDiffusion,self).__init__()
        self.size=size
        self.in_channel=in_channel
#        self.net = nn.Sequential(*[
#            nn.Conv2d(in_channel, 64,3,padding=1),
#            nn.GroupNorm(32,64),
#            nn.ReLU(),
#            nn.Conv2d(64, 64,3,padding=1),
#            nn.GroupNorm(32,64),
#            nn.ReLU(),
#            nn.Conv2d(64,in_channel * 2,3,padding=1),
#            nn.ReLU(),
#
#        ]).to(device)
        self.relu = nn.ReLU()
        self.norm1 = Norm(64)
        self.conv1 = ConcatConv2d(in_channel, 64, ksize=3, padding = 1)
        self.conv2 = ConcatConv2d(64,64, ksize=3, padding = 1)
        self.norm2 = Norm(64)
        self.conv3 = ConcatConv2d(64, in_channel * brownian_size, ksize = 3, padding = 1)
        self.norm3 = Norm(in_channel * brownian_size)
    def forward(self,t,x):
        bs = x.shape[0]
        out = x.view(bs, self.in_channel, self.size, self.size)
        # out = self.net(out)
        out = self.conv1(t,out)
        out = self.norm1(out)
        out = self.relu(out)
        out = self.conv2(t,out)
        out = self.norm2(out)
        out = self.relu(out)
        out = self.conv3(t,out)
        out = self.norm3(out)
        out = self.relu(out)
        out = out.view(bs,-1)
        return out

class SDEBlock(nn.Module):
    noise_type="general"
    sde_type="ito"
    def __init__(self, state_size, brownian_size, batch_size, option = dict(), device="cpu", parallel=False,
        method="euler", noise_type="general", integral_type="ito", is_ode=False, input_conv_channel = 64,input_conv_size=6, layers="linear"):
        super(SDEBlock, self).__init__()
        self.noise_type=noise_type
        self.sde_type=integral_type
        self.state_size = state_size
        self.batch_size = batch_size
        self.brownian_size = brownian_size
        self.parallel = parallel
        self.device = device
        self.is_ode = is_ode
        if parallel:
            self.batch_size = int(self.batch_size / 2)

        if layers=="linear":
            self.drift = LinearDrift(state_size, state_size).to(device)
            self.diffusion = LinearDiffusion(state_size, state_size * brownian_size).to(device)

        elif layers=="conv":
            self.drift = ConvolutionDrift(input_conv_channel, input_conv_size).to(device)
            self.diffusion = ConvolutionDiffusion(input_conv_channel, input_conv_size, brownian_size = self.brownian_size).to(device)

    def f(self,t,x):
        out = self.drift(t,x)
        return out
        #return self.f(x)
    def g(self,t,x):
        bs = x.shape[0]
        if self.is_ode:
            out =  torch.zeros_like((self.batch_size,self.state_size, self.brownian_size)).to(self.device)
            return out
        out = self.diffusion(t,x)

        out =  out.view(bs, self.state_size, self.brownian_size)
        return out

"""
SDEBlock: LinearDrift dx + LinearDiffusion dW
SDENet: fe -> SDEBlock -> fcc
"""

class SDENet(Model):
    def __init__(self, input_channel, input_size, state_size, brownian_size, batch_size, option = dict(), method="euler",
        noise_type="general", integral_type="ito", device = "cpu", is_ode=False,parallel = False):
        """"""""""""""""""""""""
        super(SDENet, self).__init__()
        self.batch_size = batch_size
        self.parallel = parallel
        self.input_size = input_size
        self.option = option
        self.input_channel = input_channel
        #state_size = 64 * 14 * 14
        self.device = device
        self.fe = nn.Sequential(*[
            nn.Conv2d(input_channel,16,3,padding=1),
            nn.GroupNorm(8,16),
            nn.ReLU(),
            nn.Conv2d(16,32,4,padding=2),
            nn.GroupNorm(16,32),
            nn.ReLU(),
            nn.Conv2d(32,64,3,2),
            nn.GroupNorm(32,64),
            nn.ReLU(),

        ]).to(device)
        state_size, input_conv_channel, input_conv_size = self.get_state_size()
        self.input_conv_channel = input_conv_channel
        self.input_conv_size = input_conv_size

#        print(state_size, input_conv_channel, input_conv_size, "ehehehehehe\n\n\n\n")
#        print(f"Init features extraction layer with device {self.device}")
        # Output shape from (B,3,32,32) -> (B,64,14,14)
        if parallel:
            self.batch_size = int(self.batch_size /  2)
        self.rm = SDEBlock(
                state_size=state_size,
                brownian_size = brownian_size,
                batch_size = batch_size,
                option=option,
                method=method,
                integral_type=integral_type,
                noise_type=noise_type,
                device=device,
                parallel=parallel,
                is_ode=is_ode,
                input_conv_channel=input_conv_channel,
                input_conv_size=input_conv_size,
                layers="conv"
            ).to(device)

        self.fcc = nn.Sequential(*[
            nn.AdaptiveAvgPool2d(1),
            nn.Flatten(),
            nn.Linear(input_conv_channel,10),
            nn.Softmax(dim = 1)
        ]).to(device)

        self.intergrated_time = torch.Tensor([0.0,1.0]).to(device)
        self.device = device
        self.method = method
    def get_state_size(self):
        out = torch.rand((1,self.input_channel,self.input_size, self.input_size)).to(self.device)
        shape = self.fe(out)
        return shape.view(1,-1).shape[-1], shape.shape[1], shape.shape[2]
    def forward(self,x):
        out = self.fe(x)
        bs = x.shape[0]
#        print(f"Shape after Feature Extraction Layer: {out.shape}")
        out = out.view(bs,-1)
#        print(f"After the feature extraction step, shape is: {out.shape}")
#        print(f"Device of out {out.device}")
#        print(f"Shape before the SDE Intergral: {out.shape}")
        out = sdeint(self.rm,out,self.intergrated_time, options=self.option,method="euler", atol=5e-2,rtol=5e-2, dt=0.1, dt_min=0.05,adaptive=True)[-1]
        out = out.view(bs,self.input_conv_channel, self.input_conv_size, self.input_conv_size)
        out = self.fcc(out)
        return out

The code run with no any mistake. But there is a thing that the results is not so good. It usually converges at second / thrid epoch.
And accuracy with convolution layers is not good at all.
So my question here is: "Will the convolution layer is available in torchsde by someway or the loss.backward() does not update ConcatConv2ds' parameters?"

I'm afraid that's far too large an example for us to help you debug. Moreover it's not clear that this is actually an issue to do with torchsde at all (indeed you mention that using linear layers seems to work correctly).
Your basic approach of reshaping from (batch, channels * height * width) to (batch, channels, height, width), and back again, sounds essentially correct, however.

Thanks Ms @patrick-kidger, whenever I raise a issue and got your answers, I find out what happen in my work.
I have done more Experiments, and the issue cause by the Adaptive Average Pooling, I dont really know why.


Updates to init and poll()

Closes #5
Added pwcacheexpire to init to allow adjustment of the cache time
Added timeout to init to allow adjustment of the http timeout
added force to pol() to bypass the cache regardless of the timeout
moved the check for the vitals to after the cache check (minor optimization)

Let me know if I got this right...

Thank you @wcwong !!  Great job!


NTR: Repression of monocyte activation

@milarolo I have moved this ticket here to the go-ontology tracker, as @pgaudet advised, and closed the issue in the go-annotation tracker (https://github.com/geneontology/go-annotation/issues/2321).

cc @RLovering

Hi @milarolo
If you agree, I will add 'negative regulation of monocyte activation' as the primary GO term, because it will be an 'is_a' child of 'negative regulation of leukocyte activation' (screenshot below), so this will allow to keep the naming conventions consistent. I will add 'repression of monocyte activation' as an exact synonym, if this was the term used in the referenced paper.
Is this ok?
And could you please let me know what dbxrefs to add? It will be GOC:aruk for the project, and should I add any others?
Thanks,
Barbara
cc @RLovering

Hi Barbara,
About the new term that I requested "repression of monocyte activation":
I agree with you that "negative regulation of monocyte activation" is better to keep  the naming conventions consistent.
I agree adding "repression of monocyte activation" as an exact synonym of the new term created.
About the dbxref, GOC:aruk would be fine. I don't think you need to add others.
I just have a question about making it a child of "negative regulation of leukocyte activation". I thought it would be better to make it a child of "monocyte activation". Is there a specific reason why you chose that term for the parent?
Thank you for taking care of this,

Hi Mila,
Thanks for your comments and questions.
You are correct about making "monocyte activation" a parent of "negative regulation of monocyte activation". It will indeed become an additional parent on this new term, connected to it using the ontology relation 'negatively_regulates'.
Whereas "negative regulation of leukocyte activation" will be the 'is_a' parent of "negative regulation of monocyte activation". Every term in the ontology needs to have an 'is_a' parent, or else things break, which is why I only mentioned this parent. The parents related to the new term using the '(positively/negatively)_regulates' relationships will be inferred automatically via logical definitions. I hope this answers your question. Please let me know, if you have any other questions.
Thanks,
Barbara

Thank you for your clarification Barbara
Mila


Traits

Very late to the party on this—like, slightly late—but I'm wondering how Flow can support this style of composition.
Right now, Flow supports HOCs, but that's not always what is needed.
https://flowtype.org/docs/react.html#higher-order-components
What do you think?

Looking back through the history of programming, it seems clear that most people can agree an single inheritance.  But if there had been a clear winner among the myriad approaches to multiple inheritance I think it would have become common by now.

Take this for example: composing React props.
https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgBCArhhnAHYAKATnDgM5gC8YA3qmGJQMIwCWAYwDWALjAAKAJQsAfGABucfgBMANJzDZ84gOQAjUuQq6wAHzC6aeBngymLuhsX0BbfvY1cVN-gHMKPRwaflcAQxosB0tbQUoVCKjzSxwwvzxo3XI4GAx+HABJCig4TOzc-IAROEEGXS9uCgAxGuIGcWk5RWV1TUpXODa8OAU8Gg6ZZnklVQb+wdtBjAmumd6uQRgwhgYAOTDXPFEGDBCKPwbBAAt+GBVrQLAAQRoaMKwAHgAJABUAWQAMgBRGB4Q4UDCyDQAX3Q2gIBTi1DojBY7E0fhguCux1O-HOly2O32hwA-OITmcLpo8hh
Attempting to merge Flow types to use as propTypes throws this error: "Property cannot be accessed on any member of intersection type". https://cloudup.com/cICohVjFUqa

Also @jedwards1211, shelve the condescending tone. Not helpful.

What version of flow are you using?  I've seen those errors on intersection types less as I've upgraded to newer versions of flow.

Sorry my comment sounded condescending, what I should say is, given that React mixins are deprecated, and the decorator proposal is in enough flux that we have babel-plugin-transform-decorators-legacy, I see a lot of churn in this area, so I think Flow shouldn't support any solution to this problem unless it becomes widely adopted.

No worries. Here's what I'm attempting to do, which I realize may be fools' gold:

satisfy both React PropTypes and Flow types
reuse and merge props

https://gist.github.com/kevinSuttle/fb3d4b33c83e091e7f980dda9ff8df8e

The prop intersection with & should work although there have been issues with it in the past.  I think I sometimes still see legitimate errors that confusingly seem to come from the intersection failing to work, but it's hard to remember.  I take it you were interested in using Traits to work around the flow type errors?
Merging propTypes can be done with the dot spread operator.
On the other hand you might be able to use babel-plugin-tcomb instead of propTypes to get runtime checking of your flow types.

These Flow issues came after the fact because declarative composition isn't documented right now, but there are plenty of blog posts/docs that are anti-Class, anti-inheritance, anti-createClass, and anti-mixin. I personally feel that HOCs are convoluted and unnecessarily complex. It just comes off dogmatic at the cost of real-world use cases.
Even the intersection type example from the Flow docs feels confusing. This doesn't feel like how people normally write code.
What's attractive about traits is that you get:

composition
conflict resolution
declarative, human-readable syntax
data privacy
immutability

I agree about the intersection type example, there should be more examples than just an intersection of functions.
I can understand the appeal of traits, but I'm not convinced they're better than object composition.  Maybe there are better examples, but I would just use object composition for what the examples in that link are trying to do with traits:
class Position {
  constructor(self) {
    this.self = self
  }
  x = 0;
  y = 0;
  print() {
    console.log(`${this.self} is calmly resting at (${this.x}, ${this.y})`);
  }
}
class Move {
  constructor(self, position) {
    this.self = self
    this.position = position
  }
  to(x,y){
      console.log(`${this.self} moves from (${this.position.x}, ${this.position.y}) to (${x}, ${y})`);
      this.position.x = x;
      this.position.y = y;
  }
}

class MovingMinion {
  position = new Position(this)
  move = new Move(this, this.position)
  toString() {
    return 'moving minion'
  }
}

var movingMinion = MovingMinion();
movingMinion.position.print();
// => moving minion is calmly resting at (0, 0)
movingMinion.move.to(2,2);
// => moving minion moves from (0, 0) to (2, 2)
movingMinion.position.print();
// => moving minion is calmly resting at (2, 2)

Down farther in the article things get more complicated with Trait.resolve because name conflicts are an inherent problem with all of these approaches to multiple inheritance.  And I think there will always be weird cases that Traits can't support because of name conflicts that object composition can handle just fine.  For instance what if you also wanted to have a targetPosition on a minion?  As far as I can tell from cursory reading you couldn't put two Position traits on an object because they would both try to use this.x and this.y.  But with object composition it's easy:
class MovingMinion {
  position = new Position(this)
  targetPosition = new Position(this)
  move = new Move(this, this.position)
  moveToTarget = new MoveToTarget(this, this.position, this.targetPosition)
  toString() {
    return 'moving minion'
  }
}

It's much more explicit how the composed behaviors are hooked up this way than when using Traits.

Thanks for the thorough explanation.
Here's what I find odd about the intersect type.
This: no errors
https://flowtype.org/try/#0PTAEAEDMBsHsHcBQiCWBbADrATgF1AEoCmAhgMb6TaxqgDk2pFdA3MkQB5Z6i4CeGIqABCAV1y5YAOwAK1DAGdQAXlABvRKFDSAwtBRkA1gC5QACgCUKgHygAbrBQATADSbeAoqboAjcZKk6UAAfekYFIlwg0LoFUR80FCi3LSciBRQAcylvDGx0Emw+aPoIsmknQuKQ+gwSTKISuklYaFwUDABJKUhYJpa2joARWDIFOhTtKQAxUdEFU0sbe0dXd2k0WHmiWDsibEWrZVsHZ0mNrYit3EPl07WtMmgSBQUAORI0LwVcfKlMyZkAAWKGgTkYOVAAEFsNgSHwADwACQAKgBZAAyAFFoEQvlJcNY3ABfdhcHD4J4vJRiCTSUCcXBEKROJTEci4AB0OhoWCkzPwGncPxI7TIoDSkBIojaclgihU6ncWn4gm8fjpgUmqXSWUhdDyBSKE2VoCprw+X3VuC17lJ7nKUh+2FEFBwZjy8oWtICcsUFg0Wi0cUE2A98gUFjYWntWghaTDAdNjFwomwUnMpq0CI1ASzQfN70+RGUagA2gADAAkalwIIUnM9ik5aQy2WJoBrdZQDabDcLlqIxIrAF1SUGJ1M9AZDKXu72I5zdPojOPJ9Z81pa-XG4vgaDwcy1xOEcBc9INxOLHbEPbVUIMSQfERoH6lKpA6Bns-oMZnSh-hJZB71AR8fx9aQ30VCDZAjUAADJQKfF83zYRBOG4SlpB+JDwP8elVHDL1jDAl8YLfI5L1ABEYIlXVslLPsW3oqQO2XGdGMXdjVyo7Nvxfaw1CY-joGJU8RKo08YI3RAgA
This: errors all over the place
https://flowtype.org/try/#0PTAEAEDMBsHsHcBQiCWBbADrATgF1AEoCmAhgMb6TaxqgDk2pFdA3MkQB5Z6i4CeGIqABCAV1y5YAOwAK1DAGdQAXlABvRKFDSAwtBRkA1gC5QACgCUKgHygAbrBQATADSbeAoqboAjcZKk6UAAfekYFIlwg0LoFUR80FCi3LSciBRQAcylvDGx0Emw+aPoIsmknQuKQ+gwSTKISuklYaFwUDABJKUhYJpa2joARWDIFOhTtKQAxUdEFU0sbe0dXd2k0WHmiWDsibEWrZVsHZ0mNrYit3EPl07WtMmgSBQUAORI0LwVcfKlMyZkAAWKGgTkYOVAAEFsNgSHwADwACQAKgBZAAyAFFoEQvlJcNY3ABfdhcHD4J4vJRiCTSUCcXBEKROJTEci4AB0OhoWCkzPwGncPxI7TIoDSkBIojaclgihU6ncWn4gm8fjpgUmqXSWUhdDyBSKE2VoCprw+X3VuC17lJ7nKUh+2FEFBwZjy8oWtICcsUFg0Wi0cUE2A98gUFjYWntWghaTDAdNjFwomwUnMpq0CI1ASzQfN70+RGUagA2gADAAkalwIIUnM9ik5aQy2WJoBrdZQDabDcLlqIxIrAF1SUGJ1M9AZDKXu72I5zdPojOPJ9Z81pa-XG4vgaDwcy1xOEcBc9INxOLHbEPbVUIMSQfERoH6lKpA6Bns-oMZnSh-hJZB71AR8fx9aQ30VCDZAjUAADJQKfF83zYRBOG4SlpB+JDwP8elVHDL1jDAl8YLfI5L1ABEYIlXVslLPsW3oqQO2XGdGMXdjVyo7Nvxfaw1CY-joGJU8RKo08YI3RB2QoTl432MwEVI6BaOAIkJTmfEuQaXAcTxAVhD4TonDMOg0BIAC6Csa8gA

I think the REPL on Try Flow differs from the cli executable as well, especially with regards to importing and exporting types from various files.
I should note that locally I have a Button and Icon class, but the rest are pure functional components.  Maybe that's the discrepancy?

It's because you need to declare the required properties e.g. <LabelButton label="..." .../>

Are you coming from TypeScript?  TypeScript only added non-nullable properties recently, before that it had no concept of required properties as far as I know

basically "Property not found in" means "required property missing from" in those errors

You'll get the same errors if you do var buttonProps: ButtonProps = {} or try to render <Button /> after annotating it with class Button extends React.Component<void,ButtonProps,void>

No, I haven't used TypeScript. More from classical statically-typed OOP languages (non-functional).
I feel like I'm missing something foundational.

The errors are saying you need to pass in the required props you've declared (the ones without ? before the colon) to the JSX element.  Does that make sense?

I think so.
I've refactored a bit and gotten the errors down, but I'm still not quite sure what it's looking for.
https://flowtype.org/try/#0PTAEAEDMBsHsHcBQiCWBbADrATgF1AEoCmAhgMb6TaxqgDk2pFdA3MrgJ4ZGgBCArrlywAdgAVqGAM6gAvKADeiUKE7cAXPQBGg4SLqgAPvUZSiuA8bpT+WtCgsAaZaAAmRKSgDmIzXQzY6CTYHJb0ZmSirsGhRvQYJF5EYXTCsNC4KBgAkiKQsClpGVkAIrBkUnTOKmTQJFJSAHIkaETqUriBIl7VoKIAYuX8UgD8mgAUAJRyAHygAG6wKK69omiww0Sw80TYY6BTswtLKy5rG2YbuPuHsnOLy6siAMLQKGQA1jfTd8ePLmQABYoaCuRgifYjACC2GwJA4AB4ABIAFQAsgAZACi0CIrREuBmzgAvuwuDwMSQtERoBJYNI5IoXHVqdB2p0UN0ScgiAAPLB4UCREQdPi6USM8YKdyeHyyfyBNAxKpCuoNZqteVaXD6Ryqcla8X6YmgTQCISiOkMn4zFwInQWkQuGpqpotIiyBQAbQABgASaUebwiE0B2r1N2tYk+gC6pJUKltKgRwAdeltZO4oEprPNeitMnkectkhkADJs1SaQW2Ig+QL8MLRTmacWRJKAvSpOoW9A2wWbXa224g3KFJ3pAA6GXBk2iV7vD6eidSSfzt6fYlJhMIlk0mbj0uTvfQYkpk-blNtjNAA

I think this is what's throwing me off.
Optional vs absent vs non-nullable
<EMAIL_ADDRESS>https://flowtype.org/try/#0PTAEAEDMBsHsHcBQiCWBbADrATgF1AEoCmAhgMb6TaxqgDk2pFdA3MrgJ4ZGgBCArrlywAdgAVqGAM6gAvKADeiUKE7cAXPQBGg4SLqgAPvUZSiuA8bpT+WtCgsAaZaAAmRKSgDmIzXQzY6CTYHJb0ZmSirsGhRvQYJF5EYXTCsNC4KBgAkiKQsClpGVkAIrBkUnTOKmTQJFJSAHIkaETqUriBIl7VoKIAYuX8UgD8mgAUAJRyAHygAG6wKK69omiww0Sw80TYY6BTswtLKy5rG2YbuPuHsnOLy6siAMLQKGQA1jfTd8ePLmQABYoaCuRgifYAQWw2BIHAAPAAJAAqAFkADIAUWgRFaIlwM2cAF92FweOiSFoiNAJLBpHJFC46lToO1OihusTkEQAB5YPCgSIiDp8XSiBnjBTuTw+WT+QJoGJVQV1BrNVpyrS4fSOVRkzVi-RE0CaARCUS0+k-GYueE6c0iFw1VVNFpEWQKADaAAMACRSjzeETG-21equ1pE70AXRJKhUNpU8OA9r0NtJ3FAFJZZr0lpk8lzFskMgAZFnKdT82xELz+fghSLs9SiyIJQE6VJ1M3oK389bba23IHZQoO9IAHTSoPG0Svd4fD3jqQTudvT7GsNqt2yABEWpEu713D3qdEu8T8fhzOpMzHJYnN+gROTT8vydb6aAA

@kevinSuttle Ah, I got bit by this one too, unfortunately Flow doesn't support default values in destructuring right now: https://github.com/facebook/flow/issues/183
So even though for instance you have className='btn' Flow doesn't realize a default is being assigned

And yeah optional vs absent vs non-nullable took me a little while to wrap my head around too

In any case, regardless of whether you use traits for something else, I don't think you'd need them to fix these Flow errors

Re: #183: https://flowtype.org/docs/react.html#stateless-functional-components I guess it's a very subtle difference?
And add in Maybe types, and then I'm super confused.
But to your point, yes, these errors don't appear solvable by traits.

Ah, so in their example for default props in stateless functional components they use a maybe prop in the type signature for the defaulted prop.  Which I think unfortunately means Flow doesn't know it's guaranteed to be defined.  This is different than when using Component classes, where you can explicitly declare props with defaults as non-maybe but Flow will not complain if you omit them thanks to internal magic.

Hm. Ok. Thanks for the detailed responses. Appreciated @jedwards1211.

No problem, I went through a lot of the same frustration when I was getting started with flow!


Ensure bug-id and bug type provided when raising bugs

When raising a bug (known-bugs) both bug-id: and a bug
type: must be provided. A ScenarioException will now be
raised if this is not the case.
Resolves: #395

LGTM, thanks Ed

LGTM, thanks Ed


Stop globbing of quoted arguments to native commands

Fix globbing so that quoted args are not expanded.
Also Fix some minor issues with exceptions being raised when resolving
the path - falling back to no glob.
The bulk of the change is in the first commit, which passes the Ast or null instead of the IScriptExtent when constructing the parameters and arguments that are used by the parameter binder.
Fix #3931,#4971

Must ... have ... this ... fix.  :-)

@lzybkr I was out in training last Friday. Will get this done today.

🎉


[AMBARI-25271] : Prepare Rolling Upgrade Test changes

What changes were proposed in this pull request?
Updating test method signature for Prepare Rolling Upgrade in test_namenode since 2 methods share same signature
How was this patch tested?
The patch was tested with Unit Testing
Backporting to branch-2.6: https://github.com/apache/ambari/pull/2964

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/5190/
Test FAILed.
Test FAILured.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/5193/
Test PASSed.


Initial release

Basic setup implementation

[x] add test CI (#3)
[x] rewrite using program:exit (#2)
[x] implement replace for all function using react adding React. prefix inside style rule (#5)
[x] handle scenario with multiple imports and one satisfies the syntax option (#6)

Setup plugin & config

[x] create plugin and configs ESLint reference (#8)

[x] create tests packages inside the repo and add a complete working example

[x] add lint and format (#10)

[x] linter and follow this guide
[x] format using prettier

Refine tests and add documentation

[x] add configuration tests (#11)

[x] add both working and not working examples in tests
[x] add tests using vitest to ensure reported data is correct

[x] add documentation inside GitHub via markdown files (use eslint-doc-generator) (#12)
[x] add CONTRIBUTING.md

[x] to make test working in local you should run build first

[x] add package.json meta

engines
peerDependencies
repository
homepage
bugs
keywords

Release management and release

[x] publish
[x] use changeset for automatic release (#13)
[x] publish 1.0 with changeset

Version 1.0 has been published successfully using changeset:
https://www.npmjs.com/package/eslint-plugin-react-import


Added ability for user-selected default Abstract Rewards icon

Changed the path in QuestPreview.js (line 677) to point to a user-created folder/image.
Requires user to create a folder in the user data folder named FQL. (\AppData\Local\FoundryVTT\Data\FQL)
A jpg image may be placed in this folder and when renamed to defaultAbstract.jpg it will be the default icon for newly created Abstract Rewards.

note: I considered png or svg files instead of jpg but I think that the average user will have more access to jpg icon images, especially considering how many are included in Foundry/D&D 5E/Etc.

I'll add some more comments soon, but this PR should be modified.

Hi @Shuggaloaf.. I didn't want to leave you hanging.. So I came up with the best solution for this task. In the 0.7.4 update there is a new non-viewable module setting that stores the default abstract reward image.
You can easily set it in a macro with:
await game.settings.set('forien-quest-log', 'defaultAbstractRewardImage', '<image path>');

Or even better have a macro w/ a file browser to select the default image.
new FilePicker({
   type: 'image',

   callback: async (path) =>
   {
      await game.settings.set('forien-quest-log', 'defaultAbstractRewardImage', path);
   },
}).browse();

The file browser one will be likely added to an upcoming macro compendium for FQL.
So alas... I do appreciate you taking the time to make this PR, but the solution I mentioned above is very flexible and will be available soon.

Thanks for the reply and no worries, whatever works!
On Sat, 10 Jul 2021 15:51:22 -0700, Michael Leahy wrote:

Hi @Shuggaloaf.. I didn't want to leave you hanging.. So I came up with
the best solution for this task. In the 0.7.4 update there is a new
non-viewable module setting that stores the default abstract reward
image.
You can easily set it in a macro with:
await game.settings.set('forien-quest-log',

'defaultAbstractRewardImage', '');

Or even better have a macro w/ a file browser to select the default

image.

new FilePicker({
type: 'image',

callback: async (path) =>
{
await game.settings.set('forien-quest-log',

'defaultAbstractRewardImage', path);

},
}).browse();

The file browser one will be likely added to an upcoming macro

compendium for FQL.

So alas... I do appreciate you taking the time to make this PR, but the
solution I mentioned above is very flexible and will be available soon.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:

https://github.com/League-of-Foundry-Developers/foundryvtt-forien-quest-log/pull/68#issuecomment-877713857


Added sample code for MSBuild aliases

@devlead Can you rebase this for merge?

@patriksvensson rebased.

Related to #750.


Option to keep track of resistance level from 0 to 100

Suggested by Robert S. Double check if IC4 supplies any resistance data.

#337


Python3 Support

This pull request makes pg2kinesis work with python3. While the code in this pull request will work in both 2 and 3, pg2kinesis will only work with a python3 compatible aws_kinesis_agg, which is available on this branch. More on this issue can be found here but this issue is actively being tested and is on-track to be merged in the near future.
That being said, no changes in pg2kinesis rely on that branch being merged, so this pull should be reviewed independently of that bug.
This pull adds six to the list of dependencies which is available under the commercially friendly MIT license and fixes non-deterministic test behavior in test___main__.py caused by MagicMock not being formattable and time.time not being mocked:
self = <pg2kinesis.__main__.Consume object at 0x7f55b56c4eb8>, change = <Mock id='140006202557272'>

    def __call__(self, change):
        self.cum_msg_count += 1
        self.cum_msg_size += change.data_size

        self.msg_window_size += change.data_size
        self.msg_window_count += 1

        fmt_msgs = self.formatter(change.payload)

        progress_msg = 'xid: {:12} win_count:{:>10} win_size:{:>10}mb cum_count:{:>10} cum_size:{:>10}mb'

        for fmt_msg in fmt_msgs:
            did_put = self.writer.put_message(fmt_msg)
            if did_put:
                change.cursor.send_feedback(flush_lsn=change.data_start)
                logger.info('Flushed LSN: {}'.format(change.data_start))

            int_time = int(time.time())
            if not int_time % 10 and int_time != self.cur_window:
                logger.info(progress_msg.format(
                    self.formatter.cur_xact, self.msg_window_count,
                    self.msg_window_size / 1048576, self.cum_msg_count,
>                   self.cum_msg_size / 1048576))
E               TypeError: non-empty format string passed to object.__format__

pg2kinesis/__main__.py:96: TypeError

Hopeful this makes it to master. Thanks for the consideration.

@matthewstory Thanks for this! I'd much prefer we hold off on merging this until https://github.com/awslabs/kinesis-aggregation/issues/22 makes it up to pypi, especially since it's so close to landing.
If work on kinesis-agg gets delayed for whatever reason we can revisit and get this in sooner.

@matthewstory I haven't forgotten about this! Looks like the changes we are waiting for still havent landed on https://github.com/awslabs/kinesis-aggregation/issues/22
If there's no real urgency in getting these changes in I'd still prefer we give the other project time to get their side ironed out and save us from any potential gaps in testing or back-and-forth changes here.

No urgency from my side. Happy to wait if that makes things less
complicated for everyone and lets us easily test it.
On Wed, Feb 28, 2018 at 5:08 PM, Geoff Johnson<EMAIL_ADDRESS>wrote:

@matthewstory https://github.com/matthewstory I haven't forgotten about
this! Looks like the changes we are waiting for still havent landed on
awslabs/kinesis-aggregation#22
https://github.com/awslabs/kinesis-aggregation/issues/22
If there's no real urgency in getting these changes in I'd still prefer we
give the other project time to get their side ironed out and save us from
any potential gaps in testing or back-and-forth changes here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/handshake/pg2kinesis/pull/10#issuecomment-369400402,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABNjFsqJWsRKLHEhYv0SjI8-vtXgKqPks5tZc5sgaJpZM4SHnKm
.

--
regards,
matt

@matthewstory the code behind awslabs/kinesis-aggregation#22 merged last night. It is now on pypi as 1.1.0.
Please update pull and get travis wired up so we can merge this!

Well it didn't happen that night, but got to it today. Please note that the tests were 30s slower in Python 3.3 than in 2.7 per Travis, but they pass. Not sure if this is cause for concern or not.


update pf and rhcs dependencies

https://issues.redhat.com/browse/COST-2758

Codecov Report

Merging #2398 (0d3a151) into main (b9de03b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             main    #2398    +/-   ##
========================================
  Coverage   69.90%   69.90%
========================================
  Files         413      413
  Lines        7854     7854
  Branches     1853     1852     -1
========================================
  Hits         5490     5490
+ Misses       2361     2256   -105
- Partials        3      108   +105

Impacted Files
Coverage Δ

src/utils/cookie.ts
58.33% <0.00%> (ø)

src/utils/format.ts
67.00% <0.00%> (ø)

src/api/orgs/orgUtils.ts
37.50% <0.00%> (ø)

src/api/queries/query.ts
43.85% <0.00%> (ø)

src/utils/localStorage.ts
78.66% <0.00%> (ø)

src/store/metrics/selectors.ts
75.86% <0.00%> (ø)

src/api/resources/resourceUtils.ts
17.18% <0.00%> (ø)

src/components/exports/exportsLink.tsx
43.75% <0.00%> (ø)

src/components/permissions/permissions.tsx
22.05% <0.00%> (ø)

src/pages/components/currency/currency.tsx
31.25% <0.00%> (ø)

... and 25 more

Continue to review full report at Codecov.

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


What is the time complexity?

Hi,
what is the expected time complexity in big-O notation for an inference session on the U-2-Net model?
Thanks!

Sorry, what do you mean about the big-O? The running time of the ablation
is provided in Table 2: https://xuebinqin.github.io/U2Net_PR_2020.pdf
On Thu, Jul 21, 2022 at 12:52 PM Benny @.***> wrote:

Hi,
what is the expected time complexity in big-O notation for an inference
session on the U-2-Net model?
Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/xuebinqin/U-2-Net/issues/321, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSGORKHRGYSQHBFFW2GHO3VVGS6RANCNFSM54IZ5F6Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Xuebin Qin
PhD
Department of Computing Science
University of Alberta, Edmonton, AB, Canada
Homepage: https://xuebinqin.github.io/


Update repo path to new match new gocd domain name

The Go.cd domain name expired recently, and according to https://groups.google.com/forum/#!msg/go-cd/ssWT_krsLdM/xobPCVUoEwAJ the team will be migrating to a new domain name.

Fixed in #16


Radio buttons not checked with react-bootstrap + immutable

Tried to reproduce with ESNextbin, but I get a ReactDOM error in the boilerplate sample.
I have a simple form that uses react-bootstrap components. When the radio buttons are clicked, the state updates as expected, but the buttons do not appear clicked in the UI. Any suggestions would be appreciated.
Happy to help try to reproduce in a working ESNextbin sandbox/provide additional information.
import React from 'react';
import { Control, Form } from 'react-redux-form/immutable';
import { Radio } from 'react-bootstrap';

class MyForm extends React.PureComponent {

  handleSubmit(vals) {
    console.log(vals);
  }
  render() {
    return (
      <Form
        model="search"
        onSubmit={(vals) => this.handleSubmit(vals)}
      >
        <Control.radio model=".sex" value="male" component={Radio} inline>
          Male
        </Control.radio>
        <Control.radio model=".sex" value="female" component={Radio} inline>
          Female
        </Control.radio>
      </Form>
    );
  }
}

export default MyForm;

Thanks,
Terry

Sure, can you make a reproducible example in www.esnextb.in ?

Sorry, to clarify, I was not able to get ESNextbin working with readt-redux-form/immutable, even well enough to just render the form.
You can check out the following: https://esnextb.in/?gist=97d0c044a2f119de9993d1a6274a3639 (https://gist.github.com/tmcdonnell87/97d0c044a2f119de9993d1a6274a3639)
Adding the line import { Control, Form } from 'react-redux-form/immutable'; causes ESNextbin to throw the following error:
import { createModeler } from './reducers/model-reducer';
^
ParseError: 'import' and 'export' may appear only with 'sourceType: module'

Sorry, to clarify, I was not able to get ESNextbin working with readt-redux-form/immutable, even well enough to just render the form.
You can check out the following: https://esnextb.in/?gist=97d0c044a2f119de9993d1a6274a3639 (https://gist.github.com/tmcdonnell87/97d0c044a2f119de9993d1a6274a3639)
Adding the line import { Control, Form } from 'react-redux-form/immutable'; causes ESNextbin to throw the following error:
import { createModeler } from './reducers/model-reducer';
^
ParseError: 'import' and 'export' may appear only with 'sourceType: module'

@tmcdonnell87 I was not able to reproduce this. The following fully reproducible code works as expected and the buttons successfully appear as clicked in the UI:
import React from 'react';
import ReactDOM from 'react-dom';
import { Control, Form, combineForms } from 'react-redux-form/immutable';
import Immutable from 'immutable';
import { Radio } from 'react-bootstrap';

import { createStore } from 'redux';
import { Provider } from 'react-redux';

const store = createStore(combineForms({
  search: Immutable.fromJS({ sex: 'male' }),
}));

class MyForm extends React.PureComponent {

  handleSubmit(vals) {
    console.log(vals);
  }
  render() {
    return (
      <Provider store={store}>
        <Form
          model="search"
          onSubmit={(vals) => this.handleSubmit(vals)}
        >
          <Control.radio model=".sex" value="male" component={Radio} inline>
            Male
          </Control.radio>
          <Control.radio model=".sex" value="female" component={Radio} inline>
            Female
          </Control.radio>
        </Form>
      </Provider>
    );
  }
}

ReactDOM.render(<MyForm />, document.querySelector('#app'))

Please review the above code and let me know if there are any large discrepancies between the above and your code.

That works for you in ESNextbin? I copied and pasted that directly and it's still erroring

I tried it directly on a local project. I'm not sure why it's going to react-redux-form/src/immutable.js - it should instead be hitting react-redux-form/immutable.js directly.

any update? i had the same problem as you have

@weichenghsu I ended up using a LocalForm for that particular use case so didn't spend more time on it. Were you able to reproduce in a sandbox?


[REVIEW] Quantile bindings

Exposed libgdf quantile functionality in dataframe.py and series.py. Main difference from pandas, if calculating multiple quantiles in dataframe.py it returns a dataframe with 2 columns: the requested quantiles and the calculated values. Pandas returns the quantiles as indices. Could add that functionality depending on review feedback.

Note: This PR requires a small libgdf PR: https://github.com/rapidsai/libgdf/pull/175

LGTM pending libgdf merge + CI

rerun tests

rerun tests

This is failing because of CI logic, not because of any issues in the PR. Here's the explanation I sent to @mike-wendt: "We have pygdf PR 291 with a branch called bX, and CI looks for a libgdf sister branch also called bX, and it clones that branch, even it has already been merged into libgdf master.  In this case it was, with libgdf PR 175. But we also have pygdf 292 which we already merged, which depends on libgdf 166 which was already merged. But since 292 was merged and depends on something in master that is not in bX, CI fails for 291…
So technically you need to make that sister branch logic check if the sister branch was already merged into master. If it was, just clone master."
I'm going ahead and merging this because doing so will fix the CI errors.


Sentiment chart branch

Adds sentiment scores to a Pie Chart to show percentage of positive, negative, and neutral comments

This PR is from last week


Loading our own videos in the algorithm

First off thank you so much for your hard work on this project it is really remarkable. My team and I were able to get this running on a Raspberry PI 4 which is running Pyton 3.7 , armv7l, and Raspberry Pi OS (32 bit).
We made some modifications to the module versions and we figured you would like to know. They are listed below:
-editdistance==0.5.3
-matplotlib==3.3.3
-numpy==1.16.0
-scipy==1.0.1
-Pillow==8.0.1
-tensorflow==1.14.0
-sk-video==1.1.10
-dlib==19.21.0
Any other modules not listed from the setup.py are as originally indicated.
QUESTION:
Furthermore we would like to inquire about how to properly run our own videos in the algorithm. Specifically are there any specs we must apply to our input videos such as resolution, fps, or any other factors?
Thank you.

Hello,
We have resolved this issue ourselves.
Thank you

Hello,
We have resolved this issue ourselves.
Thank you


Allow relative path for load-path option

Hi,
Having multiple apps/modules in my development workspaces, it would be great to be able to specify relative path in load-path setting. The build would check if load paths exist based on current framework path.
- workspace
  - app_1
    .libsass.json // load-path: ["../app_2/src","../app_3/src"]
    - src
      main.scss
    - build
      main.css
  - app_2
    - src
      _lib.scss
  - app_3
    - src
      _vars.scss

Thanks for the great package

👍
I will like it too. When projects are shared between several collaborators/systems, relative paths would be necessary.


As a user I want to easily migrate my data from one pod to another without breaking outside links to my data

The last part (without breaking links) might be out of scope for the server, but it's probably worth discussing.

3xx redirections have been mentioned in previous discussions and of course that's a proved/working solution on the Web, but if we want the social aspect of Solid to work, I feel like link "stability" matters.
Moving your pod around should probably not break the links that people have created (unless you know what you're doing), and keeping an intermediary in the chain (i.e., the previous pod provider doing 3xx) might be a concern for privacy.
One idea that I've mentioned on Gitter, although somewhat crazy, might be to have a GTLD for Solid and an easy way to get your own names/identifiers there; those would then be your own stable entry points. I'm just thinking out loud here though.. :)

Interesting/related discussion and ideas: https://gitter.im/solid/chat?at=5c877a26c8e5bc51622a288e

Yeah, and #25 also stems from the same motivation. I know that myself, I wouldn't use a Pod under somebody else's domain name.

Added to readme

Opening this as part of moving all user stories into issues again.


fix(plugins/plugin-client-common): split headers have low contrast in…

… dark themes
Fixes #7538

Description of what you did:

My PR is a:

[ ] 💥 Breaking change
[x] 🐛 Bug fix
[ ] 💅 Enhancement
[ ] 🚀 New feature

Please confirm that your PR fulfills these requirements

[x] Multiple commits are squashed into one commit.
[x] The commit message follows Conventional Commits, which allows us to autogenerate release notes; e.g. fix(plugins/plugin-k8s): fixed annoying bugs
[x] All npm dependencies are pinned.

/lgtm


Black weight font variant is selected when regular weight was requested

Description
On Linux, with the core fonts for the Web installed with https://corefonts.sourceforge.net, Typst selects Arial Black, although Arial would be correct.
Dockerfile for reproduction:
FROM ghcr.io/typst/typst:latest

ENV TYPST_FONT_PATHS=/usr/share/fonts/truetype/msttcorefonts

RUN set -eux; \
    apk add --no-cache msttcorefonts-installer; \
    update-ms-fonts; \
    apk del --no-cache msttcorefonts-installer;

Typst file:
#text(font: "Arial", weight: "regular")[regular]

#text(font: "Arial", weight: "black")[black]

Typst falsely classifies Arial_Black.ttf as regular weight, resulting in both lines being written in Arial Black, when you compile this.
This issue does not occur on macOS with the natively installed Microsoft fonts.
Reproduction URL
No response
Operating system
Linux
Typst version

[X] I am using the latest version of Typst

Duplicate of https://github.com/typst/typst/issues/576

Where can I get ahold of the raw Arial Black ttf file to inspect it?

Ok, I've managed to extract it. The OS/2 table of the font specifies a usWeightClass of 400, which is clearly wrong.

I suspected something like that, but was not familiar enough with fonts to confirm. I don't think, we should wait for this to be fixed upstream, since this the de-facto standard way of installing MS fonts on Linux since forever. That means an upstream fix would take years to reach users.
What do you think is the best way forward here?

I'm not sure. Perhaps there is no way but to ship exceptions, but if so, we should definitely apply them very carefully, e.g. maybe not for any font ending with "black", but rather specifically for Arial Black. I'll discuss this with @reknih.

Typst already have some ad-hoc exceptions for font names. Maybe we can generalize that and introduce a font map mechanism into typst. That can be a mapping embedded into typst binary like this:
NewComputerModern08-Italic:
  - family: "New Comupter Modern"
NewComputerModern08-BookItalic:
  - family: "New Comupter Modern"
  - weight: 450

The keys correspond to the FULL_NAME record in the font file. Users encountering fonts with incorrect metadata can simply submit a pull request to update this file accordingly. For instance:
"Arial Black":
  - family: Arial
  - weight: 900

In the future, we can offer an API that allows users to supply their own fontmap.yaml, which would override the default one built into Typst.

I wonder whether should just decide based on the FULL_NAME or perhaps also on the checksum. The problem with the latter is that some fonts will continue to retain their "wrong" metadata across multiple versions, so FULL_NAME is probably the better albeit less safe choice.

I wonder whether should just decide based on the FULL_NAME or perhaps also on the checksum. The problem with the latter is that some fonts will continue to retain their "wrong" metadata across multiple versions, so FULL_NAME is probably the better albeit less safe choice.

I agree. Can I help with this in any way? Is someone experienced willing to work on this, or should I give this a go?

While this is sort of a dupe, I've reopened so that we can properly use it for further discussion and close it once we've implemented something to this effect.

Typst uses (family, style, weight, stretch, size) 5-tuple to identify a font.

OpenType font formats also includes style and weight, but font designers make fonts without aware of the typst coordinate system. That's why typst is using a very hacking algorithm to calculate the correct family-coordinate of a font.

Typst only uses the first four, not the size for font selection. The family-style-weight-stretch coordinate system is pretty common, e.g. in CSS. It is not Typst-specific. The only thing that's specific is the (hacky) effort Typst makes to have a nicer family name and the few exceptions where Typst patches the metadata based on name.

I think that is not optimal because when using FULL_NAME ... emph and strong will not work.

That's a fair criticism.

Thus I proposed another approach in https://github.com/typst/typst/issues/3213#issuecomment-1897824364: Design a systematic approach to map OpenType coordinate to the typst coordinate.

To be clear: I am not against adding a general exception mechanism. But as you said, it would require not just a list, but also an automatic produce to get a "nice" uniform family consisting of only fonts differing in style/weight/stretch from the available data in the font. In theory, font names could also be selected in such a way that this property is enforced for a given font set, but that might be weird because an existing font name might change when a new font is installed.
That's why I proposed doing something more predictable and mostly relying on TYPOGRAPHIC_FAMILY. I'd be all on board with a more systematic approach to map OpenType coordinate to the CSS coordinate system if we find a good one.

Typst only uses the first four, not the size for font selection.

Wouldn't it make sense for Typst to also use size for font selection? New Computer Modern (and probably others) has different font files optimized for 8 point and 10 point sizes.

Computer Modern is actually pretty unique in that respect. The differences in the two variants are due to the Optical Size difference of the fonts, consisting of small weight and detail differences that make the fonts more legible at their respective sizes. Some modern font families include "Display" variants which are intended for display font sizes (>~18pt) but don't make such a clear distinction. Variable fonts have begun to ship the opsz variation axis for optical sizing. The units on that scale are standardized with regards to point size.
Typst does not yet support variable fonts (#185) but once we do, we should automatically adjust the opsz axis based on font size. In my opinion, support for legacy approaches for optical sizing (dedicated denominated fonts or Display variants) belongs in the same work package instead of here.

I implemented #3228. Feedback appreciated!

@mkroening #3228 Has been merged. Would you like to submit a PR to fix your Arial Black font issue?

Ok, I've managed to extract it. The OS/2 table of the font specifies a usWeightClass of 400, which is clearly wrong.

@laurmaedje, can you point me to a tool that can be used to extract such information? I'd like my PR fixing this to be comprehensive for all corefonts.

I use opentype.js.org. You need the font inspector tab rather than the glyph inspector and then check the OS/2 table.

I just opened https://github.com/typst/typst/pull/3321.


MinMax element finder in array

This is a C program to find maximum and minimum element in the array.

Hi Dear @MannanAhmad
Great code
Thanks for your contribution......
Show your support on my youtube channel web Pixar(The institute of coding)
like , share , subscribe
youtube - https://youtu.be/5qnQjgdpFPg
telegram-channel - https://t.me/WebPixar
join our telegram channel for more goodies , swag packs

Done.
Kindly check my youtube channel "GyanWithMannan" too.
And show your support by doing like share and subscribe.
Thanks and Regards
Mannan Ahmad
On Fri, Oct 8, 2021, 10:31 1dharode @.***> wrote:

Hi Dear @MannanAhmad https://github.com/MannanAhmad
Great code
Thanks for your contribution......
Show your support on my youtube channel web Pixar(The institute of coding)
like , share , subscribe
youtube - https://youtu.be/5qnQjgdpFPg
telegram-channel - https://t.me/WebPixar
join our telegram channel for more goodies , swag packs
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/1dharode/Hacktoberfest2021/pull/179#issuecomment-938345112,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALVIHSUCTN7V54D3IXAH4CTUFZ3K5ANCNFSM5FO2ZBUQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Start Bundle Upgrade Cycle

We've had stuff lying about for at least two months, and in some cases multiple versions in preview, which makes zero sense, so EOL the old and GA the new, deleting the interim versions (manaully updated already). Additionally fix some CVEs while here, this is only available in the upgraded version, so others are still vulnerable until upgrade.

I checked if the ingress got the new flag on the EOL version, just to get it out there.  Sadly not, hence my comments above.


Bootstrap property startPageActionBarHidden not working

The property startPageActionBarHidden is not working with<EMAIL_ADDRESS>and<EMAIL_ADDRESS>The property as described here, use to hide the ActionBar on the landing page
Steps to reproduce:

Create the master-details NG app

tns create myApp --ng

Remove ActionBar from items.component.html and item-details.component.html
Add the property in main.ts

platformNativeScriptDynamic({ startPageActionBarHidden: true }).bootstrapModule(AppModule);

Result: On Android, we will have Actionbar with the title the name of the application while on iOS there will be no ActionBar at all (no matter if the property is set or not).
Test application here
Workaround:
Go to the landing page and hide the action bar though the Page instance from Di
constructor(private itemService: ItemService, private _page: Page) {
   this._page.actionBarHidden = true;
}

might be related to issue https://github.com/NativeScript/NativeScript/issues/6098

As of version 4.x.x of tns-core-modules and NativeScript the porperty startPageActionBarHidden is no longer needed as there is no longer a Page instance created on bootstrap. Instead the first page instance is created for the default route.
So to hide the action bar on Android (on iOS we simply need to remove it from the HTML) we can get a Page instance in our default route and use actionBarHidden property.

import { isAndroid } from "platform";
import { Page } from "ui/page";

constructor(private page: Page) {
        if (isAndroid) {
            this.page.actionBarHidden = true;
        }
}

The startPageActionBarHidden will be marked for deprcication and removed from the documentation articles examples.

Documentation updated via https://github.com/NativeScript/docs/pulls


Update Ruby version to support 2.3.7

For @eregon

@eregon do you know how I can fix these problems supporting such an old version of Ruby?

I think the issue is the Gemfile.lock is checked in the repo, and parallel 1.21.0 needs Ruby >= 2.5, so you'd need to reresolve the Gemfile to install properly.
One way would be to not check in Gemfile.lock in the repo (common for gems, because then CI runs represent what users get when they install seafoam, which automatically uses the latest dependencies). But the dependencies here are actually test dependencies, so that's not so useful. Could explicitly rm Gemfile.lock before using setup-ruby as one way.
Supporting 2.3 might not be worth the effort, I'll keep you updated.


Fix tests for mac

Fix #204: TestData should be platform independent
Fix #205: PythonVersions cannot be constructed on macOS

Partially related, but there are tests which assume that sys.winver exists, which then fail on non-Windows OSs. Probably good for another PR as we keep fixing tests.

There are about 50 tests that have dependencies on windows-specific code. Maybe some of them should stay windows-specific and be simply ignored when executed on mac/unix.

Yup, and I'm sure some of them are using those platform-specific items for purposes other than their platform-specific qualities (like the test that uses kernel32.dll because it's binary). Some of the winver tests may just use it for what it looks like when analyzed.


PORTALS-2688: first pass with Lighthouse accessibility results

(seems to be an unrelated error in synapse-react-client integration tests : test/containers/entity/annotations/SchemaDrivenAnnotationsEditor.integration.test.tsx)


[BUG] Members of nested groups in Azure AD do not inherit the same permissions as those in the parent group

Rancher Server Setup

Rancher version: v2.9-head 3c4ccdc and upgrade from 2.8.5 to 2.9-head
Installation option (Docker install/Helm Chart): Docker install

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc):

Information about the Cluster

Kubernetes version: Local
Cluster Type (Local/Downstream): v1.30.2+k3s2

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)

If custom, define the set of permissions: Admin

Describe the bug
When a group is added in Azure AD with specific permissions, members of nested groups do not receive the same permissions. After upgrading from version 2.8.5 to 2.9-head, nested group members who previously had access in 2.8.5 lose their access post Rancher upgrade.
To Reproduce

Create a rancher server v2.8.5
Enable azure AD with default settings - do not add any filter.
Navigate to Users and auth >> role template, create a global role as follows:

apiVersion: management.cattle.io/v3
displayName: inheritedrole1
inheritedClusterRoles:
  - cluster-owner
kind: GlobalRole
metadata:
  name: role1

Create a downstream node provider k3s cluster.
Navigate to Users and auth >> groups >> Add a user group with the role created above. >> group1
Login as a user1 from the group nested in the parent group >> group2
Verify the user has permissions to the downstream cluster.
Upgrade rancher server to v2.9-head.

Result
Notice the user1 do not have the permissions that were previously seen pre upgrade.
Expected Result
Expected nested users to have permissions added for the parent group.
Additional context

This is only seen on azure AD auth providers. Tried the same use case with Active directory and noticed no change in the permissions.
User attributes post upgrade do not have the parent group listed..
F.e:

2.8.5 user attributes:
 azuread:
    Items:
    - displayName: anugroup
      memberOf: true
      metadata:
        creationTimestamp: null
        name: azuread_group://bf<redacted>
      principalType: group
      provider: azuread
    - displayName: anunestedgroup1
      memberOf: true
      metadata:
        creationTimestamp: null
        name: azuread_group://95<redacted>
      principalType: group
      provider: azuread

2.9-head user attributes:
  azuread:
    Items:
    - displayName: anunestedgroup1
      memberOf: true
      metadata:
        creationTimestamp: null
        name: azuread_group://95<redacted>
      principalType: group
      provider: azuread

Group structure:
anugroup
|__ anuuser1
|__ anunestedgroup1
      |__ anunesteduser1

Verified on v2.9-head 637346f and 2.8.5 >> v2.9-head 637346f

Verified adding a group with nested users, have same permissions as the parent.
Verified users of group has the expected permissions.
Verified adding a group on 2.8.5 with nested users and on an upgrade nested users have the required permissions.
Verified adding filter works as expected for nested users on fresh install and upgrade checks.


versions:update-properties does not resolve X.Y-something-SNAPSHOT properly

Context
We have a library (libfoo) that has (at least) one feature branch and a master branch. The version in the pom is specified as follows:

branch master: 1.0-SNAPSHOT
branch featureA: 1.0-featureA-SNAPSHOT

Then we have an application (appbar) which also has feature branches:

branch master: 2.0-SNAPSHOT
branch featureA: 2.0-featureA-SNAPSHOT

The dependency between appbar and libfoo is defined through a property, as follow:
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>appbar</artifactId>
  <version>2.0-featureA-SNAPSHOT</version>

  <properties>
    <libfoo.version>1.0-featureA-SNAPSHOT</libfoo.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>libfoo</artifactId>
      <version>${libfoo.version}</version>
    </dependency>
  </dependencies>
</project>

Issue
When using mvn -U versions:update-properties to replace the -SNAPSHOT with the actual latest corresponding version, we end up with a version from the master branch (ex:1.0-1234) instead of one from the feature branch (ex:1.0-featureA-1235)
Workaround
If we define the version directly in the dependency:
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>appbar</artifactId>
  <version>2.0-SNAPSHOT</version>

  <dependencies>
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>libfoo</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

And if we use mvn -U versions:use-releases instead, then we end up with the appropriate version resolved. But this is a solution that does not scale well: if we have 10+ dependencies with the same version (ex: multi-module repository where each lib is a module), then at each version upgrade, the version should be adapted for each dependency.
TL;DR

versions:use-releases resolves 1.0-something-SNAPSHOT into 1.0-something-XXXXX.
versions:update-properties resolves 1.0-something-SNAPSHOT into 1.0-XXXXX.
versions:update-properties  should behave like versions:use-releases.

Up ?

I've got the exact same issues. Could someone please have a look?

I have the same issues.
Someone has been able to explore more on this topic.

I have the same issues.
Someone has been able to explore more on this topic.

Just a note - I'm gonna try to fix this in my fork. If someone else has started, please let me know so I can jump to help instead.


Automation [squash on merge]

Took more code than I thought, and I want to move some stuff out. But it works :)
This moves the modules to JSON files as the source of truth and adds npm run awesome to:

Generate markdown tables with up-to-date compatibility badges
Replace the relevant README sections with the generated markdown
Update the TOC (courtesy of remark-toc)
Linkify GitHub mentions and issues (courtesy of remark-github)
Add bookmarks for all modules, sort them, remove warn about dead references.

Added levelup compatibility badges to the bundles. This is specified in the JSON as:
https://github.com/Level/awesome/blob/cfa7d4fa90b62e28d2be2eafcd411030b9f938a1/modules/bundles.json#L6-L9
And jsondown now uses that same generic mechanism:
https://github.com/Level/awesome/blob/cfa7d4fa90b62e28d2be2eafcd411030b9f938a1/modules/stores.json#L23-L30

These files are now generic enough to be moved to their own npm packages:

compatibility.js
remark-bookmarks.js
mdast-image

But I prefer to first merge this PR and pull in more modules from the wiki (#1, which is much easier now) to see if there are any gaps in the tooling.
@ralphtheninja WDYT?

Also, would you mind testing npm run awesome to avoid "works on my machine"? You can manually remove one of the tables from README before npm run awesome to see that it regenerates.

Also, would you mind testing npm run awesome to avoid "works on my machine"? You can manually remove one of the tables from README before npm run awesome to see that it regenerates.

Tried removing the first table but seems links are broken since no back ticks are inserted:

diff --git a/README.md b/README.md
index 066d7bb..3aff8b6 100644
--- a/README.md
+++ b/README.md
@@ -20,14 +20,14 @@

 ## Bundles

-Convenience modules that bundle [a store](#stores) with [`levelup`] and [`encoding-down`].
+Convenience modules that bundle [a store](#stores) with [levelup] and [encoding-down].

 Name | Compatibility | Dependencies | Description
 :--- | :------------ | :----------- | :----------
-**[`level`]** | ![levelup](https://img.shields.io/badge/levelup-2.0-brightgreen.svg) | [![dependencies](https://img.shields.io/david/level/level.svg?label=%E2%99%A5)](https://david-dm.org/level/level) | Bundle for [`leveldown`].
Main entry point for beginners.
-**[`level-mem`]** | ![levelup](https://img.shields.io/badge/levelup-2.0-brightgreen.svg) | [![dependencies](https://img.shields.io/david/level/level-mem.svg?label=%E2%99%A5)](https://david-dm.org/level/level-mem) | Bundle for [`memdown`].
-**[`level-rocksdb`]** | ![levelup](https://img.shields.io/badge/levelup-2.0-brightgreen.svg) | [![dependencies](https://img.shields.io/david/level/level-rocksdb.svg?label=%E2%99%A5)](https://david-dm.org/level/level-rocksdb) | Bundle for [`rocksdb`].
-**[`level-browserify`]** | ![levelup](https://img.shields.io/badge/levelup-1.3-orange.svg) | [![dependencies](https://img.shields.io/david/level/level-browserify.svg?label=%E2%99%A5)](https://david-dm.org/level/level-browserify) | Bundle for [`level-js`].
+**[`level`]** | ![levelup](https://img.shields.io/badge/levelup-2.0-brightgreen.svg) | [![dependencies](https://img.shields.io/david/level/level.svg?label=%E2%99%A5)](https://david-dm.org/level/level) | Bundle for [leveldown].
Main entry point for beginners.
+**[`level-mem`]** | ![levelup](https://img.shields.io/badge/levelup-2.0-brightgreen.svg) | [![dependencies](https://img.shields.io/david/level/level-mem.svg?label=%E2%99%A5)](https://david-dm.org/level/level-mem) | Bundle for [memdown].
+**[`level-rocksdb`]** | ![levelup](https://img.shields.io/badge/levelup-2.0-brightgreen.svg) | [![dependencies](https://img.shields.io/david/level/level-rocksdb.svg?label=%E2%99%A5)](https://david-dm.org/level/level-rocksdb) | Bundle for [rocksdb].
+**[`level-browserify`]** | ![levelup](https://img.shields.io/badge/levelup-1.3-orange.svg) | [![dependencies](https://img.shields.io/david/level/level-browserify.svg?label=%E2%99%A5)](https://david-dm.org/level/level-browserify) | Bundle for [level-js].

Also, db.open() looks slightly odd:

Also, db.open() looks slightly odd:

I did not mean to keep that haha. Will fix.

Tried removing the first table but seems links are broken since no back ticks are inserted:

I'll see if I can replicate.

@ralphtheninja which node version are you on?

node 10

@vweevers I can switch to another version just to see if that's the problem. Which one are you on?

I just tried node 10, works for me. I was on node 8.6.0. Can you try it with the latest commit (https://github.com/Level/awesome/pull/11/commits/1bc21d477812311eaf885cdedf08a62482897ad9)?

Found the issue, I think. I'm using the wrong node type for the link content. Instead of text I should use inlineCode.

Still have the same issues. I get the same error when running npm run awesome even without removing the first table. Also, if I remove the Core table it doesn't re-generate.

:(

It's weird that you can't reproduce it :open_mouth:

If I only do npm run awesome (without changing anything). I get the following output:
$ npm run awesome

><EMAIL_ADDRESS>awesome /home/lms/src/level/awesome
> node src README.md modules/*

README.md
  1:12-1:23  warning  dead reference: leveldown      remark-bookmarks
  1:12-1:21  warning  dead reference: memdown        remark-bookmarks
  1:12-1:21  warning  dead reference: rocksdb        remark-bookmarks
  1:12-1:22  warning  dead reference: level-js       remark-bookmarks
  1:57-1:66  warning  dead reference: levelup        remark-bookmarks
  1:71-1:86  warning  dead reference: encoding-down  remark-bookmarks

⚠ 6 warnings

Can you apply the following patch and send me the output?
diff --git a/src/index.js b/src/index.js
index bbab71a..073c195 100644
--- a/src/index.js
+++ b/src/index.js
@@ -23,8 +23,20 @@ remark()
     summary: () => 'Click to expand'
   })
   .use(github)
+
+  .use(() => (tree) => {
+    console.log('BEFORE')
+    console.log(JSON.stringify(tree, null, 2))
+  })
+
   .use(bookmarks, { modules })

+  .use(() => (tree) => {
+    console.log('AFTER')
+    console.log(JSON.stringify(tree, null, 2))
+    process.exit()
+  })
+
   // Disable padding to lessen diff noise
   .use(stringify, { paddedTable: false, looseTable: true })

output.txt

The difference is this:
{
  "vince-before": {
    "identifier": "riakdown",
    "referenceType": "shortcut",
    "type": "linkReference",
    "children": [
      [{
        "type": "inlineCode",
        "value": "riakdown"
      }]
    ]
  },
  "magnus-before": {
    "identifier": "`riakdown`",
    "referenceType": "shortcut",
    "type": "linkReference",
    "children": [{
      "type": "inlineCode",
      "value": "riakdown",
      "position": ..
    }],
    "position": ..
  }
}

The presence of position on the nodes suggests that these are the parsed nodes of the original markdown, rather than newly generated nodes. Which means src/remark-generator.js doesn't do anything in your case.
And I found out why :) Your shell expands the glob pattern in node src README.md modules/* which is incompatible with:
https://github.com/Level/awesome/blob/491c7b52d5fd9ca931271dd7602149aa186eeb0d/src/index.js#L15
That's my bad. Fix coming in a bit.

@vweevers Works fine now!

I.e. if you do node src README.md modules/core.json it should leave the other sections intact.

Done.

@vweevers Maybe we could have a similar approach to documentation for e.g. leveldown, levelup, level, level-mem, level-rocksdb etc.

@ralphtheninja yeah, def. I was thinking we could create a preset (see https://github.com/unifiedjs/unified#example-1) with a bunch of remark plugins, and use it everywhere.

@ralphtheninja yeah, def. I was thinking we could create a preset (see https://github.com/unifiedjs/unified#example-1) with a bunch of remark plugins, and use it everywhere.

Feel free to create some issues on it and break it down. Maybe it's even possible to use across the board? I'm thinking mainly on keeping the same "level style" in all READMEs.

@vweevers Side note; What's the "next step" for level? I'm thinking we should try to push through the latest abstract-leveldown into dependents to make this readme a little more green.

I'm thinking we should try to push through the latest abstract-leveldown into dependents to make this readme a little more green.

Yes, starting with level-js. That's been waiting too long

(Airtap work can wait, no?)

(Airtap work can wait, no?)

I feel airtap works rather well right now.

Maybe we can also use the level badge in related projects?

What do you mean?

Sort of like the awesome badge. There are many awesome projects scattered across github, but they all (or most of them) use the awesome badge. If that makes sense.

You mean adding the badge to projects like subleveldown (outside the level org)? Sure :)


Suite and StmtList

Check with instructor about these to get some tips.

@rvarca22 @IanMarsh1 Not sure if either of you are working on this, but this is one of the crucial pieces remaining, since all of the compound statements depend on it. Should be a short, quick one now that the parser for Program has been implemented, but let me know if you have any questions.


remove transport/3 from socket

transport/3 is deprecated in Phoenix 1.4+

We also need to bump the phoenix version to ~> 1.4 in mix.exs

This has been taken care of in the 1.2 release, which required some testing changes. Thanks!


Player entities could be handled directly as other entities and this would be resolved (except for own fire overlay, I guess)
Video: https://streamable.com/6w9j50

Yes, this is something I am working on atm so it should be fixed this week!


Firmware H1.0 leads to a 404

The link https://edu.irobot.com/create3/firmware/H.1.0 leads to a 404.

Oh no! Checking with the web team, now.

Thank you for reporting this issue! The link is now fixed.


New version: VisualRegressionTests v1.2.3

Registering package: VisualRegressionTests
Repository: https://github.com/JuliaPlots/VisualRegressionTests.jl
Created by: @t-bltg
Version: v1.2.3
Commit: fefd2d0865f2d1bf6298270eb1db90c87c5f9915
Reviewed by: @t-bltg
Reference: https://github.com/JuliaPlots/VisualRegressionTests.jl/commit/fefd2d0865f2d1bf6298270eb1db90c87c5f9915#commitcomment-82883579
Description: Automated integrated regression tests for graphics libraries

This PR can be trashed.


Amazon ec2 abuse

Hey,
I just got an Amazon AWS abuse because of using the scrapoxy image on one of their instances..
 We've received a report(s) that your AWS resource(s)

AWS ID: 2221xxxxxxx    Region: eu-west-1    EC2 Instance Id: i-0c29xxxxxxxx7 [34.xx.xx.xx]

has been implicated in activity which resembles attempts to access remote hosts on the internet without authorization. Activity of this nature is forbidden in the AWS Acceptable Use Policy (https://aws.amazon.com/aup/). We've included the original report below for your review.

Please take action to stop the reported activity and reply directly to this email with details of the corrective actions you have taken. If you do not consider the activity described in these reports to be abusive, please reply to this email with details of your use case.

Did anyone else get an abuse from them?
Regards

Hi, i get the same since 1 month.
I have nothing to do with the targeted entity and attack type (Account take down on Sony)
I think my security policies need some more controls
Investigating...


repo.msys2.org down unreachable

I am unable to reach repo.msys2.org.
Unsure if this is related to whatever issue caused #163 , but the diagnostics I have done say it is down.
http://repo.msys2.org/mingw/i686/ is unreachable
ping repo.msys2.org

Pinging diablo.msys2.org [<IP_ADDRESS>] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for <IP_ADDRESS>:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

debug output:
$ pacman -Syuv --debug
debug: pacman v5.0.1 - libalpm v10.0.1
debug: config: attempting to read file /etc/pacman.conf
debug: config: new section 'options'
debug: config: HoldPkg: pacman
debug: config: arch: x86_64
debug: config: SigLevel: Required
debug: config: SigLevel: DatabaseOptional
debug: config: LocalFileSigLevel: Optional
debug: config: new section 'mingw32'
debug: config file /etc/pacman.conf, line 73: including /etc/pacman.d/mirrorlist.mingw32
debug: config: new section 'mingw64'
debug: config file /etc/pacman.conf, line 76: including /etc/pacman.d/mirrorlist.mingw64
debug: config: new section 'msys'
debug: config file /etc/pacman.conf, line 79: including /etc/pacman.d/mirrorlist.msys
debug: config: finished parsing /etc/pacman.conf
debug: setup_libalpm called
debug: option 'logfile' = /var/log/pacman.log
debug: option 'gpgdir' = /etc/pacman.d/gnupg/
debug: option 'hookdir' = /etc/pacman.d/hooks/
debug: option 'cachedir' = /var/cache/pacman/pkg/
debug: registering sync database 'mingw32'
debug: database path for tree mingw32 set to /var/lib/pacman/sync/mingw32.db
debug: GPGME version: 1.6.0
debug: GPGME engine info: file=/usr/bin/gpg, home=/etc/pacman.d/gnupg/
debug: checking signature for /var/lib/pacman/sync/mingw32.db
debug: 1 signatures returned
debug: fingerprint: AD351C50AE085775EB59333B5F92EFC1A47D45A1
debug: summary: valid
debug: summary: green
debug: status: Success
debug: timestamp:<PHONE_NUMBER>
debug: exp_timestamp: 0
debug: validity: full; reason: Success
debug: key: AD351C50AE085775EB59333B5F92EFC1A47D45A1, Alexey Pavlov (Alexpux<EMAIL_ADDRESS>owner_trust unknown, disabled 0
debug: signature is valid
debug: signature is fully trusted
debug: setting usage of 15 for mingw32 repository
debug: adding new server URL to database 'mingw32': http://repo.msys2.org/mingw/i686
debug: adding new server URL to database 'mingw32': http://downloads.sourceforge.net/project/msys2/REPOS/MINGW/i686
debug: adding new server URL to database 'mingw32': http://www2.futureware.at/~nickoe/msys2-mirror/i686
debug: registering sync database 'mingw64'
debug: database path for tree mingw64 set to /var/lib/pacman/sync/mingw64.db
debug: checking signature for /var/lib/pacman/sync/mingw64.db
debug: 1 signatures returned
debug: fingerprint: AD351C50AE085775EB59333B5F92EFC1A47D45A1
debug: summary: valid
debug: summary: green
debug: status: Success
debug: timestamp:<PHONE_NUMBER>
debug: exp_timestamp: 0
debug: validity: full; reason: Success
debug: key: AD351C50AE085775EB59333B5F92EFC1A47D45A1, Alexey Pavlov (Alexpux<EMAIL_ADDRESS>owner_trust unknown, disabled 0
debug: signature is valid
debug: signature is fully trusted
debug: setting usage of 15 for mingw64 repository
debug: adding new server URL to database 'mingw64': http://repo.msys2.org/mingw/x86_64
debug: adding new server URL to database 'mingw64': http://downloads.sourceforge.net/project/msys2/REPOS/MINGW/x86_64
debug: adding new server URL to database 'mingw64': http://www2.futureware.at/~nickoe/msys2-mirror/x86_64
debug: registering sync database 'msys'
debug: database path for tree msys set to /var/lib/pacman/sync/msys.db
debug: checking signature for /var/lib/pacman/sync/msys.db
debug: 1 signatures returned
debug: fingerprint: AD351C50AE085775EB59333B5F92EFC1A47D45A1
debug: summary: valid
debug: summary: green
debug: status: Success
debug: timestamp:<PHONE_NUMBER>
debug: exp_timestamp: 0
debug: validity: full; reason: Success
debug: key: AD351C50AE085775EB59333B5F92EFC1A47D45A1, Alexey Pavlov (Alexpux<EMAIL_ADDRESS>owner_trust unknown, disabled 0
debug: signature is valid
debug: signature is fully trusted
debug: setting usage of 15 for msys repository
debug: adding new server URL to database 'msys': http://repo.msys2.org/msys/x86_64
debug: adding new server URL to database 'msys': http://downloads.sourceforge.net/project/msys2/REPOS/MSYS2/x86_64
debug: adding new server URL to database 'msys': http://www2.futureware.at/~nickoe/msys2-mirror/msys/x86_64
Root      : /
Conf File : /etc/pacman.conf
DB Path   : /var/lib/pacman/
Cache Dirs: /var/cache/pacman/pkg/
Hook Dirs : /usr/share/libalpm/hooks/  /etc/pacman.d/hooks/
Lock File : /var/lib/pacman/db.lck
Log File  : /var/log/pacman.log
GPG Dir   : /etc/pacman.d/gnupg/
Targets   : None
:: Synchronizing package databases...
debug: url: http://repo.msys2.org/mingw/i686/mingw32.db
debug: maxsize: 26214400
debug: using time condition:<PHONE_NUMBER>
debug: opened tempfile for download: /var/lib/pacman/sync/mingw32.db.part (wb)
debug: curl returned error 28 from transfer
error: failed retrieving file 'mingw32.db' from repo.msys2.org : Connection timed out after 10000 milliseconds
debug: url: http://downloads.sourceforge.net/project/msys2/REPOS/MINGW/i686/mingw32.db
debug: maxsize: 26214400
debug: using time condition:<PHONE_NUMBER>
debug: opened tempfile for download: /var/lib/pacman/sync/mingw32.db.part (wb)
debug: curl returned error 0 from transfer
debug: response code: 304
debug: file met time condition
 mingw32 is up to date
debug: url: http://repo.msys2.org/mingw/x86_64/mingw64.db
debug: maxsize: 26214400
debug: using time condition:<PHONE_NUMBER>
debug: opened tempfile for download: /var/lib/pacman/sync/mingw64.db.part (wb)
debug: curl returned error 28 from transfer
error: failed retrieving file 'mingw64.db' from repo.msys2.org : Connection timed out after 10000 milliseconds
debug: url: http://downloads.sourceforge.net/project/msys2/REPOS/MINGW/x86_64/mingw64.db
debug: maxsize: 26214400
debug: using time condition:<PHONE_NUMBER>
debug: opened tempfile for download: /var/lib/pacman/sync/mingw64.db.part (wb)
debug: curl returned error 0 from transfer
debug: response code: 304
debug: file met time condition
 mingw64 is up to date
debug: url: http://repo.msys2.org/msys/x86_64/msys.db
debug: maxsize: 26214400
debug: using time condition:<PHONE_NUMBER>
debug: opened tempfile for download: /var/lib/pacman/sync/msys.db.part (wb)
debug: curl returned error 28 from transfer
error: failed retrieving file 'msys.db' from repo.msys2.org : Connection timed out after 10000 milliseconds
debug: url: http://downloads.sourceforge.net/project/msys2/REPOS/MSYS2/x86_64/msys.db
debug: maxsize: 26214400
debug: using time condition:<PHONE_NUMBER>
debug: opened tempfile for download: /var/lib/pacman/sync/msys.db.part (wb)
debug: curl returned error 0 from transfer
debug: response code: 304
debug: file met time condition
 msys is up to date

(output continues just checking packages)
I've run all of

pacman -Sy && pacman -S pacman-mirrors
pacman -Su
pacman -Syuu

Not sure what to think at this point. anyone else experiencing this?

I have no problems accessing repo.msys2.org. Something with your network

Now - looking around - I see most can...
mxtoolbox
Hop		IP Address		HostName
1		<IP_ADDRESS>		mxtb-hsrp1.mxtoolbox.com
2		<IP_ADDRESS>	aus-core-10-v11.corenap.com
3		<IP_ADDRESS>		net64-20-229-137.static-customer.corenap.com
4		<IP_ADDRESS>		xe-2-2-0.mpr1.aus1.us.zip.zayo.com
5		<IP_ADDRESS>		ae1.cr1.dfw2.us.zip.zayo.com
6		<IP_ADDRESS>		ae11.er1.dfw2.us.zip.zayo.com
7		<IP_ADDRESS>		be3029.ccr41.dfw03.atlas.cogentco.com
8		<IP_ADDRESS>		be2763.ccr21.dfw01.atlas.cogentco.com
9		<IP_ADDRESS>		be2938.rcr21.dfw04.atlas.cogentco.com
10		<IP_ADDRESS>		te0-0-2-1.nr11.b028597-0.dfw04.atlas.cogentco.com
11		<IP_ADDRESS>		* * *
12		<IP_ADDRESS>	* * *
13		<IP_ADDRESS>		* * *

tcpiputils
Step	Time		IP - Hostname / IP, Provider and Location details
1	0.395 ms		<IP_ADDRESS> - core23.fsn1.hetzner.com
2	2.934 ms		<IP_ADDRESS> - core11.nbg1.hetzner.com
3	3.197 ms		<IP_ADDRESS> - juniper5.rz2.hetzner.de
4	3.621 ms		<IP_ADDRESS> - te0-0-1-2.nr11.b040138-0.nue01.atlas.cogentco.com
5	3.755 ms		<IP_ADDRESS> - te0-3-1-1.rcr21.nue01.atlas.cogentco.com
6	5.889 ms		<IP_ADDRESS> - be2270.ccr22.muc03.atlas.cogentco.com
7	11.051 ms	<IP_ADDRESS> - be2959.ccr41.fra03.atlas.cogentco.com
8	17.735 ms	<IP_ADDRESS> - be2813.ccr41.ams03.atlas.cogentco.com
9	27.581 ms	<IP_ADDRESS> - be2182.ccr21.lpl01.atlas.cogentco.com
10	96.965 ms	<IP_ADDRESS> - be3042.ccr21.ymq01.atlas.cogentco.com
11	104.197 ms	<IP_ADDRESS> - be2093.ccr22.yyz02.atlas.cogentco.com
12	111.496 ms	<IP_ADDRESS> - be2994.ccr22.cle04.atlas.cogentco.com
13	119.405 ms	<IP_ADDRESS> - be2718.ccr42.ord01.atlas.cogentco.com
14	129.983 ms	<IP_ADDRESS> - be2831.ccr21.mci01.atlas.cogentco.com
15	140.302 ms	<IP_ADDRESS> - be2432.ccr21.dfw01.atlas.cogentco.com
16	141.416 ms	<IP_ADDRESS> - be2939.rcr21.dfw04.atlas.cogentco.com
17	142.433 ms	<IP_ADDRESS> - te0-0-2-0.nr11.b028597-0.dfw04.atlas.cogentco.com

@Alexpux  can you provide a traceroute? Obviously not looking for your IP - just the last cogentco.com parts - I'll have to get in touch with cogent's netengs.  Any info you have though will help.

traceroute repo.msys2.org
traceroute to diablo.msys2.org (<IP_ADDRESS>), 64 hops max, 52 byte packets
 1  www.asusnetwork.net (<IP_ADDRESS>)  2.331 ms  1.925 ms  1.243 ms
 2  ip1-22.ethernet.wplus.ru (<IP_ADDRESS>)  3.641 ms  51.659 ms  19.550 ms
 3  <IP_ADDRESS> (<IP_ADDRESS>)  8.445 ms  24.546 ms  28.102 ms
 4  <IP_ADDRESS> (<IP_ADDRESS>)  10.789 ms  5.308 ms  465.031 ms
 5  <IP_ADDRESS> (<IP_ADDRESS>)  18.872 ms  4.390 ms  6.453 ms
 6  <IP_ADDRESS> (<IP_ADDRESS>)  57.586 ms  112.283 ms  39.881 ms
 7  be4766.nr21.b015761-2.fra06.atlas.cogentco.com (<IP_ADDRESS>)  38.618 ms  54.065 ms  55.271 ms
 8  <IP_ADDRESS> (<IP_ADDRESS>)  50.199 ms  92.730 ms  70.771 ms
 9  be2845.ccr41.fra03.atlas.cogentco.com (<IP_ADDRESS>)  45.599 ms
    be2846.ccr42.fra03.atlas.cogentco.com (<IP_ADDRESS>)  42.837 ms  40.281 ms
10  be2813.ccr41.ams03.atlas.cogentco.com (<IP_ADDRESS>)  63.224 ms
    be2814.ccr42.ams03.atlas.cogentco.com (<IP_ADDRESS>)  83.665 ms  70.413 ms
11  be2183.ccr22.lpl01.atlas.cogentco.com (<IP_ADDRESS>)  55.178 ms
    be2182.ccr21.lpl01.atlas.cogentco.com (<IP_ADDRESS>)  65.579 ms
    be2183.ccr22.lpl01.atlas.cogentco.com (<IP_ADDRESS>)  56.234 ms
12  be3042.ccr21.ymq01.atlas.cogentco.com (<IP_ADDRESS>)  127.201 ms  132.942 ms
    be3043.ccr22.ymq01.atlas.cogentco.com (<IP_ADDRESS>)  163.625 ms
13  be2090.ccr21.yyz02.atlas.cogentco.com (<IP_ADDRESS>)  151.305 ms  150.265 ms  296.119 ms
14  be2993.ccr21.cle04.atlas.cogentco.com (<IP_ADDRESS>)  229.550 ms
    be2994.ccr22.cle04.atlas.cogentco.com (<IP_ADDRESS>)  150.223 ms  158.959 ms
15  be2718.ccr42.ord01.atlas.cogentco.com (<IP_ADDRESS>)  155.782 ms  154.103 ms
    be2717.ccr41.ord01.atlas.cogentco.com (<IP_ADDRESS>)  152.943 ms
16  be2831.ccr21.mci01.atlas.cogentco.com (<IP_ADDRESS>)  174.320 ms
    be2832.ccr22.mci01.atlas.cogentco.com (<IP_ADDRESS>)  167.216 ms  181.790 ms
17  be2432.ccr21.dfw01.atlas.cogentco.com (<IP_ADDRESS>)  202.572 ms
    be2433.ccr22.dfw01.atlas.cogentco.com (<IP_ADDRESS>)  189.377 ms
    be2432.ccr21.dfw01.atlas.cogentco.com (<IP_ADDRESS>)  178.237 ms
18  be2938.rcr21.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  189.496 ms
    be2939.rcr21.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  206.137 ms
    be2938.rcr21.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  183.024 ms
19  te0-0-2-0.nr11.b028597-0.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  245.993 ms  520.058 ms
    te0-0-2-1.nr11.b028597-0.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  177.510 ms
20  <IP_ADDRESS> (<IP_ADDRESS>)  184.769 ms  191.194 ms  211.692 ms
21  <IP_ADDRESS> (<IP_ADDRESS>)  171.785 ms  187.094 ms  175.872 ms
22  <IP_ADDRESS> (<IP_ADDRESS>)  174.942 ms  211.374 ms  250.055 ms

@Alexpux Ok - thanks, I will get in touch with them, if not today, then tomorrow, maybe this will help others, I know it isn't local - probably some source based stuff either my ISP or cogent is doing. I'll know soon.

This is happening to me today, same results. Good to know it's probably not a local issue but frustrating. @erichiller Did you ever find more information?

Closing. I don't think we can do anything with this, but if someone thinks of something, I'm all ears.
Also, there are mirrors.

@dakotahawkins
It is definitely a ISP / route-specific issue - I had a neighbour who also has Old Time Warner (now Charter) and it doesn't work there either. Here's his tests:
ping
ping repo.msys2.org
PING diablo.msys2.org (<IP_ADDRESS>): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- diablo.msys2.org ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

traceroute
traceroute repo.msys2.org
traceroute to diablo.msys2.org (<IP_ADDRESS>), 64 hops max, 52 byte packets
 1  router.asus.com (<IP_ADDRESS>)  1.042 ms  0.898 ms  1.002 ms
 2  <IP_ADDRESS> (<IP_ADDRESS>)  17.630 ms  13.543 ms  9.227 ms
 3  <IP_ADDRESS> (<IP_ADDRESS>)  9.707 ms  10.074 ms  14.003 ms
 4  agg20.lamrcadq02r.socal.rr.com (<IP_ADDRESS>)  10.706 ms  14.958 ms  11.831 ms
 5  agg28.tustcaft01r.socal.rr.com (<IP_ADDRESS>)  15.656 ms  16.098 ms  16.098 ms
 6  bu-ether16.tustca4200w-bcr00.tbone.rr.com (<IP_ADDRESS>)  17.233 ms  16.323 ms  16.171 ms
 7  0.ae1.pr0.lax10.tbone.rr.com (<IP_ADDRESS>)  12.216 ms
    0.ae5.pr0.lax10.tbone.rr.com (<IP_ADDRESS>)  11.402 ms
    0.ae1.pr0.lax10.tbone.rr.com (<IP_ADDRESS>)  11.323 ms
 8  be3056.ccr41.lax05.atlas.cogentco.com (<IP_ADDRESS>)  12.135 ms  13.295 ms  16.824 ms
 9  be3032.ccr21.lax01.atlas.cogentco.com (<IP_ADDRESS>)  18.262 ms
    be3033.ccr22.lax01.atlas.cogentco.com (<IP_ADDRESS>)  13.633 ms
    be3032.ccr21.lax01.atlas.cogentco.com (<IP_ADDRESS>)  12.758 ms
10  be2932.ccr22.phx02.atlas.cogentco.com (<IP_ADDRESS>)  24.365 ms
    be2931.ccr21.phx02.atlas.cogentco.com (<IP_ADDRESS>)  23.291 ms
    be2932.ccr22.phx02.atlas.cogentco.com (<IP_ADDRESS>)  23.765 ms
11  be2929.ccr21.elp01.atlas.cogentco.com (<IP_ADDRESS>)  31.375 ms
    be2930.ccr21.elp01.atlas.cogentco.com (<IP_ADDRESS>)  32.035 ms
    be2929.ccr21.elp01.atlas.cogentco.com (<IP_ADDRESS>)  33.777 ms
12  be2928.ccr42.iah01.atlas.cogentco.com (<IP_ADDRESS>)  48.615 ms
    be2927.ccr41.iah01.atlas.cogentco.com (<IP_ADDRESS>)  49.630 ms
    be2928.ccr42.iah01.atlas.cogentco.com (<IP_ADDRESS>)  49.311 ms
13  be2443.ccr22.dfw01.atlas.cogentco.com (<IP_ADDRESS>)  49.423 ms
    be2441.ccr21.dfw01.atlas.cogentco.com (<IP_ADDRESS>)  49.202 ms
    be2443.ccr22.dfw01.atlas.cogentco.com (<IP_ADDRESS>)  49.494 ms
14  be2939.rcr21.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  52.814 ms
    be2938.rcr21.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  50.845 ms
    be2939.rcr21.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  50.356 ms
15  te0-0-2-1.nr11.b028597-0.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  52.157 ms  52.073 ms
    te0-0-2-0.nr11.b028597-0.dfw04.atlas.cogentco.com (<IP_ADDRESS>)  51.462 ms
16  <IP_ADDRESS> (<IP_ADDRESS>)  51.169 ms  51.560 ms  51.830 ms
17  <IP_ADDRESS> (<IP_ADDRESS>)  51.564 ms  51.622 ms  51.293 ms
18  * * *

1/4 mile away my work's connection operates fine (they are most definitely not TWTC).
from there:
traceroute
Tracing route to diablo.msys2.org [<IP_ADDRESS>]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  <IP_ADDRESS>
  2     1 ms     1 ms     1 ms  <IP_ADDRESS>
  3     1 ms     1 ms     1 ms  <IP_ADDRESS>
  4     2 ms     2 ms     2 ms  1-1-5.mpr2.lax12.us.zip.zayo.com [<IP_ADDRESS>]
  5     2 ms     2 ms     2 ms  ae14.cs1.lax112.us.eth.zayo.com [<IP_ADDRESS>]
  6     2 ms     2 ms     2 ms  ae1.mpr2.lax12.us.zip.zayo.com [<IP_ADDRESS>]
  7     2 ms     2 ms     2 ms  be6461.ccr41.lax05.atlas.cogentco.com [<IP_ADDRESS>]
  8     3 ms     2 ms     3 ms  be3033.ccr22.lax01.atlas.cogentco.com [<IP_ADDRESS>]
  9    14 ms    14 ms    14 ms  be2932.ccr22.phx02.atlas.cogentco.com [<IP_ADDRESS>]
 10    22 ms    22 ms    22 ms  be2930.ccr21.elp01.atlas.cogentco.com [<IP_ADDRESS>]
 11    36 ms    36 ms    36 ms  be2928.ccr42.iah01.atlas.cogentco.com [<IP_ADDRESS>]
 12    36 ms    36 ms    36 ms  be2443.ccr22.dfw01.atlas.cogentco.com [<IP_ADDRESS>]
 13    37 ms    37 ms    37 ms  be2939.rcr21.dfw04.atlas.cogentco.com [<IP_ADDRESS>]
 14    37 ms    37 ms    38 ms  te0-0-2-1.nr11.b028597-0.dfw04.atlas.cogentco.com [<IP_ADDRESS>]
 15    38 ms    37 ms    38 ms  <IP_ADDRESS>
 16    44 ms    56 ms    38 ms  <IP_ADDRESS>
 17    37 ms    37 ms    37 ms  <IP_ADDRESS>

@erichiller
I have old TWC at home as well. I contacted them (in case it was my specific dynamic IP) and apparently I won't be assigned a new IP until next month.
What's strange is that we're all getting to the same next-to-last node in the route, and then it either fails or succeeds to get a response from diablo.msys2.org.
@elieux
The fact that it only fails when it gets to diablo.msys2.org is what makes me think that perhaps you could do something about it! What that thing is, I don't know, but I don't know how that server is configured either. Perhaps an over-zealous blacklist? Maybe we happen to have dynamic IPs that used to be assigned to people who actually belong on a blacklist?

@dakotahawkins, yeah, that is plausible. I'll ask around and see what I can do.

So far it doesn't seem like anything's wrong with/on the server. The hosting company will be adding another uplink connection from another ISP in ~2 months, which -- I hope -- will work around any Cogent-related issues.

@elieux If you think the server logs something that might be useful I could always try to ping it while you look. Very weird for it to get all the way to the end of the route and fail, but I guess it could be either the next-to-last hop failing to hit the server or the server refusing the connections.

I have the same issue.
With ISP1,
 11     *      273 ms     *     ionity-11.edge3.dal006.pnap.net [<IP_ADDRESS>]
 12   270 ms   270 ms   270 ms  <IP_ADDRESS>
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *      185 ms  if-ae-32-2.tcore2.NTO-New-York.as6453.net [<IP_ADDRESS>]
 18     *      201 ms   195 ms  if-ae-12-2.tcore1.N75-New-York.as6453.net [<IP_ADDRESS>]
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28   244 ms     *        *     edge3.ae1-edgenet.dal006.pnap.net [<IP_ADDRESS>]
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

With ISP2,
 15   268 ms   268 ms   266 ms  ionity-11.edge3.dal006.pnap.net [<IP_ADDRESS>]
 16   270 ms   270 ms   269 ms  <IP_ADDRESS>
 17   280 ms   272 ms   280 ms  <IP_ADDRESS>

Both tests, at the same location. The fact that it fails at the endpoint suggests something to do with diablo.msys2.org

It's NOD32!

haha thats global issue

Experiencing similar results here on TWC in so-cal. Any updates on what's causing this?


bash: use default PATH in FHS environments

If bash is executed within an environment where PATH is not set, it uses
the DEFAULT_PATH_VALUE compiled into bash to set PATH. In nixpkgs we set
this to /no-such-path by default. This makes sense in a nixpkgs/NixOS
environment since paths like /bin or /usr/bin should not be used.
However, when bash is used inside an FHS environment, this produces
results that differ from distributions which follow the FHS standard.
Before this change:
$ steam-run env -i /bin/bash -c 'echo $PATH'
/no-such-path
After this change:
$ steam-run env -i /bin/bash -c 'echo $PATH'
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

I encountered an issue caused by this when trying to build Android 12 inside a fhs-userenv environment.  Somewhere deep in the android build system it clears the environment and depends on bash using its normal DEFAULT_PATH_VALUE to reset the PATH to something usable.
If forFHSEnv is not set, it should not change the bash derivations, and so should not require a mass-rebuild.
CC @peti @yegortimoshenko

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 126448 at 82fe6ba3 run on x86_64-linux 1

1 package marked as broken and skipped:

ovftool

77 packages skipped due to time constraints:

Sylk
altair
android-studio (androidStudioPackages.stable)
androidStudioPackages.beta
androidStudioPackages.canary
androidStudioPackages.dev
anki-bin
appimage-run
apple-music-electron
arduino-ci
...

11 packages built successfully:

dropbox
dropbox-cli
flutter (flutterPackages.stable)
kodiPackages.steam-launcher
mate.caja-dropbox
protontricks
steam
steam-run
steam-run-native
steam-tui
steamcmd

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/add-bin-bash-to-avoid-unnecessary-pain/5673/53

@jonringer can you take a look at this?

I wonder if we should expose this as something like bashInteractiveFHS or something in all-packages.nix

@jonringer  I fixed the merge conflicts and took your suggestion to make a bashInteractiveFHS.


Modify regex to match json that includes newlines.

This fixes issue #20
What seems to happen is that some queries return a single line, which causes no issues.
plugin:auto-classifier:587 {"reliability": 0.8, "output": "journal"}

Other times, it returns the same content but in a JSON format to include newline characters.
plugin:auto-classifier:587 {
"reliability": 0.9,
"output": "linux"
}

The raw response comes in the form of a (multi-line) string and not proper JSON. The existing regex does not allow for the newline characters, which is what I changed.

Hello @gravityfargo, I am deeply thankful for your PR, which notably is the first for this plugin.
The modification you've made to the regex not only addresses issue #20 but also seems to resolve several unknown errors.
Your PR has been approved. Thank you for your contribution!
Best,
Hyeonseo.