[20.09] python3Packages.pikepdf: add patch for CVE-2021-29421

Motivation for this change
https://nvd.nist.gov/vuln/detail/CVE-2021-29421
Going by version numbers this looks like a huge leap to backport a patch, but the patch is actually quite simple and applies cleanly apart from the addition of the new test, which simply has a trailing-content conflict, requiring the manual patch alteration.
Said test passes fine though, so I'm quite confident in the validity of this backport.
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
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] 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)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

(pre-existing failure on darwin due to python-xmp-toolkit)

Result of nixpkgs-review pr 119787 at 3e30d017 run on aarch64-linux 1

1 package failed to build:

ocrmypdf

5 packages built successfully:

img2pdf (python38Packages.img2pdf)
pdfarranger
python37Packages.img2pdf
python37Packages.pikepdf
python38Packages.pikepdf

3 suggestions:

warning: unused-argument
Unused argument: fetchpatch.
Near pkgs/development/python-modules/pikepdf/default.nix:5:3:
  |
5 | , fetchpatch
  |   ^

warning: unused-argument
Unused argument: python3.
Near pkgs/development/python-modules/pikepdf/default.nix:17:3:
   |
17 | , python3
   |   ^

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/development/python-modules/pikepdf/default.nix:35:5:
   |
35 |     ./1.18.0-CVE-2021-29421.patch
   |     ^

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement.

Hmmmmmm. ocrmypdf doesn't appear to be already broken for aarch64. Looks like a fairly weird python threading crash. I don't have an aarch64 machine myself to test with though.

I have an idea.
@ofborg build ocrmypdf

@ofborg build ocrmypdf

I'm getting a segfault during the test suite, but the stack trace isn't very insightful as to why

Sounds like you need #110893 ;)
But it's a strange one, because the patch is pure python. Are we sure this doesn't happen occasionally to the existing version?

this still seems to segfault during tests. however, the stacktrace doesn't seem meaningful

Unfortunately NixOS 20.09 has reached its end-of-life status on 2021-07-01, one
month after the release of NixOS 21.05.
Since we do not accept any changes to its branches anymore, I'm closing this pull
request.


SCOPE_IDENTITY()

In the procedure AddZone SCOPE_IDENTITY() is used.  SCOPE_IDENTITY() returns the last ID of ANY table inserted, not the one you are inserting to. Rather the OUTPUT clause should be used return the ID. The following code should be used.
DECLARE @Output TABLE (ID INT)

INSERT INTO [Tzdb].[Zones] ([Name])
OUTPUT Inserted.Id INTO @Output
VALUES (@Name)

SET @id = (SELECT ID FROM @Output)

@hyperlance The statement made above regarding SCOPE_IDENTITY() is incorrect. It returns the most recent Identity value in the current scope, and hence it is being used correctly in the AddZone stored procedure. It is possible that you are confusing this with @@IDENTITY which has been problematic as it returns the most recent Identity value across all scopes in the current session (i.e. inserts made in a Trigger that was fired from the insert made into a table in the current scope). SCOPE_IDENTITY() does not have that problem and should be used here.
Please see the MSDN documentation for this: https://msdn.microsoft.com/en-us/library/ms190315.aspx
No changes should be made to the AddZone stored procedure (at least not for anything related to SCOPE_IDENTITY() ).

Yes, but there are still problems with using it. See http://www.sqlbadpractices.com/how-not-to-retrieve-identity-value/

@hyperlance According to that post you linked to, the problem is largely academic as it requires a parallel plan to be involved. And that same post even states that the problem won't happen with INSERT INTO table VALUES (), which is what the AddZone stored procedure is using. And, the Microsoft KB article that is linked to from that post indicates that the problem was fixed as of SQL Server 2008 R2, SP2 (essentially).
The OUTPUT clause should be used when needing to capture multiple Identity values resulting from a set-based INSERT. But it is unnecessary overkill to use it in this context (i.e. INSERT ... VALUES ).

Best practice always wins out in my book. If you start short cutting then you make that a habit and you end up with sloppy code.

Best practice always wins out in my book.

I tend to agree. And that is why I am saying that in this context, SCOPE_IDENTITY is the best practice. The post you linked to, as well as the Microsoft KB article that post linked to, both clearly state that:

SCOPE_IDENTITY has problems only when parallel plans are involved.
Doing INSERT INTO ... VALUES does not generate a parallel plan.

Hence, SCOPE_IDENTITY is never a problem when using INSERT INTO...VALUES, and is the best practice in that context. I have worked on systems with 5000+ transactions per second and we used SCOPE_IDENTITY in all cases except when multiple rows were being inserted, in which case we used the OUTPUT clause. We never had a problem because that is how you are supposed to do things, and neither the post you linked to nor its linked Microsoft KB article contradict that.
The only problem seems to be that the post you linked to makes an unsubstantiated logical leap at the end when stating that "The recommended way of retrieving identity values ... is to use the OUTPUT clause". That statement needed to be qualified with "when dealing with parallel plans". And the code example at the end showing INSERT INTO...VALUES using the OUTPUT clause makes no sense, and that pattern is not what is being recommended in that linked Microsoft KB article.


Feature: use oao.json to manage some options

Hi 😀,
I made just a simple change to can be possible to define some global options using a json config file instead of write always in the cli, as suggested on #44, but using a oao.json instead of put in a package.json, like lerna does.
For now, I put just the --src and --ignoreSrc option that can be defined. Remembering that user input options defined on cli will override the global on oao.json
With this change it's possible to create something like these:
{
  "src": ["packages/*", "helpers/*"],
  "ignoreSrc": "others"
}

And I change to accept an array of globs too, instead just a string!

Coverage remained the same at 84.369% when pulling 567c85cd6b2e638395d1a728e21842abc62850a3 on pedronauck:master into 67952239b3cf37917886eced7924b2388612f52c on guigrpa:master.

Hey, thanks for the PR! I'll check it out shortly.
Just one question up front, why an additional file instead of using package.json?

Thanks @guigrpa, I don't like to put a lot of configs on package.json, I think that it responsable to define things about the package, I prefer separate the concerns and put in a file that has just things about your concern. Can be more easy to put the eyes on project and find what you want. And how you mentioned lerna on the README, I think that you could follow it's path.
But if you guess that it's better put these config on package.json, I think that's a good idea too.

I think package.json might be better, yes. It's where you specify basic things of your package (in our case, the monorepo root package): name, entry point, build scripts, ... and with your PR things like subpackage directories, etc.
Other tools also put their config (some of them optionally) in there: Ava, Jest...

@guigrpa I made change and put config on package.json as you suggested, if you can check and deploy a new version, I need a lot these change in a big project on my work 🙏

Coverage remained the same at 84.369% when pulling e98026ce876c18d378cc1a70e3c3344311d098e6 on pedronauck:master into 67952239b3cf37917886eced7924b2388612f52c on guigrpa:master.

Please check out v0.9.0 and tell me if it's OK. I tested it on a couple monorepos and seemed to work fine.

Thanks for the PR!!

I tested in my repo and everthing is fine, thanks @guigrpa for accept the pr too and congratulations for the package, I was waiting long time a good monorepo package, lerna for me it's a big messy! :v:
cheers

Hey, I just wanted say Thank you for this addition!  I have /examples/* and /packages/* and this cleans up my repo greatly.
I've been using oao for a couple months now & it's been fantastic.  Great work!


SetLogFilenameExtension extension as a suffix to log file name

Fix for https://github.com/google/glog/issues/124.

I have signed the CLA

@googlebot  Why this PR is still not merged into master branch?

googlebot does not merge anything. The PR has not been merged yet because no one reviewed the PR.

@shinh  PTAL

Please resolve the conflict.


Add package mlokmath

Is this ready for publishing? I'm seeing that mlokmath.nim is empty, and also there's no readme.

I am sorry kind of forgot about everything


Native mobile app

Placeholder for investigation into offering a native mobile app on iOS and Android

One option would be to use therecipe/qt to add an interface. This has the advantage of covering both a mobile UI and a desktop UI without having to have multiple different versions of the application.
I haven't used it (I'm still learning go), so I don't know how difficult it would be to implement.


Unify the creation of new wfd items

This also ensures any rbd is created with an id claim.

Thanks. Will merge once #9 is resolved


v3.0.0-beta Thread

Everything about v3.0.0-beta

You can download v3.0.0-beta here
- If you see an update popup, just close it.

add me on discord ill pay for you guys if u can full teach me how to use and etc add me itzreinfr in discord

Hey, here to tell you that its incredibly slow, just letting you know. I know about the 5 player thingy but if its possible to make it faster please prioritize that, anyways, great extension as always!

 I know about the 5 player thingy but if its possible to make it faster please prioritize that, anyways, great extension as always!

Unfortunately, it is not possible to make it faster. I don't think it's worth making another update due to its current speed.
I will be archiving this GitHub repository next month.

Will you make another version of this tracker? Or are you ending development, if the latter is true its been an honor with this.

No longer works—it says Player Not Found in This Game even if they are (tested with an alt) no matter what due to a roblox update


adding Whisk to the list of adopters

Codecov Report

Merging #783 into master will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #783      +/-   ##
==========================================
- Coverage   86.59%   86.54%   -0.05%
==========================================
  Files          71       71
  Lines        2282     2282
  Branches       88       88
==========================================
- Hits         1976     1975       -1
- Misses        306      307       +1

Impacted Files
Coverage Δ

...d/src/main/scala/io/circe/NonEmptySeqDecoder.scala
91.66% <0%> (-8.34%)
:arrow_down:

Continue to review full report at Codecov.

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

This is amazing @viktortnk! Thanks a lot for letting us know!

Excellent, thanks @viktortnk!


Draft: Enterprise Contract POC with OPA/Rego

Early demo showing how rego might work.

Thinking about whether this should be merged, or whether we should start out in whatever repo the EC code is supposed to live in. Maybe it's better to start a new repo now, what do you think?

This was a useful POC, but the code isn't going to live in this repo, so let's abandon this now.
See https://github.com/hacbs-contract/ec-policies and maybe some upcoming PRs in the build-definitions repo.


add option to show current project in menubar (osx)

Very nice! Can you please also run "make fmt" to format the sources and "make lint" to check the code with cpplint?

there you go! everything fine now as far as i can see

Thank you!


ssh.completion.bash: parse "Host" directives from all config files

The ssh config can include other files using "Include".
The previous code was not taking this into consideration.

Hey, seems like this PR has gone stale. So I am closing it. Thanks for contributing!


New Tractus-X project contributor

Before requesting the project contributor role, please make sure, that you:

Make yourself familiar with the Eclipse Foundation project roles: https://eclipse-tractusx.github.io/docs/oss/contributor-committer
Make ourselves familiar with prerequisites, like a signed ECA: https://eclipse-tractusx.github.io/docs/oss/getting-started
Check the committer list of our project and highlight at least one of them on this issue, since every committer
can add project contributors: https://projects.eclipse.org/projects/automotive.tractusx/who

Necessary Information
Email address to add<EMAIL_ADDRESS>Committers, that could take over<EMAIL_ADDRESS>Please make sure, that you accept the invitation you receive from GitHub, after you have been added as project contributor.

Hi @borisrizov-zf, I guess you do not get notified with your Email mentioned instead of GitHub handle.
Could you take over for your colleague? If you are unsure, where and how to do that, I can also guide you

Hi @SebastianBezold I've done it before. The autofill is not working, I suppose the eclipse account is not mapped?
@MehrdadSalari can you please check your eclipse username <-> email mapping.

Yeah, autofill is buggy unfortunately. When pasting the email and saving, it usually works, even though the autocomplete did not suggest it.
But AFAIK, this only works with the email and not with the EF username. That's why we ask for the email in the issue template actually 😁

Ok, last time I did it, it did bring up the username, but maybe I'm just imagining... In any case it's done now. I'll close this.


Virtual Deserialization v0.1.3

We can now deserialize a reference as a base class without hitting runtime assertion errors.

CI doesn't pass because of a version problem. I need to fix CI.

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/assemblyscript
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/visitor-as
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /home/runner/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2022-01-08T20_54_47_356Z-debug.log
Error: Process completed with exit code 1.


Cannot import dependency that is a child-dependency of another

Aim
Given library A and library B, B depends on A. A crate should be able to import both A and B.
Expected behavior
To be able to use both libraries
Bug
I have tried two scenarios to import library A and B.

List both dependencies in Nargo.toml. This leads to an error:

The application panicked (crashed).
Message:  ice: the same path was inserted into the file manager twice
Location: crates/fm/src/lib.rs:57

Attempt to import lib A without listing it in Nargo.toml. This leads to:

The application panicked (crashed).
Message:  error reporter: could not find crate libA
Location: crates/noirc_frontend/src/hir/resolution/import.rs:199

To reproduce
No response
Installation method
None
Nargo version
nargo 0.5.1 (git version hash: 7f6dede414c46790545b1994713d1976c5623711, is dirty: false)
@noir-lang/noir_wasm version
No response
@noir-lang/barretenberg version
No response
@noir-lang/aztec_backend version
No response
Additional context
No response
Submission Checklist

[ ] Once I hit submit, I will assign this issue to the Project Board with the appropriate tags.

Can you provide a repo where we can reproduce this please?

Can you provide a repo where we can reproduce this please?

Yes, please use this subfolder in this repo: https://github.com/SleepingShell/darkforest-noir/tree/main/init

@TomAFrench what is the status of this issue?

Resolved in https://github.com/noir-lang/noir/pull/1034


Routes for email verification

First of all, well done 👏🏼
I'm really impressed by the ideas, quality of code and documentation.
I'm thinking about adding email verification. Yes, it has some complexity, because you need to verify email after registration and when changing email but it's still essential for many apps.
I got inspired by forgot-password and reset-password routes. Here is my idea:

generate-token route that takes an email as input and returns a token.
on_after_generate_token event to handle email sending or what ever.
verify-token route that takes the generated token and returns a relevant status code.

Do you think it would work that way or there is a better way?

Hi @dralshehri! Thank you very much for your support 😄
Indeed, I've thought about email validation and I agree it's an important feature. I think you are on the right track, it effectively matches the existing architecture while keeping it optional.
I'll think about it but this is definitely something that could be interesting to have 👍

That's great !

Yes please to this! Definitely want it pre forgot/reset pw

Hi @dralshehri , do you have any update on this ? I was thinking on developing it before I found your great idea.

I will try to finish it by a week or two.

I've reviewed the code and docs to see if my suggestion is still valid or not. Let me do a deep dive in flows that might need email verification.
Password Reset Flow:
The current implementation is supporting email verification through after_forgot_password handler but it might need to be clarified in documentation. For example:

User initiates the password reset by forgot-password route.
Using the after_forgot_password handler, we might send the user an email that has a link with JWT token in it (url path / query parameter).
Clicking the email link will take the user to a reset password form and the token will be available in the url to be utilized.
Submitting the form using reset-password route will verify token and reset password.

To DO

[ ] Add an example to the docs on how to verify email after forgot password request.

Register/Activate Flow:
The current implementation assumes the user is_active and email will not be verified. In order to verify email before activation we might need to follow this example:

User registers through register route and is_active is False by default.
Using the after_register handler, we might send the user an email that has a link with JWT token in it (url path / query parameter).
Clicking the email link will take the user to a page where the token will be available in the url to be utilized.
Sending a request using activate route (not implemented yet) will verify token and activate user.

To DO

[ ] Change the default value for is_active in BaseUser model to be False.
[ ] Generate an JWT token after creating the user in register route.
[ ] Pass the token to after_register handler.
[ ] Under get_register_router() function, create a new activate route that will verify the token and activate the user (similar to reset-password route).
[ ] Try to avoid duplicated code with reset.py by moving the JWT decoding and verification code to utils.py for example.
[ ] Add ACTIVATE_USER_BAD_TOKEN to common.py.
[ ] Add tests.
[ ] Add documentation.

Here is how I think the register.py should look like conceptually.
❗Be cautious. The following code was not tested.
from typing import Callable, Optional, Type, cast

import jwt
from fastapi import APIRouter, HTTPException, Request, status
from pydantic import UUID4

from fastapi_users import models
from fastapi_users.db import BaseUserDatabase
from fastapi_users.password import get_password_hash
from fastapi_users.router.common import ErrorCode, run_handler
from fastapi_users.utils import JWT_ALGORITHM, generate_jwt

ACTIVATE_USER_TOKEN_AUDIENCE = "fastapi-users:activate"

def get_register_router(
    user_db: BaseUserDatabase[models.BaseUserDB],
    user_model: Type[models.BaseUser],
    user_create_model: Type[models.BaseUserCreate],
    user_db_model: Type[models.BaseUserDB],
    activate_user_token_secret: str,
    activate_user_token_lifetime_seconds: int = 3600,
    after_register: Optional[Callable[[models.UD, Request], None]] = None,
) -> APIRouter:
    """Generate a router with the register and activate routes."""
    router = APIRouter()

    @router.post(
        "/register", response_model=user_model, status_code=status.HTTP_201_CREATED
    )
    async def register(request: Request, user: user_create_model):  # type: ignore
        user = cast(models.BaseUserCreate, user)  # Prevent mypy complain
        existing_user = await user_db.get_by_email(user.email)

        if existing_user is not None:
            raise HTTPException(
                status_code=status.HTTP_400_BAD_REQUEST,
                detail=ErrorCode.REGISTER_USER_ALREADY_EXISTS,
            )

        hashed_password = get_password_hash(user.password)
        db_user = user_db_model(
            **user.create_update_dict(), hashed_password=hashed_password
        )
        created_user = await user_db.create(db_user)

        token_data = {"user_id": str(created_user.id), "aud": ACTIVATE_USER_TOKEN_AUDIENCE}
        token = generate_jwt(
            token_data,
            activate_user_token_lifetime_seconds,
            activate_user_token_secret,
        )

        if after_register:
            await run_handler(after_register, created_user, token, request)

        return created_user

    @router.post("/activate")
    async def activate(token: str):
        try:
            data = jwt.decode(
                token,
                activate_user_token_secret,
                audience=ACTIVATE_USER_TOKEN_AUDIENCE,
                algorithms=[JWT_ALGORITHM],
            )
            user_id = data.get("user_id")
            if user_id is None:
                raise HTTPException(
                    status_code=status.HTTP_400_BAD_REQUEST,
                    detail=ErrorCode.ACTIVATE_USER_BAD_TOKEN,
                )

            try:
                user_uuid = UUID4(user_id)
            except ValueError:
                raise HTTPException(
                    status_code=status.HTTP_400_BAD_REQUEST,
                    detail=ErrorCode.ACTIVATE_USER_BAD_TOKEN,
                )

            user = await user_db.get(user_uuid)
            if user is None or user.is_active:
                raise HTTPException(
                    status_code=status.HTTP_400_BAD_REQUEST,
                    detail=ErrorCode.ACTIVATE_USER_BAD_TOKEN,
                )

            user.is_active = True
            await user_db.update(user)
        except jwt.PyJWTError:
            raise HTTPException(
                status_code=status.HTTP_400_BAD_REQUEST,
                detail=ErrorCode.ACTIVATE_USER_BAD_TOKEN,
            )

    return router

😢 I apologize for not having the time to implement this completely.
🙏🏼 @frankie567 would you check if we are on the right track?
🙏🏼 @diegorosen (or anyone else) would you please takeover the task of completing this?

Hello @dralshehri! Thank you for this thorough investigation. I still think it's a good feature, however, I wish it to be optional.
I'll probably work on it myself as it'll probably require lot of changes. However, I'm a bit busy at the moment, so it'll probably take some time to be released.

I have some time to work on this PR.  Is anyone else is currently handling it?  Just wanting to avoid duplicating the work here.

I'm very happy to close this ticket 🎉 The feature will be released soon!
Thank you all for your help and guidance on this, especially @eddsalkield and @mark-todd who took on the job.
Cheers 👏

I'm very happy to close this ticket 🎉 The feature will be released soon!
Thank you all for your help and guidance on this, especially @eddsalkield and @mark-todd who took on the job.
Cheers 👏

@all-contributors add @dralshehri for ideas

@all-contributors add @lefnire for ideas


chore: add semantic-release-jira plugin

Idea of the package is to add tags to JIRA issues once they are included in a release. It parses the commit footer (following conventional commits) and supports statements like the following:

available "commands" are Closes, Updates and Resolves (case insensitive):resolves DCOS-12345

multiple references, separated by ,, \s or \n:Closes DCOS-12345, updates DCOS-23456
resolves DCOS-34567

Testing
you can change .releaserc and run locally, but I'd not recommend doing it, you can screw up very easily :(
I was able to update some issues on a test run tho:
[ … ]
[3:43:56 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "semantic-release-jira"
[ … ]
[3:43:56 PM] [semantic-release] › ✔  Loaded plugin "success" from "semantic-release-jira"
[ … ]
[3:43:59 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "semantic-release-jira"
[3:43:59 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "semantic-release-jira"
[ … ]
[3:44:06 PM] [semantic-release] › ℹ  Start step "success" of plugin "semantic-release-jira"
[3:44:06 PM] [semantic-release] [semantic-release-jira] › ⬤  Updating DCOS-40780 with { "update": { "labels": [ { "add": "testing-repo:dcos-ui" }, { "add": "testing-tag:test+v1.0.1" } ] } }
[3:44:06 PM] [semantic-release] [semantic-release-jira] › ⬤  Updating DCOS-40899 with { "update": { "labels": [ { "add": "testing-repo:dcos-ui" }, { "add": "testing-tag:test+v1.0.1" } ] } }
[3:44:07 PM] [semantic-release] [semantic-release-jira] › ✔  Successfully updated DCOS-40899
[3:44:07 PM] [semantic-release] [semantic-release-jira] › ✔  Successfully updated DCOS-40780
[3:44:07 PM] [semantic-release] › ✔  Completed step "success" of plugin "semantic-release-jira"
[ … ]

used config:
{
  "branch": "jg/semantic-release-jira",
  "tagFormat": "test+v${version}",
  "verifyConditions": ["semantic-release-jira"],
  "prepare": [],
  "publish": [
  ],
  "success": [
    {
      "path": "semantic-release-jira",
      "apiURL": "https://jira.mesosphere.com/rest/api/2/issue/${issueKey}",
      "apiJSON": '{ "update": { "labels": [ { "add": "testing-repo:dcos-ui" }, { "add": "testing-tag:test+v${version}" } ] } }'
    }
  ]
}

:tada: This PR is included in version 2.20.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Calculator?

Allow doing simple calculations using chat preview.
Might fit better in its own mod

If this was to be its own mod then I would need some sort of API in MarkCraft so that they are still compatible. That would need a lot of thinking on, so likely won't be happening any time soon


Added the RBAC for druid leader election.

It is required for https://github.com/gardener/etcd-druid/pull/133

Please fix the unit tests.
/author-action

/cla

Shouldn't this PR be considered at all only with the new version of etcd-druid?

Probably, but it doesn't harm to merge this already now, I assume? Shall we go ahead?

Hi, the PR https://github.com/gardener/etcd-druid/pull/133 is merged. Would you merge this PR as well?
Thanks

Hi, Can you merge this PR as https://github.com/gardener/etcd-druid/pull/133 is merged. @amshuman-kr I made the requested changes

Hi, Can you merge this PR as gardener/etcd-druid#133 is merged. @amshuman-kr I made the requested changes

@abdasgupta , could you please explain me exactly which part of https://github.com/gardener/gardener/pull/3828#issuecomment-815031750 (Please make it ready for review when there is a new etcd-druid release.) is not clear?

I must have given more importance to this part The referenced PR is not even merged. Anyway, sorry that I bothered too early. A new release of ETCD Druid is shortly coming. Would let you know. Thanks.

New ETCD druid release https://github.com/gardener/etcd-druid/tree/v0.5.0 v0.5.0 is available with the related Druid PR merged in it. We are okay to go ahead with this PR. Thanks.

/hold until https://sap-ti.slack.com/archives/C0177NLL8V9/p1619608337034400 is sorted out

/unhold as v1.22 is released


Added "Contacts" example

Add Contacts framework example.
Contacts framework is replaced of the traditional AddressBook framework.

Thanks!


Install status showing after service install complete on list page

The percent installed is displaying on the service list page after the installation is complete. It also displayed in other service states, noted in screenshots.

closing bc already fixed


Fix in case of refresh token error

fixes #50

Hey @tmenguy , if you don't mind I'll split this PR in 2 as there are a lot of changes there and difficult to see which is which

fix for requestTimeout - that's a big bug, great catch there!
change to the authentication workflow, re-authenticate if jwtToken needs refresh

as you want no pb, you want me to do it? Lot of changes , yes a lot of commits, but see the final diff , no so much :)

@tmenguy  can you take a quick peek at https://github.com/cliviu74/wallbox/pull/51/commits
This is the timeout issue fixed as you suggested.
I'll split the jwtToken in a few minutes

great, thanks a lot :)

actually if you merge your #51 I rebase and this one will be the token

so you don't have to create a new one

Can we move past this :) Will add ecosmart mode handling support right after

thx for the wrongly added files :) cleaned it with bfg, do you think we can merge this one now?

an up to merge it ?

Left a few comments on it. As it looks at the moment, I don't see the need for a retry authentication based on http code return. The way I see it, if authentication fails, it should return with an error rather than retry.
There is a change of retry storms if upstream api has a temporary issue.

You don't need to destroy the object, you can simply reauthenticate. If you want to force a token reissue, you can just wipe the token and reauthenticate (see code below)
`from wallbox import Wallbox, Statuses
from dotenv import load_dotenv
import os
import hashlib
if "WALLBOX_USER" not in os.environ:
load_dotenv()
wallboxUsername = os.getenv("WALLBOX_USER")
wallboxPassword = os.getenv("WALLBOX_PASS")
def caculateHash256(hashedString):
hashedString = hashedString.encode()
return hashlib.sha256(hashedString).hexdigest()
w = Wallbox(wallboxUsername, wallboxPassword)
Authenticate with the credentials above
w.authenticate()
Print a list of chargers in the account
print(f"Chargers under the account {wallboxUsername}: {w.getChargersList()}")
oldToken = caculateHash256(w.jwtToken)
w.jwtToken  = ""
w.authenticate()
newToken = caculateHash256(w.jwtToken)
print(f"Old hashed token: {oldToken}\nNew hashed token: {newToken}")
`
python3 example-token-reissue.py                                                                                Chargers under the account *********: [*******] Old hashed token: 6fcba25979030f1cabb609f0ddbd9eaa13818f2335e36e0e53eb7eb6097047ba New hashed token: cf8fbf6bacbaaa2be053c14712d41f1c8117d8b8d8a9c37a5c3000b7606754c4

Yes, but you need to do : w.jwtToken  = "" which requires a good understanding of the library intricacies, a token should be a hidden variable nobody outside the library should access: what I was proposing was doing it automatically only when needed.
It is more of a design philosophy here : does your library should be fixing the issues/specificities of the system you abstract with it.
As an example the Wallbox APIs needs a timeout by default as they sometimes miss-behave, this is not common knowledge, hence having a good default timeout tuned for those issues would make more sense. Here it is the same : knowing that sometimes the refresh of the refresh token need to be done is not common knowledge, hence I do think it should be abstracted by the library : rule of thumb here if every single use of a library need the exact same code wrapper, or outside fixing, it should be made as default in the library :) ... but again a design choice, I personally prefer to no put the burden of fixing what I'm abstracting to every single user of the abstraction, but again, no pb it is your library. But as an example the Homeassitant integration will need already 2 changes : one for the timeout, one for the token refresh, where a fix in the library would make the life better of all users of the Wallbox library without any hassle.
Tell me what you prefer, no worries, I'll simply maintain my fork and make it evolves (or make a radically different async version :) ).

As raised earlier, my concern is around the handling of a refresh issued on every http error. A better implementation needs to be considered to ensure the token is refreshed only when it's not valid, not on every possible error as it's proposed by this change.
We are running at risk of possible locking people's wallbox account by causing a retry storm, under the current implementation when the upstream api will error out with anything else than a 401 http code.
Coming back to the token implementation, if the token is no longer valid before it's expired, it needs to be handled upstream, or at least it needs to be handled better by the authenticate method. I just don't see how your change is fixing this by issuing a continuous authentication if there is a http error returned by the upstream api. Again, this is an interface library, not an application in itself.
I would also like to address here that, while I appreciate your contributions which have been extremely valuable, I don't appreciate the suggestion that you can fork the library because you disagree with the design choice. Of course you are welcomed to maintain a fork if you feel this design fundamentally contradicts your views on how an interface library should operate, you don't need my permission to do so. I do hope though we can collaborate to maintain a useful and safe library for people to use.
I must stress out that this is an UNOFFICIAL library that using an upstream commercial API and we aresponsibility not to cause any harm to the users of this library as well as ensuring we're not abusing Wallbox service (i.e. by causing a retry storm). That's why I am taking my role of vetting the changes and asking questions until I make sure we are doing this to the best of our abilities. I hope you appreciate this.
I am also looking for active maintainers of this, people who can vet and merge changes, if you'd like to become one we can have a discussion.

Hi,
As for the error issue: it will throw an exception after the first call if it fails, it is not an infinite loop we have here, but yes it would do 2 call instead of one at each error, I'll commit one that wil reset the token explicitly
" I don't appreciate the suggestion that you can fork the library because you disagree with the design choice" : slight misunderstanding here, written language is messy (esp for a non native speaker like me) ... would be for my own use, no real point here to compete or anything, just having my fork for my needs.
And I appreciate the discussion we have anyway, and yes good that you take seriously your role here, its why I don't want to push too hard for changes you are not confortable with.

just pushed a change (virtually equivalent, but potentially one less API call in case a user of the library catch an auth error an retries to call it)

Hopefully this time we are ok with the latest changes :)

up

Hi probably last time I’m asking, I changed the PR to be pretty close to the the reset you were mentioning, could  you just say yes or no here please so I can move on?

Up

Hi @cliviu74 , is there an issue on your side (or a long vacation!) … after a month of silence time to ask again…

up


Add Series.in/2 tests for boolean series

This adds boolean series tests for Series.in/2 and rounds out https://github.com/elixir-nx/explorer/pull/475.
Addition to the tests (https://github.com/elixir-nx/explorer/pull/477/commits/7936681622cfb7d792f696749d84c3167d0f4b4d) written in https://github.com/elixir-nx/explorer/pull/477.
Original PR: https://github.com/elixir-nx/explorer/pull/420
Thanks y'all! :purple_heart:

@miXwui thank you! :purple_heart:


fatal error: cub/cub.cuh: No such file or directory

I am trying to setup Hetu with CUDA 10.2. I have followed all the steps provided in the README.MD, but I am facing an issue while performing the make -j 8 step. I have installed CUB from https://github.com/NVIDIA/cub/releases/tag/1.12.1 and used appropriate path in cmake.config file. However, I always get an error saying fatal error: cub/cub.cuh: No such file or directory.

Is it possible to attach a sample cmake.config file for reference?

Hi @lmohit95, this may be a feasible way to solve this problem:
mv cub-1.12.1/cub  /usr/local/cuda/include

Run this script in the folder where you unzipped the cub-1.12.1.zip before performing the make -j 8 step. In this way, it will not be requisite to modify cmake.config.

Thanks a lot. It worked.


Website down

I cant access the website. Can't ping it either. Dont know if it should be an issue on the repo, but I dont where else to put it :)

Mat said the website would be down forever. However, you can clone this repo and host it yourself.

Oh. I hosted it but I dont get the data for some reason


[Bug]: User is able to remove items from the cart at the checkout

What happened?
When calling checkout I add two items:

Base price, quantity 1;
Price for storage, quantity 50.

The price for storage has constraints that it has to be between 50 and 1000 (Gb).
At the checkout the user is able to change the quantity for storage within the allowed limits but is also able to completely remove this item. I do not want them to be able to remove it.
I can not find any setting that would prevent user from modifying the items at the checkout, even if I create a transaction using the API and pass the transaction id to the paddle.checkout.open() method

Steps to reproduce

Create two products, one with a price price and allowing quantity 1 to 1; second one with a price allowing quantity between 50 and 1000
Call paddle.checkout.open() for two items - base product and storage product (quantity 50)
User is able to remove the storage during the checkout

What did you expect to happen?
No response
How are you integrating?
No response
Logs
No response

Screenshot of the price configuration for storage:

Hey @marinaglancy 👋
Thanks for taking the time to send in such a detailed issue. Setting a quantity limit against a price lets you specify the maximum and minimum units for an item when buying, but it doesn't require a customer to buy an item. In your example, it'll stop the customer from buying fewer than 50 units, but won't stop them removing the item altogether.
There's a few things you can do here that might help:

If you're creating a transaction using the API then passing it to Paddle.js, you can mark the transaction as billed to prevent quantity changes. Billed transactions cannot be changed, so the quantity stepper and delete icon for items aren't presented.
If you're passing items and customer data when opening a checkout so that customers land on the payment screen, the transaction for the checkout is created as ready. You can use an eventCallback to listen for checkout events, then send a request to the Paddle API to mark a transaction as billed.
You can consider using inline checkout instead of overlay. With inline checkout, you can present the items list yourself. This means you that you don't need to include the option to change quantities or remove items. We have a simple Codepen that includes an items list with no quantity stepper.

Here's a quick screenshot of how overlay checkout looks for a billed transaction 👇

Stopping customers from removing an item like this is feedback that we've had before, so I chatted with the PM who heads up checkout to let them know it's something that you're looking for too. In the meantime, I'm going to mark this as a feature request and close the issue. Pop back and let us know how you get on with the suggested solutions, and feel free to reopen the issue if there's anything else we can do to help 😄

Thank you very much! Marking transaction as billed worked perfectly


Add benchmarks for f32 & f64 operations.

[xxx@xxx]:~/projects/wagon/exec> go test -bench=BenchmarkF github.com/go-interpreter/wagon/exec
goos: linux
goarch: amd64
pkg: github.com/go-interpreter/wagon/exec
BenchmarkF64Arithmetic10Interpreted-8   	  100000	     14344 ns/op
BenchmarkF64Arithmetic10Native-8        	  300000	      4343 ns/op
BenchmarkF32Arithmetic10Interpreted-8   	  100000	     13365 ns/op
BenchmarkF32Arithmetic10Native-8        	  300000	      4240 ns/op
PASS
ok  	github.com/go-interpreter/wagon/exec	7.688s

Looks like the floating point operations are only ~3x faster instead of ~5x. I think this is attributable to missing operations for conversion from integer to float - hopefully I'll get around to that this weekend.

Codecov Report

Merging #128 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #128   +/-   ##
======================================
  Coverage    66.5%   66.5%
======================================
  Files          41      41
  Lines        4490    4490
======================================
  Hits         2986    2986
  Misses       1233    1233
  Partials      271     271

Continue to review full report at Codecov.

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

this should have "improved" the benchmarks, right? :)

Dont think so, as processors arent much faster on 32bit floats than 64bit floats?

my naive assumption was that pipelines would be somewhat more full.


homework-9

Topics Covered

@Profile
@Slf4j
@ControllerAdvice
DTOs

Screenshots
start
Drift Video
Watch the Drift Video

Metric
Value

alert_status
:white_check_mark: OK

bugs
0

code_smells
0

reliability_rating
A (0 Bugs)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0

Metric
Value

alert_status
:x: ERROR

bugs
0

code_smells
0

reliability_rating
A (0 Bugs)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


UP-4529: Replace form text input with select in Skin Manager pop-up.

https://issues.jasig.org/browse/UP-4529

@bjagg this looks like a good change... is it working?

@drewwills Yes, from the limited testing I did it was working quite well.

+1


ParseError: 'import' and 'export' may appear only with 'sourceType: module'

hi @alessioalex ,
i'm using your workflow for build (angular2 beta1), all is working fine but got stuck in following error
F:\nodeApp\angular2-browserify\node_modules\angular2moment\TimeAgoPipe.ts:3
import {Pipe, ChangeDetectorRef, PipeTransform, OnDestroy} from 'angular2/core';
^
ParseError: 'import' and 'export' may appear only with 'sourceType: module'
please help as soon as possible.

Hi @shaibansid . Delete node_modules, reinstall everything again and also install the latest typescript available globally: npm i typescript -g. Let me know if that fixes the problem.

@alessioalex Many thanks, by upgrading solve my problem.


[ClangImporter] Handle submodule imports in bridging headers

If a bridging header imported a submodule but not the top-level module, the top-level module would never be made visible. This is a problem since the Clang importer makes all top-level decls available through their enclosing top-level modules, not the individual submodules.
To fix this, stop special-casing the way we handle bridging header imports; we can translate them from Clang Modules to Swift ModuleDecls the same way we do for regular imports.
rdar://problem/37355259

Yes, that's it. That code already handles submodules, and what we had before didn't, so just stop doing what we had before.


in KQAPro's 'kb.json' there is 'subClassOf' instead of 'instanceOf' for concepts

In the code: https://github.com/shijx12/KQAPro_Baselines/blob/master/utils/load_kb.py#L15
knowledge json format:
    'concepts':
    {
        'id':
        {
            'name': '',
            'instanceOf': ['<concept_id>'],
        }
    },
......

While in KQAPro's dataset:
{
    "concepts": {
        "Q7270": {
            "name": "republic",
            "subclassOf": [
                "Q7174"
            ]
        },

in the paper: (KQA Pro)

Using subClassOf might be more reasonable comparing to instanceOf?

The newly updated version fixed this problem.


BENCH: optimize: add DFO CUTEST benchmark

What does this implement/fix?
This PR adds the smooth DFO benchmark set of Moré and Wild, and changes the default behavior of Wolfe line search (when called from BFGS) to use cheaper directional derivative finite differencing if the gradient function is based on finite differencing (if a regular gradient function is provided, that is still used).
Additional information
The DFO benchmark results on the current scipy (for BFGS):

The DFO benchmark results on the version in this PR (for BFGS):

These are summarized in a histogram of performance ratio (number of function evaluations used by each version divided by the number of function evaluations used by the fastest of the two versions):

For most problems either approach is about the same (within a factor of 2), but there are a few problems where the new version is much faster.

I guess another alternative that could be tried is a wrapper function?

@sarafridov It looks like there are still a few reviewer comments to address. Since we'll be cutting the next release branch soon I may bump the milestone if you don't have the bandwidth to circle back here before Monday.

Yes, sorry I got busy with other stuff but I’ve been meaning to finish this. I’ll try to make the edits and reply before Monday, but if I don’t have time it’s ok to put it in the next release.
Thanks,
Sara

On Dec 2, 2021, at 7:32 PM, Tyler Reddy @.***> wrote:
@sarafridov https://github.com/sarafridov It looks like there are still a few reviewer comments to address. Since we'll be cutting the next release branch soon I may bump the milestone if you don't have the bandwidth to circle back here before Monday.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/scipy/scipy/pull/14579#issuecomment-985186711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD2LCP6AEJTCQLHJZ44U6HLUPA243ANCNFSM5CAM7WFA.
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I think I've addressed all of these issues, but there are some merge conflicts I'm not sure how to resolve (and these seem to be blocking the tests from running).

You may also need help figuring out how to push my branch into here. After spot checking that branch form my fork, and perhaps backing up your branch locally, you could so something similar to this to push from one branch to another with a different name (and would likely need a force push in this case with -f).

I won't be able to look at this until mid next week.

Thanks for fixing the merge conflict! I think I managed to get your branch into my local state, but I'm trying to run the tests locally before I push it back here, and I'm getting a build error FileNotFoundError: [Errno 2] No such file or directory: 'scipy/stats/biasedurn.pxd' when I run python runtests.py. I think this is happening because biasedurn.pxd was renamed, but I'm not sure why the test build seems to be expecting the old version. Are you able to run tests locally in your branch treddy_gh_14579_rebase?

I'll bump the milestone here because this is a big PR and I'm a bit nervous to merge it before branching without a high degree of certainty that it is "ok." It looks like I was supposed to help move this forward a bit more so I'll make a note to circle back soon if an optimize expert doesn't beat me to it.

Thanks Tyler!

On May 29, 2022, at 1:51 PM, Tyler Reddy @.***> wrote:
I'll bump the milestone here because this is a big PR and I'm a bit nervous to merge it before branching without a high degree of certainty that it is "ok." It looks like I was supposed to help move this forward a bit more so I'll make a note to circle back soon if an optimize expert doesn't beat me to it.
—
Reply to this email directly, view it on GitHub https://github.com/scipy/scipy/pull/14579#issuecomment-1140522333, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD2LCPYCKVLCQNZJOMRRUNTVMPKEXANCNFSM5CAM7WFA.
You are receiving this because you were mentioned.

@sarafridov Thanks for you patience! I'd like to help get this merged. One thing that I think would help is if we could split the benchmarks from the rest of the PR. Would you mind if we start with the benchmarks in this PR, then we can create a new PR for the line search enhancement? I can resolve the merge conflicts for you and push back to your branch, if that's OK with you. The line search enhancements will still be in the commit history, and I'll create a backup before merging just in case, but you might want to create your own backup branch, too.

Sure, thanks Matt! Any help merging is appreciated :)

Excellent I'll do that shortly!

OK. I removed the directional derivative part, which we'll merge as part of another PR.

I thought about keeping _that_ part here and asking you to make the new PR with the benchmarks (instead of vice-versa) to preserve the link between comments and code, but there weren't many comments directly linked to the code anyway, and we can always refer back to the comments in this PR if need be. When the history gets long, sometimes it's nice to start with a clean slate.

A few questions about the benchmarks:

Did this commit make any non-formatting changes?  It looks like you used Black to format those. That's fine for new files, but please don't use it on existing files. SciPy hasn't adopted Black yet, so it makes it difficult to see what's really going on with amidst all the formatting changes.
Are reference values for the optimal value of the objective function available? I'd like to track the difference between the values found by our optimizers and the reference value.
Can you find the licenses for the references for any code you referenced for the benchmarks and link to them here? (It looks like you manually translated from Matlab to Python?)

Also, I see that Tyler mentioned that these are written like others in this file, but they don't follow the usual ASV pattern. If I were to provide a different reference to follow, would you be willing to refactor these, or would you prefer that I take care of it and push the changes here?
Thanks!

I think the only non-formatting change there was in test_linesearch.py, where it looks like I reverted a function signature change that I had added in a previous commit
I think the optimal objective values are zero for all of these, but now I can't find where I got that from unfortunately.
I did indeed manually translate from MATLAB to Python, since I couldn't find an existing Python implementation. The original MATLAB versions came from https://www.mcs.anl.gov/~more/dfo/, which is the supplement to the paper Benchmarking Derivative-Free Optimization Algorithms by J. Moré and S. Wild. SIAM J. Optimization, Vol. 20 (1), pp.172-191, 2009. Each MATLAB file has a header comment that references the paper and original authors but doesn't explicitly include a license as far as I can tell. However, the website says that the benchmark functions were derived from those in the CUTEr problem set, which includes this license: https://github.com/ralna/CUTEst/blob/master/LICENSE

Regarding reformatting, I probably won't have time to do much before mid-November; if you want to reformat things earlier please go for it, and otherwise I can take a stab at it then. Thanks!

@rgommers @tylerjereddy thought I should check with you since you commented about the benchmarks above:
On one hand, the original CUTEst benchmarks are LGPL, and the Matlab translation from which these Python versions were derived are not explicitly licensed. On the other hand, there are only so many ways to write a mathematical function like these, and I don't think LGPL covers the mathematical functions themselves. What would you suggest to avoid copyright issues here? My inclination would be the conservative route - check with both the Matlab and the original CUTEst authors for permission to relicense these under BSD before including these.

OK. I removed the directional derivative part, which we'll merge as part of another PR.

Would you mind updating the title and main PR description? I was confused for a while when looking at the PR diff.

What would you suggest to avoid copyright issues here? My inclination would be the conservative route - check with both the Matlab and the original CUTEst authors for permission to relicense these under BSD before including these.

Agreed. In particular the CUTEst author permission seems important. There's enough code and it's specific enough that it's clear that it is derived from the original code; writing it from scratch probably would not have yielded such a close match.

@sarafridov The CUTEst license is LGPL, and my understanding is that derivative works of LGPL code must be LGPL-licensed. This means that neither the Matlab code you referenced or the code you wrote can be distributed under a more permissive license, like SciPy's BSD 3-Clause license, without an exception being made. Would you be willing to contact the original authors of these benchmarks and ask for permission for SciPy to distribute them under our BSD 3-Clause license?

@sarafridov The CUTEst license is LGPL, and my understanding is that derivative works of LGPL code must be LGPL-licensed. This means that neither the Matlab code you referenced or the code you wrote can be distributed under a more permissive license, like SciPy's BSD 3-Clause license, without an exception being made. Would you be willing to contact the original authors of these benchmarks and ask for permission for SciPy to distribute them under our BSD 3-Clause license?

@sarafridov can respond in full, but the original matlab (& fortran) code for this test set is BSD 3-slaused: https://github.com/POptUS/BenDFO

Thanks @wildsm. It says in the paper that "We use a selection of problems from the CUTEr collection". Just to be explicit, this means that the code in POptUS/BenDFO was written independently of any LGPL-licensed code; it was just written based on the same mathematical problems? If so, then yes, I don't think we would need any further permission.
(The concern was that if the code in POptUS/BenDFO was derived from CUTEr code, then any derived code may need to be LGPL-licensed per the terms of the LGPL.)

@mdhaber, correct: the BenDFO problems are based on mathematical problems in cuter (now cutest: https://github.com/ralna/CUTEst) but were new implementations of those algebraic problems.

That's great to hear. Thanks @wildsm! I really appreciate the work!
The comment above suggested that the optimal values of the objective function were all zero, but sounded unsure. Is that right? (Another thing I'd like to track here is the difference in the achieved objective function value from the reference.)

That's great to hear. Thanks @wildsm! I really appreciate the work!
The comment above suggested that the optimal values of the objective function were zero for all problems, but sounded unsure. Is that right? (Another thing I'd like to track here is the difference in the achieved objective function value from the reference.)

It is not the case the all of the original 53(4 since there are 4 problem types in calfun) problems admit a solution f=0.
Noting an achievable objection function value is a good aspiration, but probably most meaningful for the 'smooth' problem class.
Instead, since these are sums of squares, for now it would be safest to say that the objective function is always bounded below by 0 (and hence achieving a near-zero value is a good target).

As a side question - based on your experience, are there free, permissively-licensed optimizers that we don't already include in SciPy that we should add? (Here's our current list.) We've also considered allowing minimize to use IPOPT (via cyipopt) as an optional dependency, which the user would need to install separately because its license is incompatible. Do you think that would be valuable?

There are several permissively licensed optimizers that could be added, but I do not want to distract from the current PR.
If there is an issue or project that you could link me to or otherwise have a way for the broader teams to address (and potentially improve optimizer options in scipy), I will try to help.
Thanks to @sarafridov and you all for your efforts.

Thanks for the quick replies and info @wildsm!

I'll make that change and merge this. I decided that the format of the benchmarks is OK for now - the system used by the global optimizers (which was used in this PR) is not standard (e.g. it uses track_all for timing instead of time_all), but there are some advantages, so there's no need to refactor.

I ran this locally and these seem like a useful set of problems. They are quite fast to run, but they do expose some unusual behavior in some optimizers (e.g. COBLYLA quite frequently maxes out at 1000 function evaluations). I haven't checked that they are translated exactly, but the solvers seem to agree on the optimal value of the objective function in most cases. One oddball is 17:
[100.00%] ··· ============================== ============== =========== ========================
              --                                                        result type
              --------------------------------------------- ------------------------------------
               DFO benchmark problem number      solver      mean_nfev          min_obj
              ============================== ============== =========== ========================
                            17                   COBYLA         48.0       7182338.049392037
                            17                   SLSQP         139.0<PHONE_NUMBER>.8110585
                            17                   Powell        296.0<PHONE_NUMBER>7479208
                            17                nelder-mead      600.0       6409.119264481873
                            17                  L-BFGS-B        16.0       6977375.029202724
                            17                    BFGS         1852.0<PHONE_NUMBER>2271016
                            17                trust-constr     2484.0      27559.144777426165

So it might be worth a look at the translation - did it turn into an unbounded maximization, or are the solvers really struggling?  I should check that the failure of the solvers is being tracked, too. (separately).
I'll go ahead and merge if CircleCI comes back green.

[100.00%] ··· ============================== ============== =========== ========================
              --                                                        result type
              --------------------------------------------- ------------------------------------
               DFO benchmark problem number      solver      mean_nfev          min_obj
              ============================== ============== =========== ========================
                            0                    COBYLA        182.0       36.00000001629636
                            0                    SLSQP          21.0       35.99999999999999
                            0                    Powell        231.0       35.99999999999998
                            0                 nelder-mead      1390.0      36.000000004916636
                            0                   L-BFGS-B        30.0       36.00000000029088
                            0                     BFGS          40.0       36.00000000000747
                            0                 trust-constr      30.0       36.00000000006579
                            1                    COBYLA        239.0       36.00000002161123
                            1                    SLSQP          21.0              36.0
                            1                    Powell        374.0       35.99999999999997
                            1                 nelder-mead      1096.0      36.00000001672908
                            1                   L-BFGS-B        50.0       36.00000000000113
                            1                     BFGS          60.0       36.00000000512027
                            1                 trust-constr      40.0        36.0000000000484
                            2                    COBYLA         93.0        8.38460155098156
                            2                    SLSQP          23.0       8.380281690140846
                            2                    Powell        217.0       8.380281690140844
                            2                 nelder-mead      276.0       8.380314322959702
                            2                   L-BFGS-B        32.0       8.380281690152533
                            2                     BFGS         268.0       8.380281698083904
                            2                 trust-constr      40.0       8.380281690145555
                            3                    COBYLA        107.0       8.400780446868142
                            3                    SLSQP          23.0       8.380284602260867
                            3                    Powell        196.0       8.380281690140844
                            3                 nelder-mead      320.0       8.380314069260285
                            3                   L-BFGS-B        40.0       8.380281690152607
                            3                     BFGS         380.0       8.380281690223411
                            3                 trust-constr      48.0       8.380281690221938
                            4                    COBYLA        103.0        9.89172925972701
                            4                    SLSQP          23.0       9.880597014925373
                            4                    Powell        256.0       9.880597014925371
                            4                 nelder-mead      267.0       9.880630904843933
                            4                   L-BFGS-B       112.0       9.880597014925657
                            4                     BFGS         462.0        9.88059701530113
                            4                 trust-constr     136.0       9.880597014929531
                            5                    COBYLA        124.0       9.880673204658704
                            5                    SLSQP          23.0       9.880597015430164
                            5                    Powell        186.0       9.880597014925371
                            5                 nelder-mead      310.0       9.880645653536046
                            5                   L-BFGS-B        40.0       9.880597014932858
                            5                     BFGS         316.0       9.880597014940241
                            5                 trust-constr     200.0       9.880597014935532
                            6                    COBYLA        1000.0      0.2761343670249867
                            6                    SLSQP         109.0     3.534301293924672e-05
                            6                    Powell        665.0     1.7404243721438573e-26
                            6                 nelder-mead      159.0     8.177661197416674e-10
                            6                   L-BFGS-B       126.0     3.0327590958858587e-07
                            6                     BFGS         114.0     9.730195046515482e-11
                            6                 trust-constr     177.0     5.200784532767023e-09
                            7                    COBYLA        1000.0      18.15444498891401
                            7                    SLSQP         295.0     2.4772818584112955e-05
                            7                    Powell        1039.0    1.1093356479670479e-31
                            7                 nelder-mead      325.0     4.3387935016943286e-10
                            7                   L-BFGS-B        33.0       18.35859455706266
                            7                     BFGS         417.0     2.2882524907281913e-11
                            7                 trust-constr     375.0     2.746553712615791e-09
                            8                    COBYLA        1000.0    0.0036908922090317185
                            8                    SLSQP         112.0     2.467526280245205e-06
                            8                    Powell         67.0              0.0
                            8                 nelder-mead      142.0     0.0003575878654431348
                            8                   L-BFGS-B       120.0     1.2590925940553836e-08
                            8                     BFGS         136.0      3.64407093097148e-12
                            8                 trust-constr     128.0     4.6652773496330196e-12
                            9                    COBYLA        1000.0      1.5616155551517263
                            9                    SLSQP         114.0     3.1446883905430233e-06
                            9                    Powell         60.0              0.0
                            9                 nelder-mead      110.0     0.0001185672468711772
                            9                   L-BFGS-B       140.0     1.0985609971404184e-05
                            9                     BFGS         160.0     4.353936427472428e-12
                            9                 trust-constr     172.0     1.1084157363858046e-10
                            10                   COBYLA        1000.0    0.0018267758852006735
                            10                   SLSQP          99.0     9.231453061284653e-05
                            10                   Powell        997.0     1.692602785645291e-13
                            10                nelder-mead      305.0     1.3905860499424258e-06
                            10                  L-BFGS-B       100.0     3.5701552391704273e-05
                            10                    BFGS         165.0     3.266272925189801e-07
                            10                trust-constr     190.0     3.4240610197075264e-07
                            11                   COBYLA        1000.0     0.007588035155492048
                            11                   SLSQP         179.0      3.44391715908274e-05
                            11                   Powell        1742.0    3.0130545641301406e-22
                            11                nelder-mead      380.0     1.2207288155937388e-06
                            11                  L-BFGS-B       165.0     2.5695461782917457e-05
                            11                    BFGS         280.0     1.908979241735041e-07
                            11                trust-constr     355.0     2.208504660413736e-07
                            12                   COBYLA        1000.0      63.35600768650094
                            12                   SLSQP          28.0        48.9842541402506
                            12                   Powell        130.0       48.98425367924135
                            12                nelder-mead      120.0       48.98425367981376
                            12                  L-BFGS-B        54.0       48.98425585246278
                            12                    BFGS          27.0       48.98425367924929
                            12                trust-constr      60.0       48.98425367924165
                            13                   COBYLA        1000.0       52.5180366249726
                            13                   SLSQP          47.0       48.984285104912686
                            13                   Powell        255.0       48.984253679248496
                            13                nelder-mead      119.0     1.7922698821282258e-09
                            13                  L-BFGS-B        90.0        48.9843135995884
                            13                    BFGS          75.0       48.984253679241974
                            13                trust-constr      84.0       48.98425367938097
                            14                   COBYLA        1000.0     0.010846968025621654
                            14                   SLSQP          36.0      0.010926876593972496
                            14                   Powell        482.0      0.008214880387696202
                            14                nelder-mead      226.0      0.008214877316410097
                            14                  L-BFGS-B        36.0      0.009974372219517814
                            14                    BFGS          92.0      0.008214877322486921
                            14                trust-constr      96.0      0.00821493131546288
                            15                   COBYLA        1000.0       8.3527643805625
                            15                   SLSQP          80.0      0.010852444332488186
                            15                   Powell        232.0       1.7749269756254313
                            15                nelder-mead      346.0      0.008214877318251797
                            15                  L-BFGS-B        92.0      0.010443321669298032
                            15                    BFGS         136.0      0.008214877306853469
                            15                trust-constr     1924.0     0.008214941209108827
                            16                   COBYLA        1000.0    0.00038308147268715565
                            16                   SLSQP          22.0     0.0005011638818990982
                            16                   Powell        570.0     0.00030750560950841397
                            16                nelder-mead      260.0     0.00030750561104950664
                            16                  L-BFGS-B        45.0     0.0004998454312085443
                            16                    BFGS         165.0     0.0003075071717883809
                            16                trust-constr     170.0     0.00030985544885250914
                            17                   COBYLA         48.0       7182338.049392037
                            17                   SLSQP         139.0<PHONE_NUMBER>.8110585
                            17                   Powell        296.0<PHONE_NUMBER>7479208
                            17                nelder-mead      600.0       6409.119264481873
                            17                  L-BFGS-B        16.0       6977375.029202724
                            17                    BFGS         1852.0<PHONE_NUMBER>2271016
                            17                trust-constr     2484.0      27559.144777426165
                            18                   COBYLA        1000.0     0.010975991274795866
                            18                   SLSQP         145.0     0.0031019739183846718
                            18                   Powell        1926.0    0.0022876970870087574
                            18                nelder-mead      1200.0     0.004794624522076027
                            18                  L-BFGS-B       133.0      0.009260103353715464
                            18                    BFGS         266.0      0.002287670084218029
                            18                trust-constr     371.0      0.002287793309747557
                            19                   COBYLA        1000.0     0.01449258959907267
                            19                   SLSQP         334.0      0.002387635461912692
                            19                   Powell        2028.0     0.017136978287569753
                            19                nelder-mead      1200.0     0.11412012392582763
                            19                  L-BFGS-B       224.0      0.010392828812354508
                            19                    BFGS         518.0      0.002287670118424779
                            19                trust-constr     546.0     0.0022896826830664527
                            20                   COBYLA        1000.0     0.012314747076097223
                            20                   SLSQP         435.0     3.7403380991915257e-05
                            20                   Powell        3856.0    0.00013999662219714502
                            20                nelder-mead      1275.0    0.0037644989112963437
                            20                  L-BFGS-B       270.0     0.0028719244514205464
                            20                    BFGS         410.0     3.797654976888867e-05
                            20                trust-constr     540.0     3.911398406372046e-05
                            21                   COBYLA        1000.0     0.19021806725341522
                            21                   SLSQP         975.0      0.005234314850263207
                            21                   Powell        5562.0     0.10605836851573695
                            21                nelder-mead      1800.0      0.5377026960946113
                            21                  L-BFGS-B       500.0     0.00028813027873123817
                            21                    BFGS         1010.0    1.8827451845615612e-06
                            21                trust-constr     1900.0    4.185790050233788e-05
                            22                   COBYLA        1000.0     0.10003177690766717
                            22                   SLSQP         613.0      0.007622482850835413
                            22                   Powell        9933.0    0.0009381552314367413
                            22                nelder-mead      2400.0     0.008256161684722775
                            22                  L-BFGS-B       741.0      0.000314364893841669
                            22                    BFGS         1001.0    1.8916384785289867e-06
                            22                trust-constr     1118.0    1.3321351943695367e-05
                            23                   COBYLA        1000.0      0.2362971492708929
                            23                   SLSQP         1331.0     0.10106796888625674
                            23                   Powell        5265.0      6.567880194260053
                            23                nelder-mead      2400.0      5.580001849914321
                            23                  L-BFGS-B       806.0      0.011298205825883999
                            23                    BFGS         2002.0    0.0003297859042824798
                            23                trust-constr     1950.0    1.3757805796874542e-05
                            24                   COBYLA        1000.0    0.0027210848918468693
                            24                   SLSQP          85.0      0.039023423059962446
                            24                   Powell        1522.0      0.0758318699160596
                            24                nelder-mead      480.0      0.07558874075499751
                            24                  L-BFGS-B       100.0     0.00023411051762240796
                            24                    BFGS         108.0     4.177123227644773e-09
                            24                trust-constr     132.0     2.2154751422553546e-06
                            25                   COBYLA         32.0<PHONE_NUMBER>452771
                            25                   SLSQP          16.0             2020.0
                            25                   Powell        329.0<PHONE_NUMBER>304955
                            25                nelder-mead       72.0<PHONE_NUMBER>396066
                            25                  L-BFGS-B        72.0<PHONE_NUMBER>4503868
                            25                    BFGS         147.0<PHONE_NUMBER>5561681
                            25                trust-constr     189.0<PHONE_NUMBER>5561688
                            26                   COBYLA        678.0       85822.20465825836
                            26                   SLSQP         130.0       85822.20163050466
                            26                   Powell        301.0       85822.24229503317
                            26                nelder-mead      333.0       85822.20162974804
                            26                  L-BFGS-B        70.0       85822.28180418117
                            26                    BFGS         215.0       85822.20162635631
                            26                trust-constr     235.0        85822.2016263593
                            27                   COBYLA        928.0       85822.20748496873
                            27                   SLSQP         252.0       85822.20162647964
                            27                   Powell        286.0       85822.29989083631
                            27                nelder-mead      397.0       85822.20164251165
                            27                  L-BFGS-B       155.0       85822.21347725767
                            27                    BFGS         591.0       85822.20162635631
                            27                trust-constr     405.0       85822.20162635841
                            28                   COBYLA        274.0     4.567933585235919e-06
                            28                   SLSQP          73.0     0.0001275291143854763
                            28                   Powell        2192.0     2.62902981284408e-22
                            28                nelder-mead      630.0     4.168900076322192e-09
                            28                  L-BFGS-B       112.0     9.673403808567107e-07
                            28                    BFGS         140.0     1.3393622123502154e-10
                            28                trust-constr     175.0     1.819529612033121e-10
                            29                   COBYLA        169.0     7.228441475939319e-07
                            29                   SLSQP          58.0     0.00017792262972978623
                            29                   Powell        2227.0    6.554533948298135e-23
                            29                nelder-mead      472.0     4.392761093121637e-07
                            29                  L-BFGS-B       112.0     2.0258935263141074e-05
                            29                    BFGS         176.0     6.136941614799513e-11
                            29                trust-constr     152.0     2.4623717975095197e-10
                            30                   COBYLA        1000.0    0.0036544588617460697
                            30                   SLSQP          72.0      0.006287589283329275
                            30                   Powell        3018.0    0.0035168774842111537
                            30                nelder-mead      813.0     0.0037430185611118747
                            30                  L-BFGS-B       180.0     0.0036331210832657988
                            30                    BFGS         270.0     0.0035168737463856397
                            30                trust-constr     333.0     0.0035168739464551393
                            31                   COBYLA        507.0     9.563260675050992e-06
                            31                   SLSQP         113.0     7.559376195674753e-05
                            31                   Powell        5182.0    1.4405961280325035e-21
                            31                nelder-mead      1008.0    1.993137661280346e-05
                            31                  L-BFGS-B       190.0     0.00016452253916588005
                            31                    BFGS         290.0     4.226424638113484e-11
                            31                trust-constr    10000.0     0.00860514728003039
                            32                   COBYLA        1000.0     0.004996093419091057
                            32                   SLSQP          76.0      0.00748298302440139
                            32                   Powell        2362.0     0.00654899679530417
                            32                nelder-mead      1142.0     0.004782384226390245
                            32                  L-BFGS-B       143.0      0.00751254641713398
                            32                    BFGS         418.0      0.006503955074807308
                            32                trust-constr    11000.0     0.03376312998006939
                            33                   COBYLA        1000.0     0.004790522744041185
                            33                   SLSQP          80.0      0.006136919804702198
                            33                   Powell        4848.0    0.0027998978593152275
                            33                nelder-mead      1799.0    0.0031707681652494613
                            33                  L-BFGS-B       312.0      0.002823158486757189
                            33                    BFGS         504.0     0.0027997618778556575
                            33                trust-constr    12000.0     0.026740538342589985
                            34                   COBYLA        1000.0     0.002477075965308623
                            34                   SLSQP          47.0     1.8202225661529484e-05
                            34                   Powell        3303.0    1.3549012557932144e-22
                            34                nelder-mead      2000.0      0.3406697389548668
                            34                  L-BFGS-B        55.0     2.991968759920641e-05
                            34                    BFGS         132.0     1.8709798615677602e-13
                            34                trust-constr     154.0     1.7082950861593002e-08
                            35                   COBYLA        1000.0      2.7742441299951137
                            35                   SLSQP          74.0       1.1056629223458196
                            35                   Powell        712.0      0.050641072866261495
                            35                nelder-mead      747.0      5.46489474798272e-05
                            35                  L-BFGS-B       108.0       1.105965377496062
                            35                    BFGS         132.0       0.6345415441186326
                            35                trust-constr     192.0       1.105960125097165
                            36                   COBYLA        1000.0     0.29941668888383516
                            36                   SLSQP         426.0      0.04140439863979013
                            36                   Powell        3474.0     0.04014330272700565
                            36                nelder-mead      2200.0     0.07609312836138543
                            36                  L-BFGS-B       684.0      0.04203767275972611
                            36                    BFGS         756.0      0.04013773868180521
                            36                trust-constr     1056.0      0.0401377475379302
                            37                   COBYLA        252.0       1.7898162978212655
                            37                   SLSQP         228.0       1.789825242674377
                            37                   Powell        682.0       1.7898135868820384
                            37                nelder-mead      809.0       1.7898135880745636
                            37                  L-BFGS-B       396.0       1.7898136280593107
                            37                    BFGS         252.0       1.7898135868811282
                            37                trust-constr     960.0       1.7898135869083511
                            38                   COBYLA        289.0       10.238983941422939
                            38                   SLSQP         216.0       10.238994699907447
                            38                   Powell        534.0       10.238973850652153
                            38                nelder-mead      1058.0      10.238973442379468
                            38                  L-BFGS-B       135.0       10.239986315277417
                            38                    BFGS         396.0       10.23897342140297
                            38                trust-constr     405.0       10.238973421446603
                            39                   COBYLA        704.0       18.281166339083896
                            39                   SLSQP         276.0       18.281172707363083
                            39                   Powell        653.0       18.281163008134268
                            39                nelder-mead      2000.0      18.281162945170095
                            39                  L-BFGS-B       165.0       18.28315258333434
                            39                    BFGS         517.0       18.28116175363265
                            39                trust-constr     638.0       18.28116175375586
                            40                   COBYLA        858.0       22.260606435048906
                            40                   SLSQP         398.0        22.2606981682437
                            40                   Powell        737.0       22.260594329663107
                            40                nelder-mead      2200.0      22.260916512172354
                            40                  L-BFGS-B       180.0       22.263680904414326
                            40                    BFGS         564.0       22.260591734938515
                            40                trust-constr     792.0       22.260591735055833
                            41                   COBYLA        832.0       26.272777626725947
                            41                   SLSQP         367.0       26.272774470672505
                            41                   Powell        775.0       26.272777250417114
                            41                nelder-mead      2400.0      26.27279966391945
                            41                  L-BFGS-B       195.0       26.27565351873632
                            41                    BFGS         611.0       26.272766396820437
                            41                trust-constr     949.0       26.27276639696674
                            42                   COBYLA         67.0     1.3779270017854998e-06
                            42                   SLSQP          83.0     1.981125865175874e-06
                            42                   Powell        975.0     9.335632166778367e-22
                            42                nelder-mead      237.0     6.465456843517023e-07
                            42                  L-BFGS-B        72.0     4.181630242250661e-06
                            42                    BFGS         114.0     1.2474610014362838e-12
                            42                trust-constr     102.0     9.301653128175893e-13
                            43                   COBYLA        103.0     5.338633400068714e-07
                            43                   SLSQP         102.0      2.21762195166915e-05
                            43                   Powell        918.0     5.5086057784253994e-21
                            43                nelder-mead      335.0      4.52708455882542e-07
                            43                  L-BFGS-B        91.0     4.4966419744444954e-08
                            43                    BFGS         140.0     2.7029960247429463e-11
                            43                trust-constr     140.0     1.3440415937610982e-12
                            44                   COBYLA        141.0     1.9045502364917844e-06
                            44                   SLSQP         157.0     2.160789669234786e-06
                            44                   Powell        1196.0    3.197963593305558e-21
                            44                nelder-mead      716.0     2.604956216519312e-07
                            44                  L-BFGS-B       117.0     4.253645603685192e-07
                            44                    BFGS         216.0     1.796256672183103e-13
                            44                trust-constr     198.0     2.0894038836280167e-13
                            45                   COBYLA        149.0      0.02029939322581242
                            45                   SLSQP          89.0     1.0351674580358287e-07
                            45                   Powell        252.0     8.959222295130253e-22
                            45                nelder-mead      375.0      4.86780002255299e-05
                            45                  L-BFGS-B        42.0      2.40098232210167e-10
                            45                    BFGS         174.0     5.367397574407069e-10
                            45                trust-constr      78.0     2.454088398353555e-06
                            46                   COBYLA        1000.0<PHONE_NUMBER>474.8965
                            46                   SLSQP          84.0     9.996599730876226e-10
                            46                   Powell        308.0     1.1774403070777338e-20
                            46                nelder-mead      465.0     8.181505338483143e-05
                            46                  L-BFGS-B        66.0     2.7791771145450177e-10
                            46                    BFGS         192.0     5.371130442041379e-10
                            46                trust-constr     114.0     2.9953810604237804e-06
                            47                   COBYLA        206.0      0.031345389476570694
                            47                   SLSQP         156.0     8.602559202539433e-10
                            47                   Powell        402.0     3.5524832063261114e-20
                            47                nelder-mead      853.0     0.00010539806608737956
                            47                  L-BFGS-B        63.0     1.7096060207533679e-09
                            47                    BFGS         405.0     8.552560226301659e-10
                            47                trust-constr      81.0     4.041706874673093e-06
                            48                   COBYLA        268.0      0.018392055570552443
                            48                   SLSQP         139.0     0.0034366694960716385
                            48                   Powell        500.0      8.06006186354541e-20
                            48                nelder-mead      1117.0    0.0002198383834780977
                            48                  L-BFGS-B        88.0     4.803613395887105e-10
                            48                    BFGS         605.0     1.0689500477414616e-09
                            48                trust-constr      99.0     4.5226625522612525e-06
                            49                   COBYLA        369.0      0.03428531323720612
                            49                   SLSQP         304.0     1.719564972450352e-06
                            49                   Powell        600.0     3.022936823467032e-19
                            49                nelder-mead      1411.0    0.00030925186830592474
                            49                  L-BFGS-B       104.0      6.51061604981082e-10
                            49                    BFGS         702.0     1.2850314898252282e-09
                            49                trust-constr     208.0     4.8793043447732755e-06
                            50                   COBYLA        1000.0<PHONE_NUMBER>420.505
                            50                   SLSQP         174.0       16090.611617843075
                            50                   Powell        622.0     2.8815482388462136e-19
                            50                nelder-mead      2400.0       9.64238414027864
                            50                  L-BFGS-B       156.0     1.885568155721845e-09
                            50                    BFGS         831.0     1.2659752664812657e-09
                            50                trust-constr     273.0     4.878639421667073e-06
                            51                   COBYLA        1000.0     0.043713658911804086
                            51                   SLSQP         321.0      0.003924596822050221
                            51                   Powell        5094.0    9.735906314159545e-25
                            51                nelder-mead      1600.0     0.001974655275796391
                            51                  L-BFGS-B       162.0      0.018002244485516704
                            51                    BFGS         540.0     2.530043305286086e-10
                            51                trust-constr     837.0     5.2831275528446416e-08
                            52                   COBYLA        1000.0      1267974.2895068463
                            52                   SLSQP         993.0<PHONE_NUMBER>3164454
                            52                   Powell        6497.0      12.202607453274954
                            52                nelder-mead      1600.0<PHONE_NUMBER>8816407
                            52                  L-BFGS-B       306.0       4.536639532281335
                            52                    BFGS         777.0       4.534879777769612
                            52                trust-constr     432.0       4.544389715643134
              ============================== ============== =========== ========================

Thanks everyone!


Cannot require other packages (phantomjs-node) installed globally

I use the following script to install the kernel to jupyterhub , nodeJS version 4.2.6 , Jupyter 5.1 :
  cd ~
  git clone https://github.com/notablemind/jupyter-nodejs.git
  sudo mv ~/jupyter-nodejs /etc/
  cd /etc/jupyter-nodejs/
  sudo npm install
  sudo npm run build
  sudo npm run build-ext
  cd /etc/jupyter-nodejs/
  sudo node install.js /usr/local/share/jupyter/kernels/nodejs/

Most of the functions works properly, except when I install phantomjs-node, I tried to require the this package in jupyterhub,
require('phantom');

The error message is as following:
Error: Cannot find module 'phantom'
    at Function.Module._resolveFilename (module.js:326:15)
    at Function.Module._load (module.js:277:25)
    at Module.require (module.js:354:17)
    at require (internal/module.js:12:17)
    at /etc/jupyter-nodejs/build/context.js:78:16
    at require (/etc/jupyter-nodejs/build/context.js:58:27)
    at evalmachine.<anonymous>:1:1
    at Object.exports.runInContext (vm.js:44:17)
    at Context.rawRun (/etc/jupyter-nodejs/build/context.js:184:30)
    at Domain.<anonymous> (/etc/jupyter-nodejs/build/context.js:204:27)

(Updated)
I figure out the solution here, modify the kernel.json to include NODE_PATH as env:
{
  "argv": [
    "node",
    "/etc/jupyter-nodejs/build/run.js",
    "{connection_file}"
  ],
  "display_name": "NodeJS 4.3.10",
  "language": "javascript",
  "env":{
    "NODE_PATH" : "/usr/local/lib/node_modules"
  }
}

Yes, I just spent a long time debugging the same issue. Does jupyter-nodejs not by default look for global modules in /usr/lib/node_modules or /usr/local/lib/node_modules?
Further, I'm running it with jupyterhub, and it seems that whoever compiles it wins... meaning it was only looking in MY home directory's node_modules for modules; other users could not load modules from their local node_modules folder.


[Sema] Warn on unsound pointer conversions

In this PR is the logic to emit a warning on unsound array-to-pointer, string-to-pointer, and inout-to-pointer conversions. This is done through the introduction of an underscored attribute @_nonEphemeral which denotes a pointer parameter which cannot accept pointer conversions that are only valid for the duration of the call they're passed to.
This includes all array-to-pointer and string-to-pointer conversions, and most inout-to-pointer conversions with the exception of:

Global and static variables
Stored properties on such variables that are accessed directly (e.g excluding ones with property observers, ones on non-final classes and resilient types in general)
Force unwraps of any of the above

Various pointer parameters in the stdlib have been marked as @_nonEphemeral, primarily pointer parameters for initialisers on pointer types. In addition, this PR infers @_nonEphemeral on pointer parameters for memberwise initialisers and enum case constructors.
Essentially, this is the warning logic of #20070 plus:

The allowing of stored properties on final class global/static vars to be treated as non-ephemeral.
An additional note that suggests that the user use withUnsafe[Mutable][Bytes/Pointer], or for arrays, withUnsafe[Mutable][Bytes/BufferPointer], or for strings, withCString.
The inferring of @_nonEphemeral for enum case constructors.
More tests.

If possible, I'd like to get this into Swift 5, allowing us to transition to an error for Swift 6. I do appreciate how late we are into the release cycle for such a (relatively big) change though.
I'm unsure if this PR requires Swift evolution discussion – I'm happy to start up a thread if it's felt that it does.
Resolves SR-2790.

I'll try to take a look at Sema changes tomorrow.

Sorry for taking so long to get back to this! I have opened an updated PR here: https://github.com/apple/swift/pull/27695.