Empty space allocated for right sidebar when not used

Hi, not sure if this is a bug or usage question, but I am sufficiently confused by what's happening to raise it here.
I am working on porting the seaborn docs to the pydata theme. I'm finding that, on a page with html_sidebars set to [], a large empty space is nonetheless allotted when the window gains a certain width.
Largest size looking nice:

Appearance after a slight enlargement:

The threshold corresponds to where the right sidebar would be unhidden on a page that uses it.
Am I missing something about how to control this? I do have .no-sidebar {  display: none;  } in my custom CSS (which I think applies only to the left sidebar anyway), but that isn't the cause — without it I get the same general effect but with centered content.
Apologies that this isn't a self-contained example, but here are links to relevant source files:

index.rst
conf.py
custom.css

I appreciate any help you can give!

Hmmmm, this feels like a CSS bug to me. My feeling is that we want to follow a few principles:

The "center of weight" of the page should be the middle of screen.
If we have a sidebar, this means that the content center can be slightly to the left, and the sidebar to the right (or left, depending on the sidebar)
If we have no sidebars, the content should be in the middle.
We should choose a reasonable max width for the content

That all sounds right to me. How can I be most helpful in identifying the source of the big?


TLAPM fails to parse set literals containing multiple expressions of form x \in S

This is similar to SANY issue https://github.com/tlaplus/tlaplus/issues/1021, demonstrating that difficult parsing areas remain difficult across implementations. TLAPM will fail to parse the following:
---- MODULE Test ----
op == {x \in BOOLEAN, y \in STRING}
====

Ref #159

Fixed by #140


stabular package incompatible

Not sure if anyone uses stabular over longtable, but it errors with
! Missing # inserted in alignment preamble.

If its array option is loaded, the error is
! Undefined control sequence.
<argument> \ERRORmissingcells

Example:
\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,title,math,table,firstaid}
  }
\documentclass{article}

\usepackage[
%  array % errors with or without
  ]{stabular}

\begin{document}

\begin{stabular}{cc}
A & B \\
C & D
\end{stabular}

\end{document}

hm yes, it would have to copy the tabular adaptions in array.sty.

... or build on array perhaps? What happens if array is loard afterwards?


Fix typo in https://kubernetes.io/blog/2020/06/30/sig-windows-spotlight-2020/

Fix typo spotted in https://github.com/kubernetes/website/pull/22179/files#r450381366
Preview

Thanks for getting that! I was about to do the same.

@kaslin happy to review? You can reply with “/lgtm” and approvers will take account of it, even if Prow doesn't recognize you as an official blog reviewer.

/lgtm

Do I need to assign it back to you to approve @sftim ?

I can approve my own PR, but I'll let someone else do that.

/approve


Folder Level Suppression for Predefined Set Of Variables Injected Using setattr

Injection:
def initialize(context_name):
    for tag in paired_tags:
        setattr(sys.modules[context_name], tag, type(tag, (Element,), {"name": tag, "paired": True}))

    for tag in paired_textonly_tags:
        def __init__(self, content="", **kwargs):
            self.attributes = []
            self.children = [content]
            self.styles = kwargs.pop("styles", [])
            for key, value in kwargs.items():
                self.attributes.append(f'{key}="{value}"')

        setattr(sys.modules[context_name], tag, type(tag, (Element,), {"name": tag, "paired": True, "__init__": __init__}))

    for tag in unpaired_tags:
        setattr(sys.modules[context_name], tag, type(tag, (Element,), {"name": tag, "paired": False}))

Usage:
from modules import html_py

html_py.initialize(__name__)

page = html(lang="en", children=[

])

I have arrays consisting of all HTML5 tags. This will be used in multiple files.
Any way to suppress errors on a specific directory for specific variables (reportUndefinedVariable)?
Maybe creating a file at root just like .gitignore?

You can change the severity (or suppress) a particular diagnostic at the workspace level using python.analysis.diagnosticSeverityOverrides or in a pyrightconfig.json file. Or you can do so at the file level using comments. Or suppress them at the line level.
But there isn't a way to change the severity or suppress diagnostics for particular subdirectories.

I would assume the workspace and folders are the same. Am I wrong?

Any way to suppress errors on a specific directory for specific variables (reportUndefinedVariable)?

Also, how would I modify pyrightconfig.json to act the same as # type: ignore[html,head,...]

Oh, I misunderstood what you were asking. You could suppress reportUndefinedVariable globally or at the file level, but not for particular variable names.

I would assume the workspace and folders are the same. Am I wrong?

If your workspace looks like this:
root
    subdir1
        file1.py
    subdir2
        file2.py

You can use VS Code settings or pyrightconfig.json to control the severity of diagnostics across the entire workspace, but you couldn't, for example, have different severities for all files within subdir2 since the VS Code settings are global and pyrightconfig.json is only supported at the root level.
If you're talking about a multi-root workspace (see Add Folder to Workspace...), I believe we support having separate pyrightconfig.json files for each root of the workspace.

@sushantshah-dev, if this does not resolve the issue, please reopen.


submitting a remote form forgets the previous url

1: go to /edit
2: submit form
3: arrive at show page
4: hit back
expected: arrive at edit page
actual: arrive at show page (hitting back again goes to previous urls, never edit page)

workaround:
(function(){
  var remoteForm = 'form[method!=get][data-remote=true]';
  $(document).on('submit', remoteForm, function(e, response) {
    Turbolinks.controller.history.push(window.location.href);
  });

  $(document).on('ajax:success', remoteForm, function(e, response) {
    if(response.substring(0, 10) == 'Turbolinks'){ return; }
    Turbolinks.clearCache();
    $("body").html(response.match(/<body[^>]*>([\s\S]*?)<\/body>/i)[1]);
    Turbolinks.dispatch("turbolinks:load");
    window.scroll(0, 0);
  });
})();

@grosser possible simpler fix would be to leverage the redirect options in place for turbolinks.
redirect_to :show, turbolinks: "advance"
This will keep browser history rather than replace it.

yeah but then all my controllers have to be turbolinks aware ... I'd love for it to stay a client-side concern

Is there any time that redirect_to shouldn’t push the last page onto the history? What's wrong with this?
class ApplicationController < ActionController::Base
  private

  def redirect_to(*args, **options)
    super(*args, **options, turbolinks: 'advance')
  end
end


Failed to setup

After adding the repository through HACS and restarting, adding the account (HON, with supported devices, location Europe) the account initializes and then fails to set up. Multiple restarts later and re-adding the repo no different result.  Directly in the HON app, all works as expected.
Any thoughts?

Home Assistant 2023.7.3
Log:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 390, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hon/init.py", line 71, in async_setup_entry
coordinator = await hon.async_get_coordinator(appliance)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hon/hon.py", line 90, in async_get_coordinator
coordinator = HonBaseCoordinator( self._hass, self, appliance)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hon/base.py", line 34, in init
self._type_id       = appliance["applianceTypeId"]
~~~~~~~~~^^^^^^^^^^^^^^^^^^^
KeyError: 'applianceTypeId'

Same issue happen for me. I did provide correct password and username but still this error occur.

Ok I know how to fix it, I guess there is an incorrect entry somewhere.
@hajtuJ do you have the same error?

Ok I know how to fix it, I guess there is an incorrect entry somewhere.
@hajtuJ do you have the same error?

Thanks for looking into this. Lemme know if I can support you with a donation of a  "cup of coffee" :)

Hi @KevinVeenman, I just made an update. Can you please test and tell me the result ? at minimum you should have a different log with more info.

Hey @gvigroux, thanks for the update. Unfortunately no success just yet.  I get the following log message (see below).
This error originated from a custom integration.
Logger: homeassistant.config_entries
Source: custom_components/hon/device.py:20
Integration: hOn (documentation, issues)
First occurred: 10:51:13 PM (1 occurrences)
Last logged: 10:51:13 PM
Error setting up entr [LOGIN EMAIL] for hon
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 390, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hon/init.py", line 72, in async_setup_entry
coordinator.device = HonDevice(hon, coordinator, appliance)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hon/device.py", line 20, in init
self._type_id       = appliance["applianceTypeId"]
~~~~~~~~~^^^^^^^^^^^^^^^^^^^
KeyError: 'applianceTypeId'

Thank for your support :)
I've decided to have a more strict approach, so you should not have any issue anymore (but maybe some devices will not appears).
If one device is missing after loading the integration:

please add these lines in you configuration.yaml and reboot

logger:
  logs:
    custom_components.hon: debug

after the reboot, look at the log and share the first log called "All appliances:"

Other question, do you have devices using Farenheit?

@KevinVeenman , @hajtuJ can you please do a new test?

I'm closing this due to lack of feedback


Add finalizer support to async Redis client

Also add libevent example that tests it and also demonstrates pubsub.
Fixes #925

@michael-grunder have you had a chance to take a look at this? Thank you!

@michael-grunder I don't think there are any backwards compatibility issues. The only thing that changes in a potentially backwards incompatible way is struct redisCallback (its size and the offsets of the pendingSubs and privdata members), but that's not allocated explicitly by users, nor is it used in any inline functions (in fact, it probably shouldn't be in a public header file at all).

I guess code that explicitly accesses redisAsyncContext::replies would break, but I don't imagine that was ever intended for public consumption.

I was just about to open an issue asking for this yesterday.  I presume this is to support knowing when hiredis forgets the callback.
A couple of questions:

The finalizer seems necessary only for subsriptions, because regular callbacks are called once, and only once, right?
There is code in the subscription logic that replaces subscription callbacks in the dicts, if a previous subscription exists.  Are the finalizers called in that case?  Should they?  Only if the privdata member is different?

@kristjanvalur

I chose to run the finalizer for regular callbacks as well, because that allows me to generically free state in the C++ code that sits on top of hiredis without having to know whether the callback is a subscription callback or not. If you don't want a finalizer, pass NULL :)
Similarly, I chose to always run the finalizer in the replacement case. Your old callback will never be called again (finalize it), and the new one will.

@kristjanvalur sorry for the long delay, I made the change you requested. PTAL?

LGTM, although honestly, not much is happening in this repo.   C++ programmers worldwide would thank you :)

@tudor are you still interested in finishing this?

@zuiderkwast No, I'm not planning to work on this any more. I ended up having to parse the request and response (to know whether it's pub/sub or regular command) anyway for a different reason, in which case I can tell when the callback may be called multiple times.

That's a shame, it looked like a worthwhile addition.  If there is interest, I can pick this up.

@kristjanvalur I was going to pick it up myself, but you can do it if you want.
We want it for hiredis-cluster, so we can implement pubsub without actually looking at the commands sent by the user. We haven't fully decided if this is enough though.

Hehe, I'm not sure I'm less rusty with hiredis internals. :-) I was just going to rebase and apply Michael's comments. I'll invite you for review.

This PR doesn't correctly handle SUBSCRIBE with multiple channels with finalizer.
I've implemented this now in #1173. It's ready for review. Please have a look. (I'll try to get time to implement the RESET command too, and to allow calling commands while in monitor mode.)
I had to rewrite a lot, because a callback can be used for multiple channels, which can be usubscribed independenly. To keep track of the last reference to a callback (for calling the finalizer at the right time) I've added a reference counter in the callback struct.


Cannot read property 'tags' of undefined

I'm trying to use this with the Hexo Theme Phantom but this error keeps appearing.
Unhandled rejection TypeError: /Users/jackiechong/Garden/business/test/themes/phantom/layout/post.ejs:1
 >> 1| <%- partial('_partial/article-full', {item: page}) %>

/Users/jackiechong/Garden/business/test/themes/phantom/layout/_partial/article-full.ejs:22
    20| <%- item.content %>
    21|
 >> 22| <%- popular_posts() %>
    23|
    24| <!-- Tags -->
    25| <%- partial('article-tags') %>

Cannot read property 'tags' of undefined
    at Object.module.exports.getList (/Users/jackiechong/Garden/business/test/node_modules/hexo-related-popular-posts/lib/list-json.js:129:20)
    at module.exports (/Users/jackiechong/Garden/business/test/node_modules/hexo-related-popular-posts/lib/helper.js:7:31)
    at Object.<anonymous> (/Users/jackiechong/Garden/business/test/node_modules/hexo-related-popular-posts/index.js:170:32)
    at Object.wrapper [as popular_posts] (/Users/jackiechong/Garden/business/test/node_modules/lodash/lodash.js:4968:19)
    at eval (eval at compile (/Users/jackiechong/Garden/business/test/node_modules/ejs/lib/ejs.js:549:12), <anonymous>:50:17)
    at returnedFn (/Users/jackiechong/Garden/business/test/node_modules/ejs/lib/ejs.js:580:17)
    at Theme._View.View._compiledSync (/Users/jackiechong/Garden/business/test/node_modules/hexo/lib/theme/view.js:122:20)
    at Theme._View.View.View.renderSync (/Users/jackiechong/Garden/business/test/node_modules/hexo/lib/theme/view.js:50:21)
    at Object.partial (/Users/jackiechong/Garden/business/test/node_modules/hexo/lib/plugins/helper/partial.js:42:17)
    at Object.wrapper [as partial] (/Users/jackiechong/Garden/business/test/node_modules/lodash/lodash.js:4968:19)
    at eval (eval at compile (/Users/jackiechong/Garden/business/test/node_modules/ejs/lib/ejs.js:549:12), <anonymous>:9:17)
    at returnedFn (/Users/jackiechong/Garden/business/test/node_modules/ejs/lib/ejs.js:580:17)
    at Theme._View.View._compiled (/Users/jackiechong/Garden/business/test/node_modules/hexo/lib/theme/view.js:127:30)
    at Theme._View.View.View.render (/Users/jackiechong/Garden/business/test/node_modules/hexo/lib/theme/view.js:29:15)
    at /Users/jackiechong/Garden/business/test/node_modules/hexo/lib/hexo/index.js:390:25
    at tryCatcher (/Users/jackiechong/Garden/business/test/node_modules/bluebird/js/release/util.js:16:23)
    at /Users/jackiechong/Garden/business/test/node_modules/bluebird/js/release/method.js:15:34
    at RouteStream._read (/Users/jackiechong/Garden/business/test/node_modules/hexo/lib/hexo/router.js:134:3)
    at RouteStream.Readable.read (_stream_readable.js:445:10)
    at resume_ (_stream_readable.js:825:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Is there something I'm missing or am I placing it in the wrong file? Can't find anything on the error.

@ghostssura
hexo-theme-phantom seems to have the same issue as #4 . Please change the following code to the themes/hexo-theme-phantom/layout/_partial/article-full.ejs.
...
<!-- Content -->
<%- item.content %>

<%- popular_posts( {} , item ) %>

<!-- Tags -->
<%- partial('article-tags') %>
...

That did it! Thanks @tea3.


why Default box size is only can be set at 303030  ?

I have receptor where grid box size is going upto 404090. So i received this error. Is ther any way i can do docking with this grid size.
`WARNING: The search space volume > 27000 Angstrom^3 (See FAQ)
Using virtual sreening mode
Output will be in the directory ./test2_out
Reading input ... done.
Setting up the scoring function ... done.
Using heuristic search_depth
Analyzing the binding site ... done.
GPU Platform: NVIDIA CUDA
GPU Device: NVIDIA GeForce GTX 1650
Using random seed: 189892838
An error occurred: relation too large!.
Please contact the author, Jiansheng Wu<EMAIL_ADDRESS>so
that this problem can be resolved. The reproducibility of the
error may be vital, so please remember to include the following in
your problem report:

the EXACT error message,
your version of the program,
the type of computer system you are running it on,
all command line options,
configuration file (if used),
ligand file as PDBQT,
receptor file as PDBQT,
flexible side chains file as PDBQT (if used),
output file as PDBQT (if any),
input (if possible),
random seed the program used (this is printed when the program starts).

Thank you!
`

Hi, the answer to you question is here: https://autodock-vina.readthedocs.io/_/downloads/en/latest/pdf/#:~:text=Why am I seeing a,are given in Angstroms instead.
Why am I seeing a warning about the search space volume being over 27000 Angstrom^3?
This is probably because you intended to specify the search space sizes in “grid points” (0.375 Angstrom), as in AutoDock 4. The AutoDock Vina search space sizes are given in Angstroms instead. If you really intended to use an unusually large search space, you can ignore this warning, but note that the search algorithm’s job may be harder. You may need to increase the value of the exhaustiveness to make up for it. This will lead to longer run time.


Actions

It would be useful to be able to use DDB to filter records of any model, and then perform a action on them.
The obvious source of "actions" is Django admin list actions.  That re-uses an existing well defined interface for actions.  This would allow removal of the DDB "csv" and "json" export , as those could be provided by https://github.com/saxix/django-adminactions or many other apps providing that type of functional.
Another very interesting app I am now starting to use is https://django-action-framework.readthedocs.io/ which allows defining actions generically against models in a way that can be accessed by other apps.  Those actions can be fairly easily added to Django admin , so they would automatically become available to DDB if it uses Django admin actions.
However DDB actions can also be exposed via DRF which might be a way that DDB can access the actions from the JS layer.  I haven't tried this yet, and would prefer to use django admin for many types of actions which I dont feel comfortable exposing over DRF unless I also built lots of security related tests to ensure it could not accidentally be exposed to non-admins.

I agree that if DDB is going to support any sense of write actions then it should start with the existing admin ones.
I think the JSON and CSV exports are core parts of DDB data access functionality and additionally they tie to the public views as well (I have very mixed feelings about public views being disabled by default).
I have no problem with exposing admin actions if someone were to put a pull together for it. Happy to discuss how that might work. In general I'd like to avoid picking up DRF as a dependency. I would want to expose it in a DDB specific API that ties direct into the admin functionality much like how the rest of DDB works.

nts: I think any "admin" column could have the bulk actions from the associated admin in the title right click menu

This is committed and can be installed direct from github, I will release it sometime in the next week or two, might do a 3.2 with everything I get done over the holidays (in between Cyberpunk sessions).
If you could give it a try sometime and let me know how it goes that'd be appreciated.


⚠ Jenkins Plugins Artifactory has degraded performance

In 0ea64f7, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1339 ms

Resolved: Jenkins Plugins Artifactory performance has improved in c813c42 after 12 minutes.


x/build/cmd/gerritbot: flag common mistakes in GitHub PRs like no word wrap, wrong bug format, using markdown, ...

#61182 starts with an enumeration of friction for the GitHub PR workflow.
We could reduce some friction by automatically flagging common PR problems to save maintainer time and give faster feedback to a potential contributor.
If a maintainer sees that someone who sent a GitHub PR has responded properly in Gerrit to automated feedback, that is a signal that more detailed feedback from a human reviewer is more likely to be acted upon, which might help a maintainer triage which CLs get their attention when. (One of the worst issues listed in #61182 is that for some percent of GitHub PRs, the author never responds to feedback in Gerrit).
I am about to send a WIP CL for discussion. It started as a way to flag improper word wrapping (#24832), but once we can flag one problem, it was a small-ish step to add a loop, define a simple rule func signature, and then define a set of small rules.
Current rule names
title: no package found
title: no lowercase word after a first colon
title: no colon then single space after package
title: ends with period
body: short
body: long lines
body: might use markdown
body: no sentence candidates found
body: no bug reference candidate found
body: bug format looks incorrect
body: bug reference candidate not at end
body: still contains PR instructions
body: contains Signed-off-by

Most of those rule definitions are small -- the median rule body is 5 lines of code (an if statement + 2 lines).
We could add more rules in the future, such as flagging raw benchmark output (suggesting benchstat), asking about the seeming absence of a test, flagging an incorrectly formatted CL reference, possibly checking gofmt, and so on.
Sample results
Running those rules against a corpus of 1000 recent CLs that started as GitHub PRs gives the following stats:
   Findings per CL: 1.45 (avg.)
 CLs with findings: 76.5%

CL hit %   Finding name
--------   ------------------------------------------------
    7.6%   title: no package found
   13.6%   title: no lowercase word after a first colon
    0.0%   title: no colon then single space after package
    2.0%   title: ends with period
   21.8%   body: short
   21.7%   body: long lines
   10.5%   body: might use markdown
    6.8%   body: no sentence candidates found
   46.0%   body: no bug reference candidate found
   10.3%   body: bug format looks incorrect
    1.6%   body: bug reference candidate not at end
    2.2%   body: still contains PR instructions
    0.9%   body: contains Signed-off-by

That corpus is the 1000 most recent PRs that were ultimately merged. The results here are for the commit message in the first patch set (prior to any human feedback).
Philosophy
The rules mostly err on the side of reducing false positives, though some are unavoidable. We attempt to mitigate false positives by stating in the message we post to the CL that the findings are "potential problems" based on "simple heuristics", and we ask the contributor to reply on the CL if a finding appears wrong. Part of the intent is to engage a first time contributor and get them using Gerrit, but without annoying them too much.
We also attempt to point towards auxiliary info and advice specific to the rule violation. If a rule triggers for a potential problem related to a commit message, we also include links to the contributing guide Good commit messages section and instructions on how to edit the commit message. (A current problem is new contributors don't always know how to edit the commit message after a human asks them to change it, which leads to extra review iterations).
There is also some simple logic to be more lenient for PRs that appear to be trivial changes (e.g., don't complain about a missing bug reference if the title contains things like "typo" or "grammar"). Where we have less certainty (e.g., identifying markdown use), we attempt to express that uncertainty in the resulting message shown to the user. The rule definition also allows us to skip certain rules for some repos (e.g., don't complain in the proposal repo about a missing package).
CC @heschi, @cagedmantis

There is some potential overlap with another CL I sent (CL 509135 for #61316), but to start, I suggest we discuss the two issues separately. (Later, we can resolve whether/how to combine the message from CL 509135 with this message, vs. if it is better to have separate messages, but might be good to first establish if there is any interest in proceeding with this issue).
Also, there is some overlap with what could eventually be done with Tricium, but:

This seemed simple enough to try as an interim step.
This is in Go rather than Python.
Heschi recently mentioned here that it might be some time before even simple rules are added to Tricium, which seemingly does not have much out of the box.
There might be some benefit to building experience with automatically nit picking GitHub PRs (a workflow correlated with newer contributors in greater need of help) before we attempt to nit pick more seasoned contributors for all Gerrit CLs.

There is now an initial implementation in https://go.dev/cl/513397 (with a few small tweaks such that the CL hit % numbers are slightly different in the CL vs. the opening comment here).

Thanks for that analysis @thepudds.
I want to comment on the "without a period" contributing to being a possible problem. It seems better to me to consider the period or no period as fine. That is, both Fixes #57151. and Fixes #57151 should be interchangeable.
https://go.dev/wiki/CommitMessage includes:

Don't be too pedantic in code reviews: it's not worth asking people to change from Updates or something else to For, or vice versa.

I usually include periods after "For #nnn." because I consider them to be short sentences. A recent CL by Russ https://go.dev/cl/506415 is another example that included a period in the Fixes line.

Hi @dmitshur, that makes sense. (That rule already allows different aliases like Fixes vs. Closes vs. Resolves, but it was not top of mind for me that the trailing period is common for some people on the core Go team such as yourself, and the examples in the Contributing Guide and wiki don't seem to use the trailing period, which is why the rule as originally defined would complain about that).
I'll circle back to this shortly to stop it from complaining about a trailing period. (I might stack it behind the corpus CL, in part to serve as an example of how the summary stats and whatnot change for the corpus after a small change).

Also, before I did anything here, I skimmed a dozen or so random-ish CLs to see how reviews would stall, what seemed to be taking up human time, what types of review feedback could potentially be automated, and so on, and during that, I thought I saw ~1-2 times where someone on the core Go team asked someone to remove a trailing period from a Fixes or Updates line, but I might have been mistaken. (E.g., it might be that a reviewer just supplied an example without a period for a commit message that happened to use a period but also had some other bug format problems).
In any event, to help make sure everyone is on the same page, I just tweaked the CommitMessage wiki page to say that a period is acceptable. Given this is policy-ish, please let me know if that's wrong, or correct my edit if needed.


[#5699] buffer boundary check is missing

Codecov Report

Merging #5700 into 1.8.x will decrease coverage by <.01%.
The diff coverage is 28.57%.

@@           Coverage Diff            @@
##           1.8.x   #5700      +/-   ##
========================================
- Coverage   40.6%   40.6%   -0.01%
========================================
  Files       2667    2667
  Lines      80152   80154       +2
  Branches   10867   10868       +1
========================================
  Hits       32545   32545
- Misses     44649   44650       +1
- Partials    2958    2959       +1

Impacted Files
Coverage Δ

...om/navercorp/pinpoint/web/mapper/SpanMapperV2.java
0% <0%> (ø)
:arrow_up:

...n/server/bo/serializer/trace/v2/SpanDecoderV0.java
87.91% <40%> (-0.32%)
:arrow_down:

...pinpoint/rpc/ChannelWriteFailListenableFuture.java
42.85% <0%> (-28.58%)
:arrow_down:

...p/pinpoint/rpc/client/WriteFailFutureListener.java
56.25% <0%> (-18.75%)
:arrow_down:

...vercorp/pinpoint/rpc/packet/ClientClosePacket.java
55.55% <0%> (-11.12%)
:arrow_down:

...rc/main/java/com/navercorp/pinpoint/test/Item.java
68.96% <0%> (-3.45%)
:arrow_down:

...navercorp/pinpoint/rpc/common/SocketStateCode.java
82.92% <0%> (-2.44%)
:arrow_down:

...orp/pinpoint/rpc/server/DefaultPinpointServer.java
78.81% <0%> (-1.05%)
:arrow_down:

...point/rpc/client/DefaultPinpointClientHandler.java
71.83% <0%> (+1.26%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

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


Move codecov to root

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.51%. Comparing base (af65fb7) to head (df463e6).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #35   +/-   ##
=======================================
  Coverage   99.51%   99.51%
=======================================
  Files           9        9
  Lines        1445     1445
=======================================
  Hits         1438     1438
  Misses          7        7

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Zeta/versioned transactions

side q: now that we have our own repo, can we port stuff like processTx into here from our sdk? we can make this one public

side q: now that we have our own repo, can we port stuff like processTx into here from our sdk? we can make this one public

Yeah we can, I'll have a look at utils to see what we can port over


feat: added message_author_id field to message_reaction_add_t event

Code change checklist

[x] I have ensured that all methods and functions are fully documented using doxygen style comments.
[ ] My code follows the coding style guide.
[ ] I tested that my change works before raising the PR.
[ ] I have ensured that I did not break any existing API calls.
[x] I have not built my pull request using AI, a static analysis tool or similar without any human oversight.

Wait, 4 commits from here are in #732 .
How has GitHub not picked up on this?

Wait, 4 commits from here are in #732 . How has GitHub not picked up on this?

It's just a difference in history between branches, it'll iron out in the merge

Wait, 4 commits from here are in #732 . How has GitHub not picked up on this?

It's just a difference in history between branches, it'll iron out in the merge

Ah right 👍

Oopsy whoopsy

is this ready at all?

I've renamed this PR from feat: added message_author_id field to message_reaction_add_t event to feat: added component default values. I'll also test this and see if this good to go 👍

i have ticked the boxes in the pr, and added archies changes to merge this, as i need it in my own projects.


Feature: Vehicle spin controller

Allows modifying the vehicle spin value, which people might find useful.
Earlier demo:
https://github.com/user-attachments/assets/9c54007b-7f91-4c5d-a736-c9ddb5298d56
Current UI:

I also want to bump the window width a bit so this glitch won't occur?


Row order inside Site

Hi @Kungsgeten,
thanks for this nice little package! I just discovered it and hypothes.is in general a couple of days ago. What I feel to be a little inconvenient is the fact, that the highlights are sorted from youngest to oldest according to 'update date'. This leads to the highlights being in the opposite way, I would expect them to be. I realize that I do not know what your use case is and therefore your need may be different...
Looking at the API, I realized it is possible to sort them according to location in the actual site as well. I added this functionality to my clone and was wondering if you'd like to support it? If so I'd be happy to provide this.
Cheers
Peter

Hi!
I didn't know you could sort them in the order of the site, only by date. A problem I encountered when implementing the "archive" function was how to get the newest of the fetched entries. Also when searching I think there was a problem choosing ascending/descending if you gave the API a "not older than this" date.
If you could get the archiving function to work while still maintaining the original order of the highlights that would be great!

Maybe I should've looked at your commit first, before commenting :) It seems like your solution finds the location and then only sorts when inserting the content into the org file. Smart! I'd be happy to see a pull request!

You are right in regards the working of the solution. This looked like the most straightforward solution for now.
I saw your comment in the code regarding the archiving, but the ordering was the issue that first grabbed my attention :)
You mean, the ordering of sites in the response is not reliable?

I just realized,  that I completely misread your first comment (I think?). Never mind then...

Fixed in #4 thanks!


Imp: rename properties file and update scripts

@ranzpirat could you double check that the docker related files have been correctly updated everywhere?

The change to the Dockerfile is correct, we can actually deprecate/remove the gradle task and remove the related packaging file.


Mocha cannot find the inherited tsconfig even though it is present in node_modules

Prerequisites

[x] Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
[ x Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
[x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
[x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend that you not install Mocha globally.

Description

Unit tests run by mocha stopped working after the recent minor package update with the error:

✖ ERROR: error TS6053: File<EMAIL_ADDRESS>not found.

Steps to Reproduce

Checkout the https://github.com/appium/appium-windows-driver project
Run npm i
Run npm run test

Expected behavior: [What you expect to happen]
Unit tests are executed
Actual behavior: [What actually happens]

The above error message is shown. These tests were working properly before
Reproduces how often: [What percentage of the time does it reproduce?]
Always
Versions

The output of mocha --version and node_modules/.bin/mocha --version: 10.2.0/10.2.0
The output of node --version: v20.5.1
Your operating system

name and version: macOS 14.0
architecture (32 or 64-bit): arm64

Your shell (e.g., bash, zsh, PowerShell, cmd): zsh
Your browser and version (if running browser tests): -
Any third-party Mocha-related modules (and their versions): -
Any code transpiler (e.g., TypeScript, CoffeeScript, Babel) being used (and its version): TypeScript

Additional Information

tsconfig:
{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends"<EMAIL_ADDRESS>  "compilerOptions": {
    "strict": false,
    "outDir": "build",
    "types": ["node"],
    "checkJs": true
  },
  "include": [
    "index.js",
    "lib"
  ]
}

mocharc:
module.exports = {
  require: ['ts-node/register'],
  forbidOnly: Boolean(process.env.CI)
};

ls node_modules/@appium/tsconfig
LICENSE                 README.md               package.json            tsconfig.json           tsconfig.plugin.json

It looks like the issue started happening after bumping typescript from v5.2 to v5.3

The problem went away after this recent change for us: https://github.com/TypeStrong/ts-node/pull/2091

This isn't an issue in Mocha. Mocha doesn't run any TypeScript-specific logic. It's "just" a general test framework. Mocha provides APIs/hooks for tools such as ts-node. Those tools are the ones that do fancy things like search for TSConfigs and transpile TypeScript code to JavaScript.
That's why, as @davidsiu kindly pointed out, the solution ended up being in ts-node. 💯


Allow completion detail to accept a Node

Allows more complex styling of the text inside the completion detail.

What kind of styling are you planning to use this for? I'm somewhat weary of adding complex data structures like DOM nodes to completion objects, since when there are a lot of completions that could easily become a performance issue.

I’d like to add the type’s name with different colors for different types
and a short description in a different font. Since this is opt-in, we can
test for perf issues and it won’t affect other people who don’t use it. CM5
had the ability to do this, and having this allows us to migrate in a more
straightforward way.
On Sun, Sep 11, 2022 at 11:41 PM Marijn Haverbeke @.***>
wrote:

What kind of styling are you planning to use this for? I'm somewhat weary
of adding complex data structures like DOM nodes to completion objects,
since when there are a lot of completions that could easily become a
performance issue.
—
Reply to this email directly, view it on GitHub
https://github.com/codemirror/autocomplete/pull/13#issuecomment-1243286037,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACG263MMJ453UOIV7BQVXZTV53GCXANCNFSM6AAAAAAQI4C6QI
.
You are receiving this because you authored the thread.Message ID:
@.***>

optionClass can be used to add additional classes to the completion element based on its content (and thus to style the label and the detail text in a custom way). Would that help?

It looks like this gives the ability to add a class for the whole
completion, but not the ability to have separate styles within the detail
text (in my case, the type name and description).
On Tue, Sep 13, 2022 at 5:42 AM Marijn Haverbeke @.***>
wrote:

optionClass
https://codemirror.net/docs/ref/#autocomplete.autocompletion^config.optionClass
can be used to add additional classes to the completion element based on
its content (and thus to style the label and the detail text in a custom
way). Would that help?
—
Reply to this email directly, view it on GitHub
https://github.com/codemirror/autocomplete/pull/13#issuecomment-1245358318,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACG263MYKUNFT22GME7X2KDV6BZE5ANCNFSM6AAAAAAQI4C6QI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Right, but those already have other classes (cm-completionLabel and cm-completionInfo) that you can target with a scoped rule, no?

Here's some examples of what I would like to do, which I can't do by using the other classes:

I see. addToOptions is what you want there, I think. Add a new element to options that is rendered based on some extra information you put in the completion object.

Looks like this is what I need. Thanks.
On Tue, Sep 13, 2022 at 9:53 PM Marijn Haverbeke @.***>
wrote:

I see. addToOptions
https://codemirror.net/docs/ref/#autocomplete.autocompletion^config.addToOptions
is what you want there, I think. Add a new element to options that is
rendered based on some extra information you put in the completion object.
—
Reply to this email directly, view it on GitHub
https://github.com/codemirror/autocomplete/pull/13#issuecomment-1246231245,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACG263NBSGU6EV3XX5FFQUTV6FK3HANCNFSM6AAAAAAQI4C6QI
.
You are receiving this because you authored the thread.Message ID:
@.***>


added CODE_OF_CONDUCT.md

Hi Harshana,
There was a build issue with the project, which is now fixed and changes were merged to the master branch. Please update your PR with the changes so the build will pass. Then we can approve and merge the PR in to the master branch. Thank you for your valuable contribution. :)

@kasunkv I think we are safe to merge now.


Enable updating caveats

Abstract
This PR introduces the notion of "semantic caveats," i.e. caveats that have a semanticType property that means something in to the client (e.g. the MetaMask extension). The purpose of doing this is to enable the identification of specific caveats, such that they can be updated. This PR introduces the updateCaveatFor(domainName, methodName, caveat) method for this purpose.
Justification
To understand why we need something like this, consider an eth_accounts permission for some domain with the following caveats: [ filterResponse, filterResponse ]
Say the user wants to expose an additional account to the domain. One of the caveats is meant to enforce this restriction, but we cannot know which one without additional information about each caveat.
The alternative to this method would be to re-request the permission entirely with a new set of caveats, but I can't imagine a clean way of doing that in practice. In the eth_accounts example, you could argue that there's there will likely only ever be a single filterResponse caveat, in which it's not a problem. However, I think we have grand plans for this system, and the inability to easily determine the purpose of caveats will bite us in the ass sooner rather than later.
IMO, we should've used the type param on caveats the way this PR uses semanticType. Our current types describe what caveats do rather than why they exist. This is already something of a problem for e.g. the permissions settings page, where we can't easily describe the purpose of a caveat to an end user.
Specification
To enable this feature on a PermissionsController, the semanticCaveatTypes property must be specified on the constructor's config object. The format is made to be extensible, such that we can add additional configs for different semantic types. Currently, each permission can only have caveat of each semantic type specified in the config.
If this feature is enabled, all caveats of all permissions must specify their semanticType, otherwise adding them will fail. I'm agnostic about this behavior, but it does make things simpler.
The new method exposed, updateCaveatFor, also requires the semantic caveat feature to be enabled and the target caveat to have a valid semanticType.
Requested feedback

Should we add an updateCaveatsMiddleware and keep the updateCaveatsFor method internal?

I'm rolling this one back. I do think we need something like this, but there's a simpler solution, which is in the works.

Other possible approaches:

Record selected account info on the account-related permissions themselves.
make accounts a first-class dimension in the capabilities, as a “granter” field, for example. Then all permissions are per granter and per recipient and per function. We could also embed the granter in the parentcapability field, like ‘account:function’, becoming a sort of resource identifier.


.mjs is hard to use with SSR frameworks like NextJS

Hello,
I'm using rc.0 version of this library.
It seems you're publishing only .mjs files for workbox-window, but .mjs files are pretty new development and are hard to use with legacy or even new versions of frameworks like more resent and stable NextJS 7.0.2. Such feamework doesn't support .mjs files in dependencies and complain for builds with "unknown export keyword" errors.
Could you for the time being publish both .mjs and .js versions on npm? It would make it far easier to use this library.

Another reason is that for performance reasons for testing we use jsdom to render page on server side within node itself, without bundling the code. Currently we use Node 10 (stable!) which doesn't support .mjs files our of the box.

Here's specific error I'm getting after compiling my Next.js app that requires workdbox-window. If you can suggest other solution than you publishing version with .js files, I'd be fine as well :)
/Users/sheerun/Source/search/node_modules/workbox-window/build/workbox-window.prod.mjs:1

SyntaxError: Unexpected token export
    at new Script (vm.js:84:7)
    at createScript (vm.js:264:10)
    at Object.runInThisContext (vm.js:312:10)
    at Module._compile (internal/modules/cjs/loader.js:684:28)
    at Module._compile (/Users/sheerun/Source/search/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:732:10)
    at Object.newLoader [as .mjs] (/Users/sheerun/Source/search/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:620:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:560:12)
    at Function.Module._load (internal/modules/cjs/loader.js:552:3)
    at Function._load (/Users/sheerun/Source/search/node_modules/@sentry/node/src/integrations/console.ts:37:43)
    at Module.require (internal/modules/cjs/loader.js:657:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.<anonymous> (/Users/sheerun/Source/search/pages/_app.js:9:1)
    at Module._compile (internal/modules/cjs/loader.js:721:30)
    at Module._compile (/Users/sheerun/Source/search/node_modules/pirates/lib/index.js:83:24)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Also here's package.json of workbox-window:
  "main": "build/workbox-window.prod.mjs",
  "module": "index.mjs",

While module is indeed es6 module, I think main is supposed to be CJS-compatible script.

Sorry you're running into issues with this. We decided to use .mjs for workbox-window because every browser that supports service worker also supports importing modules and works fine with .mjs. Also every JavaScript bundler (Rollup, webpack, parcel) support modules and also works just fine with .mjs.
I wasn't aware that NextJS didn't support .mjs. I've talked to some of my colleagues who work with  the NextJS team and we've already filed a PR to fix this, so hopefully that'll get merged soon.
In my opinion, since all browsers and all bundling tools already support the .mjs file extension, and since node is moving forward with .mjs for all its modules, then it doesn't make sense for tools and application frameworks to not support it as well, so they should update. And I'm pretty sure NextJS will update.
In the meantime, you might try:

Copying the contents of Workbox.mjs into your application source and rename it to Workbox.js (obviously not ideal, but it should work as a temporary solution).
Create a symlink between a local Workbox.js file and the one in node_modules.
If NextJS lets you add or modify your webpack config, you could try adding the resolve plugin.

Another reason is that for performance reasons for testing we use jsdom to render page on server side within node itself, without bundling the code. Currently we use Node 10 (stable!) which doesn't support .mjs files out of the box.

For node, if you use esm it should be no problem to work with import statements and .mjs files. Have you tried using that to render pages server side? It's very easy to get started with.

Could you for the time being publish both .mjs and .js versions on npm? It would make it far easier to use this library.

This would be a bit tricky for us with our current publishing infrastructure. Right now we publish the file that corresponds to main in package.json to our CDN when we release new versions. For service worker packages, that's a .js file, but for workbox-window we want to publish the .mjs file to our CDN because using modules is the easiest way for modern browsers to consume that file.
For us to change this convention we'd have to rewrite our deployment infrastructure, and that most likely won't be a high priority for us.

Thank you for quick response and providing a workaround :)
I'll wait for Next.js to release fix, but other developers might not have as actively maintained frameworks available. Sure it would be nice touch to include CommonJS version for previous generation bundlers, but I won't argue on this. But I think using main is something I could argue:
As far as I am aware the convention of package.json fields is as follows:

main - CJS compatible entry file
module - ES6 modules entry file
browser - Browser compatible entry file

So maybe you might consider changing main in your packages to browser to not confuse developers (and bundlers) who expect this entry to be compatible with CommonJS environment.

You haven't yet released stable v4 so I think there's still time to change this.

I'm finding this a bit challenging as well, the recommended solution of using the following code doesn't work well as we use a strict CSP policy preventing using inline script tags.
<script type="module">
// Important: change the filename to workbox-window.prod.mjs before deploying.
import {Workbox} from 'https://storage.googleapis.com/workbox-cdn/releases/4.0.0-beta.1/workbox-window.dev.mjs'

new Workbox('/sw.js').register();
</script>

And we're excluding node_modules from compilation, so it's been a slog to get our babel/webpack combo to figure out how to allow this even outside of SSR.

Sure it would be nice touch to include CommonJS version for previous generation bundlers

@sheerun, I don't know of any JS bundlers that don't support .mjs or import/export statements in the source files. The problem you were encountering with NextJS is they were explicitly not including .mjs files in their webpack config. Webpack can handle them just fine, so it's an easy fix for NextJS (and it looks like the fix has already been merged).

As far as I am aware the convention of package.json fields is as follows...

I agree that putting an .mjs file in main is a deviation from standard node conventions.
This is an artifact of our deployment code (which assumes the file in the main field gets uploaded to our CDN) being written before we had a workbox-window package. We should probably decouple these things now (i.e. not use the main field for CDN related data), but that still won't solve your problem unless we also generate a CJS/UMD version.
I could look into adding that, but I'm not sure if we want to block the v4 release on it. I'm not sure realistically how many people are going to need workbox-window to work with require() in node.
@jeffposnick any thoughts on this?

I'm finding this a bit challenging as well, the recommended solution of using the following code doesn't work well as we use a strict CSP policy preventing using inline script tags.

@calinoracation you definitely don't need to use an inline <script> tag, that was just supposed to be an example and not a recommendation. You can put the contents of that inline <script> into its own file and load it via <script type="module" src="path/to/sw-loader.mjs">.

And we're excluding node_modules from compilation, so it's been a slog to get our babel/webpack combo to figure out how to allow this even outside of SSR.

Hmmm, this is a trickier issue because we're definitely not going to publish an ES5 version of any Workbox packages. All browsers that support service worker also support ES modules, so it would be quite wasteful to ship ES5 code to those browsers.
I'd recommend trying to compile your SW-related window code separately from your main bundle. You could then load it via <script type="module">, and it should work fine in all browsers that support service worker.
I'd also strongly recommend you try to change your policy on transpiling node_modules. The number of npm packages being published with only ES2015+ source code is growing every day, and by limiting yourself to ES5-only code, your missing out on these libraries, and you're also likely shipping much larger bundles to your users than you need to be.

@sheerun after looking at our deployment code, I don't think it'd be much work at all to generate both a native module and a UMD bundle (which I've confirmed works with require() in node), so I'll try to do that before releasing v4.

@philipwalton I'm reporting that unfortunately https://github.com/zeit/next.js/pull/6253/files doesn't fix my problem because .mjs file of workbox are ignored by this line:
return /node_modules/.exec(path)

Thanks for the UMD bundle change, it will help us a ton!
Does this UMD bundle mean that by importing the package will always result in a production build? I'm not sure the implications or if there's a resolve path to get the dev one that we should be using, but thought I'd mention it in case it wasn't intentional.

I'd also strongly recommend you try to change your policy on transpiling node_modules. The number of npm packages being published with only ES2015+ source code is growing every day, and by limiting yourself to ES5-only code, your missing out on these libraries, and you're also likely shipping much larger bundles to your users than you need to be.

Thanks for that recommendation, we may look into it but it's a pretty risky change for us with such a large codebase and already super long build times and wasn't super feasible for us at this time.
Again thanks so much, we're already benefiting from the changes in v4 and are excited for all of these new features to land!

I'm reporting that unfortunately https://github.com/zeit/next.js/pull/6253/files doesn't fix my problem because .mjs files of workbox are ignored by this line:

@sheerun If I understand correctly that line will exclude workbox-window from the babel transpilation, but it won't exclude it from your app. Is that your issue? That it's not being transpiled?

Does this UMD bundle mean that by importing the package will always result in a production build? I'm not sure the implications or if there's a resolve path to get the dev one that we should be using, but thought I'd mention it in case it wasn't intentional.

@calinoracation yes, if you run require('workbox-window') in node, you'll get the production bundle. If you want to get the development bundle you'd have to do `require('workbox-window/build/workbox-window.dev.umd.js');

@philipwalton any reason not to put the dev bundle in "main" and the production one in "browser", or, to use process.env.NODE_ENV to switch between the two in a single entry point, as is common?

@ljharb can you describe the ideal setup you'd like to see?
We use process.env.NODE_ENV internally in our source for dev-only code, but we strip that out at publish time and create two separate prod and dev builds. We do this because process is not a global in browser environments.
If all bundlers support the browser field of package.json (I think they do?), then I'd be fine with setting it in our package.json, but I'm still unclear as to why you'd want a dev version in node. I'm also hesitant because my understanding is webpack will favor the browser field over the module field if both are present.

hmm, that webpack thing is a fair point.
However - if you had an extensionless browser pointing to a production UMD .js file and also a production .mjs file, and extensionless "main" pointing to a development CJS .js file and also a development .mjs file, would that work?

Ok, after discussing this with the rest of the team, here's what we're going to do. Hopefully this will make it as easy as possible to consume workbox-window in a variety of situations while still allowing those that don't need (or want) to ship ES5 code to be able to do so.
In https://github.com/GoogleChrome/workbox/pull/1899, I've updated the build to include a module version transpiled to ES5. That means we should be able to support all of the following situations:

Requiring workbox-window in a node:

// Imports a UMD version with ES5 syntax
const {Workbox} = require('workbox-window');

Importing workbox-window via webpack or Rollup in a context where your build does not automatically transpile anything in node_modules:

// Imports the module version with ES5 syntax
import {Workbox} from 'workbox-window';

Importing workbox-window via webpack or Rollup in a context where you handle transpiling yourself (or you don't need to transpile to ES5):

// Imports the module version with ES5 syntax
import {Workbox} from 'workbox-window/Workbox.mjs';

Does this address all the issues raised here?

I think this is perfect now
The only issue is one I mentioned earlier, Next.JS supports now .mjs but ignores all .mjs modules in node_modules directory, so it'll take UMD bundle instead of MJS which could save some bundle size.
Probably it would be better to un-ignore just .mjs files from node_modules?

@sheerun I'm pretty sure Next will take the .mjs version, it just won't transpile it (which is fine since by default it's already transpiled if you just reference workbox-window).
And we'll likely release these changes today as a new release candidate, so you should be able to test and confirm before we release the final v4.

It's not a problem with workbox but next.js

I'm pretty sure Next will take the .mjs version, it just won't transpile it

That's exactly what's happening. Webpack takes .mjs and throws it into the bundle along with "exports xxx" statement which doesn't work when bundled among other js files into single file.

Webpack should remove the export statements itself, it shouldn't depend on Babel to do that.
I'm bundling workbox-window on a project right now using webpack, and even if I exclude all node_modules from transpilation in babel-loader, workbox-window still gets included in the bundle, and it doesn't contain any export statements.
We can confirm after the next release candidate is released.

Workbox version 4.0.0-rc.1 has been released, so please try it out and let me know if anything is still not working.

It's working fine but I believe it's because webpack takes umd bundle instead of module (module is set as fallback field https://github.com/zeit/next.js/pull/6256)
Anyway, you can close this as it's not workbox issue anymore, thank you :)

This is working fantastically for us now, thanks folks!


Replace old reactive API docs

Hello.
I've replaced old reactive API docs in README.md.
This is for v5.0.x, v5.1.x and master branches.
Thank you.

Thanks a lot. That's merged now.


switch edgeRouting

https://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/KIML+Layout+Options#KIMLLayoutOptions-edgeRouting

ORTHOGONAL - current
POLYLINE - will probably just work
SPLINES - might have enough control points to not need to get fancy with subdivision ()

ohhhhh, these are all so good - I'm really digging the orthogonal one
especially; reminds me of circuit boards / transit maps :O :D
On Tue, Nov 1, 2016 at 5:59 PM Forrest Oliphant<EMAIL_ADDRESS>wrote:

https://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/KIML+Layout+Options#KIMLLayoutOptions-edgeRouting

ORTHOGONAL - current
POLYLINE - will probably just work
SPLINES - might have enough control points to not need to get fancy
with subdivision (
https://camo.githubusercontent.com/bbac15791f17d7faaa0214ac666e87e9698c3cb4/68747470733a2f2f75706c6f61642e77696b696d656469612e6f72672f77696b6970656469612f636f6d6d6f6e732f7468756d622f642f64622f422543332541397a6965725f335f6269672e6769662f32343070782d422543332541397a6965725f335f6269672e676966
)

https://camo.githubusercontent.com/bfab5f643d66c870917615d5f61d2779b089eb5b/68747470733a2f2f72747379732e696e666f726d6174696b2e756e692d6b69656c2e64652f636f6e666c75656e63652f646f776e6c6f61642f6174746163686d656e74732f373131313039342f656467655f726f7574696e672e706e673f76657273696f6e3d31266d6f64696669636174696f6e446174653d31333934333039393430303030266170693d7632
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/forresto/choo-graph-viz/issues/2, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlegkIfHr0UXrAcbJtU0T-dQR0gqcEks5q52_sgaJpZM4KmUhZ
.


Updated MongoStore in app.js

Changed the MongoStore code as per new format
app.use(session({ 	secret: 'keyboard cat', 	resave: false, 	saveUninitialized: false, 	store: MongoStore.create({ 		mongoUrl: process.env.MONGO_URI 	})       }))

This is really important for new learners. Hopefully this is merged soon.


Progress Bar and text overlap in Tickets fragment.

Describe the bug

Find my tickets text is overlapped by the progress bar.
To Reproduce

Go to the tickets fragment.
Expected behavior

Proper spacing should be provided between the elements
Logs

Screenshots

Smartphone Info:

|Device         |One Plus 5|
|Android Version|9.0.0|
Additional context

Would you like to work on the issue?

[x] Yes
[ ] No
Other:
@iamareebjamal Should I go ahead?

@nikit19 Should I go ahead?

Solved with PR #829 @iamareebjamal  @nikit19


exposure documentation for infrastructure

exposure documentation (examples, taxonomy) relates only to buildings - we should include examples and codes possible to use for infrastructure too at the highest level (this is only visible when user clicks on ged4all taxonomy) to clearly demonstrate support for these exposure types

Agree, and the page https://docs.riskdatalibrary.org/exposure.html should be added to the Exposure section.

The attributes given in the table and examples are only part of what can be completed. I think the value fields should also be included in the table explicitly, rather than mentioned in the text only.


model open

Excuse me, will the model be open source? Looking forward to try the effect.

We have provided an example checkpoint of SUR-adapter [Google Drive]. Please try it!


Focus is  not switching after using Open Expose View

After selecting a Window at "Open Expose View" and then selecting another window by normaly clicking on it, it won't get focus so you can't use the buttons of the window anymore.
Like you can see in the screenshot

Thanks for your comment! Same happened to us, when we reproduced this bug.
However, we tracked down the reason for this obviously wrong behavior -- we called the wrong methods in order to bring the selected window to front after using the dashboard.
It'll be fixed in the very next release (coming on tuesday)!

'sent the wrong message' coughcough


Issue with MDNS v1.2.1  (IDFGH-11221)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.0.1
Espressif SoC revision.
ESP32-D0WD-V3
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
Custom Board
Power Supply used.
USB
What is the expected behavior?
I expect the mDNS 1.2.1 to work exactly the same as 1.2.0. I did not have any issues with the 1.2.0 as I can reach my webserver by using mDNS instance name.
What is the actual behavior?
mDNS not working when updated to the latest version (1.2.1) due to ERR_NAME_NOT_RESOLVED error:

It loads for about 15 seconds and then returns an error:

I am able to capture mDNS packets using wire shark but cannot figure out why any browser fails to connect to it:

Steps to reproduce.
Change the version of the mdns component in idf_component.yml from 1.2.0 to 1.2.1 and rebuild the project.
Debug Logs.
N/A

More Information.
We use the following function to setup the mDNS:
static void wifi_mdns_init(void) {
    esp_err_t err = ESP_OK;
    err           = mdns_init();
    if (err != ESP_OK) {
        TraceErrWIFI("mDNS INIT: FAILED (%s)", esp_err_to_name(err));
        return;
    }
    err = mdns_hostname_set(CONFIG_LWIP_LOCAL_HOSTNAME);
    if (err != ESP_OK) {
        TraceErrWIFI("HOSTNAME: FAILED (%s)", esp_err_to_name(err));
        return;
    }
    err = mdns_instance_name_set(CONFIG_LWIP_LOCAL_HOSTNAME);
    if (err != ESP_OK) {
        TraceErrWIFI("INSTANCE: FAILED (%s)", esp_err_to_name(err));
        return;
    }
    err = mdns_service_add("XXXXXXX-XXXXX", "_http", "_tcp", 80, NULL, 0);
    if (err != ESP_OK) {
        TraceErrWIFI("SERVICE: FAILED (%s)", esp_err_to_name(err));
        return;
    }
}

I have also noticed that for mdns 1.2.1 , the following flag is used: CONFIG_ESP_WIFI_ENABLED however this does not even exist in my sdkconfig.h. How is that even possible?

For now, I am using mDNS version 1.2.0 but I am just really curious what could be an issue with the 1.2.1 and what could cause this failure. Any ideas are appreciated!

@krupis thank you for reporting.
As I understand, you want to configure mdns over the WIFI interface, right?
The problem, as you noted, is the absence of CONFIG_ESP_WIFI_ENABLED in your sdkconfig.h. This is needed to register mdns event handlers.
Could you please check if CONFIG_ESP_WIFI_ENABLED is enabled in the sdkconfig (this file used to generate sdkconfig.h) file? If it's not, it should be enabled so that mdns can register events over the WIFI interface.

@gabsuren
Thanks for response.
CONFIG_ESP_WIFI_ENABLED also does not exist in my sdkconfig. I am using esp-idf version 5.0.1

After createing sdkconfig.defaults, please executed idf.py reconfigure or remove skconfig and call idf.py build/menuconfig again

Updated: The issues is coming that CONFIG_ESP_WIFI_ENABLED is not exists in esp-idf 5.0.1. I will fix it soon.
For quick fix there are a few options.

Revert this commit 24f7031  : fix(mdns): fix build issue if CONFIG_ESP_WIFI_ENABLED disabled
Add new config in Kconfig

Use latest ESP-IDF

Meanwhile I will fix the issue for official branch

I can confirm that adding ESP_WIFI_ENABLED  in Kconfig fixed the issue.


Tests Fail Immediately

Describe the bug
After running the detox test command, the tests fail before doing any actions in a couple of seconds. The metro-bundler runs but the app doesn't launch past the splash screen. If I close the app and open it again the app is irresponsive. It moves past the splash screen but the buttons do not work. Running the app through XCode works fine.
To Reproduce

[x] I have tested this issue on the latest Detox release and it still reproduces

Environment (please complete the following information):

Detox: 13.2.0
React Native: 0.60.3
Node: 10.15.3
Device: iPhone 7
Xcode: 10.2.1
iOS: 12.2
macOS: 10.14.3

Device and Verbose Detox Logs
logs.txt
XCode log: https://gist.github.com/ReshmiCode/d79d6652a5373256147b1bac20c49cb0

I am sorry, but this looks like a log from Detox earlier than 13.2.0.
If this is indeed 13.2.0, please add the following launch argument to your scheme in Detox and post the Xcode log again: -enableAppDelegateVerboseLogging YES.
Thanks

Also, do you use any analytic frameworks?

I think I was using the Detox.framework from the older version but this one should be updated.
logs.txt
We use Mixpanel, Amplitude, and Firebase for analytics.

Did you add the -enableAppDelegateVerboseLogging YES launch argument?

Yup

Please disable the OS_ACTIVITY_MODE environment variable and attach log again. Could be why I am seeing nothing from Detox.

Is this better? https://gist.github.com/ReshmiCode/3a05e8495033f1544681c9609a16119f
The bottom seemed to be cut off so I just commented it.

Yes, much better now. This is an old Detox.

Is there some way I can check which version it is in the framework file? I deleted the folders in Library/Detox and ran npm i again to regenerate what I thought was the new version. In the repo I ran detox --version and 13.2.0 appears.

detox version I think only prints what is in package.json.
Make sure the project doesn't include any Detox. run detox rebuild-framework-cache and then try again. You should not be testing with the ios.none configuration.

After doing that I get:
logs.txt
I'm fairly certain it was updated properly before because I received the exception breakpoint at a different location than before the update. I could do another video run through if you'd like.
This crash is occurring before I run the tests command. I don't have the ios.none config in the project.
This is the closet relevant looking log to the bottom of the XCode console.
2019-07-23 10:52:01.664338-0500 Fanguru[55027:1662837] [DetoxManager] Using default 'detoxServer': ws://localhost:8099 2019-07-23 10:52:01.664546-0500 Fanguru[55027:1662837] [DetoxManager] Using default 'detoxSessionId': guru.fan.app 2019-07-23 10:52:01.669413-0500 Fanguru[55027:1663223] [] nw_socket_handle_socket_event [C21.1:1] Socket SO_ERROR [61: Connection refused] 2019-07-23 10:52:01.670968-0500 Fanguru[55027:1663223] [] nw_socket_handle_socket_event [C21.2:1] Socket SO_ERROR [61: Connection refused] 2019-07-23 10:52:01.671710-0500 Fanguru[55027:1663211] [] nw_connection_get_connected_socket [C21] Client called nw_connection_get_connected_socket on unconnected nw_connection 2019-07-23 10:52:01.672189-0500 Fanguru[55027:1662837] [DetoxManager] Web socket failed to connect with error: Error Domain=NSPOSIXErrorDomain Code=61 "Connection refused" UserInfo={_kCFStreamErrorCodeKey=61, _kCFStreamErrorDomainKey=1}
And this is where the crash takes me to at first

If you are running from Xcode, you are most likely using an old version. Remove all traces from Detox inside your project.

So the folder in node_modules and the line from package.json?

If possible revert all changes you've made to your project while debugging the previous issue.
I will close this one as this issue was solved already in 13.2.0.

@LeoNatan Is it not a different issue than the previous issue I was facing? Since the update, the tests fail differently than before. If I run the tests not through XCode (w/ the updated Detox) I get the first log I attached in the description.

I think it isn't.
  * frame #2: 0x00000001073f00fa Detox`-[DetoxAppDelegateProxy applicationDidBecomeActive:](self=0x0000600003665640, _cmd="applicationDidBecomeActive:", application=0x0000000000000000) at DetoxAppDelegateProxy.m:317
    frame #3: 0x00000001073f017d Detox`-[DetoxAppDelegateProxy applicationDidBecomeActive:](self=0x0000600003665640, _cmd="applicationDidBecomeActive:", application=0x00007f970c707300) at DetoxAppDelegateProxy.m:323:3
    frame #4: 0x00000001073f017d Detox`-[DetoxAppDelegateProxy applicationDidBecomeActive:](self=0x0000600003665640, _cmd="applicationDidBecomeActive:", application=0x00007f970c707300) at DetoxAppDelegateProxy.m:323:3
    frame #5: 0x00000001073f017d Detox`-[DetoxAppDelegateProxy applicationDidBecomeActive:](self=0x0000600003665640, _cmd="applicationDidBecomeActive:", application=0x00007f970c707300) at DetoxAppDelegateProxy.m:323:3
    frame #6: 0x00000001073f017d Detox`-[DetoxAppDelegateProxy applicationDidBecomeActive:](self=0x0000600003665640, _cmd="applicationDidBecomeActive:", application=0x00007f970c707300) at DetoxAppDelegateProxy.m:323:3
    frame #7: 0x00000001073f017d Detox`-[DetoxAppDelegateProxy applicationDidBecomeActive:](self=0x0000600003665640, _cmd="applicationDidBecomeActive:", application=0x00007f970c707300) at DetoxAppDelegateProxy.m:323:3

cannot happen with the latest Detox. This is why I immediately suspected that was it.

You can see recent line 323:
https://github.com/wix/Detox/blob/52a567f735c68ea8cc77a61d00215e4a601878bc/detox/ios/Detox/DetoxAppDelegateProxy.m#L323
with old:
https://github.com/wix/Detox/blob/1627025cb31376e4540a8e960374fe1e9cc79edb/detox/ios/Detox/DetoxAppDelegateProxy.m#L323
super_class(&super, _cmd, application); is the call to the super implementation, that due to bad swizzling, caused a stack overflow (infinite recursion).

Now that I compared the lines, I am 100% sure you are using an old Detox.

Wait. I might be mixing up logs.
 Signal 11 was raised
(
	0   Detox                               0x000000010a650186 _ZL16__DTXHandleCrashP11NSExceptionP8NSNumberP8NSString + 497
	1   Detox                               0x000000010a64ff0b _ZL17__DTXHandleSignali + 61
	2   libsystem_platform.dylib            0x00000001134f6b5d _sigtramp + 29
	3   ???                                 0x0000600002fb5b50 0x0 +<PHONE_NUMBER>93840
	4   UIKitCore                           0x000000011c80e311 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 280
	5   UIKitCore                           0x000000011c80fcad -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3932
	6   UIKitCore                           0x000000011c8150c6 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1617
	7   UIKitCore                           0x000000011c05a6d6 __111-[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:]_block_invoke + 904
	8   UIKitCore                           0x000000011c062fce +[_UICanvas _enqueuePostSettingUpdateTransactionBlock:] + 153
	9   UIKitCore                           0x000000011c05a2ec -[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:] + 236
	10  UIKitCore                           0x000000011c05ac48 -[__UICanvasLifecycleMonitor_Compatability activateEventsOnly:withContext:completion:] + 1091
	11  UIKitCore                           0x000000011c058fba __82-[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]_block_invoke + 782
	12  UIKitCore                           0x000000011c058c71 -[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:] + 433
	13  UIKitCore                           0x000000011c05d9b6 __125-[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]_block_invoke + 576
	14  UIKitCore                           0x000000011c05e610 _performActionsWithDelayForTransitionContext + 100
	15  UIKitCore                           0x000000011c05d71d -[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:] + 223
	16  UIKitCore                           0x000000011c0626d0 -[_UICanvas scene:didUpdateWithDiff:transitionContext:completion:] + 392
	17  UIKitCore                           0x000000011c8139a8 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 514
	18  UIKitCore                           0x000000011c3cadfa -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 361
	19  FrontBoardServices                  0x0000000119ada125 -[FBSSceneImpl _didCreateWithTransitionContext:completion:] + 448
	20  FrontBoardServices                  0x0000000119ae3ed6 __56-[FBSWorkspace client:handleCreateScene:withCompletion:]_block_invoke_2 + 283
	21  FrontBoardServices                  0x0000000119ae3700 __40-[FBSWorkspace _performDelegateCallOut:]_block_invoke + 53
	22  libdispatch.dylib                   0x0000000113124d02 _dispatch_client_callout + 8
	23  libdispatch.dylib                   0x0000000113127d41 _dispatch_block_invoke_direct + 295
	24  FrontBoardServices                  0x0000000119b15146 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 30
	25  FrontBoardServices                  0x0000000119b14dfe -[FBSSerialQueue _performNext] + 451
	26  FrontBoardServices                  0x0000000119b15393 -[FBSSerialQueue _performNextFromRunLoopSource] + 42
	27  CoreFoundation                      0x000000010ff38be1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	28  CoreFoundation                      0x000000010ff38463 __CFRunLoopDoSources0 + 243
	29  CoreFoundation                      0x000000010ff32b1f __CFRunLoopRun + 1231
	30  CoreFoundation                      0x000000010ff32302 CFRunLoopRunSpecific + 626
	31  GraphicsServices                    0x0000000114df82fe GSEventRunModal + 65
	32  Detox                               0x000000010a645d68 __detox_UIApplication_run + 365
	33  UIKitCore                           0x000000011c816ba2 UIApplicationMain + 140
	34  Fanguru                             0x0000000108a61410 main + 112
	35  libdyld.dylib                       0x0000000113192541 start + 1
)

Hmm. So I will ask you to please follow again the steps you did, but with the latest Detox. Your Detox.framework was cached somehow, and so it was outdated. With the latest Detox.framework from node_modules, try to run from Xcode.

This is the log generated using the Detox.xcodeproj from when I recursively clone the Detox repo. Inside the folder, I checked line 323 of DetoxAppDelegateProxy.m and it matched the new one.
Now my XCode console has an infinite loop of the web socket failing. I do see AppDelegateProxy in it though. https://gist.github.com/ReshmiCode/a53a13b539bd50016792f2934957ad34

Did you reproduce the issue here in this log? I see Detox is in stand-by, waiting for a server to start.

Please follow our discussion in the previous issue to run your test from ios.none.

I deleted Library/Detox and the Detox node modules and ran npm i. If I follow the ios.none stuff using Detox.framework from the node modules, the tests run but if I go it through detox build and test the normal way I'm still getting the original error. Is there some reason for this?

Hmm I can't think of any. In both cases, the same framework is used.
Let's try to debug the problem without Xcode (the flow that is broken).
Open a new terminal and run the following command:
xcrun simctl spawn booted log stream --style compact --process "<your binary name>" --predicate "subsystem != 'CFNetwork' || subsystem != 'com.apple.network'"

Then reproduce your issue and attach the log from the above command.

I'm not getting a log. The binary name is the bundle id right?
https://www.loom.com/share/b7977ae73ef843c9a3657f9f92ed48d2

The binary name is the binary name, not the bundle id. You can find out what it is by inspecting the CFBundleExecutable key in the Info.plist of your app.

https://gist.github.com/ReshmiCode/de0081620490a5dae507fb055e8fafeb

No Detox logs in that one.

Was I supposed to keep anything from before? I removed everything.

@henrymoulton Please follow this guide: https://github.com/wix/Detox/blob/master/docs/Guide.DebuggingInXcode.md
Add exceptions breakpoint and add -enableAppDelegateVerboseLogging YES. Run from Xcode, reproduce and attach the log from Xcode here. Thanks

Terminal output:
https://gist.github.com/henrymoulton/3dabcbc549d0973f067b2ee2f52281f1
Log1:
https://gist.github.com/henrymoulton/82a20c30efa3449e570e4b93f34bdbd3
Log2:
https://gist.github.com/henrymoulton/04c4a128eb789938d136fa97d78931ad
Log3:
https://gist.github.com/henrymoulton/cafa7671b823242065999d80b7a8ab5a
Not sure this will be helpful as tests aren't running, let me know what I can do to provide further logs.
Thanks!

I don't see the crash happening in the logs provided.

Even if I run the same command with the working tests using the XCode config, the logs don't have anything Detox related
https://gist.github.com/ReshmiCode/c2a1dcfe7b733666aeeee92c7f9d73c2

Is this issue related? https://github.com/wix/Detox/issues/1525

detox[42222] ERROR: [Detox.js/APP_CRASH] App crashed in test 'edit profile should successfully update all their details', here's the native stack trace:
Signal 11 was raised
(
        0   Detox                               0x0000000102875186 _ZL16__DTXHandleCrashP11NSExceptionP8NSNumberP8NSString + 497
        1   Detox                               0x0000000102874f0b _ZL17__DTXHandleSignali + 61
        2   libsystem_platform.dylib            0x00000001093c3b5d _sigtramp + 29
        3   ???                                 0x0000000000600000 0x0 + 6291456
        4   UIKitCore                           0x000000011124a731 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 280
        5   UIKitCore                           0x000000011124c0cd -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3932
        6   UIKitCore                           0x00000001112514e6 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1617
        7   UIKitCore                           0x0000000110a95a4e __111-[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:]_block_invoke + 904
        8   UIKitCore                           0x0000000110a9e346 +[_UICanvas _enqueuePostSettingUpdateTransactionBlock:] + 153
        9   UIKitCore                           0x0000000110a95664 -[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:] + 236
        10  UIKitCore                           0x0000000110a95fc0 -[__UICanvasLifecycleMonitor_Compatability activateEventsOnly:withContext:completion:] + 1091
        11  UIKitCore                           0x0000000110a94332 __82-[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]_block_invoke + 782
        12  UIKitCore                           0x0000000110a93fe9 -[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:] + 433
        13  UIKitCore                           0x0000000110a98d2e __125-[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]_block_invoke + 576
        14  UIKitCore                           0x0000000110a99988 _performActionsWithDelayForTransitionContext + 100
        15  UIKitCore                           0x0000000110a98a95 -[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:] + 223
        16  UIKitCore                           0x0000000110a9da48 -[_UICanvas scene:didUpdateWithDiff:transitionContext:completion:] + 392
        17  UIKitCore                           0x000000011124fdc8 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 514
        18  UIKitCore                           0x0000000110e0702f -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 361
        19  FrontBoardServices                  0x000000010c43dd25 -[FBSSceneImpl _didCreateWithTransitionContext:completion:] + 448
        20  FrontBoardServices                  0x000000010c447ad6 __56-[FBSWorkspace client:handleCreateScene:withCompletion:]_block_invoke_2 + 283
        21  FrontBoardServices                  0x000000010c447300 __40-[FBSWorkspace _performDelegateCallOut:]_block_invoke + 53
        22  libdispatch.dylib                   0x0000000108ff1d02 _dispatch_client_callout + 8
        23  libdispatch.dylib                   0x0000000108ff4d41 _dispatch_block_invoke_direct + 295
        24  FrontBoardServices                  0x000000010c4790da __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 30
        25  FrontBoardServices                  0x000000010c478d92 -[FBSSerialQueue _performNext] + 451
        26  FrontBoardServices                  0x000000010c479327 -[FBSSerialQueue _performNextFromRunLoopSource] + 42
        27  CoreFoundation                      0x0000000105b99db1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
        28  CoreFoundation                      0x0000000105b99633 __CFRunLoopDoSources0 + 243
        29  CoreFoundation                      0x0000000105b93cef __CFRunLoopRun + 1231
        30  CoreFoundation                      0x0000000105b934d2 CFRunLoopRunSpecific + 626
        31  GraphicsServices                    0x000000010d5422fe GSEventRunModal + 65
        32  Detox                               0x000000010286a968 __detox_UIApplication_run + 365
        33  UIKitCore                           0x0000000111252fc2 UIApplicationMain + 140
        34  RedactedApp                        0x0000000101951214 main + 80
        35  libdyld.dylib                       0x000000010905f541 start + 1
)

Same error on my machine on 13.3.1

I need the full logs as requested above.
The linked issue was something I fixed with the current code.

Ok thanks @LeoNatan I struggled to get a log because when I ran in that mode via xCode as instructed Detox didn't start/didn't get any logs. This seems similar to what @ReshmiCode reported.

If you have that environment variable set, please remove it. If you are not debugging the process, set it to debug. Otherwise, there is no reason why the logs would not appear when running in Xcode. Unless those logs are provided, I cannot help, as I have not been able to reproduce this.

Apologies, still struggling to produce a log here.

If you have that environment variable set, please remove it. If you are not debugging the process, set it to debug.

Does this look correct?

Detox server running:

Test runner output with a specific test selected:

Logs from within the Xcode window:
Log1
Log2
I've tried the other way of getting the log you suggested in the thread:
xcrun simctl spawn booted log stream --style compact --process "<your binary name>" --predicate "subsystem != 'CFNetwork' || subsystem != 'com.apple.network'"
however I wasn't able to get a log from that either.
I went to a React Native meetup where they some people suggested downgrading the applesimutils, but I'm reluctant to do so as I assume it would mean not being able to use future versions of Xcode.

applesimutils has nothing to do with the problem. When running from Xcode, applesimutils is not used.
In the Xcode logs you have posted, I see Detox logs, but you have not reproduced there the crash. Try to focus on the specific test that reproduces the crash, set it as .only and try running as your are running now.

I have set .only to the initial test that runs in the test suite.
However the behaviour of the simulator when it starts is to timeout with nothing happening.

Just to make sure, the following order should be followed:
run-server
Play in Xcode
detox test
When running like this, do you see nothing happen in the simulator?

Yes that's the order I'm using, nothing is happening in simulator.

Happy to send a video recording privately.

Contact me at lnatan [at} wix.com

Sent, thanks in advance.

@ReshmiCode, I've sent the video to @LeoNatan and he confirmed that even with the setup there wasn't a Detox log / Detox wasn't able to start.
When using the example projects https://github.com/wix/Detox/tree/master/examples I find that the tests do run.
That makes me think that the React Native project's dependencies are causing an issue for Detox to start.
Looking inside my AppDelegate.m file I find:
#import "AppDelegate.h"
#import <CodePush/CodePush.h>

#import <React/RCTBridge.h>
#import <React/RCTBundleURLProvider.h>
#import <React/RCTRootView.h>
#import <Fabric/Fabric.h>
#import <Crashlytics/Crashlytics.h>
#import "Firebase.h"
#import <React/RCTPushNotificationManager.h>
#import "RNSplashScreen.h"

Are there any similar dependencies you have that you suspect have recently changed/added that might have caused this freeze?

My assumption is that the fix inside 13.2.0 that fixes #1525 still doesn't fix some projects

@henrymoulton After a certain pr (the RN update to 0.60.3) our iOS tests start breaking. They used to have the timeout error but with the newer Detox version they started failing almost immediately and throwing the signal 11 error. If I use Detox.framework from either my node modules or from the Detox repo the tests run (can't remember which).
The only thing that had been edited from AppDelegate.m recently was removing #import <CodePush/CodePush.h> but that wasn't in the breaking pr.
Ours currently looks like:
#import <React/RCTBridge.h> #import <React/RCTBridgeModule.h> #import <Fabric/Fabric.h> #import <Crashlytics/Crashlytics.h> #import <React/RCTBundleURLProvider.h> #import <React/RCTRootView.h> #import <FBSDKCoreKit/FBSDKCoreKit.h> #import <React/RCTLinkingManager.h> #import "RNBranch.h" #import "Orientation.h" #import <Firebase.h> #import "RNFirebaseMessaging.h" #import "RNFirebaseNotifications.h" #import "RNSplashScreen.h" #import <BugsnagReactNative/BugsnagReactNative.h>

Ok so we have common dependencies on:
#import <Fabric/Fabric.h>
#import <Crashlytics/Crashlytics.h>
#import <Firebase.h>
#import "RNSplashScreen.h"

@ReshmiCode can you try seeing if downgrading to 12.11.3 works for you?

@henrymoulton downgrading does make it work!

Awesome it does for me too! @LeoNatan do any of the four dependencies we share feel like it would break Detox from v12 to v13?
I can probably tackle debugging with adding one or two using the example projects, perhaps @ReshmiCode has time to debug the other two.

13.2.0 was released because of an analytics framework. Don't remember which one. Please reproduce on a demo project so I can investigate.

Will try Firebase. @ReshmiCode do you use Cocoapods in your project?

Yeah we use Cocoapods @henrymoulton

@LeoNatan I was able to make a reproducible repo with Crashlytics and Fabric.
https://github.com/ReshmiCode/Detox-Test/tree/breaking-stuff

Great. Please do not remove this repository. I will take a look soon.

+1 I have the same problem

The repo throws the following exception:
[Fabric] Value of Info.plist key "Fabric" must be a NSDictionary.

@ReshmiCode

@LeoNatan the exception appears in which step of the process? Running detox build and detox test (-c ios) reproduces the issue.
I've added the minimum integration possible to reproduce the bug so I might have missed a setup step as I wasn't the one to originally add these dependencies to our project.

The app is crashing on launch:

It crashes because you haven't provided the necessary information in Info.plist. The crash you are seeing when running tests is not the one reported here.

Try to run your app in Xcode without tests. Once you fix all issues, let me know.

@LeoNatan pushed a fix, it now properly builds and launches through XCode

I am starting to get impatient here. After your fix, the test succeeds.

Please make an effort to have working project before posting it here.

I have the same problem but I'm not using Crashlytics and Fabric.
My common dependencies with @ReshmiCode and @ReshmiCode henrymoulton are Firebase and RNSplashScreen.
#import <Firebase.h>
#import "RNSplashScreen.h"

Please try to create clean project with Firebase and Splash screen and see if the issue reproduces. Thank you.

I was able to make a working project with RN Splash Screen so just Firebase is left. @henrymoulton have you had a chance to make a repo with it?

Sorry haven't had a chance, once I saw you'd submitted a broken build I waited for that to resolve. What version of react-native-firebase are you using?

I have the same problem and I have version 5.5.5
 "react-native-firebase": "^5.5.5",

Thanks for confirmation @redbluenat, @ReshmiCode what's a way to contact you, email? Also have some questions about your jest-circus setup I saw in another thread.

@henrymoulton I'm using version 5.2.3. You can contact me at<EMAIL_ADDRESS>

Haven't been able to get Firebase to compile using the Detox example as a boilerplate. Ran into this issue https://github.com/invertase/react-native-firebase/issues/321 and don't have time to look into further

Wait. I might be mixing up logs.

I am getting the same error as your log. Have you investigated that? Note: I am also using firebase.

Disabling RNSplashScreen in AppDelegate.m fixes the signal 11 crash for me.
//  [RNSplashScreen show];

@yairganon it fixed for me too, but it is not really a solution because I need to show splash :/

@ywongweb 	solution works for me too, I wrapped the line using our env variables
We are using react-native-config library, react-native 0.59.10
// need to import the lib
#import "ReactNativeConfig/ReactNativeConfig.h"

...

  if(![[ReactNativeConfig envFor:@"ENV"] isEqualToString:@"e2e"]){
   [RNSplashScreen show];
  }

But I guess this is just a workaround and there's a way to fix it in Detox

@LeoNatan if you still need repo with splash screen and firebase I can provide you one.

@LeoNatan here is a link for repo with firebase and splash screen. If you have any questions let me know. https://github.com/kantorm/testDetox

Thank you!
Please do not delete this repo. It will take me a while before I can look at the issue.

I have the same problem splashscreen and firebase also

detox[6917] ERROR: [DetoxExportWrapper.js/DETOX_INIT_ERROR]   -[__NSDate _URLOverride]: unrecognized selector sent to instance 0x600000d4c3d0 ( 	0   CoreFoundation                      0x00000001109098db __exceptionPreprocess + 331 	1   libobjc.A.dylib                     0x000000010f791ac5 objc_exception_throw + 48 	2   CoreFoundation                      0x0000000110927c94 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132 	3   CoreFoundation                      0x000000011090e623 ___forwarding___ + 1443 	4   CoreFoundation                      0x0000000110910418 _CF_forwarding_prep_0 + 120 	5   Detox                               0x000000010b1d80b5 -[DetoxAppDelegateProxy application:didFinishLaunchingWithOptions:] + 266 	6   UIKitCore                           0x000000011d8aa731 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 280 	7   UIKitCore                           0x000000011d8ac0cd -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3932 	8   UIKitCore                           0x000000011d8b14e6 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1617 	9   UIKitCore                           0x000000011d0f5a4e __111-[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:]_block_invoke + 904 	10  UIKitCore                           0x000000011d0fe346 +[_UICanvas _enqueuePostSettingUpdateTransactionBlock:] + 153 	11  UIKitCore                           0x000000011d0f5664 -[__UICanvasLifecycleMonitor_Compatability _scheduleFirstCommitForScene:transition:firstActivation:completion:] + 236 	12  UIKitCore                           0x000000011d0f5fc0 -[__UICanvasLifecycleMonitor_Compatability activateEventsOnly:withContext:completion:] + 1091 	13  UIKitCore                           0x000000011d0f4332 __82-[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]_block_invoke + 782 	14  UIKitCore                           0x000000011d0f3fe9 -[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:] + 433 	15  UIKitCore                           0x000000011d0f8d2e __125-[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]_block_invoke + 576 	16  UIKitCore                           0x000000011d0f9988 _performActionsWithDelayForTransitionContext + 100 	17  UIKitCore                           0x000000011d0f8a95 -[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:] + 223 	18  UIKitCore                           0x000000011d0fda48 -[_UICanvas scene:didUpdateWithDiff:transitionContext:completion:] + 392 	19  UIKitCore                           0x000000011d8afdc8 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 514 	20  UIKitCore                           0x000000011d46702f -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 361 	21  FrontBoardServices                  0x0000000117088d25 -[FBSSceneImpl _didCreateWithTransitionContext:completion:] + 448 	22  FrontBoardServices                  0x0000000117092ad6 __56-[FBSWorkspace client:handleCreateScene:withCompletion:]_block_invoke_2 + 283 	23  FrontBoardServices                  0x0000000117092300 __40-[FBSWorkspace _performDelegateCallOut:]_block_invoke + 53 	24  libdispatch.dylib                   0x00000001129e5d02 _dispatch_client_callout + 8 	25  libdispatch.dylib                   0x00000001129e8d41 _dispatch_block_invoke_direct + 295 	26  FrontBoardServices                  0x00000001170c40da __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 30 	27  FrontBoardServices                  0x00000001170c3d92 -[FBSSerialQueue _performNext] + 451 	28  FrontBoardServices                  0x00000001170c4327 -[FBSSerialQueue _performNextFromRunLoopSource] + 42 	29  CoreFoundation                      0x0000000110870db1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 	30  CoreFoundation                      0x0000000110870633 __CFRunLoopDoSources0 + 243 	31  CoreFoundation                      0x000000011086acef __CFRunLoopRun + 1231 	32  CoreFoundation                      0x000000011086a4d2 CFRunLoopRunSpecific + 626 	33  GraphicsServices                    0x0000000113fb02fe GSEventRunModal + 65 	34  Detox                               0x000000010b1d4888 __detox_UIApplication_run + 365 	35  UIKitCore                           0x000000011d8b2fc2 UIApplicationMain + 140 	36  wasder                              0x00000001088c9f40 main + 112 	37  libdyld.dylib                       0x0000000112a53541 start + 1

Good news, I managed to reproduce using the demo project. Investigating.

Fixed.

Thanks for the fix @LeoNatan 🎉


test: Validate kube-dns service before running any tests

Perform nslookup for kube-dns.kube-system.svc.cluster.local from each
client pod before running any tests to eliminate test flakes due to
coredns issues.
Signed-off-by: Jarno Rajahalme<EMAIL_ADDRESS>

All test fails are for unrelated reasons


Running actions list with poll api(temporary)

Closes #23

Have tested locally, it works. But later we have to colorize stdoud somehow


ARXIVNG-456 added contributor guidelines

This was branched from ARXIVNG-407, so #20 should be merged first.

Coverage decreased (-0.06%) to 90.975% when pulling 5d49bd0f9462c1fa9f3cc81c546d59895317513b on task/ARXIVNG-456 into 3c47ed3b1007835553d9634e437239393238f34c on develop.

Merging per discussion.