npm start failed after npm run eject and (Invalid Host header)

My project was build through create-react-app my-app  and i use react-app-rewired to manage a css library. When i want to modify host from 'localhost:3000' to 'localhost.xxxxx.cn:3000'  so that i run npm run eject to find if possible. But afetr that, i can't use npm start(react-app-rewired start) to start my project cause it's turns out an error:
$ npm start

><EMAIL_ADDRESS>start /Users/vermouth_xyy/myworkspace/xyyDevWorkspace/reactProject2018/my-app/antd-demo
> react-app-rewired start

module.js:529
    throw err;
    ^

Error: Cannot find module 'react-scripts/package.json'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.resolve (internal/module.js:18:19)
    at Object.<anonymous> (/Users/vermouth_xyy/myworkspace/xyyDevWorkspace/reactProject2018/my-app/antd-demo/node_modules/react-app-rewired/scripts/utils/paths.js:24:11)
    at Module._compile (module.js:624:30)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)
    at Module.require (module.js:568:17)
    at require (internal/module.js:11:18)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `react-app-rewired start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/vermouth_xyy/.npm/_logs/2018-06-21T05_51_36_070Z-debug.log

my package.json is:
{
  "name": "antd-demo",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "antd": "^3.6.2",
    "apollo-cache-inmemory": "^1.2.5",
    "apollo-client": "^2.3.5",
    "apollo-link-http": "^1.5.4",
    "axios": "^0.18.0",
    "babel-plugin-import": "^1.8.0",
    "graphql": "^0.13.2",
    "graphql-tag": "^2.9.2",
    "react": "^16.4.0",
    "react-apollo": "^2.1.6",
    "react-app-rewire-less": "^2.1.1",
    "react-app-rewired": "^1.5.2",
    "react-dom": "^16.4.0",
    "react-router": "^4.3.1",
    "react-router-dom": "^4.3.1",
    "react-scripts": "1.1.4"
  },
  "proxy": "http://<IP_ADDRESS>:8086",
  "scripts": {
    "start": "react-app-rewired start",
    "build": "react-app-rewired build",
    "test": "react-app-rewired test --env=jsdom",
    "eject": "react-scripts eject"
  }
}

i have fixed this issue by add a new file called  .env.development  in the root of the project contains this:
HOST=mypublicdevhost.com
https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#invalid-host-header-errors-after-configuring-proxy

Once you have run npm run eject all your webpack configuration is in your project's directory (directory name "config" if I remember correctly), and you no longer need react-app-rewired as you can edit it directly. You will also get no more updates to that configuration from create-react-app.
By ejecting, you have just converted your project into a completely stand-alone project.
react-app-rewired is used so that you don't need to eject to make changes, since it is not possible to "uneject". Further, I can normally use npm start and access the server on any valid hostname or IP address for my system without needing to change any server settings (and have other people access it from their machine). You do need to at least have been on react-scripts version 1.0.2 as discussed in this create-react-app issue (the very first google search item).
You did not need to use eject for this.

after npm run eject you need to run npm install

you can check package.json file, 2 files have changes before and after npm eject

Having the same issue, won't work even I do npm i after eject.

React-app-rewired is not needed for an ejected project. It is designed to let you make changes to the configuration without having to eject.

npm install -g react-scripts after that run npm run eject, or you can use npx instead of npm

My issues was having my dependancies in a parent folders package.json. Node parses the directory tree so ensure react-app-rewired is in the child/leaf nodes.
"react-app-rewired": "^2.2.1",
"sass": "^1.54.5"


Bugfix develop makefile

Submisison Checklist

[x] Run tests: ./runCmdStanTests.py src/test
[x] Declare copyright holder and open-source license: see below

Summary:
Windows tests on Jenkins occasionally fail (might be that one Jenkins worker has different settings). Need to debug first and then fix. This is related to https://github.com/stan-dev/cmdstan/pull/890
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):
Rok Češnovar, Univ. of Ljubljana
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

This was a problem with the gelman-group-win-new Windows agent. It had both The Rtools 3.5 and Rtools 4 in PATH. Resolved now so this PR is unnecessary. Sorry everyone for the spam.


scale down RC before deleting

Scale RC to 0 then wait 1 second to allow Kubernetes deleting pods.

👍


720 | Longest Word in Dictionary | C++

Title - C++ code for 720. Longest Word in Dictionary
What will change - Adding C++ code for leetcode problem 720
Type of Issue -
Please add/delete options that are not relevant.

[x] Adding New Code

Programming Language
Please add/delete options that are not relevant.

[x] C++

@SSKale1 Please assign this issue to me.

Please assign this to me


first push GPU version of racon

Hi,
We reused an existing GPU implementation of Racon tool and modified it to suit our needs. We have tested this GPU version against a sample dataset and got considerable speed of about 45%. This effort is a part of Galaxy academic project at Penn State funded by NSF. We are open for feedback and kindly want this be pushed to the main upstream repository.

I am not sure what exactly this PR accomplishes, the majority of files are build files tied to CMake?


test check_imports_sorting , Easy to use

Want to know the answer.
Now,
[src\shared\wtypes.rs:8] In "ctypes::{c_short, c_double, c_ushort, wchar_t};": "c_short" should be after "c_double"

Want,
[src\shared\wtypes.rs:8]
 ×: use ctypes::{c_short, c_double, c_ushort, wchar_t};
 ○: use ctypes::{c_double, c_short, c_ushort, wchar_t};

To copy only and can be corrected.

#410 ...
How do I?
[src\shared\wtypes.rs:8] In "ctypes::{c_short, c_double, c_ushort, wchar_t};": "c_short" should be after "c_double"
[src\shared\wtypes.rs:9] In "shared::minwindef::{BYTE, USHORT, ULONG, WORD, DWORD};": "USHORT" should be after "ULONG"
[src\shared\wtypes.rs:9] In "shared::minwindef::{BYTE, USHORT, ULONG, WORD, DWORD};": "WORD" should be after "DWORD"
[src\um\d2d1_1.rs:11] In "shared::minwindef::{FLOAT, BYTE, DWORD, BOOL};": "FLOAT" should be after "BYTE"
[src\um\d2d1_1.rs:11] In "shared::minwindef::{FLOAT, BYTE, DWORD, BOOL};": "DWORD" should be after "BOOL"
[src\um\d2d1_1.rs:12] In "shared::guiddef::{REFCLSID, CLSID};": "REFCLSID" should be after "CLSID"
[src\um\d2d1_1.rs:14] In "shared::dxgi::{IDXGISurface, IDXGIDevice};": "IDXGISurface" should be after "IDXGIDevice"
[src\um\d2d1_1.rs:16] In "um::winnt::{HRESULT, PWSTR, PCWSTR};": "PWSTR" should be after "PCWSTR"
[src\um\d2d1_1.rs:shared::minwindef::{FLOAT, BYTE, DWORD, BOOL};] "use 11" should be after "use shared::guiddef::{REFCLSID, CLSID};"
[src\um\d2d1_1.rs:shared::guiddef::{REFCLSID, CLSID};] "use 12" should be after "use shared::dxgiformat::DXGI_FORMAT;"
[src\um\d2d1_1.rs:shared::dxgiformat::DXGI_FORMAT;] "use 13" should be after "use shared::dxgi::{IDXGISurface, IDXGIDevice};"
[src\um\d2d1_1.rs:um::winnt::{HRESULT, PWSTR, PCWSTR};] "use 16" should be after "use um::unknwnbase::{IUnknown, IUnknownVtbl};"
[src\um\d2d1_1.rs:um::wincodec::{IWICBitmapSource, IWICColorContext, IWICImagingFactory};] "use 18" should be after "use um::documenttarget::IPrintDocumentPackageTarget;"
[src\um\d2d1_1.rs:um::documenttarget::IPrintDocumentPackageTarget;] "use 19" should be after "use um::dcommon::{D2D1_PIXEL_FORMAT, DWRITE_MEASURING_MODE};"
[src\um\d2d1_1.rs:um::dwrite::{DWRITE_GLYPH_RUN, DWRITE_GLYPH_RUN_DESCRIPTION, IDWriteRenderingParams};] "use 21" should be after "use um::d2dbasetypes::D2D_SIZE_F;"
[src\um\d2d1_1.rs:um::d2dbasetypes::D2D_SIZE_F;] "use 22" should be after "use um::d2d1::{"
[src\um\documenttarget.rs:shared::ntdef::HRESULT;] "use 11" should be after "use shared::guiddef::{GUID, REFGUID, REFIID};"
[src\um\ocidl.rs:10] In "shared::minwindef::{ULONG, DWORD};": "ULONG" should be after "DWORD"
[src\um\ocidl.rs:11] In "shared::wtypesbase::{LPOLESTR, LPCOLESTR};": "LPOLESTR" should be after "LPCOLESTR"
[src\um\ocidl.rs:12] In "shared::wtypes::{VARTYPE, CLIPFORMAT};": "VARTYPE" should be after "CLIPFORMAT"
[src\um\ocidl.rs:16] In "um::oaidl::{VARIANT, IErrorLog};": "VARIANT" should be after "IErrorLog"
[src\um\ocidl.rs:shared::wtypesbase::{LPOLESTR, LPCOLESTR};] "use 11" should be after "use shared::wtypes::{VARTYPE, CLIPFORMAT};"
[src\um\ocidl.rs:shared::wtypes::{VARTYPE, CLIPFORMAT};] "use 12" should be after "use shared::ntdef::HRESULT;"
[src\um\ocidl.rs:shared::ntdef::HRESULT;] "use 13" should be after "use shared::guiddef::CLSID;"
[src\um\ocidl.rs:um::unknwnbase::{IUnknown, IUnknownVtbl};] "use 15" should be after "use um::oaidl::{VARIANT, IErrorLog};"
[src\um\wincodec.rs:11] In "shared::minwindef::{DWORD, UINT, INT, BOOL, FLOAT, BYTE, ULONG, LPVOID};": "UINT" should be after "INT"
[src\um\wincodec.rs:11] In "shared::minwindef::{DWORD, UINT, INT, BOOL, FLOAT, BYTE, ULONG, LPVOID};": "INT" should be after "BOOL"
[src\um\wincodec.rs:11] In "shared::minwindef::{DWORD, UINT, INT, BOOL, FLOAT, BYTE, ULONG, LPVOID};": "FLOAT" should be after "BYTE"
[src\um\wincodec.rs:11] In "shared::minwindef::{DWORD, UINT, INT, BOOL, FLOAT, BYTE, ULONG, LPVOID};": "ULONG" should be after "LPVOID"
[src\um\wincodec.rs:12] In "shared::windef::{HBITMAP, HPALETTE, HICON};": "HPALETTE" should be after "HICON"
[src\um\wincodec.rs:18] In "shared::guiddef::{REFGUID, GUID, CLSID, REFCLSID};": "REFGUID" should be after "GUID"
[src\um\wincodec.rs:18] In "shared::guiddef::{REFGUID, GUID, CLSID, REFCLSID};": "GUID" should be after "CLSID"
[src\um\wincodec.rs:26] In "um::objidlbase::{IStream, IStreamVtbl, IEnumString, IEnumUnknown};": "IStreamVtbl" should be after "IEnumString"
[src\um\wincodec.rs:shared::winerror::{] "use 13" should be after "use shared::ntdef::{LPCWSTR, LPWSTR, PCWSTR, WCHAR};"
[src\um\wincodec.rs:shared::ntdef::{LPCWSTR, LPWSTR, PCWSTR, WCHAR};] "use 17" should be after "use shared::guiddef::{REFGUID, GUID, CLSID, REFCLSID};"
[src\um\wincodec.rs:shared::guiddef::{REFGUID, GUID, CLSID, REFCLSID};] "use 18" should be after "use shared::dxgiformat::DXGI_FORMAT;"
[src\um\wincodec.rs:um::winnt::{HANDLE, ULARGE_INTEGER};] "use 24" should be after "use um::propidl::PROPVARIANT;"
[src\um\wincodec.rs:um::propidl::PROPVARIANT;] "use 25" should be after "use um::objidlbase::{IStream, IStreamVtbl, IEnumString, IEnumUnknown};"
[src\um\wincodec.rs:um::ocidl::IPropertyBag2;] "use 27" should be after "use um::dcommon::D2D1_PIXEL_FORMAT;"
[src\um\wincodec.rs:um::unknwnbase::{IUnknown, IUnknownVtbl};] "use 29" should be after "use um::d2d1::ID2D1Image;"

cc @GuillaumeGomez who wrote the test and is therefore responsible for improving the diagnostics.


Command pop-up missing selection highlight

Was messing around with the theme and noticed the pop-up for file search/commands is missing the highlighting, so it is almost impossible to know which option is selected.

fixed in v1.2.1, thanks


Clarify installation requirement

See https://github.com/dotansimha/graphql-code-generator/issues/5450

Thanks @JanCVanB !


Cluster configuration management system

Some configuration settings should be the same for every node in a federation, e.g.

the list of nodes, each of which has a:

public key
BigchainDB hostname or IP address
RethinkDB hostname or IP address
human-readable name, e.g. "Ipwitch Associates Inc."

other federation-level settings? One possibility is the block timeout value.

It should be impossible for nodes to disagree on these settings, i.e. there needs to be some way for them to propose changes, vote on them, and use new values once they've gotten a quorum of votes. There must be distributed consensus on all these settings.
See the discussion on these related, more specific issues:

Managing the "current keyring" in the federation #187
Proposal: Make block timeout value configurable #427

Today we had a meeting to discuss this and we concluded that the existing system (where the keyring is read from the configuration settings at launch and is then stored in memory) is probably good enough. We just need some better documentation and a way to do a clean shutdown. I will:

close this issue
close the related issue #187 (on managing the current keyring)
write some documentation about cluster startup and adding/removing nodes
create a new issue about a need for a clean shutdown (if an issue like that doesn't exist already)


How to use CodyHouse with Nuxt?

I searched for nuxt in the issues section and did not find anything
the documentation also covers only gulp webpack and manual install
how do I install CodyHouse base in nuxt
Would be awesome if you can add a section in the guide for the same
Fantastic work team, cheers

Hi there! We do not have a doc section for nuxt yet. We're looking into it and see if we can add a new section soon.
Meanwhile, here's an article covering how to import the framework and components in Vue:
https://codyhouse.co/blog/post/using-the-codyhouse-components-with-vue-js
This should help you with nuxt as well.
In the Install the CodyHouse Framework section, you can find how to import the base into your custom scss file. You can then compile the custom scss file in style.css as you would typically do using your nuxt.config.js file.
Hope this helps!

Hi Claudia!
First I would like to thank your team for the awesome framework, it made it to so easy to work!
I purchased a Pro version a week ago!
Now I'm looking for a documentation on how to integrated to a NuxtJS project!

Hi Hamza,
great to hear that!
We didn't schedule a NuxtJS doc section yet. We do have an article on how to import the framework and components in Vue:
https://codyhouse.co/blog/post/using-the-codyhouse-components-with-vue-js
Are there any steps missing in that guide that you think we should cover? Thank you.

@HamzaPlus, I am currently using CodyHouse CSS framework in a Nuxt.js project: https://www.acousticarium.com
However I am excluding the CH JS files because Vue is doing the task. It works fine but I am having this issue purging the CSS.

I'm closing this issues as everything seems to be working with PurgeCSS as well. Feel free to reopen it if there are still problems. Chers!

@slidenerd I've implemented CodyHouse with Nuxt. The trick is is making breakpoint.scss and mixins.scss a Nuxt resource. I recorded tutorials on this https://www.youtube.com/watch?v=ufMByFlIWck
@claudia-romano Feel free to share this video with anyone who needs it.
@retroriff Nice work on that website!

Hi Ryan, thanks for that! We have included it in our Docs section:
https://codyhouse.co/ds/docs/framework#nuxt


Bug: Link to headings not working

Headings still have their id attribute applied correctly via the customHTMLRenderer from baseOptions.js, however linking to these headings is not as simple after the recent update introducing support for running flatnotes in a subpath.
Before, I was able to link to a heading in the same document with this code:
[Link to Heading](#heading-name)

However after the update this redirects me to http://example.com:8080/#heading-name, instead of the old funtional http://example.com:8080/note/ExampleNote/#heading-name. If I used instead something like:
[Link to Heading](/note/ExampleNote#heading-name)

Then it would work correctly, but it's quite ugly and requires a lot of repetition. I also tried using WikiLinks like so:
[[ExampleNote#heading-name]]

But this redirects me to http://example.com:8080/note/ExampleNote%23heading-name.
A fix could be to change the behavior of links when they start with a # character, so for instance [Link to Heading](#heading-name) always prepends the note's path to the redirecting URL. Otherwise it could be convenient to stop converting characters into URL-compatible characters when using WikiLinks, like in the example above where # becomes %23. This could be seen as an extension of WikiLinks, allowing you to not only link to another note but also a specific section of that note.
I'm not sure how these changes would fare with an application running on a subpath.

Ah. I made sure to cover all relative paths in the application but hadn't considered that there might be relative paths in the content!
I'll take a look to see if I can intercept the rendering of hyperlinks and use Vue Router to set the href value to an absolute path (which would take path prefixes into account).

@pbogre - The develop branch now has a resolution for this. [Link to Heading](#heading-name) should now resolve as expected. I've pushed a build to Docker Hub, so please give the :develop tag a go if you can.

Thanks for looking into this! I'll check out the develop branch as soon as I can.

Just tested it, can confirm it's working! Thanks again.


Add MalwareBazaar as a default file source

Add MalwareBazaar as a default file source.

Thanks for the contribution! 😁


Consider moving list of old admissions to admission_admin

We should  consider moving the list of old admissions out of the /opptak page and under admission_admin as that's really where it belongs. This should maybe be a separate controller, and we could provide a link to it in the admissions admin applet.
This way we can avoid mixing admin/non-admin things on the /opptak page.

Relevant PR: #713


Redistribute symbols for native providers

For diagnosing native memory issues it would be helpful to have the debug symbols.
e.g. for MKL:

libiomp5md.pdb
MathNet.Numerics.MKL.pdb

Maybe as separate download.

The latter is available in the Zip file distribution (release archive). The former we don't build ourselves, need to check whether we have symbol files for that one.

Thats exactly what I wanted.
Thanks

maybe README.md should point to http://1drv.ms/1NlUeDT instead of Codeplex.
Then I would have found it myself.
PS: libiomp5md.pdb is in the redist folder of Intel Parallel Studio XE nearby the dll

It is linked from the website at NuGet & Binaries. The Codeplex link will be dropped entirely soon as I've finally found a replacement for the old Codeplex discussion board.


RISCv32 qemu configuration does not work with upstream qemu

Tried latest qemu and no luck running Zephyr applications with the latest version from master.
@nategraff-sifive any hints?

Latest QEMU has different machines than the QEMU in Zephyr SDK. You'll want to build with "-DBOARD=hifive1" and then run QEMU with the argument "-machine sifive_e".
We should point the qemu_riscv32 board at the riscv32_fe310.dtsi since the "sifive_e" target is equivalent to an SiFive FE310, the same as on the HiFive1.

@nategraff-sifive thanks, that works, I am getting a few issues on riscv32 now though, not sure what is going on, can you reproduce those on the actual hifive1 board?
See https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/22802/3/tests

@nategraff-sifive note that the above is using a pre-release of the SDK, so you might want to download that version of the SDK to reproduce or using a recent qemu.
https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.4-rc3

@nashif I'll take a look 👍

@nategraff-sifive any update?

@nashif Sorry, not yet. I had some other tasks take priority. I should have some time to dive into this within the next few days.

@nashif Are any RISC-V targets part of the standard sanitycheck that gets run on PRs? I went back to establish a baseline and ran ./scripts/sanitycheck -p qemu_riscv32 using SDK 0.9.3 on the v1.12.0 and v1.13.0 tags and I saw failures in both cases in:

tests/kernel/timer/timer_api/kernel.timer
tests/kernel/timer/timer_monotonic/kernel.timer

Those are two of the tests that are failing with SDK 0.9.4-rc3, so there's also a subset of the regressions that have just been broken for a while.

qemu_riscv32 is a default platform and all tests run on this board for every commit. I guess what you are seeing is a sporadic behaviour with current qemu that stops being sporadic in the new qemu. usually if you re-run the tests again the test will pass (with sanitycheck --only-failed)

Quick update: I just tested the new_qemu branch against the downstream riscv-qemu and a number of tests are still failing. Notably, with downstream QEMU the tests are crashing QEMU, as opposed to the tests assertions failing in upstream. It remains to be seen which of the two failures is preferable.

@nashif
So the QEMU sifive_e target doesn't quite exactly match the FE310-G000 SoC on the HiFive 1. One of the discrepancies is that the machine timer driving Zephyr's sys_clock runs at 32768 Hz on the FE310, while in QEMU it runs at the same speed as the CPU, 10 MHz. The result is that tests fail all over the place because they depend on the system clock to be running at the right frequency.
If you set SYS_CLOCK_HW_CYCLES_PER_SEC=10000000 for the HiFive 1, then sanitycheck passes.
This doesn't resolve the actual hardware failure for the tests/kernel/workq/work_queue test.
I think the proper resolution is the following steps:

Bring back the qemu_riscv32 target as a hifive1 clone with this configuration change
File a bug with QEMU that the machine timer frequency in the sifive_e target differers from the FE310-G000 SoC it's emulating
Since the work queue bug doesn't affect QEMU or sanitycheck, continue ahead with SDK 0.9.4 and file a bug with the Zephyr project that work queue tests fail on the actual HiFive 1 board so I can track that down without blocking here anymore.

Thoughts?

@galak Doing a quick glance over the source, it looks like modifying SIFIVE_CLINT_TIMEBASE_FREQ in include/hw/riscv/sifive_clint.h might just do the trick. Let me try that and see what happens.

Bring back the qemu_riscv32 target as a hifive1 clone with this configuration change

meanwhile I have been testing with the above option and it works fine

see #10136

@nashif Awesome!
@galak So I made the change I just suggested and ran sanitycheck on the hifive1 target. Oddly enough, there's exactly one test failing and it's tests/kernel/mem_pool/mem_pool_api/kernel.memory_pool causing QEMU to jump to 0x00000008, where it subsequently crashes. Not sure yet what's going on, but I'll keep looking.


Pyspice

Motivation for this change
Adds PySpice. I tested this on some of the examples in the doc and everything worked.
Things done

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

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

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

pyyaml and requests bumps need to be tested with a hydra job, so this PR is going to take some time.

pyyaml and requests are now in staging. Probably land in master in a week or so.

Great, thanks for the update. I've also implemented the change. Let me know if any issues.

commit message should be:
python3Packages.pyspice: init at 1.4.2

Done.

@FRidh any chance of an update on this? Thanks!


Exception running create and help commands

Running the latest version of flatiron (0.1.4), the create command throws the following exception in node 0.6.2
"TypeError: Cannot call method 'concat' of undefined",
"    at Object. (/usr/local/lib/node_modules/flatiron/lib/flatiron/plugins/cli.js:197:46)",
"    at apply (/usr/local/lib/node_modules/flatiron/node_modules/director/lib/director/router.js:356:19)",
"    at _every (/usr/local/lib/node_modules/flatiron/node_modules/director/lib/director/router.js:28:9)",
"    at [object Object].invoke (/usr/local/lib/node_modules/flatiron/node_modules/director/lib/director/router.js
Running help command throws:
"TypeError: Object [object Object] has no method 'help'",
"    at /usr/local/lib/node_modules/flatiron/lib/flatiron/plugins/cli.js:110:15",
"    at Array.forEach (native)",
"    at showUsage (/usr/local/lib/node_modules/flatiron/lib/flatiron/plugins/cli.js:109:12)",
"    at loadCommand (/usr/local/lib/node_modules/flatiron/lib/flatiron/plugins/cli.js:143:18)",
"    at Object. (/usr/local/lib/node_modules/flatiron/lib/flatiron/plugins/cli.js:194:18)",
"    at apply (/usr/local/lib/node_modules/flatiron/node_modules/director/lib/director/router.js:356:19)",
"    at _every (/usr/local/lib/node_modules/flatiron/node_modules/director/lib/director/router.js:28:9)",

Thanks. I'll look into this tonight.

I'm getting the same. Thanks for being on top of things @indexzero!

I just pulled down the latest and this looks fixed now.


Remove deprecated numpy types like np.str, np.int, np.complex, etc.

The deprecation of these types expired in numpy 1.24. Fixing this is necessary for me to fix hera_cal.


OnNodesChange is triggered when the component is initialized

Describe the Bug
I think the onNodesChange event is triggered only when the nodes or edges change as stated in the documentation.

However, it puzzled me that it is triggered immediately when the component is initialized.
Your Example Website or App
https://codesandbox.io/s/react-flow-onnodeschange-hxg0z0
Steps to Reproduce the Bug or Issue

Open the link below
Check the console

Expected behavior
OnNodesChange should be triggered when change occurs.
Screenshots or Videos
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context
No response

Good point! I will add a note to the docs. In this case the nodes get initialized. After the mount, React Flow measures them and notifies the onNodesChange handler about the width and height.


New hasMany API

Much idea similar here. Like to implement. Need to test feasibility first. Snippet below.
import { hasMany } from 'ember-data/relationships';
import Model from 'ember-data/model';
import attr from 'ember-data/attr';

export default Model.extend({
  age: attr('number'),
  username: attr('string'),
  friends: hasMany('user', {
    filter(reference, record) {
      return reference.where('age', '>=', record.get('age')).limit(10);
    }
  }),
});

Here's how to change the relationship option dynamically for use-cases such as changing filter hook to increase the limit for infinite scrolling/pagination.
Disclaimer: I'm not sure if changing the relationship option has any drawbacks in Ember Data. I assume that there's none as long as you don't change built-in options such as async, inverse, etc..
const user = await this.store.findRecord('user', 'user_a');
const friends = await user.get('friends');
const newLimit = 20;

friends.relationship.relationshipMeta.options.filter = (reference, record) => {
  return reference.where('age', '>=', record.get('age')).limit(newLimit);
};
friends.reload();

Implemented in #20


[QUESTION]How to import excel file from network(http)

Please prefix your issue with one of the following: [BUG] [PROPOSAL] [QUESTION].
Package version, Laravel version
Laravel 5.2
Expected behaviour
Actual behaviour
    $this->excel->load($disk->downloadUrl('example2016.xls'), function($reader) {
        // reader methods
        $result  = $reader->toArray();
        dd($result);
    },'UTF-8',true);

Exception stack trace
PHPExcel_Reader_Exception in Excel5.php line 443:
Could not open http://o7vsd12rl.bkt.clouddn.com/example2016.xls for reading! File does not exist.
Screenshot of Excel file
http://o7vsd12rl.bkt.clouddn.com/example2016.xls
Steps to reproduce the behaviour

I'm also having this problem trying to import a file from S3. S3 returns the file content - if you pass the content directly to Laravel Excel it cannot parse it. The only way I can see around is the download the file, save it to the local filesystem, then load that file into Laravel Excel, then delete the file. If anyone knows of a better way to just pass Laravel Excel file content?

That's not supported by the parent package. Nothing we can do about it. Only thing you can do is what @samiles suggests.


fixed typo

my meshMetering -> by meshMetering

Closing because someone changed the area and also fixed the problem parallely.


The import is not working

Generates incorrect import code when
version: v1
plugins:
  - plugin: es
    opt: target=ts
    out: src/protobuf

Error: Cannot find module './packet_pb.js'
// packet9999_pb.ts:

import type { GenDescFile, GenDescMessage } from "@bufbuild/protobuf/codegenv1";
import { fileDesc, messageDesc } from "@bufbuild/protobuf/codegenv1";
import type { Packet } from "./packet_pb.js";
import { fileDesc_packet } from "./packet_pb.js";
import type { Message } from "@bufbuild/protobuf";

import "packet.proto";

message Packet9999 {
	required int32 packet_id = 1;
	required MSG1 val = 2;
// ...
}

It could be because of the .js extension. We generate .js as described in the ECMAScript spec. But bundlers haven't yet implemented it. You can use the import_extension option to remove the extension:
version: v1
plugins:
  - plugin: es
    opt: target=ts,import_extension=none
    out: src/protobuf

If the import is coming from a buf module dependency, then you may need to run use the --include-imports flag

@srikrsna-buf this is exactly it for me. the files generate as '.ts' but the import path resolves to '.js'. your fix worked - thanks!


doc: fix nixos-rebuild

Description of changes
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

I've split it out in 2 commits. Feel free to merge when the tests ran satisfactorily.
(happy to merge as well if you would rather not).

@pennae btw, I'm grateful that you made the change you did. nixpkgs needs more love, and not so many people want to undertake more involved changes.
Thanks again!

for other people coming here, there is one more reference in one of home-manager's dependency
https://git.sr.ht/~rycee/nmd/tree/master/item/lib/manual-docbook.nix#L37
this will likely take a couple of days to get fixed.

Was this change time critical in any way justifying a (self-)merge after not even fifteen minutes?

@piegamesde thanks for coming by!
The change was small and it was something that was forgotten in the original PR causing breakage. I didnt see much harm here.
(I came to the original PR not being able to switch to the latest nixpkgs, so i thought it did warrant fast action)
What do you suggest in the future ?

Personally, I'd like to have all pull requests open for at least 24 hours (with an exception for security relevant ones and maybe quick-reverts), and if it was technically possible I would even like to enforce that. Most of the time waiting a couple of extra hours does is not that bad, especially given since channels have a similar delay already.


tests, network, vmi_networking: Combine redundant tests of VMIs without network

What this PR does
Before this PR:
There were 2 tests that created an Alpine VMI without networking and AutoattachPodInterface=false. One of which counted the number of interfaces in the guest and the other one just waited for the VMI to launch
After this PR:
Improve the more detailed test and delete the redundant one

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

/retest

When triggering a retest, please provide a convincing reasoning on why the network jobs failure is unrelated.


Typo in legacy Build a Personal Portfolio Webpage, test 2 and 5

Describe the Issue
I'm not certain that legacy courses are still being up kept, but the 2nd and 5th tests have typos in their text.
Second test:

Your #welcom-section element should contain an h1 element.

"welcom-section" should be "welcome-section"
Fifth test:

Your portfolio should contain at least one elment with a class of project-tile.

"one elment" should be "one element"
Affected Page
https://www.freecodecamp.org/learn/responsive-web-design/responsive-web-design-projects/build-a-personal-portfolio-webpage
Steps to Reproduce
Go to link, and scroll down to the tests.
Recommended fix or suggestions
Just correcting the test text.
Screenshots
No response

Thanks for opening this issue.
This looks something that can be fixed by "first time" code contributors to this repository. Here are the files that you should be looking at to work on a fix:
List of files:

https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/english/01-responsive-web-design/responsive-web-design-projects/build-a-personal-portfolio-webpage.md

Please make sure you read our guidelines for contributing, we prioritize contributors following the instructions in our guides. Join us in our chat room or the forum if you need help contributing, our moderators will guide you through this.
Sometimes we may get more than one pull requests. We typically accept the most quality contribution followed by the one that is made first.
Happy contributing.


UI: Fix the snapshot reverting message

When a volume is attached and frontend enabled (e.g. not in the maintenance mode), the revert wouldn't be allowed. UI should prompt the user: Cannot revert with frontend enabled. Please reattach the volume in maintenance mode to revert the volume. Workload shutdown might be needed.
Now it prompts: "Volume may not be mounted on the host when reverting, otherwise it may cause filesystem error."

Validation: PASSED
Steps to test:

Create a volume, attach it to a node
Create snapshot
in volume details page, click on the snapshot

Expected result: Revert button is disabled & a tool tip contains the message Cannot revert with frontend enabled. Please reattach the volume in maintenance mode to revert the volume. Workload shutdown might be needed is displayed when hover on the button.  (PASS)


Nginx idr caching config

Moves the IDR caching config from roles/nginx-proxy/vars/example-omero.yml to `idr-playbooks/group_vars/proxy-hosts.yml.
Originally the vars were stored in the role so that they could be public whilst the remaining IDR config was private, but following a refactoring nearly all of the IDR config is in public group-vars.
To test this Vagrant (vagrant up idr-database idr-omero idr-gateway) you will need https://github.com/openmicroscopy/infrastructure/pull/152

I think this needs a bug fix discovered by Ola.

On second thoughts the bug in the caching config already existed, so I think it's easier to look at this PR purely as moving variables from one file to another, otherwise there are merge conflicts since the bug fix commit comes after other new additions to file.

if cache is fixed https://github.com/openmicroscopy/infrastructure/pull/159/files#diff-2f8f0d61b08d12fe59795d928cfd272cR33 do we need this PR?

#159 is basically my "merge" branch. The intention is to split it out into separate PRs for review and rebase as they're merged.

No vetoes.


cannot yank (copy) multi-byte characters (Chinese)

你好，中国

A yank of Chinese text above, would then pasted (in application other than VS Code) as
‰Ω†Â•ΩÔºå‰∏≠ÂõΩ

Note that, neovim itself can yank it correctly.
Extension version: 0.0.50
Neovim version: 0.4.3
nvim --version
NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5

i guess something wrong with buffer encoding

any solution now?

@Jackiexiao Can you provide a reproduction step? Everything seems to be working fine on my end.

@Jackiexiao Can you provide a reproduction step? Everything seems to be working fine on my end.
@xiyaowong

yy to copy 你好 in vscode (macOS), then paste it in other application, you can see ‰Ω†Â•Ω

try add
vim.opt.encoding = "utf-8"
vim.opt.fileencoding = "utf-8"

to init.lua

I guess add set encoding=utf-8 to ~/.config/nvim/init.vim achieve the same result? but it doesn't work

@Jackiexiao Please try let g:clipboard = g:vscode_clipboard in vscode-neovim v1.3.0+

it works!! thx!! @xiyaowong


Add support for Fts auto Complete and docs + tests

Add support for FTS auto complete
Add support for Documentation hover
Add support for FTS auto complete templates
Updated and added unit tests

Formatted using prettier, Also updated changelog to include from v2.0.1->v2.0.5


1.37 releases

⚛👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.

Copy the correct template for your contribution

🐛 Are you fixing a bug? Copy the template from https://bit.ly/atom-bugfix
📈 Are you improving performance? Copy the template from https://bit.ly/atom-perf
📝 Are you updating documentation? Copy the template from https://bit.ly/atom-docs
💻 Are you changing functionality? Copy the template from https://bit.ly/atom-behavior

Replace this text with the contents of the template
Fill in all sections of the template
Click "Create pull request"

Updated
On Fri, May 3, 2019 at 11:16 AM AvionzGij<EMAIL_ADDRESS>wrote:

⚛👋 Hello there! Welcome. Please follow the steps below to tell us about
your contribution.

Copy the correct template for your contribution

🐛 Are you fixing a bug? Copy the template from
https://bit.ly/atom-bugfix
📈 Are you improving performance? Copy the template from
https://bit.ly/atom-perf
📝 Are you updating documentation? Copy the template from
https://bit.ly/atom-docs
💻 Are you changing functionality? Copy the template from
https://bit.ly/atom-behavior

Replace this text with the contents of the template
Fill in all sections of the template
Click "Create pull request"

You can view, comment on, or merge this pull request online at:
https://github.com/atom/atom/pull/19256
Commit Summary

1.37.0-beta0
Merge pull request #19130 from
atom/fuzzy-finder-1.13.0-targeting-master
Bump fuzzy-finder version in package-lock.json
Merge pull request #19136 from atom/aw/open-file-regression
1.37.0-beta1
:arrow_up<EMAIL_ADDRESS>to fix atom/fuzzy-finder#380
regression
Merge pull request #19169 from atom/aw/launch-it
Merge pull request #19200 from atom/aw/electron-link-up
Merge pull request #19203 from atom/aw/reopen-projects
:shirt: format atom-application.test.js
Merge pull request #19207 from atom/aw/versioned-application-state

File Changes

M package-lock.json
https://github.com/atom/atom/pull/19256/files#diff-0 (6)
M package.json
https://github.com/atom/atom/pull/19256/files#diff-1 (6)
M script/package-lock.json
https://github.com/atom/atom/pull/19256/files#diff-2 (69)
M script/package.json
https://github.com/atom/atom/pull/19256/files#diff-3 (2)
M spec/atom-environment-spec.js
https://github.com/atom/atom/pull/19256/files#diff-4 (104)
M spec/main-process/atom-application.test.js
https://github.com/atom/atom/pull/19256/files#diff-5 (2308)
A spec/main-process/atom-window.test.js
https://github.com/atom/atom/pull/19256/files#diff-6 (424)
M src/application-delegate.js
https://github.com/atom/atom/pull/19256/files#diff-7 (4)
M src/atom-environment.js
https://github.com/atom/atom/pull/19256/files#diff-8 (32)
M src/core-uri-handlers.js
https://github.com/atom/atom/pull/19256/files#diff-9 (13)
M src/ipc-helpers.js
https://github.com/atom/atom/pull/19256/files#diff-10 (4)
M src/main-process/atom-application.js
https://github.com/atom/atom/pull/19256/files#diff-11 (354)
M src/main-process/atom-window.js
https://github.com/atom/atom/pull/19256/files#diff-12 (66)
M src/register-default-commands.coffee
https://github.com/atom/atom/pull/19256/files#diff-13 (6)

Patch Links:

https://github.com/atom/atom/pull/19256.patch
https://github.com/atom/atom/pull/19256.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/pull/19256, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAKRPO2FKF5FNELCIBVTTTPTP7FBANCNFSM4HKSLTPA
.

Updated
On Fri, May 3, 2019 at 11:16 AM AvionzGij<EMAIL_ADDRESS>wrote:

⚛👋 Hello there! Welcome. Please follow the steps below to tell us about
your contribution.

Copy the correct template for your contribution

🐛 Are you fixing a bug? Copy the template from
https://bit.ly/atom-bugfix
📈 Are you improving performance? Copy the template from
https://bit.ly/atom-perf
📝 Are you updating documentation? Copy the template from
https://bit.ly/atom-docs
💻 Are you changing functionality? Copy the template from
https://bit.ly/atom-behavior

Replace this text with the contents of the template
Fill in all sections of the template
Click "Create pull request"

You can view, comment on, or merge this pull request online at:
https://github.com/atom/atom/pull/19256
Commit Summary

1.37.0-beta0
Merge pull request #19130 from
atom/fuzzy-finder-1.13.0-targeting-master
Bump fuzzy-finder version in package-lock.json
Merge pull request #19136 from atom/aw/open-file-regression
1.37.0-beta1
:arrow_up<EMAIL_ADDRESS>to fix atom/fuzzy-finder#380
regression
Merge pull request #19169 from atom/aw/launch-it
Merge pull request #19200 from atom/aw/electron-link-up
Merge pull request #19203 from atom/aw/reopen-projects
:shirt: format atom-application.test.js
Merge pull request #19207 from atom/aw/versioned-application-state

File Changes

M package-lock.json
https://github.com/atom/atom/pull/19256/files#diff-0 (6)
M package.json
https://github.com/atom/atom/pull/19256/files#diff-1 (6)
M script/package-lock.json
https://github.com/atom/atom/pull/19256/files#diff-2 (69)
M script/package.json
https://github.com/atom/atom/pull/19256/files#diff-3 (2)
M spec/atom-environment-spec.js
https://github.com/atom/atom/pull/19256/files#diff-4 (104)
M spec/main-process/atom-application.test.js
https://github.com/atom/atom/pull/19256/files#diff-5 (2308)
A spec/main-process/atom-window.test.js
https://github.com/atom/atom/pull/19256/files#diff-6 (424)
M src/application-delegate.js
https://github.com/atom/atom/pull/19256/files#diff-7 (4)
M src/atom-environment.js
https://github.com/atom/atom/pull/19256/files#diff-8 (32)
M src/core-uri-handlers.js
https://github.com/atom/atom/pull/19256/files#diff-9 (13)
M src/ipc-helpers.js
https://github.com/atom/atom/pull/19256/files#diff-10 (4)
M src/main-process/atom-application.js
https://github.com/atom/atom/pull/19256/files#diff-11 (354)
M src/main-process/atom-window.js
https://github.com/atom/atom/pull/19256/files#diff-12 (66)
M src/register-default-commands.coffee
https://github.com/atom/atom/pull/19256/files#diff-13 (6)

Patch Links:

https://github.com/atom/atom/pull/19256.patch
https://github.com/atom/atom/pull/19256.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/pull/19256, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAKRPO2FKF5FNELCIBVTTTPTP7FBANCNFSM4HKSLTPA
.


Syntax highlighting for code snippets

https://mdxjs.com/guides/syntax-highlighting

Added with 6341cb8. Pages with syntax highlighting to be published.


Update renovatebot/github-action action to v34.132.1

This PR contains the following updates:

Package
Type
Update
Change

renovatebot/github-action
action
patch
v34.132.0 -> v34.132.1

Release Notes

renovatebot/github-action
v34.132.1
Compare Source
See the the changelog for changes in all releases.
34.132.1 (2023-02-12)
Bug Fixes

deps: update renovate/renovate docker tag to v34.132.1 (5f40203)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Branch automerge failure
This PR was configured for branch automerge. However, this is not possible, so it has been raised as a PR instead.


Suggest: add 'blank' vue.config.js file with comment/link to documentation about extending webpack

What problem does this feature solve?
As a new cli user, a first impression after creating a new project with vue cli is the missing webpack config. A glance at the docs can clear this up, but I'd advocate for creating a default vue.config (or webpack file?) with a comment explaining why a webpack config file isn't there, what a vue.config file is, etc.
What does the proposed API look like?
Something like commented out examples of the general settings seen in the Vue UI, link to dos about extending vue config, etc.

Well we already generate a README.md file, I think that would be a good place to include some links to the docs. :+1:
I don't think that rendering some empty config files with a link would offer any better experience then that. I also would not want these comments to go much further than linking to the docs, I feel like this is already too much:

with a comment explaining why a webpack config file isn't there, what a vue.config file is, etc.

All of that is covered in the docs, so I don't feel like it's a good idea to add a "documentation light" to any config file within the project. A Link to the docs should suffice. People unwilling to read docs are on their own as far as my personal opinion is concerned.

@easherma Actually that's the right place. Feel free to go ahead.


[Relay][Topi][CPU] Dense with weight transform

This PR adds weight transformed dense to avoid weight layout conversion. With this PR, current dense pack template can achieve 2x performance on CPU targets.
@icemelon9

@icemelon9 PTAL

Thanks @kevinthesun


Update qq to 5.2.0

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Update qq to 5.2.0

It seems that the download url does not accept https.

It works in China...
➜  ~ curl -I https://dldir1.qq.com/qqfile/QQforMac/QQ_V5.2.0.dmg
HTTP/1.1 200 OK
Server: nnws/<IP_ADDRESS>
Date: Fri, 21 Oct 2016 16:00:33 GMT
Content-Type: application/octet-stream
Content-Length: 33240461
Connection: keep-alive
Cache-Control: max-age=600
Expires: Fri, 21 Oct 2016 16:10:33 GMT
Last-Modified: Fri, 21 Oct 2016 08:47:02 GMT
X-Cache-Lookup: Hit From Disktank

Weird...
-bash-4.4.0- /Users/$USER [> curl -I https://dldir1.qq.com/qqfile/QQforMac/QQ_V5.2.0.dmg
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

-bash-4.4.0- /Users/$USER [> curl -I --insecure https://dldir1.qq.com/qqfile/QQforMac/QQ_V5.2.0.dmg
HTTP/1.1 403 Forbidden
Date: Fri, 21 Oct 2016 16:09:19 GMT
Server: PWS/<IP_ADDRESS>
Connection: close

-bash-4.4.0- /Users/$USER [> curl -I http://dldir1.qq.com/qqfile/QQforMac/QQ_V5.2.0.dmg
HTTP/1.1 200 OK
Date: Fri, 21 Oct 2016 16:07:28 GMT
Server: PWS/<IP_ADDRESS>
X-Px: rf-ht h0-s33.p3-syd ( h0-s40.p3-syd), ht h0-s40.p3-syd.cdngp.net
Cache-Control: max-age=600
Expires: Fri, 21 Oct 2016 16:07:41 GMT
Age: 587
Accept-Ranges: bytes
Content-Length: 33240461
Content-Type: application/octet-stream
Last-Modified: Fri, 21 Oct 2016 08:47:02 GMT
Connection: keep-alive

Thank you for the contribution. It needed some fixes, so they were made in 9cf6b358e3baa36045021edc3ba1a2d09c9eec68. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.

Error: sha256 mismatch
Expected: f396bef6a8f6389170bf14367290fc8ceeb3de26d261c66795e7e18ecbce71ef
Actual: 4a0d67db88c533b98d19b5f163259e765988339bad4c1e7b9bb72e0c5354d7c3

Make a PR to update, please. Directions in reporting a bug.


bug: ng-enter,ng-leave don't fire when using slides

Type: bug
Platform: all
After upgrading to 1.2.1 I have a weird problem.
I'm using animate.css in my app to slide a popup in & out. In addition I have a couple of views using slides. When I open the popup from the main view it animates fine, but after moving to one of the slides views the animations are not played (the popup just appears). It also remains like this when going back to the main view.
At first I thought it was something with the new ion-slides directive, but it actually also happens with ion-slide-box.
Here's a codepen to demonstrate:
http://codepen.io/anon/pen/zrKPrE
I also tried adding animations from code - in this case after moving to the slides view again nothing happens and nothing is written to the console.
.animation('.popup', [function() {
return {
enter: function (element, doneFn) {
console.debug("enter");
jQuery(element).fadeIn(1000, doneFn);
},
leave: function(element, doneFn) {
console.debug("leave");
jQuery(element).fadeOut(1000, doneFn);
}
}
}])

Thanks! We were disabling ngAnimate in slides so I removed that for now to assess with the new slider.


Allow accessors to override non-class or abstract properties

An accessor may override a base property if all the property's declarations are (1) not from a class or (2) abstract.
If the base property is synthetic — from an intersection, for example — then it is allowed if any of the property's declarations are non-class or abstract.
Fixes #40733
Fixes #41347

Based on discussion in the design meeting, the change should instead be to exempt all properties that don't come from a class. Plus, we should keep this issue in mind in case other changes to Ecmascript cause TS to add language features dealing with prototypiness of properties/accessors.

This now matches what we decided in the design meeting. I'm going to fold in #42635 next since they do almost the same thing.

Ping @elibarzilay @rbuckton

Based on discussion in the design meeting, the change should instead be to exempt all properties that don't come from a class. [...]

I'm not 100% sure what "all properties" means here. We specifically added support to describe getters and setters in interfaces and type literals to differentiate between fields and accessors. We couldn't do that for mapped types, though, since mapped types can only describe field-like values (i.e., no getters, setters, or methods).

Re-reading it, I think I put the specifier in the wrong location on that comment -- I edited the description a couple months after the design meeting, so it's more up-to-date than the comment.
Basically, the change should exempt properties that whose declarations all come from outside a class, unless they're synthetic, in which case they are exempt if any declaration comes from outside a class.
I don't know what support we had for accessors in interfaces and type literals at the time, but it definitely sounds like they behave the same as classes now. I'll update the code to implement that.

Well, running the tests again without the accessor change in createUnionOrIntersectionProperty still has them all passing. So I reverted my change to see whether CI agrees with me.


Atom terminates with Segfault in Ubuntu 18.10

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
[Atom stops after launch with a segfault.]
Segmentation fault (core dumped)
Steps to Reproduce

[Upgrade Ubuntu -> 18.10]
[Launch Atom]
[wait - if launched from menu or see segfault if launched from cli]

Versions
$apm --version
apm  2.1.1
npm  6.2.0
node 8.9.3 x64
atom 1.31.2
python 2.7.15+
git 2.19.1
Additional Information

Segfaults on Fedora 29 beta as well.

Followed suggestion from this thread: https://github.com/atom/atom/issues/11743
Installed atom-1.32.0-beta3 and is working now.

Same issue here. Atom was up to date, before OS upgrading to Ubuntu 18.10.
Atom 1.32.0 Beta is working (but not my expected solution).

See https://github.com/atom/atom/pull/18012
and https://github.com/electron/electron/issues/13972
I hope the Atom team is able to release 1.32 as stable release soon, or can backport the Electron upgrade to the 1.31 branch.
Btw, Electron released 2.0.12 so the dependency can be upgraded again for 1.32 or maybe 1.33: https://github.com/electron/electron/releases/tag/v2.0.12

Duplicate of https://github.com/atom/atom/issues/18268
One gonna see a lot of these duplicate until the dev team finally release a stable working version...

I installed the latest beta too, but it had some issue with highlighting in bash.

As of 1.32, Tree-sitter (our new parsing system), is enabled by default:
http://blog.atom.io/2018/09/26/atom-1-31.html#tree-sitter-is-enabled-by-default
If you notice highlighting issues, please open an issue in the related language repository e.g. https://github.com/atom/language-shellscript/issues/127.

Just wanted to mention that 1.32.0 stable has been released :v:


Added french translations for 8 names

Added french translation for these names:

Andy: André
Jasper: Gaspard
Emily: Émilie
Josef: José
Lucius: Luc
Patrick: Patrice
Matan: Mattan
Ian: Yan

Removed translation for Benjamin because "benjoin" is not the translation

Awesome, thank you very much!
merged #33


Merge 2020-08-04 into tensorflow

Please test with following PRs:
apple/llvm-project#1595
@swift-ci Please clean test TensorFlow

Please test with following PRs:
apple/llvm-project#1595
@swift-ci Please clean test TensorFlow

Please test with following PRs:
apple/llvm-project#1595
@swift-ci Please clean test TensorFlow


Stop using ParquetReader completely

The main thing we were still using the ParquetReader class for was its
SchemaHandler.  But that was clumsy as it still had vestiges of the
renaming-columns-to-valid-go-public-field-names gunk that was needed for
its reflect-based api.
In this update, things that care about the parquet schema read the parquet
file footer directly, bypassing parqet-go's SchemaHandler class.  We're
still using the ParquetFile interface and low-level handlers for thrift,
compression, etc. from parquet-go, but we're now totally free from its
reader package.

Would it make sense to still have a struct that contains the source.ParquetFile and *parquet.FileMetaData values together, since they're typically passed together?

Yes, I think it makes sense to just use the Reader struct for this instead of creating something new.  Cleaned up to follow this pattern...

Ugh, this passes our ztests but its broken with another test file that I have here.  I'll see if I can debug this...


Is there a plan to support inserting declaration statements?

Describe the feature
expect
Insert a new statement before (or after) a statement.
import { parseModule, generateCode } from "magicast";

// Parse to AST
const mod = parseModule(`export default { }`);

// Insert a declaration statement before the `export default` statement
mod.exports.before(`const a = "VariableDeclarator";`);

// Ensure foo is an array
mod.exports.default.foo ||= [];

// Add a variable as a new array member
mod.exports.default.foo.push("a", "var");

/**
 * const a = "VariableDeclarator";
 * export default {
 *   foo: [a],
 * };
 */
console.log(generateCode(mod).code);

Additional information

[X] Would you be willing to help implement this feature?

Sounds reasonable. I think we could use $append and $prepend on every node? Prefix with $ indicates it's a special operation and avoids conflicts with the namespace.


Upgrade to Lean v4.4.0

I fixed the version in lean-toolchain now to avoid unpleasant surprises in the future. We should upgrade this somewhat regularly though :)

@matzemathics feel free to do the fix here :)

Please run nix fmt as well, or at least update the formatter if you want to use something other than alejandra.

@mmarx any ideas  what might be wrong in the nix build. It seems to me as if the lean flake is broken 😕.

I'll take a look.

@mmarx any ideas what might be wrong in the nix build? It seems to me as if the lean flake is broken 😕.

The problem is that ProofWidgets4 fails to build, because it has some custom logic in its lakefile.lean that builds Javascript from Typescript. buildLeanPackage doesn't do this, so it fails when the code tries to include those non-existing Javascript files. Not sure what the easy way to fix this would be, though.

Will merge without the nix changes for now and create a new draft PR for them.


Make compatible with React 16

This PR makes chai-react compatible with React 16. The test file passes when ran in browser.

Old description hidden below
This might allow React 16 to still work with this package. The react-addons-test-utils package has been deprecated and one should use react-dom/test-utils instead: https://reactjs.org/blog/2017/09/26/react-v16.0.html#packaging
This change allows us to remove react-addons-test-utils from our repository altogether while legacy tests still using chai-react pass now.
Let me know if I can help you with getting this to some release :relaxed:
EDIT: Unfortunately it seems this isn't enough to make chai-react compatible with React 16. Oh well. I'll see if there's a way to make this compatible with React 16, or if it would be easier to migrate tests away from chai-react altogether

Would you need to update package.json as well? I'm happy to help out a little if needed, but this repository is mostly inactive these days.

I'll see if I can get this to work with React 16, as that's the next thing on my plate. I'll let you know how it goes.

Ok now the CI passes, too. I think this should be good to go :relaxed:. This could be releases as 4.0.0, as it is a breaking change to support only React 16 and forward

Should be published as version 4.0.0 now.

Thanks! I'll give it a go the next time I touch code related to this ☺


Allow PitchShift deformer to take list for n_semitones

The PitchShift deformer only takes a single semitone parameter (n_semitones), which makes it a little awkward to work with when you want to perform multiple pitch shifts. LinearPitchShift can perform multiple shifts, but they have to be linearly spaced, which might not be the desired functionality (e.g. I may want n_semitones = [ -2, -1, 1, 2]).
It would be nice if PitchShift would accept (in addition to a single value) a list for the n_semitones parameter, in which case it would generate an output audio/jams for every pitch shift value in the list (times n_samples). This would make the behavior more consistent with other deformers (e.g. DynamicRangeCompression), and would allow (what I'm really after) writing more generic code that can apply a deformer agnostically of which deformer it actually is because the deformer is fully defined during initialization.

This would be pretty easy to do if we just tweak PitchShift to accept a float-or-array instead of a single float.  Should be a minor hack, if you want to take a crack at it.

Cool, I'll try and squeeze in a PR sometime before the end of this week

Check background for an example of this kind of logic.  All you need to do is then make this part iterate over the list of pitch values, instead of yielding a single value.

Cool, I'll try and squeeze in a PR sometime before the end of this week

Actually, I wound up on a spree of muda hacking last night, so I don't mind taking this one over today.


Change feedback response

Reply with "Ok, sender, will do". Maybe insert an invisible character after the first character of the nickname to prevent a highlight?

Maybe we could randomise from a selection of phrases? Like "will do", "alrighty", "you got it", "no problem", "consider it done", etc?

:+1:


Bad Request error in production

Edit: So I have found this to be related to ALLOWED_HOST but even with a setting of "*" the issue still persists. I'll take a dig at this since I've just gotten home from work.
I am seeing an issue using the production docker-compose and env files (suited for my environment and verified working otherwise, explained later in post) -- if I bring up the containers with "DJANGO_DEBUG=False" I will always receive a 400 - Bad Request error when attempting to access the API. If I set this to "True" then everything functions as expected. I haven't been able to figure out why just yet, but there isn't anything special about my setup that differs from the documentation examples. I can provide any information needed to help debug since I don't think running with Django debug on is a great idea.
My compose file and env is a bit different but I've tried this with the defaults and saw the same problem occurring so I don't believe they are related.
env_prod.list
# Database config
MYSQL_DATABASE=openeats
MYSQL_ROOT_PASSWORD=root

# Django config
API_URL=<IP_ADDRESS>:8000
API_PORT=8000
# openssl rand -hex 32
DJANGO_SECRET_KEY=blahblahblahblahblah
DJANGO_SETTINGS_MODULE=base.settings
DJANGO_DEBUG=True
ALLOWED_HOST='food.neverlocate.me'
HTTP_X_FORWARDED_PROTO=True

# Node config
NODE_ENV=production
NODE_URL=localhost:8080
NODE_PORT=8080
NODE_API_URL=https://food.neverlocate.me
NODE_LOCALE=en

docker-compose.yml
version: '2'
services:
  api:
    build: api/
    command: ./base/gunicorn_start.sh
    restart: on-failure
    volumes:
      - /opt/openeats/static-files:/code/static-files
      - /opt/openeats/site-media:/code/site-media
    depends_on:
      - db
    ports:
      - "8007:8000"
    env_file:
      env_prod.list
  node:
    build: frontend/
    command: npm start
    volumes:
      - node_modules:/code/node_modules
    depends_on:
      - api
    ports:
      - "8008:8080"
    env_file:
      env_prod.list
  db:
    image: mariadb
    volumes:
      - /opt/openeats/db:/var/lib/mysql
      - ./mariadb:/etc/mysql/conf.d
    env_file:
      env_prod.list
volumes:
  node_modules:

nginx (food.conf)
upstream api {
  ip_hash;
  server <IP_ADDRESS>:8007;
}

upstream node {
  ip_hash;
  server <IP_ADDRESS>:8008;
}

server {
    listen 443 http2;
    server_name food.neverlocate.me;
    ssl on;
    ssl_certificate /etc/nginx/certs/food-fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/food-key.pem;
    ssl_dhparam /etc/nginx/certs/dhparam.pem;
    ssl_protocols TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_ecdh_curve secp384r1;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver <IP_ADDRESS> <IP_ADDRESS> valid=300s;
    resolver_timeout 5s;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $http_host;
        proxy_pass http://node/;
    }

    location /api/ {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $http_host;
        proxy_pass http://api;
    }

    location /admin/ {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $http_host;
        proxy_pass http://api;
    }

    location /static-files/ {
        root /opt/openeats;
        try_files $uri /static-files/$uri;
    }

    location /site-media/ {
        root /opt/openeats;
        try_files $uri /site-media/$uri;
    }
}
server {
    listen 80 ;
    server_name food.neverlocate.me;

    return 301 https://food.neverlocate.me$request_uri;
}

So I've managed to fix this, at least temporarily, by manually adding my host in ALLOWED_HOSTS in api/base/settings.py -- it seems like the environment variable is not getting passed along and properly processed by the api container.

Change ALLOWED_HOST='food.neverlocate.me' -> ALLOWED_HOST=food.neverlocate.me

Hi Ryan,
I just gave that a try with the same results. I'm just putting together a BASH script quickly to take care of taking in the domain, generating a secret and pushing out the changes to Dockerfiles, etc then running docker-compose automatically. It should help with getting it deployed a bit easier for people and I want to tackle this problem a bit myself since it's interesting. I'll post it in this issue when I've finished.

This is kind of hacky, but it works for me. Definitely has room for improvement though:
prod-build.sh
#!/bin/bash
set -euo pipefail

allowedhost() {
    echo "Which host/domain name will this be accessed by?"
    read -r -s varAllowedHost
    if [[ -z varAllowedHost ]]; then
        echo "Nothing provided as input. Stopping."
        exit 1
    else
        echo "Using domain: ${varAllowedHost}"
    fi
}

djangosecret() {
    echo "Generating Django secret..."
    varDjangoSecretKey=`openssl rand -hex 32`
    if [[ -z $varDjangoSecretKey ]]; then
        echo "Django secret failed to generate."
        echo "Missing openssl (or really old?) Exiting."
        exit 1
    fi
}

djangosettings() {
    defaultdjangodebug='false'
    defaultdjangohttpxforwarded='true'
    echo "Django Settings"
    echo "Enable Django debug mode (true/false)? Defaults to false."
    read -e -i "$defaultdjangodebug" inputdebug
    echo "Enable HTTP X_FORWARDED_PROTO (true/false)?"
    varDjangoDebug=${inputdebug:-$defaultdjangodebug}
    echo "If you're using nginx, Apache or some other forward proxy with HTTPS, set to true. Defaults to true."
    read -e -i "$defaultdjangohttpxforwarded" inputforward
    varDjangoHttpForwarded=${inputforward:-$defaultdjangohttpxforwarded}
    if [[ -z $varDjangoDebug ]] || [[ -z $varDjangoHttpForwarded ]]; then
        echo "Something was not set. Please try again. Exiting."
        exit 1
    fi
}

nodesettings() {
    defaultapiurl=localhost:8080
    defaultnodelocale=en
    echo "Change Node API URL? Defaults to localhost:8080 (recommended)"
    read -e -i "$defaultapiurl" inputapi
    varNodeAPIURL=${inputapi:-$defaultapiurl}
    echo "Change Node locale? Defaults to en (recommended)"
    read -e -i "$defaultnodelocale" inputlocale
    varNodeLocale=${inputlocal:-$defaultnodelocale}
}

mysqlsettings () {
    defaultmysqlroot=`openssl rand -hex 16`
    defaultmysqldb=openeats
    echo "Set MySQL root password? Defaults to a randomly generated 16 character password."
    read -e -i "$defaultmysqlroot" inputroot
    varMySQLrootpassword=${inputroot:-$defaultmysqlroot}
    echo "Change MySQL database name? Defaults to openeats"
    read -e -i "$defaultmysqldb" inputdb
    varMySQLDB=${inputdb:-$defaultmysqldb}
}

dockersed() {
    for var in ${!var@}; do
        sed -i "s/$var/${!var}/" docker-prod-template.yml
    done
}

main() {
   echo "OpenEats quick setup script"
   echo "Running domain setup ..."
   allowedhost
   echo "Generating Django secret"
   djangosecret
   echo "Running Django settings setup ..."
   djangosettings
   echo "Running Node settings setup ..."
   nodesettings
   echo "Running MySQL settings setup ..."
   mysqlsettings
   echo "Generating finished docker-compose production file"
   dockersed
}

main

docker-prod-template.yml
version: '2'
services:
  api:
    image: openeats/api
    command: ./base/gunicorn_start.sh
    restart: on-failure
    volumes:
      - static-files:/code/static-files
      - site-media:/code/site-media
    depends_on:
      - db
    environment:
      - ALLOWED_HOST=varAllowedHost
      - API_URL=<IP_ADDRESS>:8000
      - API_PORT=8000
      - DJANGO_SECRET_KEY=varDjangoSecretKey
      - DJANGO_DEBUG=varDjangoDebug
      - HTTP_X_FORWARDED_PROTO=varDjangoHttpForwarded
  node:
    image: openeats/node
    command: npm start
    volumes:
      - node_modules:/code/node_modules
    depends_on:
      - api
    environment:
      - NODE_ENV=production
      - NODE_URL=localhost:8080
      - NODE_PORT=8080
      - NODE_API_URL=varNodeAPIURL
      - NODE_LOCALE=varNodeLocale
  db:
    image: mariadb
    environment:
      - MYSQL_DATABASE=varMySQLDB
      - MYSQL_ROOT_PASSWORD=varMySQLrootpassword
  nginx:
    image: openeats/nginx
    command: ./start.sh
    ports:
      - "80:80"
    volumes:
      - static-files:/var/www/html/openeats-static/static-files
      - site-media:/var/www/html/openeats-static/site-media
    depends_on:
      - api
      - node
volumes:
  database:
  node_modules:
  static-files:
  site-media:

After running the script and then doing docker compose -f docker-prod-template.yml up -d I was able to verify that everything works.
[root@neverlocate OpenEats]# curl -vvvv -H 'Host: food.neverlocate.me' http://<IP_ADDRESS>:86/api/v1
* About to connect() to <IP_ADDRESS> port 86 (#0)
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 86 (#0)
> GET /api/v1 HTTP/1.1
> User-Agent: curl/7.29.0
> Accept: */*
> Host: food.neverlocate.me
>
< HTTP/1.1 404 Not Found
< Server: nginx/1.13.3
< Date: Tue, 29 Aug 2017 00:29:16 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Language, Cookie
< Content-Language: en
<
* Connection #0 to host <IP_ADDRESS> left intact

Check it in this branch for something you can pull and run the script to deploy:
prod_shell branch at bglopez/OpenEats

I've done some testing on my end and I'm also able to get the ALLOWED_HOST to load what I give it in the env file.
I'm going to rename this to ALLOWED_HOST not loading correct value. If you could do me a favor and print out what the ALLOWED_HOST env value is inside the container when running via the env file that would be helpful. I'm curious as to why its not loading for you.
We can continue the discussion about the script you created in the PR.

Are you still have issues with this?


Outdated docs.

I was trying to use Hyprcursor via the hyprctl setcursor command, and when I pass in a theme name, I get size not int as an error. Vaxry told me that this means I didn't supply enough arguments to hyprctl setcursor, so this leads me to believe that the docs need to be freshened up a little.

uhh that should be reported to hyprland-wiki lol


Feature request - can we add MQTT Explorer to Mosquitto add on

Can we add MQTT Explorer (http://mqtt-explorer.com/) to the mosquitto add on in a similar way that we have access to ozw-admin on the zwave addon via NoVNC I believe?

While nice, I think this might be over the top for the add-on.
Adding features like this makes an add-on way more complicated to maintain but even more important, way heavier to run.

The flip side is it makes it easier to debug issues. E.g. I'm suffering from several OpenZwave issues at the moment - being able to more easily look at what is on MQTT would be very handy but I take your point on the complexity.

MQTT explorer just needs access to the broker that is publishing messages. You can run it from another computer and connect to the broker. So it should be easy to run it standalone.


Error when importing pointnet2_utils

Hi,
Thanks for the great work! I try to run the code, and get this error:
CUDA error: the provided PTX was compiled with an unsupported toolchain.
This error only happens when I import as from pointnet2_ops import pointnet2_utils (commenting it has no error). And the error also only happens when I use Nvidia Ampere arc, specifically, Nvidia A5000. Here is my other setting:

Python: ver 3.9
Pytorch: ver 1.9, with cuda 11.1
Cuda driver in my Ubuntu machine: 11.3

Note: the pointnet2 installation goes well, without any error message
Thanks!

Thanks for your interest.
Two suggestions: 1) please upgrade your pytorch version to 1.13+ for Ampere Arch; 2) please make sure the pytorch instsall cuda version is same as your Cuda driver version.
Hope that can help.

Thanks much for your reply. Thanks to this PyTorch forum here, I added “8.6” in the TORCH_CUDA_ARCH_LIST here, and it solved the issue.


Ruby capstone project

Link to project: https://github.com/GordonOtieno/ruby-capstone/projects/1
We were 3 people in a group:
Haadiiii #1, GordonOtieno #2, whid-bb #3

Hi Team,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉
Highlights :green_circle:

Tasks assigned to each student are distributed in a fair manner :heavy_check_mark:
Each requirement of the project has one corresponding card :+1:
The required number of columns has been added to the board :+1:
The GitHub issue link contains the requested information :+1:

Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


[WIP] Profile Overrides (RFC #2282 Part 1)

Profile Overrides (RFC #2282 Part 1)
WIP: Putting this up before I dig into writing tests, but should be mostly complete.  I also have a variety of questions below.
This implements the ability to override profiles for dependencies and build scripts.  This includes a general rework of how profiles work internally. Closes #5298.
Profile overrides are available with profile-overrides set in cargo-features in the manifest.
Part 2 is to implement profiles in config files (to be in a separate PR).
General overview of changes:

Profiles moved to core/profiles.rs. All profile selection is centralized there.
Removed Profile flags test, doc, run_custom_build, and check.
Removed Profile from Unit and replaced it with two enums: CompileMode and ProfileFor.  This is the minimum information needed to compute profiles at a later stage.
Also removed rustc_args/rustdoc_args from Profile and place them in Context.  This is currently not very elegant because it is a special case, but it works. An alternate solution I considered was to leave them in the Profile and add a special uber-override layer.  Let me know if you think it should change.
Did some general cleanup in generate_targets.

Misc Fixes

cargo check --test name was checking too many things.  Now it only checks the test and its deps.
cargo check now honors --release. Fixes #5218
cargo build --test will set panic correctly for dependences.  Fixes #5369.

Questions

Thumbs up/down on the general approach?
The method to detect if a package is a member of a workspace should probably be redone.  I'm uncertain of the best approach.  Maybe Workspace.members could be a set?
Hash and PartialEq are implemented manually for Profile only to avoid matching on the name field.  The name field is only there for debug purposes. Is it worth it to keep name?  Maybe useful for future use (like #4140)?
I'm unhappy with the Finished line summary that displays [unoptimized + debuginfo].  It doesn't actually show what was compiled.  Currently it just picks the base "dev" or "release" profile.  I'm not sure what a good solution is (to be accurate it would need to potentially display a list of different options).  Is it ok?  (See also #4140 for the wrong profile name being printed.)
Build-dependencies use different profiles based on whether or not --release flag is given.  This means that if you want build-dependencies to always use a specific set of settings, you have to specify both [profile.dev.build_override] and [profile.release.build_override].  Is that reasonable (for now)?  I've noticed some issues (like #1774, #2234, #2424) discussing having more control over how build-dependencies are handled.
build --bench xxx or --benches builds dependencies with dev profile, which may be surprising.  --release does the correct thing.  Perhaps print a warning when using cargo build that builds benchmark deps in dev mode?
Should it warn/error if you have an override for a package that does not exist?
Should it warn/error if you attempt to set panic on the test or bench profile?

TODO

I have a long list of tests to add.
Address a few "TODO" comments left behind.

Thumbs up/down on the general approach?

:+1: :+1: :+1:

The method to detect if a package is a member of a workspace should probably be redone.

I think current implementation is OK: linear scan is perfectly fine until you have hundreds of members.

Is it worth it to keep name?

I have no opinion here :)

I'm unhappy with the Finished line summary

It still works correctly when no overrides are present, and otherwise it is a minor detail, so I suggest to punt on this for know: current solution seems at least OK to me!

Build-dependencies use different profiles based on whether or not --release flag is given.

Yeah, that seems generally wrong, but OK for now, because it more or less matches the current behavior. I would say that this is probably an instance where we do need a separate, not dev/not release profile, but let's deal with that later.

build --bench xxx or --benches builds dependencies with dev profile,

Hm, is this the current behavior? It definitely is a bug!

Should it warn/error if you have an override for a package that does not exist?

Let's give at least a warning if it's not too hard: typoes are likely in the names of packages, especially with - vs _ distinction.

Should it warn/error if you attempt to set panic on the test or bench profile?

It is allowed now, right? Then I think error is probably not feasible, but the warning seems useful!

Thanks @matklad for doing such a detailed review so quickly!
Unfortunately, I've discovered a pretty fundamental flaw in how it works.  Units are not being properly de-duplicated.  Example: test→lib and bin→lib, the lib gets compiled twice (once as a regular dependency, and again as a test dependency).  But if you don't have panic set they get compiled with the exact same settings!
I think Profile really must be a part of Unit.  I had a previous attempt that had it part of the Unit, but I was concerned about the huge amount of copying.  However, I was using Strings before (instead of InternedString), and it seemed much worse at the time (require lots of clone() calls).  I'm going to rewrite it to use this approach.  Profile is only 24 bytes on my system, so it shouldn't be too bad.  On the plus side, it should simplify some things.
Sorry for the churn, I'll try to fix this today and address all your comments.

I've pushed the update that now embeds the profile inside Unit.  It works quite a bit better now.  I fear there are still some hidden gotchas, so I'll need to spend a fair amount of time making tests.  I left a long comment in there about a subtle issue with cargo test, that I think I'm going to revisit because it's not quite right.  Getting proper panic support is turning out to be very tricky.  Doc tests are also turning out to be very tricky, because it greedily links against any libs it finds in Context.libraries.

:umbrella: The latest upstream changes (presumably #5392) made this pull request unmergeable. Please resolve the merge conflicts.

The CI failures are due to the introduction of rust-lang/rust#49289 (starting with nightly 2018-04-15).  cargo check will now emit rmeta files for all targets.  This will actually address #3624.  However, I'm uncertain how the test should be structured now.  It's trying to verify the "freshness", but the behavior has changed between rust versions.  How do you typically accommodate different rustc versions?

(I've updated the first comment with some other Misc Fixes that probably aren't too controversial, but please review them.  Sorry for the long comment, I just wanted to be thorough.)
The latest push includes some tests (profile_targets.rs) that illustrate what I was asking about before in regards to a way to verify exactly which commands get run, but ignoring the order.  I don't think it would be possible to achieve the same level of verification with the existing functions (in particular, verifying what doesn't get run).  Let me know if you would prefer it to be done in a different way, though.  One alternative thought I had would be to have an option for with_json to ignore the order of messages, and add some more information to ArtifactProfile to be able to distinguish which profile is used.
Questions

The doc profile does not seem to be used.  Internally it is assigned to running rustdoc, but rustdoc does not use any flags from the profile.  Is that intended?  Perhaps we could deprecate it (or maybe just remove it from the docs)?  There are about 24 crates on crates.io that set it for whatever reason.
I just want to double-check... I've been using the term "profile override" in a few places, but I'm starting to feel that might not be clear (compared to [profile.dev] is overriding the default dev profile).  "package profile override" would be more accurate, but is maybe a little wordy?

Behavior Changes to Discuss
The following are new changes in behavior that I'm uncertain if we should keep or change.

cargo build --release --all-targets now compiles libs and bins twice (once for benchmarks, once for unit-tests).  Previously the de-dupe logic would only compile them once (since they are essentially identical).  This is because with CompileMode in Unit it distinguishes between a Bench and Test, so it doesn't get de-duped.  I could maybe add a special case for this?

If a build.rs is needed for different profiles, it will now be run separately for each one.  For example, build --all-targets will run build.rs once for the dev targets, and once for the bench targets (because the opt-level is different between them).  I think this is more-correct behavior, but may be a surprising change to some.  Thoughts?

Panic Changes and Issues
Getting panic correct has been quite tricky.  This is the list of changes and issues I'm currently aware of.  These assume you have panic set in some profile.

cargo build with tests or benches was previously failing (error: the crate `foo` is compiled with the panic strategy `abort` which is incompatible with this crate's strategy of `unwind` ).  This is now fixed.

cargo test builds binaries without panic set.  This is a tricky issue.  If this is fixed, then the lib would get built three times (once without panic for tests, once with panic for bins, once with --test as a unit-test).  The bigger problem is that rustdoc for doc-tests would fail to run because it would pick up both copies of the lib.  See comment previously about needing to change Context.libraries to fix this.  Leave as-is?  Fix now/later?

build.rs scripts and their dependencies have panic cleared because the panic-clearing logic thinks it is a compiler plugin (see build_base_args).  However, I don't think build.rs scripts should be treated the same as compiler plugins/proc-macros.  Would it be worth it to fix this?  The change is fairly easy -- I would probably add for_plugin (for_compiler?) to Target and adjust walk_used_in_plugin_map to use that instead of for_host.  This is a minor issue, but I was a little surprised to see it in one of my test cases.
The consequences are:

build.rs scripts are always built without panic.
If you have a dependency that is shared as a regular dependency and a build dependency, and you run cargo test or cargo bench, the dependency will be built twice, but with the same settings.  Internally it thinks one is "dev without panic" (for tests) and the other is regular "dev" (for build.rs).  It works fine, but slows things down since the shared dependency is built twice.

Known Bugs

DEBUG env var in build.rs is incorrect if profile debug=0.  #5370.  Will fix in a separate PR.
Having a global build_config.release flag causes some issues.  I'm uncertain how difficult this is to fix.  Generally getting rid of the global build_config.release would be the correct approach.  Thoughts?  Address now or later?  I think this only affects cargo build, and the workaround is to pass --release to it.  Consequences:

PROFILE env var in build.rs is incorrect for cargo build --bench name, it says it is "debug" when in reality it is "release".
cargo build --bench xxx will build dependencies in dev profile, which may be surprising (#4929).

cargo check only ever uses dev or release profile.  For example, cargo check --test foo uses dev instead of test.  I'm uncertain how any of the profile flags might affect rustc when running check.

The latest push includes some tests (profile_targets.rs) that illustrate what I was asking about before in regards to a way to verify exactly which commands get run, but ignoring the order. I don't think it would be possible to achieve the same level of verification with the existing functions (in particular, verifying what doesn't get run)

Yeah, that seems reasonable. Let's add with_stderr_unordered perhaps which compares sets of lines?

However, I'm uncertain how the test should be structured now. It's trying to verify the "freshness", but the behavior has changed between rust versions. How do you typically accommodate different rustc versions?

I think we can add
// If you are reading this, and 1.27.0 is already stable, feel free to just remove this if!
if !is_nightly() { return; }

The doc profile does not seem to be used. Internally it is assigned to running rustdoc, but rustdoc does not use any flags from the profile. Is that intended? Perhaps we could deprecate it (or maybe just remove it from the docs)? There are about 24 crates on crates.io that set it for whatever reason.

Yep, I believe we can safely deprecate this profile. That is, leave the syntax in Cargo.toml, give a warning about it, and remove traces of doc profile from the code. Eventually I think we'll do the same for test and bench profiles, but they are used, so we'll deal with that separately.

"package profile override" would be more accurate, but is maybe a little wordy?

I personally think about it as just "package profile". We need override in the surface syntax just to namespace this feature. I wonder if a sweeter syntax is possible? [profiles.dev.for.image] perhaps?

cargo build --release --all-targets now compiles libs and bins twice

I think it is important to remove this duplication. Could we get rid of the Bench compile mode?

If a build.rs is needed for different profiles, it will now be run separately for each one. For example, build --all-targets will run build.rs once for the dev targets, and once for the bench targets (because the opt-level is different between them). I think this is more-correct behavior, but may be a surprising change to some. Thoughts?

Hm, so currently build_scripts are compiled only with dev or release profiles. I suggest we keep this behavior, for three reasons:

No change means that we won't break someone's code,
If we remove all profiles except dev and test, we'll effectively have to change it back,
Test fiddle with panic setting, and this I think should not affect build scripts.

Long term, I believe the current behavior of using both dev and release for build scripts is also wrong. I think we need a separate use-visible profile for build scripts and their dependencies, so that cargo build && cargo build --release does not compile build scripts twice.
I don't think there should be any sharing between the build script and the main code. Especially for cross-compilation, it seems unreasonable to use the same profile for both.

Yep, I believe we can safely deprecate this profile.

Would you like that now, or in a separate PR (since this one is getting a little long)?

[profiles.dev.for.image] perhaps?

Hm, that is a little clearer.  Not sure if anyone else wants to weigh in?

I think it is important to remove this duplication. Could we get rid of the Bench compile mode?

It would be nice, because once the Unit is constructed, it is not needed.  However, there would need to be a way for generate_targets and generate_default_targets to know that we are cargo bench to select the correct targets and profiles.  I could pass a flag in through CompileOptions, what do you think?  An alternate solution is to just swap the mode in generate_targets when the Unit is made which would be a one-line change to fix this.

Hm, so currently build_scripts are compiled only with dev or release profiles. I suggest we keep this behavior, for three reasons:

This is how it works (before and after this change) for compiling the build.rs script.  I was talking about executing it.  In the new code, it is run twice because the OPT_LEVEL is different for different targets' dependencies.  This goes back to, should cargo build --bench xxx build the dependencies of a benchmark in dev mode?  I guess I left it sort this in a halfway state.  I see two options.  One is to restore the old behavior (benches get dev for custom-built dependencies), and I can fix that by just checking the global release flag for running build.rs, which I think is an easy change.  The other is to actually fix that problem, which might be more difficult (involves removing the use of the global release flag).  I'm fine with restoring the old behavior, this is an edge case (building benchmarks with cargo build without --release flag).  I'm also fine with trying to fix it properly.  Or other options (like not even trying to build benches with cargo build if you don't set --release?).

I think we need a separate use-visible profile for build scripts and their dependencies

Isn't that what build-override is essentially?  I think I mentioned it earlier, that this pseudo-profile already exists, but you have to define it twice (profile.dev.build-override and profile.release.build-override), and it has a weird relationship with other overrides.
This brings up a issue that was nagging at me.  I didn't fully understand the reasoning for the override precedence in the RFC.  Since other rules take precedence over build-override, it seems like that can yank away the ability to independently control how a build script is compiled vs how the dependency itself is compiled.   There is a comment in the RFC thread that you and Manishearth had separately about this, but it didn't make sense to me.  The build-dependencies are always kept independent of the final binary, even if we removed the precedence.  Changing the precedence could give the user more control.  (Or even adding something like [profile.scripts.overrides.somedep] which would be very easy to do.)  I guess my rambling question is, why not give independent control?

Could you elaborate why do you think so?

The only reason this exception is made is to ensure the panic flag is cleared (because plugins are linked with things that can't have it set).  build.rs scripts don't have that limitation since they aren't linked with the compiler.  I'm fine with clearing it for build.rs.  I'm uncertain how likely it is to be a problem for someone.  Considering it has always been this way, and things built with panic=abort is very rare to start with, it might not bother anyone.  However, if panic is set, it could cause shared dependencies to be needlessly built twice.

I think it's fine to leave this duplication as is, but, if we are to fix it, then perhaps " Internally it thinks one is "dev without panic" (for tests) and the other is regular "dev" (for build.rs)." is the bit that needs adjustments?

Correct, it's a small, trivial change to say "panic = None" for build scripts in the profile builder.

Would you like that now, or in a separate PR (since this one is getting a little long)?

A separate one. I'd prefer to merge this sooner, and not to fix  all profile bugs at once :)

Hm, that is a little clearer. Not sure if anyone else wants to weigh in?

I personally don't care about syntax at this stage. There's already override in there, so let's not change it for now.

I could pass a flag in through CompileOptions, what do you think? An alternate solution is to just swap the mode in generate_targets when the Unit is made which would be a one-line change to fix this.

Another option is to split CompileMode into two enums: one to be used with CompileOptions, which  corresponds to which cli options were passed, and one to be used with Units. But "swapping the mode" solution also sounds fine with me!

I was talking about executing it

Oh, right! I've completely misunderstood your original comment then! The new behavior indeed seems more correct to me as well!

Isn't that what build-override is essentially? I think I mentioned it earlier, that this pseudo-profile already exists, but you have to define it twice (profile.dev.build-override and profile.release.build-override), and it has a weird relationship with other overrides.

Yep, it's almost like build-override, with two important differences: you don't need to override it twice, and, by default, build profile is the same for cargo build and cargo build --release.

The build-dependencies are always kept independent of the final binary, even if we removed the precedence.

Hm, I think we though that dependencies are shared between the library and the build script. Because they are independent, priority for build_overrides indeed does not make sense.

Hm, I think we though that dependencies are shared between the library and the build script. Because they are independent, priority for build_overrides indeed does not make sense.

OK, let me know if you want to iterate on this now or later.  It's pretty easy to change.
Let me know if there's anything else.  I think I've gone through the issues I can think of.

:umbrella: The latest upstream changes (presumably #5415) made this pull request unmergeable. Please resolve the merge conflicts.

:sunny: Test successful - status-appveyor, status-travis
Approved by: matklad
Pushing c24a09772c2c1cb315970dbc721f2a42d4515f21 to master...