Alright, the PR has been landed and released on [email protected] so you should be good to go =)

Decided to just squash the commits as I don't know how the commits are merged/squashed on this repo =/

Alright, that should do it. Tested with repro repo here from original issue https://gist.github.com/twolfson/5122c4398147df6bb2bfaeb37a59997b

I'll update the commit message now with what you gave me

Also using getOwnPropertyNames as keys can iterate over prototype keys as well (which I believe we want to avoid)

Oh wow, I somehow assumed this repo was using a transpiler somehow (usually avoid them myself). Going to also drop the let to avoid browser compatibility issues

👍 Taking today off so will revisit tomorrow

On Tue, Aug 11, 2020, 9:35 AM johnjbarton [email protected] wrote:

@johnjbarton requested changes on this pull request.

The commit message first line would be like fix(adapter): filter functions from result

In src/adapter.js https://github.com/karma-runner/karma-jasmine/pull/272#discussion_r468712998 :

@@ -191,8 +191,13 @@ function KarmaReporter (tc, jasmineEnv) { // Any errors in top-level afterAll blocks are given here. handleGlobalErrors(result)

• // Remove functions from called back results to avoid IPC errors in Electron
• // https://github.com/twolfson/karma-electron/issues/47
• let cleanedOrder = Object.assign({}, result.order);

Looks like Object.assign() is not supported on IE11. https://caniuse.com/#search=object.assign

I think we could loop over Object.keys() and copy if typeof result[key] !== 'function'.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/karma-runner/karma-jasmine/pull/272#pullrequestreview-465237420, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG4KWHDEBFRUYSZBLENBVLSAFXMFANCNFSM4O3G6YRQ .

Another message from me:

It looks like livereload-js (one of the deep dependencies of gulp-livereload) had a release 9 days ago so it's likely a recent npm install broke it on you

https://www.npmjs.com/package/livereload-js

Had an issue reported via email. It should be resolved now but I'd like to persist it here:

S, Wed Aug 5, 9:33PM PST:

I would really appreciate if you could tell me what I am doing wrong. Please see my attached stack overflow question.

Using gulp-livereload with gulp-sass https://stackoverflow.com/q/63276661/13364585?sem=2

@twolfson, Wed Aug 5, 9:57PM PST:

What version of Firefox are you using and if you move backwards in your version control, does it resume working?

Also, can you find my GitHub repo fork and create an issue there? (forget if possible on forks)

S, Wed Aug 5, 10:05PM PST:

Thanks for looking into this! I have the issue with both Firefox version 79.0 as well as Firefox Developer Edition version 80.0b4 Rolling back in my version controller doesn’t seem to help. I have the same issue even if I start a new project.

@twolfson, Wed Aug 5, 10:31PM PST:

Hmm, if the issue is persisting in Firefox, even if you roll back, then my hunch is wrong but I've been holding back on upgrades for a bit so I'll give it a try tonight or tomorrow

Fwiw, my hunch was that Mozilla sent me an email today about third party iframes but you need to specifically enable Fission to test it messing with you https://wiki.mozilla.org/Project_Fission#Enabling_Fission

S, Wed Aug 5, 10:45PM PST:

Thanks! :)

@twolfson, Wed Aug 5, 11:29PM PST:

Firefox 79 works fine without issues for me. I've verified via python-livereload. Reading through your StackOverflow, it seems like something is wrong in your hosted livereload.js =/ There is a fallback variant inside of the extension but the URL for that wouldn't be :35729 (LiveReload server)

• CLI tool I'm using: https://github.com/lepture/python-livereload

• Hosted livereload.js in CLI tool: https://github.com/lepture/python-livereload/blob/v2.6.1/livereload/vendors/livereload.js

• Logic that LiveReload extension uses to determine which livereload.js to load: https://github.com/twolfson/livereload-extensions/blob/v20.3.0/src/common/injected.coffee#L45-L68

@twolfson, Wed Aug 5, 11:29PM PST:

Going to post this on GitHub for persistence

Had an issue reported via email. It should be resolved now but I'd like to persist it here:

S, Wed Aug 5, 9:33PM PST:

I would really appreciate if you could tell me what I am doing wrong. Please see my attached stack overflow question.

Using gulp-livereload with gulp-sass https://stackoverflow.com/q/63276661/13364585?sem=2

@twolfson, Wed Aug 5, 9:57PM PST:

What version of Firefox are you using and if you move backwards in your version control, does it resume working?

Also, can you find my GitHub repo fork and create an issue there? (forget if possible on forks)

S, Wed Aug 5, 10:05PM PST:

Thanks for looking into this! I have the issue with both Firefox version 79.0 as well as Firefox Developer Edition version 80.0b4 Rolling back in my version controller doesn’t seem to help. I have the same issue even if I start a new project.

@twolfson, Wed Aug 5, 10:31PM PST:

Hmm, if the issue is persisting in Firefox, even if you roll back, then my hunch is wrong but I've been holding back on upgrades for a bit so I'll give it a try tonight or tomorrow

Fwiw, my hunch was that Mozilla sent me an email today about third party iframes but you need to specifically enable Fission to test it messing with you https://wiki.mozilla.org/Project_Fission#Enabling_Fission

S, Wed Aug 5, 10:45PM PST:

Thanks! :)

@twolfson, Wed Aug 5, 11:29PM PST:

Firefox 79 works fine without issues for me. I've verified via python-livereload. Reading through your StackOverflow, it seems like something is wrong in your hosted livereload.js =/ There is a fallback variant inside of the extension but the URL for that wouldn't be :35729 (LiveReload server)

• CLI tool I'm using: https://github.com/lepture/python-livereload

• Hosted livereload.js in CLI tool: https://github.com/lepture/python-livereload/blob/v2.6.1/livereload/vendors/livereload.js

• Logic that LiveReload extension uses to determine which livereload.js to load: https://github.com/twolfson/livereload-extensions/blob/v20.3.0/src/common/injected.coffee#L45-L68

@twolfson, Wed Aug 5, 11:29PM PST:

Going to post this on GitHub for persistence

Could you support to use of terminal as a build system as Terminus did?

Terminus build system usage of their docs;

Terminus Build System
It is possible to use Terminus as a build system. The target terminus_exec is a drop in replacement of the default target exec. It takes exact same arguments as terminus_open except that their default values are set differently.

terminus_cancel_build is used to cancel the build when user runs cancel_build triggered by ctrl+c (macOS) or ctrl+break (Windows / Linux).

The following is an example of build system define in project settings that run a python script

{
    "build_systems":
    [
        {
            "name": "Hello World",
            "target": "terminus_exec",
            "cancel": "terminus_cancel_build",
            "cmd": [
                "bash", "-c", "echo helloworld"
            ],
            "working_dir": "$folder"
        }
    ]
}
The same Hello World example could be specified via a .sublime-build file.

{
    "target": "terminus_exec",
    "cancel": "terminus_cancel_build",
    "cmd": [
        "bash", "-c", "echo helloworld"
    ],
    "working_dir": "$folder"
}
Instead of cmd, user could also specify shell_cmd. In macOS and linux, a bash shell will be invoked; and in Windows, cmd.exe will be invoked.

{
    "target": "terminus_exec",
    "cancel": "terminus_cancel_build",
    "shell_cmd": "echo helloworld",
    "working_dir": "$folder"
}

https://packagecontrol.io/packages/Terminus

This is a duplicate of #175, #177, and #202. Have you tried a package like https://packagecontrol.io/packages/Console%20Exec ?

Cool, yea =/ Thanks for understanding =) If more people write in about it, then we'll gladly revisit =)

And still glad to help you work through any of those workarounds =)

On Thu, Jul 23, 2020, 9:54 AM Juan Carlos [email protected] wrote:

Yeah, no problem, I've also thought about other ways to solve this issue. Thanks for your time

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/twolfson/spritesmith/issues/81#issuecomment-663117509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG4KWGN2VCFHXLMBGAS2BTR5BTNFANCNFSM4PFYVKHA .

Ahh, very interesting. Hmm, would you be okay with a workaround instead of a formal library solution? I'm skeptical it's worth addressing since nobody has asked about it the 8 years this library has been around o_o

Workaround options:

• Define a custom layout which adds margin to all sides of image and x/y of sprites (essentially wrapping existing padding friendly solutions). Would be happy to write up demo code for this
• Use a tool like gm to add margin after spritesmith then offset CSS mixin accordingly
• Sanity check: Verify background-repeat: no-repeat doesn't resolve the issue
• Something else I can't think of

On Thu, Jul 23, 2020, 9:27 AM Juan Carlos [email protected] wrote:

I guess it could be considered an edge case, so far it's most noticeable with text on certain typographies, when scaling there are some filter artifacts due to chrome's scaling filter. [image: explanation] https://user-images.githubusercontent.com/18577412/88311864-0ad53000-ccd7-11ea-8b6a-badc9c304b29.png

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/twolfson/spritesmith/issues/81#issuecomment-663103998, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG4KWB7TII37VRHFVCZHF3R5BQF7ANCNFSM4PFYVKHA .

I see. Can you explain your use case further? I know padding between images is good for artifacts based on past issues (https://github.com/twolfson/spritesmith/issues/7) but haven't heard about margin having that effect

White space between the sprites and the image borders helps avoid some scaling artifacts.

This feature is available via the padding option in processImages:

https://github.com/twolfson/spritesmith/tree/3.4.0#spritesheetprocessimagesimages-options

Here's an example usage:

https://github.com/twolfson/spritesmith/tree/3.4.0#padding

If you're using our Grunt or gulp variants, then it's padding in the params object:

https://github.com/twolfson/gulp.spritesmith/tree/6.11.0#spritesmithparams

https://github.com/twolfson/grunt-spritesmith/tree/6.8.0#documentation

Description

When switching from Electron 8 to 9, I noticed our Karma/Electron tests were now timing out despite the tests passing. It looks like something is keeping the Electron process alive even when running with singleRun: true and autoWatch: false.

Reproduction Steps

I've created a repo with a fairly minimal reproduction of the problem. I've been able to see the issue using Node 12.18.2 on both Ubuntu 18 and MacOS.

Clone the repo:

1. Clone the repo: git clone https://github.com/dpwatrous/karma-electron-repro.git
2. Install dependencies: npm install
3. Run the test with iframes (this should succeed): npm run test-iframe
4. Run the test iframes disabled (this should hang until Karma times out): npm run test-no-iframe

Deciding to close this issue for now since it's been concluded that this is not caused by karma-electron

Bumps lodash from 4.17.11 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.11...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Aaaand PR opened =) https://github.com/karma-runner/karma-jasmine/pull/272

We received a bug report in karma-electron, https://github.com/twolfson/karma-electron/issues/47, which eventually traced back to Electron being unable to pass a function to between Karma contexts due to IPC fixing passing references between processes

This PR resolve that bug by removing the function which was being attempted to pass as a reference between processes

In this PR:

• Remove Order.sort function passing to Karma callback
• Fixes https://github.com/twolfson/karma-electron/issues/47

Feel free to request commit message changes (or apply them yourself). I tried to find documentation on them but was running out of time =/

Alright, if you use the following in your package.json, it should use the patched code. Opening PR shortly now

// In place of "karma-jasmine": "^3.3.1"
"karma-jasmine": "twolfson/karma-jasmine#dev/stop.passing.functions.in.callbacks.usable.fork"

Damn, they wrote their library in a way where git:// won't work so easily a dependency. I'm getting pulled off to another task but should be back to put a bow on this soon

About to submit a PR which you can then use in place of karma-jasmine in your repo for the meantime =)

Yep, a hack in karma-jasmine's adapter.js fixed it =)

    delete result.order.sort;
    tc.complete({
      order: result.order,
      coverage: window.__coverage__
    })

Going to search around for a bit for something more formal but we've got an answer and a hack-ish solution for now =)

Alright, so it looks like there have been changes to the Electron IPC to avoid passing references between contexts. I'm guessing the error is arising from karma-jasmine passing a function along the bridge as it similarly errors when I try to do so as well

Also that would explain why karma-mocha in karma-electron tests didn't have a similar issue

So the fix should be to update karma-jasmine to stop sending a function in their done handler (or at least it looks similar to that so far)

It looks like something in the window.postMessage handler must have changed to not parse data as we'd expect. Guessing it's attempting to clone now rather than serialize/similar but going to dig a little deeper

Yep, that's definitely the issue/change. We get a CSP error in Electron@8 and 9 but no similar postMessage error in @8

Hmmm, when I make Electron visible and open the console of the new window. I see this error. At first glance, this looks like a serialization error for Karma across either its window to window bridge or its window to node bridge

electron/js2c/renderer_init.js:126 Uncaught (in promise) Error: An object could not be cloned.
    at EventEmitter.t.ipcRendererInternal.send.t.ipcRendererInternal.invoke (electron/js2c/renderer_init.js:126)
    at Object.BrowserWindowProxy.postMessage (electron/js2c/renderer_init.js:166)
    at postMessageCallParentKarmaMethod (context.js:293)
    at ContextKarma.boundProxyMethod [as complete] (context.js:199)
    at KarmaReporter.jasmineDone (adapter.js?e14e485cb2a825ba86577e6749e91dda740e6c04:196)
    at UserContext.fn (jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6488)
    at QueueRunner.attempt (jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6365)
    at QueueRunner.run (jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6406)
    at QueueRunner.execute (jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6273)
    at queueRunnerFactory (jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:1458)
t.ipcRendererInternal.send.t.ipcRendererInternal.invoke @ electron/js2c/renderer_init.js:126
BrowserWindowProxy.postMessage @ electron/js2c/renderer_init.js:166
postMessageCallParentKarmaMethod @ context.js:293
boundProxyMethod @ context.js:199
KarmaReporter.jasmineDone @ adapter.js?e14e485cb2a825ba86577e6749e91dda740e6c04:196
fn @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6488
attempt @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6365
QueueRunner.run @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6406
QueueRunner.execute @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6273
queueRunnerFactory @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:1458
dispatch @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6471
(anonymous) @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6437
(anonymous) @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:1650
(anonymous) @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:6422
channel.port1.onmessage @ jasmine.js?fbc7eaf339ea249d8c912b258548d4e7b4dc180c:2712

I'm going to see if that appeared in Electron@8 or not to confirm if it's a red herring or not

I've successfully reproduced your error. Going to re-read the karma-electron documentation around iframe and dig into your code further

Alright, got a little more time. Let's see if we can hammer this out

Alright, had 1 distraction but so far I was able to upgrade to Electron@9 for our tests with only a module.id/module.parent change due to core Node.js behavior in our test suite but nothing else

It looks like I'm getting pulled away to another task at the moment but should continue soon after that hopefully

Looking into this now

Hmm, interesting. I'm heads down at the moment but should be able to look into this by EOD, if not sooner. Thanks for the reproduction repo so far! =)

Sadly, one of the confusing but also surprisingly good consistent attributes of Handlebars. Glad you figured it out =)

Unsure why this thread is getting so much love out of the blue this morning

It seems some people are still trying to tease out some convoluted reasoning so I'll make this clear:

• The initial discussion wasn't 100% about maintenance time
• It was about a disagreement with an architecture that I wasn't invited to the table at but was being told to maintain (which has a cognitive and temporal overhead)
• We had a civil discourse about the consequences of said architecture
• I still disagreed with the architecture and decided to not participate in its ecosystem, hoping that the author would change their mind to a non-intrusive solution

I am still of the same opinion. It's clear we'll be looping if this thread is allowed to persist so locking it

Thanks everyone for your contributions and thoughts

Bumps electron from 5.0.13 to 9.1.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/electron/electron/releases">electron's releases</a>.</em></p> <blockquote> <h2>electron v9.1.0</h2> <h1>Release Notes for v9.1.0</h1> <h2>Features</h2> <ul> <li>Added support for <code>MessagePort</code> in the main process. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24323">#24323</a></li> <li>Added support for suspend and resume events to Windows. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24283">#24283</a></li> <li>Added support for suspend and resume events to macOS. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24294">#24294</a></li> <li>Expose sessionId associated with a target from debugger module. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24398">#24398</a></li> <li>Implemented <code>systemPreferences.getMediaAccessStatus()</code> on Windows. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24312">#24312</a></li> </ul> <h2>Fixes</h2> <ul> <li>Fixed an intermittent high-CPU usage problem caused a system clock issue during sleep. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24415">#24415</a></li> <li>Fixed an issue where some old notifications were not properly removed from the Notification Center on macOS. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24406">#24406</a></li> <li>Fixed bug on macOS where the main window could be targeted for a focus event when it was disabled behind a modal. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24354">#24354</a></li> </ul> <h2>electron v9.0.5</h2> <h1>Release Notes for v9.0.5</h1> <h2>Fixes</h2> <ul> <li>Fixed "Paste and Match Style" shortcut on macOS to match OS's "Option-Shift-Command-V". <a href="https://github-redirect.dependabot.com/electron/electron/issues/24185">#24185</a></li> <li>Fixed "null path-to-app" in test-app when Electron's path contains spaces or special characters. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24232">#24232</a></li> <li>Fixed an error when calling <code>dialog.showCertificateTrustDialog</code> with no <code>BrowserWindow</code>. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24121">#24121</a></li> <li>Fixed an issue where <code>shutdown</code> would be emitted both on app <em>and</em> system shutdown on macOS. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24141">#24141</a></li> <li>Fixed an issue where <code>withFileTypes</code> was not supported as an option to <code>fs.readdir</code> or <code>fs.readdirSync</code> under asar. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24108">#24108</a></li> <li>Fixed an issue which would cause streaming protocol responses to stall in some cases. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24082">#24082</a></li> <li>Fixed an issue with click events not being emitted on macOS for Trays with context menus set. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24236">#24236</a></li> <li>Fixed delayed execution of some Node.js callbacks in the main process. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24178">#24178</a></li> <li>Fixed tray menu showing in taskbar on Windows. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24193">#24193</a></li> <li>Fixed window titlebar not responding to pen on Windows 10. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24103">#24103</a></li> </ul> <h2>Other Changes</h2> <ul> <li>Fixed issue with some IMEs on windows (for ex: Zhuyin) don't terminate after pressing shift. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24059">#24059</a></li> <li>Fixed mac app store rejection notice for invalid symbolic link in bundle. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24238">#24238</a></li> <li>Updated Chromium to 83.0.4103.119. <a href="https://github-redirect.dependabot.com/electron/electron/issues/24234">#24234</a></li> </ul> <h2>Documentation</h2> <ul> <li>Documentation changes: <a href="https://github-redirect.dependabot.com/electron/electron/issues/24177">#24177</a></li> </ul> <h2>electron v9.0.4</h2> <h1>Release Notes for v9.0.4</h1> <h2>Fixes</h2> <ul> <li>Added missing support for <code>isComposing</code> KeyboardEvent property. <a href="https://github-redirect.dependabot.com/electron/electron/issues/23996">#23996</a></li> <li>Enable NTLM v2 for POSIX platforms and added --disable-ntlm-v2 switch to disable it. <a href="https://github-redirect.dependabot.com/electron/electron/issues/23934">#23934</a></li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/electron/electron/commit/a822d2639a9c9c2c670e91d73f78e921865ce38e"><code>a822d26</code></a> Bump v9.1.0</li> <li><a href="https://github.com/electron/electron/commit/9d6ac058c9ba09e5211cd703675f70901468ca5a"><code>9d6ac05</code></a> feat: expose sessionId in debugger module (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24398">#24398</a>)</li> <li><a href="https://github.com/electron/electron/commit/cbe66f27e725070c7c0c590a2e485978a554be19"><code>cbe66f2</code></a> fix: intermittent 100% CPU usage on macOS (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24415">#24415</a>)</li> <li><a href="https://github.com/electron/electron/commit/4f10bde056d5fe175f338b5bc7b04baf422df5bb"><code>4f10bde</code></a> feat: implement systemPreferences.getMediaAccessStatus() on Windows (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24275">#24275</a>) ...</li> <li><a href="https://github.com/electron/electron/commit/473c7dbe734fd2df68fa68f3a344e3a0222dfbf8"><code>473c7db</code></a> chore: use node_bindings loop for clarity (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24418">#24418</a>)</li> <li><a href="https://github.com/electron/electron/commit/4515c4db00d94175179e47b0c4d05d7d4f0074a7"><code>4515c4d</code></a> feat: add app render-process-gone event (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24315">#24315</a>)</li> <li><a href="https://github.com/electron/electron/commit/6dd394a155116cec542656165973a7888fe3938f"><code>6dd394a</code></a> fix: remove same-tag notifications before showing new ones (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24406">#24406</a>)</li> <li><a href="https://github.com/electron/electron/commit/4ace4995c81f1b04ab99cc1707d037e9972e1316"><code>4ace499</code></a> feat: MessagePorts in the main process (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24323">#24323</a>)</li> <li><a href="https://github.com/electron/electron/commit/71e329663e24fa4773dd4bdbf8fe71844de87bb8"><code>71e3296</code></a> feat: add new render-process-gone event (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24309">#24309</a>)</li> <li><a href="https://github.com/electron/electron/commit/67002fdf11b7329cdba2e70ace583cb0b853e4cc"><code>67002fd</code></a> fix: macOS modal focus (<a href="https://github-redirect.dependabot.com/electron/electron/issues/24354">#24354</a>)</li> <li>Additional commits viewable in <a href="https://github.com/electron/electron/compare/v5.0.13...v9.1.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Looked at vulnerability, not affected by it

I am using npm version:- 6.14.5 and node version:- 12.16.1 Following are steps to build and test the json-content-demux package:

git clone https://github.com/twolfson/json-content-demux.git npm install npm test

After performing npm test, I am getting following error, so can you help me please in this or suggest me steps if I missing something.:

Loading "test.js" tasks and helpers...ERROR

Error: No such module: evals <WARN> Task "test" not found. Use --force to continue. </WARN>

Aborted due to warnings. npm ERR! Test failed. See above for more details.

Nothing to configure, you only need to update the repo:

• git pull
• npm install
• npm test

Alright, that was surprisingly easy. We swapped the test suite over to nodeunit and it's running/passing now. Released in 0.1.4

Going to take the time to touch-up the rest of the repo now since I'm already here

Fwiw, the main library doesn't have this issue (in fact it has no dependencies) so it should work just fine

Hmm, the issue is probably that the repo hasn't been updating a very long time so it's using a very old version of grunt, which likely has some broken dependencies by now

I'll triage the repo to see how much work this is going to be

Most work has been done in #101 but has been halted for now due to lack of time. If anyone decides to pick this up again, that's probably a good place to start

logical lines that begin with a string and don't follow other docstrings are now considered to be docstrings fixes #100 requires flake8>=3.0 drop support for python 2.7 and 3.4 added some type assertions update tests for new docstring rules and to call flake8 directly

Unsure what you mean by "it's your project", open source with broad licensing is the public's project imo -- it just so happens that I'm a maintainer here. Using phrasing like "it's your project" seems like a way to sneak out of responsibility here and in future bug fixes for said relevant code ._.

I similarly don't have time to build out this enhancement fully, hence the "help wanted" tag on the original issue

Closing this PR and making a comment on the original issue for future contributors

Thanks for your time and contributions =)

I'd really prefer to use flake8 APIs instead of running the command directly =/ It slows down the tests and makes debugging weirder/harder (e.g. print statements are now in assert blocks instead of just stdout

Unfortunately, I took a shot but don't have time to dig to find a nice default options for FileChecker or FileProcessor =/

https://flake8.pycqa.org/en/3.8.2/internal/checker.html#processing-files

Also, it's good practice to avoid using .* when you can. Better to use not class identifiers to avoid accidentally greedy code:

 OUTPUT_REGEX = re.compile(r'[^:]+:([\d]+):([\d]+): (.*)') 

Also can we add an example comment line before so someone can better understand what the regex is doing?

I tried to find a reference to this in the flake8 docs but I can't seem to. Where's this documented and can we add a comment linking to it?

Yea, I concur that our goal should be to be in alignment with active PEPs (it doesn't look like there's a finalized state)

My internet is back, going to give reviewing a go

Updated the title to better reflect the intention of the PR since logical lines seems more auxiliary based on your comment

Was just about to review/process replies but Internet has cut out again today. Hopefully will be able to go through this tomorrow or Sunday

On Fri, Jun 5, 2020, 11:44 AM Peter Linss [email protected] wrote:

Did some more research and found out that what I was referring to as 'continuation docstrings' are actually called 'additional docstrings' and are part of PEP258 https://www.python.org/dev/peps/pep-0258/#additional-docstrings. While that PEP was rejected, it's still referred to in PEP257 https://www.python.org/dev/peps/pep-0257/#what-is-a-docstring which is still active, and 'additional docstrings' are explicitly mentioned along with 'attribute docstrings'.

So I strongly suggest we consider them docstrings and remove the previous line check entirely.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zheller/flake8-quotes/pull/101#issuecomment-639699896, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG4KWFTAMXLRJDMLEIQSUDRVE4HVANCNFSM4NS4URPA .

Also, can you explain how logical lines make it easier to handle variable docstrings as opposed to physical lines?

My current take is that they're not too different and we usually need full file state awareness for the docstring parser to work (i.e. don't just care about previous line but all previous lines in file -- e.g. class statement could take a lot of line breaks to finish its closing parens)

Not your fault as this seems more/less the same as https://github.com/zheller/flake8-quotes/pull/101/files#diff-d7312ce5f3248fb3a2d6e340b7cf0d22L183

tokens = [Token(t) for t in tokenize.generate_tokens(lambda L=iter(file_contents): next(L))]

but this is a damn confusing line, we should prob break it up into a more straightforward function

        # Generate `readline()` matching interface for `tokenize.tokenize` and pass it in
        #   https://docs.python.org/3/library/tokenize.html#tokenize.tokenize
        previous_logical_readline_fn = (lambda L=iter([previous_logical.encode('utf-8')]): next(L))
        prev_tokens = tokenize.tokenize(previous_logical_readline_fn)

We can prob drop this change, I usually do the update via ./release.sh which adds this change to the git tag commit for good measure/traceability

__version__ = '3.2.0'

What's the purpose of the parentheses here? It seems inconsistent with the similar logical operators below

            is_docstring = token in self.docstring_tokens

Afk for a while today. Might not be able to review until tomorrow or the weekend even

At first glance, seems like overreach in the PR =/ If we're just changing from physical to logical lines and dropping our own parsing support, then I'd imagine that only the init parameter changes and we drop some conditional logic

One example of overreach is this looks like it includes changes like adding a typing convention which I feel is a whole other discussion since it should require willingness of contributors to maintain and lint that

On Thu, Jun 4, 2020, 12:17 PM Peter Linss [email protected] wrote:

I wasn't able to remove the old docstring logic completely, it's still needed to detect inline docstrings. But a lot of other code was able to go away.

Given that we now rely on flake8 to determine what a logical line is, the testing code had to change to call flake8 rather than the checker directly. The checker now also returns 1 based column numbers (using the line and column reported by flake8s tokenizer).

Now any logical line with a leading string is considered a docstring, unless if follows another docstring. I did the previous line check to match previous behavior, but I'm not sure if I should have.

A second docstring is not processed as a docstring (AFAICT), but it's still logically a docstring since it's ignored by the python interpreter, so it probably shouldn't be considered a multiline string either as it is now.

I'm thinking to add another error code for duplicate docstrings, but still consider them docstrings. Though checking for duplicate docstrings seems out of scope for this module... I welcome your feedback on that point.

If this PR works for you, I'll add code to fix #82 https://github.com/zheller/flake8-quotes/issues/82 shortly. I know it's a significant change.

I also added type annotations (mostly) which required dropping support for Python 3.4 as well. This should still work with 3.4 if we just strip the type annotations or switch them all to comment style.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zheller/flake8-quotes/pull/101#issuecomment-639063831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG4KWF535E2G5Z65FV4OFDRU7XMRANCNFSM4NS4URPA .

As of PR #94, we should only be parsing files as a backup:

https://github.com/zheller/flake8-quotes/pull/94

I'm revisiting the flake8 docs to better understand if this implies logical lines or not. It's not 100% clear to me. However, it does look like there's some abstractions which weren't standardized when we first built everything so feel free to use those

https://flake8.pycqa.org/en/3.8.2/internal/checker.html#flake8.processor.FileProcessor

I guess I'd prefer to either keep code length the same or reduce it, and ideally not rewrite the whole thing unless it's absolutely necessary

If we have to drop [email protected] support, then we can always make it a major release. It seems like [email protected] was released in 2016 so that's plenty of time people have had to upgrade

https://flake8.pycqa.org/en/latest/release-notes/

Python 2 has been sunset so nope, we don't care about supporting it anymore

This has been patched in 1.3.1. Thanks for the bug report =)