Optimize array cast for equivalence

In web servers and crypto, there is frequent back-and-forth casting between ubyte[] and string. This created a bottleneck where perf gave this function a 7% sampling prevalence. After this optimization, it went down <1%.

Seems like we could do this on the compiler side.

Auto-merge toggled on

Yes, please make a ticket to do this on the call site.

Wait, in fact it's already done https://github.com/D-Programming-Language/dmd/blob/c6ac10aed0f7dc76112e576204e3a1e8ea307dbd/src/e2ir.c#L3962.
Can you please provide a test case for this @etcimon?

So it is!  This change should be 100% dead code.

Maybe it's not yet done for gdc or ldc, waiting for more input from @etcimon before reverting this.

I assumed this was the line that dropped the load on the server, but the commit actually removed a modulo comparison operation as well:
https://github.com/etcimon/druntime/commit/f938683cf83473f20f7fcd9e7a948e2f612b3b46#diff-7165ac077e578d70f8d6f9153b344bdaR32
I'll isolate this on the server today

It looks like the modulo might be responsible for this to be 35% slower, but it only slows down from 1.0% to 1.35% in the perf diagnostics because I delegated the monty reduce operations to openssl, so my bigint operations don't use the array cast. I could do an optimization in that library instead once I get around to optimizing it correctly, it was 10x slower than openssl in monty because of some inline issues I suppose. So, this can be reverted, sorry about that

The modulo could be replaced with length * tbytes != nbytes, leaving only a single division.
And we could optimize the IR gen for common scale factors to use a cheap shift.


pgupgrade: Scale back clair pods when upgrading clair db (PROJQUAY-5235)

When upgrading the clair postgres, scale back the clair pods to prevent further operations
This will cause the previous postgres deployment to terminate and the upgrade can complete

/cherrypick redhat-3.9

/cherrypick redhat-3.9


Dictionary variables should support attribute access with nested dictionaries

When creating a dictionary variable explicitly like
&{var} =    Evaluate    {'key': 'value', 'nested': {'key': 'value'}}

or in a variable file like
DICT__var = {'key', 'value', 'nested': {'key': 'value'}}

it is possible to access values as attributes like
Should be equal    ${var.key}    value

This is useful, for example, when working with REST interfaces that return JSON data structures. Unfortunately accessing values only works with the immediate keys of the dictionary, not with the nested dictionaries, and thus this currently fails:
Should be equal    ${var.nested.key}    value

A workaround is either using the normal dictionary key access syntax or assigning the internal dictionary into a new dictionary variable. Both of these are somewhat ugly, though:
   Should be equal    ${var['nested']['key']}    value
   &{nested} =    Set variable    ${var.nested}
   Should be equal    ${nested.key}    value

This issue can be implemented by changing the internal robot.utils.DotDict to convert internal dictionaries into DotDicts recursively.


Set repository to be a template

@avahoffman Want to wait until it's functional?  Or just click the button so it's done? :)

Doesn't matter to me :)

Done!


Add Nebari landing page

Reference Issues or PRs
#182
What does this implement/fix?
Put an x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features to not work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[ ] Did you test the pull request locally?
[ ] Did you add new tests?

Documentation

Access-centered content checklist
Text styling

[ ] The content is written with plain language (where relevant).
[ ] If there are headers, they use the proper header tags (with only one level-one header: H1 or # in markdown).
[ ] All links describe where they link to (for example, check the Nebari website).
[ ] This content adheres to the Nebari style guides.

Non-text content

[ ] All content is represented as text (for example, images need alt text, and videos need captions or descriptive transcripts).
[ ] If there are emojis, there are not more than three in a row.
[ ] Don't use flashing GIFs or videos.
[ ] If the content were to be read as plain text, it still makes sense, and no information is missing.

Any other comments?

To clarify - this PR is for you @gabalafou to work off or the landing page (rather than reviewing the PR thoroughly).
Mostly since adding the landing page requires changes to how we handle other routes on the site (and cannot be done directly in main as we have no landing page right now).
No need to check for broken links manually as our build setup will throw any broken links automatically.

Notes from our discussion from Friday.
It'll be good to merge this PR soon because we introduce the /doc subdirectory here that impacts all of our cross-links. :)
Adding it to the milestone!

Okay, so I'm taking over this PR. I'm going to fix the merge conflicts and now and then shall we merge it in?

@trallard I already fixed the conflicts. 🪄😃 Is there a way we can change this PR so that it both creates a space for me to work in while I build the landing page but without replacing the existing landing page? That way we can merge this PR in sooner rather than later?

Ok I had to do some work on the configuration + add redirects to have a "hidden" landing page.
@kcpevey  and/or @pavithraes - this allows us to merge right now and have the foundation for Gabriel to work on the landing page.
Also this Closes #199

🎉


Handle undocumented tags

There are undocumented tags. Push to UNKNOWN if included in answer from E3DC.
Signed-off-by: bjoernbrings<EMAIL_ADDRESS>

And fixed problems that container don't have a value as well

And fixed problems that container don't have a value as well


Take out the blue dot on the right and implement the markdown convertor on the toolbar instead

leave the swipe from right edge to center alone.

Solution: https://github.com/yoha/Notes/commit/1d3e76666987662001de2c5fd26cfbfb1301d7d0


Vulnerability roundup 97: lout-3.40: 1 advisory [7.8]

search, files

[ ] CVE-2019-19917 CVSSv3=7.8 (nixos-20.09, nixos-unstable)

Scanned versions: nixos-20.09: 50c8d1e0deb; nixos-unstable: 83cbad92d73.

See also: #90853


how to use next()

how to use next() ?
help me

Do you know using it?

yes very easy :)

step 1 - In your constructor create the options object which will be passed to OwnCaroussel in step 2
constructor() {       super();       this.options = {             onInitialized: function(){             this.carousel = this;       } };
Step 2 - Pass options to OwlCarousel as follows
 <OwlCarousel {...this.options}>
Step 3 - now you can call any of carousel's methods - For an example -
this.carousel.next() or this.carousel.prev() etc.
Hope this helps :)

@pavan168
Could you explain how to define  "this.carousel" ?
I'm stuck in connecting with method.
Below is the constructor of class component.
constructor(props) {
    super(props);
    this.carousel = React.createRef();
    this.options = {
      onInitialized: function() {
        this.carousel = this;
      }
    };
    this.initialState = {
      ...
    };
    this.state = this.initialState;
  }

@pavan168
Could you explain how to define "this.carousel" ?
I'm stuck in connecting with method.
Below is the constructor of class component with the attempt with your comment
constructor(props) {
    super(props);
    this.carousel = React.createRef();
    this.options = {
      onInitialized: function() {
        this.carousel = this;
      }
    };
    this.initialState = {
      ...
    };
    this.state = this.initialState;
  }

So @bangdy when you pass this.options into the Owl Carousel component and when it's initialized with options you could access its functions using this.carousel anywhere in your methods. Have you tried upto that point?

for calling a method of OwlCarousel you should put ref on react OwlCarousel element and append it to this then call method on this for example:
export class Owldemo1 extends Component { click = ()=>{     console.log(this.slider);     this.slider.next(500) } render() {     return (
             <button onClick={this.click} className="btn btn-info">                 salam             </button>             <OwlCarousel items={5}                          className="owl-theme"                          loop                          nav                          margin={10}                          ref={slider => (this.slider = slider)}             >

             </OwlCarousel>
     ) }


Update wasmer to 2.3.0

Closes #1353

Seems the new Wasmer doesn't agree with our MSRV:
error: package `corosensei v0.1.3` cannot be built because it requires rustc 1.59.0 or newer, while the currently active rustc version is 1.56.1

Should I update the 1.56.1 CI job to 1.59.0?

Yeah, sounds reasonable.


Custom icons

Is it possible to replace all the other icons (prev, next, close) and not just the spinner?

What I did instead was, I turned off the close button and the next / prev arrows and I passed custom components using the customControls property.

Please see the new version for adding custom components.


Unsupported response $ref

I have a swagger file containing $refs to pre-defined responses. swagger-diff fails with an error:
My resp-ref.yaml file:
---
swagger: '2.0'
info:
  version: 0.0.0
  title: Simple API
paths:
  /:
    get:
      responses:
        202:
          description: OK
        default:
          $ref: "#/responses/apiError"
responses:
  apiError:
    description: "Any erroneous status code: 400 (parse error), 401 (auth error),\
      \ 402 (trial access), 403 (insufficient permissions), 404 (not found), 405 (unsupported\
      \ HTTP method), 415 (unsupported content type, 422 (validation error), 429 (request\
      \ rate limit exceeded), 500 (server error), 503 (maintenance)"
    schema:
      type: 'object'

When calling swagger-diff resp-ref.yaml resp-ref.yaml (I use same file for simplicity)
Error I am getting:
/var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:46:in `rescue in set_value_with_coercion': Cannot coerce property "responses" from Hash to {String=>Swagger::V2::Response}: The property '$ref' is not defined for Swagger::V2::Response. (Hashie::CoercionError)
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:34:in `set_value_with_coercion'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/indifferent_access.rb:107:in `indifferent_writer'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:168:in `block in initialize_attributes'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:167:in `each_pair'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:167:in `initialize_attributes'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:99:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger/swagger_object.rb:16:in `initialize'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:68:in `new'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:68:in `block in coerce_or_init'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:35:in `call'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:35:in `set_value_with_coercion'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/indifferent_access.rb:107:in `indifferent_writer'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:168:in `block in initialize_attributes'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:167:in `each_pair'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:167:in `initialize_attributes'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:99:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger/swagger_object.rb:16:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger/v2/path.rb:20:in `initialize'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:68:in `new'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:68:in `block in coerce_or_init'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:40:in `call'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:40:in `block in set_value_with_coercion'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:40:in `each'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:40:in `map'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/coercion.rb:40:in `set_value_with_coercion'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/extensions/indifferent_access.rb:107:in `indifferent_writer'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:168:in `block in initialize_attributes'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:167:in `each_pair'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:167:in `initialize_attributes'
    from /var/lib/gems/2.1.0/gems/hashie-3.3.2/lib/hashie/dash.rb:99:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger/swagger_object.rb:16:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger/api.rb:21:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger/api.rb:9:in `new'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger/api.rb:9:in `build_api'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger.rb:24:in `build'
    from /var/lib/gems/2.1.0/gems/swagger-core-0.2.3/lib/swagger.rb:35:in `load'
    from /var/lib/gems/2.1.0/gems/swagger-diff-1.0.5/lib/swagger/diff/specification.rb:54:in `parse_swagger'
    from /var/lib/gems/2.1.0/gems/swagger-diff-1.0.5/lib/swagger/diff/specification.rb:6:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-diff-1.0.5/lib/swagger/diff/diff.rb:5:in `new'
    from /var/lib/gems/2.1.0/gems/swagger-diff-1.0.5/lib/swagger/diff/diff.rb:5:in `initialize'
    from /var/lib/gems/2.1.0/gems/swagger-diff-1.0.5/exe/swagger-diff:6:in `new'
    from /var/lib/gems/2.1.0/gems/swagger-diff-1.0.5/exe/swagger-diff:6:in `<top (required)>'
    from /usr/local/bin/swagger-diff:23:in `load'
    from /usr/local/bin/swagger-diff:23:in `<main>'

Thank you for your feedback! It looks like this is an issue with swagger-rb, the underlying library swagger-diff uses to parse Swagger specifications. Unfortunately, we’re juggling a few different priorities at this time, and probably won’t get to this quickly. If you’re interested, we’d welcome a PR addressing this issue. It looks like there are two possible ways to approach this:

File an issue with swagger-rb and wait for them to fix it. However, swagger-rb appears to be inactive, or possibly abandoned, so I don’t anticipate any issue being addressed quickly.

Replace the Swagger parser. When I last looked into this, ruby_swagger looked to be a viable candidate that was under active development, though it's also pretty young, so may not be feature-complete yet. swagger_parser was another candidate. It was less active, though also had no outstanding issues/PRs, so may just be stable. If you wanted to attempt replacing the Swagger parser, it would be worth investigating the current state of parsers, in case someone released a better candidate since I last looked.

If you opt for 2, you may also want to file an issue with swagger-rb so they’re aware and can address the underlying problem if and when they have time.
Either way, we’d be happy to review a PR, and appreciate the contribution!

When looking at #31, I discovered that swagger-rb does implement support for $ref, but does not include it in the response object. So adding another monkey patch to patch.rb and a new spec to specification_spec.rb is also an option here.

I just released Swagger::Diff 1.1.0. Among other improvements, it replaces the underlying parser, and should now support this Swagger specification, too. If you encounter any other problems, please let us know.


Run prettier-standard in Sublime Text 3?

Is this already possible? I couldn't figure out how to do this.

Why is this so slow though?


Form submit is not working after using aysnc blur validation.

I really have no idea about what went wrong because, the async validation is working well but I am unable to use submit button after that.
redux-form => 7.0.3
Here is my async method:
`import * as api from '../../../tools/apiConfig';
import axios from 'axios';
const asyncValidate =(values, dispatch, props, currentFieldName) => {
 const locale = props.locale.contactinfo;
 return new Promise((resolve, reject) => {
   if (currentFieldName === 'zip') {
     const field1 = {
       postal_code: values.zip
     }
     axios.post(api.VALIDATE_ZIP, field1).then((response) => {
       if (response.data == false) {
        return reject({ zip: locale.postalRemoteValidate });
       }
       else {
        return resolve()
       }
     });
   }
   else if (currentFieldName === 'email') {
     let field2 = {
       email: values.email
     }
     axios.post(api.VALIDATE_EMAIL, field2).then((response) => {
       if (response.data == false) {
        return reject({ email: locale.emailValidation });
       }
       else {
        return resolve()
       }
     })
   }
 })
}

export default asyncValidate;

`

@Abhijeetjaiswalit thanks for confirming but no need to create a duplicate of #2021.


assert hidden_states.shape[2] > 1, "OpenSoraInpaint only supports video input"

i tried the traing inpainting using my dataset , but  i got some errors , i got hidden_states.shape[2] ==1 , i do not fix any code

but my dataset is the video input

It seems that your input has only 1 frame. Please check your input.


Update model_storage_usage.go

Increase StorageUsage.bytes from int32 to int64
See #5

Hi, thanks for the pull request. The container-reg is auto-generated though. We already fixed this in release 1.0.1.
The getter and setter should be changed also in the new vesion.


Split the Package?

Might it be more useful to split monomer off into a core monomer package, as well as some widget collections that depend on monomer?
For instance, I think there's a bunch of stuff missing on monomer animation, as well as options that might be missing in monomer and would be nice to add. As is, I'd have to do a pull request on the entire monomer repository, adding code that might not be easily ported. If monomer were split off into monomer-core, monomer-widgets-core, etc, it'd make it easier for others to develop their own widget packages for monomer and share them.
Moreover, it'd make it easier to learn the library because instead of having to go through all widgets, you'd only need to go through the core library and learn an abbreviated monomer-widgets-core library instead, instead of not having priority through the assorted widgets.

@liamzee Hi, actually I recently added a bunch of new animations to my fork of monomer. I am just waiting for my pull request of removing redundant imports and fixing typos in documentation to be merged, so I can rebase my animation branch and open PR for them. Meanwhile you can check them out on my fork.
Also, I have been working on my custom collection of widgets for monomer. I needed some composites in my projects and I wrote them and figured that they can be useful for other people, so I created a repo with all of them. If @fjvallarino creates an official monomer-widgets-core repo which you are talking about, then I would consider moving all my custom widgets there.

@liamzee @Deltaspace0 the Monomer package is already Monomer Core. It provides the following features:

OS and event handling abstractions.
Application lifetime.
A foundational set of widgets that most applications need.

The last point may be the most controversial since some of the widgets are clearly not foundational. Mostly I'm thinking about alert/confirm, colorPicker/colorPopup, split, and themeSwitch, but depending on each one's perspective, others could be included. Some reasons for having widgets in the library's core are:

Excluding those items, I believe the library needs to provide a basic set of features without requiring users to find out which extra packages they need. Separating them into widgets-core would create a more confusing user experience.
Some of the mentioned widgets were used as a test bed for figuring out how things could be done (ColorPicker and ColorPopup) and to also show that other things could indeed be done (the really basic animation package the library includes).
As such, reading their source code can be useful when thinking about new widgets.
Additionally, having some of these widgets around in the main package helps me test things more easily because I can avoid compile/reload cycles and only use ghcid. Losing this would cause friction and complicate testing issues that are reported.

What do I think about external packages implementing widgets? I think that's the correct way of handling new widgets. Take, for example, Hagrid. It provides really useful functionality, relying on the core features provided by the library, but it's an independent package that can evolve as fast as its maintainer wants and can do things however is deemed better. The creator owns the package and can implement its vision without restrictions of any kind.
If somebody creates a package with a single widget or a collection of widgets, I'd be more than happy to link to it on the project's main page. This also applies to most of the widgets I could create in the future (save for a couple of layout-related ones). Doing this will simplify the maintenance of the core library and avoid having me as a blocker. Can I help if questions arise? Absolutely. But most new widgets do not require changes to the Core library; if changes are required, we can discuss/implement them.
Going back to the original question: I think forking the library to add a new widget is not the best option and having separate packages is the preferred way, since it gives more control to the creator of the widgets and removes blockers. I will make it clearer in the Readme.


fix(web): Catch battery status promise rejections

Description
Fixes https://github.com/react-native-device-info/react-native-device-info/issues/1544
Compatibility
Web-only fix.
Checklist

[x] I have tested this on a device/simulator for each compatible OS
[n/a] I added the documentation in README.md
[n/a] I updated the typings files (privateTypes.ts, types.ts)
[n/a] I added a sample use of the API (example/App.js)

LGTM, but should this be considered as a BC breaking change?
Some users may be try/catching and handling errors differently than what you're doing here..

Some users may be try/catching and handling errors differently than what you're doing here..

This is a fair point - how about a more narrow change that only affects the init() call, since that basically can't be caught right now (which is why I worked on this to begin with)?

Frustratingly, it doesn't appear that the catch() at https://github.com/react-native-device-info/react-native-device-info/pull/1545/files#diff-a2eea7d51d5408108433b3aa81ed471741b8f15ae58ca9dd358da064f819c3b5R84 is consistently working on Windows. I have seen this resurface recently, although with much less frequency. Chrome 86 and 100. I can't recreate it with a similar browser setup on LambdaTest... invoking navigator.getBattery() in the JS console returns the BatteryManager.

Thanks for your patience - sorry my time here is so intermittent, but I can't promise more in general 😬 - at any rate, I like the idea of the catches, but if it is not consistent it doesn't help much
(though as an aside: what !? how can a catch not consistently catch...how is that even a thing? So difficult trying to produce reliable code for all platforms...)
As a policy note on breaking changes (assuming consistent behavior can be created...) I am okay with breaking changes in general, my stance is "version numbers are free". My requirement is more about developer empathy in that breaking changes do get a semver major, and they are accompanied with a really good developer note explaining exactly who is affected, and exactly what changed, and a reasonable attempt to specify the likely change for adoption. That's all - and it's not difficult + and I usually handle that myself during the commit so that the auto-release infrastructure picks it up.
TL;DR: no big deal to do a breaking change normally

Marking as "on hold" until behavior consistency is achieved so whatever path forward is the final path forward is reliable vs flaky


[WIP] Various v2.9.0 changes

Trying to get https://github.com/StackStorm/st2web/pull/605 finished so we can include at least one directly user-visible performance improvement.
Changes

Some improvements in the GET /v1/executions API endpoint - sometimes parameters field can be None
GET/v1/actions/overview API endpoint - performance improvements

Remove log statement which logged under INFO every action object which caused unnecessary and massive performance overhead
Reduce number of queries from N * 2 to 2

Changes in bcb63f58cb9530c5ce4b73203992d19e4f8cb222 and 7d070d81c6f29d7b6952ba1c6f7c4cb06b9ab6a1 substantially improve performance of GET /v1/actions/views/overview API endpoint.
It changes the code to perform 1 database query instead of n * 2 where n is number of actions in the database. This + the logging change now makes this API endpoint return in ~6-7 seconds instead of ~35 seconds on installations with a lot of actions.
Having said that, 6 is still too long, imo.
The main problem is that in the new WebUI "Rules" tab / app now depends on this API endpoint.
@enykeev Can we some how get rid of request to this API endpoint all together in the new rules tab? Or can we replace it with a call to some other (faster) API endpoint?

Adding to my comment above - another option to provide a better WebUI rules tab user experience would be delay loading action parameters and display rules immediately on the page once rules are loaded and full in action parameters loaded once action data is loaded from that API endpoint.
This would provide a much better user-experience - current approach with page being "white" aka not-rendered / empty until actions overview API endpoint loads is very not friendly for installations with a lot of actions.
/cc @enykeev


Uno generates redundant styles for each breakpoint for {bp}:container

UnoCSS version
0.52.7
Describe the bug
Currently if we add md:container class, Uno will generate this styles:
@media (min-width: 768px){
.md\:container{max-width:768px;}
}
@media (min-width: 1024px){
.md\:container{max-width:1024px;}
}
@media (min-width: 1280px){
.md\:container{max-width:1280px;}
}
@media (min-width: 1536px){
.md\:container{max-width:1536px;}
}

But it is enought to have this one:
@media (min-width: 768px){
.md\:container{max-width:768px;}
}

Reproduction
https://unocss.dev/play/?html=DwEwlgbgBAxgNgQwM5ILwCIC2IBcMD2AdgC4JiECmATugHzAD04EtQA&config=JYWwDg9gTgLgBAbzgEwKYDNgDtUGEJaYDmANHGFKgM6owCqWEcAvnOlBCHAOQCujAYypVuAKFGoAHpFgoMAQ14AbeGkw58hYEQAUCZgEpRQA&css=Q&options=N4IgLgTghgdgzgMwPYQLYgFwKgGzgUwF8g
System Info
No response
Validations

[X] Read the Contributing Guidelines.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

why this issue closed...

In my case, I dont need any .container class，but unocss（actually tailwindcss）generates them（each breakpoint）automatically， And，I dont know how to disable it.. (while could disable in tailwindcsss config)
Now, I use a global class to overwrite it, like:
.container {
  max-width: none;
}

If there`s any other resolutions, please let me know.


Add ability for status/toast messages

When a user performs a change action(Mark favorite/archive), there should be a confirmation message.

message comes up when favorite or archive button has been pressed

toast now comes up for actions. only one that is not coming up is "back" since the remove method is not working, but it is an easy fix


Task6-9

Tasks 6 to 9

@Sandhyathota1
Task -6
Code verified. Default activity names

Task -7
Code verified. Default activity names

Task -8
Code verified. Default activity names

Task -9
Code verified. Default activity names


Site is not responsive

Top bar needs to remove buttons when viewport shrinks
Menu bar does not auto/open close
Button to open/close menu is laggy,

Fixed by #14


Add the FOSSA plugin

This PR adds the FOSSA plugin. FOSSA is a service that scans dependencies for Open Source licensing issues. This plugin contains an API and a widget that shows the latest compliance status.
The widget has different states depending on the number of issues:

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)

Closes #3094

I didn't add a changeset and didn't add a CHANGELOG.md since it is a new plugin. Is this correct? Or should I add a new changeset which just says Add FOSSA plugin?

I didn't add a changeset and didn't add a CHANGELOG.md since it is a new plugin. Is this correct? Or should I add a new changeset which just says Add FOSSA plugin?

Since, it's a new package, we don't have to add a changeset.

@dhenneke, you can merge it now! :grin:


babashka: 1.2.174 -> 1.3.176

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for babashka is: A Clojure babushka for the grey areas of Bash
meta.homepage for babashka is: https://github.com/babashka/babashka
meta.changelog for babashka is: https://github.com/babashka/babashka/blob/v1.3.176/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.3.176 with grep in /nix/store/fprcwr6fnxrj98p0iv9lzlxx93d0ny8x-babashka-1.3.176
found 1.3.176 in filename of file in /nix/store/fprcwr6fnxrj98p0iv9lzlxx93d0ny8x-babashka-1.3.176

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

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
babashka
bbin
neil

Instructions to test this update (click to expand)

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

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fprcwr6fnxrj98p0iv9lzlxx93d0ny8x-babashka-1.3.176
ls -la /nix/store/fprcwr6fnxrj98p0iv9lzlxx93d0ny8x-babashka-1.3.176/bin

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

3 packages built:

babashka
bbin
neil

Maintainer pings
cc @bennyandresen @bhougland18 @DerGuteMoritz @jlesquembre @thiagokokada for testing.

λ nix-review pr 221933                                                                                master nixpkgs
$ git -c fetch.prune=false fetch --no-tags --force https://github.com/NixOS/nixpkgs master:refs/nixpkgs-review/0 pull/221933/head:refs/nixpkgs-review/1
remote: Enumerating objects: 69, done.
remote: Counting objects: 100% (52/52), done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 69 (delta 37), reused 21 (delta 21), pack-reused 17
Unpacking objects: 100% (69/69), 206.64 KiB | 1.41 MiB/s, done.
From https://github.com/NixOS/nixpkgs
   1283da924bc..f8ac00dd806  master     -> refs/nixpkgs-review/0
$ git worktree add /home/benny/.cache/nixpkgs-review/pr-221933-2/nixpkgs f8ac00dd8060bb3d5b83c28e712f091116f15162
Preparing worktree (detached HEAD f8ac00dd806)
Updating files: 100% (34041/34041), done.
HEAD is now at f8ac00dd806 Merge pull request #217634 from tehmatt/tehmatt-gdbgui
$ git merge --no-commit --no-ff 3756776f1d167451343da095025df0d167721be6
Automatic merge went well; stopped before committing as requested
$ nix --experimental-features nix-command build --no-link --keep-going --no-allow-import-from-derivation --option build-use-sandbox relaxed -f /home/benny/.cache/nixpkgs-review/pr-221933-2/build.nix

Link to currently reviewing PR:
https://github.com/NixOS/nixpkgs/pull/221933

3 packages built:
babashka bbin neil

error: build log of '/nix/store/hd95k2ifyqk5fcp85vkwls1nff5nwvqa-babashka-1.3.176.drv!*' is not available
error: build log of '/nix/store/fprcwr6fnxrj98p0iv9lzlxx93d0ny8x-babashka-1.3.176' is not available

I'm able to run babashka, bbin and neil and they seem to work fine.
From https://github.com/NixOS/nixpkgs
   1283da924bc..f8ac00dd806  master     -> refs/nixpkgs-review/0
$ git worktree add /home/benny/.cache/nixpkgs-review/pr-221933-2/nixpkgs f8ac00dd8060bb3d5b83c28e712f091116f15162
Preparing worktree (detached HEAD f8ac00dd806)
Updating files: 100% (34041/34041), done.
HEAD is now at f8ac00dd806 Merge pull request #217634 from tehmatt/tehmatt-gdbgui
$ git merge --no-commit --no-ff 3756776f1d167451343da095025df0d167721be6
Automatic merge went well; stopped before committing as requested
$ nix --experimental-features nix-command build --no-link --keep-going --no-allow-import-from-derivation --option build-use-sandbox relaxed -f /home/benny/.cache/nixpkgs-review/pr-221933-2/build.nix

Link to currently reviewing PR:
https://github.com/NixOS/nixpkgs/pull/221933

3 packages built:
babashka bbin neil

error: build log of '/nix/store/hd95k2ifyqk5fcp85vkwls1nff5nwvqa-babashka-1.3.176.drv!*' is not available
error: build log of '/nix/store/fprcwr6fnxrj98p0iv9lzlxx93d0ny8x-babashka-1.3.176' is not available

I'm able to run babashka, bbin and neil and they seem to work fine. So the error doesn't appear to be an issue.

This build log error is common for packages build with @r-ryantm bot and when nix-community is enabled.


WIP check in assets-for-api-docs doesn't ever start or report status.

Type of Request
bug
Infrastructure Environment
Autosubmit and/or WIP check
What is happening?
In this PR: https://github.com/flutter/assets-for-api-docs/pull/229 There is a "WIP" check that never reports its status.  I'm no longer allowed to commit PRs in that repo, and the autosubmit label just gets removed by the bot because the WIP check never reported status.
I've tried pushing an empty change to trigger the check again, but it doesn't seem to get triggered.
What can I do to unstick this?
Expected results
I expect the WIP check to complete in a reasonable time.

WIP was being enforced during branch protection but the WIP app was removed from the flutter org. Removed WIP from branch protection.
Please rebase the PR to clear out the WIP status check.


Wrong security group in example launch-template for managed node groups?

Description
The launch template example for managed node groups references to the security group for EKS worker groups (self-managed nodes). In our case this prevents Pods from communicating with the K8s API server. The Kubelets on the other hand seem to be able to communicate with the API server: Pods are scheduled and started correctly.
https://github.com/terraform-aws-modules/terraform-aws-eks/blob/9022013844a61193a2f8764311fb679747807f5c/examples/launch_templates_with_managed_node_groups/launchtemplate.tf#L49
Imho the clusters primary security group must be referenced here. In our case this change solved the connectivity problems within the cluster.
Reproduction
Use the example launch template for managed nodes groups from this repo, start a Pod and try to access the K8s API Server (by default <IP_ADDRESS>). We noticed it when deploying our basic cluster components, such as cert-manager, which has to access a ConfigMap via API server.
Expected behavior
The cluster primary security group (in the AWS console it can be found under Configuration -> Networking -> Cluster security group) is referenced here:
security_groups             = [module.eks.cluster_primary_security_group_id]
Additional context
I have reinsured myself and created a managed node group via AWS console. The cluster security group mentioned above is, as expected, always attached to the EC2 instances.
There is also an additional hint when choosing "Use Launch Template" in the creation wizard for a new node group:

If you specify custom security groups in the launch template, Amazon EKS will not add the cluster security group, and you must ensure the ingress and egress rules of your security groups enable communication with your cluster’s endpoint.

Further hints under Configuration -> Networking -> Cluster Security group:

The Cluster Security Group is a unified security group that is used to control communications between the Kubernetes control plane and compute resources on the cluster. The cluster security group is applied by default to the Kubernetes control plane managed by Amazon EKS as well as any managed compute resources created through the Amazon EKS API.

Worker node security groups are security groups applied to unmanaged worker nodes that control communications from worker nodes to the Kubernetes control plane.

Update: I don't want to rule out that there was a problem with the AWS CNI plugin and the node rolling update (triggered by the security group change in the launch template) solved the problem because the aws-node pods were restarted. We could not reproduce the error again.
But the main question remains: Which SG should be used here?

you have described input/outputs in docs
for input is will be:
If provided, all workers will be attached to this security group. If not given, a security group will be created with necessary ingress/egress to work with the EKS cluster.

for output it will be:
Security group ID attached to the EKS workers.


Java azure function using @BlobInput to auto bind data from Azurite Storage

Which service(blob, file, queue, table) does this issue concern?
blob
Which version of the Azurite was used?
latest V3
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
npm and dockerised version
What's the Node.js version?
10.13.0
What problem was encountered?
Java Azure Function using @BlobInput does not retrieve from Azurite storage.
Steps to reproduce the issue?
A Azure Function Event Grid Trigger which uses @BlobInput annotation, to auto bind the file using data.url in the event recieved by the function (see snippet)
@BlobInput(name = "zipfile", dataType = "binary", path = "{data.url}") final byte[] content
Currently tried with local installation via node installation of Azurite and latest dockerised version (docker run -p 32788:10000 mcr.microsoft.com/azure-storage/azurite)
File exists inside the storage, and can be downloaded, even seen using Azure Storage Explorer... The function is triggered via sending an event (e.g.http://localhost:7070/runtime/webhooks/EventGrid?functionName=MyAwesomeFunction), but the data URL used for the @BlobInput e.g. http://localhost:32788/devstoreaccount1/mytestcontainer1/test.zip never retrieves from azurite storage and remains null.
Is this because the URLs don't match the same pattern as when using Azure storage e.g. https://mystoragearea.blob.core.windows.net/mycontainer/test.zip, or something to do with the internals of the annotation implementation?
Have you found a mitigation/solution?
No, assistance required.

Hi raztiff
Sounds interesting. So can you get the blob from url http://localhost:32788/devstoreaccount1/mytestcontainer1/test.zip in storage explorer? If so, mostlikly the issue is not in Azurite side. I'm not sure it's because of the url format or not. Can you help open issue for Azure Function Event Grid Trigger? I'm not Java or Azure Function experts, they may help you more efficiency.

Hi @XiaoningLiu
Thanks for getting back tome, just getting around to reply now. I will put a an example project together and post here over the course of this weekend... I think it will just get bounced soon as mention Azurite. If it goes no where I will certainly create an issue there and link back to here in case it helps others.

Thanks @raztiff ! Welcome open the issue here when you have further findings. Will close this issue for now.


Add cache information for docker images

Currently caching of docker builds is not working on the CI

Coverage remained the same at 88.52% when pulling 3345d1c0587df97a52411e8597eb287c5132fd33 on optimize-docker into c797b3866638957c1005e801b367c762e2907d8e on master.


added ibm cloud install script and updated devcontainer to run script

Codecov Report

Merging #122 (6972c36) into main (0ad8af1) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #122   +/-   ##
=======================================
  Coverage   95.20%   95.20%
=======================================
  Files           5        5
  Lines         334      334
=======================================
  Hits          318      318
  Misses         16       16

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 0ad8af1...6972c36. Read the comment docs.


Update decompress fpga readme

Existing Sample Changes
Description
Restructured the readme to match the new template. Corrected formatting, added information on running the sample in DevCloud, fixed branding and some links, and significantly restructured the readme.
Fixes Issue#
External Dependencies
N/A
Type of change
Please delete options that are not relevant. Add a 'X' to the one that is applicable.

[X] Documentation

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Command Line
[x] VSCode

Adding @jimmytwei for notices.


Exception rendering favicon updates

We appear to throw this exception quite often on Firefox 88:
Failed to insert new messages
can't access dead object at https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1

Stacktrace:
X/<@https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1:234308
       = ./static/js/favicon.js line 49 column 18
X@https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1:234498
       = ./static/js/notifications.js line 140 column 5
C@https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1:393626
       = ./static/js/unread_ui.js line 61 column 5
N@https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1:702395
       = ./static/js/message_events.js line 128 column 5
Yn@https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1:528972
       = ./static/js/server_events.js line 128 column 17
success@https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1:529918
       = ./static/js/server_events.js line 222 column 17
u/n.success@https://zulipchat.com/static/webpack-bundles/69c5399e55706914a897.js:1:26107
       = ./static/js/channel.js line 98 column 9

This exception likely prevents completed rerendering of UI, so is important.

The exception appears to be this:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Dead_object

Removing the release goal label, since we fixed the release-critical part of this in #18466.


Extensions icons shrink on a particular width

Decrease the width of the extension viewlet slowly until you notice that the extension icons have been shrunk.
I find this a bit weird. In no other place do we shrink icon size to reduce space.
Was this intentional?
I suggest to either hide them or show them at full size.

cc @benibenj

It is intentional and as designed. Since Icons are important to represent extensions we do not want to hide them but when the space is less we shrink them.


interactsh: 1.0.2 -> 1.0.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/projectdiscovery/interactsh/releases.
meta.description for interactsh is: "An Out of bounds interaction gathering server and client library"
meta.homepage for interactsh is: "https://github.com/projectdiscovery/interactsh"
meta.changelog for interactsh is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.0.6 with grep in /nix/store/hpknihnai6z8iqhfksj6jp0mng1h2ayq-interactsh-1.0.6
found 1.0.6 in filename of file in /nix/store/hpknihnai6z8iqhfksj6jp0mng1h2ayq-interactsh-1.0.6

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
interactsh

Instructions to test this update (click to expand)

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

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/hpknihnai6z8iqhfksj6jp0mng1h2ayq-interactsh-1.0.6
ls -la /nix/store/hpknihnai6z8iqhfksj6jp0mng1h2ayq-interactsh-1.0.6/bin

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

1 package built:

interactsh

Maintainer pings
cc @HanEmile for testing.

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

1 package built:

interactsh


Add constant modifiers

Modifiers should be added for the built-in constants, such as:

PDF_WIDTH
AUTO_ROWS
AUTO_COLUMNS
BORDER_OFFSET
TEXT_OFFSET_Y
COLORS (to put color customization in one place)

#4


Android Device is not identified

SDK version: 3.3.2
Environment: Development
    "react": "18.2.0",
    "react-native": "0.71.7",

Are logs available?

[19:30:58] I | ReactNativeJS ▶ Running "xxxxxx" with {"rootTag":91}

[19:30:58] I | ReactNativeJS ▶ 'CustomerIO', { siteId: 'siteId',
                             │ apiKey: 'apiKey',
                             │ region: 'EU',
                             │ organizationId: '' }, { logLevel: 4,
                             │ autoTrackDeviceAttributes: true,
                             │ enableInApp: true,
                             │ trackingApiUrl: '',
                             │ autoTrackPushEvents: true,
                             │ backgroundQueueMinNumberOfTasks: 10,
                             │ backgroundQueueSecondsDelay: 30,
                             └ pushClickBehaviorAndroid: 'ACTIVITY_PREVENT_RESTART' }

[19:30:58] I | ReactNativeJS ▶ [CodePush] Sync already in progress.

[19:30:58] I | ReactNativeJS ▶ [CodePush] Checking for update.

[19:31:06] I | ReactNativeJS ▶ [CodePush] App is up to date.

[19:31:14] I | ReactNative ▶ [GESTURE HANDLER] Initialize gesture handler for root view com.facebook.react.ReactRootView{40d7e58 V.E...... .......D 0,0-1080,2208 #5b}

[19:31:14] I | ReactNative ▶ [GESTURE HANDLER] Gesture handler is already enabled for a parent view

[19:31:43] I | ReactNativeJS ▶ 'CustomerIO.identify'<EMAIL_ADDRESS>
[19:31:43] I | ReactNativeJS ▶ 'getRegisteredDeviceToken', 'The device token is not available.'

[19:31:43] I | ReactNative ▶ [GESTURE HANDLER] Gesture handler is already enabled for a parent view

Describe the bug

The Android Device is not identified
CustomerIO.pushMessaging().getRegisteredDeviceToken(); return error

The device token is not available.

To Reproduce

Expected behavior

Screenshots

Additional context

After downgrade the google-service version, the sdk works
classpath 'com.google.gms:google-services:4.3.15'


resin-image: calculate IMAGE_ROOTFS_MAXSIZE based on IMAGE_ROOTFS_SIZE

Instead of hardcoding IMAGE_ROOTFS_MAXSIZE, calculate its value using an
anonymous python function.
Signed-off-by: Fathi Boudra<EMAIL_ADDRESS>

Can one of the admins verify this patch?

Hi, thanks for the contribution.
lgtm

@resin-jenkins retest this please

@resin-jenkins retest this please

This change has been merged, thanks!


Error in modifyJestConfig

🐛 Bug report
Current Behavior
$ razzle test
C:\Users\Pontu\Desktop\code\TypeScript\razzle-canary\node_modules\razzle\scripts\test.js:22
throw err;
^
TypeError: Assignment to constant variable.
at C:\Users\Pontu\Desktop\code\TypeScript\razzle-canary\node_modules\razzle\config\createJestConfig.js:120:14
Expected behavior
Allow overriding of JestConfig as stated in the docs.
Reproducible example
Just use the modifyJestConfig from the canary docs and modify anything, e.g:
jestConfig.testEnvironment = 'node';
jestConfig.testMatch = ['/test/api/*.test.(ts|js)'];
Your environment

Software
Version(s)

Razzle
4.0.0-finch.8

Razzle Plugins
none

Node
12.18.4

Browser
Chrome

npm/Yarn
1.12.4

Operating System
Win 10

TypeScript
4.0.2

React
16.13.1

https://github.com/jaredpalmer/razzle/releases/tag/v3.3.0-canary.7

fixed


[WIP] Groovy Interpreter for Apazhe Zeppelin [ZEPPELIN-2176]

What is this PR for?
Groovy Interpreter
What type of PR is it?
Feature
Todos

[ Tests ] - Task
[ Documentation ] - Task

What is the Jira issue?
[ZEPPELIN-2176]
How should this be tested?
Follow the groovy interpreter documentation samples
Questions:

Does the licenses files need update? YES
Is there breaking changes for older versions? NO
Does this needs documentation? YES

@Leemoonsoo, I moved the repo under the user, used the latest master, now i have another error:
++ grep -e '"ref":' -e '"sha":'
++ tr '\n' ' '
+ COMMIT=
+ sleep 30
+ python ./travis_check.py dlukyanov
Traceback (most recent call last):
  File "./travis_check.py", line 36, in <module>
    commit = sys.argv[2]
IndexError: list index out of range
Build step 'Execute shell' marked build as failure
Putting comment on the pull request
Finished: FAILURE

Jenkins build script didn't handle well when source branch name of pullrequest is master.
I just updated the jenkins build script to handle the name master.
@dlukyanov Could you trigger jenkins again (close/open pr) and see if it checks correctly?

@Leemoonsoo, now I see status from travis )
And going to solve strange build errors...
Thanks!

The error
[ERROR] error An unexpected error occurred: "https://registry.yarnpkg.com/binary-extensions/-/binary-extensions-1.8.0.tgz: Request failed \"502 Bad Gateway\"".
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.3:yarn (yarn install) on project zeppelin-web: Failed to run task: 'yarn install --no-lockfile' failed. (error code 1) -> [Help 1]
[ERROR]

looks like temporary network problem. You can always restart the failed Job and see if it passing.

@Leemoonsoo , is it possible to restart jenkins checks after travis succeed?
I've never got travis success without restarting travis jobs manually.
https://travis-ci.org/dlukyanov/zeppelin/builds

Hello All, Asking for help with Jenkins:
Travis succeed:  https://travis-ci.org/dlukyanov/zeppelin
But jenkins failed: https://builds.apache.org/job/zeppelin-pull-request/604/console
Build https://travis-ci.org/dlukyanov/zeppelin/builds/213281815
[1] OK              https://travis-ci.org/dlukyanov/zeppelin/jobs/213281816
[2] Not completed   https://travis-ci.org/dlukyanov/zeppelin/jobs/213281817
[3] OK              https://travis-ci.org/dlukyanov/zeppelin/jobs/213281818
[4] OK              https://travis-ci.org/dlukyanov/zeppelin/jobs/213281819
[5] OK              https://travis-ci.org/dlukyanov/zeppelin/jobs/213281820
[6] OK              https://travis-ci.org/dlukyanov/zeppelin/jobs/213281821
[7] OK              https://travis-ci.org/dlukyanov/zeppelin/jobs/213281822
[8] OK              https://travis-ci.org/dlukyanov/zeppelin/jobs/213281823
1 job(s) failed, 0 job(s) running/pending
+ RET_CODE=1
+ '[' 1 -eq 2 ']'
+ '[' 1 -eq 2 ']'
+ exit 1

Looks like second test matrix succeeded after the manual restart.
In this case, you also need to trigger Jenkins again to check latest build status.
Simply close and reopen this PR will do that.

I tested last commit and it works well.
However the variable can't be read from the other paragraph.

This behavior is different from other interpreters, like spark (scala), python, r.
Is it intended?
Also, can we place document under /docs/interpreter/ instead of /groovy/, so website can show groovy documentation?

@Leemoonsoo Interesting) I did not knew that... i'll take a look how it's implemented...
With doc - i'll move it

@Leemoonsoo, Just committed changes.
Doc moved.
About shared vars - it will be a little different from scala/spark.
If you use groovy script variable (undeclared or annotated) it will behave like you mentioned
a="Hello world"
//or
@groovy.transform.Field String aa = "Hello world"
//or
g.put('aaa',"Hello world")

@Leemoonsoo , done. waiting for travis.

Thanks @dlukyanov for the contribution.
LGTM!

Merge to master if no further comments.

@AhyoungRyu, changes committed,waiting for travis

Thanks for addressing my comments! I left some minor comments again about "author name" in the source code and removing unnecessary log.info. Except these two things, LGTM 👍

@Leemoonsoo , @AhyoungRyu , any other comments?

Looks good to me :)

Merge to master if no further comments.


Fix build-watch

We were watching everything, which was causing an infinite loop if you changed a file. Avoid watching build output.

Thanks for the pull request @mramato!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

Thanks @mramato . I can confirm this fixes the infinite build loop in master.


Issue search features ideas: multiple filters, filter indicators, exclude filters

Gitea version (or commit ref): 1.1.1+2-g2854c8a
Git version: 2.12.2
Operating system: Windows Server 2012
Database (use [x]):

[x] MSSQL

Can you reproduce the bug at https://try.gitea.io:

[x] Not relevant

Log gist: Not relevant

Feature enhancement ideas for issue search:

[ ] Indicators to show which filters are active (and clicking each to remove it)
[ ] Allow multiple filters (such as multiple labels, or both labels and assignees)
[ ] Negative filters ("no label", "no milestone", or "no assignee")
[ ] Exclude filters (show issues that do not match a selected label or assignee)

Any plans to introduce this functionality?
Maybe in version 1.3.0?

There is no people work on that. Maybe 1.3.0.

Related to #3407

Negative filters ("no label", "no milestone", or "no assignee")

Yes please, I miss this very much ❤

More related issue filter and search feature requests: #791 #3409 #10777 #11009 #25979 #27195 #27572 #22899 #28177 #30722

I did not find this: Is there already a ticket requesting the "poster=me" filter functionality?
That way one can share a link for people to clean up their own issues.


RFC: Optional dynamic types for Legion fields

I've been thinking about how to do interop between Regent and Python tasks, and one of the challenges is that going in the Regent -> Python direction we lose type information. Currently for Python -> Python calls we pickle the field space, which includes type information, so that we can figure out what to do with the region when we unpack it.
One way to solve this that would generalize beyond just Regent and Python would be to introduce an optional type system into Legion. I realize this can become a bottomless pit, so for the moment I'm just going to suggest the minimal set of features needed to make my use case for Regent and Python work. In theory, this could be later adapted to be more general if there were a need for that.
My proposal is to use semantic tags to encode type information on fields. A type would be associated with a field, not a field space. Initially, I'm just interested in basic integer and floating point types: int8/16/32/64, uint8/16/32/64, flt16/32/64. If a type can't be described as one of the above, then the tag is just omitted, indicating that the type is dynamic.
Clearly, I could do this just as private contract between Regent and Python, so strictly speaking there isn't any need for a standard. However, it seems like the sort of thing that might be useful potentially in the future, as at the moment the runtime doesn't understand anything about the data it's throwing around.
Would anyone else here consider this to be useful, and if so are there any other features you want or comments on the design above?

It's worth noting that we already have some partial support for runtime types in Legion for the coordinate types of index spaces and we could probably extend some of the existing machinery to capture a limited set of (probably just POD) data types. Right now the runtime keeps around TypeTag information on index spaces:
https://gitlab.com/StanfordLegion/legion/blob/master/runtime/legion.h#L102
TypeTags currently encode the size of the coordinate type, it's signed-ness, and the number of dimensions in the index space. Most of this encoding is handled by Realm and Legion is just piggy-backing off it. The only reason not to go down this path is that we might have to start instantiating lots of templates for lots of types.
Another note: Legion currently only tracks the size of fields, but it would certainly be nice to give better type errors for things like dependent partitioning, but we could only do that with the same kind of dynamic type information.

Assigning to @lightsighter since (if we do this) the implementation will be mainly in Legion.

How many types are we going to support? What are they? What are the encodings?


publish on npm?

Sure. How?

[ ] make awesomeplete awesomer as a commonJS module
[ ] install npm (part of node or https://github.com/npm/npm)
[ ] Getting Started with NPM (as a developer)
[ ] :beers:

I remember I said I was going to PR this, but forgot about it. Sorry! I'll do it this evening.

@LeaVerou The package.json is fine these days, but you'll still need to publish it.

for those stumbling on this issue, here's the command to install the package in its current state:
npm install "LeaVerou/awesomplete#gh-pages" --save

I thought I'd save people the few mins search time I just spent

+1

+1

+1 for publishing on npm
Thanks @robotvert, your workaround works like a charm.

We have 1.1 now https://www.npmjs.com/package/awesomplete


[stable/redis Add JSON Schema

Signed-off-by: juan131<EMAIL_ADDRESS>Is this a new chart
No
Description of the change
This PR includes a basic JSON schema for the Redis chart. It doesn't cover all the possible values of the chart but just the ones that, in my opinion, are more likely to be modified.
This is valid for Helm 3 to validate some values and, at the same time, for Kubeapps to render a simple form so the chart containing it is easier to configure and deploy. See https://github.com/kubeapps/kubeapps/blob/master/docs/developer/basic-form-support.md for more information.
This is an example of the file rendered by Kubeapps:

Checklist

[x] Chart version bumped in Chart.yaml according to semver.
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @carrodher @andresmgot

@andresmgot Is this good to go now?

yes, it is. It's just that I am not a maintainer here so we need the /lgtm from @carrodher

/ok-to-test
/lgtm


Example IDs not showing in ID Mapper

Example IDs in the ID mapper won't show examples for anything that isn't a "PATRIC ID".  Use the dropdown box and select something that isn't "PATRIC ID".

@mandywil the main thing is to find out what's requirement, @aswarren probably has insight on this as he is the 'owner' of ID Mapper service.

Hi Andrew, I think if you could provide a list of example identifiers for each of the identifiers in the list (preferably all for the same sequence, though I don't think we implied anything of that kind) or -- even better -- tell me where I can find that information (so I learn :) ), then I can take care of this.
Thanks!

@dawenx I don't think we can / should provide separate examples for each of the id types.
Please remove the "Example" from under the dropdown menus.
Instead,   just add the following gray text in the text box itself.
Enter one or more identifiers separated by comma, space, or newline, e.g. Rv0001 Rv0002 Rv0003 Rv0004 Rv0005

ok, will do.

But its true, right, that one of the IDs has to be PATRIC.  What Marcus showed in the screenshot will not work (convert Drugbank ID to KEGG ID).  You could only convert Drugbank to PATRIC, and then PATRIC to KEGG.  So PATRIC ID needs to be in the example, unless this is no longer the way that ID Mapper is set up.

The screenshot was just to show that example IDs didn't show up unless it was a PATRIC ID.  So if I wanted to convert a PATRIC ID to a KEGG ID, it would show an example of a PATRIC ID but not of a KEGG ID.


Where is _getTokenArcMap()?

Where is security.ArcGISTokenSecurityHandler class setting token = self._getTokenArcMap() from? I don't see it in abstract.BaseSecurityHandler either.

It is in ArcGISTokenSecurityHandler  as only this security method uses it

Oops I found it. Thanks Mike.


Clean up images built during package-image tests

The images are not needed after the task run and should be deleted. Ideally this happens via defer so that they are also deleted when the test fails.

Transferring as a consequence of https://github.com/opendevstack/ods-pipeline/pull/722.


Gpt's answers is not relevant to the question

I don't know if this happen to others, but mine is completely weird. Everything working fine yesterday but now even a "hi" message from me will get an article about world war or something really random.

Send your code, maybe some can help you

that is true please see question and answer below
input: Hi there
response: [TalkAI.Choice(text: "!\n\nMy name is Vishnu and I'm a Senior Technical Support Manager at an IT-Services company. I'm responsible for providing technical support and guidance to my team, as well as escalating and resolving customer issues. I have over 10 years of experience in this position, and I'm adept at troubleshooting complicated technical issues and helping customers get their products and services back up and running quickly.\n\nMy technical expertise includes software installation, hardware troubleshooting, network configuration, cloud hosting, and more. I'm also experienced in customer service and can provide helpful guidance to my team, especially when dealing with difficult customers. I'm passionate about helping customers and building relationships with them to ensure satisfaction and loyalty.\n\nIf you have any questions about")]

Hi I found that when you say Hi there, the AI try to complete with rest of text. like in my example (Hi there, My name is ...). the solution is put ? at the end of your question.

This is true, it's giving me the same random asnwers even to normal questions.

This is true, it's giving me the same random asnwers even to normal questions.

put question mark (?) at the end of your questions.

Every single answer is random, am I the only one?

Fixed it, if you ever get random answers, check what input are you sending. For error I was sending an empty string.


Create an Individual Contribution Report for the milestone 2

Create an individual report for the milestone 2
Put that report in the wiki

Fisnihed. Here is the report: https://github.com/bounswe/bounswe2023group8/wiki/Ömer-Faruk-Çelik-‐-Milestone-2-Individual-Contribution-Report


Lazily resolve JsonSerializers in JsonNetSerializer

The current JsonNetSerializer implementation creates the default
serializers
within its constructor, which then calls ModifyJsonSerializerSettings.
This
means that a subclass of JsonNetSerializer cannot modify the
JsonSerializerSettings with fields set by the constructor, because the
order of
operations is:

Call subclass constructor with parameter A, which will set subclass
field A; field A will be used in ModifyJsonSerializerSettings.
Subclass constructor calls JsonNetSerializer constructor with
:base()
JsonNetSerializer constructor calls ModifyJsonSerializerSettings
as part of JsonSerializer.Create
ModifyJsonSerializerSettings makes use of default value for
field A, because it has not been set yet.
JsonSerializer constructor exits
Subclass constructor sets value of field A from parameter
A.

By using the Lazy class, we can ensure that ModifyJsonSerializerSettings is
called after the subclass constructor has exited, which allows fields to
be set and thereby used in ModifyJsonSerializerSettings. The unit test
in Connection.doc.cs has been expanded to demonstrate this capability
with a (fairly trivial) use case.

Hi @tsliang, we have found your signature in our records, but it seems like you have signed with a different e-mail than the one used in yout Git commit. Can you please add both of these e-mails into your Github profile (they can be hidden), so we can match your e-mails to your Github profile?

@karmi fixed author and email

Thanks for this @tsliang :+1:
For the most part, this LGTM.  However, calling a virtual method in a base constructor as we're doing here  when calling ModifyJsonSerializerSettings() is generally a bad idea, for reasons exactly like this.  Lazy instantiating the serializers feels like we're working around the problem rather than addressing it...but it might be the only way to fix this though.
Would love to get @Mpdreamz and @russcam s opinion on this.

@tsliang I've proposed an alternate solution in the PR attached above which also ties into the issue raised in #2183.

@gmarz I usually try to avoid construct-with-init (hence the use of Lazy) - IMHO classes should be fully initialized upon construction and not require a separate init method to be called afterwards, lest someone forget to call the init method after construction. Still, this should get the job done. What is the general ES policy on construct-with-init? Are those used a lot in the project?

What about custom resolvers? Right now I have problems setting my own :(

@SayliS what sort of problems?

IMHO classes should be fully initialized upon construction and not require a separate init method to be called afterwards

@tsliang I totally agree but I think this is a scenario where I can live with it, especially because it gives us a way to solve #2183 as well.  I like the idea of using the lazy constructs, but still feels like we're working around the problem rather than fixing the poor design.

What is the general ES policy on construct-with-init? Are those used a lot in the project?

We have no policy on this and not something we do a lot at all.  This may be one of the only instances.

@gmarz ok, that makes sense. I have proposed one other solution on #2189. Maybe you can take a look and see what you think? I think it'll solve the problem without requiring any significant changes in how the JsonNetSerializer is used. If it doesn't suit you, though, then let's just do #2189 and I'll close this PR.

@SayliS I'm assuming you mean adding your own custom converters?  You can do this by overriding ContractConverters in your custom serializer.  Is that not working for you?

@SayliS  is talking about Newtonsoft-Json Resolvers actually. The problem is that it is impossible to use dependency injection with virtual methods called in the base class.
Here is an example what is my problem and @SayliS
https://msdn.microsoft.com/en-us/library/ms182331.aspx?f=255&MSPPError=-2147217396

@mynkow gotcha.  Yea, that's exactly what this PR and #2189 is aiming to solve.  Let's close this issue and move the discussion over there to eliminate the redundancy.
@tsliang I'll pull these changes into #2189 if we choose to go this route.


6062 migrate user detail part 2

Issue
https://github.com/gravitee-io/issues/issues/6062
Description

continue the migration of user details screen
improve somme component
integrate UX feedback

Additional context

Gravitee.io Automatic Deployment
📚 View the storybook of this branch here


A11y_Visual Studio Code Client_Welcome Screen_Screen reader: Narrator/NVDA is not announcing the correct label name "show welcome page on startup".

GitHubTags
#A11yTCS; #A11ySev2; #A11yMAS; #A11yWCAG; #DesktopApp; #Visual Studio Code Client;#BM-VisualStudioCode-Win32-Nov2021; #WCAG1.3.1; #Win32; #Element:label;#ScreenReader; #NVDA; #Narrator;#Win10;#AINotInScope;
Actual Result
Narrator/NVDA is not announcing the correct label name of " show welcome page on startup".
Expected Result
Narrator/NVDA should announce the correct label name of "show welcome page on startup".
Environment Details
Application Name: Visual Studio Code Client
Version:1.62.1 (user setup)
Windows Version: Windows 10 (21H1)
Repro Steps
1)Start Narrator/NVDA.
2)Open Visual studio code editor
3)Using "Alt+H" key navigate to the "Help" menu bar option .
4)Using "Down" arrow key navigate to the "Welcome" item.
5) Make sure you have the following  setting in settings.json: "workbench.startupEditor": "gettingStarted"
6)Using "Alt+H" navigate to "Help" menu bar option and use "down" arrow key to navigate to "Getting started" and observe that the screen reader is announcing the correct label name of the "show welcome page on startup".
User Impact
Screen reader users will face difficulty as correct label name is not announce by the screen reader.

This is expected behaviour. Closing as invalid.
Screen reader always announces the name of the menu entry as it should. The "Get Started" label is appropriate here


Add test to compare local hashes with a list of servers

this test is executed only with the flag --comparehashes
this test needs a running local mainnet server
will be executed after dredd in the Docker Compose test

This looks great, except I think we should test all supported versions and not just v9 vs v10. (That is, I think we should test v9.61.3, v10.00, v10.0.1, etc.)

yep that's mean to setup an instance for each version.. it's possible right now.. just need to add a list of servers in CHECK_SERVERS variable. v9 means here to use the API v1 and v10 means to use the API v2. I will fix that.


questions

I have few questions:

does this code work with older paraview installations (5.0)? As far as I can see this is a rewrite on client with react+redux instead of jquery?
is this production ready?
(crosspost from mailing) The web visuailzer should work via npm installation? It does not work for me:

C:\Users\danie\AppData\Roaming\npm\node_modules\pvw-visualizer\bin\pvw-visualizer-cli.js:41
var pvPythonExecs = find(paraview).filter(function(file) { return file.match(/pvpython$/) || file.match(/pvpython.exe$/); });
                                   ^

TypeError: find(...).filter is not a function
    at Object.<anonymous> (C:\Users\danie\AppData\Roaming\npm\node_modules\pvw-visualizer\bin\pvw-visualizer-cli.js:41:36)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:139:18)
    at node.js:968:3

Mostly yes, but the client is expecting new RPC endpoints that are only present in Paraview/master and the next release (5.2).

Almost/yes as we don't expect to add or fix anything as far as we know. May still have a couple small bug fix.

It should, but we never run it on Windows, and until we bring back ParaViewWeb support in our binaries with Windows, it won't be easy to test. This should happen for the 5.2 release though.
That command line is just hiding the pvpython one. (See mailing list)

so it does not work with PV 5.0?

It won't fully work (missing color opacity handling) and you will run into performance issue (binary image stream as been improved).
5.2 fix all of those issues.


Streaming should return BadRequest if an Activity is not present

The streaming code should not throw Null Reference exceptions, and return 500s if the incoming body does not deserialize into an Activity, but rather should return BadRequest similar to the adapter.
Describe the solution you'd like
BadRequest returned instead of 500 internal server error
Additional context
Customer reported issue.

Fixed


Added CocoaPods installation

Thank you so much for your contribution. It's pretty clean.
But I prefer don't add the cocoapods documentation on the README for now. I have a issue with the statics resources (Xibs, Storyboards, and Images).
All the resources of available on the Pods folder, but I can't instantiate them on the code.
If you have a clue 😜

@hyperoslo can you guys give it a ✋?

Ohhhh, resources are a huuuuuuuuuuuge pain for CocoaPods!

I didn't know that before.... 😢


PWX-28163-pt2: Auto-TLS support

This fix adds support for Auto-TLS portworx setup  (gRPC using TLS certs signed by Kubernetes)
Summary of changes:

config - removed cacert:<path> and cacert-data:<[]byte>, replaced w/ certificate-authority-data:<base64>  (same as KUBECONFIG)
pxc config cluster set - adding connection validation, and --force option that skips the validation  (forces config)
kubectl pxc - will add Kubernetes CA and also validate connection and auto-detect SSL/TLS
Makefile - moved .PHONY at the top, fixing goimports build rules

Signed-off-by: Zoran Rajic<EMAIL_ADDRESS>
What this PR does / why we need it:
The Auto-TLS support for Portworx will switch gRPC endpoint to secure TLS/SSL mode, so pxc / kubectl pxc will stop working.
As a fix, we added validation of the gRPC endpoints which includes detection (and proper validation) of SSL/TLS gRPC as set up by Portworx.
Which issue(s) this PR fixes (optional)
Closes # PWX-28163  (part 2)
Note, this fix also relies on the https://github.com/portworx/px-installer/pull/1556  (part 1 fix)
Special notes for your reviewer:
Quick tests:
Added the validation of the endpoint-connection to Portworx
$ ./pxc config cluster set --name=default
error connecting to <IP_ADDRESS>:9020: dial tcp <IP_ADDRESS>:9020: connect: connection refused

$ ./pxc config cluster set --name=default --endpoint=<IP_ADDRESS>:9020
TLS validation failed for "<IP_ADDRESS>:9020": x509: certificate signed by unknown authority

$ kubectl config view --flatten --minify | awk '/certificate-authority-data:/{ print $2 }' | base64 -d > /tmp/ca.crt
$ ./pxc config cluster set --name=default --endpoint=<IP_ADDRESS>:9020 --cafile /tmp/ca.crt
Cluster information set

note, we are no longer "blindly" accepting the configuration, but will test it  (including the SSL cert validation)
there is also a new --force option, which will turn off the validation and "force" the blind acceptance of the config

Also added SSL validation (and importing Kubernetes CA) when running in the "plugin mode" as kubectl pxc :
$ kubectl pxc --pxc.v 3 cluster describe
INFO[0000] pxc version: (DEV)
INFO[0000] CurrentContext = kubernetes-admin@kubernetes
INFO[0000] Kubectl plugin mode detected
INFO[0000] Port forwarder using kubeconfig
DEBU[0000] port-forward: CurrentCluster: config.Cluster{Name:"kubernetes", CACertData:"", Endpoint:"", Secure:false, TunnelServiceNamespace:"kube-system", TunnelServiceName:"portworx-api", TunnelServicePort:"9020"}
DEBU[0000] port-forward: running "kubectl -n kube-system port-forward svc/portworx-api :9020"
DEBU[0000] port-forward: started
INFO[0003] Connected to localhost:35747
DEBU[0003] Read 40 bytes
DEBU[0003] Output: Forwarding from <IP_ADDRESS>:35747 -> 9020
INFO[0003] Connecting to Portworx at endpoint localhost:35747
INFO[0003] CurrentContext = kubernetes-admin@kubernetes
DEBU[0003] Appending custom CA certificate
DEBU[0003] Connecting to localhost:35747
DEBU[0004] Checking TLS certificate
DEBU[0004] Got the following TLS certificates from the endpoint:
DEBU[0004] > CN=system:node:foo4,O=system:nodes   (isCA:false, issud by CN=kubernetes)
DEBU[0004] Endpoint localhost:35747 successfully validated
DEBU[0004] Setting up TLS for grpc connection to localhost:35747
INFO[0005] Connected to localhost:35747
INFO[0006] Information about the node which was used: SDK Version[0.152.0] MoreInfo[build:042dcda5b4b8501771bf6f81f0b9b623a4108d23]
Name: px-cluster-bedd70f2-7fd7-435f-9aa5-0a7bb639f9b7
UUID: 0cd28d42-7da1-4fcf-a617-59b152b44c00
Status: Ready

Nodes:
Hostname  Version          Used     Capacity  Status  Kernel Version               OS
--------  -------          ----     --------  ------  --------------               --
foo2      <IP_ADDRESS>-042dcda  3.0 GiB  20 GiB    Ready   4.15.0-200-generic           Ubuntu 18.04.6 LTS
foo5      <IP_ADDRESS>-042dcda  3.0 GiB  20 GiB    Ready   4.18.0-240.1.1.el8_3.x86_64  CentOS Linux 8
foo4      <IP_ADDRESS>-042dcda  3.0 GiB  20 GiB    Ready   4.18.0-240.1.1.el8_3.x86_64  CentOS Linux 8
foo3      <IP_ADDRESS>-042dcda  3.0 GiB  20 GiB    Ready   5.4.0-135-generic            Ubuntu 20.04.5 LTS
DEBU[0008] Port forwarding stopped
DEBU[0008] Closing Ctrl-C capturing function

note, the messages from Checking TLS certificate till Setting up TLS for grpc are new messages (new code) added by this PR

Excellent PR! 👍🏼

Something is wrong with the tests. They work on master but not on the PR:
$ make clean all test
rm -f pxc kubectl-pxc
rm -rf dist
go build  -o pxc -gcflags "-N -l" -ldflags "-X github.com/portworx/pxc/cmd.PxVersion=v0.35.0-2-g0b510a1-pr_197 "
cp pxc kubectl-pxc
./hack/test.sh
error connecting to localhost:9921: dial tcp [::1]:9921: connect: connection refused
Failed to create target cluster
make: *** [Makefile:105: test] Error 1


Java Err while creating Container

Describe the problem
I get an Error.
I know its after "Starting Minecraft server" but maybe somebody can help me.
Container definition
docker run -d -it -e MEMORY=4G -p 25565:25565 -e EULA=TRUE -v /home/tomistkacke:/data itzg/minecraft-server:java17
Container logs
[init] Running as uid=1000 gid=1000 with /data as 'drwxr-xr-x 2 1000 1000 4096 Jul 22 17:54 /data'
[init] Resolving type given VANILLA
[init] Resolved version given LATEST into 1.21
[mc-image-helper] 18:07:20.232 INFO  : Created/updated 1 property in /data/server.properties
[init] Setting initial memory to 4G and max to 4G
[init] Starting the Minecraft server...
Error: LinkageError occurred while loading main class net.minecraft.bundler.Main
java.lang.UnsupportedClassVersionError: net/minecraft/bundler/Main has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0

Since you're not specifying a Minecraft version it's defaulting to latest which requires Java 21. Just didn't specify a tag on the image and it should work.

i tried Java17 after it failed without a Tag.
The Error message is the same

Make sure you have pulled the latest image.

I repulled the image and i can finally play some minecraft.
Thank you guys for your help :)


Document @ directives

Fixes https://github.com/aspnet/AspNetCore.Docs/issues/12739.

Also talked offline, going to update more docs since some directives apply to both Razor and Component files

Also @guardrex are we separating Blazor docs by version (preview4, 5, 6 etc.)?

No, we haven't been doing that, nor are we able to. What we've been doing is very rapidly ... within 24 hours rolling out the released preview docs with that release. We haven't been writing on the next preview release because we have no way to version the content.
AFAIK today, we aren't merging anything for Pre6 until Pre6 releases. We'll need to get @danroth27 to say if we're doing something different now (e.g., calling out in the text "This is bit only applies to the upcoming Pre6 release" ... something like that).

:up::date: and also want to be sure I get @ajaybhargavb's review.

:up::date: for @ajaybhargavb's final approval.

I got a verbal OK from @ajaybhargavb. Merging.

@guardrex re-reading your comment it seems like maybe I shouldn't have merged this yet? If so what do we do to fix it?

Moved to https://github.com/aspnet/AspNetCore.Docs/pull/12762.

Thanks!

Unless one of the main doc cats wants to take over the Blazor merges this time, I'll review, update (grammar+style only), and merge them on release day. I'll deal with any merge conflicts that arise. I also update the common sample app as soon as the NuGet packages land.
Typically within 48 hours after release, I make a full sweep and apply any needed touch-ups. The sweep is tracked at :point_right: https://github.com/aspnet/AspNetCore.Docs/issues/10717.
We've done this several times now, and it seems to be going well. So far, so good. :beers:


Add  support of write attribute in Leshan server demo

It would be good if we can have an option to perform write attribute on the demo server code, with operations Minimum Period, Maximum Period, Greater Than, Less Than, and Step.

Thx to @AButenko there is a REST API for this. (see #733).
To test it you can use :
curl -i  -X PUT  "http://localhost:8080/api/clients/yourendpointname/3/0/0/attributes?pmin=30&pmax=120"
curl -i  -X PUT  "http://localhost:8080/api/clients/yourendpointname/3/0/attributes?pmin=30&pmax=120"
curl -i  -X PUT  "http://localhost:8080/api/clients/yourendpointname/3/attributes?pmin=30&pmax=120"

Thx to @AButenko there is a REST API for this. (see #733) But still no UI.
To test it you can use :
curl -i  -X PUT  "http://localhost:8080/api/clients/yourendpointname/3/0/0/attributes?pmin=30&pmax=120"
curl -i  -X PUT  "http://localhost:8080/api/clients/yourendpointname/3/0/attributes?pmin=30&pmax=120"
curl -i  -X PUT  "http://localhost:8080/api/clients/yourendpointname/3/attributes?pmin=30&pmax=120"

Hello, I have the same issues and I tested the above command with Leshan Server demo but got the "INTERNAL_SERVER_ERROR(500)", also I tired this one”http://localhost:8080/api/clients/epname/3303/0/5700/attributes?pmin=30&pmax=120&gt=8.0&st=1.2”, I got “dquote>” from my terminal. I wonder do I need to modify the Leshan server demo? So what I am trying to achieve is the notify part, for example, if the temperature sensor value is over 8 then I get the obs notification, I already tried the SSEClient python script, it works and show all the obs results, so I wonder any instructions of how I can set to receive the obs result when the value is in certain scope? Thank you so much.

I just tested with a leshan-client-demo and I get :
HTTP/1.1 200 OK
Date: Wed, 29 Sep 2021 08:24:47 GMT
Server: Jetty(9.4.34.v20201102)
Content-Type: application/json
Content-Length: 116

{"status":"INTERNAL_SERVER_ERROR(500)","valid":true,"success":false,"failure":true,"errormessage":"not implemented"}

Meaning that all seems to works well at server side but we get a INTERNAL_SERVER_ERROR(not implemented) from the client.
This the expected behavior as Write Attribtues is not implemented for leshan client (see #534)


asm: update doc pseudotests for Python

Signed-off-by: Juanjo Alvarez<EMAIL_ADDRESS>

Don't mind about failure on .NET it's not related


Split the repository in two

Brought up in #227, this issue raises the possibility of splitting this repository in two.
In my opinion, Snabbdom is too bloated: my use case requires a custom h function; custom modules; and I have no use for thunks. The core patching algorithm (together with the vnode representation) is the only part of Snabbdom that I try to keep untouched in my own fork (I made some simplifications).
With this, I would like to propose the splitting of this repository in two repositories: something like snabbdom-core, which would mainly contain the core algorithm, possibly with vnode (I'd be okay with removing vnode from it too); and some other repository, say snabbdom-utils or even simply snabbdom, containing the h function, modules, thunks, DOM API, and anything else that might be useful for the "common" users of the library.
What do you guys think?

I like this idea, see my comment here: https://github.com/snabbdom/snabbdom/issues/227#issuecomment-275416178
Thinking of it a bit more, your proposal to me sounds more like "extracting" core than splitting. We could create snabbdom-core and then this same snabbdom package could consume it. This way one could now use snabbdom-core —like in your case—, and everyone else using snabbdom could continue to do so as of now.
I'd like to hear what people think would be the benefits of this change, apart from us being able to do import { init } from 'snabbdom-core'…

I'd propose using npm scoped packages if this is decided upon. Then the name of this "core" could be @snabbdom/core. It's a good way to differentiate what are "official" snabbdom packages and which are 3rd party snabbdom-foo.

I'd propose using npm scoped packages if this is decided upon. Then the name of this "core" could be @snabbdom/core.

Brilliant 💯

If you put the core in a separate package, could you also take the opportunity to have diff and patch be two separate functions?  It seems like a nice way to make it more "low-level"
I'm not acquainted with the snabbdom core so there are probably some considerations that I'm not aware of.

@whmountains I'm not sure of the impacts of splitting diff and patch; it seems to me like it would be a whole different algorithm, since right now Snabbdom patches the DOM as it diffs it (only iterating through the structure once). In any case, I believe that that could be done at a later time. On another note: you could also then create a whole new snabbdom-diff-patch-core, although that might be over-modularising. 😄

I'm not sure of the impacts of splitting diff and patch; it seems to me like it would be a whole different algorithm

I'm pretty sure that splitting the diffing and patching in snabbdom is going to lead to more downsides than upsides. Combining the 2 processes, to my best knowledge, has a lot to do with the performance that snabbdom achieves. A lot of the hook/module behavior is dependent on knowing a lot of information about the process as a whole, and my own investigation to split the 2 usually lead to trade-offs around the types of vNode/module hooks that are achievable. One thing I've always loved about snabbdom is its modules and the ability to create very cool things using modules. So personally, I'd be very unexcited to see that behavior change.

@nunocastromartins @TylorS Okay that's fine.  Point well taken.  I had actually edited my comment to take out that part but it looks like you all got it via email anyway.

I don't understand this proposal. In practice snabbdom is already split. snabbdom.js has only init and vnode (vnode is just 2 or 3 lines of code). h is already a separate thing. So are the modules and thunk.

@staltz But when I do npm install snabbdom it comes bundled with everything - when I only want the core algorithm. The core algorithm itself is, in my opinion, the selling point of this library: it is a generic approach to updating the DOM where nothing is assumed, not the API to interact with the DOM; not how to update the properties/attributes of an element. Everything else in this repository: the h function; the modules; exist to simplify the interaction with the core algorithm but, ultimately, they're nice defaults to interact with the algorithm. I'm not saying they shouldn't exist, just that they should exist in a separate repository: with separate tests and with different concerns.
Expanding on what I mean by different concerns:
I believe that the core algorithm should strive to be absolutely generic (so long as performance doesn't suffer), no assumptions made on how the user will use the library; whilst the repository containing the default h functions, modules, etc. may make some assumptions that people here already seem to make, e.g. quoting you in regards to a different concern, with which @paldepind agreed:

I believe snabbdom is meant to be used in particular functional style where this wouldn't be a concern.

I understand where you're coming from @nunocastromartins. The core is definitely more general purpose than some of the modules. But what are the benefits to doing this? npm install snabbdom-core will take a bit less disk space than npm install snabbdom?

Like I said previously I like the idea, but if there are no benefits (other than less disk space since bundle size should be the same) I pretty much agree with @staltz and @paldepind.

I understand your reasoning; simply wanted to bring this up in any case.
It's just that I tend to like to keep things small and focused: when I find that there is extra bloat, I just feel the need to remove it 😄. It's not so much about the disk space but the fact that I'm "importing" to my project things that I know I won't ever need.
Another thing I can't understand when installing this package is the future of the project. Will this project grow? Will more modules be added? Will I get even more files that I have no use for when I update the package in the future? These are the kind of questions I raise before installing a package, and this is why I believe the project would benefit from splitting concerns. Keep the project focused: the core in being as lean, generic, and efficient as possible; the rest in providing a set of tools tailored to be used in a specific style (say, for functional programming). Note that these are two distinct concerns, reason why I believe they should be split into two repositories.
Again, I know that in the end I'm just saving a whole meaningless bytes; but I suppose that my concern is a bit more philosophical. 😀

@staltz is right, Snabbdom is already split in practice because you can cherry pick what modules you want to include. Don't like thunks? Don't include them in your bundle and you'll be as lean as if they never were in the first place.
I used Snabbdom early sketches to learn how this virtual dom theory works in practice, so I am very grateful to @paldepind for that ❤
But you (@nunocastromartins) are not the only one who thinks Snabbdom has become bloated. I also think so too, even if it's just from a philosophical point of view.

Correct me if I'm wrong but, if I'm interested in using Snabbdom not as an end-user, i.e. someone who actually builds UIs, but as a package developer who wants to use Snabbdom's core algorithm behind the scenes and someone npm installs my package, won't all the Snabbdom files that I have no need for be downloaded by that user (since I have snabbdom as a dependency)?
I'm not certain of this (maybe I should only upload a bundle of my project anyway?), but should this be the case, then I'd feel bad for all the extra bloat I just put on anyone using my package. 😄

@nunocastromartins

won't all the Snabbdom files that I have no need for be downloaded by that user (since I have snabbdom as a dependency)?

Yes, but only during development. Your users will be likely using a tool such as Browserify to generate a bundle that contains only the parts of Snabbdom you've actually included in your package.

Is this really about a few kB of disk space in node_modules of your project? That's not bloat, it's micro-bloat, or nano-bloat. The majority of npm packages have things like these. Inspect other libraries, maybe other libraries may have serious bloat (I recall installing a small library and downloading >500 MB). Not this library.
I would close this issue and go forward because we're not seeming to get consensus.

Yes, but only during development.

I'm aware. I understand what all of you have been saying.

I would close this issue and go forward because we're not seeming to get consensus.

I agree. I'll just close this; reopen it if you feel the need to.

@nunocastromartins I don't have a strong opinion on this issue. I was trying to help out with your query. That is, while there may be nano-bloat or not in this library, you don't have to worry about users of your package downloading the whole of Snabbdom, since it's just a development time dependency.
I actually feel closing this issue was a bit premature. It's been opened only for two days.


[Bug] Fix backend addteammembers api

Describe the bug
There is problem with addTeamMembers api. Because it frontend is unable to add team members and throwing errors. fixing it is most important to fix frontend problems.
To Reproduce
Steps to reproduce the behavior:

open thunder client or postman
use auth token and try to addteam members.
it is not giving any response.

Expected behavior
when try to add team members with auth token. we should able to add the data.
Have you read the Code of Conduct?
yes

@kushal98 can you please assign me this issue

please go ahead with the issue @Hemu21 .
Happy Learning :)

@Kajol-Kumari I Created the PR. I solved that issue can you please check it.

depratizing it to level 1 as its just a typo fix


"iat" needs to be a number

I decided to release the fix for this as a "non-breaking change". It is "breaking" in a sense because code will now error that sets "iat" or "exp" to strings (usually stringified numbers). However I think that this is a very rare usecase for this library since using expiration in unit tests would require fuzzing with the clock which is always hard. Even if someone hits this error, maybe it is a good thing to require them changing these values from strings to numbers after all and these changes should not take too long and are pretty obvious and easy to find. I hope I did not create too much of a fall out. If I did, please complain here.


mutalisks stuck bug.

Unwanted, the mutalisk flock stays at home.

Solved: they just want to arrive at the same time as overlordtransports, these are extra slow as upgrades are not used atm.
No action.


Revert "Use the RECV_STATUS op in ALTS handshake RPCs"

Reverts grpc/grpc#20929 and is a workaround for https://github.com/grpc/grpc/issues/21142

I misread the issue about this being a probable root cause and not a definite root cause. After the tests finish running, we should see if this revert fixes the failures

The test that's failing is a test that was added in #21142 itself, so it's a definite root cause. I can reproduce the failure locally (oddly, reproduces with the make build, but not bazel RBE), but it will take some more time to root cause.

added more details in https://github.com/grpc/grpc/issues/21142
This revert is still good to unbreak master before the fix

Merged the fix forward in https://github.com/grpc/grpc/pull/21193, so closing this PR


add application button on home page for super user and added status field in application details

Date: 6/01/2024
Description
This PR adds application button on home page for super user and also addds status field in application details page.
Documentation Updated?

[ ] Yes
[x] No

If your feature adds a new API, then documentation related to the feature like API-Contracts, and Data-models  must be updated.
Breaking Changes

[ ] Yes
[x] No

If your feature introduces breaking changes or if something is missing, please mention the related issue tickets.
Development Tested?

[x] Yes
[ ] No

Confirm whether the changes have been tested locally during development.
Tested in Staging?

[ ] Yes
[x] No

Indicate whether the changes have been tested in the staging environment.
Under Feature Flag

[ ] Yes
[x] No

Specify if the changes are currently under a feature flag.
Database Changes

[ ] Yes
[x] No

Please add a screenshot of the UI change


Drop clang-4.0 package from Travis

apt-get is complaining that it doesn't exist.  Seems like all we need is the
llvm-toolchain-trusty-4.0 package.

Hmm no.  Despite the description on llvm.org, llvm-toolchain-trusty-4.0 doesn't seem to provide a clang-4.0 binary, at least not under that name...


Test more formats and add support for them

Probably through ffmpeg

Added "manually" support for .mkv, but should polish it more in order to support the most possible formats, also for the output video