When controller occurs before application controller

I have the issue:
undefined method `each_pair' for "new":String
# lib/mongoid/attributes/processing.rb:23:in `process_attributes'

The issue disappears when:

Removing load_and_authorize_resource and check_authorization from the controller (with the latest versions of devise(3.3.0) & cancancan(1.9.2) )
When the controller is renamed so that it occurs alphabetically after the application_controller.rb.

To see this error run this app: https://github.com/mrjlynch/sample-mongoid-error-app and go to localhost:3000/action/new

@mrjlynch Removing load_and_authorize_resource and check_authorization from the controller worked because issue is in build_resource method which is called by these methods internally.
After renaming controller, error didn't show up but your model  is not loaded correctly.
This error can also be avoided by defining param_method , see https://github.com/CanCanCommunity/cancancan#strong-parameters

We do not support Mongoid in the main gem anymore.


Integration Test - Release - 2019/03/28 01:26:43

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

@PRMergerTest2 : Thanks for your contribution! The author, @v-caxian, has been notified to review your proposed change.


Can't override value from style

Discussed in https://github.com/AvaloniaUI/Avalonia/discussions/13639

Originally posted by mohdimas November 17, 2023
hi there,
it seems that since updating to avalonia 11.0.5, I can no longer override a property of a control inline. It'll always pick the value from the style. So for example:
<Style Selector="Path.DownArrowBoldPath">
        <Setter Property="Width"
                Value="12" />
        <Setter Property="Height"
                Value="12" />
        <Setter Property="Data"
                Value="..." />
    </Style>

...

<Path Classes="DownArrowBoldPath"
           Width="20"
           Height="20" />

Then the path will have width and height of 12. is there any known issue? many thanks

@mohdimas seems to be fixed in latest nightly. Please ping me if it is not fixed for you yet.

@mohdimas seems to be fixed in latest nightly. Please ping me if it is not fixed for you yet.

Is it available in nuget? I only see 11.0.7

@mohdimas https://github.com/AvaloniaUI/Avalonia/wiki/Using-nightly-build-feed

@mohdimas https://github.com/AvaloniaUI/Avalonia/wiki/Using-nightly-build-feed

I tried to update to the latest version in the nightly build, but unfortunately it doesn't solve the issue. I tested it in this repo.
The inline property in a path that is defined in a template still can't override property from the style.


Add blog language field?

Many interesting blogs are not in English. Adding a language field/filter will help I think.
Thanks for this great blogs list.

More general question: Are non-English blogs accepted?

sorry to late reply, @StephaneArguin you're right about it. however, for me it can be hard to check the blogs. i will not close this issue but let me think about it a while. do you have any idea about it?

for me it can be hard to check the blogs
What criteria do you check? Is there a formal list of properties for a blog?

do you have any idea about it?
How about finding co-maintainers from native speakers of foreign languages?


[Question] Code coverage when merging sharded reports

I've used the documentation about Merge Shard Reports to successfully run my playwright tests in a sharded mode and then merge the monocart-reporter reports.
The problem I have though is that I'm using the Code Coverage Report feature and each shard contains a v8 code coverage report file. These files aren't merged using the technique described in the Merge Shard Reports section and though in this section you mention that:

You may need to transfer the attachments by yourself and update the path of the attachments with attachmentPath API.

That doesn't solve the issue of merging the code coverage reports right? If I manually transfer the code coverage attachments to the expected directory I will have the problem that the different shards have multiple code coverage files with the same directory structure. I would have to overwrite files ending up with the code coverage from only one of the shard runs right?
Any thoughts on this? Am I missing something or this isn't supported yet?

@edumserrano  Yes, it can only merge test reports, but not coverage reports.
See here: Merge Coverage Reports
Example: merge-code-coverage
I don't think we need to transfer the code coverage attachments, because it will generate new code coverage attachments after merged. But we need to use the raw report for merging code coverage. (in the example repo, the raw report will be transferred by github actions upload-artifact and download-artifact)
Long time no see 😊 Currently, MCR has become an independent tool specifically for code coverage, and monocart-reporter is just a custom reporter for playwright that simply integrates MCR without covering all its features. Therefore, if we need to use advanced code coverage features, perhaps we need to write some scripts manually, or even use MCR separately.

Following the instructions from both Merge Shard Reports and Merge Coverage Reports I've managed to create a single merge.js file that merges both the monocart-reporter reports and the monocart-coverage-reports reports.
The problem I'm facing now is that the link to the global code coverage options in the merged monocart-reporter report is incorrect.
What I'm doing is running my Playwright tests with two shards:

npx playwright test --shard=1/2 then copy the test results to <root-dir>/shards/1
npx playwright test --shard=2/2 then copy the test results to <root-dir>/shards/2

Then I run the merge.js and output the merged reports to <root-dir>/shards/merged. The contents of the merge folder look like this:
root-dir/
└── shards/
    └── merged/
        ├── monocart-report.html
        ├── monocart-report.json
        └── code-coverage/
            └── v8/
                └── index.html

The link on the monocart-reporter report at <root-dir>/shards/merged/monocart-report.html to the global code coverage points to <root-dir>/code-coverage/code-coverage/v8/index.html.
On the merge function from monocart-reporter I have tried to set the CoverageReportOptions.reportPath to <root-dir>/shards/merged/code-coverage/v8/index.html but that didn't take effect. Is this perhaps a bug or am I doing something wrong?
Note that on the playwright.config.ts which generates the sharded reports I do set the CoverageReportOptions.reportPath to path.resolve('./test-outputs/playwright/code-coverage', 'v8/index.html') which works fine when running without shards.

[NOTE]
 is used to mean the root directory of the project where for instance the playwright.config.ts, merge.js and package.json files are.

It seems a bit complex to merge coverage manually. I will consider whether it can also merge the coverage report when merging the test report.

I guess it would be nice merging the test reports would also take care of merging the coverage report. Meanwhile, following the instructions you provided it wasn't hard for me to get something like this:
// merge.js

const monocartReporter = require("monocart-reporter");
const coverageReport = require("monocart-coverage-reports");

async function mergeCodeCoverageReportsAsync() {
  const inputDir = [
    "./shards/1/code-coverage/raw",
    "./shards/2/code-coverage/raw",
  ];

  const coverageOptions = {
    name: "Merged Coverage Report",
    inputDir,
    outputDir: "./shards/merged/code-coverage",
    sourceFilter: (sourcePath) => {
      return (
        sourcePath.startsWith("projects/playground/src") ||
        sourcePath.startsWith("projects/ngx-module-federation-tools/")
      );
    },
    entryFilter: (entry) => {
      return !entry.url.includes("fonts.googleapis.com");
    },
    reports: [
      [
        "v8",
        {
          outputFile: "v8/index.html",
          inline: true,
          metrics: ["lines"],
        },
      ],
      [
        "console-summary",
        {
          metrics: ["lines"],
        },
      ],
    ],
  };

  await new coverageReport.CoverageReport(coverageOptions).generate();
}

async function mergeTestReports() {
  const reportDataList = [
    "shards/1/monocart-report.json",
    "shards/2/monocart-report.json",
    "shards/3/monocart-report.json",
    "shards/4/monocart-report.json",
  ];

  await monocartReporter.merge(reportDataList, {
    name: "My Merged Report",
    outputFile: "shards/merged/monocart-report.html",
    // the below has no effect
    // coverage: {
    //   name: "new name",
    //   reportPath: "./shards/merged/code-coverage/v8/index.html",
    // }
  });
}

const main = async () => {
  await mergeCodeCoverageReportsAsync();
  await mergeTestReports();
};

main();

And when executing with node ./merge.js, the output is:
[MCR] Merged Coverage Report
┌───────┬────────────┬─────────┬───────────┬───────┐
│ Name  │ Coverage % │ Covered │ Uncovered │ Total │
├───────┼────────────┼─────────┼───────────┼───────┤
│ Lines │    89.36 % │   7,401 │       881 │ 8,282 │
└───────┴────────────┴─────────┴───────────┴───────┘
[MR] merging report data ...
[MR] report data loaded: shards/1/monocart-report.json
[MR] report data loaded: shards/2/monocart-report.json
[MR] report data loaded: shards/3/monocart-report.json
[MR] report data loaded: shards/4/monocart-report.json
[MR] generating test report ...
[MR] coverage: code-coverage/v8/index.html Coverage Report - Playground app for @ln/ngx-module-federation-tools (global)
[MR] My Merged Report
┌─────────────┬──────────────────────┐
│ Tests       │ 354                  │
│ ├ Passed    │ 203 (57.3%)          │
│ ├ Flaky     │ 0   (0.0%)           │
│ ├ Skipped   │ 148 (41.8%)          │
│ └ Failed    │ 3   (0.8%)           │
│ Steps       │ 18360                │
│ Suites      │ 69                   │
│ ├ Projects  │ 3                    │
│ ├ Files     │ 22                   │
│ ├ Describes │ 0                    │
│ └ Shards    │ 4                    │
│ Retries     │ 0                    │
│ Errors      │ 151                  │
│ Logs        │ 0                    │
│ Attachments │ 9                    │
│ Artifacts   │ 1                    │
│ Playwright  │ v1.46.1              │
│ Date        │ 20/08/2024, 10:54:11 │
│ Duration    │ 4m 12s               │
└─────────────┴──────────────────────┘
[MR] html report: shards/merged/monocart-report.html (json: shards/merged/monocart-report.json)
[MR] view report: npx monocart show-report shards/merged/monocart-report.html

The directory where the merged reports are outputted looks like this:
root-dir
  shards
    merged
      monocart-report.html
      monocart-report.json
      code-coverage
        v8
          index.html

With this I'm almost there, there are two things that are missing:

I need to copy the attachments from each of the shard test reports into the merged directory <root-dir>/shards/merged. Or else I won't see the screenshots for diff, actual or expected. I could probably adjust the merge.js script to do this as well but for now I'm doing it manually. I just copied the relevant folders from each of the shards directory into this folder so that I can see the screenshots from failed tests.
The global code coverage link for the merged report is incorrect. It points to  <root-dir>/code-coverage/v8/index.html. If we notice the output from running node .\merge.js, we can see the line [MR] coverage: code-coverage/v8/index.html Coverage Report - Playground app for @ln/ngx-module-federation-tools (global). This path is correct if it was relative to the directory where the merge report was created, which for my example would be <root-dir/shards/merged/code-coverage/v8/index.html but what we get is  <root-dir/code-coverage/v8/index.html . I don't know why this is the case and it seems that setting the CoverageReportOptions.name and CoverageReportOptions.reportPath.

All this to say:

Yes it would be nice if merging the reports would be easier. If it would also merge the code coverage reports and even copy the screenshots to the merged directory. Being able to run a simple command similar to npx playwright merge-reports but for monocart-reporter would be truly awesome. However I can understand this is likely a large piece of work. What do you think?
Whilst you think whether or not the first option is something achievable, would it be perhaps a small/easy fix to allow the report path for the global code coverage to be set when merging the reports? That would at least mean there's a path forward for this right? Otherwise I don't know how I could resolve my issue. Or is this also something complicated to solve @cenfun?

Thanks, I have figured out how to merge coverage reports, and also copy attachments to the merged directory when merging test reports. WIP.

Please try<EMAIL_ADDRESS>Note: The coverage reports will be merged automatically if we specify the raw report in coverage options:
// global coverage options
coverage: {
    reports: [
        // for merging coverage reports
        'raw'
    ]
}

Testing results from<EMAIL_ADDRESS>Perhaps I'm doing something wrong but I got two problems:

On the merged report I got multiple links to the links to the code coverage under the artifacts section. There should only be one link correct?

The merged code coverage file is incorrect. It contains instead the coverage report from the last shard only.

How I executed the test
I run 4 test executions (4 shards) and then manually copied the output from monocart-reporter into shards/<shard-number> folder. This resulted in the following folder structure:
root-dir/
└── shards/
    ├── 1/
    │   ├── monocart-report.json
    │   ├── monocart-report.html
    │   ├── code-coverage/
    │   │   └── raw/
    │   │       └── ...
    │   └── assets/
    ├── 2/
    │   ├── monocart-report.json
    │   ├── monocart-report.html
    │   ├── code-coverage/
    │   │   └── raw/
    │   │       └── ...
    │   └── assets/
    ├── 3/
    │   ├── monocart-report.json
    │   ├── monocart-report.html
    │   └── assets/
    └── 4/
        ├── monocart-report.json
        ├── monocart-report.html
        └── assets/

Then I ran npx tsx ./playwright.monocart-reporter-merge.ts to merge the sharded reports. The playwright.monocart-reporter-merge.ts file looks like this:
import { MonocartReporterOptions, merge } from "monocart-reporter";

async function mergeTestReportsAsync(): Promise<void> {
  const reportDataList: unknown[] = [
    "shards/1/monocart-report.json",
    "shards/2/monocart-report.json",
    "shards/3/monocart-report.json",
    "shards/4/monocart-report.json",
  ];
  const options: MonocartReporterOptions = {
    name: "My Merged Report",
    outputFile: "shards/merged/monocart-report.html",
  };
  await merge(reportDataList, options);
}

async function main(): Promise<void> {
  await mergeTestReportsAsync();
}

main();

This resulted in a merged folder being created with the following structure:
root-dir/
└── shards/
    └── merged/
        ├── monocart-report.html
        ├── monocart-report.json
        ├── code-coverage/
        │   └── v8/
        │       └── index.html
        └── assets/

The merged code coverage is incorrect

When running without any shards the code coverage is 89.42 %.
When running with 4 shards the code coverage is:

shard 1: 85.29%
shard 2: 71.50%
shard 3: no code coverage because no chromium test was executed in this shard.
shard 4: no code coverage because no chromium test was executed in this shard.

After merging the code coverage is 71.50% (it used the code coverage report from the last shard).

@cenfun let me know if you need more information.

**In addition to the feedback above the MonocartReporterOptions.coverage doesn't seem to be respected at all when doing the merge with the merge function. **
For instance, after I run the sharded tests, following the same scenario as described in my previous comment, if I run npx tsx ./playwright.monocart-reporter-merge.ts to merge the sharded reports and set the MonocartReporterOptions.coverage as follows:
import {
  MonocartReporterOptions,
  ReportDescription,
  merge,
} from "monocart-reporter";

async function mergeTestReportsAsync(): Promise<void> {
  const codeCoverageReports: ReportDescription[] = [
    [
      "v8",
      {
        outputFile: "v8/index.html",
        inline: true,
        metrics: ["lines"],
      },
    ],
    [
      "console-summary",
      {
        metrics: ["lines"],
      },
    ],
    [
      "cobertura",
      {
        file: "cobertura/code-coverage.cobertura.xml",
      },
    ],
    [
      "lcovonly",
      {
        file: "lcov/code-coverage.lcov.info",
      },
    ],
  ];
  const reportDataList: unknown[] = [
    "shards/1/monocart-report.json",
    "shards/2/monocart-report.json",
    "shards/3/monocart-report.json",
    "shards/4/monocart-report.json",
  ];
  const options: MonocartReporterOptions = {
    name: "My Merged Report",
    outputFile: "shards/merged/monocart-report.html",
    coverage: {
      name: "new name",
      reportPath: "./shards/merged/code-coverage/v8/index.html",
      reports: codeCoverageReports,
    }
  };
  await merge(reportDataList, options);
}

async function main(): Promise<void> {
  await mergeTestReportsAsync();
}

main();

I would expect to get different types of code coverage, one for V8, one for console summary, one for cobertura and one for lcovonly. However, I only get a V8 report. The name and reportPath are also ignored.
Would this be something that could be supported?

Suggestion
It seems that some of these problems come from how you are deciding to merge monocart reports and its code coverage. If we take a look at the merge-cli from Playwright what they suggest is:

use the blob reporter to get raw data.
use the merge-cli to merge the report
optionally pass in a playwright configuration file for the merge operation, otherwise the default playwright.config.ts will be used. Note that configuration file for the merge only needs to export the configuration for the testDir and reporter values of the playwright configuration. Everything else is likely ignored.

If we draw a parallel for the monocart-reporter:

You also use the raw reporter to get code coverage. You have a json file with the monocart report data which probably serves as raw data for merging the test results.
Instead of a merge-cli we create a small merge script which uses a merge function from the monocart-reporter package to merge the reports
In the merge script we can specify the name of the merged report as well as the source of the sharded reports but nothing else. In contrast with the playwright merge cli which let's you specify other merge related settings such as the reporters to output from the blob (raw) reporter.

I think a lot of the issues I reported on the previous comments would be solved if the merge function respected more of the MonocartOptions which let you specify things like, where to output the reports, which code coverage options to use, etc.

I found that the output directory of raw report is code-coverage/raw in the shards. The default path should be 'coverage/raw', I think that's why the merge failed. Please do not use a custom output directory, this is not supported for now.

coverage options for shard

coverage: {
    reports: [
        // We can temporarily use 'console-details' or 'v8' to verify or check if the coverage is corrected, but it doesn't make sense for merging.
        //'console-details',
        //'v8',

        // used for merging and do not set the `outputDir`
        'raw'
    ]
},

coverage options for merging
In fact, the merge is generating new coverage reports with new coverage options from the raw data files.

Change the directory from code-coverage to just coverage
As per:

I found that the output directory of raw report is code-coverage/raw in the shards. The default path should be coverage/raw, I think that's why the merge failed. Please do not use a custom output directory for shard coverage, this is not supported for now (maybe fix it next patch).

I tried changing the coverage directory to be coverage instead of code-coverage, however that didn't change the outcome. On<EMAIL_ADDRESS>it still resulted in an incorrect code coverage after the merge. Still showing two links on the monocart report and they both show the code coverage from the last shard,
This is just to keep you informed, to let you know that it didn't work but it doesn't matter much because the behavior is different with version 2.7.1
Testing results from<EMAIL_ADDRESS>
[!NOTE]
Apologies if I didn't express myself correctly in the previous posts. I didn't mean to say that you should do things like the blob reporter and the merge-cli from Playwright. I was merely trying to use that as an example to point out that when trying to do a merge with monocart-reporter, the merge didn't seem to respect the configuration provided to it (like the fact that it wouldn't obey the code coverage options).
Version 2.7.1 changes this though, the code coverage options are now respected and things like the scenario from Another problem with coverage options not being respected are now working as expected.

Version 2.7.1 has improved on all of the issues I reported here 🎉. I believe I found a small bug but I'll open a separate issue for it as to not side track this one.
Thank you for the quick resolution @cenfun 🥇


visit GUI window not opening

I am running visit3.3.3 in Linux Mint 21.1. I am running Linuxmint by virtual box in a window host machine. After installing visit when I am giving the command to open visit GUI window. It only shows the message "Running: gui3.3.3" and the visit GUI is not opening (see the attached picture).
I am using visit for last 1 year. It was working fine. Suddenly this problem started for the last 3-4 days.
Desktop

OS and version: Linux Mint 21.1
Visit Version: 3.3.3

So, I think the GUI is immediately dying. Can you try a couple of things?
First try ./visit -debug 5 and attach here the any .vlog files you can find. You may need to tar them and/or compress them to get them to attach here.
Next, try ./bin/visit -cli -nowin and see if that gets you to a python prompt? If it does and if you know where some data is you can try to open, then try...
OpenDatabase(<my data file>)
AddPlot("Pseudocolor",<some variable>)
DrawPlots()
SaveWindow()

See if it generates a .png file. This will confirm quite a bit about what is working and not working.

@debasismpt125 checking if you were able to get any debug logs, let us know and we can take a look at them.


I have a problem with image loading DeepFace

I work strictly according to the documentation with git and I want to run a test check for recognition, but I get such an error:
package-list.txt my package-list.
File "c:\Users\Alex\Desktop\deepFace_recognition\deepface\tests\face-recognition-how.py", line 20, in
img1 = DeepFace.extract_faces(img_path="dataset/img1.jpg", target_size=target_size)[0]["face"]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "c:\users\alex\desktop\deepface_recognition\deepface\deepface\DeepFace.py", line 811, in extract_faces
img_objs = functions.extract_faces(
^^^^^^^^^^^^^^^^^^^^^^^^
File "c:\users\alex\desktop\deepface_recognition\deepface\deepface\commons\functions.py", line 152, in extract_faces
img = load_image(img)
^^^^^^^^^^^^^^^
File "c:\users\alex\desktop\deepface_recognition\deepface\deepface\commons\functions.py", line 106, in load_image
raise ValueError(f"Confirm that {img} exists")
ValueError: Confirm that dataset/img1.jpg exists

I'm trying to run face-recognition-how.py for a dataset

So following the traceback you shared: have you confirmed the the image exists?
For instance, sometimes you may provide the path to that image as dataset/img1.jpg but the correct path is actually dataset/img1.jpeg, or vice versa.

exception message is clear. you have to feed a valid image path.

Are you running unit_tests.py from the root directory, like so python tests/unit_tests.py?
If so, this will always fail. So you must cd into the test directory and run the unit_tests.py from there.
The reason for that is because of how the load_image function handles file paths - for now, it takes as input a relative path

Got it. I apologize, I misunderstood your initial comment.
Are you running face-recognition-how.py from the root directory, like so python tests/face-recognition-how.py?
If so, this will always fail. You must cd into the test directory and run the face-recognition-how.py from there.
The reason for that is because of how the load_image function handles file paths - for now, it takes as input a relative path


Changelog not updated

Hi! As I’m watching the repository, I noticed the releases always refer to the changelog for the changes, but the changelog is not up-to-date.
(I don’t know if this repo uses an automatic process for this or not, sorry if this issue feels off for some reason.)
Thanks again for your work on this package, it’s a very important CSS area. 🙏

oops, I didn't notice this.
I have not made release workflow yet. TBH I forgot this.
I'll fix it soon. Thank you!!


google-signin seems not to work

When I click the button the login dialog opens and login seems to be accepted but when I'm returned to the starting page the login button doesn't change to logout or something (still show "Sign in")

Login/logout works now but when I add/remove an element that uses google-signin it somehow breaks. I get for example "the debug target crashed"
in Dartium 1.13.0-edge.f3f358e5f38829f3284d7f922f2393d0803115dd (from September 14)


Custom animation in page transitions possible?

When transitioning between pages is it possible to specify the animation used? It defaults to slide up but I'd like to use slide in from left in certain cases and pop in for others.
Thanks!

Did you close this issue because you figured out how to specify animation, or because you did not require it any more?

Sorry, I still require the animation but I pulled down the source code and I saw it's just not as easy as passing in a parameter. I found this article and example code which shows how to do it:
https://github.com/jsuarezruiz/xamarin-forms-page-transitions
https://geeks.ms/jsuarez/2017/10/09/xamarin-forms-transiciones-entre-paginas/
(Google Translate required but it's readable)
It requires custom page renderers in the platform projects. I'm going to give it a go and if it works out I'll submit a PR.

Or if I'm WAY over complicating this just lemme know :)


Allow user apps installed with the Helm CLI to be upgraded from Rancher UI

Someone in the Rancher Users Slack wanted to know if they could upgrade an app through forms in the Rancher UI if they had previously installed the app with the Helm CLI.
As of v2.6.x, when apps are installed with the Helm CLI, they are visible under Apps & Marketplace under Installed Apps. When you click it, you can only see YAML and the upgrade option shows a blank page. The reason is that Rancher has no way to know what repository it should associate with the chart to look for new versions. It seems Rancher needs more information than that as well, so we would need to research what info we would need to get from the user in this case.
Ryan Hunt suggested that if you go to the edit/upgrade page for an app that was installed with the Helm CLI, the UI could present a form to let us “adopt” managing that app, asking for the repo it came from and anything else we may need to allow the app to be upgraded from the Rancher UI.

There's a mechanism already that should offer a list of charts to select if one isn't detected. I can't remember how that works though, or if it's only on the create/edit flow. It might be broken or only show if a previously known chart is missing (the repo/chart values are there but the repo was removed).
Whatever is implemented here should tie in to that process.

This sounds more like a bug to me in the logic than a problem with the design


Server browser UI overlap on controller

Yeah, this happens because we don't use footer buttons for the player/server count and someone manually lined them up with the button (and forgot about controller)


idea: add a field for users to attach files (e.g., jpg, png) to the review

Now, I don't know if this is nuts, but an editor we have recruited for being a mentor for the mentoring program said that he runs a graduate level course on peer review in which his students are asked to review a preprint. One of the assignments is to do a graphical abstract of the preprint. I was thinking that would be a great thing to add if one had it for the review. One concern would be if someone uploaded some porn images or something like that. How would we check for that?

So the current rich text editor actually does allow for images and videos! We can remove this functionality, but it is already built in. As far as moderating, I think it would have to be assumed that no one will post something outside of community guidelines, and if they do, it will be moderated and removed, and they may be removed as well.
Let me know if you have further questions about this, or if this is sufficient please close out the issue. Thanks!


Periodogram() should have power normalisation options

Problem description
I've received some feedback from Prof. Tim Bedding that units of Power Spectral Density are useful for solar-type oscillators, but not necessarily for other types. Power Spectral Density should be the default, but other types could be possible.
I'll seek out some more community feedback before building a functional example.
Example
pg = lightcurve.to_periodogram(normalization="psd")

Hi Daniel!
Thanks for your great comment--- This is a use case I haven't personally experienced so I'm glad you raise such a clear example. I've had Tim fill me in on the details while he was still here, so I'll try and write a pull request for this soon!

@danielhey Thank you for weighing in!!  Do you have a suggestion as to what Lightkurve's ideal interface might be to enable you to avoid the extra conversions?

Hi Daniel,
If you wanted to do this one that would be great! You've got more experience on this topic so it would almost certainly turn out better than if I did it. Having it as a property is a neat idea, and a kwarg in from_lightcurve() was what I was thinking as well.
Cheers!

I struggle to think of anything more exciting than @danielhey preparing a PR and @ojhall94 testing and reviewing it. :heart:
Note: over in #403 we just tinkered with the API to provide a generic Periodogram parent class and specific LombScarglePeriodogam and BoxLeastSquaresPeriodogram sub classes.  The latter hold extra data and methods which are specific to those methods.  I imagine psd normalization can go in the parent class (@christinahedges ?), but either way you will want to make sure to start a PR from the most recent version of the master branch because of these changes!

This can be closed with #416 having been merged


No installation instructions

No installation instructions are provided in the README.md
I can see mentioning of building a phar, is it not possible to get this installed as a binary in ./vendor/bin using composer or installed globally?

Thanks for finding this, instructions added to the readme, feel free to add a PR for composer binary functionality!


Docs do not automatically update

Master PRs that are accepted do not trigger a rebuild of the docs

I remember this was mentioned somewhere: https://docs.rs/

There's a way to push it to our GH pages so we don't need to publish stuff on cargo, and an easy script to get it working.  In the travis yml I just needed to add this (we'd need to make sure it only does this on master branch pushes)
after_success: |
    cargo rustdoc \
    && echo '<meta http-equiv=refresh content=0;url=rust-vst/index.html>' > target/doc/index.html && \
    sudo pip install ghp-import && \
    ghp-import -n target/doc && \
    git push -qf<EMAIL_ADDRESS>gh-pages

Of course that's only considering it builds correctly on Unix systems, I'm not sure if there's a way to do the same on appveyor.


Modules with alias are not mocked

Describe the bug
If I try to mock a module imported by another module, by providing an alias as key, such as vi.mock('@module-alias'), the module is not mocked as expected.
If I provide the relative path as key, such as vi.mock('..src/MyModule'), the module is mocked as expected.
// MyInnerModule
export const MyInnerModule = { key: undefined }

// MyModule
import { MyInnerModule } from '@/MyInnerModule'
export const MyModule = { key: MyInnerModule.key }

// MyModule.test
import { MyModule } from '@/MyModule';
import { vi, describe, it, expect } from 'vitest';

// Try with relative path ../src/MyInnerModule, it works
vi.mock('@/MyInnerModule', () => {
  return {
    MyInnerModule: {
      key: 1,
    },
  };
});

describe('MyModule', () => {
  it('should have key', () => {
    expect.assertions(1);
    expect(MyModule.key).toBe(1); // Got undefined
  });
});

This issue may be related to https://github.com/vitest-dev/vitest/pull/2777 but it didn't solve my case.
Reproduction
Stackblitz, follow the instruction on line 4 to switch between non working and working
https://stackblitz.com/edit/vitest-dev-vitest-qj31uc?file=test/MyModule.test.ts
System Info
All the infos are on stackblitz:

  "devDependencies": {
    "@vitest/ui": "latest",
    "vite": "latest",
    "vitest": "0.29.8"
  },

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Don't use relative paths in aliases: https://vitejs.dev/config/shared-options.html#resolve-alias


Update and configure gatsby-plugin-purgecss.

https://github.com/GatsbyCentral/gatsby-starter-wordpress/issues/40
Updated gatsby-plugin-purgecss to latest major version. (needed for newer options)
Enabled purging when running gatsby develop.
Specify to purge only all.sass file.
Sidenote: I see that the lock files are very old, which force installs the older version of the packages.

I would be better to not use lockfiles in this starter or maintain updated lockfiles using renovate, greenkeeper or dependabot.

@anantoghosh Awesome, thanks a lot. Great PR. Delighted to merge.


PlaceOpeningHoursPeriod has contradicting documentation

The close field on the PlaceOpeningHoursPeriod structure is marked as required but the documentation says:

If a place is always open, the close section will be missing  [...]

which indicates that close should be optional.

@ubamrein Thank you for opening this issue. 🙏
Please check out these other resources that might be applicable:

Support Console - If you have a support contract.
Discord - chat with other developers
StackOverflow - use the google-maps tag
Google Maps Platform issue trackers

This is an automated message, feel free to ignore.


Feature: Localization Processors

This is a slightly exotic feature request. I won't mind if you close this request but I still wanted to bring it up as I found it useful in our situation.
We have a Japanese translation in our current game and weren't satisfied in how TMP breaks lines in Japanese. I've created a system that uses MeCab to analyze the text and automatically insert <nobr> tags and zero-width spaces to make TMP break the lines where we want.
I've considered a few options for where to integrate this processing. I wanted to keep the original translation files, so the processing could be fixed/improved and then re-applied. But I also wanted it to work seamlessly, without having to manually run it and create some additional artefacts that then could get out of date.
For this, integrating into the YarnProjectImporter was the best option. This way, whenever a translation file is updated, the processing is run automatically when importing the lines into the project.
Unfortunately, there's no way to extend the current project importer to do some additional processing on the translations. So I've modified the importer to allow just that:
/// <summary>
/// Process Yarn localizations as they are imported.
/// Requires modification to the <see cref="YarnProjectImporter"/>.
/// </summary>
public abstract class YarnLocalizationProcessor
{
    /// <summary>
    /// The language id to process.
    /// </summary>
    public abstract string LanguageId { get; }
    /// <summary>
    /// Process the localization entries.
    /// </summary>
    public abstract IEnumerable<StringTableEntry> Process(IEnumerable<StringTableEntry> entries);
}

In YarnProjectImporter.OnImportAsset, before iterating languagesToSourceAssets:
// Find and create localization processors
List<YarnLocalizationProcessor> processors = null;
var processorTypes = TypeCache.GetTypesDerivedFrom<YarnLocalizationProcessor>();
if (processorTypes.Count > 0) {
    processors = new List<YarnLocalizationProcessor>();
    foreach (var type in processorTypes) {
        processors.Add((YarnLocalizationProcessor)System.Activator.CreateInstance(type));
    }
}

In YarnProjectImporter.OnImportAsset, after parsing the CSV:
// Run localization processors
if (processors != null) {
    foreach (var processor in processors) {
        if (processor.LanguageId != pair.languageID)
            continue;
        stringTable = processor.Process(stringTable);
    }
}

What do you think, is this something that could be useful to merge?
Of course, the interface does not need to work exactly like this, that's just something I created ad-hoc to get it working. One possible improvement could be to use AssetImportContext.DependsOnCustomDependency to allow versioning the processors independently of the project importer.

This is a cool idea, I think my main thought is any reason why this isn't better done as a line provider subclass?
Line providers are already intended to be customised based on the needs of your game.
So in your custom line provider subclass when it gets its call to PrepareForLines call you could do something like:
override void PrepareForLines(IEnumerable<string> lineIDs)
{
   if (processor.LanguageID == this.textLanguageCode)
   {
      // do custom processor stuff here
   }
}

Or even at presentation time by overriding GetLocalizedLine and do it on a line by line basis instead.
Thoughts?

Upon reflection we feel this is a presentation concern, not an import concern so a line provider is the best way forward.
Thanks for the issue.


Add contribution note to cops documentation generator

Occasionally I reviewed direct edit to cops documentation.
This is similar in intent to the following:
https://github.com/rubocop/rubocop/pull/11563
For source code comments, refer to the AsciiDoc documentation: https://docs.asciidoctor.org/asciidoc/latest/comments/#comment-blocks

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[ ] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Good idea!


Add support for rundeck trigger

Support for RunDeck Plugin's post-deployment job.

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests


Jtx offer test

Exercise the jtx json funclet by porting one of the js offer tests to the jtx framework. The first commit has already passed review. Only the second commit needs to be reviewed.
@HowardHinnant @miguelportilla

:+1:  The new test syntax is looking good.

Rebased onto latest develop and addressed review comments


Support linux/loong64 Arch

Description
Add support for loong64 builds.
Motivation and Context
To be able to build binaries for loong64.
How to test this PR?
Link: https://github.com/golang/go/issues/46229

It seems a bit involved to add such support. We have to:

bump https://github.com/tonistiigi/xx toolchain components to very recent versions (binutils 2.40+, Clang 16+, go 1.19+ but ideally the next version that's go1.21.0), and
ideally bump the QEMU version to 8.0+

before doing the trivial additions. (Which may or may not be so, depending on the tools involved.)

After #151 #174 , Why is there still no linux/loong64 image? missing one platform in https://github.com/tonistiigi/binfmt/blob/master/docker-bake.hcl ?
target "all-arch" {
  platforms = [
    "linux/amd64",
    "linux/arm64",
    "linux/arm/v6",
    "linux/arm/v7",
    "linux/ppc64le",
    "linux/s390x",
    "linux/riscv64",
    "linux/386",
  ]
}

@tonistiigi @yzewei @vicamo

After #151 #174 , Why is there still no linux/loong64 image? missing one platform in https://github.com/tonistiigi/binfmt/blob/master/docker-bake.hcl ?

You could use a little patience or make it happen yourself ;-) LoongArch availability is a bit limited especially outside of China, and open-source projects like this usually are severely limited in manpower, so you cannot expect people to keep their eyes on LoongArch at all times.
I'll try adding the support in a few days. If you see a PR fixing this issue, that'd be it, or I'll post on why this is still not feasible at the moment ;-)

After #151 #174 , Why is there still no linux/loong64 image? missing one platform in https://github.com/tonistiigi/binfmt/blob/master/docker-bake.hcl ?

You could use a little patience or make it happen yourself ;-) LoongArch availability is a bit limited especially outside of China, and open-source projects like this usually are severely limited in manpower, so you cannot expect people to keep their eyes on LoongArch at all times.
I'll try adding the support in a few days. If you see a PR fixing this issue, that'd be it, or I'll post on why this is still not feasible at the moment ;-)

@xen0n Thanks!
It is better to wait for the alpine community to support loongarch before submitting a similar PR, otherwise it will be different from other architectures and bring additional code maintenance burden

After #151 #174 , Why is there still no linux/loong64 image? missing one platform in https://github.com/tonistiigi/binfmt/blob/master/docker-bake.hcl ?
target "all-arch" {
  platforms = [
    "linux/amd64",
    "linux/arm64",
    "linux/arm/v6",
    "linux/arm/v7",
    "linux/ppc64le",
    "linux/s390x",
    "linux/riscv64",
    "linux/386",
  ]
}

@tonistiigi @yzewei @vicamo

@emmansun As I said earlier, if you currently need to use a loongarch-based binfmt image, https://lcr.loongnix.cn

It seems tonistiigi/xx needs to get LoongArch awareness: the xx-info helper currently does not handle the loongarch64 loong64 things, which it definitely needs to. And the fact that the Alpine arch names are recorded means we'd better wait until things settle at Alpine side -- at least the architecture name needs to be frozen.

It seems tonistiigi/xx needs to get LoongArch awareness: the xx-info helper currently does not handle the loongarch64 loong64 things, which it definitely needs to.

This doesn't affect non-loong64-host builds -- it is used to exclude the *-linux-user configuration corresponding to the host arch, but we're primarily concerned with having loong64 emulation on other hosts e.g. amd64 or arm64. I've made #186 to hopefully fix this issue.

According to https://alpinelinux.org/posts/Alpine-3.21.0-released.html, loongarch64 support was added to Alpine Linux very recently. Note, I don't have access to any loongarch64 hardware, I'm just using your container image via setup-qemu-action and noticed that Alpine Linux supports now an architecture, that I can't cross-compile in GitHub actions of my projects, yet.


PageSize on sayings page is changed when going back from action page

Steps to reproduce:

Create more than 5 sayings in the sayings page
Change to a page size different than 5
Enter to the action by editing an action or by trying to create a new action
Go back to the sayings page
BUG: page size is 5

I'm not pretty sure if this only happens with the back card at the left of the screen

Couldn't re-produce.


Finch Icon doesn't show up on GitHub iPhone App

Describe the bug
Finch logo is blank in the GitHub App finch repository.
Steps to reproduce

Open GitHub app on your iPhone.
Go to finch repository.
Check the read me section.
Finch logo/icon is blank.

Expected behavior
Finch icon is displayed.
Screenshots or logs
If applicable, add screenshots or logs to help explain your problem.
Additional context
Add any other context about the problem here.

Seems like a standing issue. See:

https://github.com/github/markup/issues/556
https://github.com/isaacs/github/issues/316

Thanks for taking care of this. Icon now shows up in the GitHub App.


ICS-20 Fungible Token Transfer Support

We need to implement a variant of ICS-20 that shields tokens as they're transferred into Penumbra.
There are two alternative mechanisms for doing this:

Specify a Penumbra address directly as the destination address.  The IBC component of the Penumbra chain sees this destination address, and then deterministically generates a (public) blinding factor for a note with the correct value and denomination controlled by the specified destination address, and then includes that (public) note in the chain state.
The sender creates a (private) note, and submits an encryption of the note, the note commitment, and a zkproof of correctness, all bundled up and encoded in the destination address field of the transfer as a "one-time deposit address".  The IBC component of the Penumbra chain verifies the proof and checks consistency with the claimed transfer amount, then includes the (private) note in the chain state.

The difference is that in (1), observers learn the address the funds were transferred to, while in (2), the addresses are not revealed.  This provides better privacy, but at a fairly steep cost to usability/interoperability, since sending funds into Penumbra requires an implementation of our proof system.
On the other hand, while (1) reveals the link between the transparent counterparty chain address and the destination shielded address on Penumbra, there's no further information leak, and any use of the transferred funds within Penumbra can't be linked to the address or the transfer.
Because of the usability cost, I think it would be better to start with (1) as a pragmatic choice.
Further components to implement:

[x] #976
[x] #977
[x] #980
[x] #978
[x] #979
[x] #982
[x] #985
[ ] #981
[x] #2534
[ ] #2284

This is all implemented now, with the exception of any additional circuit breakers we want to add (in addition to the ones in the ICS-20 spec), and handlers for packet timeouts.

Almost there! We still need to tackle https://github.com/penumbra-zone/penumbra/issues/981, and we just added mention of https://github.com/penumbra-zone/penumbra/issues/2284, since that's required for us to close this tracking issue out confidently.

@avahowell Can we close this out? It looks like #981 may already be done?


Adding environment variables page

Adding a new environment variables page to the Okteto manifest section. This is part of an effort to break out the various concepts of the manifest into smaller, digestible content pieces.

cc @pchico83 for review

It seems there is some kind of error building the preview environment

Closing in favor of https://github.com/okteto/docs/pull/581 which felt like a cleaner way to go about merging this content 😄


Instantiated tearoffs of equal functions are not equal

According to the @eernstg equality of local functions is not specified. But we do specify that the equality properties of any function object obtained by generic function instantiation is determined by the equality of the source function objects.
But the following test fails
import "../../Utils/expect.dart";

main() {
  X localFunction<X>(X x) => x;

  var f1_1 = localFunction;
  var f1_2 = localFunction;
  var f2_1 = f1_1<int>;
  var f2_2 = f1_2<int>;

  Expect.equals(f1_1 == f1_2, f2_1 == f2_2);
}

If f1_1 == f1_2, then it must be f2_1 == f2_2 or vice versa, if f1_1 != f1_2, then we should have f2_1 != f2_2. Anyway Expect.equals() in this test must pass but it doesn't
Tested on Dart SDK version: 2.15.0-139.0.dev (dev) (Wed Sep 22 12:41:36 2021 -0700) on "windows_x64"

@sgrekhov, I'm not sure about the configurations where this failure occurs (it could be a common-front-end-only behavior, but it could also depend on the backends). Do you have more precise information about the failing configurations?

@eernstg it's a runtime error on dartk and dartkp configurations. Please see https://dart-ci.firebaseapp.com/cl/215543/1

OK, thanks!

https://dart-review.googlesource.com/c/sdk/+/215620 fixes
co19/LanguageFeatures/Constructor-tear-offs/equality_A03_t01
co19/LanguageFeatures/Constructor-tear-offs/equality_A03_t02
co19/LanguageFeatures/Constructor-tear-offs/equality_A03_t04

The test co19/LanguageFeatures/Constructor-tear-offs/equality_A03_t05 still fails because it has an incorrect expectation, filed https://github.com/dart-lang/co19/issues/1210.


How do I add react-native-macos to an existing React Native project?

I have an existing React Native project with iOS, Android, Windows, and web. I would also like to experiment with support for MacOS.
Is there a command I can run that will add a "mac" directory? It would be great if the README could be updated with these instructions.
EDIT: Ok it wasn't too hard, I just ran the init command, then copied macos into my app, and updated my package.json to include react-native-macos.
EDIT 2: Ok damn, now I'm getting a ton of these errors:
This error is caused by a @providesModule declaration with the same name across two different files.
Error: @providesModule naming collision:
  Duplicate module name: ReactNative
  Paths: <myapp>/node_modules/react-native-macos/Libraries/react-native/ReactNative.js collides with <myapp>/node_modules/react-native/Libraries/Renderer/src/renderers/native/ReactNative.js

Do I need to replace react-native with react-native-macos? Would it be possible for you to fix this in a similar way to react-native-windows?

Sorry I just saw #65. A big +1 to that.

You can add rn-cli.config.js for handling these issues. Something like this worked for me https://gist.github.com/ptmt/b1473dead098cf53d667e355aedf2a7b (though, it's quite old, worked with the RN 10 months ago. Now I'm working on #163, so it might change a bit.

Oh wow, thanks! I didn't know that existed. I'll try it out.
On 18 May 2017, 2:13 PM +0700, Dima Loktev<EMAIL_ADDRESS>wrote:

You can add rn-cli.config.js for handling these issues. Something like this worked for me https://gist.github.com/ptmt/b1473dead098cf53d667e355aedf2a7b (though, it's quite old, worked with the RN 10 months ago. Now I'm working on #163 (https://github.com/ptmt/react-native-macos/pull/163), so it might change a bit.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (https://github.com/ptmt/react-native-macos/issues/164#issuecomment-302320951), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAIhELyPQHwTMIb07Ag_0_s2xoTsGh_0ks5r6--PgaJpZM4Nd62J).

I've added the project successfully to my existing RN project, but I'm running into one last issue when trying to run the app.
The React-Packager is throwing this error:
error: bundling: UnableToResolveError: Unable to resolve module `react-native` from `/Users/**/index.macos.js`: Module does not exist in the module map or in these directories:
  /Users/**/node_modules

index.macos.js
import { AppRegistry, StyleSheet, Text, View } from 'react-native';

When I change 'react-native' to 'react-native-macos' It's all working just fine. Isn't 'react-native' supposed to resolve to macos automatiscally by the mac cli?
How to fix this? obviously I want to import from 'react-native' so I can share components between platforms.

You're right. There is a specific babel resolver for making that alias. Could you please check that you have installed babel plugins and this config in your package.json or .babelrc? https://github.com/ptmt/react-native-macos/blob/master/local-cli/templates/HelloWorld/_babelrc

@ptmt Tried adding the above mentioned babelRC config and it doesn't seem to have solved the issue.
.babelrc
{
  "presets": [
    "react-native-stage-0"
  ],
  "plugins": [
    ["module-resolver", {
      "alias": {
        "react-native": "react-native-macos",
      }
    }]
  ]
}

rn-cli.config.js
const path = require('path');

// Don't forget to everything listed here to `package.json`
// modulePathIgnorePatterns.
const sharedBlacklist = [
  /node_modules[/\\]react[/\\]dist[/\\].*/,

  'downstream/core/invariant.js',

  /website\/node_modules\/.*/,

  // TODO(jkassens, #9876132): Remove this rule when it's no longer needed.
  'Libraries/Relay/relay/tools/relayUnstableBatchedUpdates.js',
];

const platformBlacklists = {
  web: [
    '.ios.js',
    '.android.js',
  ],
  ios: [
    '.web.js',
//    '.android.js',
    /node_modules\/react-native-macos\/.*/,
  ],
  android: [
    '.web.js',
    '.ios.js',
    /node_modules\/react-native-macos\/.*/,
  ],
  macos: [
    '.ios.js',
    '.android.js',
    /node_modules\/react-native\/.*/,
  ],
};

function escapeRegExp(pattern) {
  if (Object.prototype.toString.call(pattern) === '[object RegExp]') {
    return pattern.source.replace(/\//g, path.sep);
  } else if (typeof pattern === 'string') {
    const escaped = pattern.replace(/[\-\[\]\{\}\(\)\*\+\?\.\\\^\$\|]/g, '\\$&');
    // convert the '/' into an escaped local file separator
    return escaped.replace(/\//g, `\\${path.sep}`);
  }
  throw new Error(`Unexpected packager blacklist pattern: ${pattern}`);
}

function blacklist(platform, additionalBlacklist) {
  // eslint-disable-next-line
  return new RegExp('(' +
    (additionalBlacklist || []).concat(sharedBlacklist)
      .concat(platformBlacklists[platform] || [])
      .map(escapeRegExp)
      .join('|') +
    ')$'
  );
}

module.exports = {
  getBlacklistRE(platform) {
    if (process && process.argv.filter(a => a.indexOf('react-native-macos') > -1).length > 0) {
      return blacklist('macos')
    }
    return blacklist(platform);
  },
};

Please let me know if there is anything I am missing.

Could you please post your package.json also? And add something like `"react-native-test": "react-native-macos", to babel config resolver section?

{
  "name": "PROJECT_NAME",
  "version": "0.1.0",
  "private": true,
  "engines": {
    "node": ">=8.1.0",
    "npm": ">=5.1.0"
  },
  "devDependencies": {
    "babel-eslint": "^8.0.0",
    "babel-plugin-module-resolver": "^2.7.1",
    "eslint": "^4.6.1",
    "eslint-config-airbnb": "^15.1.0",
    "eslint-plugin-babel": "^4.1.2",
    "eslint-plugin-import": "^2.7.0",
    "eslint-plugin-jsx-a11y": "^6.0.2",
    "eslint-plugin-react": "^7.3.0",
    "react-test-renderer": "16.0.0-alpha.6",
    "reactotron-react-native": "^1.11.1",
    "reactotron-redux": "^1.11.2",
    "rn-nodeify": "mvayngrib/rn-nodeify",
    "rnpm-plugin-windows": "^0.2.7"
  },
  "scripts": {
    "start": "react-native start",
    "android": "react-native run-android",
    "ios": "react-native run-ios",
    "macos": "react-native-macos run-macos",
    "test": "node node_modules/jest/bin/jest.js --watch",
    "postinstall": "./node_modules/.bin/rn-nodeify --install crypto,stream,vm --hack",
    "lint": "node_modules/eslint/bin/eslint.js src/",
    "lint-fix": "node_modules/eslint/bin/eslint.js src/ --fix"
  },
  "jest": {
    "preset": "react-native",
    "setupFiles": [
      "./setupJest.js"
    ],
    "transformIgnorePatterns": [
      "node_modules/(?!react-native)/"
    ]
  },
  "dependencies": {
    "assert": "^1.4.1",
    "babel-jest": "^20.0.3",
    "babel-preset-env": "^1.6.0",
    "babel-preset-es2015": "^6.24.1",
    "babel-preset-react-native-stage-0": "^1.0.1",
    "base-64": "^0.1.0",
    "browserify-sign": "^4.0.4",
    "csv-string": "^2.3.2",
    "events": "^1.1.1",
    "fuzzy": "^0.1.3",
    "immutability-helper": "^2.3.0",
    "immutable": "3.7.6",
    "jest": "^20.0.4",
    "path-browserify": "0.0.0",
    "process": "^0.11.10",
    "pwgenjs": "^0.0.1",
    "react": "16.0.0-alpha.6",
    "react-immutable-proptypes": "^2.1.0",
    "react-native": "^0.44.0",
    "react-native-crypto": "^2.0.2",
    "react-native-document-picker": "^2.1.0",
    "react-native-fabric": "^0.5.0",
    "react-native-file-provider": "^1.0.2",
    "react-native-fs": "^2.8.0",
    "react-native-keyboard-aware-scroll-view": "^0.2.9",
    "react-native-keychain": "^1.2.0",
    "react-native-macos": "^0.16.0",
    "react-native-randombytes": "GrokInteractive/react-native-randombytes",
    "react-native-router-flux": "^3.38.0",
    "react-native-sensitive-info": "^5.2.0",
    "react-native-timer": "^1.3.1",
    "react-native-vector-icons": "^4.2.0",
    "react-native-windows": "0.44.0-rc.3",
    "react-redux": "^5.0.5",
    "readable-stream": "^1.0.33",
    "redux": "^3.6.0",
    "redux-persist": "^4.8.2",
    "redux-persist-transform-immutable": "^4.3.0",
    "stream-browserify": "^1.0.0",
    "timers-browserify": "^1.4.2",
    "tty-browserify": "0.0.0",
    "url": "^0.10.3",
    "util": "^0.10.3",
    "uuid-js": "^0.7.5",
    "vm-browserify": "0.0.4"
  },
  "react-native": {
    "crypto": "react-native-crypto",
    "path": "path-browserify",
    "_stream_transform": "readable-stream/transform",
    "_stream_readable": "readable-stream/readable",
    "_stream_writable": "readable-stream/writable",
    "_stream_duplex": "readable-stream/duplex",
    "_stream_passthrough": "readable-stream/passthrough",
    "stream": "stream-browserify",
    "timers": "timers-browserify",
    "tty": "tty-browserify",
    "vm": "vm-browserify"
  },
  "browser": {
    "crypto": "react-native-crypto",
    "path": "path-browserify",
    "_stream_transform": "readable-stream/transform",
    "_stream_readable": "readable-stream/readable",
    "_stream_writable": "readable-stream/writable",
    "_stream_duplex": "readable-stream/duplex",
    "_stream_passthrough": "readable-stream/passthrough",
    "stream": "stream-browserify",
    "timers": "timers-browserify",
    "tty": "tty-browserify",
    "vm": "vm-browserify"
  }
}

I'v redacted a few things from the list, but most of the relevant things are in there.

See this project I just forked to demonstrate cross-platform capability https://github.com/ptmt/react-native-nw-react-calculator I just tried and packager correctly resolves react-native as react-native-macos. If you could add something to stop it working that would be helpful to understand the reason behind this. Try to use other babel plugins or aliases just to ensure that babel respect this config section.

Even changing it to directly use react-native-macos now gives me this error:
error: bundling: UnableToResolveError: Unable to resolve module PickerAndroid from ....../node_modules/react-native/Libraries/Components/Picker/Picker.js

The above error also occurs using react-native-macos run-macos on the nw calculator, though I see it is made to be served through nw and electron. But maybe that's a clue as to what's causing it?

it seems that eighter babel resolver or rn-cli.config.js that I added there doesn't work. So you pulled https://github.com/ptmt/react-native-nw-react-calculator this, made yarn install, then try to do react-native-macos start --reset-cache

I don't think it's Babel because that is just for aliasing (right?), I went into the app file and changed it to explicitly look in react-native-macos so that should be where it looks.
I didn't try it with yarn, i just did npm install and then attempted to run it. Doing it exactly as you just specified worked.

Now trying with a fresh project...

It... it worked.
yarn install to get your packages works, npm install doesn't. That's an interesting tidbit.

Okay, so to answer this thread!

Have a regular react project, we call it #1
react-native-macos init to get your macos project, we call it #2
Copy macos folder from #2 to #1
Also place rn-cli.config.js inside #1
Copy hidden files from #2 to #1 and overwrite. Probably only need babelrc
Edit #1's package.json to  include the dependencies and devdependencies of #2 that are not present there
YARN install
react-native-macos run-macos

I want to point out by the way that create-react-native-app uses App.js and you need to go modify the xcode project to look for 'App' where it looks for index.macos

This approach led to some problems when i then tried to run ios. I'll try again tomorrow I suppose.

I don't think it's Babel because that is just for aliasing (right?), I went into the app file and changed it to explicitly look in react-native-macos so that should be where it looks.

Actually, react-native-macos uses react-native inside it, so it's relying on this babel aliasing.
Thanks for detailing description. Any chance that I can have a look at the project itself?

Where are we with that! I would Loooooveeee to see my react-native have three target. macos, ios, and android. And have three separate npm script so i can start all three target and hot reload all three at the same time. Never been able to do so yet.
I am capable of starting one or another, depending of (not quite sure yet) .babelrc and, the presence or "not" of rn-cli-.config.js.
If both are there, i can run macos, but not ios. If i dont have rn-cli.config.js, AND, remove babelrc module resolver plugins, then i can run ios, but not macos.
There is definitely something feasible here, but i can't put my hand on it.

Any one can give me a full procedure for make react-native-macos in react-native running iOS/android project
_https://github.com/ptmt/react-native-macos
https://github.com/ptmt/react-native-macos/issues/164#issuecomment-339545000
https://github.com/ptmt/react-native-macos/issues/164#issuecomment-345874097_
I try all above solution but it not work


Rate limiting API routes doesn't work or is very inconsistent

Version
nuxt-security: v1.0.0-rc.3
nuxt: v3.8.0
Reproduction Link
https://stackblitz.com/edit/nuxt-starter-lytnxe?file=app.vue
Steps to reproduce
I have a routeRule set up to try to rate limit an API endpoint. It looks like the following in nuxt.config.ts:
'/api/test/**': {
      security: {
        rateLimiter: {
          tokensPerInterval: 3,
          interval: 86400000
        }
      }
    }

Unfortunately it's just very inconsistent. If I start up the server and hit the endpoint directly, and refresh it more than 3 times, it will correctly throw a 429. But if I'm navigating around the site, where the pages are calling the same API via $fetch, it won't trigger. Additionally, after navigating around the site, going back to the endpoint and refreshing more than 3 times will no longer throw the 429 any more.
For my own scenario, I'm not even sure if rate limiting the API is a good idea (i.e., I have a cloud function which does the server-side rendering calling the same API; I would not want that one to be rate limited). But I expected it to be rate limited with that configuration.
I also may be misunderstanding the routeRule itself. I thought '/api/test/**' rate limiting would count the number of requests to any endpoint that started with /api/test, but maybe it only rate limits each unique endpoint that starts with? For example, would /api/test/A and /api/test/B each get 3 requests per day, or would they get 3 requests combined per day? Either way, it doesn't appear to work right.
What is Expected?
I'm expecting it to correctly and consistently rate limit the API route - whether I'm loading it directly or loading it from a page.
What is actually happening?
It doesn't consistently rate limit.

Hey @georgesaliba
Thanks for this issue. This new rate limiter was actually introduced as a part of RC1 version.
I am looking for all possible feedback regarding it so your issue and comment is more than welcome!
You have done a great work analysing what could be improved. Maybe you already have an idea how it could be fixed?
If you like, feel free to create a PR with proposed change. I will be more than happy to help you with it so that we can make it better together :)

Any more info @georgesaliba ?

Hi @Baroshem ! I actually have been trying to move from client-side API calls to server-side API calls using server components, as to not expose these APIs at all rather than trying to rate limit them. Unfortunately, the rateLimiter middleware seems to actually be limiting the calls being made from server components, so I've largely been disabling rate limiting for my use case as a workaround.

Hey @georgesaliba
Maybe a better option would be to increase the amount of tokensPerInterval rather than disabling it?

Yes and no for my use case.
I'll use an example which isn't my use case but demonstrates it well enough. Imagine I have a website that hosts recipes. Each recipe is just a list of ingredients, and there are many recipes in the database - all of them public. So I have one paginated summary API that gives me a list of recipes, and a details API that gives me the ingredients in any one recipe.
Now I don't want bots to just scrap my database for all the recipes, and all the subsequent ingredients in each recipe. So I put rate limits on the recipe details page (the one that lists ingredients) that was reasonable for a real human (e.g., let's say most people don't view more than 100 recipes a day), and that worked. However, the bots were still hitting the recipe details API, and able to continue to scrape all the recipes from the database. So I tried to put a rate limit on that API, but it didn't work (hence why I opened this issue).
In my case, however, I don't even really want to even expose that the recipes details API to the public. I would rather it only be exposed to my own server as an API, and always presented to my users as HTML listing the ingredients on details page (where the limit works). However, to do this, I need to use Nuxt server components. I didn't realize, however, that these seemingly server components were going through the same nuxt-security middleware (presumably it calls the API server-to-server, stores the HTML, then is making an async call just to fetch that HTML down to the client). I had built the server components as each line item in the recipe, so even viewing a few recipes quickly blew through the rateLimit (e.g., a recipe with 100 ingredients was making 100 calls on page load).
So I can disable the rate limit on the server components folder (/_nuxt_island/** I believe), but it's likely better if I make it so the entire recipe is a single server component instead. So that's my next step, at which point I'll look at getting rid of the rate limit bypass on the server components folder. But in this scenario, I'm not really worried about the API rate limiting not working anymore.

I see. Is there anything we can do from the module side to help you?

Following up on this, I'm seeing a slightly different (but maybe related?) issue, but it's confusing me.
So I've removed all my API route-specific rate limiting, so it should just be using the default rate limits. What I'm seeing is when I hit a Nuxt page route directly, I'm getting a 429 response from the API, even though I've only hit the page once. But if I navigate to that same Nuxt page from another page, it works fine.
I'm pretty sure what's happening is the server-side call from my Nuxt page to the Nuxt server API is getting rate limited even though it's an internal call, while the call that happens when I navigate to the page is happening from the client-side, meaning it's mapping to the customer's IP and rate limiting per user correctly.
Is there any way to exclude internal API traffic from the rate limits, while keeping the rate limits on the same API when being called from the client-side?

Hey, I think it could be a bug on the implementation side.
Would you be up for contributing and fixing this issue? :)

@georgesaliba are you open for creating a Pull Request with a fix for that? :)

Hi @Baroshem
I'm happy to try tackling this one.
However would love to get your input first on independent vs cumulative limits first, as we were discussing in: https://github.com/Baroshem/nuxt-security/issues/292#issuecomment-1822461922
I don't know how other rate limiters approach this question, also happy to look at reference implementations. If there is a standard rateLimiter package that you like, let me know

Hey @vejja
Yes please. If you have time, feel free to take a look at this case.
Regarding
Say you have a limit of 10 requests/sec at the global level, but /route1 has a limit of 5 req/s. What happens if you hit index 5 times, can you still hit /route1 ? In other words, are the limits cumulative or independent ?

I would say that in general rate limiters are supposed to help avoid attacks such as DOS and DDOS. And in case of this attacks, you are keen on blocking whole user (device) from accessing your website no matter what endpoint this bot is trying to access.
So IMO, if a user or device manages to reach a limit of any routes it should be blocked from accessing the whole website. That is why, by default rate limiter has a limit of 150 requests per minute.
Regarding the examples, here are some useful tools that do the same:

https://www.npmjs.com/package/express-rate-limit
https://github.com/timb-103/nuxt-rate-limit (I based the new rate limiter on this one)
https://blog.logrocket.com/rate-limiting-node-js/

Hey guys, was out on holiday, but following up. I tried to take a look at the rate limiter code, but it looked fine - at least as far as I could understand it.
I have a feeling that the root cause is that the rate limiter is looking at "x-forwarded-for", but that's not what Google uses when Nuxt is hosted on Google Firebase (executed in a Google Cloud Function behind the scenes). Apparently Firebase is behind the Fastly CDN, so the originating IP address is stored in "fastly-client-ip" instead (per this). I suspect that could apply to any server behind Fastly CDN, though not sure. I've also found some conflicting info about exactly which string this info is stored, apparaently based on the specific technology solution, so probably makes the most sense to have that lookup string be a configurable array for strings, where they get tried in some order if the previous was wasn't found.
As a result, the IP-based rate limiting is just limiting the sum of all traffic from any user on the site when going through the Cloud Function, not rate limiting specific users. As the user population grows, there can be 429s on any call for any user, which basically breaks functionality at random throughout the site.

unjs/h3 now have getRequestIP since v1.8 and getRequestFingerprint since v1.9
Not sure if this addresses your concerns but worth checking
BTW in the GitHub discussion they mention this module as an example of why they think it is preferrable to use getRequestIP: https://github.com/unjs/h3/pull/503

As an aside, after digging through the logs a bit, it ends up the client IP address isn't in either "x-forwarded-for" nor "fastly-client-ip", but instead in "cf-connecting-ip". In my case, Cloudflare is fronting Firebase, which sits behind Fastly. So Cloudflare's header is the only accurate source of the client IP (fastly-client-ip only contains the Cloudflare IP, and x-forwarded-for contains only the Cloudflare IP and Google's IP, not client IP).
I'm not sure if a better option here is to make the header where the IP address is pulled from configurable, or if my use case is unique enough I should be rolling my own rate limiter.

@georgesaliba
Any feedback from you? :)

Hey @Baroshem ! Given the complexity and very specific requirements I had, I ended up creating my own rate limiter, which worked for my use case. But then I quickly decided to scrap the whole idea of rate limiting at the middleware, and replaced it with Cloudflare rate limiting (basically what is actually called out as a recommendation in the Nuxt Security docs).

Hey @georgesaliba
Yes, I think this is the right way to go in the production applications as solutions on the application level are already too late to handle rate limiting so the built it rate limiting is aimed at simpler web apps.
Do you think we could close the issue?


Show all tabs by default

As per the UI/UX review. I have removed the show/hide for this and kept "Browse undetected issues:" as a label instead.

For Doctor, Hide/Show tabs in full screen recommendations view is unnecessary when there is enough visible space. Make reactive.

It looks like this breaks the warning icon on the tab of the issue that was identified:

One thing that was IMO nice about the old style was that the detected issue tab was on the left, and undetected issues were on the right, so there was some more separation between them. Maybe the warning icon would be enough. What do you think?
We also don't need the "Browse undetected issues" button any more if we're already showing them all the time :)

Aaaand possibly we shouldn't show the 'no issue' tab if an issue was found. That one doesn't have any useful information in that case. All the other tabs do.

t looks like this breaks the warning icon on the tab of the issue that was identified
Oh dear. I'll have a look into that.

We also don't need the "Browse undetected issues" button any more if we're already showing them all the time :)

This is no longer a button. Just a label in a different colour to distinguish from the other items. Maybe I should just rename to "Undetetcted Issues".

oh yeah. on your screenshot it actually shows up a differently than for me, I think having an "undetected issues" label makes sense then!
This is what I see in both Firefox and Chrome:

@goto-bus-stop - I have gotten it to show up the same way now. I'll be looking into this again today.

@goto-bus-stop - This is ready for review again. :+1:

Hmm I still get the same display with that change:

I think what we want is something more like this:

@goto-bus-stop - I actually get the second image as the result when I run it. What resolution is your screen? I'm assuming its something to do with screen res.

It looks the same to me on both 1920×1080 and 4K. Do you maybe have more local commits that weren't included in the PR yet? :thinking:

@goto-bus-stop - After some detective work I found the missing code. :+1:

@goto-bus-stop - Alright. That can be a separate PR.


Can't get focusInfo in serchField correctly

OpenUI5 version: all
Browser/version (+device/version):
Google Chrome: Version 125.0.6422.113 (Official Build) (x86_64)
Any other tested browsers/devices(OK/FAIL):
URL (minimal example if possible):
https://sapui5.hana.ondemand.com/#/entity/sap.m.SearchField/sample/sap.m.sample.SearchFieldSuggestions/code
User/password (if required and possible - do not post any confidential information here):
Steps to reproduce the problem:

open code editor, add "console.log(this.byId("searchField").getFocusInfo());" in onsuggest function
focus on searchField, select an Item in suggestion lists
blur and refocus on searchField, the focusInfo is not correct

What is the expected result?
No mater where I focus in searchField, the cursor position should be right.
What happens instead?
Most of the time, it returns an error cursor position
Any other information? (attach screenshot if possible)

Hi,
In your case you can get the correct cursor position with the following code:
function onSuggest(event) {
		setTimeout(function () {
			console.error(event.oSource.getFocusInfo());
		}, 0);
	}

Best,
Teo


Evaluate Kawaze filtering for blur

https://community.arm.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-20-66/siggraph2015_2D00_mmg_2D00_marius_2D00_notes.pdf

Move to future roadmap


How do you make navbar Black and bar button ite

I trying to change navbar to black and bar button items to white. Can you guide in right approach

Use black navigation bar style on Storyboard (set it on Navigation Controller).


Fix example given for invalid add command

When using the add command incorrectly, an example is shown to the user.

However, the example itself will return an error message as well as there is a requirement for the Telegram handle to be 5 to 32 characters long:

Action required: correct the example given.

Fixed in #50


Change AVAudioSession defaults to iOS defaults

Currently, the default category is AVAudioSessionCategoryPlayAndRecord which will automatically turn-on the microphone even for listen/view-only cases.
Instead of forcing developer to use playAndRecord, developer should be responsible to set the relevant category, which will result mic to turn on if playAndRecord or record is used. (PR https://github.com/webrtc-sdk/webrtc/pull/5)
This PR sets the defaults to iOS defaults.
https://developer.apple.com/documentation/avfaudio/avaudiosession/capturing_stereo_audio_from_built-in_microphones

this looks good to me. question is how does this work for existing flutter-webrtc users? LiveKit iOS SDK already handles management of the audio session.
feels like flutter-webrtc should add this management layer before upgrading to this build. here's the logic that we use to init audio session when the first audio track is received. and here is when it's published
@cloudwebrtc, do you want to add this to flutter-webrtc first?

@davidzhao Thanks for pointing this out, this is my concern also.

hey, @davidzhao @hiroshihorie I think we need to find whether there is a localStream (including audio track) in the flutter-webrtc plugin to switch category, when there is no loalstream created, there is no need to use playAndRecord

These operations can be done internally by flutter-webrtc native, and users have no perception.

Yes! I agree this could be done transparently by flutter-webrtc.
I think only two actions are needed:

when user creates a local audio track, set audio session to playAndRecord
when a onTrack event is triggered, and it's an audio track, set audio session to play (if it's currently ambient)

@cloudwebrtc @davidzhao Yes I agree it should be handled internally, but there should be an option for this to be off. So if the developer is managing the audio session themself it will cause conflict.

if we only set audiosession if it's set to ambient, then it should be ok right?
if dev set it to something else, we would not override.
similarly with playAndRecord, we would only set it if it wasn't set

Should be ok most of the time but I'm still thinking if it's ok for the uncommon cases.
Some categoryOptions  and modes don't work with different categories, and switching category transparently might reset these settings.
I think it still might be safe to have an option to turn off this auto-management of audio session, since it's hard to understand 100% of developer's intention.
soloAmbient does not support background playback so it is possible that developer would like to change this to playback https://developer.apple.com/documentation/avfaudio/avaudiosession/category/1616509-playback
Could be almost fully managed :
No LOCAL AUDIO: Set one of playback (dev may want soloAmbient, ambient for some reason)
Has LOCAL AUDIO track: Set record
Has LOCAL AUDIO track and REMOTE AUDIO track: SetplayAndRecord
Problem 1: How to know user's preferred playback mode (playback, soloAmbient, ambient)
Possible solution: Store the initial playback category and set it back to that.
Problem 2: How should we handle categoryOptions  and modes ?
I'm not sure about multiRoute category. 😅

Some categoryOptions and modes don't work with different categories, and switching category transparently might reset these settings.

You are right that it's possible they might want ambient. I think it's ok for users to actually tell us those use cases.. and we can add a toggle then to disable this? Just trying to avoid over-engineering this for the initial version. So proposal is:

set to playback (with appropriate mode) if current category is ambient AND a remote audio track is received
set to playAndRecord (with appropriate mode) if current category is not playAndRecord AND a local track is created.

wdyt?

@davidzhao Sounds good! won't hurt to have an option to turn this off tho!


[Tensor] Column-major in operations with strided inputs and output

This PR includes implementation of operations with strided inputs and output to support column-major.
Self-evaluation:

Build test: [X]Passed [ ]Failed [ ]Skipped
Run test:   [X]Passed [ ]Failed [ ]Skipped

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #2398. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

This will reopen once when we understand column-wise ordering more clearly.


Add Zebra crate versions to dev-dependencies, to enable crater tests

Motivation
If we add versions to all of Zebra's dev-dependencies, our crates will get tested by Rust compiler team crater runs.
This helps prevent build and test failures caused by future Rust compiler versions.
Specifications
https://rustc-dev-guide.rust-lang.org/tests/crater.html
Also possibly the restrictions here, if they are still current:
https://www.reddit.com/r/rust/comments/f5xpib/psa_denywarnings_is_actively_harmful/
And we might need optional feature dependencies:
feature_name = ["optional_dep?/feature_if_dep_activated_by_another_feature"]

Changes

[ ] Add crate versions to all dev-dependencies on Zebra crates

[ ] Remove the tower-batch-control -> zebra-consensus circular dependency by copying those verifiers into tower-batch-control (and copying the tests into zebra-consensus so we're also testing the latest verifier code)

[ ] Make sure the tests that are on by default:

run reasonably fast
don't use too much network
(check crater docs for any other requirements)

Testing
This needs testing using cargo release, to make sure there aren't any other circular dependencies.
Related Work
Split off PR #6908 and ticket #6149.

Hey team! Please add your planning poker estimate with Zenhub @arya2 @conradoplg @dconnolly @oxarbitrage @teor2345 @upbqdn

Hey, I would like to take on that.
I started checking and I think we could at this point just specify version = "1" for most relevant crates in dev-dependencies. Can you see any downside of this approach? I think it would a bit lower the maintenance burden

Hey, I would like to take on that. I started checking and I think we could at this point just specify version = "1" for most relevant crates in dev-dependencies. Can you see any downside of this approach? I think it would a bit lower the maintenance burden

It gave me a build error when I tried this, prerelease package needs to be specified explicitly, but I don't see any downside here if it works. The maintenance burden should be relatively trivial if it needs to be a specific version.

indeed it doesn't work for pre-release packages, tho it should work after 1.0.0. Anyway, I'll go with setting specific versions for now

can you assign this to me please for easier searching?

Also fyi since #8136 publishing will be blocked by https://github.com/zcash/librustzcash/pull/1083 https://github.com/zcash/librustzcash/pull/1088


duplicates/clones should includes attributes like style

This is a (multiple allowed):

[] bug

[x] enhancement

[ ] feature-discussion (RFC)

Swiper Version: 3.4.2

Platform/Target and Browser Versions: all

What you did

Expected Behavior
duplicates/clones should also include attributes like "style"
Actual Behavior
duplicates/clones doesn't include attributes like "style"

Duplicated slides are done via DOM cloning so the include everything. Make sure you add your custom styles BEFORE you init swiper with loop


Rely on devs' local versions

This means that it will always use the local version of the remix package which is needed to sync up things like the main router.
Also adds a bun.lock file for bun installations (fun time to realise its disgustingly fast!)

I'm not 100% sure on the difference between peer dependencies and regular dependencies. So I'm not sure about the exact implications of this.  I eventually want to make this useable without remix and without yup, but I think the best way to do this is to split it up into separate packages. So we'd have @signal-form/remix as the remix package. We need to set up a monorepo structure for this though.


Adds filtering by namespace and organization labels.

Summary
Adds filtering by namespace and organization labels.
Fixes #35
Checklist

[X] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog
[X] Update tests.
[X] Link this PR to related issues.

@glrf I updated it. It makes complete sense what you said 👍


AMS SDK

How this works

We use latest version of AMS file
We apply patch to the AMS spec with tags (rhoas is current name - not great :) )
We generate content but filter out default API - we can still keep it as it would not be used in UI and other clients etc.

FYI @pmuir @riccardo-forina this works well as package and reduces  UI bundle size by ~460kb.
Release details
npm notice name:          @rhoas/account-management-sdk
npm notice version:       0.0.1-dev
npm notice package size:  53.3 kB

There is still some inefficiency due to number of typescript files not being used in the final compilation but still being commited. I think that this is ok as long overall bundle size works.
I haven't documented or added examples to API as I think we do not want people to use it.

UI PR: https://github.com/redhat-developer/app-services-ui/pull/296

Do RHOAS clients use all of the endpoints you have tagged?

Yes. Although this is only for UI. I will do the same for golang and see if we have overlap (so far I see there is 100% overlap for those)


Add timeout for recover and event monitor

This is another attempt of https://github.com/containerd/cri/pull/884.

Add timeout to both recovery logic and event monitor.
Generate Unknown state if fail to load container/sandbox status.

Update containerd to include ttrpc context cancellation support https://github.com/containerd/ttrpc/pull/29.
I've experimented, the context can now successfully stop pending calls to containerd-shim.
There is some wait group inside containerd, which could still block forever though, e.g. https://github.com/containerd/cri/blob/master/pkg/server/io/helpers.go#L63, which we should try to fix in the future.
This is still much better than before. We should cherry-pick this to v1.2.

/test pull-cri-containerd-verify

/test pull-cri-containerd-verify

Based on https://github.com/kubernetes/kubernetes/issues/69060, kubelet will start new container although there is one in unknown state.
So it is not very useful to handle load failure containers as unknown. Given so, I prefer doing that in another PR, and not cherrypick it. In this PR I'll just simply add timeout.


Country prefix +49 for hotline is misleading(EXPOSUREAPP-4677)

1- Remove +49 from hotline numbers
2- Adjust Instruction text about it. (DE, EN, Default) Strings

Please, kindly check submission_contact_step_1_content in strings that is used in include_submission_contact.xml in content description.

Please, kindly check submission_contact_step_1_content in strings that is used in include_submission_contact.xml in content description.

Please, kindly check submission_contact_step_1_content in strings that is used in include_submission_contact.xml in content description.

Thx, I have adjusted it, Please let me know if it is Ok

Please, kindly check submission_contact_step_1_content in strings that is used in include_submission_contact.xml in content description.

Thx, I have adjusted it, Please let me know if it is Ok

Link back to https://github.com/corona-warn-app/cwa-documentation/issues/501.


Improve semantic tokens caching algorithm

Summary of the changes

Razor recently switched over to using pure range handling for semantic tokens via https://github.com/dotnet/razor-tooling/pull/5949. Unfortunately, while this switch improved overall perf, it introduced scrolling lag which is especially apparent in larger files.
This PR addresses scrolling lag in certain scenarios. Namely, if a user has scrolled somewhere they previously scrolled before and has not modified the file, we will attempt to quickly provide them with tokens from the cache. We are significantly smarter about providing cached tokens; for example, while we will first attempt to find an exact range match in the cache, we will also look for partial matches. If we find a partial match, this may allow us to compute a reduced range and therefore lower the amount of overall work we have to do.
From testing manually, this did seem to ultimately improve the scrolling experience once C# finalized their tokens (since we don't begin caching until tokens are finalized).
Writing actual tests for this scenario is difficult, especially with the current Mock infrastructure, which does make this a risky change. https://github.com/dotnet/razor-tooling/issues/5948 is already filed to track this, but this may affect what release we want to take this fix in.
Next steps here to further improve perf would be to (1) work with Platform to get a "nothing has changed" range response implemented (tracked via this internal issue) and (2) possibly have Platform address https://github.com/dotnet/razor-tooling/issues/5973. I've briefly chatted with Christian about the latter issue and it seems like it may be a difficult issue to resolve, so it likely warrants further discussion.

Partially fixes https://github.com/dotnet/razor-tooling/issues/5974
Fixes https://github.com/dotnet/razor-tooling/issues/5971

From testing manually, this did seem to ultimately improve the scrolling experience once C# finalized their tokens (since we don't begin caching until tokens are finalized).

Can you clarify this?  what do you mean "finalized their tokens"?

I have a few concerns about the approach here:

The editor only requests classifications for content that it has been notified has changed. If classifications are requested after scrolling, one of the following has occurred:

The location after scrolling has not previously been displayed
The editor has been notified that classifications have changed for the specific span visible after scrolling

For both of these cases, caching is not especially helpful.

Roslyn has already implemented a hardened asynchronous tagger API that handles its own caching and update notification strategy (AbstractAsynchronousTaggerProvider<TTag>). Why are we not leveraging that logic?

Hoping to get to this this morning

Also, the lack of tests here is a complete block for me.  I'm ok with the general high level approach being taken here.  but we absolutely need a wealth of tests for a lot of itneresting cases.
I'd also recommend some multithreaded tests that run like a thousand times with a couple of threads reading/writing to the cache simultaneously.

Benchmarks:
This PR

Method
Mean
Error
StdDev
Op/s
Gen 0
Gen 1
Gen 2
Allocated

'Razor Semantic Tokens Range Scrolling'
1.509 ms
0.0107 ms
0.0100 ms
662.6
29.2969
13.6719
-
184 KB

'Razor Semantic Tokens Range Scrolling'
1.524 ms
0.0268 ms
0.0287 ms
656.0
29.2969
13.6719
-
184 KB

'Razor Semantic Tokens Range Scrolling'
1.522 ms
0.0132 ms
0.0123 ms
657.0
29.2969
13.6719
-
184 KB

Old Cache

Method
Mean
Error
StdDev
Op/s
Gen 0
Gen 1
Gen 2
Allocated

'Razor Semantic Tokens Range Scrolling'
1.507 ms
0.0268 ms
0.0251 ms
663.8
27.3438
13.6719
-
178 KB

'Razor Semantic Tokens Range Scrolling'
1.515 ms
0.0079 ms
0.0074 ms
660.1
27.3438
13.6719
-
178 KB

'Razor Semantic Tokens Range Scrolling'
1.480 ms
0.0149 ms
0.0139 ms
675.8
27.3438
13.6719
-
178 KB

This is a sort of "worst case" test, where we've got a small "window" we're looking at as we scroll (so lots of requests), we never scroll back up (so we can actually use the cache we paid all that CPU/memory to create) and the document is reasonably large (380 LOC). My reading of this is that CPU-wise there's only a marginal difference, easily within the realm of "something else was happening on my computer". The allocations are slightly higher with the new code, but again the difference is very small.
My take from these benchmarks and my experience using the actual product is that this won't make much of a difference WRT perceived or real performance, but the several bugs that seem to have been fixed along the way make it worth taking on those merits alone.

My take from these benchmarks and my experience using the actual product is that this won't make much of a difference WRT perceived or real performance, but the several bugs that seem to have been fixed along the way make it worth taking on those merits alone.

Believe in yourself! Thanks for digging into the numbers Ryan!

Will work on additional tests in immediate follow-up PR


Spacing between cards increases on scrolling

The layout_height attribute of RelativeLayout containing the card was set to match_parent.
Changing it to wrap_content fixed the issue #
@ichimichi


Cannot find type [Microsoft.Open.AzureAD.Model.AppRole]

Is there anyway to use AzureAD module in this? Seems that the module is installed but can not be used properly
AzureAD needs to run in powershell.exe v2 and actions run it as pwsh.exe v.7
Caught the exception System.Management.Automation.PSArgumentException: Cannot find type [Microsoft.Open.AzureAD.Model.AppRole]: verify that the assembly containing this type is loaded.
at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)
https://docs.microsoft.com/en-us/answers/questions/903709/cloudshell.html

Can you share your workflow and error logs for better understanding?

Hi @gfrid,  this action is for Azure PowerShell. AzureAD is not included. You can refer to https://learn.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0 for details.

Hi @gfrid, I'll close this issue due to the reason in my last comment. Feel free to create a new one if you have more questions.


cURL initial view code error

Describe the bug/problem
When we start the app for first time, the default codegen language is cURL, and if we press the View Code button without typing anything in the url tab, then is shows an error.
Steps to Reproduce the bug/problem
Initially launching the app:

After pressing the View Code button:

Expected behavior
This should not show an error, instead it should show
curl --url ''
Device Info (The device where you encountered this issue):

OS: [MacOS]
Version: [Sonoma 14.3.1]

I have a query regarding the test cases.
test('GET 7', () {
      const expectedCode = r"""curl --url 'https://api.foss42.com'""";
      expect(curlCodeGen.getCode(requestModelGet7, "https"), expectedCode);
    });

/// GET request model with body
const requestModelGet7 = RequestModel(
  id: 'get7',
  url: 'https://api.foss42.com',
  method: HTTPVerb.get,
  requestBodyContentType: ContentType.text,
  requestBody:
      'This is a random text which should not be attached with a GET request',
);

What this test case is expecting that if I have a GET request, then anything written in the BODY should not be attached.
Quoting RFC 7231
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
Which means, that a GET request can have a body, it depends on how server is handling it.
Also referencing an article by elastic search, which uses get requests with body to return data.
Thoughts on this @animator @ashitaprasad  ?

@CH1NRU5T
Mozilla docs reads Requests using GET should only be used to request data (they shouldn't include data)
Also, many REST clients do not permit sending body with GET requests like dart http or python requests.
Do take a look at this article. It mentions how later version of RFC tightened the usage of content in GET.
elasticsearch is an exception (the doc you attached is very old) and not the norm. They started providing POST endpoints in later versions.

@animator Sure, the docs suggest one should not attach the body with a GET request.
But as a REST API Client, shouldn't Api Dash allow the users to send it anyway?
The user should be aware of the fact that sending a body with a GET request is not suggested.

This topic has been discussed earlier where we took the design decision to stick to the best practices.
It is also coupled by the fact that many libraries being used in the language specific generated codes do not allow attaching body in GET request.

Alright, Thank you for the clarification.

Another query regarding a test case!
test('GET 3', () {
      const expectedCode =
          r"""curl --url 'https://api.foss42.com/country/data?code=IND'""";
      expect(curlCodeGen.getCode(requestModelGet3, "https"), expectedCode);
    });

/// GET request model with override query params
const requestModelGet3 = RequestModel(
  id: 'get3',
  url: 'https://api.foss42.com/country/data?code=US',
  method: HTTPVerb.get,
  requestParams: [
    NameValueModel(name: 'code', value: 'IND'),
  ],
);

This test case is when you already have a request param in your URL, and you additionally add a param with the same key in the params list, then the one on the list should be presented in the final output on generated code.
I think that the one written in the params tab should be appended at the end of the cURL request.
It should look like this:
curl --url 'https://api.foss42.com/country/data?code=US&code=IND'

Issue is not just with cURL but also other codegens as reported in #183 #201

@animator should we add just a single global response for the all the codegens when the url is empty, it will not just only solve the problems for the current codegens, but for the upcoming unhandle codegens too ?

@PCoder23 I think we have those, kTemplateStart.
According to me, the main issue seems to be, that for every codegen we are calling the requestModelToHARJsonRequest() method, and from this method's response we are proceeding to generate the code.
I think we should not use the requestModelToHARJsonRequest() method because we already have the requestModel, so we should proceed with it, without converting it to JSON and all that procedure.
@animator thoughts on this?

The issue has been resolved in the main branch using a fallback URL in case one is missing.