Stop playing after command/change

Hi, it's great project!
It plays well right after reset.
But it will stop when I change something (vol+-, station).
It will continue playing after disconnect and connect RST wire from VS1053. (probably reseting)
I've checked wiring multiple times. I tried to connect VS1053 RST to ESP8266 RST (WemosD1) or to 5V - it doesn't matter.
I'm aware of one change - I had to change following code:
from system_update_cpu_freq ( 160 ) ; to system_update_cpu_freq ( 80 ) ;
If it was set to 160 then tho sound was disruptive. For 80MHz is good.
This is part of debug output:
D: Reset VS1053...
D: End reset VS1053...
D: Slow SPI,Testing VS1053 read/write registers...
D: Fast SPI, Testing VS1053 read/write registers again...
D: endFillByte is 88
Could you advise ?
Thanks

Looks like there is something wrong with the web interface.  Could you try to enter some commands like "upvolume=2" on the serial interface in the IDE?  Use the "Enter" key after each command.
Could you also try a different (stronger) powersupply?

I appreciate your quick response.
I've tried different stronger powersupply and also command via serial interface - same behaviour :(
I believe it's not related to web GUI.
I don't have "reset circuit". I've just connected V1053 RST to ESP RST or 5V or via 10k resistor to 5V.
Could missing "reset circuit" affect functionality ?
I've read in different thread that it's not really necessary.
Also I've tried my VS1053 board in different project without problems. So I believe my hardware is ok.

The reset circuit is not critical.  Are there unusual lines in the logging when you change the volume?

I don't think so. It looks normal for me
D: Starting ESP Version Wed, 31 May 2017 12:35:00 GMT...  Free memory 13152
D: Sketch size 348080, free size 700416
D: Reset VS1053...
D: End reset VS1053...
D: Slow SPI,Testing VS1053 read/write registers...
D: Fast SPI, Testing VS1053 read/write registers again...
D: endFillByte is 88
...
D: FileRequest received /index.html
D: Response sent
D: list request from browser
D: FileRequest received /radio.css
D: Response sent
D: FileRequest received /favicon.ico
D: Response sent
D: Command: upvolume with parameter 2

then I need to diconnect/connect VS1053 RST  manually

D: Command: upvolume with parameter 2

diconnect/connect VS1053 RST

D: Volume is now 34

same after command via serial - diconnect/connect VS1053 RST

D: Metadata block 64 bytes
D: Streamtitle found, 56 bytes
D: StreamTitle='Urban Jazz Coalition - Better Days Comin'';

I see something strange: The endFillByte is 88.  Normally this would be 00.  Are you sure you chip is a VS1053?.  I know that some modules have a different chip, although it has been sold as a VS1053.  Please check this.

Yes, the software is for VS1053 only.


ES6 template literals - interpolation colouring

I'm really liking Semanticolor, however my main issue with it is that it's not very useful when it comes to template literal colouring.
By default, the template literal uses the my theme's styling, which marks what's in the ${} of a template literal, however, I lose out on the colourisation of those same variables that I'm using elsewhere. Alternatively, I can restore that functionality by colourising strings, but that just runs them into a jumble of colours, which is no good for a plethora of other reasons.
Support for the colourisation of variables within template literal interpolation blocks would be extremely useful.
Theme colouring

Colourisation colouring

Thanks. I'll look into this soon.

What JavaScript grammar are you using?

I'm using the ES6 Babel grammar.

It's gandm's language-babel specifically.

Fixed in 3.4.0.


bug: Module '"novel"' declares 'Editor' locally, but it is not exported.

Provide environment information
System:
OS: Linux 6.2 Ubuntu 20.04.6 LTS (Focal Fossa)
CPU: (2) x64 AMD EPYC 7763 64-Core Processor
Memory: 4.20 GB / 7.74 GB
Container: Yes
Shell: 5.0.17 - /bin/bash
Binaries:
Node: 20.11.0 - ~/nvm/current/bin/node
Yarn: 1.22.19 - /usr/bin/yarn
npm: 10.2.4 - ~/nvm/current/bin/npm
pnpm: 8.15.1 - ~/nvm/current/bin/pnpm
Describe the bug
Module '"novel"' declares 'Editor' locally, but it is not exported.
Link to reproduction
any
To reproduce
After installation packages
Additional information
No response

I am also facing the same problem.

Awh, they updated

Same issue

Same here

To people on this thread please refer this.
The latest novel version does not support Editor. You can downgrade to v1 if you still want to use Editor or refer this to setup novel v2 correctly.
This thread can be closed

@amang06   great but they should change the documentation from Novel Example

Thank you for the informations, is their any good v1 documentation?

@UPocek I don't think there is follow this video v1 setup is pretty straightforward. You can also refer to the project in the description if you want to save time

@UPocek I don't think there is. Follow this video v1 setup is pretty straightforward. You can also refer to the project in the description if you want to save time

That work but latest version not work

@chk7964  actually they updated their version, so your old setup will not work there
Now you need to follow this style for Novel Editor

@UPocek I don't think there is. Follow this video v1 setup is pretty straightforward. You can also refer to the project in the description if you want to save time

Can you provide demo repository.

same issue here

@steven-tey Please fix the docs for beginners, they are not at all friendly and useful

Any update on how to fix this ?


Testing the encoding.

This adds more tests... this time on the encoding.

Merging since this only adds new tests.


Can't Modify or turn off shift_whitelist

I have added a datapack to modify shift_whitelist but it just loads with the default I also tried to turn off the shift_whitelist with the config but it doesn't work. I know that I have the file path correct because I can modify global_whitelist.
I'm not sure how to resolve this issue/bug

how did you make it work?

mine would not even work

how did you make it work?

I didn’t that’s the problem :(

mine's can vein dig default but don't know how to whitelist other stuffs

Seems that the whitelist system is broken, to change them your meant to be able to use a datapack and change the tags but it seems the mod just uses default tags even if a datapack is installed


raftstore: optimize metrics of the local reader

Signed-off-by: 5kbpers<EMAIL_ADDRESS>
What have you changed? (mandatory)
Currently the metrics of local reader seems too confused.
This PR removes a confused metrics reject_by_cache_miss and some unused metrics, add a counter of the total executed requests number.
What are the type of the changes? (mandatory)

Engineering (engineering change which doesn't change any feature or fix any issue)

How has this PR been tested? (mandatory)
ci, manual test
Does this PR affect documentation (docs) or release note? (mandatory)
No.
Does this PR affect tidb-ansible update? (mandatory)
https://github.com/pingcap/tidb-ansible/pull/873

/test


media player unavable

Home Assistant version
0.99.3
SmartIR version
1.7.3
SmartIR configuration

binary_sensor:
  - platform: threshold
    name: "Status TV Studio"
    entity_id:  sensor.rgbplug2_energy_power
    upper: 26

  - platform: threshold
    name: "Status Stereo Studio"
    entity_id:  sensor.presa_tpl1_watts
    upper: 26

sensor:
  - platform: template
    sensors:
     presa_tpl1_watts:
        friendly_name_template: "{{ states.switch.presa_tpl1.name}} Current Consumption"
        value_template: '{{ states.switch.presa_tpl1.attributes["current_power_w"] | float }}'
        unit_of_measurement: 'W'

media_player:
  - platform: smartir
    name: Stereo Studio
    device_code: 1099
    controller_data: <IP_ADDRESS>
    power_sensor: binary_sensor.status_stereo_studio

  - platform: smartir
    name: TV Studio
    device_code: 1010
    controller_data: <IP_ADDRESS>
    power_sensor: binary_sensor.status_tv_studio

**Describe the bug**

The component is installed (i tried also reinstalling it without changes), the media player are defined ( those was working until 1 month ago) but the media player are not create. No trace. No error in log.

I'm afraid I can't help you without errors in logs. Please try to restart HA and examine line by line if something related to SmartIR

Same problem, with HA 0.98.3
In the folder .homeassistant/custom_components/smartir/pycache    the file media_player.cpython-37.pyc does not exist
There is no error in HA anywhere

for me the error was that the .json file for device was missing (lost after upgrade !).

Thats's not my error, because I've got all de json files in the folders, media_player, fan and climate.
Thanks jokerigno.

for me the error was that the .json file for device was missing (lost after upgrade !).

Thats's not my error, because I've got all de json files in the folders, media_player, fan and climate.
Thanks jokerigno.


How can I embed CalendarView written in Kotlin?

I am trying to implement Android library written in Kotlin via platform channels. I don't know how to achieve this. I have chosen this library because it is highly customizable and there is not any Flutter library advanced like this. So I thought may be I can implement this via platform channels like admob_flutter plugin. I asked this question on Stackoverflow but there is no answer yet. I would be appreciated if you can give me any ideas, sample codes. (or some Flutter library which is like that)
Here is my question on Stackoverflow

The Google Maps plugin uses a platform view: https://github.com/flutter/plugins/tree/master/packages/google_maps_flutter


refactor: Update xapi_events_all_parsed and supporting view

Extract org and object id into the top level of xapi_events_all_parsed.
Use the String type instead of JSON for the event JSON data, since the JSON type is so poorly supported.
Add time_last_dumped to event_sink.relationships PK to help speed up queries on that data

@Ian2012 @mariajgrimaldi @soryrawyer I can't ping you all for reviews directly, but would appreciate your eyes on this. It should tidy up some longstanding issues with this table, but once merged will require you to drop the xapi_events_all_parsed table and xapi_events_all_parsed_mv view so they can be recreated. Hopefully that will be the last time we need to do this, but I kinda doubt it.


Bump OpenSSL component to 3.0.14

OpenSSL released a new version that has a few security fixes that affect the 3.0.x series we use. We're currently on 3.0.13 with the OpenSSL we package together for the latest puppet-agent.
Those CVEs that will be fixed by updating to OpenSSL 3.0.14 are: CVE-2024-4741 CVE-2024-4603 CVE-2024-2511
All of those are rated 'low', so there isn't an critical need to have this patched right away.

Fixed in https://github.com/puppetlabs/puppet-runtime/pull/865


Updates for SDK 1.17 (requires golang 1.17)

OSPK8-461 #close

This will require us to bump our downstream CI to golang 1.17. Need to check on how to do this so we can continue to have golang 1.16 on the stable branch.

This will require us to bump our downstream CI to golang 1.17. Need to check on how to do this so we can continue to have golang 1.16 on the stable branch. @olliewalsh

Do you mean for the buildah jenkins job? Might be better to change the job to fetch the version from Dockerfile

This will require us to bump our downstream CI to golang 1.17. Need to check on how to do this so we can continue to have golang 1.16 on the stable branch. @olliewalsh

@dprince Do you mean for the buildah jenkins job? Might be better to change the job to fetch the version from Dockerfile

Yes, I'm looking into it today.

/retest


Errors Running on Colab

When running the command !python -m torch.distributed.launch --nproc_per_node=1 --master_port=1234 train.py --batch 1 /content/data/preprocessed on Google Colab, it first complains that 'Ninja is required to load C++ extensions' which can be fixed by running pip install ninja.
Unfortunately running the command again after restarting runtime returns the following error which I can't seem to get around:
0% 0/800000 [00:00<?, ?it/s]Traceback (most recent call last):
 File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
   "__main__", mod_spec)
 File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
   exec(code, run_globals)
 File "/usr/local/lib/python3.6/dist-packages/torch/distributed/launch.py", line 253, in <module>
   main()
 File "/usr/local/lib/python3.6/dist-packages/torch/distributed/launch.py", line 249, in main
   cmd=cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-u', 'train.py', '--local_rank=0', '--batch', '1', '/content/data/preprocessed']' died with <Signals.SIGFPE: 8>.

Any idea on how to get this to work?

I thinks it is related to pytorch, as you don't need to install ninja separately.

PyTorch and CUDA versions match the ones mentioned in the README. I think the issue was with the batch number being too small - changing it seemed to get things running

A small helper script for converting weights on google colab,
https://colab.research.google.com/drive/1OtRXSTK720kBVfkP_YboTJvxC5-7iAak

A small helper script for converting weights on google colab,
https://colab.research.google.com/drive/1OtRXSTK720kBVfkP_YboTJvxC5-7iAak

Can you send me this file? 493173142@qq.com,thanks!

A small helper script for converting weights on google colab,
https://colab.research.google.com/drive/1OtRXSTK720kBVfkP_YboTJvxC5-7iAak

Nice!


Compatibility

Can flutter work on a 4gb ram machine?

@jaesmoke
I believe that this kind of questions belong on discord channel

Can flutter work on a 4gb ram machine?

probably yes, I have 3 recommendation:

use linux (don't use snapcraft, install flutter the right way)
debug on physical device (not on emulator)
don't use android studio (it uses a tons of RAM)

As suggested above, please ask such questions on support channels.
Closing from here.

ok thanks :)


"The handle is invalid" exception when redirecting output to a file

Version: Parquet.Net v3.8.5
Runtime Version: .NET 5.0.301
OS: Windows 10 Pro Version 21H1 OS Build 19043.1083
Expected behavior
when I redirect the output of parq tool to a file, I expect the output of parq tool will be in the file. The syntax I use is like this:
parq convert path_to_my_parquet_file.parquet > test.json

Actual behavior
When I open test.json after the execution, I see
parq v3.8.5

reading file (10 rows min)...
The handle is invalid

Steps to reproduce the behavior

Open Terminal
Execute parq convert path_to_my_parquet_file.parquet > test.json (change with any parquet file)
Check content of test.json

Code snippet reproducing the behavior

I cloned the repository, and debugged to try to find the issue. I get that same exception. The stacktrace is:
   at System.ConsolePal.SetCursorPosition(Int32 left, Int32 top)
   at System.Console.SetCursorPosition(Int32 left, Int32 top)
   at Cpf.Widgets.ProgressMessage.Dispose()
   at Parquet.CLI.Commands.FileInputCommand.ReadTable(Int32 maxRows) in C:\Thirdparty\parquet-dotnet\src\Parquet.CLI\Commands\FileInputCommand.cs:line 36
   at Parquet.CLI.Commands.ConvertCommand.ConvertFromParquet(Int32 maxRows) in C:\Thirdparty\parquet-dotnet\src\Parquet.CLI\Commands\ConvertCommand.cs:line 48
   at Parquet.CLI.Commands.ConvertCommand.Execute(Int32 maxRows) in C:\Thirdparty\parquet-dotnet\src\Parquet.CLI\Commands\ConvertCommand.cs:line 36
   at Parquet.CLI.Program.<>c__DisplayClass0_3.<Main>b__9() in C:\Thirdparty\parquet-dotnet\src\Parquet.CLI\Program.cs:line 86
   at Cpf.App.Command.Execute(ConsoleArguments arguments, Action`1 onBeforeExecuteCommand)

So it looks like it's trying to set the cursor position, which of course isn't possible in a file

This isn't the official Parquet.NET repo. See https://github.com/aloneguid/parquet-dotnet


Support Hero Chat?

I want to use Multiverse Alias with Hero Chat, is there any way?

Try
https://www.spigotmc.org/resources/mv-chatalias.44531/
It allows you to use Multiverse world aliases with Herochat by using {mvAlias}.


pdb command to call pdb.disable

import pdb; pdb.disable() is such a nice feature that it should have a command.
disable is already taken for breakpoints.
Something short like cc[ont] would be nice.

First, I'd like to make sure that I understood your use case: you have a program which contains a bunch of pdb.set_trace(); at some point, you would like to type ccont to continue the execution without breaking at the subsequent set_trace()s. Is this correct?
I am fine to add a new command, but only if it's not obscure. E.g., I don't understand what ccont stays for :).
Moreover, note that you can easily add custom commands using pdbrc.py; e.g., see [this example)(https://github.com/antocuni/pdb/blob/master/pdbrc.py#L37)

Yes, you understood it correctly.
It might be just a single set_trace, which gets hit by lots of tests then though.
ccont came up via cont(inue), which is taken already.
I agree that the name is obscure.

import pdb; pdb.disable() is good enough for me for now.


As an end-user, TOTP reset process is too onerous (and for support too...)

In order to support users who have a new device, or have lost their TOTP device, we need a process to get them working again with a "sufficient" amount of verification, and less burden on support.
[need more description of current problem]
Team consensus is that stripping all roles may be overkill, and might be better to have better identity validation.
Security considerations
There are significant considerations here, as we should be resistant to social engineering this process.
Implementation sketch/ideas:
Validation for TOTP reset could be:

phone calls to the phone on file for an org manager (not currently gathering phone number as a recovery factor)
email from another team member in the same org
demonstrate control of the old device by logging in to cloud.gov and taking an auditable action

@bengerman13 and @spgreenberg is this card sufficient to get started on the self-service TOTP reset? If not, feel free to edit or create a new card.

Related issue: #1317

Status: shibboleth id deployed in dev, but there is still a configuration issue making the cg IDP not functional. I am tracking this down.

I think this is just waiting on cloud-gov/cg-uaa-extras#152


[WIP] Arrow table importer for reading CSV and Parquet

@alexbaden This is where we stopped yesterday

@alexbaden Now it calls to Arrow reader but still not filling chunk_index_

https://github.com/omnisci/omniscidb/pull/416 replaces this PR


Maybe center the speed plugin controls?

The left and right side of the bottom panel seem to be quite crowded already, and the right side is disturbed by popping HD icon, so perhaps...the playback speed controls could be centered?

@Netherdrake TBH, given there's so little space in there, and the fact we'll open source this, it might be better that we show this in the upper right corner of the video (if possible).


Deploy failed due to stacks circular dependency

When I update the INFRA_STACK's VPC. The cdk deploy failed. It reports an export name in INFRA_STACK is dependent by JOB_STACK, so INFRA_STACK can't be updated unless JOB_STACK is updated.
However, CDK will also figure out JOB_STACK depends on INFRA_STACK, and thus a circular dependency exists.
This issue is an open issue which recorded here: https://github.com/aws/aws-cdk/issues/3414
It can be harmful to us. Since we might have hundreds of JOB_STACKS in production which depend on one INFRA_STACK. If the updates to INFRA_STACK cause all JOB_STACKS fail to update. It could be a disaster.

Another example is the security group ElasticMapReduce-Master-Private and ElasticMapReduce-Slave-Private are circular dependent, which will cause cloudformation unable to delete the vpc resource.

Duplicated with https://github.com/MoonsetJS/Moonset/issues/21


added --shell param to docker-machine env command

as after moving to 1.10 client, env is not auto-detected appropriately in all situations, so this is a small patch to add the --shell=bash param to the docker-machine env call in the script

Considering "--shell" also supports cmd, powershell and emacs, doesn't this now mean it won't work in those cases? I think the Quickstart CLI that Docker Toolbox comes with is PowerShell based isn't it?

As for cmd and powershell, given that the script is for bash, it won't work
directly in windows shells, right? Not sure about emacs, though.
Interesting enough, the shell auto detection worked fine in 1.9 for me, it
is since I moved to 1.10 that I had to explicitly add the shell param to
the env command.
El mar., 15 de marzo de 2016 22:22, Nick Griffin<EMAIL_ADDRESS>escribió:

Considering "--shell" also supports cmd, powershell and emacs, doesn't
this now mean it won't work in those cases? I think the Quickstart CLI that
Docker Toolbox comes with is PowerShell based isn't it?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/Accenture/adop-docker-compose/pull/19#issuecomment-197025305

That's a very good point.


Update ADOT json validation schema

Issue #, if available: https://github.com/aws/eks-anywhere-packages/issues/786
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve

/cherrypick release-0.14


Please add collaborator as CDCgov GitHub org member

Please add the following outside collaborators (github usernames) as members of the CDCgov GitHub org so that I can add them to a GitHub team.

kant777

Sent out an invitation to github.com/cdcgov.

Kant is utc4


Intercept paste over terminal and inject using Javascript.

This is to workaround restrictions in some browsers with pasting into an iframe.

This appears to just be a Safari issue, see https://github.com/openshift-labs/workshop-terminal/issues/13

Can't fix this by intercepting using layer on top of iframe. Need to fix butterfly.


Fix typo in doc

According to your documentation (https://docs.mangopay.com/endpoints/v2.01/mandates#e230_the-mandate-object) $mandateId is a string

Hi @apetitpa , sorry for this long wait, but your update is good ! It's a string, not an int, even if we're managing only numbers today as IDs.
Thanks for contributing to our SDK :)
Mickaël


BUG: TypeError: Class extends value undefined is not a constructor or null

name: Bug report
about: Create a report to help us improve
title: 'TypeError: Class extends value undefined is not a constructor or null'
labels: ''
assignees: ''

Describe the bug
npx next dev triggers error after installing aws-amplify and @aws-amplify/ui-react:
TypeError: Class extends value undefined is not a constructor or null
    at Object.618 (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:161)
    at __nccwpck_require__ (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:11796)
    at Object.270 (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:474)
    at __nccwpck_require__ (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:11796)
    at Object.327 (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:321)
    at __nccwpck_require__ (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:11796)
    at Object.845 (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:3794)
    at __nccwpck_require__ (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:11796)
    at eval (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:11924)
    at Object.eval (/projects/nextjs-fbxtsa/node_modules/next/dist/compiled/postcss-scss/scss-syntax.js:1:11950)
    at Object.function (https://nextjs-fbxtsa.jw.staticblitz.com/blitz.7286dbe8d47d3473cde7be488b7d048fb59b05f2.js:11:19819)
    at Module._compile (https://nextjs-fbxtsa.jw.staticblitz.com/blitz.7286dbe8d47d3473cde7be488b7d048fb59b05f2.js:6:187549)
    at Object.Module._extensions..js (https://nextjs-fbxtsa.jw.staticblitz.com/blitz.7286dbe8d47d3473cde7be488b7d048fb59b05f2.js:6:187908)
    at Module.load (https://nextjs-fbxtsa.jw.staticblitz.com/blitz.7286dbe8d47d3473cde7be488b7d048fb59b05f2.js:6:185988)
    at Function.Module._load (https://nextjs-fbxtsa.jw.staticblitz.com/blitz.7286dbe8d47d3473cde7be488b7d048fb59b05f2.js:6:183564)
    at Module.require (https://nextjs-fbxtsa.jw.staticblitz.com/blitz.7286dbe8d47d3473cde7be488b7d048fb59b05f2.js:6:186304)

error Command failed with exit code 1

Link to the blitz that caused the error
https://stackblitz.com/edit/nextjs-fbxtsa?file=pages%2Findex.js
To Reproduce
Steps to reproduce the behavior:

Go to https://stackblitz.com/fork/nextjs
Ctrl-C the server
npm i aws-amplify @aws-amplify/ui-react
npm install && npx next dev

Expected behavior
I didn't change any of the code, only installed dependencies, so I expected npx next dev to work at least.
Version of webcontainer
Hash: 7286dbe8d47d3473cde7be488b7d048fb59b05f2
Desktop (please complete the following information):
Browser name  = Chrome
Full version  = 90.0.4430.93
Major version = 90
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
performance.memory = {
totalJSHeapSize: 97503413,
usedJSHeapSize: 74534329,
jsHeapSizeLimit:<PHONE_NUMBER>
}

Seems like a bug indeed, thanks for reporting 🙏

@ericclemmons if you add those packages, try and save your files (package.json + package-lock.json) and refresh the browser. I believe that should fix it. At least I was able to add the dependencies and start the project https://stackblitz.com/edit/nextjs-vwvppl?file=package.json.

I tested this again and it seems to work now. I tried adding the authenticator component and it works.

Feel free to respond or create a new issue if you run into things like this again.


Bugfix/zenko 791 quota update on put fail

Location metric is updated before a data is actually put. If put fails, metric should be decremented appropriately.

History mismatch
Merge commit #c96dd225c02850009f9bac01f0def784645e444f on the integration branch
w/8.1/bugfix/ZENKO-791-quota-update-on-putfail is merging a branch which is neither the current
branch bugfix/ZENKO-791-quota-update-on-putfail nor the development branch
development/8.1.
It is likely due to a rebase of the branch bugfix/ZENKO-791-quota-update-on-putfail and the
merge is not possible until all related w/* branches are deleted or updated.
Please use the reset command to have me reinitialize these branches.

@bert-e reset

Reset complete
I have successfully deleted this pull request's integration branches.

Waiting for approval
The following approvals are needed before I can proceed with the merge:

2 peers

Peer approvals must include at least 1 approval from the following list:

@dora-korpar

@RachedBenMustapha

@rahulreddy

Integration data created
I have created the integration data for the additional destination branches.

this pull request will merge bugfix/ZENKO-791-quota-update-on-putfail into
development/8.0
w/8.1/bugfix/ZENKO-791-quota-update-on-putfail will be merged into development/8.1 (pull request #1450)

The following branches will NOT be impacted:

development/6.4
development/7.4

Follow integration pull requests if you would like to be notified of
build statuses by email.

History mismatch
Merge commit #7f6f2c3ddedd5fcfeb2ba14dd6cb3d9c95c079d2 on the integration branch
w/8.1/bugfix/ZENKO-791-quota-update-on-putfail is merging a branch which is neither the current
branch bugfix/ZENKO-791-quota-update-on-putfail nor the development branch
development/8.1.
It is likely due to a rebase of the branch bugfix/ZENKO-791-quota-update-on-putfail and the
merge is not possible until all related w/* branches are deleted or updated.
Please use the reset command to have me reinitialize these branches.

In the queue
The changeset has received all authorizations and has been added to the
relevant queue(s). The queue(s) will be merged in the target development
branch(es) as soon as builds have passed.
The changeset will be merged in:

:heavy_check_mark: development/8.0

:heavy_check_mark: development/8.1

The following branches will NOT be impacted:

development/6.4
development/7.4

There is no action required on your side. You will be notified here once
the changeset has been merged. In the unlikely event that the changeset
fails permanently on the queue, a member of Release Engineering will
contact you to help resolve the matter.
IMPORTANT
Please do not attempt to modify this pull request.

Any commit you add on the source branch will trigger a new cycle after the
current queue is merged.
Any commit you add on one of the integration branches will be lost.

If you need this pull request to be removed from the queue, please contact a
member of Release Engineering now.

I have successfully merged the changeset of this pull request
into targetted development branches:

:heavy_check_mark: development/8.0

:heavy_check_mark: development/8.1

The following branches have NOT changed:

development/6.4
development/7.4

Please check the status of the associated issue ZENKO-791.
Goodbye dora-korpar.


Avoid to do one request per small group of entities to retrieve their labels

Should increase the speed for Primary Sources
Also simplifies a bit the code

Merged, thanks for the PR :-)


Fixed #22276 -- Surfaced ValidationError to end-user if management form is invalid

This change was accepted as part of https://code.djangoproject.com/ticket/22276

Closing due to inactivity. Please send a new PR if someone can continue work on this.


Add logging for backing parameters

I've given this PR a little bit of thought and perhaps there is a relatively easy solution that avoids committing to a json structure in the plugin: std::multimap


[Feature request] CallComposite features should be disabled if they are not available

What feature are you requesting?
It would be great if the CallComposite (of full UI SDK) could implement graceful degradation or progressive enhancement principles. It can be confusing for the end-user when features are not working, due to device or browser limitations.
Think of;

Disable screen sharing button when user is using mobile (iOS / Android)
Disable speaker picker in pre-join screen when not available (iOS / Android (?))
and perhaps more that I couldn't think of yet.

What would be the benefit of adding this feature?
Currently the button is visible and enabled which confuses users and developers. They think this is a feature that is supported, where it is not supported (which is already documented).
What solution would be ideal for you?
Best would be if the SDK / CallComposite could detect if screen sharing is possible in the users browser, and enable/disable accordingly. However, I am not sure if it is possible to detect this programmatically.
What alternatives have you considered?
n/a
Is there any additional information for your request?
CallComposite is currently not used by my customer case, since we require other modifications. And in the end, screen sharing should not be possible by the guest, thus this will be disabled entirely. However we faced this and I can imagine that this is problematic for other customers eventually.
Attach screenshots or images add detail to your request:

I fully support this idea. Out of interest do you think we should hide functionality like this when unavailable on certain devices, show the button/feature as greyed out (or equivalent), or when interacted with present an informational with something like: "this feature is not available on your device". (+ @alkwa-msft @ddematheu2).
As a note specifically for detecting screenshare availability we should be able to use this API: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia

Out of interest do you think we should hide functionality like this when unavailable on certain devices, show the button/feature as greyed out (or equivalent), or when interacted with present an informational with something like: "this feature is not available on your device".

I wasn't sure about this one, thus I hope that a UI/UX designer wants to think about this. 😃
If the feature is greyed out, it would make sense to show a tooltip / message that this functionality is not supported on the current device. However, having all those disabled features could clutter the interface a lot, especially on mobile.

Personally, I'd like to programatically remove features also. In my use case there are certain times that I don't even want screen-sharing as an option. But all the buttons have the same css class.

Personally, I'd like to programatically remove features also. In my use case there are certain times that I don't even want screen-sharing as an option. But all the buttons have the same css class.

This is something that I would love as well for the CallComposite. Perhaps best to log this as a new issue @leijae?

I have added both enhancements as feedback to our backlog.


feat: add Array.head method

prelude to slicing on axis 0

@douglasdavis , I reckon this is a pretty easy one to allow in quickly. I don't know how effective it would be at culling massive graphs, but extra work on that doesn't belong here.

yep looks good to me!

Codecov Report

Merging #270 (29ab15b) into main (97286b2) will increase coverage by 0.03%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #270      +/-   ##
==========================================
+ Coverage   94.54%   94.57%   +0.03%
==========================================
  Files          19       19
  Lines        2200     2214      +14
==========================================
+ Hits         2080     2094      +14
  Misses        120      120

Impacted Files
Coverage Δ

src/dask_awkward/lib/__init__.py
100.00% <100.00%> (ø)

src/dask_awkward/lib/core.py
91.53% <100.00%> (+0.08%)
:arrow_up:

src/dask_awkward/lib/inspect.py
93.54% <100.00%> (+1.88%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@douglasdavis , added an attempt at mocking a materialised layer for axis 0 slicing, which makes column optimisations pass. It's probably brittle! We should come up with a set of tests first, then fix problems. This will also apply to repartition, though.
Also, we need to decide whether head() and sample() should be dak functions only, as @jpivarski suggested, or if we keep one or both as they are. I think having them as functions is fine, but there is an argument for head() (only) as a method also.

@douglasdavis , added an attempt at mocking a materialised layer for axis 0 slicing, which makes column optimisations pass. It's probably brittle! We should come up with a set of tests first, then fix problems. This will also apply to repartition, though.

great! I'll take a look and test it out

Also, we need to decide whether head() and sample() should be dak functions only, as @jpivarski suggested, or if we keep one or both as they are. I think having them as functions is fine, but there is an argument for head() (only) as a method also.

I think we decided to make head a method (the precedent set by dataframe is huge here). I would argue that sample should probably be treated in the same way (pandas.DataFrame.sample being a method); though NumPy does have a function for random sampling (numpy.random.choice)

assert 0.3 < (len(arr) / len(daa)) < 0.7 - I should calculate what the actual chance of this failing is, since it's using random probabilities. Perhaps even better, I should change sample() to allow to set the numpy random seed? I'm not sure that will work when the tasks can be running simultaneously.

(when this is in, repartition should use the same mock)

I know there exists a sphinx plugin to handle this- I'd like to eventually get all sphinx types from the typehints, it's just not high on my todo list right now :)

Do you have anything else in mind for this PR or good to go?

Do you have anything else in mind for this PR or good to go?

I feel like the mock will need revisiting, but maybe we can make more extensive test cases for it out of real workflows after merging. I don't have a clear idea of how it can be improved now, since I don't know how it will break.


feat: show holder_count in ckb_hodl_wave chart

By observing on the Charts page, the coordinate color on the left of CKB HODL Wave is different from other coordinates, which can be unified here.
In terms of color, 24h and holder count are the same color. It is better to use different colors to distinguish them.
Compared to 1d-1w, 1w-1m or 1m-3m, the line widths of 24h and holder count are larger than them and can be kept consistent with other line widths.

By observing on the Charts page, the coordinate color on the left of CKB HODL Wave is different from other coordinates, which can be unified here.
In terms of color, 24h and holder count are the same color. It is better to use different colors to distinguish them.
Compared to 1d-1w, 1w-1m or 1m-3m, the line widths of 24h and holder count are larger than them and can be kept consistent with other line widths.
cc @Sven-TBD

@Sven-TBD please check


#2142, another case didn't fixed before

Fixes #2142.

Pull Request Test Coverage Report for Build 8459

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 60.837%

Totals

Change from base Build 8457:
0.0%

Covered Lines:
8283

Relevant Lines:
13615

💛  - Coveralls


The cost of small modules

I've seen rumblings of the-cost-of-small-modules as related to webpack growing in recent months.
The TL;DR is high file size and runtime cost of webpack's module scaffolding.

chart of file size per number of modules

runtime cost per number of modules

I'm wondering if there's a plan for a plugin or feature to address these issues.

Related: https://github.com/webpack/webpack/issues/2425#issuecomment-216121041

Yeah, this is definitely something we want to address. I've ran some experiments and it seem to be possible. The most difficult part of the process is the var renaming and inlining. I hope we can work together with @Rich-Harris and integrate the rollup core to do the heavy lifting.
This will be one important thing we'll do after the webpack 2 release. We concentrate on documentation and bug fixing first.

@jdalton nice article! I'd also be interested in a real-world example with webpack v2 and tree shaking on large projects. It should improve exec time when dead code is eliminated from the bundle?

@acidicX Yes, it was just v1, but Nolan Lawson wrote the article.

@acidicX I didn't write the post, @nolanlawson did.

@jdalton First.

@acidicX Yep, in the benchmark I didn't focus on tree-shaking because I wanted to isolate the cost of modules in non-dead code. Up to now I found everyone had been focusing on the tree-shaking aspects of Rollup, whereas to me the scope-hoisting was the really exciting part. :smiley:

I previously noted elsewhere that Webpack 2 can produce significantly less efficient bundles compared to Webpack 1 in some cases.
Apart from switching to scope-hoisting (which would likely require a very large development effort), there are a few areas where we could likely make small improvements in the short-term.
I've specifically noticed that transpiled ES6 modules can produce an awful lot of boilerplate code.

Take a fairly simple module:
import angular from 'angular';
import moment from 'moment';

export default angular.module('foo', [])
.run(function(){
    window.foo = moment();
});

Even without considering the weight of the external dependencies, it's evident that the ES6 transpilation process adds an incredible amount of bloat, particularly when dealing with default exports and imports:
webpackJsonp([1],{

/***/ 103:
/***/ function(module, exports, __webpack_require__) {

	/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0_angular__ = __webpack_require__(1);
	/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0_angular___default = __WEBPACK_IMPORTED_MODULE_0_angular__ && __WEBPACK_IMPORTED_MODULE_0_angular__.__esModule ? function() { return __WEBPACK_IMPORTED_MODULE_0_angular__['default'] } : function() { return __WEBPACK_IMPORTED_MODULE_0_angular__; }
	/* harmony import */ Object.defineProperty(__WEBPACK_IMPORTED_MODULE_0_angular___default, 'a', { get: __WEBPACK_IMPORTED_MODULE_0_angular___default });
	/* harmony import */ var __WEBPACK_IMPORTED_MODULE_1_moment__ = __webpack_require__(0);
	/* harmony import */ var __WEBPACK_IMPORTED_MODULE_1_moment___default = __WEBPACK_IMPORTED_MODULE_1_moment__ && __WEBPACK_IMPORTED_MODULE_1_moment__.__esModule ? function() { return __WEBPACK_IMPORTED_MODULE_1_moment__['default'] } : function() { return __WEBPACK_IMPORTED_MODULE_1_moment__; }
	/* harmony import */ Object.defineProperty(__WEBPACK_IMPORTED_MODULE_1_moment___default, 'a', { get: __WEBPACK_IMPORTED_MODULE_1_moment___default });

	/* harmony default export */ exports["default"] = /* harmony import */__WEBPACK_IMPORTED_MODULE_0_angular___default.a.module('foo', []).run(function () {
	    window.foo = /* harmony import */__WEBPACK_IMPORTED_MODULE_1_moment___default.a.bind()();
	});

/***/ }

},[103]);

Sadly, Uglify can't improve on this much:
webpackJsonp([ 1 ], {
    103: function(e, n, t) {
        var o = t(1), u = o && o.__esModule ? function() {
            return o["default"];
        } : function() {
            return o;
        };
        Object.defineProperty(u, "a", {
            get: u
        });
        var r = t(0), f = r && r.__esModule ? function() {
            return r["default"];
        } : function() {
            return r;
        };
        Object.defineProperty(f, "a", {
            get: f
        }), n["default"] = u.a.module("foo", []).run(function() {
            window.foo = f.a.bind()();
        });
    }
}, [ 103 ]);

It seems like there are some targeted optimizations that we can make around modules that only have a single export.

@schmod can you add rollup to your examples just for comparison?

It's not an apples-to-apples comparison.  Rollup doesn't provide a module system of its own, and instead asks if we want to target AMD, CJS, UMD, ES6, or an IIFE.
If we only have a single chunk, and no external dependencies (like the CommonsChunkPlugin I used to separate Angular and Moment from my "application" in the above example), this doesn't matter.
In fact, if you only have a single chunk, there are few benefits of having a module system at runtim at all.  In this situation, Rollup's approach is clearly superior.
If we do want to have multiple chunks, asynchronous loading, and many of the other things that Webpack provides, we still need a module system, and things get a lot more complicated.  It's less obvious as to how we can take advantage of rollup's scope-hoisting without adding any unnecessary overhead at runtime.
tl;dr; Rollup and Webpack have substantially different purposes

That being said, while a direct comparison isn't possible, Rollup handles ES6 modules more efficiently, even without scope-hoisting.
If rollup treats our libraries as opaque external dependencies, and targets CJS, we get a reasonably efficient bundle:
'use strict';

function _interopDefault (ex) { return (ex && (typeof ex === 'object') && 'default' in ex) ? ex['default'] : ex; }

var angular = _interopDefault(require('angular'));
var moment = _interopDefault(require('moment'));

var index = angular.module('foo', [])
.run(function(){
    window.foo = moment();
});

module.exports = index;

In this example, _interopDefault is only declared once, and Rollup is smart enough to map export default to module.exports for my own module.  The generated sources can be minified efficiently.
_interopDefault is really only useful when importing ES6 modules, but Rollup doesn't know it's unnecessary, because Angular and Moment are completely opaque to Rollup in this configuration.
If I want to dispense with a "real" module system entirely, Rollup can generate an IIFE that imports Angular and Moment from the global scope:
var myMod = (function (angular,moment) {
'use strict';

angular = 'default' in angular ? angular['default'] : angular;
moment = 'default' in moment ? moment['default'] : moment;

var index = angular.module('foo', []).run(function () {
    window.foo = moment();
});

return index;

}(angular,moment));

The resulting bundle is (surprisingly) a bit less efficient, as there's no reusable _interopDefault function.  Otherwise, the resulting bundle can be minified efficiently.
"use strict";
function e(e) {
    return e && "object" == typeof e && "default" in e ? e["default"] : e;
}
var n = e(require("angular")), t = e(require("moment")), o = n.module("foo", []).run(function() {
    window.foo = t();
});
module.exports = o;

If we want Rollup to behave a little more like Webpack, the node-resolve and commonjs plugins can be used to pull our external modules into a single bundle.
var myMod = (function () {
'use strict';

var commonjsGlobal = typeof window !== 'undefined' ? window : typeof global !== 'undefined' ? global : typeof self !== 'undefined' ? self : {}

function interopDefault(ex) {
	return ex && typeof ex === 'object' && 'default' in ex ? ex['default'] : ex;
}

function createCommonjsModule(fn, module) {
	return module = { exports: {} }, fn(module, module.exports), module.exports;
}

// rollup dumps entire source of angular.js here...

var index$1 = createCommonjsModule(function (module) {
module.exports = angular;
});

var angular$1 = interopDefault(index$1);

var moment = createCommonjsModule(function (module, exports) {

// and the source of moment gets dumped in here.

});

var moment$1 = interopDefault(moment);

var index = angular$1.module('foo', [])
.run(function(){
    window.foo = moment$1();
});

return index;

}());

The result is a lot less efficient (1.32MB).  Angular is packaged as weird pseudo-IIFE, while Moment is packaged as a UMD module.  Rollup creates a few helper functions to deal with these things.
This is the worst-of-all-worlds scenario – we've got the overhead of a module system, with none of the benefits.
This reveals one of the key drawbacks of Rollup -- only native ES6 sources benefit from tree-shaking and scope-hosting.  Even though Moment is written with ES6 modules, it's bundled into a UMD module for NPM.
An apples-to-apples size comparison is particularly difficult in this scenario, because Webpack greedily bundles all of Moment's locale files (via a dynamic require()), and produces a huge 1.7MB bundle. See https://github.com/moment/moment/issues/1435) for some context.
Rollup doesn't know how to handle this, and silently ignores the require() in Moment's source (which seems less-than-ideal).

If I use the bundle-loader plugin to mitigate this, the resulting bundle is 1.41MB;  only about 10KiB larger than the equivalent Rollup bundle (most of which is occupied by the huge manifest that bundle-loader jams into the main bundle):
/* 5 */
/***/ function(module, exports, __webpack_require__) {

	var map = {
		"./af.js": 6,
		"./ar-ma.js": 8,
		"./ar-sa.js": 10,
		"./ar-tn.js": 12,
....

Plus one of these for each locale:
/***/ },
/* 6 */
/***/ function(module, exports, __webpack_require__) {

	var cbs = [],
		data;
	module.exports = function(cb) {
		if(cbs) cbs.push(cb);
		else cb(data);
	}
	__webpack_require__.e/* nsure */(1, function(require) {
		data = __webpack_require__(7);
		var callbacks = cbs;
		cbs = null;
		for(var i = 0, l = callbacks.length; i < l; i++) {
			callbacks[i](data);
		}
	});

It's a larger bundle than Rollup, and it seems like there are opportunities to make bundle-loader (a lot) more efficient in this kind of scenario.  However, this kind of dynamic loading isn't easily achievable with Rollup, whereas Webpack supports it extensively.

But, wait.  Wasn't Moment written with native ES6 modules?  Rollup can take advantage of that by enabling jsnext:main support in rollup.config.js:
plugins: [ json(), nodeResolve({ jsnext: true }), cjs({ exclude: ['node_modules/moment/**'] }) ],

With this configuration Rollup hoists all of Moment's internals into the same scope as our main application, and produces a bundle that's a whopping 2KB smaller (1.30MB).
Note that I had to explicitly tell rollup's CJS plugin not to process Moment's sources, because it wasn't smart enough to identify Moment's jsnext:main entry as an ES6 module.  Also, locales aren't included in the bundle.

Wait.  Can Webpack 1 take advantage of ES6 sources?
Kind of.
If I allow babel-loader to process my node_modules folder, and include moment via import moment from 'moment/src/moment', Webpack packages Moment by bundling its ~100 modules individually, and produces a 1.45MB bundle.
The same configuration with import moment from 'moment' produces a 1.41MB bundle.
So, where does that leave us?
My example primarily shows how Webpack and Rollup behave when importing large external libraries from NPM.  In many ways, it is a contrived example that does not demonstrate the good features of Rollup or Webpack.
Among other things, I didn't import any of my own sources, and the two libraries I used both happen to publish pre-bundled sources to NPM.
In practice, most users are going to be importing lots of their own modules, and a small handful of external libraries.  In this scenario, the advantages of Rollup are more evident, as there is virtually no cost associated with splitting my own source code into lots of small files.  There would be a similar advantage when importing "native" CJS modules from NPM.
On the other hand, working with external libraries in Rollup was far from straightforward.  Few existing libraries are written in ES6 to take advantage of tree-shaking, and I needed to explicitly remind Rollup's CJS preprocessor to ignore Moment's ES6 sources.  The reward for all of this effort was underwhelming -- while Moment's written with ES6 modules, it doesn't expose an API that benefitted at all from tree-shaking.  jsnext:main isn't standardized, and Rollup fails to offer a good solution for dynamic loading.
However, a few of the advantages that Rollup demonstrated could be easily incorporated into Webpack 2 without major architectural changes:

Reusable ES6 helper methods (Webpack generates these for each module -- they could very easily be hoisted into a higher scope to promote reuse).

May be related to https://github.com/babel/babel-loader/issues/231 -- including transform-runtime appears to result in more helpers being generated; not less.
The specific issues with Webpack 1 and _interopRequireDefault appear to be a Babel issue.

No unnecessary ceremony around export default when a module only has one export.
Generated modules and helper methods can be minified efficiently (without sacrificing readability of the unminified code).  Webpack adds property names like __esModule and default, which cannot be effectively minified without providing hints to the minifier.
Bonus: Optimize bundle-loader – it's staggeringly inefficient.

Before resorting to scope-hoisting, there are also other small optimizations that could be done -- if a module is only used once, it can likely be safely inlined into the consuming module's scope as an IIFE (or similar).

I also haven't investigated runtime performance.  @nolanlawson clearly demonstrated that Webpack has a surprising amount of runtime overhead.  It seems unlikely that any of the small tweaks that I discuss will have much impact in this area.
It's also worth noting that a large application built with Rollup will have a relatively "flat" lexical scope hierarchy (with one extremely crowded layer).  I'd be interested to see some investigation into how well modern JS engines (and GC) can deal with that.
My concerns may be unwarranted, but it's possibly worth considering the implications of putting thousands of variables into a single scope.

Apologies for the rambling deep-dive.  Investigating this has been fairly enlightening!

So, after posting that, I decided to investigate whether or not Webpack 2's improved since beta.6.

why didn't I do that first.  [facedesk]

The good news is that most of my concerns have been addressed.
Using the same example as previously, Webpack 2.1.0-beta.21 generates the following bundle:
webpackJsonp([0],{

/***/ 106:
/***/ function(module, exports, __webpack_require__) {

"use strict";
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0_angular__ = __webpack_require__(1);
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0_angular___default = __webpack_require__.n(__WEBPACK_IMPORTED_MODULE_0_angular__);
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_1_moment__ = __webpack_require__(0);
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_1_moment___default = __webpack_require__.n(__WEBPACK_IMPORTED_MODULE_1_moment__);

/* harmony default export */ exports["default"] = __WEBPACK_IMPORTED_MODULE_0_angular___default.a.module('foo', []).run(function () {
    window.foo = __WEBPACK_IMPORTED_MODULE_1_moment___default()();
});

/***/ }

},[106]);

Putting it all together, in the "basic" example, Webpack 1 produces a 1.7MB bundle, and Webpack 2 produces a 1.66MB bundle.
Yawn.

Things are more interesting when we import Moment via ES6 (because that creates lots of modules) and minify the output.

Bundler
transform-runtime
Unminified
Minified
Min + gz

Webpack 1.13.2
yes
1.48MB
264KB
83KB

Webpack 1.13.2
no
1.45MB
245KB
78KB

Webpack 2.1.0-beta-21
yes
1.51MB
243KB
81KB

Webpack 2.1.0-beta-21
no
1.45MB
226KB
76KB

Rollup 0.34.10
no
1.27MB
212KB
73KB

Rollup 0.34.10
yes
1.27MB
212KB
73KB

There are no huge leaps forward, but it's worth noting Webpack 2 now outperforms Webpack 1 by a comfortable margin, which is a huge turnaround from the earlier betas.
Modules still have overhead, but we've trimmed most of the fat.  Including Moment via its UMD bundle is still more efficient (Moment's own internal build process uses Esperanto, which is philosophically-similar to Rollup).

The next question to answer is why transform-runtime adds so much overhead.

It might be because transform-runtime brings in slightly different babel runtimes which pull in and use corejs. The defaults ones are less strict.
In addition by default it polyfills your existing code, but that you can switch off.

Can we use source maps to our benefit here? What if we detect when they are available, and inspect those for ES2015 modules?

That was my thought too, but it doesn't seem like Rollup has a similar issue.
Digging a little further, it seems like rollup-plugin-babel actually does something similar to transform-runtime to provide and hoist the babel helpers.
However, unlike tranform-runtime, it doesn't appear to bring in core-js.  In my example above, transform-runtime patched in the polyfills for some fairly well-supported ES5 features like Object.keys(), which likely accounts for a lot of the extra heft.

transform-runtime will use core-js in library mode, which does not polyfill anything. It's essentially a complete separate copy of core-js, and the transform changes your code that calls, say, Object.keys(), to (essentially) call require('core-js/library/fn/object/keys')() instead.
AFAIK, if you polyfill at all, it's recommended to not use transform-runtime (or babel-runtime) in browser code, but babel-polyfill.

transform-runtime will use core-js in library mode, which does not polyfill anything.

Incorrect usage of "polyfill" on my part -- you are correct.

AFAIK, if you polyfill at all, it's recommended to not use transform-runtime (or babel-runtime) in browser code, but babel-polyfill.

Babel's documentation about this particular issue is SUPER VAGUE, so it's unclear what's currently recommended.
babel-loader specifically recommends transform-runtime, even though my tests show it actually makes things worse in many cases (which I assumed this was due to https://github.com/babel/babel-loader/issues/231 or babel/T7285).
rollup-plugin-babel implicitly does something similar to external-helpers, and consolidates all (used) helpers in a parent scope.  It may be possible to adapt the same concept into babel-loader.

That being said, I think we should move the module overhead conversation out of this ticket (possibly reopening #2425), and focus this discussion around bringing rollup-style scope-hoisting and merging to Webpack.
I'm curious about what @sokra has in mind, because it seems like this would require us to radically change the way that Webpack reasons about modules.

I'm curious about what @sokra has in mind, because it seems like this would require us to radically change the way that Webpack reasons about modules.

@schmod Spot on. Last week we discussed the first steps were to simply add public api hooks to allow eliding of modules. (Which would then help make this possible).

please apologize my ignoring, i dont understand: what this issue mean, plan to have rollup in webpack ?

@sokra you mentioned this being possible. When you say possible are you talking about one or the other (Inlining vs module privacy)? Or is there a potential to be able to leverage both in the same project?
Also, if you have any initial thoughts/findings on being able to leverage rollup core it'd be great to hear what you discovered.

We are referring to leverage the same scope collapsing techniques.
The Chunk class in our source has the ability to split modules however we don't have functionality to combine modules (which would be along the lines of how we would accomplish this feature).
Some techniques that we would either implement or leverage from rollup would involve variable name deconflicting. Also there has been some research from the ember team which I met with last month ( @runspired @stefpenner ) and learned that browser engines favor more mixed scenario (not all rolled up into one module), rather the most commonly used modules rolled with edge modules in separate module wrappers in a webpack bundle. Hopefully this answers some questions.

I realize this is largely unrelated, being a development time concern, but even with the recent improvements, the sheer textual bloat of the development bundles Webpack 2.2.0-rc.3 emits is a massive pain.
The following is the '@angular/core' exports section from an unoptimized Angular 2 bundle
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Class", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["a"]; });
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__src_core__ = __webpack_require__(542);
/* harmony reexport (binding) */ __webpack_require__.d(exports, "createPlatform", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["b"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "assertPlatform", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["c"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "destroyPlatform", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["d"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "getPlatform", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["e"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "PlatformRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["f"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ApplicationRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["g"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "enableProdMode", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["h"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "isDevMode", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["i"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "createPlatformFactory", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["j"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "NgProbeToken", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["k"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "APP_ID", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["l"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "PACKAGE_ROOT_URL", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["m"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "PLATFORM_INITIALIZER", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["n"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "APP_BOOTSTRAP_LISTENER", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["o"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "APP_INITIALIZER", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["p"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ApplicationInitStatus", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["q"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "DebugElement", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["r"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "DebugNode", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["s"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "asNativeElements", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["t"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "getDebugNode", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["u"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Testability", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["v"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "TestabilityRegistry", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["w"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "setTestabilityGetter", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["x"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "TRANSLATIONS", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["y"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "TRANSLATIONS_FORMAT", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["z"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "LOCALE_ID", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["A"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ApplicationModule", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["B"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "wtfCreateScope", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["C"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "wtfLeave", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["D"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "wtfStartTimeRange", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["E"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "wtfEndTimeRange", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["F"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Type", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["G"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "EventEmitter", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["H"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ErrorHandler", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["I"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationTransitionEvent", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["J"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationPlayer", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["K"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Sanitizer", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["L"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "SecurityContext", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["M"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ANALYZE_FOR_ENTRY_COMPONENTS", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["N"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Attribute", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["O"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ContentChild", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["P"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ContentChildren", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["Q"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Query", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["R"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ViewChild", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["S"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ViewChildren", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["T"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Component", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["U"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Directive", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["V"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "HostBinding", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["W"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "HostListener", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["X"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Input", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["Y"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Output", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["Z"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Pipe", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_0"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AfterContentChecked", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_1"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AfterContentInit", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_2"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AfterViewChecked", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_3"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AfterViewInit", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_4"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "DoCheck", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_5"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "OnChanges", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_6"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "OnDestroy", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_7"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "OnInit", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_8"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "CUSTOM_ELEMENTS_SCHEMA", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_9"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "NO_ERRORS_SCHEMA", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_10"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "NgModule", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_11"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ViewEncapsulation", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_12"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Version", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_13"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "VERSION", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_14"]; });
Object.defineProperty(exports, "__esModule", { value: true });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "forwardRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_15"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "resolveForwardRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_16"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Injector", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_17"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ReflectiveInjector", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_18"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ResolvedReflectiveFactory", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_19"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ReflectiveKey", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_20"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "OpaqueToken", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_21"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Inject", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_22"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Optional", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_23"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Injectable", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_24"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Self", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_25"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "SkipSelf", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_26"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Host", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_27"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "NgZone", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_28"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "RenderComponentType", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_29"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Renderer", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_30"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "RootRenderer", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_31"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "COMPILER_OPTIONS", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_32"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "Compiler", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_33"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "CompilerFactory", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_34"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ModuleWithComponentFactories", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_35"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ComponentFactory", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_36"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ComponentRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_37"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ComponentFactoryResolver", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_38"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ElementRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_39"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "NgModuleFactory", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_40"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "NgModuleRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_41"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "NgModuleFactoryLoader", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_42"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "getModuleFactory", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_43"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "QueryList", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_44"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "SystemJsNgModuleLoader", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_45"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "SystemJsNgModuleLoaderConfig", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_46"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "TemplateRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_47"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ViewContainerRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_48"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "EmbeddedViewRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_49"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ViewRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_50"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ChangeDetectionStrategy", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_51"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "ChangeDetectorRef", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_52"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "CollectionChangeRecord", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_53"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "DefaultIterableDiffer", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_54"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "IterableDiffers", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_55"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "KeyValueChangeRecord", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_56"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "KeyValueDiffers", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_57"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "SimpleChange", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_58"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "WrappedValue", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_59"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "platformCore", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_60"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "__core_private__", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_61"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AUTO_STYLE", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_62"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationEntryMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_63"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationStateMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_64"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationStateDeclarationMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_65"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationStateTransitionMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_66"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_67"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationKeyframesSequenceMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_68"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationStyleMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_69"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationAnimateMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_70"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationWithStepsMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_71"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationSequenceMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_72"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "AnimationGroupMetadata", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_73"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "animate", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_74"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "group", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_75"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "sequence", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_76"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "style", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_77"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "state", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_78"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "keyframes", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_79"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "transition", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_80"]; });
/* harmony reexport (binding) */ __webpack_require__.d(exports, "trigger", function() { return __WEBPACK_IMPORTED_MODULE_0__src_core__["_81"]; });

This all gets compressed decently with uglify for production but, as part of a 5-10MB development bundle, it makes the browser grind to a halt as soon as a breakpoint is hit, lagging for over 10 seconds on a powerful workstation.

Yes we all want all want to leave in a better, more caring and less discordant JavaScript world where Node and the Browser learn to love each other, so I appreciate Webpack 2's asserted desire to be in harmony 😃 and embrace ES Modules but would you consider removing the /* harmony reexport (binding) */ and maybe using a shorter and less obnoxious prefix than __WEBPACK_IMPORTED_MODULE_ 😄?

So there is rollup-loader now, isn't it a solution?

any news on this ? I use cli and they let me know it depend on webpack team, any news about having rollup tree shaking instead uglify or some optomisation todo better

@istiti Scope hosting is in plans for webpack 2 see https://webpack.js.org/vote/. Tree shaking is already implemented for webpack 2.

@mantastrunce and what mean "is in plans" any project board ? because here I can't find https://github.com/webpack/webpack/projects

@NekR rollup loader doesn't seem to do scope hoisting, it does appear to do rollup's more aggressive tree shaking though.
@mantastrunce Webpack 2 relies in large part on uglify to drop unused variables. For modules containing a class that uses this, uglify will not remove it.
// export and dead code module

// export used elsewhere
export function a () {
  console.log('a called')
}

// Dropped by rollup but not by uglify because of `this` usage
const oldStyleClass = function (b) {
  return {
    b,
    c: this.b + 1
  }
}

One could argue thorough linting will catch the second case, unless you're dealing with sub-par code generation from a compiled to JS language.

@wegry
// Dropped by rollup but not by uglify because of `this` usage
const oldStyleClass = function (b) {
  return {
    b,
    c: this.b + 1
  };
}

One could argue thorough linting will catch the second case, unless you're dealing with sub-par code generation from a compiled to JS language.

Or one could argue that a better solution would be to simply avoid using this and by extension, avoid using classes except where mandated by frameworks.
Classes have introduced exponential complexity and confusion to JavaScript while at the same time being, themselves, so fundamentally weak (not supporting multiple inheritance or declarative metadata) as to necessitate even more complexity just to make them a half way viable construct.
Factory patterns are preferable for so many reasons and yet we in the JavaScript world have become addicted to an a class feature that is pales in comparison to the classes provided by other languages while having had better alternatives in JavaScript for almost 2 decades.
What I dislike most about classes, which by the way can be a very elegant for some specific scenarios, is having to explain to people learning the language over and over and over and over, again that classes are not types.

@aluanhaddad You could shorten __WEBPACK_IMPORTED_MODULE_ using a simple plugin like this.

@andraaspar I appreciate the suggestion and my comment was meant to be playful, but with 24GB of tri-channel DDR@1334 (7-7-7-1T), 8 logical<EMAIL_ADDRESS>and a 1TB SSD I should be OK by default.

@aluanhaddad All that matters is a single core running at 3.2 GHZ, since Webpack by default runs on one thread (and by extension, can only be used on a single core).
If you want to take advantage of all those cores, check out https://github.com/amireh/happypack
Or start diving into the shared memory spec and think about how Webpack can get it natively :)

Hope this will be better. When I build my project with angular-cli, it blocking at 92%  of building and the rest of time is due to webpack bundle process which takes 70% of total time.
1mn angular compiler
2mn webpack bundle Uglify i think.
Cc @TheLarkInn

@aluanhaddad Not so much speed, rather than legibility of the compiled code is the issue. I get a lot of 200 character lines with bloat for no good reason.

@avindra that's an excellent point. Although some plugins, like awesome-typescript-loader, at times fork children, your point is well taken.
@andraaspar indeed, that is part of the issue.
@istiti I'm not talking about bundling speed. I am talking about the size of the development bundle. Webpack creates the bundle quite quickly and rebuilds are also very fast. The only complaint is the quantity of seemingly arbitrary text that it contains, specifically as relates to tools such as browser debuggers and editors.

fixed by Scope Hosting. See also https://medium.com/webpack/webpack-freelancing-log-book-week-5-7-4764be3266f5
Runtime and Size is now ~ rollup values plus 10ms and 500b (5000 modules, on mobile). We still include the runtime, that the difference.

@sokra awesome! I read your post and it looks like it'll help a lot for modules that depend on a lot of little things but have a single export. But what about the lodash case, where the main chunk may be importing a ton of tiny modules which live in a separate vendor chunk? I think there will still be a lot of overhead there.

My english is poor... in summary does webpack tree shake  as rollup now?!?

@istiti as of webpack 2 it already did, this is something else.

I'm guessing this might improve tree shaking if you have a module imported
that is then used depending on a build flag - being in the same scope gives
uglify a chance to remove it.

@elyobo maybe treeshaking is already here but not improved as rollup thats why I ask


fix python condition in example @ home.ts

Isabela & other spellings is a name ;)
Haven't tested.

Thanks Tom! You're right, but I wanted to keep the example simple.


response.json() is failing enconding for non ascii characters

Summary.
I'm executing a simple GET request with a list of data. But the .json() fails because there's a non ascii character and it can't encode it.
Expected Result
[
{
"key": "value"
}
]
Actual Result
*** UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 329: ordinal not in range(128)
Reproduction Steps
Try to pass this type of character (In this case is the "ü") in a request and then try to convert the response to json using response.json()
import requests

response = requests.request("GET", ulr, headers=headers)
response.json()

System Information
$ python -m requests.help

{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.2"
  },
  "platform": {
    "release": "3.10.0-327.13.1.el7.x86_64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.19.1"
  },
  "system_ssl": {
    "version": "1000114f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).

Requests uses the standard json library. Your alternative here is to do
json.loads(response.text)

That should exhibit exactly the same problem. This is not a bug in requests. Note that the json() method on a Response allows you to pass in extra keyword arguments. Those correspond to arguments one might pass to json.loads().


Would you be able to provide us with two .txt files?

How could I? The text files have to be specific to your training environment because they have to include the full path to the training images. Anyway the files have to look like this: In one line your have first the full path to a single image and then separated by an empty space the class number.


Update README.md

Added some documentation about Data Abstraction.
Please label this PR as hacktoberfest-accepted.
Thank you.

Sure I will do this


Make bookmarks remember state of tree

I often do :NERDTree <bookmark> then manually open the various subdirectories I want. It would be super convenient if NERDTree remembered the open/closed state of the tree when I create a bookmark so I don't have to do it myself.

+1

+1

+1

+1

+1
sad so see this must have feature is pending from almost two year :(.

+1

+1

+1

Gentlemen, I hear you and will be implementing this shortly.

You all can use this plugin: https://github.com/jistr/vim-nerdtree-tabs
It works, but also "blinks" on my configuration, but you should try to use it!

+1

+1

Hey all, I have been looking into this and have taken a stab at it here: https://gist.github.com/scrooloose/741b04b0a6dc8c69d043
Things to note:

I have called the idea "projects" instead of "bookmarks" since that is the direction they are heading in.

The concept is implemented as a nerdtree plugin at the moment. When the code/functionality stabilizes I will either add it to the core, or leave it as a plugin and hand it off to someone.

The interface is just :commands at the moment, but this may get more snazzy later according to feedback.

Currently, the only functionality that projects offer over bookmarks is remembering the state of the tree. I have other ideas and feature requests that may be implemented though.

Thoughts/feedback welcome.

For the first take my love <3
For the second it produces erros.

When I try to ":NERDTreeProjectSave test" it says to me

Error detected while processing function 243..244..250:
line    1:
E484: Can't open file /home/hshhhhh/.NERDTreeProjects
E684: list index out of range: 0
E15: Invalid expression: "let projHashes = " . readfile(s:Project.ProjectFileName())[0]
Error detected while processing function 243:
line    1:
E714: List required
Press ENTER or type command to continue

After adding a '/home/hshhhhh/.NERDTreeProjects' file it produce an another error:

Error detected while processing function 243..246..253:
line    3:
E716: Key not present in Dictionary: getDirChildren()
E15: Invalid expression: a:rootNode.getDirChildren()
Press ENTER or type command to continue

Do you have the latest version of nerdtree? (I should have mentioned that)

Do you have the latest version of nerdtree? (I should have mentioned that)

Sorry, I've just updated and it only requires to manually create the "touch ~/.NERDTreeProjects"

I can offer this use case (I will add it by myself, but not now). It will give you dynamical synchronization between tabs (I hope):

Add to .vimrc

autocmd BufNewFile,BufRead /home/user/projects/project1/* let project_name=project1

Add to NERDTree this functionality:

on_NERDTree_open or on_[tab/buffer/NERDTree]_focus_in:
if (project_name) then NERDTreeProjectLoad project_name

on_NERDTree_close or on_[tab/buffer/NERDTree]_focus_out:
if (project_name)
then NERDTreeProjectSave project_name

Also now it has a bug with autocomplete of project names:
What I do:
:NERDTreeProjectLoad t<tab>

What I get (but it works!):
:NERDTreeProjectLoad test
test  test  test
:NERDTreeProjectLoad test

OK, I have fixed 2 bugs (see latest gist):

The bug when .NERDTreeProjects didnt exist

The naming bug you mention above. In your example above there are actually 3 test projects. Instead of updating the test project, the code was creating new project (due to the bug).

RE your idea above on_NERDTree_close or on_[tab/buffer/NERDTree]_focus_out: <save project>: This effectively already happens. If you use NERDTreeProjectLoad and then unload the nerdtree buffer (by closing vim, or :bunload etc) then the project you have loaded will be saved again.
RE automatically loading projects when you enter the root (or by some similar condition): This might be a good idea. Unfortunately I have been drinking and can't think hard enough now :D

This effectively already happens. If you use NERDTreeProjectLoad and then unload the nerdtree buffer (by closing vim, or :bunload etc) then the project you have loaded will be saved again.

I want to use NERDTree this way:

open 3 tabs
open NERDTree in 1st tab and open the 4th tab with shift+t, NERDTree close himself automatically
go to 2nd tab, open NERDTree and want to see the same content as it was on 1st tab

But I've started use NERDTree with :NERDTreeFind instead of :NERDTreeToggle and it works okay for me.

If I understand you correctly, you can already use NERDTreeMirror to accomplish this. If you want one tree viewed in many tabs, this is what NERDTreeMirror is for. You will be viewing the same nerdtree buffer loaded in different windows.
Have I understood you correctly?

Have I understood you correctly?

Oh, thank you a much! It requieres to call :NERDTreeMirror before 1st time calling :NERDTreeToggle , but it  much better then nothing.
Thank you!
P.S. -- Now I realized that I posting in wrong issue topic, sorry! :(

Hey all, FYI here is the latest version of the plugin above: https://github.com/scrooloose/nerdtree-project-plugin.
Its still a WIP really - but I have been using it for a couple of weeks. Would appreciate any feedback and ideas. If all goes well, I plan to merge this into the main repo and replace bookmarks.

@scrooloose I got an error with b:NERDTree does not exist when trying to save a project, even though I do have the latest version of NERDTree installed. Does that have to do with how bundle loads up the plugins, maybe the order..? Thanks

+1. I would like this too.

+1, yes, please :(

+1 me too

any updates on this? Seems an old request

Pull Request #929 should make the nerdtree-project-plugin work properly again.

@scrooloose 's project plugin will work once again.  Then use the commands defined in it to manage your projects:

Create a project from the current nerdtree with
:NERDTreeProjectSave <name>
Load a project with
:NERDTreeProjectLoad <name>
Load a project from the current CWD
:NERDTreeProjectLoadFromCWD
Delete a project with
:NERDTreeProjectRm <name>


JSS Tracking API docs missing configuration of fetcher

Description
The JSS Tracking API docs do not document the configuration of the fetcher.
Expected behavior
Docs should demonstrate a complete example of configuring the trackingApiOptions.
Steps To Reproduce
Attempt to follow code in existing Usage docs:
https://jss.sitecore.com/docs/fundamentals/services/tracking
Assigning a fetcher is not documented but is required, and that fetcher needs to be configured to use a POST by default if provided any data.
Possible Fix
Update docs following tracker code samples that do work:
https://github.com/Sitecore/jss/blob/b41311b2aa8ed885a4d6d1d3d030da6e3496515b/samples/react/src/components/Styleguide-Tracking/index.js
Possibly reference dataFetcher sample if needed:
https://github.com/Sitecore/jss/blob/b41311b2aa8ed885a4d6d1d3d030da6e3496515b/samples/react/src/dataFetcher.js

Thanks to @joostmeijles for reporting on Slack.

There are another issue #212
Below the article - Invoking the Layout Service from JSS, we need to update fetchOptions, also by adding property fetcher, because it's required in fetchRouteData but is missed in documentation

There are another issue #212
Below the article - Invoking the Layout Service from JSS, we need to update fetchOptions, also by adding property fetcher, because it's required in fetchRouteData but is missed in documentation

@nickwesselman This doc request was done by merging #306. If you feel that additional information is needed, feel free to reopen this issue or create a new one.


Make sure there is no uninitialized variables in AsyncMockFactoryBase

This avoids scala.UninitializedFieldError when run on scala 2.12
with -Xcheckinit compiler flag.
Pull Request Checklist

[x] I agree to licence my contributions under the MIT licence
[x] I have added copyright headers to new files (no new files)
[x] I have added tests for any changed functionality (added compiler flag to build.sbt)

Fixes
Fixes #226
Purpose
Call initializeExpectations in AsyncMockFactoryBase constructor to avoid uninitialized variables.

thanks!

you should be able to use the snapshot build on sonatype to test with your code until i release 4.2 to maven central


UTP Request

Request UTP University Request

@NicoSM1108 I am sorry, the domain utp.edu.co is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


acc never change after every batch of learning(20 newsgroup dataset)

I want to see the result for LSTM on the 20 Newsgroup data.
Everything is the same as https://github.com/fchollet/keras/blob/master/examples/pretrained_word_embeddings.py
I just replace the Conv part by LSTM
`
model = Sequential() model.add(embedding_layer)
model.add(LSTM(128, dropout_W=0.2, dropout_U=0.2))
model.add(Dense(1))
model.add(Activation('sigmoid'))
model.add(Dense(len(labels_index), activation='softmax'))
model.compile(loss='binary_crossentropy',
optimizer='adam',
metrics=['accuracy'])
`
Unfortunately, for every batch processed, I got the same acc as follow:
Epoch 1/1
4384/15998 [=======>......................] - ETA: 1953s - loss: 0.1985 - acc: 0.9500
Epoch 1/1
4480/15998 [=======>......................] - ETA: 1937s - loss: 0.1985 - acc: 0.9500
Epoch 1/1
4544/15998 [=======>......................] - ETA: 1928s - loss: 0.1985 - acc: 0.9500
the acc is always 0.95.
I have no idea where went wrong.
Thank you all

The problem is that you are using a "binary_crossentropy" loss yet you are trying to do a multiclass classification.  Also, having the output dimension of your first Dense layer as 1 is probably not a good idea.  Try changing model.add(Dense(1)) to model.add(Dense(20)) (or 50) and changing model.compile(loss='binary_crossentropy',  to model.compile(loss='categorical_crossentropy,

@blucena  Thanks so much!