CodeQL alert: Incomplete string escaping or encoding

Problem Description
In a forked version of this repo, we noticed that CodeQL has a finding: Incomplete string escaping or encoding. Perhaps this can be addressed so that consumers of this repo don't have to remediate it themselves.

A possible way to fix this is to change the code to this.
const regexptex = this.glob.replace(/\\/g, '\\\\').replace(/\//g, '\\/').replace(/\?/g, '([^\\/])').replace(/\./g, '\\.').replace(/\*\*/g, '.+').replace(/\*/g, '([^\\/]*)')

I'll take a look and merge the fix.

Hi – just checking back on this. Were you able to merge a fix?


upgrade: skip dependent check on core versioned formulae

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Requires approval of #12483.
This skips both the outdated and broken linkage check. We could potentially keep the broken linkage part if desired.

Review period ended.


default values for missing layer count in metadata

Like recommended in the issue, we should add documentation to tell that feature can be slicer specific and may need some tweeking


Update actions version in workflow

Line 13:
actions/checkout@v2 to actions/checkout@v3
Line 17:
actions/setup-java@v1 to actions/setup-java@v3
Line 21 & 27:
actions/cache@v1 to actions/cache@v3
This would remove this warning:
Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: actions/checkout, actions/setup-java, actions/cache, actions/cache, actions/cache, actions/cache, actions/setup-java, actions/checkout
I tried to send a PR for the changes but it didn't let me 😄

Hi @bglamadrid !
I noticed one more thing in the workflow. You could cache the java part too if you want.
From Line 18:
        with:
          java-version: 11

You could add cache, like this:
        with:
          java-version: 11
          cache: maven

Source: https://github.com/actions/setup-java
cache: Quick [setup caching](https://github.com/actions/setup-java#caching-packages-dependencies) for the dependencies managed through one of the predifined package managers. It can be one of "maven", "gradle" or "sbt".


Abstract def class methods (e.g. constructors)

At the moment, there seems to be no way to abstract def class methods. This is a bit of a problem, in case you want to guarantee subclasses implement certain constructors! Take this for example:
abstract class Thing
  abstract def self.parse(s : String) : Thing
  abstract def self.construct_somehow(a : Int, b : String, c : Bool) : Thing
end

Right now, that doesn't work, but instead errors out with the error can't define abstract def on metaclass. The best way I can come up with to do something similar in the current version of Crystal is this:
abstract class Thing
  abstract def self.parse(s : String) : Thing
    raise NotImplementedError.new # Or similar
    new
  end

  abstract def self.construct_somehow(a : Int, b : String, c : Bool) : Thing
    raise NotImplementedError.new
    new
  end
end

...But that's runtime (and boilerplate-ey).
I hope there's something I'm missing!

Note that because of abstract class Thing, Thing is abstract so it can't be instantiated:
Thing.new # compile error

However, classes are already "instantiated":
Thing # => Thing

So, abstract methods in abstract types make sense, because they must be defined in concrete subclasses that can be instantiated. That doesn't apply to classes because you can use them without instantiating them.
So in my mind it doesn't make sense to have abstract class methods, and that's why they never got implemented. And in every other statically typed language there's no such thing either.

However, there is very much a legitimate use case for when you'd like subclasses to have the same set of constructors!

Sorry, I don't think this can (or will) be implemented.

FWIW there are other use cases for requiring children to implement a class method other than instantiation.
For example it would be nice if I could have did
abstract struct Athena::EventDispatcher::Listener
  abstract def self.subscribed_events : AED::SubscribedEvents

  ...
end

And in every other statically typed language there's no such thing either.

I know i'm slightly late, but there is such thing in Pascal\Delphi. https://ideone.com/qcrPSw
But they useful there because classes are "first-class ctitizens" in Pascal, so you can do
if random < 0.5 then c := Child1 else c := Child2; x := c.Create;

Rust's interface system, traits, can require implementors to provide static methods:
// abstract struct Foo
trait Foo {
    // abstract def self.bar
    fn bar();

    // abstract def baz
    fn baz(&self);
}

struct A { val: i32 }

// struct Foo < A
impl Foo for A {
    fn bar() {
        println!("bar");
    }

    fn baz(&self) {
        println!("baz: {}", self.val);
    }
}

fn main() {
    A::bar(); // print "bar"
    let a = A { val: 5 };
    a.baz(); // print "baz: 5"
}

This being missing is what prevents the concept of From being convenient in #8511 , which has a similar motivation to this issue

I think we could implement something like this, but if you misuse it you will still get a runtime error.
What I mean is, if you have:
abstract class Parent
  abstract def self.foo
end

class Foo < Parent
  def self.foo; 1; end
end

class Bar < Parent
  def self.foo; 2; end
end

If you do:
(Foo || Bar).foo

then the type of Foo || Bar, because they have Parent as a common type, is Parent.class+, that is, Parent or any of its subclasses. In this case the above code will work, but you could also have this:
(Parent || Foo || Bar).foo

In this case the type of the parenthesized expression is the same: Parent.class+. But the expressions' result is Parent and foo isn't defined for it (it's abstract), so I guess we can make it raise at runtime saying "foo is abstract for Parent".
This is still a bit better than the current state because it forces you to implement those abstract methods, and there's a very little chance that you'll end up misusing them.
Thoughts?

That sounds fine to me; at least, it makes sense from a user's perspective. I suppose this is somewhat consistent with other runtime type operations, such as
expr = "1" || 2
expr.as(Int32) # Unhandled exception: cast from String to Int32 failed

Although I'm curious about the compiler's understanding of that code; my impression is that the compiler isn't able to semantically block expressions like that containing abstract metaclasses, before they are cast to Parent.class+?
I can't quite imagine a use case that currently exists for handling Parent.class itself at runtime off the top of my head that would prevent making that a compiler error reasonable.
I see that (Parent || Foo || Bar).new.foo is, understandably, already a segfault: https://carc.in/#/r/85fj. This would presumably fix this as well?

Yes, that's already tracked here: https://github.com/crystal-lang/crystal/issues/3835
I once tried to fix it thinking it was easy but it's not. Maybe some day...

For reference, class methods are required on Serializable in the stdlib:

converter: specify an alternate type for parsing and generation. The converter must define from_json(JSON::PullParser) and to_json(value, JSON::Builder) as class methods.

In this case, a Converter module with abstract class method will be useful.

You can, in fact, do this already somehow:
abstract class Thing
  macro inherited
    extend ClassMethods(self)
  end

  private module ClassMethods(D)
    abstract def parse(s : String) : D
    abstract def construct_somehow(a : Int, b : String, c : Bool) : D
  end
end

class ThingImpl < Thing
  def self.parse(s : String) : ThingImpl
    # ...
  end

  def self.construct_somehow(a : Int, b : String, c : Bool) : ThingImpl
    # ...
  end
end

If .parse isn't defined you get:
Error: abstract def Thing::ClassMethods(D)#parse(s : String) must be implemented by ThingImpl.class
And if it returns a Thing instead of ThingImpl, you get:
Error: this method must return ThingImpl, which is the return type of the overridden method Thing::ClassMethods(D)#parse(s : String), or a subtype of it, not Thing

Likewise, for the converter case which does not require actual classes, one could write this:
module JSONConverter(T)
  abstract def from_json(pull : JSON::PullParser) : T
  abstract def to_json(value : T, json : JSON::Builder)
end

module Time::EpochConverter
  extend JSONConverter(Time)

  def self.from_json(pull : JSON::PullParser) : Time
    Time.unix(pull.read_int)
  end

  def self.to_json(value : Time, json : JSON::Builder)
    json.number(value.to_unix)
  end
end

{% Time::EpochConverter.class < JSONConverter(Time) %} # => true

No macro hooks are required here.

The following would be a compilation error if #11190 is applied: (it does not matter whether Parent itself is abstract)
abstract class Parent
end

class Foo < Parent
  def self.foo; 1; end
end

class Bar < Parent
  def self.foo; 2; end
end

(Foo || Bar).foo # Error: undefined method 'foo' for Parent.class (compile-time type is Parent+.class)

Rethinking about this issue, I don't think we need to do anything special here; as long as Parent can possibly appear in a value of type Parent+.class, it is natural to require an explicit definition of Parent.foo. We could use a non-generic ClassMethods module if we really want to exclude Parent and enforce a distinct definition in the subclasses:
abstract class Parent
  module ClassMethods
    abstract def foo
  end

  macro inherited
    extend ClassMethods
  end
end

class Foo < Parent
  def self.foo; 1; end
end

class Bar < Parent
  def self.foo; 2; end
end

Now the following is an error:
(Foo || Bar).as(Parent::ClassMethods).foo # Error: can't cast Parent+.class to Parent::ClassMethods

But this works:
class A
  property! x : Parent::ClassMethods
end

a = A.new
a.x = Foo
a.x.foo # => 1
a.x = Bar
a.x.foo # => 2
a.x = Parent # Error: no overload matches 'A#x=' with type Parent.class

([Foo, Bar] of Parent::ClassMethods).map(&.foo) # => [1, 2]

IMO this is good enough and we don't need to adjust the semantics of abstract defs to allow this to happen.

they useful there because classes are "first-class ctitizens" in Pascal

To me it is the opposite; class reference types there do not reuse the same semantics as regular classes. (Contrast with Ruby's singleton classes.)


Misalignment when pinch-zooming

From https://github.com/Leaflet/Leaflet/issues/4511 by @mgleahy:

Hello all,
I'm trying out leaflet-heat, and would like to work with the 1.0.0-rc1 version of leaaflet.  So far, pretty much everything is working fairly well, except that the pinch zoom of a leaflet-heat layer on a mobile device does not animate with the rest of the map.  It works fine with leaflet-0.7.7.
I'm just wondering if someone knows what I would need to change in the leaflet-heat source to make it play nice with leaflet 1.0.0...any suggestions?
Here's a sample - open it on an iPad, or other touch device...then try a pinch zoom:
http://playground-leaflet.rhcloud.com/tohi/1

This bug still exists. Just open the demo http://leaflet.github.io/Leaflet.heat/demo/ on your mobile phone or tablet and try to pinch zoom (use 2 fingers to move the map around and to zoom in or out with the same gesture). You can see, that the underlaying map acts like it should, but the canvas with the heatmap stays where it was and then jumps to the new location and zoom level only when the fingers are released from the screen.
Does anybody has an idea how to correct this? It used to work fine in older versions of Leaflet.
Any help or a patch is very much appreceated.


Overflow

This pull request resolves #91 .
The pull request is ready to be merged.
The details of the pull request:
The image classifier will raise timeout error when the time limit is too short.
But will not if the classifier already finished training one model.

Pull Request Test Coverage Report for Build 469

17 of 21 (80.95%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.07%) to 96.58%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

autokeras/bayesian.py
1
2
50.0%

autokeras/search.py
2
3
66.67%

autokeras/image_supervised.py
14
16
87.5%

Files with Coverage Reduction
New Missed Lines
%

autokeras/image_supervised.py
1
91.75%

Totals

Change from base Build 467:
0.07%

Covered Lines:
1638

Relevant Lines:
1696

💛  - Coveralls


Add Readme Section

refs #747.  Display the contents of the README on the work show page
Put it in a prominent portion of the page (aka under the description)

We will support text and mark down formats. Need to sanitize the contents of the README

@olendorf Here is the display of a message without a README and the output of a README file.
No README

With a README (unofficial README)

@mtribone  looks great to me.


build: update cairo-vm rev

Stack:

#631
#629
#628
#627
#626
#625
#624
#623 ⬅

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

✓ Commit merged in pull request #631


Add fixit for '-> throws' to 'throws ->'

What's in this pull request?

Update function signature parsing to handle throws between the arrow and the type.
This will fix:
func foo() -> throws Int

to
func foo() throws -> Int

and remove the bogus parse errors that are produced for this now.
Resolved bug number: (SR-1940)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci please test

@swift-ci please test

@swift-ci please test

@gribozavr Good to merge?

LGTM modulo nitpicks!

@gribozavr @jrose-apple Fixed up based on your suggestions

@swift-ci please test


#288 missing osgi headers

Fixing issue where org.simplejavamail.internal.* are not exported in Osgi.
In addition, have Apache Karaf feature available.

Thank you for your effort. Question: is there a reason why you are using a nested a module named karaf-feaure? It deviated from how the other modules are configured in Maven.

Thank you for your effort. Question: is there a reason why you are using a nested a module named karaf-feaure? It deviated from how the other modules are configured in Maven.

For the future development, we could have each module as separate, installable karaf feature, like
|   |-- karaf-feature
|   |-- karaf-feature-auth-socks
|   |-- karaf-feature-dkim
|   |-- karaf-feature-outlook
...

However, current PR doesn't have these submodules. I can also remove the submodule for now.

Ahh, I see. Yes, let's remove the nested module structure until we have multiple modules to nest. You're welcome to perform the change, else I will do it later this week. Thanks.

Released in 8.1.0

Note, that for the next release, whenever that is, I'm renaming the module to karaf-module. Together with artifactGroup, that should be enough (as with the other modules).
So the dependency becomes org.simplejavamail:karaf-module:8.1.x


pre-urldecode causes path parameters to become part of the route

Hi,
It appears that bottle pre-urldecodes the raw path string prior to passing it to the routing engine.
This has a couple of weird quirks and also probably violates the spirit of the HTTP spec relating to path handling (https://tools.ietf.org/html/rfc3986#section-3.3). In particular, this results in path segments consisting of path-like values being hoisted to the top level of the URL for routing purposes, and missing dynamic routes that should match. This prevents the path from being routed correctly, unless there is a :path wildcard filter applied. However, if this filter is applied, the Request.fullpath variable will not contain the correct string and will contain the post-decode "resolved" path.
For example, consider the URL: http://<IP_ADDRESS>:8080/hello/foo%2fbar%2fbaz/world
And the following code:
from bottle import route, run, template, request

@route('/hello/<xmlxpath>/world')
def hello(xmlxpath):
    return template('xmlxpath: {{xmlxpath}}
fullpath: {{fullpath}}',
                    xmlxpath=xmlxpath, fullpath=request.fullpath)

run(host='localhost', port=8080)

The expected behavior is that the hello function will be called and that the following will render:
xmlxpath: foo/bar/baz
fullpath: /hello/foo%2fbar%2fbaz/world

The actual behavior is that the request 404s.
If we "fix" the code by adding a :path filter to the <xmlxpath> wildcard, as below, the same output is expected.
from bottle import route, run, template, request

@route('/hello/<xmlxpath:path>/world')
def hello(xmlxpath):
    return template('xmlxpath: {{xmlxpath}}
fullpath: {{fullpath}}',
                    xmlxpath=xmlxpath, fullpath=request.fullpath)

run(host='localhost', port=8080)

However, the actual output is the following:
xmlxpath: foo/bar/baz
fullpath: /hello/foo/bar/baz/world

In the above, the fullpath contains a URL-decoded <xmlpath> segment value, which does not preserve the semantics of what was actually requested. However the issue goes deeper than this. Instead, consider the URL: http://<IP_ADDRESS>:8080/hello/foo%2fbar%2f..%2f..%2fbaz/world
The expected result of the page is the following:
xmlxpath: foo/bar/../../baz
fullpath: /hello/foo%2fbar%2f..%2f..%2fbaz/world

However, the actual result is the following:
xmlxpath: foo/bar/../../baz
fullpath: /hello/baz/world

In this case, not only is the path segment not preserved, it is pre-resolved in the fullpath.
Based on the RFC's definition of a path segment, both in structure and purpose, this behavior is troublesome as path segments are to be considered "considered opaque by the generic syntax." Furthermore, it goes on to state "URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents."
While it would be tempting to say that ensuring the Request.fullpath value has the actual full path of the request would be enough to fix this, the pre-urldecoding behavior is already arguably "wrong" given the spec — most other web frameworks' (across languages) routing behaviors for this sort of route parameter syntax follow the spec as described — and :path behavior should be the default.

This is an WSGI, or a general server issue.
If you try to access request.environ['PATH_INFO'], which holds an unaltered copy of the WSGI environ['PATH_INFO'] you get the decoded path aswell.
WSGIref decodes the path before passing it into environ['PATH_INFO'].
In fact, the WSGI spec demands it (kind of like).
This is a known and well discussed decoding issue.
See PEP 333 - Unicode issues or
Python bug tracker - Add advice about non-ASCII wsgiref PATH_INFO or
django doesn't encode request.path correctly in python3.
A workaround could be encoding  % aswell by replacing it with %25. %2F then would become %252F.
Or you could do something like:
from bottle import route, run, template, request
from urllib.parse import quote

@route('/hello/<xmlxpath:path>/world')
def hello(xmlxpath):
    return template('xmlxpath: {{xmlxpath}}
fullpath: {{fullpath}}',
                    xmlxpath=quote(xmlxpath, safe=""), fullpath=request.fullpath)

run(host='localhost', port=8080)

This will give you the desired result of:
xmlxpath: foo%2Fbar%2Fbaz
fullpath: /hello/foo/bar/baz/world

You could also do this in your own filter, that acts the same as :path but returns the matched part URL encoded.
(See Bottle docs - Routing for details)

Yes, @provinzkraut is correct. WSGI does not provide any way for bottle to access the raw path.
You are also correct, by the way. The RFC clearly states:

URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent.  Percent-encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications.  Thus, characters in the reserved set are protected from normalization and are therefore safe to be used by scheme-specific and producer-specific algorithms for delimiting data subcomponents within a URI.

But unfortunately, WSGI (and some famous HTTP load-balancers and reverse proxies as well as most web frameworks) do not preserve encoded characters after the URI was successfully split into its components. nginx for example will also decode %2F in the path before passing the request to backend services by default.
I'd recommend not relying on percent-encoding too much. You will run into trouble all the time, not only with WSGI or Bottle, but with load-balancers and reverse-proxies as well.
(Closed because this cannot be solved in Bottle)


Fix optional strict by not assigning undefined value to optional properties in object(Async) function

This PR should fix the issue #131.
The main issue wasn't in the strict() (or strictAsync()) function but more in the object() (or objectAsync()) function that always assigned the value to a property even when the value was undefined and the property was "optional".
The PR fix both the object() and objectAsync() function by not assigning optional properties when the value is undefined.

Thank you! I will check your changes in the next days.

I think that your implementation still leads to problems. If a person now passes a property with the value undefined as input, it will be filtered out in object, causing strict to still throw an error. Also, I'm against making a change in different places when really only strict is affected. I think it is easiest to exclude undefined keys at strict. I will do the implementation and add you as co-author.


Suppress registration exceptions by service type

I've been experimenting with DryIoc on top of Sitecore, which has hundreds of its own services registered with the built-in Microsoft.Extensions.DependencyInjection container. Out of the box, Sitecore has three registrations that fail the shorter reuse lifespan rule. To get DryIoc to work, it seems there are two options: re-register Sitecore's services to pass the rule, or disable the rule for the Container altogether. Neither option is ideal--I'd rather be able to tell DryIoc to suppress the exception for the offending services.
Is it possible to suppress rules per service registration with DryIoc?

Hi @coreyasmith, which version did you use? In case of v4 preview there is a flaw with lifetimes. #77

Hi @coreyasmith, which version did you use? In case of v4 preview there is a flaw with lifetimes. #77

In my case, Sitecore is registering singleton services that depend on scoped services, which should indeed throw an exception. I'd just like to suppress the exception for those services and have DryIoc continue to validate my other registrations.

@coreyasmith, Check out the new Today's versions. Let me know if they helped.

Closing as there was not any updates.


#94 improve error message

Add a NotFoundConfoundException class and use it to collect all the unfound params and raise a final error with the list of all not found params rather than just the first one.

Ok I realised I didn't get the codeclimate issue, I saw refactoring and thought it was just some styling issue, so I just removed some empty lines that didn't seem to respect PEP8.
But actually the issue is about cognitive complexity of the _load_single method. Looking at their definition of cognitive complexity it seems to be related to all the try and catch that I added, but I don't see a more explicit way to handle it. We could return the not found params arrays all the way back from the _check_params method but that seems way more clunky to me, whereas exceptions are made just for this kind of situations.
A way of making the method shorter (but not necessarily more readable) would be to wrap all the
if "<strat>" in self.strategy:
            try:
                confounds_<strat> = _load_<strat>(confounds_raw, self.<strat>)
                confounds = pd.concat([confounds, confounds_<strat>], axis=1)
            except ConfoundNotFoundException as exception:
                not_found_confounds += exception.params

blocks in a for loop. In my opinion that would be better because it would remove the duplicate code of the try/catch and concat but codeclimate might not like it since it would be less explicit.

A way of making the method shorter (but not necessarily more readable) would be to wrap all the
blocks in a for loop.

The reason why it's not a long for loop is because the arguments of the _load_xxx vary depending on the function. I guess it would be possible to add all the _load_xxx functions as attributes to the Confounds class, and use self as an argument and then access all the parameters as attributes of Confouds. Then there could be a loop over all elements of the global variable all_confounds.
I have made a suggestion for using a decorator which, if it works, will solve the codeclimate issue.
If you want to try to refactor the code in a for loop as well, go for it. Otherwise I'll try as a separate issue.
It will become handy when we add ica-aroma and censoring to the list of methods, to keep the code concise.

Yay, all good !

The only change I'm not totally sure about is to put _load_high_pass as a function and not a method of the Confounds class. It was required by codacy because _load_high_pass didn't use self. However it felt better to put all the load functions in the same place.
It feels even better to have the "All checks have passed" icon though.

@FrancoisPgm I think this is ready to merge, but it includes a major refactoring. So I think I am going to try and merge PRs #99 #96 and #100 before this one. This means you  will need to merge the other PRs in your fork, fix the conflicts and refactor the new bits on ICA. Is that OK?

Ok I'll try to do that.

Tell me if you need some help with the conflicts, I am also happy to take over and deal with the merge myself.

So.... this merge implied some pretty big refactoring. This was mostly with the parts of the code that had to do with the other PR and the added support for censoring, ica and improved compcor. The main notable change is that I had to change completely the tests. I created by hand a test file with missing params and keywords. I put a single test for both things missing at the same time. The reason why I had to do this is that I dropped support for data frames. For compcor we need the json file, so it's not possible to directly transform a dataframe.
Regarding the warnings: I manually disabled the codacy issues. It wants _load_ica and another one as functions rather than methods of the Confounds class. But there is a neat pattern where all the _load_{confound} method are exposed in the class. I really like that, and I don't care it could be a function.
For the codecov warning, the lack of coverage relates to the censoring method, which is not currently tested.

It's done, merging in main!!
Congrats and huge thanks @FrancoisPgm I love the new class structure.
@all-contributors add @FrancoisPgm for test and data


Release fix for integration with Mail < v2.6.4

There seems to be a great deal of people running into the issue fixed by #200, so I would like to release the fix as soon as possible. However I do not currently have push access on Rubygems.
See the following PRs for more details:
https://github.com/michaeldv/awesome_print/pull/200
https://github.com/michaeldv/awesome_print/pull/206

Also see: https://github.com/michaeldv/awesome_print/issues/199#issuecomment-218565362

@michaeldv wrote
@IslamAzab Added you to https://github.com/michaeldv/awesome_print/settings/collaboration as well, please coordinate new version release with the folks there.

@IslamAzab Are you able to see the collaboration page? We have a few fixes in master which have been reported by many people in many different projects and I'm currently unable to push the fixes to rubygems so I'm wondering if you have been given access?

@gerrywastaken I don't think so.

@IslamAzab Thanks for leting me know anyway. :)

I've now pushed this to Rubygems with version 1.7.0. 👍


Add Kosovo & regions

Kosovo administrative districts come from https://en.wikipedia.org/wiki/Districts_of_Kosovo
Closes #31

This has been resolved in the other PR from @EPRenaud.


Use gtest\gmock via find_package

At the moment I see gtest is configured from log archive which is stored in the project root.
It makes troubles in case external package managers. I'm playing with vcpkg at the moment but conan uses similar approach. I'm trying include rsocket-cpp to vcpkg ( https://github.com/microsoft/vcpkg/issues/10705  ) and gtest is already available via find_package but rsocket-cpp cannot find it automatically.

I would like to know the reason why deps (folly and gtest) are installed manually. with vcpkg both folly and gtest can be found via find_package.


Server doesn't come up when one of the dynomite node is unreachable

I have a setup with one instance of conductor server and 3 dynomite nodes. If I make one of the node as unreachable, then conductor server doesn't come up. Is it a requirement that all dynomite nodes in the configuration should be reachable for the server to come up? The server logs indicate that it keeps trying to prime connection to all 3 nodes, and one of them fails.

During the server initialization, all dynomite nodes should be available.

Thanks for confirming.


not close?

cannot close
I did SerialPort.close();
But the COM port cannot be closed

SerialPort.close() Undefined

It should be my global variable. Thank you

I executed it in another method, so I couldn't find the variable. It should be


[Runtime] 4.2 - Change protocol conformance scanning to use a concurrent array rather than a locked vector.

This cherry-picks #16254 and #16794 (which fixes #16254) into 4.2.
This eliminates the "gross" unlock/lock dance around getWitnessTable.
rdar://problem/37173156 and rdar://problem/40484362

@swift-ci please test

Looks like you broke Linux builds with this (something not including std::vector, at the very least). Not sure how the tests would have passed—maybe a 16.04 vs. 16.10 difference?


Revert "fix: update to use common wasm builder"

This reverts commit bb0e131de2c2c1bb5550f5970d71bf09d3721f9d.
@mhdawson I'd revert this until we can make it work

Revert the commit fixes the deps updater https://github.com/nodejs/amaro/pull/112


How to analyze the Longitudinal data using aa_5

Hi,
I am working in Jonathan Peelle's lab.
Now I want to analyze fMRI imaging data from a single subject in different days. I saw that the longitudinal measurement has been added to the aa version 5 in the change log. But I can't find more details either on the website or the discussion forum. Could you please describe or give an example of how to analyze the longitudinal data in the user script?
Thank you very much.
Zhenchen

https://github.com/rhodricusack/automaticanalysis/blob/v5-stable/examples/aa_user_fmri_multi.m


Refact CheckApplicability function to support S/MIME and Code Signing later

I don’t support doing that is this change, but I also think we should hold off on that refactoring until we get to that point. That seems like a lot of churn for unclear benefit, at least at present, although I can agree with you in the hypothetical.
One of the issues we had with QWACs is that it’s not merely sufficient for something to be a certificate; lints need an invested community of maintainers who are familiar with the specifications, the interpretations, and the use case. I suspect few, if any, of the maintainers are interested in Code Signing. The S/MIME WG activity seems too early to tell if it will produce something useful for Internet mail clients, given that right now it appears to be narrowly focusing on Enterprise/Gov’t cases and/or letting them dominate the use cases. As such, it may end up that those Guidelines aren’t adopted by major mail clients, or their audits not accepted/not seen as relevant, if they don’t end up being useful, and that seems like it could similarly impact the ability to support or maintain lints.
Given that historically ZLint has exclusively focused on TLS certs, I think the broader meta-question about other profiles is one we should hold off on, until we’ve got a body of lints and active maintainer interest. In the worst case, the structure of lints was designed to facilitate mixins of other lints in the interim, and wouldn’t be (negatively) affected by the current checks.
Originally posted by @sleevi in https://github.com/zmap/zlint/pull/472#discussion_r492062014

Meta commentary: It's not super clear to me what the "ask" of this issue is. The description seems to be tied into the the discussion from #472 in a way that's somewhat challenging to disentangle. I've put a "question" label on this for now but it might be easier to categorize with an updated stand-alone description


[v2 Genesis] Create CI release step to create and update OpenUPM branch contents

Is your feature request related to a problem? Please describe.
With the move to automate building and distrubution of the Genesis.Plugin nuget package, I'd also like to automate updating the OpenUPM package as well. This would make it easier to create and issue releases.
Describe the solution you'd like
There are a few steps needed here:

JCMG.PackageTools should be updated to handle CLI updating and execution of package updates.
An additional GitHub workflow step should be created to execute this package update step, including checking in updates on develop and the release branch.

This has been completed; whenever the VersionConstants.cs file changes as part of updating the Unity package version a Github Action will kick off to update the OpenUPM release branch.


user setup right-side dropdowns

These are a bit confusing while disabled.  Perhaps hide until they are useful?

OK they are now hidden until a csv file has been selected.


graphical glitch.

Hello i am using freeRDP with remmina and wen i conect to a remote desktop session i am unable to do anything as the whole desktop glitches. moving my mouse over things will show them instead of being invisible. the login screen stays stuck in the background overlaping anything. the right click menu stays stuck on screen. this is all visual as with windows it self there is no such problems what so ever
Steps to reproduce the behavior:
start any RDP session
Screenshots
https://imgur.com/a/WZiHaiY a giff that shows it all
Application details
freerdp-git 2.0.0.r540.g2c5da24cb-1
problem also with freerdp

Output of xfreerdp /buildconfig

This is FreeRDP version 3.0.0-dev (2c5da24cb)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=OFF WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=TRUE WITH_OPENH264=TRUE WITH_OPENH264_LOADING=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PROXY=ON WITH_PROXY_MODULES=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VAAPI=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=ON WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          Release
CFLAGS:              -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -fno-omit-frame-pointer -DWINPR_DLL
Compiler:            GNU, 10.2.0
Target architecture: x64

OS version connecting to (server side)
Windows 10 pro and windows 10 education

Environment (please complete the following information):

OS: Arch linux  Kernel: 5.4.87-1-lts

Architecture: amd64

duble posted by me accidentally

duble posted by me accidentally


Test failling

Hi
I am trying to package pyhton-email_reply_parser in Fedora repos but %{__python2} setup.py test and %{__python2} setup.py test fails :(

This should be resolved, all tests are currently passing on travis


CLIMATE-762 Automate the linking of the frontend directory from the backend directory.

CLIMATE-762

Automate the linking of the frontend directory from the backend directory.

If we can separate these PR's into individual ones then I think we can begin to merge some of your contributions into master @MichaelArthurAnderson thank you

@lewismc I see four separate branches and pull requests in my git.
Are you seeing a single big request?
https://github.com/apache/climate/pull/465
https://github.com/apache/climate/pull/468
https://github.com/apache/climate/pull/469
https://github.com/apache/climate/pull/470
https://github.com/MichaelArthurAnderson/climate/tree/CLIMATE-762
https://github.com/MichaelArthurAnderson/climate/tree/CLIMATE-917
https://github.com/MichaelArthurAnderson/climate/tree/CLIMATE-826
https://github.com/MichaelArthurAnderson/climate/tree/CLIMATE-940


update bcosRegister

Codecov Report

Merging #91 into release-rc4 will decrease coverage by 0.28%.
The diff coverage is 0.00%.

@@                Coverage Diff                @@
##             release-rc4      #91      +/-   ##
=================================================
- Coverage          39.34%   39.05%   -0.29%
  Complexity           368      368
=================================================
  Files                 48       48
  Lines               3637     3664      +27
  Branches             328      332       +4
=================================================
  Hits                1431     1431
- Misses              2105     2132      +27
  Partials             101      101

Impacted Files
Coverage Δ
Complexity Δ

...k/wecross/stub/bcos/custom/RegisterCnsHandler.java
3.92% <0.00%> (-4.42%)
2.00 <0.00> (ø)

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 319da55...0bcb6ce. Read the comment docs.


Additional SMILES Dialects

SMILES dialects not currently covered by the introduction go here.

Jmol SMILES and Jmol SMARTS: specifications and applications

superset, so doesn't address any of the problems in OpenSMILES
oligonucleotide with 100 BP
proposal: C%(123)

Others:

CXSMILES


Add configurable prefix to all Job Service table names (BATCH-185)

These changes add a new configuration setting for Job Service, called tablesPrefix, which makes the creation and usage of tables in Job Service's database to have a common prefix. For example, if tablesPrefix: "test_" is set in the configuration file, the jobservice table will then be named test_jobservice. All table creation and queries will use the prefix.
Other changes:

add new Job Service config setting tablesPrefix
change all SQL strings that reference Job Service tables to be constructed
dynamically, based on the tablesPrefix configuration value (default is an empty string).
various data/function renaming per suggestions from Geoff Wilson:  'sqlJobRepo' to just 'jobRepo',
'JSRepoPostgres' is now 'RepositoryPostgres', WithSqlServiceRepo() is now WithRepository().
shorten repository Setup() function by coalescing all table and index creation/manipulation
to a slice of strings, which we loop through to execute
rename 'log' object to 'logger', to remove warning about name collision with the Go 'log' package.

Fixes https://gr-oss.atlassian.net/browse/BATCH-185
┆Issue is synchronized with this Jira Task by Unito

Closing this PR - we will be using separate databases within the Postgres instance to do isolation of tables between JS and Airflow and/or other apps in the same db instance.


Laravel 5.5 support

Laravel 5.5 support
Removed broken OAuth2 provider with tests
New github issue template
StyleCI fixes
Dingo Router extends form the Illuminate route

Check. All good. Merge and I'll test it.

There's no guarantee there no breaking change between Route for Laravel 5.1, 5.2, 5.3, 5.4 and 5.5.
You sure want to extends and at the same time supports such varies version?

First thing first we need to support Laravel 5.5. after this release. I'll work on below 5.5. at the moment it's too much. If someone wants to use the package against 5.4 and below beta8 is there

yes @thilanga  👍


Consider upgrading to Logback 1.2.7 or later

Due security analysis reported on users' channel

Fixed.


Use of Write-Prompt leads to wrong colors in Windows Terminal

System Details

posh-git version/path: 1.0.0 beta4 ~\Documents\PowerShell\Modules\posh-git\1.0.0
PowerShell version: 7.1.0
Git version: 2.27.0.windows.1
Operating system name and version: Microsoft Windows NT 10.0.19041.0

Issue Description
This is probably not directly caused by posh-git, but I ran into it while setting up posh-git and I since I'm new to PowerShell and Windows Terminal, I don't know how to solve it.
The issue is that posh-git does not seem to respect the color scheme set in Windows Terminal. It always seems to use the default colors.
I broke down the issue to a difference between Write-Host and Write-Prompt. The former uses the colors from the color scheme, while the latter seems to use the default colors. See below (note that I print the working directory myself with Write-Host, therefore it uses the correct blue):

I tried working around this by extracting the relevant info from the status returned by Get-GitStatus but I'd end up replicating most of posh-git, so I thought I'd ask here first. Any hints or pointers would be appreciated!

posh-git favors named HTML colors over Console colors. Try:
Write-Prompt -ForegroundColor ([ConsoleColor]::Blue) ABCDEFG
Write-Prompt -ForegroundColor ([ConsoleColor]::Dark) ABCDEFG

This is why we use [ConsoleColor] for the various default settings:
https://github.com/dahlbyk/posh-git/blob/4a8cda0bceb6e5c96c177ba430af662912353de3/src/PoshGitTypes.ps1#L230-L257

Yes, this helps! Thanks a lot for the pointer 😃


WIP: Mpi/crocoddyl topic/action unittests - [closed]

In GitLab by @MaximilienNaveau on Jun 23, 2019, 11:02
Merges mpi/crocoddyl-topic/action_unittests -> cpp_devel
This is what happened:

add the action-num-diff.cpp
implement the test-action.cpp for all current action implementation
rename files to fit the states pattern: unycle.cpp -> action-unycle.cpp, etc.

In GitLab by @cmastalli on Jun 28, 2019, 13:31
@MaximilienNaveau I didn't notice this PR earlier
Unfortunately I need to close it because there are plenty of modifications already done in my commits few days ago (i.e. variable naming).
What I suggest if the follows:

I create a PR with my changes.
We merge 1
You create a PR only with num-diff stuff, (don't forget to format the num-diff code).

Sorry for the inconvenient.

In GitLab by @cmastalli on Jun 28, 2019, 13:31
closed


[Feature Request] Master password

I don't really feel comfortable keeping my private key unencrypted on my machine- as of right now the only NIP-07 extensions with this feature are BTC wallets, and I have no desire to use BTC/LN
I don't think I'm alone in wanting this. I'd PR the feature myself, but I unfortunately I've never worked with JS or React

So you are thinking of a master password that you would have to enter each time you open the extension? or each time you sign?
I think this is related to #13


Does not update the aws-auth for newly created cluster.

I am trying to create a new EKS using terraform-eks official module, and to ease the pain of creating new aws-auth configmap I was trying to use this module. But since I have multiple clusters in my kube-config, this module updates the configmap of my current-context and not the newly created EKS. Is this the expected behavior?

I would like to clarify that the aws-auth configmap declares which IAM resources can authenticate to the EKS cluster. On the other hand, the local ~/.kube/config describes which IAM credentials to use with the k8s client. Assuming your aws-auth grants you IAM user/role, then you can use the AWS CLL to update your kube config:
$ aws eks update-kubeconfig --name ex-basic --profile my-aws-credentials-file-profile

I understand, but that's not the issue. Let me explain. I am creating a new EKS and I have an eks-auth.tf which basically uses this module to add a new IAM role to the configmap. When I do the terraform apply, the cluster creation happens as usual, but it updates the aws-auth configmap(with additional settings using this module) of the current-context on my machine which is " not " this cluster.
If I remove the kube-config from my machine and try to create the cluster from scratch, it gives me the following error with this module :
kube-system/aws-auth failed to create kubernetes rest client for update of resource Get "http://localhost/api?timeout=32s": dial tcp [::1]:80: connect: connection refused

So, do I need to first create the cluster, add it to my kube-config and switch to that context and then do the terraform apply for this module?

let me break down the order of operations:

Pass aws credentials to aws provider.
The eks module creates the EKS cluster .
A aws_eks_cluster_auth data resource retrieves STS credentials for the EKS cluster.
Pass the STS credentials to the kubernetes provider.
The eks-auth module will use the kubernetes provider to configure the aws-auth configmap on the cluster.
run aws eks update-kubeconfig ... to update you local ~/.kube/config to connect to the kubernetes cluster endpoint.

This is demonstrated in the basic example. This order of operations is not unique to this module. The same can be seen in the eks module examples. you can verify order in which these events occur in the test.logs.

This is exactly what I am doing. But it would still update the configmap of a cluster existing on my machine and not the one I am trying to create and update the changes for.

If creating multiple eks cluster in the same terraform run, then you will need to use provider aliases. Please see this closed issue for more information.

If that doesn't fix you issue then you will need to share your terraform because I am not able to reproduce.

This is exactly what I am doing. But it would still update the configmap of a cluster existing on my machine and not the one I am trying to create and update the changes for.

ahh i think I know the issue. The example is indeed broken. Since the kubernetes provider does not currently have patch functionality (that is soon to change with https://github.com/hashicorp/terraform-provider-kubernetes/pull/1671#issuecomment-1086183819), the current version of this module uses the kubectl provider. This provider takes the exact same arguments as the kubernetes provider. For example:
provider "kubectl" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority[0].data)
  token                  = data.aws_eks_cluster_auth.cluster.token
}

I will fix the examples, thanks for bringing this to my attention!

the example is fixed: https://github.com/aidanmelen/terraform-aws-eks-auth/blob/main/examples/basic/providers.tf

Thank you! It seems to work now after adding the kubectl provider.


Bug with parameter renaming in plot_dependence_functions

I'm submitting a ...

[x] bug report
[ ] feature request
[ ] code improvement request

Expected behavior
How should it work (with the bug fixed or the feature implemented)?
Parameter name should be renamed from "alpha" to $\alpha$" when plot_dependence_functions is used.
Actual behavior
How does it currently work (with the bug causing problems or without the feature)?
Value error is thrown:
ValueError:
$lpha$
^
Expected end of text, found '$'  (at char 0), (line:1, col:1)
Screenshot

Steps to reproduce the problem (how to see the actual behavior)
Run this script:
import matplotlib.pyplot as plt
from virocon import (get_OMAE2020_Hs_Tz, get_OMAE2020_V_Hs,
GlobalHierarchicalModel, plot_dependence_functions, read_ec_benchmark_dataset)
file_path = "datasets/D.txt"
sample = read_ec_benchmark_dataset(file_path)
dist_descriptions, fit_descriptions, semantics = get_OMAE2020_V_Hs()
model = GlobalHierarchicalModel(dist_descriptions)
model.fit(sample)
par_rename = {"alpha": "$\alpha$", "beta": "$\beta$"}
plot_dependence_functions(model, semantics, par_rename)
plt.show()
This script is available at: https://github.com/ahaselsteiner/2020-paper-omae-hierarchical-models/blob/master/produce_error.py

I just figured out that this is not a bug, I shoud have used raw strings par_rename = {"alpha": r"$\alpha$", "beta": r"$\beta$"}.
Nevertheless... as I ran into this, we could check whether the values are raw strings and if they are not we could convert them into raw strings.

It is not possible to tell raw strings and normal strings apart, see e.g.: https://stackoverflow.com/a/5915971
raw strings are just syntactic sugar, so one does not have to escape special characters.
What we possibly could do is catch that ValueError and raise another Exception that makes the mistake more clear. (Though that might make it harder to debug other errors that cause a ValueError)
Alternatively we could a Note/Warning to the user guide.


Bug: Application filter not working based on environment selection

📜 Description
Application filter not working based on environment selection.
👟 Reproduction steps

Deploy multiple applications with multiple pipelines under same project.
Now try to add users by selecting specific environment you will see the application which is not even in this env
Now ask that user to open any application which he don't have the access.

👍 Expected behavior
After selecting environment it should load only those application which is have cd pipeline for these env.
👎 Actual Behavior
RIght now it is listing all the application created on selected project not checking the environment selected.
☸ Kubernetes version
1.21
Cloud provider

AWS KOPS

🌍 Browser
Chrome
🧱 Your Environment
No response
✅ Proposed Solution
No response
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find any similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Not a bug, its a expected behavior.


Android e2e workflow improvements

Build with latest Java, test on lowest Java
made available thanks to https://github.com/Malinskiy/action-android/pull/87

closing, https://github.com/Malinskiy/action-android/pull/87 is inactive


Added example for compression serializer

closes #121

Codecov Report

Merging #179 into master will decrease coverage by 0.49%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master     #179     +/-   ##
=========================================
- Coverage   99.52%   99.02%   -0.5%
=========================================
  Files          12       12
  Lines         632      927    +295
  Branches       76      134     +58
=========================================
+ Hits          629      918    +289
- Misses          3        4      +1
- Partials        0        5      +5

Impacted Files
Coverage Δ

aiocache/serializers.py
91.17% <100%> (+0.26%)
:arrow_up:

aiocache/settings.py
97.91% <0%> (-2.09%)
:arrow_down:

aiocache/plugins.py
98.46% <0%> (-1.54%)
:arrow_down:

aiocache/backends/redis.py
99.23% <0%> (-0.77%)
:arrow_down:

aiocache/cache.py
99.4% <0%> (-0.6%)
:arrow_down:

aiocache/decorators.py
100% <0%> (ø)
:arrow_up:

aiocache/backends/memcached.py
100% <0%> (ø)
:arrow_up:

aiocache/utils.py
100% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Homepage red section

Client feedback:
"Currently the red ‘why choose reverse vending is no a full ‘page height’ can we make this a bit taller so that it fits the page break to page break better or if you like change the design to something that works better. I just don’t think it looks right as it is at the moment."

Solution:
I'm thinking you just add padding above and below so red section is bigger?
@perminder-klair what do you think?

@kpierduta added padding to this section and closing this issue.


nested struct decoding

example code here: https://gist.github.com/jschoch/b9c4f9c08fa5be127c67
The example is a bit of a hack and i'm wondering why this isn't a feature, assuming there is some reason.
Goal is to be able to run the decoder on nested structs.
%Foo{tuple: {1,2}} encodes it's to [1,2] and decodes to {1,2}
encode/decode should work on the below and have the :tuple converted to a list and back
%Bar{name: :baz, foo: %Foo{ tuple: {1,2}}

This would be really nice. We've discussed a similar case in this SO question: http://stackoverflow.com/questions/30855638/elixir-nested-json-parsing-to-structs
Given this JSON:
json = {"name": "blah blah", "address": {"street": "smthing"}}

it would be nice to be able to write
Poison.decode!(json, as: %User{address: Address})

I could probably look into that by the end of this week if you like.

Currently working on an implementation of this. Will be part of Poison 2.0. Updates coming this weekend.

@devinus thanks for your work, really looking forward to this!

Looking forward to this as well. Will the forthcoming implementation support arbitrary levels of nesting and multiple sub struct type definitions? For example:
Poison.decode!(json, as: %User{ address: %Address{}, creds: %Creds{ foo: %Bar{} } })

@JoelPM Yes, you should be able to nest as much as you want. Still working on the implementation.

@devinus do you have an ETA on this? (not trying to be pushy at all, I'm just curious)

@stevedomin This is being worked on. It's really hard to get it right. Hopefully this weekend I'll be able to finish it.

Been playing around with Poison, it would truly be an awesome feature.

@devinus have you made any progress on that one? If you are too busy I'm happy to take a look at it (some pointers would be great though)

I would love to have this feature!

+1

+1

I take it this is trickier than it first seemed to implement. It would definitely be useful!

+1

An update for everybody watching this: this is still a very hard problem, but I'm going to tackle it this weekend. Keep posted or ping me if I forget to update everybody.

That's awesome @devinus, looking forward to your update!

Hey guys, will be providing an update on this tomorrow.

@devinus Thanks for your dedication! :smiley:

Should finish it up by tomorrow: https://github.com/devinus/poison/pull/58
Considering making this a semver major breaking API change.
Poison.decode!(json, as: Person) will no longer work. Use Poison.decode!(json, as: %Person{})
The reason for this is you can't do Poison.decode!(json, as: %Person{address: Address}) for reasons like dialyzer. I don't want to confuse people, and if I keep the as: Person syntax I will inevitably start getting bug reports.
The huge benefit to this syntax is you can now do:
Poison.decode!(json, as: %Person{age: 50}) and it will default the age field to 50.

:heart: :yellow_heart: :green_heart: :blue_heart:

@devinus the idea is that, for each field in the map, you would check if it exists in the struct and what is its type? And if it happens to be another struct, you know how to decode it? That sounds good, specially because %Person{} would work out of the box as long as it defaults to an Address. However, how would you do collections? If the collection is a default, it is very likely the collection would be empty and you cannot pass something like %Person{addresses: %Address{}} because of dialyzer.
A counter proposal is to use a syntax similar to associations in Ecto:
Poison.decode!(json, as: Person)
Poison.decode!(json, as: {Person, addresses: Address, comments: Comment})
Poison.decode!(json, as: {Person, addresses: {Address, permalink: Permalink}})

You lose the feature for default attributes though.

@josevalim Collections are done like this:
Poison.decode!(json, as: %Person{addresses: [%Address{}], comments: [%Comment{}]})

:+1:

I was doing some experiments with the feature and I can't get it working with string keys. See the tests below. Am I doing something stupid?
# failing test
person = %{"name" => "Devin Torres", "contact" => %{"email" =><EMAIL_ADDRESS>assert decode(person, as: %Person{contact: %Contact{}}) == %Person{name: "Devin Torres", contact: %Contact{email<EMAIL_ADDRESS>
  1) test decoding into nested structs (Poison.DecoderTest)
     test/poison/decoder_test.exs:60
     Assertion with == failed
     code: decode(person, as: %Person{contact: %Contact{}}) == %Person{name: "Devin Torres", contact: %Contact{email<EMAIL_ADDRESS>     lhs:  %Poison.DecoderTest.Person{address: nil, age: 42, contact: %Poison.DecoderTest.Contact{email: nil, telephone: nil}, name: "Devin Torres"}
     rhs:  %Poison.DecoderTest.Person{address: nil, age: 42, contact: %Poison.DecoderTest.Contact{email<EMAIL_ADDRESS>telephone: nil}, name: "Devin Torres"}
     stacktrace:
       test/poison/decoder_test.exs:63

# working test
person = %{"name" => "Devin Torres", "contact" => %{email<EMAIL_ADDRESS>assert decode(person, as: %Person{contact: %Contact{}}) == %Person{name: "Devin Torres", contact: %Contact{email<EMAIL_ADDRESS># successful

@stevedomin That seems like a bug.


CB-14343 Forbid anonymous access to FreeIPA LDAP server

remove anonymous acces from health agent script as it seems it's not used anymore
add a new script and state for disabling anonymous access to common install state file, as it has to be done for every instance separately
verified by installing HA FreeIPA using ldapsearch
tested by provisioning DL and DH, and scaling DH

See detailed description in the commit message.

@wonderslug and I discussed this. We think there might be a small risk in a workload depending on anonymous ldap to get config, but it should be caught in the integration testing. We also think that if we commit this then lets just create a JIRA to remove the cluster mode health checks.

I left in place the part for replication anon access


Walkthrough components

Added Annotation components.

@linasburneika I had to include some type imports for the AnnotationStep interface. I just wanted to make sure it doesn't bloat the app again.


SPI Manage Packages Portal and Authentication

Goal
This project provides a base for more features, reporting, and control for package authors and maintainers.
Scope
To keep the scope of each part of this project under control, this issue is not concerned with adding any additional author-related features. This issue only creates the pages needed for authentication and a single authenticated page that will have no content other than links to logging out and to account deletion.
The entire authentication feature will be gated to the staging server even when this issue is complete and only go live to production once additional features are implemented.
The scope for the this feature going forward is much more significant than described here. See the Future Enhancements section for more detail.
Authentication system
This authentication system includes:

A “Portal” link from the site navigation bar that goes either to the login page if the user is not authenticated or to the package portal page if they are.
Login page hosted at /login/ containing email and password fields and a link to the password reset page.
Password reset page hosted at /reset-password/ with an email field and a link to the login page.
Logout page hosted at /logout/.
Delete account page hosted at /portal/delete-account/ functionality that removes all user data and PII for a user.
A package portal page hosted at /portal/ that contains links to the logout and delete account pages.

Implementation
We will use AWS Cognito to implement the authentication portion of this feature. It takes care of password policies, email address confirmation, password reset emails, and storage of user email addresses. It can also be extended to also take care of fraud detection later, if we experience problems with that.
The user will not leave the swiftpackageindex.com domain during authentication. All communication with Cognito is through their API and the Soto Cognito Authentication package.
Password policy and confirmation/reset emails can be configured inside the Cognito control panel and we can send all email from swiftpackageindex.com. End users should not be aware that Cognito is being used unless they read the privacy policy.
We can also customise the information that Cognito stores and will start with it storing nothing but email address and (encrypted) password.
Protection of PII
Any and all user information or personally identifiable information (PII) will be stored in a separate schema in the current database.
Privacy and cookies
Before this feature goes live to the public, we will also update our privacy policy to include information about the data we store, where we store it, cookies we save, and any other privacy related changes.
Any cookies will be from swiftpackageindex.com, not from a third-party site.
Future Enhancements
Next steps for this feature will be to list managed packages within the portal page and link to sub-pages that contain the two pieces of package-specific information that currently live on the “Information for package maintainers” page: Shields.io badges and package score information.
The list of managed packages will come from connecting GitHub accounts to an SPI user account, which will add all owned packages from that account and also allowing packages to provide additional authorised GitHub accounts through the SPI manifest.
This is not yet fully specified (although has been thought through in much more detail than here, but will be the subject of future issues.

Out of interest, what alternatives were considered? Such as, logging in using GitHub or SIWA. Additionally you elude to exclusive use of username+password, as opposed to Passkeys, which seems to be the direction the industry is pushing.
It's a personal decision no doubt, but I know I've been burnt by rolling my own auth on a few occasions!

Any and all user information or personally identifiable information (PII) will be stored in a separate schema in the current database.

Is there a way to avoid storing PII on our end? I thought Dave had mentioned that Cognito takes care of that and all we need is the cookie. It would be great if that was achievable!
Generally, once we start handling PII in this way we'll need to run through the GDPR checklist. One thing that's missing for example is "data take-out":

It's easy for your customers to receive a copy of their personal data in a format that can be easily transferred to another company.

It took a while to get through Amazon's heavy upsell, but the User Guide link https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-hosted-ui-app-client.html seems like what you may be aiming for. I'm a bit unclear on where PII ends up living, but it seems like you can have that hosted at Amazon, and then hand out "JWT"s through the API that provide the "proof" of authentication - and can be used for some amount of authorization as well.
I suspect no matter what though, it'll be important to keep that GDPR checklist at hand.

It took a while to get through Amazon's heavy upsell, but the User Guide link https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-hosted-ui-app-client.html seems like what you may be aiming for. I'm a bit unclear on where PII ends up living, but it seems like you can have that hosted at Amazon, and then hand out "JWT"s through the API that provide the "proof" of authentication - and can be used for some amount of authorization as well.

Yes, that's exactly it.

I suspect no matter what though, it'll be important to keep that GDPR checklist at hand.

Absolutely. Just because we're getting Amazon to actually store it, it's still our responsibility.

Generally, once we start handling PII in this way we'll need to run through the GDPR checklist. One thing that's missing for example is "data take-out":

It's easy for your customers to receive a copy of their personal data in a format that can be easily transferred to another company.

This will fall into much more clarity as we implement it, but I believe the only PII we will store is an email address. Certainly I have checked that we don't log IP addresses or anything like that.
It will be clearer whether we need this feature as we implement, but at the moment I don't believe we would need it, and if we did it would be a text file with the user email address.


Add snapshot testing for pipeline files

This PR adds two tests:

Check the JSON of a pipeline that had all the nodes deleted
Check the JSON of a pipeline that had one node added

The bulk of this PR adds a snapshotting mechanism to make these tests easier to write and update.
Basic usage
cy.readFile('example.pipeline').matchesSnapshot();

The first run of this in a test will generate a snapshot of the pipeline file if it does not exist. If it exists, it will verify that the file matches the stored snapshot. If the test cannot find a snapshot in CI, the test will fail instead of generating a new snapshot.
In order to update a snapshot, delete the snapshot and re-run the integration tests for a new one to be generated.
Highlights of changes to pipeline json
changes going from 2.2.4 -> master:
Notebook node ui_data:
-  "description": "Notebook file",
+  "description": "Notebook",

Pipeline app_data:
+  "properties": Object {
+    "name": "simple",
+    "runtime": "Generic",
+  },

Node properties no longer include unset properties in pipeline json:
-  "include_subdirectories": false,
-  "runtime_image": "",

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

Could we actually have the tests in tests/integration and maybe something like pipeline-format.ts or pipeline-backward-compatibility.

Also, I am not sure what the snapshot mechanism does, from The first run of this in a test will generate a snapshot of the pipeline file if it does not exist. If it exists, it will verify that the file matches the stored snapshot. it seems to imply that the snapshot can be created dynamically, but what I really think we want is to have a set of pipeline examples certified to be valid (e.g. test/resources/valid_empty_pipeline.json, test/resources/valid_3_node_pipeline) and make sure that creating a new pipeline via the UI from the build env generates an equivalent pipeline, and by equivalent, I mean it's exactly the same except for unique fields like node coordinates, ids, etc.

From the changes highlighted:

The first two I believe are only additions
The third one might be a bug?

Node properties no longer include unset properties in pipeline json:

-  "include_subdirectories": false,
-  "runtime_image": "",

Are these fields that have a default value and weren't changed by the user?
runtime_image should be there otherwise pipeline can't be saved, no?

@lresende

Could we actually have the tests in tests/integration and maybe something like pipeline-format.ts or pipeline-backward-compatibility.

The test cases are currently in tests/integration/pipeline.ts, but I can move them into a new file with one of the suggested file names, do you have a preference?

Also, I am not sure what the snapshot mechanism does

I normally see snapshot testing in UI unit tests, this is the description of snapshots from jest: "Snapshot tests are a very useful tool whenever you want to make sure your UI does not change unexpectedly."
I think we can reuse this concept for the pipeline json, because I think we basically want to make sure it doesn't change unexpectedly, right?
The main idea is that we would write an integration test that creates a pipeline, and then call cy.readFile('example.pipeline').matchesSnapshot() as the assertion. The first time you run the test, it would generate the actual snapshot, this is the "certified" example and thats what you see in the snapshots/example.snap. This snapshot is never supposed to change and if it does, it is a test failure.

The third one might be a bug?

Yea, I wasn't sure if this should be considered a bug or not. The field include_subdirectories has a default value of false, so it is omitted unless manually edited. runtime_image is unset with no default so it really should be null instead of an empty string I think. Omitting these values is still backwards compatible because 2.2.4 will automatically fill  include_subdirectories and  runtime_image with false and an empty string respectively.

notes to self
elyra/elyra-example-anaconda-py3:latest

@lresende this should be good to go once https://github.com/elyra-ai/pipeline-editor/pull/136 is released and we replace the codesandbox version

@marthacryan @ajbozarth can you take a closer look at my file request logic to make sure I'm not missing anything

@bourdakos1 Where is this comparing the built pipeline with the consumer-producer.pipeline that was built on the previous Elyra release?

The complex.snapshot in this pr is not compatible with Elyra 2.2.4. If you compare the producer-consumer.pipeline and the snapshot you will see that the issue reported in #1693 is still there and the comparison is not picking it up.

You can launch Elyra 2.2.4 via docker with:
docker run -it -p 8888:8888 -v ${HOME}/opensource/jupyter-notebooks:/home/jovyan/work -v ${HOME}/Library/Jupyter:/home/jovyan/.local/share/jupyter -w /home/jovyan/work elyra/elyra:2.2.4 jupyter lab --debug

@lresende it did pick up that change as noted above, but I didn’t notice the bug. I think this issue was fixed at one point, but must have been re-introduced when moving the component definitions back to the server. I think the fix for this is changing the cpu/gpu type to number instead of string.
I can roll back the snapshot so the tests fail until fixed


Adding capability to mint new jobIds in federation

Description of the Change
This work enables the concept of FederationJobs which could span across deployment cells/stacks. As a first step, we need to create the JobIds externally and then pass it the deployment stacks so the job records can be created in external storage specific to the stack.

@joshi-keyur DefaultV3JobOperations junit test would be nice.


Add CloudRun deploy for frontend app

Add Cloud Run deployment using Skaffold: https://skaffold.dev/docs/pipeline-stages/deployers/cloudrun/
update docs for both options: gke and cloud run for the frontend app.
Will update and unify all skaffold profile in later PR.
Will fix e2e test for cloud run in later PR.

/e2e-test


the removed animation played when page state changed (document visibilitychange event)

Describe the bug:
I remove an animation, but it played when i trigger the document visibilitychange event.
I found that It doesn't remove the animation when i removed. And when it run into visibilitychange event, it played all of pause animation.
To Reproduce:

remove an animation
i slide my desktop on my mac, i guess switch tab also can trigger the bug. Anyway, to trigger the visibilitychange event.

Expected behavior:

my removed animation can not replay

Desktop:
browser chrome v73.0.3683.75

Fixed in v3.1.0!

@juliangarnier @chrisbrown-io I think bug is still there, at least partially perhaps.
Steps to reproduce:

deactivate tab (so it would become document.visibilityState === 'hidden')
run anime.reset() (while document.visibilityState === 'hidden')
get back to tab, so it would trigger visibilitychange event

Actual results:
Anime restores animations https://github.com/juliangarnier/anime/blob/3.2.0/src/index.js#L875 including those which were explicitly paused by user (in step 2)