Install snowpack for development failed.

Quick checklist

[ ] I am using the latest version of Snowpack and all plugins.

What package manager are you using?
npm
What operating system are you using?
Linux
Describe the bug
I am encountering a problem installing snow pack because I am always getting an err, Anybody with a suggestion can help. Image description below

Steps to reproduce
I am being told that the library is no longer supported.
Link to minimal reproducible example (optional)
https://github.com/mugishap/postguy

I can only commit. Same issue!

Just encountered the same problem. Still no solution available?


Add Footer

Fixes #3
Test URLs:

Original: https://www.sunstar-foundation.org/en/
Before: https://main--sunstar-foundation--hlxsites.hlx.live/en/
After: https://issue-3--sunstar-foundation--hlxsites.hlx.live/en/

As the differences found are expected and non-disruptive I will merge this PR now. If we need additional changes we can always make them later.


Bump dependencies

We need to use fast_stats on a Rails 6 app. This PR includes the necessary changes.

Hmmm, ya I need to setup an Azure Pipelines on this. I see there's no functional changes though.


The method setApplicationContext(ApplicationContext) is undefined for the type MessageDispatcherServlet

public ServletRegistrationBean messageDispatcherServlet(ApplicationContext applicationContext) {
		MessageDispatcherServlet servlet = new MessageDispatcherServlet();
		servlet.setApplicationContext(applicationContext);
		servlet.setTransformWsdlLocations(true);
		return new ServletRegistrationBean(servlet, "/ws/*");
	}

In the above method,
servlet.setApplicationContext(applicationContext);
gives an error

The method setApplicationContext(ApplicationContext) is undefined for the type MessageDispatcherServlet

when checked the API of MessageDispatcherServlet, there isn't  any method setApplicationContext.
Please Help.

Which guide did you see this in? Each guide has its own gitthub repo, so please open an issue in the corresponding tracker.


Remove unused and unmaintained modules

Thanks for updating these. We are indeed still using these regularly and though some are outdated and do not need to be maintained (from our end): 3D4DImageConversion, DTITensorNormalization, DWI_NIFTINRRDCONVERSION, ImageNoise, anything in Unsupported and one of the curve comparison (not sure which is right one of the 2). Thanks also for updating the dtiprocesstoolkit
Originally posted by @styner in https://github.com/NIRALUser/niral_utilities/issues/30#issuecomment-1043409452
The following modules should be removed and associated external project archived.
Ideally, the relevant README files should be updated to:

include History section summarizing when each was functionality was added and by who
which tools can be used to perform similar operation

List of modules to retire:

[ ] 3D4DImageConversion

Integrated in CMakeLists.txt here. See also https://github.com/NIRALUser/3D4DImageConversion

[ ] DTITensorNormalization
[ ] DWI_NiftiNrrdConversion
[ ] ImageNoise

Integrated in CMakeLists.txt here. See also https://github.com/NIRALUser/ImageNoise.git

[ ] Unsupported/CorrespondenceEvaluator
[ ] Unsupported/DMDBiomarkerTool
[ ] Unsupported/IntensityRescaler
[ ] Unsupported/TextureBiomarkerTool
[ ] Unsupported/TransformDeformationField

@styner Did we properly capture the list of functionalities that could be retried ?


Edit patient button is not working

Actual Results
Nothing happens when the Edit button is clicked.
Expected results
The system should display the Edit Patient page.
Steps to reproduce
Login > Social module > Search and select a patient > Click Edit button
Alternatively:
Login > Clinic module > Search and select a patient > Click Edit button
Screenshot/Attachment (Optional)
A visual description of the unexpected behaviour.

 Edit patient button is not working


Add hack/verify-spelling.sh script and Makefile target

As noted in https://github.com/kubernetes-sigs/descheduler/pull/429, it would be good to add this (along with hack/.spelling_failures for known failures). This is copied from k8s.io/kubernetes

/lgtm


Class Team OneNote

When adding more than one member to a Class Team, the users are not given access to the Class OneNote. If I add the members one at a time this issue is fixed.

@davidlatunoavid  - thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:  https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.

@officedocsbot close


Update vendor to include firestore adapter deps

Unfortunately firebase.google.com/go pulls in a lot of dependencies. I tried to strip down to the required dependencies by installing it on my $GOPATH and then adding them to the vendor, but it still pulls in equal number deps to the project. Trying checking if you already have the following packages already in your $GOPATH.

cloud.google.com/go
firebase.google.com/go
google.golang.org/{api, genproto, grpc}
...

Additionally, I had to update certain existing standard dependencies in the vendor that were conflicting with the internal usage in the fetched deps.

We should definitely add ones that are required, but also want to make sure we aren't adding any that may be unrelated. I already got the build working without including a75ba13, but that could be because I already had those deps in my $GOPATH from before. Want to confirm if I need to merge that commit.

Without including a75ba13 I was not able to build on my Linux system, but was able to build on my windows.

Thanks for confirming, I will include it.


draft pre-flight check plugin baked into draft init

TBD: name for the plguin
Draft is built on other modular components to help developers create apps that will end up on Kubernetes. In some cases, you'll already have some dependencies. It'd be nice for draft init to not only check for these dependencies but also start or run installation steps if necessary. So for example, if minikube is not running, then start it. If Tiller is not installed, run the helm init command. We as a team have talked about creating a plugin that checks for the dependencies and configures them if they are not already running/installed. Then, we'd like to make that a "default" plugin that runs as part of the draft init command after the client side steps in the draft init logic.

I wonder if this pre-flight plugin should also handle the case where we want to install certain plugins when draft init is called too, for example the ongoing work in #2. Would that make sense for this plugin?

I have been thinking a bit about

I wonder if this pre-flight plugin should also handle the case where we want to install certain plugins when draft init is called too, for example the ongoing work in #2

And have been looking into how other projects like docker are doing this. This sort of workflow isn't actually enforced at the tooling level, but at the packaging layer. If you fetch the latest .pkg of docker, it will install all of the "blessed" plugins into your $PATH. This gives vendors the power to distribute different packages with a completely different set of plugins, all set and ready to go for their platform.
I'm wondering if we should do the same here for this plugin: we can bake in the default draft pre-flight and draft pack-repo plugins into our distributed packages at https://github.com/Azure/draft/releases/latest, and then tie them into helm init but just warn if those plugins aren't present, giving vendors the option to provide their own pre-flight and pack-repo plugins (or not provide them at all if it's irrelevant). "Batteries included, but removable" rings a bell here.
What do you think about that?

Yeah I like that experience. If I'm not mistaken, this is what we talked about a few days ago in our meeting. Given that in the default experience that the user doesn't have to even know those are plugins, I'm 100% on board. 👍

Yep! Just commenting this publicly for posterity (also because I tend to forget things over time). :)

I still think a pre-flight check plugin would be useful, though the architecture has significantly changed since we opened this ticket.
I'll leave it up to Michelle on whether or not we want to close this ticket based on the current architecture. :)


Update dependencies + deprecations

This PR

Updates dependencies via the Kotlin-Components submodule
Cleans up android api deprecations as a result of bumping compileSdk to 33

Closes #264

Adding the blocked label until components release train with Kotlin 1.8.0 is made


Sorted collections

This introduces two new sorted collections within a SortedCollections subpackage as initially
discussed in #1.
These sorted collections maintain their order by internally maintaining in-memory B-trees which allows them to balance the performance benefits of contiguous buffers and trees.
Currently, this contains an implementation of SortedSet and SortedDictionary which are designed to mimic the API of the standard library’s Set and Dictionary as closely as possible and provide additional methods and properties specific to sorted collection types.
Checklist

[x] I've read the Contribution Guidelines
[x] My contributions are licensed under the Swift license.
[x] I've followed the coding style of the rest of the project.
[ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
[ ] I've added benchmarks covering new functionality (if appropriate).
[x] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
[ ] I've updated the documentation if necessary.

Our initial benchmark numbers are promising, in most cases we come close to, when not exceeding, the performance at large collection sizes compared to std::map

Merging to feature branch feature/SortedCollections.


button and text hardly readable (protected albums)

I'm using the Protected Albums plugin and when I get to the point to enter the password, the form looks like this:

Is there any chance to fix this in the theme or has this to be fixed in the plugin?

Thank you for fixing this!


[Ret] Last few fixes, all seals and Guardian, Alpha!

Censure dot wasn't able to crit

Hand of Light (mastery) didn't include Inquisition or 8% target dmg debuff

Templar's Verdict was calculated in the wrong way

Two-handed Weapon Spec didn't apply correctly to Judgements

Add Seal of Insight, Seal of Justice and Seal of Righteousness

Add travel time to Holy Wrath and Hammer of Wrath

Add Guardian of Ancient Kings (!)

Mark as Alpha 😮

Would really love for #670 to be merged so I can add the auto reforger. Without it I have to set the exp-cap to 4% because of our 10exp-glyph.


Use offical pre commit hooks

Closes #705
This pull request changes the pre-commit hooks to use the official hooks that are suggested to be used for all the projects that already have hooks, instead of using poetry run <xxx> for everything, which can fail because nothing specifically ensures that the projects we use are installed on the host system, which is particularly an issue for pre-commit.ci, which never installs anything locally and only uses virtual environments and such for running the hooks.
This might be up for debate and I realize I should probably have made this a separate change, but I also added codespell to the project, which I've found incredibly helpful in the past in some of my own projects that helps with spelling issues. If required I could make this change in a new pull request instead.
In the idea of moving everything to the official pre-commit hooks, I came across the fact that pyright doesn't have an 'official' so to say pre-commit hook, but their offical docs say to use a community-maintained wrapper hook (https://github.com/microsoft/pyright/blob/main/docs/ci-integration.md), which is the one I changed it to use. Personally I think it might be unwise to use pyright as a pre-commit hook, because I was noticing that it makes commits incredibly slow. I would rather run pyright manually or let CI find the issues for me than slowing down committing, but I've left it in this pull request and would suggest we put this issue up for debate.

Oh rats, I based this off my forge branch. I'll try to fix that.

Adding do-not-merge flag, pending further discussion in the related issue.

This might be up for debate and I realize I should probably have made this a separate change, but I also added codespell to the project, which I've found incredibly helpful in the past in some of my own projects that helps with spelling issues. If required I could make this change in a new pull request instead.

Yeah, let's do a separate PR here, for now, it should be using locally installed version, with codespell dependency added to pyproject.toml (under lint group).

Personally I think it might be unwise to use pyright as a pre-commit hook, because I was noticing that it makes commits incredibly slow. I would rather run pyright manually or let CI find the issues for me than slowing down committing

Feel free to set SKIP=pyright environment variable, which will skip pyright's hook when running pre-commit. You can export SKIP=pyright and then run pre-commit normally, or do it only once with SKIP=pyright pre-commit run.
Most editors even provide a way to set global environmental variables automatically once you enter a project, so you could probably get away with adding it to your editor's config, and not even having to do so manually.
I'm not entirely against removing it from pre-commit, as I do agree that it is pretty slow, however that would have to be discussed further in another issue.

Because those repositories are being used in the system installation runs it's doing now as well, it's just that first off, with changing to the official pre-commit hooks, the pre-commit.ci integration is able to function properly. This means integration parts like auto-fixing pull requests is able to work properly if you enable that option and the hooks generating errors have auto-fix support. Secondly, pre-commit will make sure that the exact versions specified will run instead of being dependent on the system's version of these projects to be up to date and or pinned to exact versions specified. With the pace some of these projects are changing, it's very easy for the system installation to get out of date.
An additional reason that is very weak and mostly for me is that then I don't have to install a bunch of things globally on my machine just because I want to be able to contribute to this particular project.

Because those repositories are being used in the system installation runs it's doing now as well, it's just that first off, with changing to the official pre-commit hooks, the pre-commit.ci integration is able to function properly. This means integration parts like auto-fixing pull requests is able to work properly if you enable that option and the hooks generating errors have auto-fix support. Secondly, pre-commit will make sure that the exact versions specified will run instead of being dependent on the system's version of these projects to be up to date and or pinned to exact versions specified. With the pace some of these projects are changing, it's very easy for the system installation to get out of date.
An additional reason that is very weak and mostly for me is that then I don't have to install a bunch of things globally on my machine just because I want to be able to contribute to this particular project.

Is codespell a new dependency that should be included pyproject.toml? If not, how is the version of the tool locked to a known working version and how is it installed?

The version is locked in the .pre-commit-config.yaml to the specific revision specified in the hook declaration. Pre-commit handles installing the correct version, and when the pre-commit.ci integration is enabled, it will auto-create pull requests for updating all hooks to the newest stable version on a schedule, being either weekly, monthly, or quarterly.

Is codespell a new dependency that should be included pyproject.toml? If not, how is the version of the tool locked to a known working version and how is it installed?

The version is locked in the .pre-commit-config.yaml to the specific revision specified in the hook declaration. Pre-commit handles installing the correct version, and when the pre-commit.ci integration is enabled, it will auto-create pull requests for updating all hooks to the newest stable version on a schedule, being either weekly, monthly, or quarterly.

the pre-commit.ci integration is able to function properly.

Since we are not yet using this... I have to ignore this comment as a potential benefit.

Secondly, pre-commit will make sure that the exact versions specified will run instead of being dependent on the system's version of these projects to be up to date and or pinned to exact versions specified.

From where is would it pull these pinned versions?

An additional reason that is very weak and mostly for me is that then I don't have to install a bunch of things globally on my machine just because I want to be able to contribute to this particular project.

poetry install is already handling this.
I remain unconvinced that these additional repositories are providing extra value.

the pre-commit.ci integration is able to function properly.

Since we are not yet using this... I have to ignore this comment as a potential benefit.

Secondly, pre-commit will make sure that the exact versions specified will run instead of being dependent on the system's version of these projects to be up to date and or pinned to exact versions specified.

From where is would it pull these pinned versions?

An additional reason that is very weak and mostly for me is that then I don't have to install a bunch of things globally on my machine just because I want to be able to contribute to this particular project.

poetry install is already handling this.
I remain unconvinced that these additional repositories are providing extra value.

I'm going to go ahead and close this PR based on strong dismissal opinions from both myself and ItsDrike. We are not yet using pre-commit.ci so I see no need to fix our pre-commit to support that. Currently, GitHub Actions is our CI system.
Certainly, the typo fixes and codespell tool are welcome, so feel free to submit those in another PR. Provided that codespell can have its version locked down (preferably in poetry.lock).

I'm going to go ahead and close this PR based on strong dismissal opinions from both myself and ItsDrike. We are not yet using pre-commit.ci so I see no need to fix our pre-commit to support that. Currently, GitHub Actions is our CI system.
Certainly, the typo fixes and codespell tool are welcome, so feel free to submit those in another PR. Provided that codespell can have its version locked down (preferably in poetry.lock).

Oh! I missed the short-term adoption of pre-commit.ci that recently transpired, so some of my comments above were uninformed. Still, I will leave this closed because this PR bundled a bit too much together and the local hooks are less of a maintenance burden than adopting external dependencies that run a single command.


Create Github runner to execute xpk on vm.

This is a great unit test to verify that xpk can be setup on a tpu vm. We want to run this on the newest available vm that we expect customers to use and then potentially support previous versions as well.

Doesn't need to be TPU


[3.x] Check ConvexPolygonShape2D point count before calcuating moment of inertia

3.x version of #47675.

Thanks!


how to hide Circular Floating Action Menu

do you have any idea how to hide whole of menu with another button click?

Yes, my menu is actionButton, and just do this:
actionButton.setVisibility(View.INVISIBLE);


Can´t parse uint64 and float32

For some types the parsing procedures are wrong.
Examples
uint64
It is parsed as an int, so the following code
@["--a=18446744073709551615"].getOpt (a: 0u64)

results in Parsed integer outside of valid range [ValueError]
float32
It is parsed as an int,
@["--b=1.0"].getOpt (b: 0f32)

results in invalid integer: 1.0 [ValueError]

Fixed by https://github.com/juancarlospaco/cliche/pull/6


Use simple DI for ModuleLauncher

squashed, rebased, and merged as https://github.com/spring-cloud/spring-cloud-data/commit/5b5f256cfafd6db7c5c9988f0335486b7bb1afe4


Add the Inside version to the Collision enum

Objective
I think the 'collide' function inside the 'bevy/crates/bevy_sprite/src/collide_aabb.rs' file should return 'Some' if the two rectangles are fully overlapping or one is inside the other. This can happen on low-end machines when a lot of time passes between two frames because of a stutter, so a bullet for example gets inside its target. I can also think of situations where this is a valid use case even without stutters.
Solution
I added an 'Inside' version to the Collision enum declared in the file. And I use it, when the two rectangles are overlapping, but we can't say from which direction it happened. I gave a 'penetration depth' of minus Infinity to these cases, so that this variant only appears, when the two rectangles overlap from each side fully. I am not sure if this is the right thing to do.

Thank you for looking into this! It may be related to #1980 and #1982

Yes! Thanks, I couldn't find these, even though I tried.
But I don't think that 'Intersecting' is the right name for the new variant as all of the variants describe some kind of intersection and this can cause some confusion I think.

@NathanSWard You are right, I updated the pull request. Removing the Option also made the code less complex.

bors try

@horvbalint Can you comment on https://github.com/bevyengine/bevy/issues/2373? :) I'd like to see if we can merge this in.

@alice-i-cecile I commented :) Please check if my changes are logically correct, I don't want to mess things up for others :)

bors r+

bors r+


Create solution.py (509. Fibonacci Number)

Description of Change
Added python solution
Checklist

[ ] Added detailed description of changes.
[ ] Relevant documentation/comments is changed or added.
[x] Added file name matches File name guidelines.
[ ] PR title follows semantic commit guidelines.

Ok


RAILS_ENV Expectations!

RAILS_ENV, What a mess!
I see @beyondtheteal's logic in #141, RAILS_ENV is set to "production" in the  staging environment and this contradiction screams MISTAKE!
@Ross-Hunter #141, I see the order we would gain by picking one method for setting environment variables.
We need some rules to sort out what we expect RAILS_ENV to do.
Requesting Proposals

Please provide your own expectations in a comment and in the form of a rule set.
Add a bullet for any additional rules
Bullets should be tight and tidy.  Long unorganized rambles will be ignored so I suggest bullet points and logical organization

This proposal stands until something better is proposed.
I propose:
Production Environment
Setting RAILS_ENV='production'  should:

only be defined and set in Heroku's lgrow production environment settings
turn dotenv OFF
render the environment vars in .env useless in the production environment
switch the application to the production database
turn testing OFF
RAKE?

Staging Environment
Setting RAILS_ENV='staging' should:

only be defined and set in the Heroku lgrow-staging instance's settings
turn dotenv OFF
render the environment vars in  .env useless in the staging environment
switch the application to the staging database
turn testing ON
RAKE?

Development Environment
Setting RAILS_ENV='development' should:

only be set in your development .env file
turn dotenv ON
switch to a development database
turn testing ON
RAKE?

What about RAKE what does RAKE do or not do in staging and production?

My proposal is to follow 12 Factor configuration and rely on environment variables directly. With Heroku, you are essentially forced to do this anyway.
TL;DR: I don't believe there is a currently a problem and the existing of the config/staging.rb file is causing confusion.

I understand deployment as a process that can be separated into development, testing, and production. When I saw that Heroku was separated into Review, Staging and Production, I thought development, testing, and production.  But I'm not so sure that Review and Staging are what I think they are.
Can you fill-in the definitions for me?

From the RAILS_ENV side, best practice is that the test environment is the local unit testing environment. development is the local development environment and any deployed environment is production.
Any differences between deployed environments should be controlled by environment variables. It's best to keep the differences between environments minimal so that deploying to production is not a gamble on whether or not it will work correctly.
Heroku is fantastic at promoting this configuration and it's a huge advantage of the platform.


Adding support for namespaces and clashing names in skin io

( as a possible fix for https://github.com/mgear-dev/mgear4/issues/172)
Adds a function to handle namespaces ( : ) and clashing names using full names ( | ) by replacing those characters with ones that Windows supports by default.
This is a bit of a gross approach, and maybe using a directory structure to handle it would be better, but this is an approach we're using and fixes all our name clash issues

Thanks for the PR @CatAndDogSoup  I will check it ASAP

@CatAndDogSoup  do you know if this approach is only working on windows? have you tried it with Mac or Linux?


switch to SC version 0.24.0

align SB with SC's API calls and schema changes

@sgherbst please run whatever additional checks make sense on this.


DS2 small model WER

I ran DS2 small model in evaluation mode without using language model. WER is around 29%. I saw in the default base_params num_epochs is 12. Is this performance expected? Thanks!

What data set have you used for evaluation?

I used librivox-dev-clean, the default dataset in the example_config for small model.

I got 32% after training. Maybe it does not have any problem due to the small network and dataset compared with the original DS2 and Librispeech.

It looks so. BTW that was from default "num_epochs"=12. I ran 28 epochs and then got 25.2%.


Feature Request: Unit Test

While Muuri is an upstream project and should be responsible for it's own unit test I believe that integration test would still be very valuable.
Additionally a sample project may be useful for developers to be able to quickly test changes they make in a live environment.

I'm going to start working on this issue when I get a chance. Might be a week or so before I have a PR ready.

@wSedlacek Thanks for the suggestion and for working on this! I'll check if I can make some time to look into the other feature requests in the coming 2 weeks 🚀


chefdk/0.13.21

announced via https://discourse.chef.io/t/released-chef-dk-0-13/8325
using https://www.chef.io/blog/2016/03/16/weve-moved-our-software-distribution-to-packages-chef-io/

$ chef -v
Chef Development Kit Version: 0.13.21
chef-client version: 12.9.41
berks version: 4.3.2
kitchen version: 1.7.3

Also, check out cask-repair, it makes Cask updates like this quite easy (details in CONTRIBUTING)


fixed php-fpm install phalcon ext bug

I completed the 3 steps below:

[x] I've read the Contribution Guide.
[x] I've updated the documentation. (refer to this for how to do so).
[x] I enjoyed my time contributing and making developer's life easier :)

I can you please squash your commits and add phalcon to php-worker container

@kideny Thank you!


Display tileId on tile hover (or on tile select)

It would be nice if the tileId of a given tile could be displayed in the status area of L-Ed (bottom right corner), something like:

Otherwise, it's hard to tell which tile a given tileId corresponds to without manually counting into tileset with __tileX and __tileY. In Tiled, it is displayed whenever you click a tile in the tileset under Tile properties:

Good idea :) Would definitely be useful!

Done, will be there in next update.


Syntax highlighting

Is it possible to implement pretty R syntax highlighting in r4intellij?

we already have customizable highlighting. I like the idea of linking out inside-r.org. The html-copy is part of intellij and we get it for free (I think). Do I miss something which your link can do?
In addition the long awaited reformatter is just being tested and will be part of the next release

closing because does not seem relevant anymore


Not Working on macOS 15.2 Beta2(24C5073e)

This project works on macOS 15.2 beta 1. However, when I updated to macOS 15.2 Beta 2, it isn't working properly. After uninstalling it, i cant reinstall it again.

same

same. really hope that this can be updated to work for macOS 15.2 beta2.

I rarely use Mac afterwards, so I have hardly paid attention to this project. Sorry for the long wait.
Check the repo homepage for the latest available method. If it doesn't work for you, please let me know.


Improve definitions of 'spectral window range maximum' & 'spectral window range minimum'

Within our 2024.05.17 dev call, we discussed that 'spectral window range maximum' (VIBSO:0000015) & 'spectral window range minimum' (VIBSO:0000016) must be considered fixed parameters of the Raman spectrometer (specifically the detector), which are part of the metadata of a Raman dataset.

[ ] Check the ISO docs for definitions of these parameters
[ ] rewrite definitions accordingly
[ ] maybe subsume under a more fitting parent class

I just discussed with @RainerStosch .
Physically the spectral window is determined by a combination of instrumental parameter, such as the excitation wavelength and several properties of both the grating and of the detector.
The grating separates spatially the different wavelengths.
The detector captures a part of them and responds to them according to the own response function, which is significantly different from zero within its own detection range.
The spectral window recorded in an experiment is given by a subset of the "spread window" by the grating and of the "response window" by the detector, thus narrower than both.
The experimentalist normally chooses the center of the spectral window by rotating the grating; the width/minimum/maximum are then calculated by the software on the basis of the spectral resolution of the grating and of the detector width. (If it is not enough, several overlapping windows are combined to cover the entire desired spectral range, similarly to a panorama photo.)
Conclusion: we suggest to keep it simple and leave the definitions as they are.


nheko: 0.6.4 -> 0.7.1

DONT MERGE, this PR should work once https://github.com/NixOS/nixpkgs/pull/73940 is merged.
Motivation for this change
https://github.com/Nheko-Reborn/nheko/releases/tag/v0.7.1
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Oh, it has been released, finally. I had prepared the update but you beat me to it.
I don't remember having problems with boost but I'm on 20.03, here's the commit maybe it can be of help.

One difference I spotted is the use of boost171 vs boost172 ( 17x is used here). I tested with boost171 and still the same error. @rnhmjoj what's the meaning of:
    "-DBoost_NO_BOOST_CMAKE=TRUE"

here?
It fixes the issue but it feels hacky to me considering https://github.com/NixOS/nixpkgs/pull/73940 ...

@doronbehar Did you try #85254?

@veprbl https://github.com/NixOS/nixpkgs/pull/85254 works just as well as https://github.com/NixOS/nixpkgs/pull/73940

I've been using 0.7.0ish for some days, i don't remember having an issue with mtxclient building?

Looks reasonable compared to the version I'm running, and nothing missing in that inputs list according to @deepbluev7

@GrahamcOfBorg build nheko mtxclient tweeny

I've been using 0.7.0ish for some days, i don't remember having an issue with mtxclient building?

Nevermind, I remember it now.
@doronbehar You may find this useful - I'm running and talking with this as we speak. Specifically I think the part that fixes your boost issue is the symlinkJoin
https://github.com/bqv/nixos/blob/live/overlays/nheko.nix

That's no good - I'm pretty sure that your final derivation references both boost.dev and .out - Not good for closure size.

@veprbl the build won't work until either #85254 or #73940 are merged. I don't want to add:
    "-DBoost_NO_BOOST_CMAKE=TRUE"

Which fixes the issue here because that's not a real fix. Please :pray: consider merging either #85254 or #73940.

@doronbehar I can't just blindly merge any of these and I haven't had time yet to look at those in detail. I propose you use the workaround for now with a comment that it can be removed once #85254 and #73940 are resolved.

Btw, you may want to include this commit in your package: https://github.com/Nheko-Reborn/nheko/commit/d94ac86816f9f325cba11f71344a3ca99591130d
I accidentally broke room joins in 0.7.x and released 1.7.1 just before I noticed that.
It will take a bit until the next release, that includes this fix.

@doronbehar I can't just blindly merge any of these and I haven't had time yet to look at those in detail. I propose you use the workaround for now with a comment that it can be removed once #85254 and #73940 are resolved.

OK, done.

Btw, you may want to include this commit in your package: Nheko-Reborn/nheko@d94ac86

Thanks @deepbluev7 for joining in and suggesting this, I appreciate your effort you are putting in Nheko.
Unfortunately, and I may need help with this @veprbl , I get this error:
applying patch /nix/store/cgmic2qicjfqzjgddg2f7a2pabmmspma-room-ids-escape-patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- a/src/ChatPage.cpp
|+++ b/src/ChatPage.cpp
--------------------------
File to patch:
Skip this patch? [y]

I tried to play with the stripLen argument to fetchpatch but it didn't help.

My bad: I tried to patch mtxclient instead :/.

@GrahamcOfBorg build nheko

I'm testing the darwin build with:
@GrahamcOfBorg build nheko

The build error you get on Darwin looks like your clang is too old to support the deduction guides for std::array. We are only testing clang-6 in our CI. (Not sure, how you guys handle compiler versions.)

OK @deepbluev7 that certainly should be possible to fix but this needs a real Darwin machine. I added a comment that links here.
Besides that all is ready.

@GrahamcOfBorg build nheko

(Last force push removing obsolete comments)
@GrahamcOfBorg build nheko

@deepbluev7 clang-6? That's old.. @doronbehar you can specialcase darwin to use pkgs.llvmPackages_6.stdenv and might have better luck

@doronbehar you can specialcase darwin to use pkgs.llvmPackages_6.stdenv and might have better luck

@bqv That's not that trivial, because we use mkDerivation by qt5... It's too much effort for me to test this, as my only means are GrahamcOfBorg.

@doronbehar, sorry I don't know the details because I'm not a cmake user. It should disable the code responsible for finding boost. I think it's an acceptable workaround until boost is fixed.

@bqv clang-6 is just the minimum version, anything newer should work (or even apple clang in Xcode 10.2+). But the CI job used clang-5, which seems to be too old.

@bqv That's not that trivial, because we use mkDerivation by qt5... It's too much effort for me to test this, as my only means are GrahamcOfBorg.

libsForQt5.mkDerivation is very simple. Basically you can replicate it just by adding wrapQtAppsHook. See pkgs/development/libraries/qt-5/mkDerivation.nix.

@GrahamcOfBorg build

The Darwin build still fails, but differently:
https://logs.nix.ci/?key=nixos/nixpkgs.85922&attempt_id=1d08c688-e7d7-45c0-bb00-c25f49ce9651

@doronbehar The current build fails, because some C++17 library features are only available in macOS 10.14.

@doronbehar The current build fails, because some C++17 library features are only available in macOS 10.14.

Thank you @deepbluev7 for replying. If so, we are almost there but I'm afraid I couldn't find a way to mark it as broken only if the minimum macOS version is not met... Hence I'm marking it as broken for every macOS version for now. If anyone knows a way to do that, please tell me. For now, the PR should be ready.

/ping @veprbl


React-Native Androd build failed: Self-suppression not permitted

Dear team,
Currently, I'm trying to run a sample App using Agora Video Call SDK.
I have followed all of the instructions from this page https://docs.agora.io/en/Video/start_call_react_native?platform=React%20Native but still failed to run the App on Android.
I'm using Macbook M1 Pro with Monterey
React-native: 0.66.4
React-native-agora: ^3.5.3
The error log from Terminal:
What went wrong:
Execution failed for task ':app:packageDebug'.

A failure occurred while executing com.android.build.gradle.tasks.PackageAndroidArtifact$IncrementalSplitterRunnable
Self-suppression not permitted

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

Get more help at https://help.gradle.org

BUILD FAILED in 11s
error Failed to install the app. Make sure you have the Android development environment set up: https://reactnative.dev/docs/environment-setup.
Error: Command failed: ./gradlew app:installDebug -PreactNativeDevServerPort=8081
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:packageDebug'.

A failure occurred while executing com.android.build.gradle.tasks.PackageAndroidArtifact$IncrementalSplitterRunnable
Self-suppression not permitted

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

Get more help at https://help.gradle.org

BUILD FAILED in 11s
at makeError (~/React-Native/AgoraVideoCall/node_modules/execa/index.js:174:9)
at ~/React-Native/AgoraVideoCall/node_modules/execa/index.js:278:16
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async runOnAllDevices (~/React-Native/AgoraVideoCall/node_modules/@react-native-community/cli-platform-android/build/commands/runAndroid/runOnAllDevices.js:109:5)
at async Command.handleAction (~/React-Native/AgoraVideoCall/node_modules/@react-native-community/cli/build/index.js:192:9)

info Run CLI with --verbose flag for more details.
====================================================
Please advise.

Sorry for the late reply, have you tried our example?


Despite attrs having relevant stubs. There is unresolved attribute reference error in the docstring !

Look at the image a snapshot in PyCharm.
There's linting error unresolved attribute reference in the docstring. Whereas defining classes with __init__ method gives no such error.
Look at the underlined attribute attribute_with_attr.

import attr

@attr.s
class UsingAttrs:
    """
    class created using attrs shows linting error.

    Attributes
    ----------
    attribute_with_attr : str
    """
    attribute_with_attr: str = attr.ib(default='some_string_value')

class NotUsingAttrs:
    """
    class created normally does not show linting error.

    Attributes
    ----------
    attribute_without_attr : str
    """
    attribute_without_attr: str

    def __init__(self, param='some string value'):
        self.attribute_without_attr = param

I believe PyCharm does its own type hinting outside of mypy.  https://www.jetbrains.com/help/pycharm/type-hinting-in-product.html

Should we open a ticket for somehow supporting PyCharm so we can dup this sort of ticket to that, or do we just want to say we don't support PyCharm and close this?  I suspect this will come up again…

Should we open a ticket for somehow supporting PyCharm so we can dup this sort of ticket to that, or do we just want to say we don't support PyCharm and close this? I suspect this will come up again…

I Posted same issue on SO, @hynek answered it as well : https://bit.ly/2N4KXV2. Looks like he wants it to be closed @wsanchez.

OK, closing


Fix release github action

Fixes #10
Seems to work
https://github.com/MrTanoshii/rusty-autoclicker/actions/runs/3451736545

@nozwock please review if you're available~

You should just merge, I can't approve PRs

Was introduced by #30


Show warning when merging conflicting crossing nodes

Context
I've just cleaned up a bunch of crossing nodes with multiple conflicting values (e.g. crossing=unmarked;marked or crossing=traffic_signals;uncontrolled. I was wondering where these came from and realised the history of each showed the change coming from iD. So I figured there must be some implicit user action that's producing these values, rather than people explicitly setting them.
After a bit of playing around I realised what it is. The simplest example:

Create two nodes, both highway=crossing. One is crossing=traffic_signals, the other is crossing=unmarked.

Merge the two nodes. The merged node now has crossing=unmarked;traffic_signals (or the other way around), and no longer has a proper icon.

Depending on the other tags on the existing nodes, there can also be other conflicting merged values like crossing:markings=no;yes.

From looking at some other changesets that have created values like these, I suspect a common sequence is:

A standalone highway=crossing node exists on a road way. In this example, it's a crossing=uncontrolled.

Someone wants to add a crossing way with more accurate tags. They draw a new way either side of the crossing node but without connecting it to the existing node.

The way is marked as a crossing using presets, in this case "Crossing With Pedestrian Signals".

There's now an error shown that the way intersects a highway without a crossing node.

Because of the proximity, clicking "Connect using a crossing" connects the new crossing way to the existing crossing node, but merges the two objects' tags. This results in the crossing node now having crossing=uncontrolled;traffic_signals.

Request
When merging two nodes with different crossing= tags, would it be possible to show a warning about invalid values? Similar to the "crossing highways" warning above.
I'm thinking something like "Crossing type contains multiple values" with an option to choose one of the two existing values on the node.
Prior art
When performing the same merge operation in JOSM, it pops up a dialog like this:

I’ve encountered a lot of these improperly merged nodes too. Thanks for diagnosing the issue. I think iD should simply avoid modifying the existing node’s crossing tag. This will result in some inconsistency between the way and node, but that would’ve been an issue anyways had the user manually connected the way to the node in the first place.
A validator rule could detect inconsistencies between the way and node, regardless of how the node was created. (Rapid has implemented this validator rule.)


Create a workflow to copy javadocs to gh-pages branch

We need to copy javadocs to gh-pages branch to use them as api references. Automating it through workflow is the best way.

Fixed this issue


Day40: 'Two Sum IV - Input is a BST' solution

Two Sum IV - Input is a BST
https://leetcode.com/problems/two-sum-iv-input-is-a-bst/
Given the root of a Binary Search Tree and a target number k, return true if there exist two elements in the BST such that their sum is equal to the given target.

Example 1:
Input: root = [5,3,6,2,4,null,7], k = 9
Output: true
Example 2:
Input: root = [5,3,6,2,4,null,7], k = 28
Output: false


[BUG] - Cannot Download

Description
Newest Update cannot be downloaded on Windows?
Reproduction steps
Virus detected, cannot download? Windows 11
Image file

Version
1.3.3
OS
Windows
Tool
A1111's webUI

This is weird, downloading this zip on my Chrome 116 only shows a warning of uncommon download.

Try this out and let me know what message the browser displays. SD-Prompt-Reader-1.3.3-post.1-dev.1-Windows-x64.zip

Download now, but shows this:

Thanks for the fix!

Since I haven't spent hundred bucks on code signing, this warning is expected. I will change released exe to this version later to prevent more people from encountering the same situation as you did.


[RO images] moving yum rpms rsync RW dir

This PR closing this issue psss#988
yum install in RO images, is failing yum to complete
scripts on EDGE/Automotive images.
Updating yum commands to use --installroot=/root/pkg

/packit test

Thanks for the patch. The proposed approach does not seem to be right: It would basically mean that for all provisioned guests the extra rsync installation would have to performed, which would be an unnecessary step which would slow down the execution.
We've shortly discussed the use case on today's hacking session and agreed on a rough outline how things could possibly work:

The provision step should include check for rsync (and make it available if not present)
This would/could handle CoreOS use case as well (rpm-ostree install rsync && reboot)

@Yarboa, could you please confirm whether something like this would make sense / be acceptable for your use case?

Thanks for the patch. The proposed approach does not seem to be right: It would basically mean that for all provisioned guests the extra rsync installation would have to performed, which would be an unnecessary step which would slow down the execution.
We've shortly discussed the use case on today's hacking session and agreed on a rough outline how things could possibly work:

The provision step should include check for rsync (and make it available if not present)
Ack
This would/could handle CoreOS use case as well (rpm-ostree install rsync && reboot)

@psss  Since there are two options if rpm -q rsync does not exist

not installed
installed but on different directory, yum need to query it

So code need to check if image is RO or RW is it?
WDYT?
I will be grateful for pseudo idea, thanks

@Yarboa, could you please confirm whether something like this would make sense / be acceptable for your use case?

Yes, it is,

@psss Since there are two options if rpm -q rsync does not exist

not installed
installed but on different directory, yum need to query it

So code need to check if image is RO or RW is it? WDYT?

Couldn't we detect if we need to install rsync by checking existence of /usr/bin/rsync?
And detection around if it is an rpm-ostree based distro (RO distro) I would make based on rpm-ostree command availability, rather then something else? That should provide quite a proof it is ...
WDYT?

I will be grateful for pseudo idea, thanks

@Yarboa, could you please confirm whether something like this would make sense / be acceptable for your use case?

Yes, it is,

@psss Since there are two options if rpm -q rsync does not exist

not installed
installed but on different directory, yum need to query it

So code need to check if image is RO or RW is it? WDYT?

Couldn't we detect if we need to install rsync by checking existence of /usr/bin/rsync?
And detection around if it is an rpm-ostree based distro (RO distro) I would make based on rpm-ostree command availability, rather then something else? That should provide quite a proof it is ...

OK we could search for ostree
[  ! -f /usr/bin/ostree ] as an identifier for non tree
[ -f /usr/bin/rsync ] || [ ! -f /usr/bin/ostree ]  || yum install rsync -y
We could go with the regular line, we can change the rpm check for rsync to [ -f /usr/bin/rsync]
In case it return code 127
[ -f /usr/bin/local/rsync ] || yum install --installroot=/root/pkg rsync -y && ln -sf /root/pkg/bin/rsync /usr/local/bin/rsync
I do not like it, but requires two executions of ssh if it is ostree based image
@thrix is it accepted?

WDYT?

I will be grateful for pseudo idea, thanks

@Yarboa, could you please confirm whether something like this would make sense / be acceptable for your use case?

Yes, it is,

What about something like the following?
rsync --version --quiet || yum install -y rsync || \
    yum install --installroot=/root/pkg -y rsync && ln -sf /root/pkg/bin/rsync /usr/local/bin/rsync

This would:

do nothing if rsync already installed (either /usr/bin/rsync or /usr/local/bin/rsync)
try to install to the default location first and if this fails:
install to the custom installroot and symlink to /usr/local/bin

Seems to me as the most straighforward way from the options brainstormed so far.

What about something like the following?
rsync --version --quiet \
    || yum install -y rsync \
    || yum install --installroot=/root/pkg -y rsync && ln -sf /root/pkg/bin/rsync /usr/local/bin/rsync

This would:

do nothing if rsync already installed (either /usr/bin/rsync or /usr/local/bin/rsync)
try to install to the default location first and if this fails:
install to the custom installroot and symlink to /usr/local/bin

Seems to me as the most straighforward way from the options brainstormed so far.

Thanks, one liner indeed

What about something like the following?
rsync --version --quiet \
    || yum install -y rsync \
    || yum install --installroot=/root/pkg -y rsync && ln -sf /root/pkg/bin/rsync /usr/local/bin/rsync

After testing it
It is trying on ostree version
yum install rsync -y

Download packages and then fail on
RPM: error: can't create transaction lock on /usr/share/rpm/.rpm.lock (Read-only file system
since it is failing to write in RO directory
and then move to the
yum install --installroot=/root/pkg -y rsync

so it is doubles the time of rsync install FYI

This would:

do nothing if rsync already installed (either /usr/bin/rsync or /usr/local/bin/rsync)
try to install to the default location first and if this fails:
install to the custom installroot and symlink to /usr/local/bin

Seems to me as the most straighforward way from the options brainstormed so far.

Thanks, one liner indeed

so it is doubles the time of rsync install FYI

Ah, I see, so the packages (and package metadata) are fetched twice. So what about checking for the presence of the rpm-ostree command as @thrix suggested and picking the suitable install method based on the check result?

* The `provision` step should include check for rsync (and make it available if not present)

* This would/could handle CoreOS use case as well (rpm-ostree install rsync && reboot)

@Yarboa @psss  I like this approach and maybe using the check for rpm-ostree for checking OSTree based system (as @thrix suggested). For me is what makes more sense. Most of the OSTree based system (Fedora IoT, RHEL for Edge, RHIVOS...) won't have yum or dnf installed, so trying to install into an alternative root directory with any of those tools will fail on those systems.
Not sure if that solution (rpm-ostree install rsync && reboot) will work right now on all the provisioners :thinking:

@psss @thrix
Is this PR, not planned for review? do you have other PR not dependent with rsync?

@Yarboa hi, it is, @psss should be back today ... we will discuss what we decided here. We are not really happy now with the solution, looks kind of hackish :/

/packit test

/packit test

@Yarboa, note that the failure on rawhide is expected, it's podman/selinux problem under investigation.

@Yarboa, @lukaszachy, @thrix, so are we ok with the current check for /usr/bin/rpm-ostree to decide how to perform the rsync install? Or any idea of a better way how to detect it's a read-only/coreos distro?

/packit test

/packit test


EKS nodes lose readiness when containers exhaust memory

What happened:
When our applications consume too much memory, K8s nodes on EKS clusters lose readiness and become completely inoperable for extended periods of time. This means that instead of being rescheduled immediately, pods remain stuck in a pending state, resulting in noticeable downtime. This does not happen on GKE clusters.
What you expected to happen:
Nodes should never lose readiness, instead the containers should be restarted and/or the pods should be OOMKilled.
How to reproduce it (as minimally and precisely as possible):

Provision a single node EKS cluster running an EC2 instance type of m5.large.
Apply the following deployment resource.apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
  labels:
    app: stress-ng
  name: stress-ng
spec:
  selector:
    matchLabels:
      app: stress-ng
  template:
    metadata:
      labels:
        app: stress-ng
    spec:
      containers:
      - args:
        - -c
        - stress-ng --bigheap 0
        command:
        - /bin/bash
        image: alexeiled/stress-ng:latest-ubuntu
        name: stress-ng

Observe the node lose readiness.$ k get nodes
NAME                        STATUS   ROLES    AGE     VERSION
ip-10-11-0-6.ec2.internal   NotReady   <none>   2m14s   v1.24.7-eks-fb459a0

Anything else we need to know?:
We've traced the cause of this problem to the memory reservation of kubelet, which is set by the bootstrap script here. https://github.com/awslabs/amazon-eks-ami/blob/eab112a19877122e46a706d3a91d42b85218f268/files/bootstrap.sh#L452
This is what kubeReserved is set to by default on this cluster.
  "kubeReserved": {
    "cpu": "70m",
    "ephemeral-storage": "1Gi",
    "memory": "574Mi"
  }

Note the memory reservation, on a GKE cluster this value would be 1.8Gi https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture#eviction_threshold.
When running with kubeReserved.memory="574Mi", kubelet logs indicate PLEG errors during memory exhaustion and the node loses readiness.
[root@ip-10-11-0-6 ~]# journalctl -u kubelet | grep -i pleg | grep -v SyncLoop | grep -v Generic
Jan 09 20:01:32 ip-10-11-0-6.ec2.internal kubelet[27632]: E0109 20:01:32.726177   27632 kubelet.go:2013] "Skipping pod synchronization" err="PLEG is not healthy: pleg has yet to be successful"
Jan 09 20:06:25 ip-10-11-0-6.ec2.internal kubelet[4077]: E0109 20:06:25.149411    4077 kubelet.go:2013] "Skipping pod synchronization" err="PLEG is not healthy: pleg has yet to be successful"
Jan 09 20:08:01 ip-10-11-0-6.ec2.internal kubelet[12256]: I0109 20:08:01.432398   12256 setters.go:546] "Node became not ready" node="ip-10-11-0-6.ec2.internal" condition={Type:Ready Status:False LastHeartbeatTime:2023-01-09 20:08:01.424711657 +0000 UTC m=+1.288302571 LastTransitionTime:2023-01-09 20:08:01.424711657 +0000 UTC m=+1.288302571 Reason:KubeletNotReady Message:[container runtime status check may not have completed yet, PLEG is not healthy: pleg has yet to be successful]}
Jan 09 20:08:01 ip-10-11-0-6.ec2.internal kubelet[12256]: E0109 20:08:01.635341   12256 kubelet.go:2013] "Skipping pod synchronization" err="[container runtime status check may not have completed yet, PLEG is not healthy: pleg has yet to be successful]"

The problem does not occur when the node is bootstrapped with kubeReserved.memory="1.8Gi". Also seems to be fine running kubeReserved.memory="1Gi", but that value is arbitrary and not tested.
Environment:

AWS Region: us-east-1
Instance Type(s): m5.large
EKS Platform version: eks.3
Kubernetes version: 1.24
AMI Version: ami-0c84934009677b6d5
Kernel: Linux ip-10-11-0-6.ec2.internal 5.4.219-126.411.amzn2.x86_64 #1 SMP Wed Nov 2 17:44:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Release information:

BASE_AMI_ID="ami-0c90e1cacda57dac6"
BUILD_TIME="Sat Nov 12 04:15:25 UTC 2022"
BUILD_KERNEL="5.4.219-126.411.amzn2.x86_64"
ARCH="x86_64"

Noting that the problem occurs in both containerd and docker based AMIs.

Thanks for the detailed issue! We definitely need to revise our kubeReserved values, memory being a simple function of $MAX_PODS isn't cutting it.
The GKE values seem fairly conservative to me; reserving ~23% (up from ~7% currently) of the available memory on smaller instance types isn't a change we should make without our own testing.

Also seeing the issue: #1098
Will close my issue in favor of this more detailed issue. It's good to see some attention on this, it's worrisome to see this happen on production workload when you use all AWS-recommended / default settings and when you always thought the EKS + EKS AMI combo would protect you against these kind of situations thanks to the automated configuration of memory reservation. Even more so after reading the K8S docs about system reserved memory, kube reserved memory, soft eviction, hard eviction: you feel confident there would be multiple barriers to breach before getting into that situation. Yet here we are.
Thanks for looking into this @cartermckinnon!
For what it's worth, here are the settings we ended up using to protect against this:
systemReserved: 300Mi
evictionSoft: memory.available: 3%
evictionHard: memory.available: 2%
These values are completely empiric and far from having been scientifically determined, nor were they tested on a lot of instance types / architectures / container runtimes / etc, but they did the job for us :)

Same here, alt ought in my scenario are many small pods, every time that there's an OOM outside cgroup the node goes down and generally takes half an hour to be back.
A good default value will be hard to set without sacrificing the node capacity, but I think a good step may be like @maximethebault with karpenter, allowing we to configure it with an LT, similar to using containerd instead of docker or setting max pods (which by the way, we use at 110 with Cilium CNI).
Related https://github.com/aws/karpenter/issues/1803#.

CC @bwagner5

There are some discussions about this on the following issues.

https://github.com/awslabs/amazon-eks-ami/issues/782
https://github.com/bottlerocket-os/bottlerocket/issues/1721

Experienced the same problem with t3.medium instances.
Can somebody explain why this happens even though there is reserved memory for kubelet? It feels strange that although there is reserved memory for the system processes, a single pod cam easily kill the whole node.

Just experienced this as well today in our test environment, also with t3.medium instances. If this is not going to be solved in the near term I think there should be a big warning somewhere in the EKS docs (or even in the console) that t3.medium and other instances affected by this are not suitable to run production workloads, cause this could have been a disaster if it was production.

Already experiencing this in eks v1.23 and m5.8xlarge instance type . When is it actually going to be resolved ? I still feel like we are not hitting the root cause of this issue.

Also seeing this issue on t3.medium on stock settings using AWS Managed Nodegroups (1.24). Without using prefix delegation.
The discussion on how to deal with user defined --max-pods is very important, because this is gaining popularity (also through adoption of Karpenter). There are several tickets on this, but generally we need an alternative to using the fixed max-pod-eni.txt values.
But this issue is more critical as it is happening also with stock settings, t3.medium having 17 pods, using (latest) standard AL2 ami. With some memory pressure, it will flap readiness or even crash.

@jortkoopmans For me it helped to consiquentually check if all pods have memory limits configured correclty.
Its important that the configured requested memory equals the configured limit memory.
Example:
 resources:
    requests:
      memory: "400Mi"
    limits:
      memory: "400Mi"

In the future, with cgroups v2 and with the finalization of Quality-Of-Service for Memory resources, it will probably be possible to configure memory limits higher than the requested memory as cgroup v2 memory throttling kicks in.
Until now, I have only been able to achieve stable nodes by setting the requests to limits..

@davidroth in a correctly configured Kubernetes cluster the pod resources shouldn't be able to make a node become unstable; that what system and kube reserved should be handling.
At the same time; as memory is (currently) uncompressible it's good practice to use the same value for limits as requests. A likely side effect of this is that all pods have additional overhead reserved which the node can then use to increase on it's default reserved values. This is exactly what we saw while we were still using the default kube reserved values with prefix delegation supporting 110 pods per node; clusters with pods that had resources exactly specified were much less likely to have a node problem than those with unconstrained or highly burstable pods.
Our solution to this was to implement the GKE kube reserved memory calculation as part of our node configuration which completely stopped this issue (FYI AKS also uses this and EKS & AKS use the GKE CPU calculation). The GKE calculation takes a proportion of node resources and I've not seen a node become unstable from this cause since we made this change.
However with Karpenter only supporting a fixed value for kube reserved we've been struggling to find a solution so that we can get Karpenter into production. At the same time as this AKS announced a (still pending for v1.29) move towards a per-pod calculation of kube reserved, but with a much higher per-pod cost that the EKS (20Mb vs 11Mb), which made me re-evaluate the problem.
So back to first principals we get the following statements.

A per-pod kube reserved calculation (+ a fixed value) should be correct

This is expensive as a node supporting the K8s default 110 pods would need a significant memory reservation

The current EKS calculation isn't correct/safe

Pods have an overhead greater than 11Mb (based on failure on node using the ENI mode and according to AKS 20Mb)
The high initial fixed value (255Mb) makes the calculation more robust for nodes with fewer pods
ENI mode is "more" correct by virtue of having a low pod density so the fixed value covers the gap better
Prefix mode is very incorrect

The GKE algorithm is robust but potentially wasteful

As it's not per-pod

My summary of the above is that for a "correct" solution the resources need to be configured per pod, but due to other considerations this is very hard and the general solution has been to use second order effects to build a good enough solution. These second order effects require certain constraints to be in place and once they aren't there is the potential for nodes to become unstable; the examples here for the EKS calculation are small nodes supporting 110 pods with a large number of those pods being deployed as burstable, and large nodes with more than about 25 pods using all of the available node resources.
As a number of things have changed since the above algorithms were created I think that we can solve this problem without needing to rely on second order effects. If we combine a static system & kube reserved configuration for the nodes and then introduce a runtime class with pod overheads we can directly model the system as it is rather than how it could be. This results in nodes which can better make use of their available resources as resources are only reserved when they're needed. The issue here is that there isn't a concept of a default runtime class so that would need to be added with a webhook (but mutating policy via CEL is WIP).
@cartermckinnon could we get some numbers published about the node resource utilisation; ideally with no pods running and then per pod.

Experiencing the same. I also notice that there isn't anything set for systemReserved in the config. I am thinking a temporary workaround to increase the evictionHard. Do we know if this is achievable without baking a new AMI?

kubelet-config.json
{
  "kind": "KubeletConfiguration",
  "apiVersion": "kubelet.config.k8s.io/v1beta1",
  "address": "<IP_ADDRESS>",
  "authentication": {
    "anonymous": {
      "enabled": false
    },
    "webhook": {
      "cacheTTL": "2m0s",
      "enabled": true
    },
    "x509": {
      "clientCAFile": "/etc/kubernetes/pki/ca.crt"
    }
  },
  "authorization": {
    "mode": "Webhook",
    "webhook": {
      "cacheAuthorizedTTL": "5m0s",
      "cacheUnauthorizedTTL": "30s"
    }
  },
  "clusterDomain": "cluster.local",
  "hairpinMode": "hairpin-veth",
  "readOnlyPort": 0,
  "cgroupDriver": "systemd",
  "cgroupRoot": "/",
  "featureGates": {
    "RotateKubeletServerCertificate": true,
    "KubeletCredentialProviders": true
  },
  "protectKernelDefaults": true,
  "serializeImagePulls": false,
  "serverTLSBootstrap": true,
  "tlsCipherSuites": [
    "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305",
    "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305",
    "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
    "TLS_RSA_WITH_AES_256_GCM_SHA384",
    "TLS_RSA_WITH_AES_128_GCM_SHA256"
  ],
  "registryPullQPS": 20,
  "registryBurst": 40,
  "clusterDNS": [
    "<IP_ADDRESS>"
  ],
  "kubeAPIQPS": 10,
  "kubeAPIBurst": 20,
  "evictionHard": {
    "memory.available": "100Mi",
    "nodefs.available": "10%",
    "nodefs.inodesFree": "5%"
  },
  "kubeReserved": {
    "cpu": "110m",
    "ephemeral-storage": "1Gi",
    "memory": "2829Mi"
  },
  "maxPods": 234,
  "providerID": "aws:///ap-southeast-2c/i-123456789",
  "systemReservedCgroup": "/system",
  "kubeReservedCgroup": "/runtime"
}

@zip-chanko as the limits aren't being enforced the combined values for kube and system reserved can be treated as a single unit.

dis a doozie

Our solution to this was to implement the GKE kube reserved memory calculation as part of our node configuration which completely stopped this issue (FYI AKS also uses this and EKS & AKS use the GKE CPU calculation). The GKE calculation takes a proportion of node resources and I've not seen a node become unstable from this cause since we made this change.

@stevehipwell I suppose that you used custom user data to do this, correct?
I see that it's possible to pass custom user data like a bash script using managed node groups in EKS, but it doesn't seem to be possible in Karpenter.
So is it a good approach setting hardcoded values for system and kube reserved resources ?
Or use a Bottlerocket bootstrap container is the way to go?

@irizzant sorry for the slow reply, I've been on annual leave. Initially we used custom user date to implement the GKE algorithm for AL2 nodes (pre Bottlerocket) managed by ASGs. When Bottlerocket was released we pivoted to implementing this calculation in Terraform and passing in the kubelet args via user data; this is the pattern we currently use in production. To support Karpenter we pivoted again and are currently in the process of final testing of a fixed per pod overhead algorithm; as all of our nodes currently support a max of 110 pods this results in a fixed reserved value for all nodes.
RE Bottlerocket I think 1.22.0 introduced bootstrap commands which should allow dynamic reserved calculations without requiring a custom OCI image; but there doesn't appear to be any documentation for this yet.

@stevehipwell this one? https://github.com/bottlerocket-os/bottlerocket-core-kit/blob/develop/sources/bootstrap-commands/README.md

Thanks @dims that's the one. I expected this to be in the main Bottlerocket docs (so I opened https://github.com/bottlerocket-os/bottlerocket/issues/4232), but I didn't think to check back here. Should it also either be in the primary Bottlerocket docs or at least referenced there?

Wow thanks @stevehipwell @dims !
By using bootstrap commands it looks like you can send Bottlerocket API commands with apiclient, like
commands = [[ "apiclient", "set", "motd=helloworld"]]
So you can actually set the values for kube reserved, but I don't understand how this can be set dynamically based on the instance type in Karpenter NodeClasses.


Adding a Animated Mouse Cursor

Project title
Animated Mouse Cursor
Project Description
A breathing effect mouse cursor built using HTML, CSS, and JavaScript.
Stack:
And in order to tick the check box just put x inside them for example - [x] like this. Please delete options that are not relevant.

[x] Html
[x] CSS
[x] JavaScript

/assign


⚠ Bofrost.lu has degraded performance

In 9935a5c, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1544 ms

Resolved: Bofrost.lu performance has improved in 2b9b322.


Importing requests is fairly slow

We are using requests in our projects, and it is working great. Unfortunately, for our CLI tools, using requests is an issue because it is slow to import. E.g. on my 2014 macbook:
python -c "import requests"

Takes close to 90 ms.
Is optimizing import time worth of consideration for the project ?

This is almost certainly the result of CFFI. Can you print what libraries you have installed in your environment (pip freeze)?

This is not linked to cffi (I don't have it installed). I did the test w/ a quasi empty virtualenv:
$ pip list
pip (8.1.2)
requests (2.10.0)
setuptools (21.1.0)
wheel (0.24.0)
$ time python -c "import requests"

real	0m0.090s
user	0m0.061s
sys	0m0.026s

I have a 2012 Macbook pro:, using a slightly different way of measuring the import time:
$ pip list
pip (8.0.2)
requests (2.10.0)
setuptools (19.6.2)
wheel (0.26.0)
$ python -m timeit -n 10000000 'import requests'
10000000 loops, best of 3: 0.571 usec per loop

I also upgraded pip and setuptools to match your environment:
$ pip list
pip (8.1.2)
requests (2.10.0)
setuptools (21.1.0)
wheel (0.26.0)
$ python -m timeit -n 10000000 'import requests'
10000000 loops, best of 3: 0.59 usec per loop

Further
$ time python -c 'import requests'
python -c 'import requests'  0.07s user 0.05s system 61% cpu 0.200 total

Which is still not ideal, but is probably higher than the simple import of requests due to Python's initialization.

That said, if you have information about specific things in our __init__.py (and elsewhere) that are causing slowness, I think we can fix them so long as they don't break backwards compatibility or our functional API.

timeit is not informative for imports, you have to create a new process every time because of python import caching.
The main cost is importing urllib3, so I suspect that should be addressed there.

@sigmavirus24 as @cournape mentions you can't time it like that; try using time on the command line. On my machine (ran each ~6-10 times to try to get a reliable average) for user+sys times (including sys because if there's any strange calls made into the kernel as a result of the import, that should be counted):

time python -c "" (CPy 2.7.11) = 130 ms (time for Python to start up)
time python -c "import requests" (2.10.0) = 240 ms (above + importing requests)
time python -c "import urllib3" (1.15.1) = 210 ms (installed separately)

So urllib3 takes about 80 ms, then about 30 ms more for requests stuff.

Neither of these numbers seem that high to me.

Yeah. Especially as your average request is going to take a few hundred milliseconds or so. If you reeeeally want to shave off milliseconds, could always back-translate to use the stdlib. 😜
Or you could shorten the name of your command line tool by 1-2 characters.

Ah, I didn't realize you were working on a CLI tool. Well, it hasn't seemed to be an issue for httpie.

It is true that as soon as you do even one request on a remote server, the delay will not matter much. But the problem in python is that you pay the import cost whether you actually do a request or not: think doing tool --version, tool --help, etc... Imagine a tool like git or hg that only occasionally do http IO.
80 ms is pretty bad in this case: the rule of thumb for a CLI tool to have noticeable delay is ~100-150 ms. Try using e.g. git with a 200 ms delay, it is a bit annoying.
Now, I completely understand that it may not be a focus of the library, especially if it is not that easy to improve.

I personally think you're using the wrong tool for the job — given that, on the metrics given above, Python itself is taking 120ms alone. Httpie and mercuial are well-loved tools that do their jobs very well, but they are not, nor ever will they be curl or git.

Makes sense; you could code up some lazy loading bits. Found this though, which claims to have been excerpted from hg: https://github.com/bwesterb/py-demandimport (haven't ever used it, no guarantees).

@kennethreitz python does not take 120 ms to start, unless you are on a seriously broken environment. It is much closer to 20 ms on decently modern hw (< 5 years), i.e. importing requests means 3x the cost of starting python.
FWIW, on my 2011 Desktop PC (Debian):
$ time python -c ""
real	0m0.020s
user	0m0.016s
sys	0m0.000s
$ time python -c "import requests"
real	0m0.107s
user	0m0.088s
sys	0m0.012s

On my 2014 macbook (OS X)
$ time python -c ""

real	0m0.022s
user	0m0.010s
sys	0m0.009s
$ time python -c "import requests"
real	0m0.096s
user	0m0.060s
sys	0m0.032s

A simple hg (for help) on my macbook takes ~ 100 ms

Oh, oops, yeah...my environment is a bit wonky because of the pyenv shim (adds about 100 ms because it's a bash script that leads to python with exec). Bypassing that, the incremental times are still the same and Python itself loads in 10 ms or so.

haha, I thought that number looked high :)

The "profimp" module shows where the time goes:
https://pypi.python.org/pypi/profimp
pkg_resources takes up a lot of time in general.
 It would be great if we could opt-out, as there is core SNI support in the appropriate versions of Python.
There doesn't appear to be any way of doing this today, if PyOpenSSL is importable. Would a PR allowing an opt-out be likely to be merged?

@dsully How would you propose to expose the API for an opt-out?

@Lukasa Unless I'm mistaken, the .contrib.pyopenssl ssl wrapper & context is not needed on Python 2.7.9+ and 3.4+. Given that, requests is always using pyopenssl when it is installed, even when the core Python libs support SNI, etc. So, changing the import to be:
# Attempt to enable urllib3's SNI support, if possible & needed.
try:
    from ssl import SSLContext  # Python 2.7.9+, 3.4+
except ImportError:
    try:
         from .packages.urllib3.contrib import pyopenssl
         pyopenssl.inject_into_urllib3()
    except ImportError:
         pass

Less of an opt-out, more of a not-needed.
Now, if there are cases where the pyopenssl SSLContext wrapper is desired for some reason (?) even when the core libraries are sufficient, then I'll make another pass. What do you think?

@dsully you said:

pkg_resources takes up a lot of time in general.

Where is Requests using pkg_resources? I don't believe either Requests or Urllib3 uses it.

Now, if there are cases where the pyopenssl SSLContext wrapper is desired for some reason (?) even when the core libraries are sufficient

If I remember correctly, only the more recent versions of 2.7 are actually appropriate. I think there were some minor issues with 2.7.9 and 2.7.10.

@sigmavirus24 Indirectly via cryptography:
src/cryptography/hazmat/backends/__init__.py
7:import pkg_resources
27:            for ep in pkg_resources.iter_entry_points(

Imported via:
packages/urllib3/contrib/pyopenssl.py
49:from cryptography.hazmat.backends.openssl import backend as openssl_backend
50:from cryptography.hazmat.backends.openssl.x509 import _Certificate

@Lukasa - without moving the location of the pyopenssl loader, currently in requests/__init__.py, would an environment variable be acceptable?

I'm tentatively open to that, yes.

Lots of code gets installed transitively, but not imported.

That sounds like the real root cause of this. Well that and the possibility that cryptography is still slow to import. Which is an issue for pyca/cryptography.

would an environment variable be acceptable?

I don't like that. Let's say someone is using HTTPie and notice it's slow. They're also using requests in a development project. If they export the environment variable to speed it up without understanding the ramifications and they're on an LTS distribution with a terrible ssl module and terrible OpenSSL, then they'll start seeing SSLErrors in their project if they were relying on any of the functionality provided by PyOpenSSL. But those SSLErrors weren't there yesterday and they've already forgotten that they exported that variable. Now we have yet one more avenue of complexity to help them debug. I abhor that.

@sigmavirus24 I hear you there. If environment changes aren't ok, an explicit call? I'd have to move the current injection, since it happens in __init__.py

@dsully so I think what we need to balance is: "better security for most people" versus "avoiding performance penalties for a smaller group of people".
If I understand your situation correctly, you have recent enough versions of OpenSSL and Python, yes? In that case a version check against the OPENSSL_VERSION in ssl would be good enough for your needs, right? Is there a reason not to try to check against that (or perhaps a more friendly attribute that isn't a string)?

Additional data here - if the PyOpenSSL (16.2.0) based SSLContext wrapper is loaded, and in requests verify is set to a file path, in this case containing an internal CA bundle, it seems as though the default CA bundle is removed and replaced with just the passed CA bundle, instead of appending. This works fine with Python 3.4+'s built in ssl.SSLContext (ie: when PyOpenSSL is not available).
Since this is getting far off the tract of this issue, I'll open another one to track what appears to be a bug.

@sigmavirus24 I think so.. but I don't follow 100%. Do you mean checking the OPENSSL_VERSION to avoid the pyopenssl injection?

@sigmavirus24 And yes, you are correct - we run Python 2.7 and Python 3.5 (soon to be 3.6), both compiled against a non-system shipped OpenSSL.$latest. Our build system (PyGradle) also sets build time CPPFLAGS and LDFLAGS to have modules like cryptography and PyOpenSSL link to the non-system OpenSSL as well.

@sigmavirus24 I think so.. but I don't follow 100%. Do you mean
checking the OPENSSL_VERSION to avoid the pyopenssl injection?

That's exactly what I failed to communicate. :)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Ok, so:
import ssl

if ssl.OPENSSL_VERSION_INFO < (1, 0, 1):
    try:
         from .packages.urllib3.contrib import pyopenssl
         pyopenssl.inject_into_urllib3()
    except ImportError:
         pass

What is the minimum OpenSSL version for the required functionality? 1.0.1?

On January 13, 2017 1:40:44 PM CST, Dan Sully<EMAIL_ADDRESS>wrote:

Ok, so:
import ssl

if ssl.OPENSSL_VERSION_INFO < (1, 0, 1):
   try:
        from .packages.urllib3.contrib import pyopenssl
        pyopenssl.inject_into_urllib3()
   except ImportError:
        pass

What is the minimum OpenSSL version for the required functionality?
1.0.1?

I think 1.0.1 is a good minimum but would rather defer to @Lukasa and @reaperhulk on that.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Additional data here - if the PyOpenSSL (16.2.0) based SSLContext wrapper is loaded, and in requests verify is set to a file path, in this case containing an internal CA bundle, it seems as though the default CA bundle is removed and replaced with just the passed CA bundle, instead of appending.

This is not a bug, unless the behaviour is inconsistent with the standard library's behaviour when you do that. Passing a custom bundle to verify should never append to the standard CA bundle, it should always replace it.

What is the minimum OpenSSL version for the required functionality? 1.0.1?

I am nervous about setting a minimum required OpenSSL version. We could definitely do it, I suppose, but it strikes me as something that is hard to come up with a universal "good" value for.

@Lukasa - It should be set to whatever pyOpenSSL's minimum is for the functionality that is required.
0.9.8 was dropped in pyOpenSSL 16.1.0:
https://pyopenssl.readthedocs.io/en/stable/changelog.html
So 0.9.9 would be the bare minimum, but that's hard to recommend. I still say 1.0.1 or perhaps 1.0.0

The problem is that "required" is a moving target. We have a definition of "required" that is true today, but any check like this is going to go out of date.

Well then it should be updated when the requirements change. :)

Heh, I agree, but speaking as someone with about twice as many maintenance tasks as his job allows, I'm a big believer in reducing the number of things I have to keep track of. ;)

PR#3817 created.

So the cryptography portion of this was fixed by @dsully in https://github.com/pyca/cryptography/commit/aa396c0805aced49d5502fafa20f304a23e369a7 which makes me believe that this can be closed.


width , height

can i  set a width or height when i create an  SVG icons?
example:
export default {
SortArrows: ,
Tick: {
svg: ,
// viewBox: '0 0 50 50',
width:100,
height:100.
},
}

No, you can't. imo, width and height are not really icon specific things. The size should be determined by the designer when they're used. You may want to change their size at different screen sizes too

oh,thank you very much


Write a GO program to reverse an array

Description
Write a GO program to reverse an array
Input  : [1, 2, 3, 4, 5]
Output : [5, 4, 3, 2, 1]

How to contribute

Save the solution in reverse_an_array.go file
Add reverse_an_array.go file in program/reverse-an-array folder

!assign


Poor performance or normal behaviour?

Issue Description
We in the middle of migration from parse.com to our own parse server on AWS EC2.
We are almost ready to go so we are testing the new platfrom.
We see weird behaviour. It's seems that parse-server don't works well with concurrent requests.
We have tested the whole app with jmeter and ab with the same result.
Parse-server tend to eat all free CPU. Even with a few requests.
We are using this simple script.
#!/bin/bash

ab -n1 -c1 \
-p parse.json \
-H "X-Parse-Application-Id: XXXXXXXXXXXX" \
-H "X-Parse-Client-Key: XXXXXXXXXXXX" \
-H "Content-Type: application/json" \
-H "Accept-Encoding: gzip" \
https://XXXXXXXXXXXX.XXXXXXXXXXXXcom:1337/parse/login

Where parse.json content is ...
{"username":"user1","password":"pass1","_method":"GET"}

We have done the tests with an empty database too. Our mongodb platform is really close to our parse-servers. There aren't any slow queries in our mongodb (80 ms is slow to us)
We hace un ELB with only one instance behind.
Results
10 requests. 1 concurrent request
Concurrency Level:      1
Time taken for tests:   2.266 seconds
Complete requests:      10
Failed requests:        0
Total transferred:      8890 bytes
Total body sent:        4090
HTML transferred:       3680 bytes
Requests per second:    4.41 [#/sec] (mean)
Time per request:       226.572 [ms] (mean)
Time per request:       226.572 [ms] (mean, across all concurrent requests)
Transfer rate:          3.83 [Kbytes/sec] received
                        1.76 kb/s sent
                        5.59 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5    5   0.2      5       6
Processing:   219  221   2.2    221     225
Waiting:      218  221   2.2    221     225
Total:        224  226   2.2    226     231

Percentage of the requests served within a certain time (ms)
  50%    226
  66%    227
  75%    228
  80%    229
  90%    231
  95%    231
  98%    231
  99%    231
 100%    231 (longest request)

10 requests. 2 concurrent requests
Concurrency Level:      2
Time taken for tests:   2.169 seconds
Complete requests:      10
Failed requests:        0
Total transferred:      8890 bytes
Total body sent:        4090
HTML transferred:       3680 bytes
Requests per second:    4.61 [#/sec] (mean)
Time per request:       433.873 [ms] (mean)
Time per request:       216.936 [ms] (mean, across all concurrent requests)
Transfer rate:          4.00 [Kbytes/sec] received
                        1.84 kb/s sent
                        5.84 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5    6   0.8      6       8
Processing:   414  428  10.0    431     440
Waiting:      414  428   9.9    431     440
Total:        419  434  10.2    439     446

Percentage of the requests served within a certain time (ms)
  50%    439
  66%    441
  75%    441
  80%    443
  90%    446
  95%    446
  98%    446
  99%    446
 100%    446 (longest request)

10 requests. 4 concurrent requests
Concurrency Level:      4
Time taken for tests:   2.145 seconds
Complete requests:      10
Failed requests:        0
Total transferred:      8890 bytes
Total body sent:        4090
HTML transferred:       3680 bytes
Requests per second:    4.66 [#/sec] (mean)
Time per request:       857.880 [ms] (mean)
Time per request:       214.470 [ms] (mean, across all concurrent requests)
Transfer rate:          4.05 [Kbytes/sec] received
                        1.86 kb/s sent
                        5.91 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5    6   0.9      6       7
Processing:   426  765 177.6    849     857
Waiting:      426  765 177.6    849     857
Total:        431  771 178.0    856     863

Percentage of the requests served within a certain time (ms)
  50%    856
  66%    857
  75%    861
  80%    861
  90%    863
  95%    863
  98%    863
  99%    863
 100%    863 (longest request)

Even with only two concurrent requests response times grows to double.
2 requests. 2 concurrent requests
Concurrency Level:      2
Time taken for tests:   0.432 seconds
Complete requests:      2
Failed requests:        0
Total transferred:      1778 bytes
Total body sent:        818
HTML transferred:       736 bytes
Requests per second:    4.63 [#/sec] (mean)
Time per request:       432.359 [ms] (mean)
Time per request:       216.179 [ms] (mean, across all concurrent requests)
Transfer rate:          4.02 [Kbytes/sec] received
                        1.85 kb/s sent
                        5.86 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        6    6   0.8      7       7
Processing:   426  426   0.2    426     426
Waiting:      426  426   0.2    426     426
Total:        431  432   0.6    432     432
WARNING: The median and mean for the initial connection time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%    432
  66%    432
  75%    432
  80%    432
  90%    432
  95%    432
  98%    432
  99%    432
 100%    432 (longest request)

Environment Setup

Server

parse-server version: 2.2.17
Operating System:     ubuntu 14.04
Hardware:             AWS EC2 c4.large

Database

MongoDB version: 3.0
Storage engine:  WiredTiger
Hardware:        AWS EC2 m4.large

Logs/Trace

It is always better to divide parse server up into multiple instance with a load balancer than using a scaled up instance. Also have you optimized your main.js file to make use of "workers" or use pm2 for deployment?

Actually, since a AWS EC2 c4.large has two cores, we have two parser-server process. One listen on port 1338 and the other listen on port 1339.  The c4.large run an haproxy listen on port 1337 and distributes requests between this local ports.
We use AWS EC2 auto scaling to scaling our platform, but we are running the test against the most simple case.
If we run the test against the haproxy, al work as expected. We can manage 2 concurrent 2 concurrent request without penalties.
So our cuestion is about concurrent requests against one process.

That is very odd indeed, do you have any trace timing info about MongoDB queries and # of queries to mongo during those tests? Running a similar setup, and we don't see those latencies

Except my process, no one is accesing to mongodb.  I see 4 connections.
Launching 100 requests, 16 concurrent...

8 ops / sec (queries)
No queries longer than 5 ms. ( I run db.setProfilingLevel(2,5) )

Document Path:          /parse/login
Document Length:        368 bytes

Concurrency Level:      16
Time taken for tests:   12.647 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      88900 bytes
Total body sent:        40900
HTML transferred:       36800 bytes
Requests per second:    7.91 [#/sec] (mean)
Time per request:       2023.545 [ms] (mean)
Time per request:       126.472 [ms] (mean, across all concurrent requests)
Transfer rate:          6.86 [Kbytes/sec] received
                        3.16 kb/s sent
                        10.02 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5    8   3.7      6      17
Processing:   487 1965 1165.3   2160    3866
Waiting:      487 1964 1165.3   2160    3866
Total:        493 1972 1166.3   2165    3877

Percentage of the requests served within a certain time (ms)
  50%   2165
  66%   2902
  75%   3111
  80%   3127
  90%   3352
  95%   3855
  98%   3871
  99%   3877
 100%   3877 (longest request)

I've tested my mongodb directly and is really fast. The bottleneck seems to be in parse-server. It can't manage concurrent requests.

What you describe is very odd... we currently process about 300rps (mostly reads and _Installation writes) and the CPU on each machine is at ~30%. And this is the most vanilla as possible as we don't leverage the cores through pm2/ cluster... what'a the result on a naked development machine with local MongoDB?

Same.
I have installed a new machine (c4.large). Mongo is empty. Only one user. My main.is (Where the cloud code is going to be) is empty too.
More data:
Node version
node --version
v5.12.0

The way I run parse-server
node /usr/bin/parse-server /srv/cgib0/config.json

My config.json
{
  "appId": "xxxxxx",
  "masterKey": "xxxxxx",
  "databaseURI": "mongodb://localhost:27017/cgib",
  "port": "1337",
  "cloud": "/srv/cgib0/cloud/main.js",
  "javascriptKey": "xxxxxx",
  "restAPIKey": "xxxxxx",
  "clientKey": "xxxxxx",
  "publicServerURL": "http://xxxxxx:1337/parse",
  "filesAdapter": {
    "module": "parse-server-s3-adapter",
    "options": {
      "accessKey": "xxxxxx",
      "secretKey": "xxxxxx",
      "bucket": "xxxxxxpro",
      "region": "eu-west-1",
      "bucketPrefix": "",
      "directAccess": true,
      "baseUrl": "https://s3-eu-west-1.amazonaws.com/xxxxxxpro",
      "baseUrlDirect": true
    }
  },
  "verifyUserEmails": true,
  "emailAdapter": {
    "module": "parse-server-simple-mailgun-adapter",
    "options": {
      "fromAddress": "info@xxxxxx",
      "domain": "xxxxxx",
      "apiKey": "key-xxxxxx"
    }
  },
  "appName": "xxxxxx"
}

parse.com need same time for a login (220 ms) but the service can manage concurrent request without letting down
Remember that I'm testing logins. Can you manage 300 login per second? I can't understand. What is happening?
(Thanks for your interest. I'm pretty lost)

I just spent some time looking into this issue. There is most definitely a performance problem with Parse Server signup/login.
Some background:

nodejs is single-threaded so when any code does something intensive it blocks all other code from executing.
By design and as a best practice, signup and login (any password hashing) should be slow.
Parse Server uses the async methods of bcrypt-nodejs to hash and compare passwords. Hypothetically, this should make the code "non-blocking."

The problem:

The async functions of the bcrypt-nodejs just call the synchronous functions within process.nextTick. See source code here.
This means that any time that Parse Server uses the hash or compare functions it's going to become blocking on nextTick and block all other code execution.

My recommendation:
Replace the current bcrypt moule with the node.bcrypt.js module. This one uses node-gyp and native bindings so that the asynchronous functions are truly non-blocking.
Looks like we can update package.json dependencies and password.js with the new module and we should be good to go. @icalvete would you like to submit a pull request for this? If not, I'd be happy to.

The native bindings may be a good idea but may be problematic for users with limited compilation tools on the remote machine.

@flovilmart Good point... Windows users will most certainly run into issues as well.
Just came across bcrypt.js which appears to do a nice job or progressively handling hashing in a non-blocking way.

@JeremyPlease also on heroku, app engine etc... all thin containers may have problems with those native modules. We could definitely try bcrypt.js, run ab against it quickly. Wanna run the benchmarks?

Running some benchmarks now. Stay tuned... 📺

👍

Well... Here are some benchmarks. Ran with ab -n200 -c100 locally 5 times for each module.

Baseline (immediately fulfill promises in password.js without bcrypt use): 250 req/sec
bcrypt-nodejs (current implementation): 5 req/sec
bcryptjs: 5 req/sec
twin-bcrypt: 5 req/sec
bcrypt (native bindings): 52 req/sec

Not sure where to go from here. We might just want to leave things as-is and note in the wiki/readme that Parse Server has a limitation around simultaneous login requests.

Maybe mark is as an optional dependency, if compilation fails, we use the std slow bcrypt-nodejs (current implementation).
Would that be reasonable?

@JeremyPlease did you use saltRounds = 10 in the hash function from bcrypt ? What was the value you used?

@flovilmart Yep, 10 saltRounds for .hash(password, saltRounds, ...)

I've tried the bcrypt and works really fine.
To me this issue can be closed.
Thanks for all.

We'll try to do a release soon when thé PR has landed

It definitely does not work as a straight replacement.

@joeyslack the PR is open and that will also factor for setups where build tools are not available remotely

@flovilmart FYI, I'm unable to login to my app (facebook connect, and also manual login method) with this new patch on master. Would love to see if it works for anyone else....

What is the issue that you see? FBConnect should be un-affected by that change.

@joeyslack :
I just tried that:
var bcryptOriginal = require('bcrypt-nodejs'); // original bcrypt
var bcryptNew = require('bcrypt'); // bcrypt native
bcryptOriginal.hash('my1Long:password', null, null, function(err, res) {
    bcryptNew.compare('my1Long:password', res, function(err, res) {
          expect(res).toBeTruthy();
          done();
    });
});

And that passes, unfortunately, we can't test it on travis as the bcrypt native module won't build

I don't have a lot of time to debug this now, but if it's working for everyone else, it's probably my VM. Will post back with more details if I find anything.

@joeyslack we're planing to release tonight 2.2.18. We don't want anyone to be locked out...

@flovilmart Turned out to be an issue with FileLoggerAdapter. I am using it in my app like:
var logger = require('parse-server/lib/Adapters/Logger/FileLoggerAdapter').FileLoggerAdapter;
Had to install this dep separately. Bcrypt changes seems to work fine.


PDF viewer (still) adding margins to print preview and printout.

Since the previous report of this issue was closed, marked as fixed,  but it clearly is not fixed,  I post this report. This issue is still causing us grief.
We print labels , 4 per sheet this adding anything to the margins of the final print is a critical fault/bug.
Now forced to go with the latest version of FF due to continuous addon issues.
Here's the problem:
FF v52.2.1esr Win 7 : Added ~0.5" to Left, Right, Top and Bottom margins.
FF v67.0 (latest) Win 7 : Added ~0.5" to Top and Bottom margins
FF v67.0 MX Linux : No added margins, however cannot use due to another bug with the Linux version of PDF.js .
I have tried/checked:
Set in about:config , all margins for the printer to 0 (print.printer_4100DN_USB.print_margin_top etc)
Ensure there are no additional Gutter or Margins added by the Printer properties.
Ensure the Application adds no add'l margin
Symptoms:
Preview in Firefox - No margins added and looks as it should.
Paper printout and Print Preview - Added extra Margin.

We are forced to use the FF Preview in FF because there is no Adobe Acrobat Reader plugin support since v57. With the old v52.2.1 FF with Acrobat Plugin everything works perfectly.

Could you provide a sample PDF file for which this happens?

Well,  its not a stand-alone file as such,  its from a Print-Labels function of Australia Post eParcel portal.
I'll try to grab the page code.

Same problems here in Firefox 69/ win10 (using pdf.js as pdf reader).
Sample where I reproduce :
https://www.maths.ed.ac.uk/~dmarsh/files/printer-testcard-colour.pdf
when opening it firefox it's ok, when i print it or print to pdf it i get an extra margin and truncated document like here :

It's also reproductable with the same document using the firefox print preview :

it can also be reproduced with this document :
http://www.africau.edu/images/default/sample.pdf
First note that i don't reproduce with this document :
https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_open_parameters.pdf
Second problem (I don't know if it can be related) :
Every pdf sent to print to my differents office printers (differents models) ask for a manual papers addition instead of using the default one. It don't have any issue using chrome or acrobat reader.

Closing since we recently merged quite a few fixes for page positioning when printing. If this is still an issue, it's most likely related to the printer settings which we cannot control from JavaScript, thus it's not something that can be fixed here.


Validator & minimum integer values

Hi,
Is there a reason why the minimum allowed value for integer inputs is 0? link
In my particular case I need to allow negative integers.
Could changing the number range be made developer modifiable through a variable in config perhaps?

You can configure it in FormMaker Blade Directive.
Yet documentation is remaining to be created.

Please could you give me an example?

Find the following piece of code around line 331 in vendor/dwij/laraadmin/src/LAFormMaker.php
		```

case 'Integer':
$out .= ''.$label.$required_ast.' :';
			unset($params['data-rule-maxlength']);
			if($default_val == null) {
				$default_val = $defaultvalue;
			}
			// Override the edit value
			if(isset($row) && isset($row->$field_name)) {
				$default_val = $row->$field_name;
			}
			$params['min'] = "0";
			$out .= Form::number($field_name, $default_val, $params);
			break;

Here you can change the $params['min'] = "0";

Hope this helps

Sorry for fixing it late.
Resolved in latest commit.
Regards,