Testnet 58: Enceladus

Testnet Release
Testnet name: Enceladus
Release date: 2023-08-07
Testnet release manager: @conorsch
Testnet Release Manager Checklist
Preceding Friday (sprint planning day):

[x] Create GitHub project column, work with team to populate the milestone with tickets targeted for the release.

Tuesday (or after release of previous testnet):

[ ] Construct the genesis data for the release:

[ ] Create new testnet directory with initial genesis allocations for this testnet by running cd testnets && ./new-testnet.sh

This genesis data will be used for testnet-preview with a randomized version of the future testnet's chain ID.

Thursday:

[ ] Check in with team again in a release meeting and update the GitHub milestone to ensure it represents what will make it into the testnet.
[ ] Draft an announcement for peer review to ensure major changes included are comprehensive.

Following Monday (release day):

[ ] Verify that testnet-preview.penumbra.zone is operational; it is redeployed on every push to main, and is an exact preview of what is about to be deployed.
[ ] Bump the version number and push its tag, via cargo-release.

[ ] Run cargo release minor for a new testnet, or cargo release patch for a bugfix. For the latter, make sure you're on a dedicated release branch.
[ ] Push the commit and newly generated tag, e.g. v0.51.0, to the remote.

[ ] Wait for the "Release" workflow to complete: it'll take ~90m, most of which is the macOS builds.
[ ] Edit the newly created (and published) release object, then click "Generate release notes." Cut and paste the generated text from the bottom to the top of the post, then save it.
[ ] You must manually review the Waiting deployment in the GitHub Action UI before the deployment will begin. Monitor the GitHub action to ensure it completes after it is approved.
[ ] Delegate to the Penumbra Labs CI validators; use amounts of ~200k penumbra per validator.
[ ] Update Galileo deployment, following docs.
[ ] Make GitHub release object and include the announcement
[ ] Make the announcement to Discord! 🎉🎉🎉

I haven't bumped the chain id yet, but plan to do so tomorrow. First, I want to make sure we get some new team members added to the allocations.

Testnet 58 has shipped. :sunglasses:


[BUG] Non-user friendly/inaccurate message when attempting to delete Cloud Credentials being used

Rancher Server Setup

Rancher version: v2.7-head (Commit ID: 76c98b4)
Installation option (Docker install/Helm Chart): Any

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): Any

Proxy/Cert Details:

Information about the Cluster

Kubernetes version: Any
Cluster Type (Local/Downstream): Downstream

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider): Node Driver (Infrastructure Provider)

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom) Any

If custom, define the set of permissions: N/A

Describe the bug
When attempting to delete a Cloud Credential that is being used by an active cluster, the user is presented with a non-user friendly error message.
To Reproduce

Create AWS Cloud Credentials in Rancher
Create an EC2 Node Driver cluster using the newly created AWS Cloud Credentials
When the cluster is Active, navigate back to the AWS Cloud Credentials, click the "three-dot" button for the credentials, and then click the Delete button
In the "Are you sure?" dialogue box, click the Delete button

Result
Note the user is presented with the message "Index with name by-cloud-cred does not exist" in the "Are you sure?" dialogue box.
Expected Result
A clear and concise error message is presented that explains to the user why they are not able to delete that set of Cloud Credentials.
Screenshots

Additional context
This is a Blocker to the completion/validation of Dashboard ticket 7138

This ticket is not a release blocker for v2.7.0, and is therefore going to be moved to the v2.7.1 Milestone.

I cannot reproduce this on 2.7-head (0dcfd16e7af68b6856ecc38654254e8ed18567de).
When deleting a cloud credential currently being used by an RKE1 cluster in AWS or Digital Ocean, i get the following message cloud credential is currently referenced by node template <node_template_name>.
When deleting a cloud credential being used by an RKE2 cluster i get the message cloud credential is currently referenced by provisioning cluster <provisioning_cluster_name>.
@jameson-mcghee are there any additional details or steps that are needed to reproduce this issue?

@jameson-mcghee , moving this "To Test" as there is a pending question to reproduce it per the previous comment.

I retested this issue on both v2.7.0-rc10 as well as v2.7-head (Commit ID: ) as both an Admin User and a Standard User. During testing, I followed the previously described Steps to Reproduce (relisted below), and I observed that intermittently the "Index with name by-cloud-cred does not exist" error message would appear (when the API response returned a 500), and that it would intermittently provide the error message "cloud credential is currently referenced by provisioning cluster <CLUSTER_NAME>" (when the API response returned a 422). However, during the bulk of the testing, the  "Index with name by-cloud-cred does not exist" error message was observed as being provided.
cc @HarrisonWAffel @snasovich
As a secondary note, the first letter of the first word in the message should be capitalized for proper grammar when this issue is resolved. i.e. For the sake of grammar and presentation, the error message should state "These cloud credentials are currently referenced by provisioning cluster: <CLUSTER_NAME>"
To Reproduce

Create AWS Cloud Credentials in Rancher
Create an EC2 Node Driver cluster using the newly created AWS Cloud Credentials
When the cluster is Active, navigate back to the AWS Cloud Credentials, click the "three-dot" button for the credentials, and then click the Delete button
In the "Are you sure?" dialogue box, click the Delete button

v2.7.0-rc10 Standard User (422 Response):

v2.7.0-rc10 Standard User (500 Response):

v2.7-head Standard User:

After a few more attempts I was able to reproduce this error, it seems it is more easily reproducible on an HA setup. The root cause seems to be an error returned by the cluster cache when we attempt to query the provisioning cluster this cloud credential belongs to.
https://github.com/rancher/rancher/blob/fe78be33779cd0d4ee122bd17e9678d3700f9787/pkg/api/norman/customization/cred/store.go#L87-L91
Because this error is being returned from client-go directly i'm not yet sure if there is a way to definitively resolve the error, but I'm still looking into it. At the very least we can make the error messages shown to the user more informative / friendly and fix some of the other casing issues noted by Jameson.

Looking into this a bit deeper I believe I have found the reason that this issue only intermittently appears in HA setups.
The credential store is using an indexer within the provisioning cluster cache to associate provisioning clusters with cloud credentials by looking at the provisioning clusters CloudCredentialSecretName and comparing it with the id sent to the backend by the frontend.
However, This indexer is added to the cache within the v2provisioning cluster controller which is only registered within the leader pod in an HA setup. The requests to delete the cloud credential are not always sent to the leader pod, in which case we see the index with name cloud-cred does not exist message. This also explains why it is not reproducible in local setups or on docker installs - as the single rancher instance will always be the leader. In order for this issue to be resolved we likely need to register this indexer for all Rancher replica's, not just the leader.

@HarrisonWAffel's fix here may also fix https://github.com/rancher/rancher/issues/39515.

/backport 2023-Q1-v2.6x

When testing on Rancher v2.7-head (Commit ID: 38979f8), I was able to verify this issue is no longer reproducing by following the Steps to Reproduce multiple times (ensuring that the issue is no longer intermittent) . Therefore I am closing this ticket.
Steps To Reproduce:

Create AWS Cloud Credentials in Rancher
Create an EC2 Node Driver cluster using the newly created AWS Cloud Credentials
When the cluster is Active, navigate back to the AWS Cloud Credentials, click the "three-dot" button for the credentials, and then click the Delete button
In the "Are you sure?" dialogue box, click the Delete button

v2.7-head (Commit ID: 38979f8):


Archiving nodejs-pt (node's i18n process has changed)

Dear nodejs-pt team,
Thank you for being part of the Node.js community. 🙏
The i18n Working Group is currently in the process of archiving node's l10n repositories since we've moved all translation efforts to the Crowdin platform over the past few years. We're planning on archiving all l10n repositories that follow the previous method that was established during the io.js fork on 01-14-22. I believe this repository meets that criteria, but if there is a reason to continue to maintain nodejs/nodejs-pt other than localizing Node.js into Portuguese (and you'd like to keep this repository open), please respond here on this issue so we can discuss it and understand how to best help you in your efforts.
In the meantime, we'd love to have you come over and be a part of the i18n WG at: https://github.com/nodejs/i18n#contributing
Please feel free to reach out to us there, or to me directly if you'd like to understand how to get involved with node's current localization efforts.
All the best,
–Ben (Node.js i18n Lead)

Hello @obensource! I think we're done over here, there has been zero activity for the last couple of years.
Thanks for looking after the official procedures!

Hey @gustavohenke 👋
Thanks a million for letting me know, I really appreciate it – and thank you for all your great work! 🙏
Cheers! 🍻
–Ben


[question] Multiple instances of MUI and Emotion in the same page

Order ID 💳
50070
Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

The problem in depth 🔍
We would like to use MUI and MUI X in a microfrontends context. Each microfrontend team needs to be able to upgrade at their own pace, so we would like each microfrontend to have its own instance of MUI and Emotion. But Emotion gives a warning that it is risky to run multiple instances of Emotion. A few questions:

Can you point us to any recommendations or examples of running multiple instances of MUI in a microfrontends context?
In MUI, how much risk is there of actual problems from running multiple instances of Emotion?
What large breaking changes are on the horizon for future major versions of MUI? (If the changes are not too large, this affects whether we prioritize independently upgrading microfrontends.)

Thank you.
Your environment 🌎

`npx @mui/envinfo`
  System:
    OS: macOS 12.6.1
  Binaries:
    Node: 18.12.0 - ~/.nvm/versions/node/v18.12.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.12.0/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.0/bin/npm
  Browsers:
    Chrome: 107.0.5304.87
    Edge: Not Found
    Firefox: 106.0.4
    Safari: 16.1
  npmPackages:
    @emotion/react: ^11.10.4 => 11.10.4
    @emotion/styled: ^11.10.4 => 11.10.4
    @mui/base:  5.0.0-alpha.103
    @mui/core-downloads-tracker:  5.10.11
    @mui/icons-material: ^5.10.9 => 5.10.9
    @mui/material: ^5.10.10 => 5.10.11
    @mui/private-theming:  5.10.9
    @mui/styled-engine:  5.10.8
    @mui/system:  5.10.10
    @mui/types:  7.2.0
    @mui/utils:  5.10.9
    @mui/x-data-grid:  5.17.9
    @mui/x-data-grid-pro: ^5.17.9 => 5.17.9
    @mui/x-date-pickers: ^5.0.5 => 5.0.5
    @mui/x-license-pro:  5.17.0
    @types/react:  18.0.22
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0

Target browsers: desktop Chrome, Edge, FF, Safari

Here is more information on setting up emotion for microfrontends: https://github.com/emotion-js/emotion/issues/2639. You should basically do what you are doing with react.
We don't expect some major breaking changes for the next version of Material UI (which currently is planned for Q4 2023). We are at this moment mostly focused on the new products MUI Base and Joy UI, and as for Material UI, the plan is to enable people to use Material You (the third version of Material Design), but that would be through new components, so it shouldn't affect existing users.


Intro

My name is Camilo Lombana a highly motivated System Engineer with over 10 years’ experience in industry such as IT, oil & gas, banking, means of payment, switch financial, Pos, retail, management and consultation.
My strengths include excellent personal relationships, team work and communication skills, train, manage and lead work groups, customer relationship, strong and effective knowledge and experience in different technology projects with compliance-oriented results and application of best practices in the management and development of projects.
I would like to improve my software development skills and I think this is a great opportunity to participate in Binary Studio Academy.

I finish this task


Update ngx_conf_file.c

try the following command
test_cmd   arg opt
b->pos point to next "arg", start points to "test_cmd"
b->pos - start = 9(strlen("test_cmd")+strlen(SPACE))
the  old code alloc b->pos - start + 1 = 10bytes, but we only need 9bytes to store "test_cmd" and '\0'
so "+1" is a waste of memory

modified nginx.conf, that only contain the following configuration
worker_processes 4
and I added some log and print to monitor like this:
nginx: [emerg] Out LOOP start:08A848A8, b->pos:08A848B9, alloc:18 bytes, word->data:worker_processes,len(word->data):16 in /usr/local/nginx/conf/nginx.conf:3
nginx: [emerg] Out LOOP start:08A848BA, b->pos:08A848BC, alloc:3 bytes, word->data:4,len(word->data):1 in /usr/local/nginx/conf/nginx.conf:3
"worker_processes" need 16+1 bytes, but alloced 18bytes
"4" need 1+1 bytes, byt alloced 3 bytes

Thanks, Valentin committed a slightly different variant of the patch, see http://hg.nginx.org/nginx/rev/4e71788460fa.
Please note that this repository is unofficial and pull requests have no chances to be merged. Proper way to submit changes to nginx is via the nginx development mailing list, see http://nginx.org/en/docs/contributing_changes.html.


Dangling alias of Union[int, float] on signals page

The selected alias at the bottom seems to come out of nowhere.
The usual :annotation: does not seem to suppress it.

I know, but normally :annotation: suppresses the auto generated annotations. We use it in a few places to suppress excessive info.

But since it isn't factually incorrect, I don't mind leaving it in for this release.
We can have a look at it the next time we dig into Sphinx to fix e.g #117


It is not possible to extend Image and Album

Someone else raised the same issue I was having on stackoverflow: http://stackoverflow.com/questions/10250145/extending-imagestore-models/10577088#10577088
The solution there is mine.
I found that there is a circular import. Here's the order of things (slightly simplified):

load_class(IMAGESTORE_ALBUM_MODEL)
from imagestore.models.bases.album import BaseAlbum
BaseAlbum has an FK to IMAGESTORE_IMAGE_MODEL (head), so it gets imported with load_class
load_class(IMAGESTORE_IMAGE_MODEL)
from imagestore.models.bases.image import BaseImage
BaseImage has an FK to IMAGESTORE_ALBUM_MODEL (album), so it gets imported with load_class
When this calls import IMAGESTORE_ALBUM_MODEL is already in sys.modules, though incomplete because it's still being built. And thus the module doesn't have an "Album" attribute yet.

The quick solution is to move the head field to models.album.Album and remove it from BaseAlbum. After doing this I was able to get the site running again. You must use the models package in your new app (not a simple models.py), with Image and Album in separate files.

I think it was solved via #51.


fix mr ref

Fixes broken link

@yathomasi I'm still seeing errors when trying to load the deployment. If you click the deployment above and navigate to the docs, you should see the same. Any idea what's happening?

I'm still seeing errors when trying to load the deployment. If you click the deployment above and navigate to the docs, you should see the same. Any idea what's happening?

I see it was 10 commits behind. It as same error as pervious which was fixed few commits behind.

Thanks @yathomasi! Didn't realize I was that far behind.


Question

I'm ok to transform some playstore french comment in issue here.
Do you think it's a good idea ?

Please use Transifex: https://www.transifex.com/projects/p/k9mail/ to contribute new translations :)


Validator fails with UTF-8 characters?

Error message when validating a new GEMS database imported from shapefiles:
mu = str(row.getValue('MapUnit'))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xba' in position 1: ordinal not in range(128)
validating database with special characters for MapUnit; not clear if hanging in introspection of DMU or the GeoPolys feature class. suspect  Map unit string in question is 'Mº' could be 'P³'?  There is no ..ba in the MapUnit polys or DMU.
I can provide the geodatabase if that's useful?

when I took the unit id's with the special characters (cambrian and Penn-Perm  ligatures) out, the validation worked

How did you get the special characters into the DMU table?


Push Assignee and other details to Notion-Board

Need
_In order to see who is assigned to each issue
As a User that has setup the integration
I want to Push the assignee information to the integration so that I can sort/filter
Acceptance Criteria
Scenario: When a GitHub issue is updated it should push the information to the Notion-board integration
GIVEN a successful integration
WHEN any update happens
THEN the corresponding issue ID is updated in Notion
Tasks

[ ] Push Assignee information
[ ] Consider pushing "Project, Milestone, Development" as well

Yes I think this works well the way that you planned it out. Having different views in Notion is a clever method to review the DB's.

Another point, if we can push "Labels" from GitHub into Notion as a :Multi-Select then we can filter based on Labels in Notion which is very handy.


Add image tooltip

This sets up a tooltip for each water feature on the chart. The tooltip is populated with an image that is stored in s3 via the targets pipeline (https://github.com/USGS-VIZLAB/pools-and-fluxes/pull/3). This sets basic function only. Bekah is gathering images, not all features have images yet.

Hmm looks like there may be some issue with the connection to S3? Some of the images load:

But for the majority I see this:

Right now we don't have images for all the features and I did not set a default for when there is no image. Bekah is working on gathering the images, so I wanted to get the ones we have in to be able to show her and also see if it brought up other considerations for the image selection process

and the interaction could be a lot better, it's hard with the many overlapping rects, but I figured this will evolve as you set up the logpile chart and figure out how each feature is represented on the chart

Ah I see, sorry. I think I was confused b/c at first on page load it seemed like some bars didn't trigger any pop up, so in my head I thought those were the ones for which Bekah hadn't found any images yet. But now I see that every bar triggers a pop-up. My bad!


Mention asp to retrieve Arch Linux package files

asp is the official tool to retrieve package files from Arch Linux. It utilizes the git mirror of the svn repo, so it's probably easier to use for many people.

Oh, i saw @AladW edited the page now. Feel free to figure out if its worth including or not.

If you want completeness you should just link the wiki page somewhere. E.g. "retrieve the PKGBUILD via ABS".

I've added a link to https://archlinux.org/svn in https://github.com/neomutt/neomutt.github.io/commit/2220c5b1a7a22586fe0bdfa1d33d48f763634be4. The ABS wiki page is linked there for people who want more.


Added a section to thumbnail to store frame buffer pixels without compression.

This PR adds a new section to the thumbnail, which allows to store framebuffer pixels without compression.  I would also like to put a PR which saves the color in PNG format next, but I didn't want to mix too many CLs in this PR.
It also fixes a small bug in resampling code, which caused rounding errors when writing out a thumbnail. In floating math, x,y coordinates of a pixel would occasionally get calculated as (a.999999) instead of (a+1) which would cause an entire row/column of pixels to be duplicated from previous row/column. This bug manifests itself when no resampling is required as well.

I've added the same resampling fix to the other APIs. One thing I found puzzling is that OpenGL aligns size to a different value as the rest of the APIs (4 in GL, not 8 like the rest). I couldn't quite understand why.

For the pixel alignment differences see the discussion in #771. It seems like I had the 8-pixel alignment on the other APIs independently perhaps just conservatively picking an alignment without debugging the issue all the way. The GL alignment was then added independently as 4-pixels. I don't think it matters either way for our purposes.
One thing I mentioned in the previous PR is that probably the next step after this would be to centralise the resampling/encoding code - have the CreateRDC function just always take raw RGBA8 and remove all of the duplicated code from the drivers. Then resample & encode for the regular thumbnail and encode to whatever format the extended thumbnail will have.
Presumably you don't want the resampling on the lossless thumbnail either - I guess just currently the max size is larger than anything you care about, or else your code that actually enables the extended thumbnail bumps up the max size?

have the CreateRDC function just always take raw RGBA8 and remove all of the duplicated code from the drivers
Presumably you don't want the resampling on the lossless thumbnail either - I guess just currently the max size is larger than anything you care about, or else your code that actually enables the extended thumbnail bumps up the max size?
The max_size happens to be larger, which is why it wasn't an issue for us yet, but it will be in the future.  I'd like to:

harmonize image resampling code and remove from drivers and put into a separate file
save the thumbnail as compressed and resampled JPG that's clamped in size and save extthumbnail as a PNG loseless compressed and original size on all platforms
have RDC load both thumbnail and extthumbnail. Right now if extthumbnail is available it replaces the compressed thumnbnail

We haven't implemented the above yet, but if you are OK with this plan, we'll put a follow up PR. Please let me know what you think.

Yep that sounds fine to me. I wasn't suggesting you had to do that as part of the PR, just that this change makes that code-cruft even more obvious than it was so it's probably a good idea as a follow-up some time.
Also about your third bullet - I'm not even sure there's much need to have both thumbnails available, it's fine to have the extended thumbnail override the original compressed thumbnail.
The original thumbnail can be kept for backwards compatibility with old versions of RenderDoc, as well as for places like the windows shell extension where we want to have a thumbnail in the first few MB of the file and don't want to have to read/seek over the whole file to read the ExtThumbnail section. Unless there's a use-case I'm not considering?

Also about your third bullet - I'm not even sure there's much need to have both thumbnails available, it's fine to have the extended thumbnail override the original compressed thumbnail.
The original thumbnail can be kept for backwards compatibility with old versions of RenderDoc
Unless there's a use-case I'm not considering?

I don't have a use case for having the old thumbnail, loaded up besides the shell extension and backwards compatibility..
If it's OK, let's wait if some use case comes up, and if it does, I can change that code to keep the two thumbnails separate.


Refactor models structure

Move configurations under models/config/ package.
Move Encoders and Decoders under companion objects.
Move models to its own file in most of the cases.
Sort imports

LGTM. However, I like to have separate model decoders.

@pirita is there any particular reason? As far as I could see, there is no need to separate the encoders from the model. Placing them in the companion object makes them available when needed, as it keeps them together since they are related.

At the moment I am fine with this approach. But i think is cleaner to have all the models in one file and the decoders in another. Also, when you have complex decoders they can have interdependencies between them, and you can finish with imports in each companion object.


Implement a simple CRUD for PrometheusRule and enhance the generation of the code

Codecov Report

Merging #8 (76357c5) into master (563704b) will decrease coverage by 36.73%.
The diff coverage is 23.14%.

@@             Coverage Diff             @@
##           master       #8       +/-   ##
===========================================
- Coverage   68.29%   31.55%   -36.74%
===========================================
  Files          19       23        +4
  Lines         429      545      +116
===========================================
- Hits          293      172      -121
- Misses        103      356      +253
+ Partials       33       17       -16

Impacted Files
Coverage Δ

cmd/perses/main.go
0.00% <0.00%> (ø)

internal/api/impl/v1/project/service.go
75.55% <0.00%> (ø)

...ernal/api/interface/v1/prometheusrule/interface.go
0.00% <0.00%> (ø)

internal/config/config.go
0.00% <ø> (ø)

pkg/client/api/v1/client.go
0.00% <0.00%> (-75.00%)
:arrow_down:

pkg/model/api/v1/metadata.go
44.00% <0.00%> (-32.93%)
:arrow_down:

pkg/model/api/v1/prometheusrule.go
0.00% <0.00%> (ø)

internal/api/impl/v1/prometheusrule/service.go
4.00% <4.00%> (ø)

internal/api/impl/v1/prometheusrule/persistence.go
20.00% <20.00%> (ø)

pkg/model/api/v1/kind.go
69.23% <69.23%> (ø)

... and 14 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 563704b...76357c5. Read the comment docs.


Type Inference PoC - iteration 1 - most basic type inference

Pull Request Description

Closes #8590

Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[ ] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

I will very much appreciate reviews on this PR.
Due to introducing a cyclic reference to the IR (by adding Expression inside of BindingsMap.Type (indirectly through Const -> Argument)), it cannot be merged before #9361 is available, because the new IR becomes unwritable.
However, getting a greenlight on it will allow me to merge it right away once #9361. It will also allow me to start followup work, basing on top of this PR as a foundation - so I really need your feedback if the foundations laid out here seem sensible to you or if I should change anything.

In 4130187d28749eb29a05b0adecc185852ad32d2f I added persistance for TypeInference pass and its related components. By default these are not included in the cache generation because the pass is disabled.
Just to test it works and see the impact, I ran the cache generation with inference enabled, through the following patch:
diff --git a/project/DistributionPackage.scala b/project/DistributionPackage.scala
--- a/project/DistributionPackage.scala	(revision 4130187d28749eb29a05b0adecc185852ad32d2f)
+++ b/project/DistributionPackage.scala	(date<PHONE_NUMBER>231)
@@ -244,6 +244,7 @@
           Platform.executableFileName(ensoExecutable.toString),
           "--no-compile-dependencies",
           "--no-global-cache",
+          "--enable-static-analysis",
           "--compile",
           path.toString
         )

The Base.bindings cache seems to have grown from 30MB to ~31.1MB.

Even though this first iteration is extremely simple, it is already giving some fruit. It allowed me to statically detect the following problem within the Image library, that was not unit tested anywhere:
X:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Image\0.0.0-dev\src\Matrix.enso:381:21: warning: Invoking a value that has a non-function type (type Image) will result in a Not_Invokable error in runtime.
  381 |     to_image self = Image (Image.from_vector self.normalize.to_vector self.rows self.channels)
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and indeed, running the following example code:
from Standard.Base import all
from Standard.Image import all

main =
    mat = Matrix.identity 32 32 channels=3
    IO.println mat
    img = mat.to_image
    IO.println img
    r = img.write (File.new "tmp.png")
    IO.println r

yields
(Matrix.Value Mat [ 32*32*CV_64FC3, isCont=true, isSubmat=false, nativeObj=0x1a02050ecb0, dataAddr=0x19fcab4c000 ])
Execution finished with an error: Type error: expected a function, but got Image.
        at <enso> Matrix.to_image(Matrix.enso:381:21-94)
        at <enso> img.main(img.enso:7:11-22)

so our type checker has found a real error based on the static knowledge :)
The problem is fixed in commit be6173cfe30d4dd01459f8aeb7fc98d30b694736 - now the type checker does not issue any warnings (for now...)
Now the output is:
(Matrix.Value Mat [ 32*32*CV_64FC3, isCont=true, isSubmat=false, nativeObj=0x217196ed0d0, dataAddr=0x21726f4dbc0 ])
(Image.Value Mat [ 32*32*CV_8UC3, isCont=true, isSubmat=false, nativeObj=0x217196f0410, dataAddr=0x21726fbcb40 ])
Writing the image to a file: X:\NBO\enso\tmp.png
X:\NBO\enso\tmp.png

Split off persistance changes to #10101 , will rebase once that is merged.


Support for fast math intrinsics

Description of changes:
Models fast math intrinsics as regular floating point operations. Includes function to check inputs are finite arguments. Adds 10 new test cases (5 positive, 5 negative) for testing fast math intrinsics.
Resolved issues:
Resolves #788
Call-outs:

Testing:

How is this change tested? Existing regression + 10 new tests.

Is this a refactor change? No.

Checklist

[x] Each commit message has a non-empty body, explaining why the change was made
[x] Methods or procedures are documented
[x] Regression or unit tests are included, or existing tests cover the modified code
[x] My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

Some changes I made:

Added tests for f32 values so we now cover all floating point types.
Changed tests to assert equality (w.r.t. regular operations) in the case of addition and substraction, but other operations show serious performance issues. Created #809 to revisit this topic later.
Dropped support for frem_fast because testing showed unexpected results. Created #810 to explain the issue and tackle it in the future.


std::__1::bad_function_call (crash when using RN >= 0.48)

Detox stopped working after upgrading to react-native 0.48.3
Description
detox test --configuration ios.sim.debug
    node_modules/.bin/mocha specs/e2e --opts specs/e2e/mocha.opts --configuration ios.sim.debug
    [...]

App starts then App crash.
<HANGS for 12000 secs>
2017-09-15 09:50:51.764 myApp[90013:21708181] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.AccessibilityManagerQueue[0x6080000e6a80]>
2017-09-15 09:50:51.765 [info][tid:main][RCTRootView.m:301] Running application MyApp ({
    initialProps =     {
    };
    rootTag = 1;
})
libc++abi.dylib: terminating with unexpected exception of type std::__1::bad_function_call
Signal caught: Abort trap: 6
0   EarlGrey                            0x000000011d382009 grey_signalHandler + 249
1   libsystem_platform.dylib            0x00000001115f3b3a _sigtramp + 26
2   libsystem_pthread.dylib             0x00000001116112c8 _pthread_keys + 9720
3   libsystem_c.dylib                   0x000000011136288f abort + 127
4   libc++abi.dylib                     0x0000000111141ce5 __cxa_bad_cast + 0
5   libc++abi.dylib                     0x000000011115ccbd _ZL26default_unexpected_handlerv + 0
6   libobjc.A.dylib                     0x000000010ed013cf _ZL15_objc_terminatev + 114
7   libc++abi.dylib                     0x0000000111159f29 _ZSt11__terminatePFvvE + 8
8   libc++abi.dylib                     0x0000000111159fa3 _ZSt9terminatev + 51
9   libc++abi.dylib                     0x0000000111159ef4 _ZSt12__unexpectedPFvvE + 6
10  libc++abi.dylib                     0x000000011115a90f __cxa_call_unexpected + 137
11  myApp                               0x00000001088fe110 _ZN8facebook5react11JSCExecutor16initOnJSVMThreadEv + 1872

Node, Device, Xcode and macOS Versions

Node:    8.5.0
Device:  iPhone 6 sim iOS 10.3
Xcode:   8.3.3
macOS: 10.12.6

"react": "^16.0.0-rc.2",
"react-dom": "^16.0.0-rc.2",
"react-native": "0.48.3",
"detox": "^5.6.2",

@LeoNatan , @silyevsk can you help taking a look at this issue ?

Does this reproduce consistently? If so, please add an exception breakpoint in Xcode and provide the backtrace of the exception. Thanks.

Yes, every run this happens. I will post an update soon.
Thanks

Same problem for here.

hey @pdavid0, can i ask if there anything new? Thanks

Xcode 9 was released, now fbsimctl is not happy.
fbsimctl --json "iPhone 6" --first 1 --simulators list
{"event_type":"discrete","timestamp":1506096591,"subject":"Error Domain=com.facebook.FBControlCore Code=0 \"Attempting to load a file at path '\/Applications\/Xcode.app\/Contents\/Developer\/Library\/PrivateFrameworks\/CoreSimulator.framework', but it does not exist\" UserInfo={NSLocalizedDescription=Attempting to load a file at path '\/Applications\/Xcode.app\/Contents\/Developer\/Library\/PrivateFrameworks\/CoreSimulator.framework', but it does not exist}","event_name":"failure"}

An iPhone 6 sim is running with iOS 11.0
I updated  to "detox": "^5.7.0", and detox-cli

@pdavid0, you can download version 8.3.3 of Xcode using the web instead, and name the current 'Xcode.app' (which is 9 in the case) to for example 'Xcode_9.0.app' and the downloaded version be 'Xcode.app'. Then you can test normally. (This is just the workaround in my case). However, the issue of std::__1::bad_function_call is still not resolved for me. Hope this help you.

Is this issue fixed with last release 5.8.1?

Will try tomorrow ! Thanks

Detox 5.8.1 does not rely on fbsimctl (for the most part... if you use device.setLocation() you would still need it). Issues related to fbsimctl are solved now.

5.8.1 has not yet been fixed to support 0.48.X issues. We’ll be investigating soon.

@LeoNatan, can I ask how about .47? Thanks

I’m not familiar with any problems there. Try it and let me know.

@LeoNatan
I have the same problem - Detox closes the app after launching and then waits for timeout of 12000ms and finishes with an error. Interesting that the app will work without any problems if you open it again manually during the timeout
Here is a part of logs:
2017-10-02 13:05:33.374 spacenation_reactnative[1455:78373] ☣ DETOX:: Detox Action Received: loginSuccess
2017-10-02 13:05:33.439 [info][tid:main][RCTCxxBridge.mm:187] Initializing <RCTCxxBridge: 0x6080001aaaa0> (parent: <RCTBridge: 0x6000000a7e00>, executor: (null))
2017-10-02 13:05:33.458 [warn][tid:main][RCTBridge.m:114] Class RCTCxxModule was not exported. Did you forget to use RCT_EXPORT_MODULE()?
libc++abi.dylib: terminating with unexpected exception of type std::__1::bad_function_call: std::exception
Signal caught: Abort trap: 6
0   EarlGrey                            0x0000000123896649 grey_signalHandler + 249
1   libsystem_platform.dylib            0x000000011425eb3a _sigtramp + 26
2   libsystem_pthread.dylib             0x000000011427c2c8 _pthread_keys + 9720

Node, Device, Xcode and macOS Versions

node v8.5.0
ios emulator - iPhone 7 iOS11
xcode 9
macOS 10.12.6

"react": "16.0.0-alpha.12",
"react-native": "0.48.3",
"detox": "^5.6.2"

It works again because when you launch the app using the icon, Detox is not injected in the app.
Sorry guys, I have not had time to look into this—working hard on DetoxInstruments. Hopefully, will have some time soon.

I have the same problem and error. Even if i've clicked on app and open it by my self detox hangs on first spec.
2017-10-03 21:11:00.728 projectName[8020:2569322] Crash handler setup started.
2017-10-03 21:11:00.728 projectName[8020:2569322] Crash handler setup completed.
2017-10-03 21:11:00.728 projectName[8020:2569322] Enabling accessibility for automation on Simulator.
2017-10-03 21:11:01.135 projectName[8020:2569322] ☣ DETOX:: Detox Action Sent: login
2017-10-03 21:11:01.369 projectName[8020:2569322] ☣ DETOX:: Detox Action Received: loginSuccess
2017-10-03 21:11:01.422 [info][tid:main][RCTCxxBridge.mm:187] Initializing <RCTCxxBridge: 0x60c0001b9a60> (parent: <RCTBridge: 0x6040000b9c20>, executor: (null))
2017-10-03 21:11:01.438 [warn][tid:main][RCTBridge.m:121] Class RCTCxxModule was not exported. Did you forget to use RCT_EXPORT_MODULE()?
2017-10-03 21:11:01.455 [warn][tid:main][RCTModuleData.mm:69] Module A0Auth0 requires main queue setup since it overrides `constantsToExport` but doesn't implement `requiresMainQueueSetup. In a future release React Native will default to initializing all native modules on a background thread unless explicitly opted-out of.
2017-10-03 21:11:01.461 projectName[8020:2569322] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.AccessibilityManagerQueue>
2017-10-03 21:11:01.462 [info][tid:main][RCTRootView.m:301] Running application projectName ({
    initialProps =     {
    };
    rootTag = 1;
})
libc++abi.dylib: terminating with unexpected exception of type std::__1::bad_function_call: std::exception
Signal caught: Abort trap: 6
0   EarlGrey                            0x0000000126680b49 grey_signalHandler + 249
1   libsystem_platform.dylib            0x0000000114dedf5a _sigtramp + 26
2   libsystem_kernel.dylib              0x0000000114dad480 libsystem_kernel.dylib + 1152
3   libsystem_c.dylib                   0x0000000114a87107 abort + 127
4   libc++abi.dylib                     0x000000011482191f __cxa_bad_cast + 0
5   libc++abi.dylib                     0x0000000114821aa3 _ZL25default_terminate_handlerv + 241
6   libobjc.A.dylib                     0x000000010e97a1c6 _ZL15_objc_terminatev + 105
7   libc++abi.dylib                     0x000000011483d159 _ZSt11__terminatePFvvE + 8
8   libc++abi.dylib                     0x000000011483d1d3 _ZSt9terminatev + 51
9   libc++abi.dylib                     0x000000011483d124 _ZSt12__unexpectedPFvvE + 6
10  libc++abi.dylib                     0x000000011483d967 __cxa_call_unexpected + 137
11  projectName                    0x000000010ddb1b74 _ZN8facebook5react11JSCExecutor16initOnJSVMThreadEv + 1876
12  projectName                    0x000000010ddb1181 _ZN8facebook5react11JSCExecutorC2ENSt3__110shared_ptrINS0_16ExecutorDelegateEEENS3_INS0_18MessageQueueThreadEEERKN5folly7dynamicE + 1025
13  projectName                    0x000000010ddb1ded _ZN8facebook5react11JSCExecutorC1ENSt3__110shared_ptrINS0_16ExecutorDelegateEEENS3_INS0_18MessageQueueThreadEEERKN5folly7dynamicE + 29
14  projectName                    0x000000010ddb0918 _ZN8facebook5react18JSCExecutorFactory16createJSExecutorENSt3__110shared_ptrINS0_16ExecutorDelegateEEENS3_INS0_18MessageQueueThreadEEE + 440
15  projectName                    0x000000010ddc9174 _ZN8facebook5react16NativeToJsBridgeC2EPNS0_17JSExecutorFactoryENSt3__110shared_ptrINS0_14ModuleRegistryEEENS5_INS0_18MessageQueueThreadEEENS5_INS0_16InstanceCallbackEEE + 580
16  projectName                    0x000000010ddc929d _ZN8facebook5react16NativeToJsBridgeC1EPNS0_17JSExecutorFactoryENSt3__110shared_ptrINS0_14ModuleRegistryEEENS5_INS0_18MessageQueueThreadEEENS5_INS0_16InstanceCallbackEEE + 29
17  projectName                    0x000000010ddc8aac _ZZN8facebook5react8Instance16initializeBridgeENSt3__110unique_ptrINS0_16InstanceCallbackENS2_14default_deleteIS4_EEEENS2_10shared_ptrINS0_17JSExecutorFactoryEEENS8_INS0_18MessageQueueThreadEEENS8_INS0_14ModuleRegistryEEEEN3$_0clEv + 636
18  projectName                    0x000000010ddc881d _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRZN8facebook5react8Instance16initializeBridgeENS_10unique_ptrINS4_16InstanceCallbackENS_14default_deleteIS7_EEEENS_10shared_ptrINS4_17JSExecutorFactoryEEENSB_INS4_18MessageQueueThreadEEENSB_INS4_14ModuleRegistryEEEE3$_0EEEvDpOT_ + 45
19  projectName                    0x000000010ddc8549 _ZNSt3__110__function6__funcIZN8facebook5react8Instance16initializeBridgeENS_10unique_ptrINS3_16InstanceCallbackENS_14default_deleteIS6_EEEENS_10shared_ptrINS3_17JSExecutorFactoryEEENSA_INS3_18MessageQueueThreadEEENSA_INS3_14ModuleRegistryEEEE3$_0NS_9allocatorISH_EEFvvEEclEv + 41
20  projectName                    0x000000010dc5d7ab _ZNKSt3__18functionIFvvEEclEv + 123
21  projectName                    0x000000010dc5d498 _ZN8facebook5react17tryAndReturnErrorERKNSt3__18functionIFvvEEE + 24
22  projectName                    0x000000010dc4bce1 _ZN8facebook5react16RCTMessageThread7tryFuncERKNSt3__18functionIFvvEEE + 33
23  projectName                    0x000000010dc5194f _ZZN8facebook5react16RCTMessageThread14runOnQueueSyncEONSt3__18functionIFvvEEEENK3$_2clEv + 175
24  projectName                    0x000000010dc5188d _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRZN8facebook5react16RCTMessageThread14runOnQueueSyncEONS_8functionIFvvEEEE3$_2EEEvDpOT_ + 45
25  projectName                    0x000000010dc51649 _ZNSt3__110__function6__funcIZN8facebook5react16RCTMessageThread14runOnQueueSyncEONS_8functionIFvvEEEE3$_2NS_9allocatorIS9_EES6_EclEv + 41
26  projectName                    0x000000010dc5d7ab _ZNKSt3__18functionIFvvEEclEv + 123
27  projectName                    0x000000010dc4bb4b _ZN8facebook5react16RCTMessageThread7runSyncENSt3__18functionIFvvEEE + 91
28  projectName                    0x000000010dc4c08b _ZN8facebook5react16RCTMessageThread14runOnQueueSyncEONSt3__18functionIFvvEEE + 315
29  projectName                    0x000000010ddc207e _ZN8facebook5react8Instance16initializeBridgeENSt3__110unique_ptrINS0_16InstanceCallbackENS2_14default_deleteIS4_EEEENS2_10shared_ptrINS0_17JSExecutorFactoryEEENS8_INS0_18MessageQueueThreadEEENS8_INS0_14ModuleRegistryEEE + 1182
30  projectName                    0x000000010dbf47cf -[RCTCxxBridge _initializeBridge:] + 3423
31  projectName                    0x000000010dbf0f99 __21-[RCTCxxBridge start]_block_invoke.182 + 153
32  projectName                    0x000000010dc0debc _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRU8__strongU13block_pointerFvvEEEEvDpOT_ + 60
33  projectName                    0x000000010dc0dcf9 _ZNSt3__110__function6__funcIU8__strongU13block_pointerFvvENS_9allocatorIS4_EES2_EclEv + 41
34  projectName                    0x000000010dc5d7ab _ZNKSt3__18functionIFvvEEclEv + 123
35  projectName                    0x000000010dc5d498 _ZN8facebook5react17tryAndReturnErrorERKNSt3__18functionIFvvEEE + 24
36  projectName                    0x000000010dbee4e0 -[RCTCxxBridge _tryAndHandleError:] + 80
37  Foundation                          0x000000010e3bb948 __NSThreadPerformPerform + 334
38  CoreFoundation                      0x000000010fcea2b1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
39  CoreFoundation                      0x000000010fd89d31 __CFRunLoopDoSource0 + 81
40  CoreFoundation                      0x000000010fccec19 __CFRunLoopDoSources0 + 185
41  CoreFoundation                      0x000000010fcce1ff __CFRunLoopRun + 1279
42  CoreFoundation                      0x000000010fccda89 CFRunLoopRunSpecific + 409
43  projectName                    0x000000010dbee24b +[RCTCxxBridge runRunLoop] + 1035
44  Foundation                          0x000000010e3838ac __NSThread__start__ + 1197
45  libsystem_pthread.dylib             0x0000000114dff6c1 _pthread_body + 340
46  libsystem_pthread.dylib             0x0000000114dff56d _pthread_body + 0
47  libsystem_pthread.dylib             0x0000000114dfec5d thread_start + 13

node v8.5.0
ios emulator - iPhone 6 iOS11
Xcode 9
macOS 10.13
react 16.0.0
react-native 0.49.0
detox 5.8.1

I've got the same error as well:
2017-10-04 14:10:46.407 AwesomeProject[82179:1638688] Crash handler setup completed.
2017-10-04 14:10:46.407 AwesomeProject[82179:1638688] Enabling accessibility for automation on Simulator.
2017-10-04 14:10:46.910 AwesomeProject[82179:1638688] ☣ DETOX:: Detox Action Sent: login
2017-10-04 14:10:47.016 AwesomeProject[82179:1638688] ☣ DETOX:: Detox Action Received: loginSuccess
2017-10-04 14:10:47.071 [info][tid:main][RCTCxxBridge.mm:187] Initializing <RCTCxxBridge: 0x6000001af6c0> (parent: <RCTBridge: 0x60c0000a4920>, executor: (null))
2017-10-04 14:10:47.095 [warn][tid:main][RCTBridge.m:114] Class RCTCxxModule was not exported. Did you forget to use RCT_EXPORT_MODULE()?
2017-10-04 14:10:47.114 AwesomeProject[82179:1638688] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.AccessibilityManagerQueue>
2017-10-04 14:10:47.116 [info][tid:main][RCTRootView.m:301] Running application AwesomeProject ({
    initialProps =     {
    };
    rootTag = 1;
})
libc++abi.dylib: terminating with unexpected exception of type std::__1::bad_function_call: std::exception
Signal caught: Abort trap: 6
0   EarlGrey                            0x000000011e163689 grey_signalHandler + 249
1   libsystem_platform.dylib            0x0000000112a59b3a _sigtramp + 26
2   libsystem_pthread.dylib             0x0000000112a772c8 _pthread_keys + 9720
3   libsystem_c.dylib                   0x00000001126f7107 abort + 127
4   libc++abi.dylib                     0x00000001124a091f __cxa_bad_cast + 0
5   libc++abi.dylib                     0x00000001124a0aa3 _ZL25default_terminate_handlerv + 241
6   libobjc.A.dylib                     0x000000010c99e1c6 _ZL15_objc_terminatev + 105
7   libc++abi.dylib                     0x00000001124bc159 _ZSt11__terminatePFvvE + 8
8   libc++abi.dylib                     0x00000001124bc1d3 _ZSt9terminatev + 51
9   libc++abi.dylib                     0x00000001124bc124 _ZSt12__unexpectedPFvvE + 6
10  libc++abi.dylib                     0x00000001124bc967 __cxa_call_unexpected + 137
2017-10-04 14:10:47.126 AwesomeProject[82179:1638688] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.WebSocketModuleQueue>
2017-10-04 14:10:47.127 AwesomeProject[82179:1638688] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.SourceCodeQueue>
2017-10-04 14:10:47.127 AwesomeProject[82179:1638688] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.DevLoadingViewQueue>
2017-10-04 14:10:47.128 AwesomeProject[82179:1638688] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.PlatformConstantsQueue>
2017-10-04 14:10:47.128 AwesomeProject[82179:1638688] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.I18nManagerQueue>
2017-10-04 14:10:47.130 AwesomeProject[82179:1638688] ☣ Adding idling resource for queue: <OS_dispatch_queue: com.facebook.react.SettingsManagerQueue>
11  AwesomeProject                      0x000000010bdee3f4 _ZN8facebook5react11JSCExecutor16initOnJSVMThreadEv + 1876
12  AwesomeProject                      0x000000010bdeda01 _ZN8facebook5react11JSCExecutorC2ENSt3__110shared_ptrINS0_16ExecutorDelegateEEENS3_INS0_18MessageQueueThreadEEERKN5folly7dynamicE + 1025
13  AwesomeProject                      0x000000010bdee66d _ZN8facebook5react11JSCExecutorC1ENSt3__110shared_ptrINS0_16ExecutorDelegateEEENS3_INS0_18MessageQueueThreadEEERKN5folly7dynamicE + 29
14  AwesomeProject                      0x000000010bded198 _ZN8facebook5react18JSCExecutorFactory16createJSExecutorENSt3__110shared_ptrINS0_16ExecutorDelegateEEENS3_INS0_18MessageQueueThreadEEE + 440
15  AwesomeProject                      0x000000010be04e74 _ZN8facebook5react16NativeToJsBridgeC2EPNS0_17JSExecutorFactoryENSt3__110shared_ptrINS0_14ModuleRegistryEEENS5_INS0_18MessageQueueThreadEEENS5_INS0_16InstanceCallbackEEE + 580
16  AwesomeProject                      0x000000010be04f9d _ZN8facebook5react16NativeToJsBridgeC1EPNS0_17JSExecutorFactoryENSt3__110shared_ptrINS0_14ModuleRegistryEEENS5_INS0_18MessageQueueThreadEEENS5_INS0_16InstanceCallbackEEE + 29
17  AwesomeProject                      0x000000010be047ac _ZZN8facebook5react8Instance16initializeBridgeENSt3__110unique_ptrINS0_16InstanceCallbackENS2_14default_deleteIS4_EEEENS2_10shared_ptrINS0_17JSExecutorFactoryEEENS8_INS0_18MessageQueueThreadEEENS8_INS0_14ModuleRegistryEEEEN3$_0clEv + 636
18  AwesomeProject                      0x000000010be0451d _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRZN8facebook5react8Instance16initializeBridgeENS_10unique_ptrINS4_16InstanceCallbackENS_14default_deleteIS7_EEEENS_10shared_ptrINS4_17JSExecutorFactoryEEENSB_INS4_18MessageQueueThreadEEENSB_INS4_14ModuleRegistryEEEE3$_0EEEvDpOT_ + 45
19  AwesomeProject                      0x000000010be04249 _ZNSt3__110__function6__funcIZN8facebook5react8Instance16initializeBridgeENS_10unique_ptrINS3_16InstanceCallbackENS_14default_deleteIS6_EEEENS_10shared_ptrINS3_17JSExecutorFactoryEEENSA_INS3_18MessageQueueThreadEEENSA_INS3_14ModuleRegistryEEEE3$_0NS_9allocatorISH_EEFvvEEclEv + 41
20  AwesomeProject                      0x000000010bca6f6b _ZNKSt3__18functionIFvvEEclEv + 123
21  AwesomeProject                      0x000000010bca6c58 _ZN8facebook5react17tryAndReturnErrorERKNSt3__18functionIFvvEEE + 24
22  AwesomeProject                      0x000000010bc954a1 _ZN8facebook5react16RCTMessageThread7tryFuncERKNSt3__18functionIFvvEEE + 33
23  AwesomeProject                      0x000000010bc9b10f _ZZN8facebook5react16RCTMessageThread14runOnQueueSyncEONSt3__18functionIFvvEEEENK3$_2clEv + 175
24  AwesomeProject                      0x000000010bc9b04d _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRZN8facebook5react16RCTMessageThread14runOnQueueSyncEONS_8functionIFvvEEEE3$_2EEEvDpOT_ + 45
25  AwesomeProject                      0x000000010bc9ae09 _ZNSt3__110__function6__funcIZN8facebook5react16RCTMessageThread14runOnQueueSyncEONS_8functionIFvvEEEE3$_2NS_9allocatorIS9_EES6_EclEv + 41
26  AwesomeProject                      0x000000010bca6f6b _ZNKSt3__18functionIFvvEEclEv + 123
27  AwesomeProject                      0x000000010bc9530b _ZN8facebook5react16RCTMessageThread7runSyncENSt3__18functionIFvvEEE + 91
28  AwesomeProject                      0x000000010bc9584b _ZN8facebook5react16RCTMessageThread14runOnQueueSyncEONSt3__18functionIFvvEEE + 315
29  AwesomeProject                      0x000000010bdfddbe _ZN8facebook5react8Instance16initializeBridgeENSt3__110unique_ptrINS0_16InstanceCallbackENS2_14default_deleteIS4_EEEENS2_10shared_ptrINS0_17JSExecutorFactoryEEENS8_INS0_18MessageQueueThreadEEENS8_INS0_14ModuleRegistryEEE + 1182
30  AwesomeProject                      0x000000010bc36dbf -[RCTCxxBridge _initializeBridge:] + 3423
31  AwesomeProject                      0x000000010bc33f69 __21-[RCTCxxBridge start]_block_invoke.172 + 153
32  AwesomeProject                      0x000000010bc4fdac _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRU8__strongU13block_pointerFvvEEEEvDpOT_ + 60
33  AwesomeProject                      0x000000010bc4fbe9 _ZNSt3__110__function6__funcIU8__strongU13block_pointerFvvENS_9allocatorIS4_EES2_EclEv + 41
34  AwesomeProject                      0x000000010bca6f6b _ZNKSt3__18functionIFvvEEclEv + 123
35  AwesomeProject                      0x000000010bca6c58 _ZN8facebook5react17tryAndReturnErrorERKNSt3__18functionIFvvEEE + 24
36  AwesomeProject                      0x000000010bc315b0 -[RCTCxxBridge _tryAndHandleError:] + 80
37  Foundation                          0x000000010c3df948 __NSThreadPerformPerform + 334
38  CoreFoundation                      0x000000010dd0e2b1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
39  CoreFoundation                      0x000000010ddadd31 __CFRunLoopDoSource0 + 81
40  CoreFoundation                      0x000000010dcf2c19 __CFRunLoopDoSources0 + 185
41  CoreFoundation                      0x000000010dcf21ff __CFRunLoopRun + 1279
42  CoreFoundation                      0x000000010dcf1a89 CFRunLoopRunSpecific + 409
43  AwesomeProject                      0x000000010bc3131b +[RCTCxxBridge runRunLoop] + 1035
44  Foundation                          0x000000010c3a78ac __NSThread__start__ + 1197
45  libsystem_pthread.dylib             0x0000000112a6b93b _pthread_body + 180
46  libsystem_pthread.dylib             0x0000000112a6b887 _pthread_body + 0
47  libsystem_pthread.dylib             0x0000000112a6b08d thread_start + 13

My package.json contains the following:

react: 16.0.0-alpha.12
react-native: 0.48.4
babel-jest: 21.0.2
babel-preset-react-native: 4.0.0
detox: 5.8.1
jest: 21.1.0
react-test-renderer: 16.0.0-alpha.12

@LeoNatan It seems to be related to React-Native: 0.48.3+ version.
With React 16, RN: 0.48.2, Detox: 5.8.1 seems working correctly, with RN 0.48.3+ It hangs on opening the app with the same logs.

+1 getting the exact same error
  "devDependencies": {
    "babel-jest": "21.2.0",
    "babel-polyfill": "^6.26.0",
    "babel-preset-react-native": "4.0.0",
    "detox": "^5.8.1",
    "eslint": "^4.8.0",
    "eslint-config-react-native": "^1.6.0",
    "jest": "21.2.1",
    "mocha": "^4.0.1",
    "react-test-renderer": "16.0.0-beta.5"
  },

Tried both iOS 11.0 and 10.3, same results

+1 Same here
 "dependencies": {
    "@types/react": "^16.0.7",
    "@types/react-native": "^0.48.9",
    "i18n-js": "^3.0.1",
    "react": "16.0.0",
    "react-native": "0.48.4"
  },
  "devDependencies": {
    "@types/jest": "^21.1.1",
    "@types/react-test-renderer": "^15.5.4",
    "babel-jest": "21.2.0",
    "babel-preset-react-native": "4.0.0",
    "detox": "^5.8.1",
    "jest": "21.2.1",
    "mocha": "^4.0.1",
    "react-test-renderer": "16.0.0",
    "rimraf": "^2.6.2",
    "ts-jest": "^21.0.1",
    "tslint": "^5.7.0",
    "tslint-react": "^3.2.0",
    "typescript": "^2.5.3"
  }

Guys, we’re in the process of adding a test suite for modern RN versions (48,49). There currently is no support for these versions on Detox iOS. There’s no more need for examples, I think we have enough of them.
Stay tuned...

Can we help solving this issue? Is there any workaround so far?

If you wish to help debug this in native, upgrade the test project to 0.48 or 0.49, set the target to "none" in package json, add exception breakpoint in Xcode and run the test suite. It should reproduce and show where something has broken. We will be able to debug this early next week.

Ok, first findings: it fails at initOnJSVMThread

I'll take a deeper look now.

 Do you know on which line it fails?

Looking into it right now. Will let you know asap.
P.S. __dtx_canaryInTheCoalMine - quite creative 🐦

😎

JSCExecutor.cpp:L231 JSCNativeHooks::installPerfHooks(m_context); crashes the app. Going deeper.

I might be wrong, but I have a feeling that RCTPrepareJSCExecutor (see https://github.com/facebook/react-native/blob/1e8f3b11027fe0a7514b4fc97d0798d3c64bc895/React/CxxBridge/RCTJSCHelpers.mm#L53) should setup these hooks before we call it in JSCExecutor, but because of some overrides we never get there. Do you have any ideas, @LeoNatan?

Could be, but can't think of any swizzle that should stop FB from their logic.

Could you break point there and run once with Detox and once without? See if there is a change of flow?

For some reason, installPerfHooks which is supposed to be defined before initOnJSVMThread is even called, is null.

I double-checked and we do hit RCTPrepareJSCExecutor before, so it should be there... but it isn't

Ok, so to workaround (yep, it is a temporary hack) this issue you can go to JSCExecutor.cpp file and comment out JSCNativeHooks::installPerfHooks(m_context); line.
Although, keep in mind that you also need to workaround https://github.com/wix/detox/issues/267 (no solution found so far).

 I still can't get why installPerfHooks is null atm of invocation and how to workaround (or even understand what exactly happens) with #267.
Thanks for guiding me here. If I find something else - I'll comment here.

Ok, found it.
{
    //...
} else {
    //Modern RN
    cls = NSClassFromString(@"RCTCxxBridge");
    m = class_getInstanceMethod(cls, NSSelectorFromString(@"runJSRunLoop"));
}

class_getInstanceMethod ruins the entire flow. If m line is commented (or the entire else is removed), then everything works. As far as tests passes, I assume I can compose a PR to fix it 🙄 .
wdyt, @LeoNatan?

No 😆 that’s a major swizzle point for Detox.

I’ll look into it.

😆 I had to try

Once you take a look into it, can you explain how this swizzle point works? Based on the debug information, m is always NULL, so we don't have any specific logic after that. Don't get how this can be handy at all ¯_(ツ)_/¯

Take a look at swz_runRunLoopThread. We install one of the most important idling resources in the swizzled method. If the result is always NULL in 0.48 because the method has been renamed in RN: https://github.com/facebook/react-native/commit/7b770556ac6eb60094bdf59bfd14876b6e2a1307
I might do a blind commit with a fix for this problem alone; will you be able to test?

https://github.com/wix/detox/commit/fb0e4f06beebfa08ec1aa86373011125a6d3581a
Please try now. Maybe we'll luck out. 😆

Wow, it works! 🤣 🚀

Extreme programming at its best ‼

@Kureev , try letting the whole test suite run, see how it reacts.

I run the entire thing and it worked except the bug reported in #270

@Kureev Wait, I don't understand how 270 and this issue are related. Or not?
@rotemmiz ❤

If 270 is unrelated, I will close this issue.

@LeoNatan this one is unrelated to #270. Although, #270 is another critical issue that makes detox stay idle after all tests are run.
P.S. I think your https://github.com/wix/detox/commit/fb0e4f06beebfa08ec1aa86373011125a6d3581a closes this issue

Ahh the 270 is the Firebase issue. Yes, still needs to be looked at. OK, I am closing this one.

Damn, I'm really sorry, I meant https://github.com/wix/detox/issues/267, not #270 🤦♂

Can you please release a new patch version with this fix in it, @LeoNatan?

I will

@rotemmiz sir, when can we expect this patch?

@kacgrzes , 5.8.2 is out

@rotemmiz Is issue resolved? I tried with 5.8.0 and .48.1. But the app is still terminated. Thanks

Btw, I am not to sure why or how. But just to test what is wrong with RN and Detox, I initialise a whole new simple app with react-native init. And the put the ID to the first screen ever. The app is still showing the message: 'terminated' but the app will still be running and thus the testing example is still executed.
detox info 16:49:40: server listening on localhost:57332...
detox info 1: Searching for device matching iPhone 7...
detox info 3: Uninstalling org.reactjs.native.example.DetoxTestingApp...
detox info 3: org.reactjs.native.example.DetoxTestingApp uninstalled
detox info 4: Installing /Users/hientran/Desktop/React_Native/testDetox/DetoxTestingApp/ios/build/Build/Products/Debug-iphonesimulator/DetoxTestingApp.app...
detox info 4: /Users/hientran/Desktop/React_Native/testDetox/DetoxTestingApp/ios/build/Build/Products/Debug-iphonesimulator/DetoxTestingApp.app installed
detox info 5: Terminating org.reactjs.native.example.DetoxTestingApp...
detox info 5: org.reactjs.native.example.DetoxTestingApp terminated
detox info 6: Launching org.reactjs.native.example.DetoxTestingApp...
detox info 6: org.reactjs.native.example.DetoxTestingApp launched. The stdout and stderr logs were recreated, you can watch them with:
        tail -F $HOME/Library/Developer/CoreSimulator/Devices/DD9F5E50-3786-421A-A1BF-B86D937162D7/data/tmp/detox.last_launch_app_log.{out,err}
  Example
    ✓ should have welcome screen (697ms)

  1 passing (5s)

I attached the terminal log here. Hope this could help anything
@rotemmiz @LeoNatan

@rotemmiz thank you!

We ran into this ourselves too on RN 0.47.1!!
We used latest detox, version 5.8.4.
I didn't spent much time on it yet, just wanted you to know.
Downgrading to detox 5.6.0 solves the issue. But, that was just a quick test.

Hmm something strange is going on. On latest RN (> 0.48), the new version works, but it may have gotten broken on older versions?

as I posted in #270 - I get the same.
The strange thing is that people here are talking about RN 48, 49, but I'm on 47.0.2
XCode 9
Iphone 8 Simulator

There may have been a regression for older RN versions.

Upgrade your RN. I am not sure it is a priority for us to debug this. If anyone wants to help debug, that would be great.

Okay. Will try it later today/tomorrow. Updating RN is 99% a pain in the .... :)

What @simonracz said ;-) Will continue debugging with him today hopefully; so far I managed to create this;
RN 0.47.1 & Detox 5.6.0 -> Works with Xcode 8.3.2 -> DOESN’T work with Xcode 9.0.1
RN 0.47.1 & Detox 5.7.0 -> Works with Xcode 8.3.3 -> DOESN’T work with Xcode 8.3.2 && Xcode 9.0.1
RN 0.47.1 & Detox 5.8.4 -> DOESN’T work with Xcode 8.3.2 && Xcode 8.3.3 & Xcode 9.0.1
So for now we're stuck on Detox 5.6.0 in combination with Xcode 8.3.2 or 5.7.0 in combination with 8.3.3.

If you guys wants to debug at the source level, drop me a line here and I will try to help.

Ok, we just verified some extra versions.
Basically with Xcode 8.3.3 and RN 0.47.1 the following works too;
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Currently pinpointing what difference between<EMAIL_ADDRESS>and<EMAIL_ADDRESS>could make the difference with @simonracz

It can be reproduced on a fresh new RN project with version 0.47.1.
Created via react-native init v47 --version<EMAIL_ADDRESS>It had dummy views and tests, like in react-native-demo.
It crashed the same way.
detox_err.txt

Update:
Fresh dummy project does NOT work with 0.47.1 and 0.48.0
However, it works with 0.49.0!

@simonracz @alexcfaber I have just pushed a proposed fix for 0.48. Could you please test? It’s not included in 5.9.3 release.

What a timing. I just started to work on this again. I’ll test it today.

The issue was very interesting. My attribute constructor function was causing +initialize to run before the C++ default constructor, which caused their default to override something.

:+1:
@LeoNatan @rotemmiz I didn't do an extensive testing, but it works where it consistently failed before. (RN v0.47.2)

CI failed though in relaunchApp.

Hmm. Why would that fail? Are you also seeing it? Could be Travis flakiness.

I passed for me locally.

It failed again in CI, on XCode8.
I built/ran the local tests with XCode9.

Yes we saw. Not sure why yet.

Found the issue. It’s a slight difference of how runloops run in iOS 10 and iOS 11.
I am looking for an alternative solution.

Fixed. @rotemmiz Could you please release a new version? 😙


Question: can specify a different directory to /tmp to clone?

Hi team, I was evaluating this tool and I would like to know if it is possible to specify a different directory to /tmp to clone the repositories that I need?.
I can see in the documentation that it will clone to /tmp, but it might be nice to be able to specify a different directory...

Relates to #146
Yes, just specify the TMPDIR environment variable with the path to the directory. The directory must exist. Depending on your OS, this variable may be different. This works for me on macOS.


Default Miner ore/vein timer is off

Type
Incorrect behavior
Operating System
Windows
OS Version
Windows 11
Bug description
I have the timer for mine ores and veins turned on, and so far they are working for all the ores, but when using the timer in the motherload mine, it is off. Prior, it was off by being 15ish seconds too slow, now it is about the same but too fast. The timer ends, but you have to wait roughly 15-20 seconds until the vein respawns.
Screenshots or videos
No response
RuneLite version
RuneLite Ver. 1.9.16
Launcher Version 2.6.3
Logs
No response

I'd be interested to know how to recreate this. I could understand if the timers were too slow, that the ore-vein spawns faster than the timer indicates, but not the other way. I never observed that, and I can't see how it could even happen.
The timers were "fixed" by me in pr #16534, but are far from perfect. This was just a correction of the old approximation of the correct timers - which can be way off.
However, I improved the system for displaying ore-vein timers to more sophisticated in pr #16542. I believe that the timers will have an error margin of 0-3 seconds with that solution.

I am also seeing this issue, and had to use a seperate plugin for Motherlode Mine while mining. Timer starts Yellow, goes green about halfway, and stays such until completion, and the timer never extends past that point. Its consistantly 45 seconds after the completion of the timer, that it finally respawns the ore for me.

Hi @Adam-
I did quite a bit of testing on this in april and I am pretty sure I figured out how it works.
Obviously, the current method of respawn timers is flawed and probably off. But I have improved the method of detecting respawn times in PR #16542, so please have a look when you get the time.
To prove that the respawn time can be much shorter than 60 seconds, here are some steps to recreate that scenario:

Mine a fresh ore vein
As soon as you mine the first pay dirt, stop mining and set a timer for around 35 seconds
When 35 seconds has passed, mine the last pay dirt (it should deplete at this point)
Start a timer to see the respawn rate.

I just tried this twice in the upstairs mlm, and the respawn times were 52 and 47 seconds, respectively. If you wait a bit longer than 35 seconds, I bet it will respawn faster.

And I agree with your comment about #16681. I never observed a respawn time longer than 100 ticks.

fixed in 8550230de72fc37e751d70fa066f5afdc1670fd9


[replay] Validation errors when replaying RayTracingInVulkan

Describe the replay bug:
Replay of RayTracingInVulkan shows validation errors that weren't there during recording:
VUID-vkBindBufferMemory-bufferDeviceAddress-03339(ERROR / SPEC): msgNum:<PHONE_NUMBER> - Validation Error: [ VUID-vkBindBufferMemory-bufferDeviceAddress-03339 ] Object 0: handle = 0xc4f3070000000021, type = VK_OBJECT_TYPE_BUFFER; Object 1: handle = 0x301e6c0000000022, type = VK_OBJECT_TYPE_DEVICE_MEMORY; | MessageID = 0x44a78781 | vkBindBufferMemory(): buffer was created with the VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT bit set, memory must have been allocated with the VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT bit set. The Vulkan spec states: If the VkPhysicalDeviceBufferDeviceAddressFeatures::bufferDeviceAddress feature is enabled and buffer was created with the VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT bit set, memory must have been allocated with the VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT bit set (https://vulkan.lunarg.com/doc/view/1.3.268.0/linux/1.3-extensions/vkspec.html#VUID-vkBindBufferMemory-bufferDeviceAddress-03339)

Verify before submission:

Was trimming enabled? --> No
Was replayer renamed if necessary? --> No
Was --sync used if title is known to need forced synchronization? --> No

Build Environment:
Current dev, commit 548080b88a6efbdc93eee19d5d9d5bb3d4009e53
To Reproduce
Steps to reproduce the behavior:

Record using gfxrecon-capture-vulkan.py with no parameters other than --capture-layer
Or get the .gfxr file from capture.zip
Run gfxrecon-replay with no parameters (I enable validation using vkconfig, presumably you could also use --validate)

Screenshots:
(n/a)
System environment:

Radeon RX 7900 XTX with AMDVLK/XGL driver on Ubuntu 23.10

Title configuration:
RayTracingInVulkan, commit 164e530154cc4af465167ed88e743684424eaec6

Hi, @nhaehnle !  Thanks for your issue.  I'm not able to build RayTracingInVulkan on my Windows machine at this time (it looks like vcpkg_windows.bat references packages that are no longer mirrored on servers.  If I can find time, I'll try to build it and run it.
Can you try running the replay with -m rebind?

Investigation notes:

When we capture on a system with bufferAddressCaptureReplay, e.g. for ray-tracing acceleration structure buffer addresses, if the buffer is created with VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR we add VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT so we can get the same GPU address in replay.
binding a VkMemory without VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT to a VkBuffer with VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT precipitates a VUID-vkBindBufferMemory-bufferDeviceAddress-03339 message
Because we do not know VkBuffer and VkImage binding until VkBindBufferMemory time, we cannot add VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT to the VkMemory creation.

We may need to rely on -m rebind to set the correct bits on the VkMemory to match the requirements of the VkBuffer.

Also, adding VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT is only valid usage if the VkBuffer is created with VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT; best I can tall at the moment reading src/Vulkan/RayTracing/Application.cpp, in this case the buffer was not created with SHADER_DEVICE_ADDRESS_BIT, so do we need to investigate whether we are incorrectly setting that bit?  Or is RayTracingInVulkan doing something incorrect that VVL isn't catching?

I was able to build RayTracingInVulkan from Visual Studio 2022 Developer Command Prompt using vcpkg_windows.bat and then build_windows.bat with this patch applied and then verify invalid usage in replay of a capture.
diff --git a/src/ImGui/imgui_impl_vulkan.cpp b/src/ImGui/imgui_impl_vulkan.cpp
index dbd8b18..094e515 100644
--- a/src/ImGui/imgui_impl_vulkan.cpp
+++ b/src/ImGui/imgui_impl_vulkan.cpp
@@ -823,15 +823,15 @@ static void ImGui_ImplVulkan_CreatePipeline(VkDevice device, const VkAllocationC
     attribute_desc[0].location = 0;
     attribute_desc[0].binding = binding_desc[0].binding;
     attribute_desc[0].format = VK_FORMAT_R32G32_SFLOAT;
-    attribute_desc[0].offset = IM_OFFSETOF(ImDrawVert, pos);
+    attribute_desc[0].offset = offsetof(ImDrawVert, pos);
     attribute_desc[1].location = 1;
     attribute_desc[1].binding = binding_desc[0].binding;
     attribute_desc[1].format = VK_FORMAT_R32G32_SFLOAT;
-    attribute_desc[1].offset = IM_OFFSETOF(ImDrawVert, uv);
+    attribute_desc[1].offset = offsetof(ImDrawVert, uv);
     attribute_desc[2].location = 2;
     attribute_desc[2].binding = binding_desc[0].binding;
     attribute_desc[2].format = VK_FORMAT_R8G8B8A8_UNORM;
-    attribute_desc[2].offset = IM_OFFSETOF(ImDrawVert, col);
+    attribute_desc[2].offset = offsetof(ImDrawVert, col);

     VkPipelineVertexInputStateCreateInfo vertex_info = {};
     vertex_info.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO;
diff --git a/vcpkg_windows.bat b/vcpkg_windows.bat
index fce8041..e6e1e82 100644
--- a/vcpkg_windows.bat
+++ b/vcpkg_windows.bat
@@ -2,7 +2,8 @@ mkdir build
 cd build || goto :error
 git clone https://github.com/Microsoft/vcpkg.git vcpkg.windows || goto :error
 cd vcpkg.windows || goto :error
-git checkout 2023.04.15 || goto :error
+rem git checkout 2023.04.15
+git checkout 2023.11.20 || goto :error
 call bootstrap-vcpkg.bat || goto :error

 vcpkg.exe install ^

Hi Brad, thank you for investigating!
FWIW, when I add -m rebind to the options during replay, I get a ton of validation errors like the following, followed by a GPU fault:
VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03802(ERROR / SPEC): msgNum: 787975915 - Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03802 ] | MessageID = 0x2ef78eeb | vkCmdBuildAccelerationStructuresKHR(): No buffer is associated with pInfos[0].scratchData.deviceAddress (0x7ffc0119b200). The Vulkan spec states: For each element of pInfos, its scratchData.deviceAddress member must be a valid device address obtained from vkGetBufferDeviceAddress (https://vulkan.lunarg.com/doc/view/1.3.261.0/linux/1.3-extensions/vkspec.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03802)

On your investigation notes: Is there a reason not to use VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT unconditionally?

hello @nhaehnle!

I was able to reproduce your reported VUID-vkBindBufferMemory-bufferDeviceAddress-03339 during a replay using gfxrecon-replay --validate foo.gfxr.
running the original "Raytracer" application with validation-layers enabled I'm seeing:
The buffer on which pInfo->accelerationStructure was placed must have been created with the VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT usage flag (https://vulkan.lunarg.com/doc/view/1.3.280.0/linux/1.3-extensions/vkspec.html#VUID-vkGetAccelerationStructureDeviceAddressKHR-pInfo-09542)
I'm unable to reproduce reported VUID-vkBindBufferMemory-bufferDeviceAddress-03339 with replays of captures of other applications using VK_KHR_raytracing / VK_KHR_application.

to me it looks the reported validation-warning in your capture-replay, while not identical, is a consequence of improper API-usage in the original application (buffer missing VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT).

I'm closing this issue, but created a follow-up in 'RaytracingInVulkan'-repo, in case you want to track it:
https://github.com/GPSnoopy/RayTracingInVulkan/issues/78

Thanks for digging into it!


SMP Crash (NoClassDefFoundError)

http://pastebin.com/gvLWY5Jq
I was placing a Wireless Connector down on a Ztones block in creative mode.

My apologies -- I'm using the RV3 version of AE2stuff on RV2 stable. Sorry for opening this issue!

I ran in the same issue before didn't read that it is for rv3.


Removing a parent node and re-attaching another node as parent messes up the real_depth column

Version: master (v5)
Hey.
Given the following categories structure:
Root - real_depth 0
    CategoryA  - real_depth 1
        SubCategoryA  - real_depth 2
        SubCategoryB  - real_depth 2

If we remove the Root category, by default, the tree changes to:
CategoryA - real_depth 1
    SubCategoryA - real_depth 2
    SubCategoryB - real_depth 2

As you can see, the children nodes did not update their real_depth value. The issue is if I now add a new root category, the real_depth is only getting worse:
NewRoot - real_depth 0
    CategoryA  - real_depth 1
        SubCategoryA  - real_depth 3
        SubCategoryB  - real_depth 3

Note that the direct child (CategoryA) has updated its real_depth value to the correct one, however, its children (SubCategoryA, SubCategoryB) thought they were pushed 1 level deeper and their real_depth is now 3. If we repeat the process of deleting the root category and re-adding a new root category, you will see that the real_depth will continue to go "deeper" and increment to 4,5,6 etc.
Solution
As I see it, there are 2 ways to deal with this:

Not really a solution - Set the onDelete constraint to cascade instead of null which will simply remove the whole tree and this will bypass the problem.

Best solution - Keep the current behavior where the node's real_depth property is keeping incrementing and ensure that when we delete a parent node, we decrease the real_depth of its descendants by 1. This will cause the tree to look something like that after deletion:
CategoryA - real_depth 0
    SubCategoryA - real_depth 1
    SubCategoryB - real_depth 1

As you can see, after deleting a root node, we actually get a correct new tree.

What do you think?

Thanks for reporting kfirba i got the same issue with 5.1 and also had problems that the ancestor chain broke. I did a quick fix and my problems are solved.
public function moveTo($position, $ancestor = null)
{
    $parentId = (!$ancestor instanceof EntityInterface ? $ancestor : $ancestor->getKey());
    if ($this->parent_id == $parentId && !is_null($this->parent_id)) {
        if (isset($ancestor))
        {
	        $this->real_depth = $this->getNewRealDepth($ancestor);
		$this->isMoved = true;
		$this->save();
		$this->isMoved = false;
        }

        return $this;
    }

    if ($this->getKey() == $parentId) {
        throw new \InvalidArgumentException('Target entity is equal to the sender.');
    }

@arrowdesign Could you submit a PR with these changes and tests for them?

Sorry if it's inconvenient, but I just deprecated real_depth.


Missing output given single species of interest

As mentioned in #34 :
lossRates.output and productionRates.output do not have any output if only one species is in lossRatesOutput.config and productionRatesOutput.config

@rs028 Are you able to reproduce this with the latest version? I've tried it and I seem to get the expected output.

@ spco Yes it works.

Ok, I'll close this.


help followed users

How is the command written in Instaloader to download the profiles followed by a user (not oneself, another)?

Afaik this is only possible when using instaloader as python module.
An similar example is posted in the manual.
You need Profile.get_followees() (see here)


doc: update documentation for release 3.7.0

This commit add upgrade documentation for release 3.7.0
and also update support matrix for v3.7.0.
Depends-On: #3312
Signed-off-by: Humble Chirammal<EMAIL_ADDRESS>

@mergify refresh
Now using the correct Mergify Depends-On: tag as documented in https://docs.mergify.com/actions/merge/#defining-pull-request-dependencies


Possible to sort expand in getOne collection?

I'm trying to sort on column level in my recipient collection
async getContractorRecipients (value) {
  const response = await db.collection('contractors').getOne(value, {
      expand: 'recipients',
  })

  this.contractor = response
},

As an workaround im using now
getRecipientSorted: (state) => (value) => {
            const sorted = state.contractor.expand.recipients.sort(function(a, b) {
                return a[value] - b[value]
            })

            return sorted.filter(recipient => recipient.slm == type)
        }
    },

You can filter and sort direct relations using the filter and sort query parameters. Use dot notation to target the relation fields, eg. if in the above slm is the relation sort field:
async getContractorRecipients (value) {
  const response = await db.collection('contractors').getOne(value, {
      expand: 'recipients',
      sort: 'recipients.slm' // prefix with - for DESC order
  })

  this.contractor = response
}

Filtering and sorting of indirect relations is in the roadmap.


Maybe to replace Bitmab.Config instead a Glide?

Maybe to replace Bitmab.Config instead a Glide?
bcs even using ARGB_8888 we have glitches with gradients.
What you think? =)
(https://github.com/bumptech/glide)

It's the same


Feature/steane tutorial

This is a tutorial in pyQuEST for constructing Monte Carlo and density matrix simulations.

Hi Shaun,
This is a fantastic contribution, thanks very much for creating it! Apologies for our delay - things are insane right now, as we're busily preparing for an upstream refactor of QuEST, and the resulting changes in private projects downstream of pyQuEST. These changes may (although we're endeavouring to ensure otherwise) cause a change to the pyQuEST API, after which we'll need to revise the examples / tutorials. It might ergo take a little time (perhaps a couple of more months, eep) for us to review your tutorial and merge it into the repo.
Sorry for the frustratingly long wait, and thanks again for the PR!
Tyson


WizardHandler.wizard().goTo does not update the step indicator

When I use the WizardHandler.wizard().goTo('title') in my controller I go the current step in the wizard but the indicator does not show the previous steps as green. Is this a known issue?

Yes it is, you would need to toggle the editMode on the wizard, instructions on how to do that can be found in the README.md.
Hope this helps, if you want further functionality I would be happy to merge a PR.


Does Yii need a 'demo' enviroment?

For a project I'm writing, I've just added a DEMO Environment which exists alongside the "dev" and 'prod' environments.
The idea behind this is to enable web developers an easier means of creating a DEMO Version of their website. I.e. if the global constant YII_ENV_DEMO is defined, one can  activate specific code segments that would be needed in a demo version of the website.
If the yii community thinks this is a useful addition, I can create a pull request with the changes.
What does everyone think?

this is an application specific need so this constant can easily be defined in index.php of the project when needed. Imo it is not generic enought to be part of the framework by default.

apart from this constant, I dont think its a bad idea to elaborate on the practical requirements for a demo environment, as a demo environment in itself is generic enough. Its plays a important role in a development lifecycle.


Remove leading underscores to pass tests

What? and Why?

Adds additional MBS form types

Next time we could do with separate PR's as the extra surveys were lost in the reformatting and the PR name was misleading


Top P, K, P+K CUDA Kernel

Accelerate Top P and Top K sampling on GPU with CUDA. Integrate these so it is easier to change them.
Average performance numbers using: vocab_size=32000, batch_size=1 on RTX 4090
Average time taken by TopP: 572.04 microseconds (p=0.95)
Average time taken by TopK: 240.963 microseconds (k=5)
Average time taken by TopP+K: 257.105 microseconds (k=5, p=0.95)

could you please add some perf numbers?

I think you can merge your PR firstly and have a following PR to fix the double softmax and memory sharing issue.


Develop

Ready for first publish

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


parallel state machines must not have the same name

Consider the following example:
class A{
  sm{
    s0{
      goS1-> s1;
    }
    s1{
      t1{
        goT2-> t2;
      }
      t2{ }
      ||
      t1{
        goT4-> t4;
      }
      t4{}
    }
  }
}

We add parallel state machines as nested state machines to a state. It must be guaranteed that two state machines won't get the same name. Currently, we assign the name of the first state to the state machines. Since inside two different state machines, we can have exactly the same name states (initial state) so this approach is going to give exactly the same name to state machines. The result is having the same name for two separate state machines. This is not acceptable in target languages.
Generated code in Java
  //A State Machines
  public enum Sm { s0, s1 }
  public enum SmT1 { Null, t1, t2 }
  public enum SmT1 { Null, t1, t4 }
  private Sm sm;
  private SmT1 smT1;
  private SmT1 smT1;

we have two enums with the name SmT1;

@vahdat-ab what is desired behaviour? Should we just not allow a nested state machine to have states with the same name? Or, do we rename states when we detect duplicate names (i.e. t1_0, t1_1)? I have been playing around with your example in UmpleOnline.

So far, I have identified the area in UmpleInternalParser where parallel state machines are created for the UmpleModel. I have added comments to show my understanding of the code. Is this correct?
// Detects that the user has created a parallel state machine
...
else if (subToken.is("||"))
      {
        if (fromState.numberOfNestedStateMachines() == 0) { continue; }
        int previousSmIndex = fromState.numberOfNestedStateMachines() - 1;
              StateMachine nestedSm = fromState.getNestedStateMachine(previousSmIndex);
              if (nestedSm.numberOfStates() == 0) { continue; }
              nestedSm.setName(nestedSm.getState(0).getName());
              addNewSm = true;
              isConcurrentState = true;
      }
...

// After analyzing the "||" token, the next subtoken we analyze is the "state" token
// From analyzing "||" (subToken's previous value) we know that this state is
// a parallel state machine
else if (subToken.is("state"))
      {
        ...
          if (addNewSm)
        {
                  if (isConcurrentState)
                  {
                    nestedStateMachine.setName(s.getName());
                  }
          s.setIsStartState(true);
        }
       ...

@TimLethbridge  what do you thin about the desired behavior in this case?
If we don't use region names equal to the initial states, we might restructure many parts of the system. It means we need region names for any reference to states inside composite states.
In this case, for example, region names can be dynamic based on then the number of regions, such as region1,region2`, etc.

I think a rule that says initial states of a set of parallel regions must differ is fine. I would even be fine to say all states in a set of parallel regions must differ in name. I am thinking from a pragmatic modeling perspective: Allowing duplication confuses the model anyway, so raising an error I think is fine. Forcing naming of regions would force extra complexity on the modeler -- more complexity than forcing names of initial states to be distinct.

@jblang94  So we don't need to change renaming regions. You need to make sure these cases are detected and proper messages are sent to users. If these cases are detected and avoided, I believe the generated code should be fine.

@vahdat-ab @TimLethbridge
Thank you for your comments. So my understanding now is if we detect that two or more parallel states have the same name during compilation, we will throw an error, stop the compilation, and display an error message to the user. Is this correct? If it is, then I believe I will be making changes within UmpleInternalParser.

yes, that's right.

You simply need to add the error to en.error with appropriate arguments (and flag it as 2 for error in the correct field of en.error), call the method that raises warnings/errors. The system takes care of displaying the message to the user and stopping.


German translation

Description
We worked on all missing translations from January 2022. We made one important change: In German there are several ways for adressing genders and to use inclusive language. There are ongoing controversials on how to do that in detail. We sent a proposal by email to the German DSpace mailing list before translating it the way we did.
Instructions for Reviewers
This includes only changes to the German messages catalog.
Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes TSLint validation using yarn run lint
[x] My PR doesn't introduce circular dependencies
[x] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[x] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[x] If my PR includes new, third-party dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.

Looks good to me as well. Thanks @YPaulsen-TLC and @pnbecker !


[WIP] Add fs.Assert()

This PR adds fs.Assert() and fs.Compare() which are used to compare directory trees against an expected structure.
The code should be complete, and I've written unit tests but I'd like to validate the interface and write some examples before merging.
One of my concerns is the panic()s in the ExpectOp generators. I'd like to remove those, but I'm not sure how.
Another consideration is possibly moving this to fs/assert (a separate package from fs) to keep the generation separate from the assertion.

I think with #34 this should change to just providing a assert.Comparison and remove the Assert()

This just needs to be rebased on top of #81 to pickup the difflib changes. Otherwise I think I'm finally happy with this new API for fs.Equal.


Narrator reads contents of the previous page.

Describe the bug

When navigating to/from Animated Visual Player page, Narrator focus gets stuck on that page.
Steps to reproduce the bug

Steps to reproduce the behavior:

Launch XAML Controls Gallery and run Narrator.
Activate Animated Visual Player from home page.
Use "win+backspace" to go back to the previous page i.e homepage.
Now item navigate and observe narrator's description.

Expected behavior

Narrator should item navigate and read the contents of the current page.
Actual behavior

Narrator reads the contents of the previous page.
Screenshots

Version Info

Gallery version (found on Settings page):

<IP_ADDRESS>
Additional context

I have not been able to repro this strange behavior with any other page in the app.
Copied from internal bug

Not reproduceable on the latest version.


Error: Cannot find module 'eslint' when running in a workspace that uses Yarn Berry without the nodeLinker: node-modules.

Describe the bug
When trying to format a file with Prettier ESLint in a worksapce that uses Yarn Berry without the nodeLinker: node-modules, the extension fails with the following error trace:
Error: Cannot find module 'eslint'
Require stack:
- /workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js
- /ide/out/vs/loader.js
- /ide/out/bootstrap-amd.js
- /ide/out/bootstrap-fork.js
Error: Cannot find module 'eslint'
Require stack:
- /workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js
- /ide/out/vs/loader.js
- /ide/out/bootstrap-amd.js
- /ide/out/bootstrap-fork.js
	at Function.Module._resolveFilename (node:internal/modules/cjs/loader:956:15)
	at Function.resolve (node:internal/modules/cjs/helpers:108:19)
	at j4 (/workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:209:36)
	at zme (/workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:185:599)
	at vy (/workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:209:3779)
	at /workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:209:6494
	at Generator.next (<anonymous>)
	at /workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:1:734
	at new Promise (<anonymous>)
	at _y (/workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:1:554)
	at wge (/workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:209:6054)
	at Object.provideDocumentRangeFormattingEdits (/workspace/.vscode-remote/extensions/rvest.vs-code-prettier-eslint-5.1.0-universal/dist/extension.js:210:74)
	at J.provideDocumentRangeFormattingEdits (/ide/out/vs/workbench/api/node/extensionHostProcess.js:101:45314)
	at /ide/out/vs/workbench/api/node/extensionHostProcess.js:101:68425
	at se.s (/ide/out/vs/workbench/api/node/extensionHostProcess.js:101:62837)
	at se.$provideDocumentRangeFormattingEdits (/ide/out/vs/workbench/api/node/extensionHostProcess.js:101:68412)
	at t.N (/ide/out/vs/workbench/api/node/extensionHostProcess.js:111:11199)
	at t.M (/ide/out/vs/workbench/api/node/extensionHostProcess.js:111:10965)
	at t.H (/ide/out/vs/workbench/api/node/extensionHostProcess.js:111:10007)
	at t.G (/ide/out/vs/workbench/api/node/extensionHostProcess.js:111:9122)
	at i.value (/ide/out/vs/workbench/api/node/extensionHostProcess.js:111:7952)
	at w (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:1902)
	at w.fire (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:2119)
	at fire (/ide/out/vs/workbench/api/node/extensionHostProcess.js:76:13931)
	at i.value (/ide/out/vs/workbench/api/node/extensionHostProcess.js:127:30340)
	at w (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:1902)
	at w.fire (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:2119)
	at fire (/ide/out/vs/workbench/api/node/extensionHostProcess.js:76:13931)
	at s.z (/ide/out/vs/workbench/api/node/extensionHostProcess.js:76:16976)
	at i.value (/ide/out/vs/workbench/api/node/extensionHostProcess.js:76:15428)
	at w (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:1902)
	at w.fire (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:2119)
	at i.acceptChunk (/ide/out/vs/workbench/api/node/extensionHostProcess.js:76:11705)
	at i.value (/ide/out/vs/workbench/api/node/extensionHostProcess.js:76:10992)
	at w (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:1902)
	at w.fire (/ide/out/vs/workbench/api/node/extensionHostProcess.js:60:2119)
	at w.u (/ide/out/vs/workbench/api/node/extensionHostProcess.js:127:19064)

To Reproduce
Steps to reproduce the behavior: (it doesn't have to be nestjs, but it already has eslint and prettier setup)

npm i -g @nestjs/cli
nest new my-project
code my-project
Having installed Prettier ESLint, it should currently be working fine
if, for example, you remove a semicolon from the end of a line, then
you run format file (Option + Shift + F on macOS)
Now start using the latest Yarn Berry version yarn set version berry
yarn
Install the VS Code sdks yarn dlx @yarnpkg/sdks vscode.
(optional) Change the TS version in VS Code to use the workspace TS version.
(Everything should be working as expected so far)
Remove nodeLinker: node-modules from .yarnrc.yml
Run yarn
Repeating step 4, results in the error mentioned in this issue from Prettier ESLint.

Expected behavior
The extension is able to locate the eslint module in Yarn Berry projects that don't use the node-modules linker. And the file is formatted successfully.
Example Project
This behaviour can be replicated using a new nestjs proejct that can be setup as described in the To Reproduce section.
Screenshots
N/A
Versions (please complete the following information):

VS Code Prettier ESLint extension: v5.1.0
Visual Studio Code: 1.80.2 (Universal)
Node: v18.16.1
Package Manager<EMAIL_ADDRESS>prettier: ^2.8.8
eslint: ^8.42.0

System Specifications (please complete the following information):

OS: macOS Ventura 13.4.1
Processor: Apple M2 Pro
RAM Size: 32 GB

Additional context
ESLint alone works fine at raising errors/warns of non-confirming code.

Information is not enough, please provide your eslint config file and the whole project structure.By the way, you'd better install eslint and prettier locally.

你好 ，您发给我的邮件我已经收到。

你好 ，您发给我的邮件我已经收到。

Yes, it's not related with yarn sdk or Yarn Berry.
I follow the steps @emadzz  and reproduce it. To tell the truth, it's not caused by this Project. It's "prettier-eslint". In "prettier-eslint",  it uses require.resolve to search a module path, unfortunately , it doesn't search module under <user_workspace>/node_modules as expected, this is why we meet "cannot find module XXX".
So, I try my best to fix it. To make everything simple, you can visit my release page, download the .vsix file, install the plugin from this file. I hope my work could help you.
@ThaJay  @davidfarinha
By the way, you have to pay attention to the version of some dependencies:

prettier  should be ^2.7.1
eslint-plugin-prettier should be ^4.2.1


New Sample: Spatial Relationships

@philium @nixta Please review.

@philium Thanks for the feedback. I've addressed all comments. Please re-review.

@philium Updated storyboard as per your comments. Please re-review.


[WFRP4CharSheet] Fix images

Changes / Comments
Fix button images bug. Old files deleted, new files added.
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[x] Does the pull request title have the sheet name(s)? Include each sheet name.
[x] Is this a bug fix?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


NPE in TableChooserDialog: Null address passed to ProgramLocation

Describe the bug
Clicking the "Make a program selection from the selected rows" button with an empty selection results in an NPE and the error message:
"Null address passed to ProgramLocation. Trace and remove this problem".
To Reproduce
Steps to reproduce the behavior:

Run a script that creates a TableChooserDialog e.g. ShowConstantUse.java
Click the button with an empty selection as described above

Environment (please complete the following information):
ghidra 10.2 master (d0a8291)

Do you have the stack trace?   There is likely one specific place that null is being passed.  The stack trace should allow us to see that.

Thanks for the update.    This should be an easy fix.