Add a Web App Manifest validator

We should add a Web App Manifest validator.
For example: https://web.telegram.org/manifest.json is not valid because it does not have an array of icons.

Their icons section looks like this:
  "icons": {
    "16": "img/icons/icon16.png",
    "32": "img/icons/icon32.png",
    "60": "img/icons/icon60.png",
    "64": "img/icons/icon64.png",
    "90": "img/icons/icon90.png",
    "128": "img/icons/icon128.png"
  }

I think we're expecting something like the following:
  "icons": [{
    "src": "/icon/web_hi_res_512.png",
    "sizes": "512x512",
    "type": "image/png"
  }]

Is their approach valid? If it is we should support. Otherwise, we can test if icons is an Array before using it.

Seems valid:
https://developer.chrome.com/extensions/manifest/icons
I wonder if we have a good way to validate the manifest.json formatting.

We could probably use https://github.com/mounirlamouri/manifest-validator
(written by a Googler).
On Thu, Sep 15, 2016 at 11:06 AM, Julian Toledo<EMAIL_ADDRESS>wrote:

Seems valid:
https://developer.chrome.com/extensions/manifest/icons
I wonder if we have a good way to validate the manifest.json formatting.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleChrome/gulliver/issues/149#issuecomment-247288376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADILADIFloQz0UWqq8yNuqK_e1IKcwFks5qqRiagaJpZM4J9sE7
.

Seems like the telegram one is for the Chrome Web Store and not at Web App Manifest.
The icons need to be an array:
https://w3c.github.io/manifest/#icons-member
Let's try that one @ithinkihaveacat

Lighthouse has a manifest parser that we forked from the one from mlamouri and have slowly updated for more corner cases/correctness and added tests: https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/lib/manifest-parser.js
The format it spits out is a little confusing, because rather than log any errors to console, at every step into the parsed manifest object it gives the parsed value but also an error string (debugString). In practice you end up writing a lot of things like manifest.value.icons.value[0].value.src.value, but I can write a quick converter that would just spit out what the parsed value ends up being :)

as an example, for your bad icons example,
  {"icons": {
    "16": "img/icons/icon16.png",
    "32": "img/icons/icon32.png",
    "60": "img/icons/icon60.png",
    "64": "img/icons/icon64.png",
    "90": "img/icons/icon90.png",
    "128": "img/icons/icon128.png"
  }}

gives a parsed response of (cutting out other manifest fields):
{
    "icons": {
      "value": [],
      "debugString": "ERROR: 'icons' expected to be an array but is not."
    }
}

whereas the correct version
{
  "icons": [{
    "src": "/icon/web_hi_res_512.png",
    "sizes": "512x512",
    "type": "image/png"
  }]
}

gives (again, cutting out other fields) the much more verbose but useful:
{
  "icons": {
    "value": [{
      "value": {
        "src": {
          "value": "https://example.com/icon/web_hi_res_512.png"
        },
        "type": {
          "value": "image/png"
        },
        "density": {
          "value": 1
        },
        "sizes": {
          "value": [
            "512x512"
          ]
        }
      }
    }]
  }
}

(note that this assumes a manifest located at example.com)
And then we could add a simple utility function that would pare that back down to
{
  "icons": [{
    "src": "https://example.com/icon/web_hi_res_512.png",
    "type": "image/png",
    "density": 1,
    "sizes": [
      "512x512"
    ]
  }]
}

which is how the browser interprets that input manifest.

@brendankenny Thanks for the heads up! I'll have a look at this.

See https://github.com/GoogleChrome/gulliver/pull/165.


typing double quotes into SwiftKotlin app becomes curly quotes

I tried typing the following into SwiftKotlin app. As I type it, the editor converts the first double quotation mark into curly quotes. Then the line cannot be translated because there is a parsing error.
let s: String = "abc"

If I copy and paste the above into SwiftKotlin app, the translation to Kotlin happens successfully.

Thanks! Interesting that nobody reported this befor. I guess the most common usage scenario is either copya&paste or open file, not typing directly. I will check it out

Fixed with 5d1501293872493efcc075d58eabb8bea4c8ee71


Remove LogEvent SequenceID or change to 64 bit ?

Random thoughts after looking at #4139. And the overhead from synchronizing cpu-caches to atomically increment a counter that very few people uses, and unexpectedly can become negative after some days.
Lets say we have an application that handles 10.000 requests/sec. This application writes a single logevent for each request.
This means the application will write 36..000.000 logevents/hour. And 864.000.000 logevents/day.
Right now the SequenceID is an integer and can hold 2,147,483,647 events, before it becomes negative. So that is 3 days without restarts. Many applications often run 7 days without restarts.
Maybe the SequenceID-property should only increment when calling the propery-getter? (Skip on constructor)
Maybe https://github.com/NLog/NLog/wiki/SequenceId-layout-renderer should be replaced by https://github.com/NLog/NLog/wiki/Counter-layout-renderer ? (Merge into one)

Maybe the SequenceID-property should only increment when calling the propery-getter? (Skip on constructor)

Sounds good!

Sounds good for NLog 5!

Yes already implemented with #4247
But it only reduces the overhead. It doesn't really fix the issue with negative integer values

Ow yes indeed. Well I guess we can close this one. Long is also nice, but not sure if needed


Identity Example

Following this note: "Please note that the identity and key must be generated first using the security token on the back of the device."
Doing so with a python lib is easy, but is there a way to do this with CoAPnet?
If so, could you point me in the right direction to do so?
Thank you!

Hi,
I made this with a simple test Console App where I put all the required calls and noted the response afterwards.
You can surely do everything required with COAPnet.
You basically need to follow this instructions: https://github.com/home-assistant/core/issues/10252
Instead of using the coap-client application you can send the same requests with COAPnet.
Best regards
Christian

OK, so can you help me understand this, its literally this command the one I am having trouble to interpret:
coap-client -m post -u "Client_identity" -k "SECURITY_CODE" -e '{"9090":"IDENTITY"}' "coaps://IP_ADDRESS:5684/15011/9063"
It clearly is a POST type, but I am assuming this has to happen before this:
var connectOptions = new CoapClientConnectOptionsBuilder()
.WithHost(address)
.WithPort(5684)
.WithDtlsTransportLayer(o => o.WithPreSharedKey(myID, secretKey))
.Build();
await coapClient.ConnectAsync(connectOptions, CancellationToken.None);
so my problem here is how to put in the POST the address and the "Client_identity", I am clearly miss understanding something, so my POST command so far is like this:
var request = new CoapRequestBuilder()
.WithMethod(CoapRequestMethod.Post)
.WithPath("15011/9063")
.WithQuery(GatewayCode)
.WithPayload("{"9090":"" + Identity + ""}")
.Build();
var response = await theClient.RequestAsync(request, CancellationToken.None).ConfigureAwait(false);
What am I missing?
Thank you in advance!

Is it that obvious that is not even worth a try?

Hello @chkr1011 , I was wondering if you could give me some guidance here, I am still stuck with it.

Your code looks fine to me. I also used it to communicate with TRADFRI devices. My code is here: https://github.com/chkr1011/CoAPnet/blob/34339382f94008482b0fd5de3c1c1453744c3fa3/Source/CoAP.TestClient/Program.cs#L59

Right! I was locating the Query in the wrong place.
Thank you for your help!


Replace GL's x11 dependency by hand-written code

We don't need much from the x11 library. Maybe it's an overkill to hook it up, and we can get away with something that we just hack in?

Was this supposed to be closed by #3520?

https://github.com/gfx-rs/gfx/pull/3520/commits/84f98481dbb77c6ba63f3277562879c3255f8542 was a part of that PR, yes


Support mastodon mentions

@MaTeS72 thank you for taking time to contribute to FlutterTagger.
Can you include a description detailing what this PR covers?

Sorry for that, I opened it by mistake. Just tried something.

Alright cheers!


load only England English dataset from common voice english dataset

training_data = load_dataset("common_voice", "en",split='train[:250]+validation[:250]')
testing_data = load_dataset("common_voice", "en", split="test[:200]")
I'm trying to load only 8% of the English common voice data with accent == "England English." Can somebody assist me with this?
Typical Voice Accent Proportions:

24% United States English
8% England English
5% India and South Asia (India, Pakistan, Sri Lanka)
3% Australian English
3% Canadian English
2% Scottish English
1% Irish English
1% Southern African (South Africa, Zimbabwe, Namibia)
1% New Zealand English

Can we replicate this for Age as well?
Age proportions of the common voice:-

24% 19 - 29
14% 30 - 39
10% 40 - 49
6% < 19
4% 50 - 59
4% 60 - 69
1% 70 – 79

Hi @amanjaiswal777,
First note that the dataset you are trying to load is deprecated: it was the Common Voice dataset release as of Dec 2020.
Currently, Common Voice dataset releases are directly hosted on the Hub, under the Mozilla Foundation organization: https://huggingface.co/mozilla-foundation
For example, to get their latest Common Voice relase (8.0):

Go to the dataset page and request access permission (Mozilla Foundation requires this for people willing to use their datasets): https://huggingface.co/datasets/mozilla-foundation/common_voice_8_0
Looking at the dataset card, you can check that data instances have, among other fields, the ones you are interested in: "accent", "age",...
Then you can load their "en" language dataset as usual, besides passing your authentication token (more info on auth token here: https://huggingface.co/docs/hub/security)from datasets import load_dataset
ds_en = load_dataset("mozilla-foundation/common_voice_8_0", "en", use_auth_token=True)

Finally, you can filter only the data instances you are interested in (more info on filter here: https://huggingface.co/docs/datasets/process#select-and-filter):ds_england_en = ds_en.filter(lambda item: item["accent"] == "England English")

Feel free to reopen this issue if you need further assistance.

Hey @albertvillanova trying the same approach as you with the common_voice_16_1 dataset. What I'm trying to do is to filter the valencian accent in the catalan subset. Gave me this error and I have everything it asks for decoding mp3:


Bump version

Bump version to 3.0.1 to prepare for a future release.
Update NuGet API key to publish packages.

Codecov Report

Merging #145 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #145   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          16     16
  Lines        1126   1126
=====================================
  Hits         1126   1126

Continue to review full report at Codecov.

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


Add new Image type

Signed-off-by: GuoRentong<EMAIL_ADDRESS>#802

Codecov Report

Merging #803 (f23e360) into main (ce848e9) will increase coverage by 0.02%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##             main     #803      +/-   ##
==========================================
+ Coverage   70.76%   70.78%   +0.02%
==========================================
  Files         171      173       +2
  Lines        7774     7787      +13
  Branches     1276     1278       +2
==========================================
+ Hits         5501     5512      +11
- Misses       1893     1894       +1
- Partials      380      381       +1

Impacted Files
Coverage Δ

towhee/__init__.py
85.59% <66.66%> (+0.12%)
:arrow_up:

towhee/newtypes/image.py
80.00% <80.00%> (ø)

towhee/newtypes/__init__.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

/lgtm
/approve


Configure the CI to run the e2e tests on GCP

What does this PR do?

Configure the CI to run the e2e tests on GCP
Motivation

We're adding support for GCP in the e2e tests
Additional Notes

We have the same PR in test-infra: https://github.com/DataDog/test-infra-definitions/pull/1093
Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge

/merge


[http-cache-filter] limit cache read chunk size to buffer size

Commit Message: [http-cache-filter] limit cache read chunk size to buffer size
Additional Description: Before this change, the cache filter will request the entire body of a cache entry in a single request from its associated cache extension, and both existing cache extensions would try to simply fulfill the request. When a file is very large, this results in trying to load an entire very large file into memory, which typically leads to a crash.
This change makes the cache filter request only the amount of data that would fill the streaming buffer per chunk, which should make it more tolerant of very large cache entries. If there is no buffer limit, an arbitrary 64MB limit is imposed.
Risk Level: Very small; change is to a WIP filter and addresses an existing crash.
Testing: Added unit test, and tested as a patch in production, where it fixed the reproducible OOM that provoked this change.
Docs Changes: n/a
Release Notes: n/a (the API between filter and cache is unchanged, this change is within the promised behavior)
Platform Specific Features: n/a

/retest

/wait


Fixed "Esc" key close bug in the visualizer

Blockers

[ ] https://github.com/openwisp/openwisp-network-topology/pull/195

Fixes #185

Coverage: 99.328%. Remained the same when pulling f6cdbec503b489acd8269948a76749580c22318f on issue-185/esc-bug-in-visualizer into 4310967dd3ed89fa6ad12765e36afa882d42c8b5 on master.


Implement first methods for muon reconstruction and analysis

@pcumani and I were working on the muon reconstruction this week and implemented some first methods.
Implemented stuff

Reconstruction of ring parameters via gaussian likelihood fit with kundu chaudhuri formula as initial guess

Estimation of the psf via a gaussian likelihood fit

Estimation of the impact parameter via a binned χ²-Fit

Estimation of optical efficiency using all of the above and the theoretical light distribution as described in @AMWMitchell s ICRC proceeding

Some features for event selection

Some open questions we have:

How are units to be handled?
Do you have ideas for more tests?

Some first results:
We applied the methods to LST Mono muon monte carlo data.
The scripts we used are in http://github.com/maxnoe/cta-muons

Fits of two well reconstructed muons:

Distribution of the radius for selected muon events:

PSF (standard deviation of gaussian fit)

Impact Parameter vs. Ring Completeness:

Optical Efficiency

Very nice.  I won't yet merge this in yet however, since there are at least 2 other implementations of muon fitting underway and it would be nice to make sure everyone uses the same structure so that we can compare results.   @rdelosreyes  will coordinate that at the F2F meeting.

Hi, I was about to submit a pull request for the same piece of code this week :-), although yours is likely a little better tested than mine. Will you be at the meeting next week? Maybe we could talk about about the method and we may be able to merge in some of my code if it is helpful.

This will definitely be a break-out session at the workshop, so we can make sure all efforts are merged then! It's ok to have two implementations, but they should use the same API and have the same inputs/outputs.

It is great to have already all this work done. It will definitively be a really valuable input.
Karl is right, DATA together with CCF  have organized a break-out session for the implementation of the muon reconstruction during the incoming Pipelines F2F meeting in Paris. There, we will examine what has been already produced and what will be finally delivered to ctapipe. The algorithms to be implemented have been studied within the CCF group and I think the best is that its implementation is validated together with them.

From a brief email exchange with Max, Paolo Cumani plans to present this implementation at the meeting next week. At the meeting, much as Raquel says, we can test the work done so far, identify tasks, and work together on an implementation for ctapipe.

Hi, Just to confirm what @AMWMitchell said: unfortunately @MaxNoe will not be in Paris for the discussion, but I will and I can present it.

Hi Max,
During the Pipelines meeting in Paris it was set up and defined the basic structure of the muon calibration tasks as well as a ctapipe branch (muonmaster) to collect all the contributions.
Looking at your code I think your input will help very much to improve the current scheme of the muon calibration.
I ask you then for your contribution to the muonmaster branch.
I will add few comments to the different parts of your code that I think it will be very useful to include in the current muonmaster branch.
Thank you very much in advance for your help.

I will close this pull request now, update my code to the use the new classes and reopen it against the muonmaster.
However, I think the muonmaster should live as short as possible. We should merge to master as often as possible and as soon as we have a new function / component.


Fix null exception in input tokenizer

Fix access property of null
Evidence:

BTW: Thank you for the excellent work in this great lib.

Coverage remained the same at 100.0% when pulling 88f06a72193d25148303644eb5b045886ac88ef7 on rod-stuchi:tokenizer-null-input into 15e1188371e684e814e05a250bb1a1c75206f82b on zeroturnaround:master.


WFLY-10770 Disable HotRodPersistenceWebFailoverTestCase on Windows until CI issues are resolved.

https://issues.jboss.org/browse/WFLY-10770
@rhusar Is working on an actual CI fix, but in the meantime we can disable the test on Windows only.

I'll wait to close this until #11482 passes, but that PR can likely deprecate this one.

Superseded by https://github.com/wildfly/wildfly/pull/11482


Add didasca.org

@SteDidasca First stage of verification passed, official domain is didasca.org as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@SteDidasca Regrettably, this request has signs of fraud. I have to close it without merging.
Please apply for free educational license with an official document which proves that you are a student. You can do it using "OFFICIAL DOCUMENT" tab at https://www.jetbrains.com/shop/eform/students.


aes-gcm: improve performance with parallel algorithm

Change-Id: I5b476758cdd1997e14051954fb025e35f831f062
Signed-off-by: Jerry Yu<EMAIL_ADDRESS>

@gbtucker ，Please review

Looks good, scheduled for integration.

integrated


Nested Scenes with 2 successive hideNavBar Scenes causes all other Scenes  not to have Nav Bar

Version
Tell us which versions you are using:

react-native-router-flux v3.35
react-native v0.35

     <Router>
        <Scene key='drawer' component={NavigationDrawer} open={false}>
          <Scene key='drawerChildrenWrapper' navigationBarStyle={Styles.navBar} titleStyle={Styles.title} leftButtonIconStyle={Styles.leftButton} rightButtonTextStyle={Styles.rightButton}>
            <Scene initial key='splashScreen' component={SplashScreen} title='Components' hideNavBar='true' />
            <Scene key='mainLoginScreen' component={MainLoginScreen} title='Login' hideNavBar='true' />
            <Scene key='mainScreen' component={MainScreen} title='Home'/> <=== Nav bar no longer appears for all subsequent screens
... Other scenes
          </Scene>
        </Scene>
      </Router>

Expected behaviour
Nav Bar should appear after the initial Splash and Login Screens
Actual behaviour
Nav Bar never appears if I have 2 successive screens with hideNavBar='true'
Steps to reproduce

Implement the code as above
Nav Bar on 3rd screen (mainScreen) does not appear.
Remove hideNavBar = true from the Login Scene
Everything works as per normal

I have the same problem:
    <Scene
      key="productintro"
      component={ProductIntro}
      hideNavBar="true"
      initial
    />

    <Scene
      key="homegym"
      component={HomeGym}
      hideNavBar={false}
      title="Home Gym"
    />

Second one does not have a NavBar.

I made it work with:
Actions.homegym({hideNavBar: false})

@peterkruty, thanks - it kinda worked for me, but there were side effects.
I put the Actions.mainScreen({hideNavBar: false}) into my Button on the loginScreen - seems like this action is called automatically cause it automatically transitions straight to the mainScreen without me having to press anything (I am just doing UI work for now)
Also, there was a warning about setState(...): Cannot update during an existing State transition, which wasn't there before. There is no setState in my render() function for either screen. Could be from the Button component - not sure how it is implemented since I am using the one from 'react-native-elements'

+1 . currently settings {hideNavBar:false} causes navigation bar to disappear. also putting {hideNavBar:true} causes navigation bar to disappear. basically , the mention of the property hideNavBar causes navigation bar to disappear! using version<EMAIL_ADDRESS>

I just have all scenes with navbars set to false in the jsx and those without set to true. Sucks but that's how i have it and I've never had a problem. Don't know about passing as props. I wouldn't though. If you want to dynamically choose to show why not just clone the Scene and give it a different key, one with nav and one without?


Added Vocean to certified-connectors

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.

[X ] I attest that the connector doesn't exist on the Power Platform today. I've verified by checking the pull requests in GitHub and by searching for the connector on the platform or in the documentation.
[X ] I attest that the connector works and I verified by deploying and testing all the operations.
[X ] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[X ] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[X ] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[X ] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process:

[ ] I have named this PR after the pattern of "Connector Name (Independent Publisher)" ex: HubSpot Marketing (Independent Publisher)
[ ] Within this PR markdown file, I have pasted screenshots that show: 3 unique operations (actions/triggers) working within a Flow. This can be in one flow or part of multiple flows. For each one of those flows, I have pasted in screenshots of the Flow succeeding.
[ ] Within this PR markdown file, I have pasted in a screenshot from the Test operations section within the Custom Connector UI.
[ ] If the connector uses OAuth, I have provided detailed steps on how to create an app in the readme.md.

Hello @mialandin,
Thank you very much and congratulations on your new submission.
Please sign the CLA. We can’t start our review process without it. You can see the link for CLA above this message.
After it’s signed, our Certification Engineers will review your pull request within 1-2 weeks.
Please let us know if you have any questions.
Thank you very much again for working with us.

Hello @mialandin,
I hope you are doing well.
Congratulations, your pull request is approved and merged. Please submit the files to ISV Studio or update your submission using your latest commit ID, please allow us up to 1-2 weeks to review your submission, and our Engineers will notify you in the “Activity Control” area in ISV Studio. Please make sure that the icon meets all the requirements, that it’s size is 230x230, icon background is not white or transparent and it matches the iconBrandColor property in apiProperties.json file.
After making the submission in ISV Studio, please attach an intro.md file in the activity control section. This file is required and it's different from readme.md. You can find an example of intro.md file on this page at step 6.
Please Create an environment in the Preview region. You will use this environment later to test your connector after Microsoft is done with the functional verification for your connector.
We expect all tests to be completed within 1-2 weeks.
If your connector passes all tests, the deployment process begins, and it typically takes up to 3 to 4 weeks to deploy your connector to all of our regions.
Please let me know if you have any questions.
Thank you very much for working with us.


Clean up Go formatter suggestions

Merge in code format changes made by go fmt in the Go SDK codebase. Ignores two formatting changes in the syscallx package that are found in generated code.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @damccorm @riteshghorse @lostluck
No code change, just cleaning up some fmt changes that were dangling

That is a very good suggestion. Would be good to add to Actions along with giving the go vet run an actual consequence if there's output.

LGTM. @damccorm good suggestion.

Run Go PreCommit

Nit: Do add the go fmt changes to the generated code. It's likely just older code that never had it run on it initially, but having automated formatting applied to automatically generated code is a win.
As for the reasons why? Where to start?

It was only in December when we got rid of the old GoGradle plugin, which didn't have the best support for formatting checks. Invoking by Gradle wasn't clear.
Github actions are very new to the project.
It's not a huge priority when only 2 engineers were changing the code and were running go fmt (or their editors were) anyway.

Should we? Absolutely. Lets do it.

Oh yeah, the build tag convention changed a while back, so it's good go fmt corrects them for us.


fix: welcome tour ending on page refresh

Description
We want to still have the guided tour running when the current page is refreshed. Note that we don't restore at the initial screen where we show the start building cta. Also we don't restore all states like for e.g focused inputs, if the widget sidebar was open we don't reopen it on refresh etc. but the tour continues to be usable. We also go back a few steps in cases where we cannot resume with the latest step on refresh.
Code changes

To do this have moved the tour related store values to a separate reducer, which is then synced with session storage at every step.
Minor refactor to make reuse code for both localstorage and sessionstorage.
Refresh the page in cypress while running the tour test.

Fixes #10923
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Cypress
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/ok-to-test sha=ca9f077

/ok-to-test sha=c606b61

/ok-to-test sha=fd6c6ca

/ok-to-test sha=62d40d1

/ok-to-test sha=8567a37


APIv2: Return StatusCreated from volume creation

The swagdoc in register_volumes.go already correctly notes that a 201
should be returned upon success, so we only need to change the handler
to match the spec.

/approve

/lgtm


feat: bump spanner client to v1.53.1

Previous version includes a potential nil pointer
exception.
See issue and fix for more information.

Codecov Report

Merging #496 (780a205) into master (762bfd8) will decrease coverage by 1.94%.
Report is 189 commits behind head on master.
The diff coverage is 25.18%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@            Coverage Diff             @@
##           master     #496      +/-   ##
==========================================
- Coverage   44.66%   42.73%   -1.94%
==========================================
  Files          21       20       -1
  Lines        4267     4563     +296
==========================================
+ Hits         1906     1950      +44
- Misses       2249     2504     +255
+ Partials      112      109       -3

Files
Coverage Δ

internal/codegen/databasecodegen/common.go
100.00% <100.00%> (ø)

...nternal/codegen/databasecodegen/readtransaction.go
100.00% <100.00%> (ø)

spanddl/table.go
29.46% <0.00%> (ø)

internal/examples/freightdb/descriptor_gen.go
0.00% <0.00%> (ø)

internal/examples/musicdb/descriptor_gen.go
5.55% <0.00%> (-1.47%)
:arrow_down:

internal/examples/freightdb/database_gen.go
23.28% <41.37%> (+0.07%)
:arrow_up:

internal/examples/musicdb/database_gen.go
17.20% <6.29%> (-3.57%)
:arrow_down:


Write Part -1 Step - 16 & unit test

Implement Step16Controller and write all unit tests.  Verify the display name of the test conforms to the pattern of "Part X Step Y".  Follow the standardize naming, comments, etc. to be consistent.

Bugs found in analysis by tech. requirements analysis.  Re-opening for bug fixes since never correctly completed.

Updates to step logic should include the formatting changes Eric asked for:
See comments in the Step 16 section of this report:
MFG2-example-8Sept-ETS-Comments.docx


Implement load all user presets

Last feature to implement before release: load all user presets from listing file or folder.

general outline is there, but issues with getting them all to load reliably


PassThroughTrackTranscoder hangs with non-baseline profile video

Hangs on mMuxer.writeSampleData() on PassThroughTrackTranscoder when transcoing mp4 file encoded on iOS (AVAssetExportSession).
It might because of main profile video file, as Android only supports and assumes baseline profile (it always overwrites profile to baseline in cpp source code...).
(NOTE: iPhone <=4S exports baseline, iPhone >=5 exports main profile)
MediaMuxer.cpp line 179 says writeSampleData will block if buffer is starved.
Perhaps hangs on wait() at MediaAdapter line 120.
Further investigation on libstagefright is required to identify actual problem.

Reproduced with High Profile / Level 2.1


Include node id in dispatch graph

Description
To include the node id & executor label for each electron in the dispatch graph on the Web app GUI
Mandatory acceptance criteria
User is able to view the node id & executor label of the electron along with each electron in the dispatch graph

Optional
An option to show or hide the node id will help users.
An option to show or hide the exector label will help users
It will help to also show the node id & executor label as part of the electon side bar when an electron is selected
Implementation details

Electron's node ID points to the transport_graph_node_id in the electrons table.
Electron's dispatcher label is available in the dispatcher_name column starting from v11 of the database

Description
To include the node id of each electron in the dispatch graph on the Web app GUI
Mandatory acceptance criteria
User is able to view the node id of the electron along with each electron in the dispatch graph
Optional
An option to show or hide the node id will help users
It will help to also show the node id as part of the electon side bar when an electron is selected
Implementation details

Most likely points to the transport_graph_node_id in the electrons table.
If this field is not being sent to the UI already, then the graph API & electron side bar API will need to be modified

Hey team! Please add your planning poker estimate with ZenHub @ArunPsiog @Prasy12

@mshkanth Can you tell mw where exactly is the case for user viewing the node id on the UI? Is it available on Figma?

@mshkanth Can you tell mw where exactly is the case for user viewing the node id on the UI? Is it available on Figma?

Updated description with screenshot. Yes, it is there in Figma

@Prasy12 - Updated issue to include executor label also.

Please add your planning poker estimate with ZenHub @Prasy12

We have an option to hide labels in our current GUI now and till that is present we will show the executor and node id in a tooltip when the hide label feature is enabled. For normal view the UI will be as in the screenshot above :
Without hide labels:

With hide labels:

cc : @santoshkumarradha @mshkanth @Kamalesh-suresh


TestPersistBatches failes race tests

See #3206
This test fails race and it has been disabled for race tests.
@girishranganathan you are the author of this, please asses the cause of failure.

cc @douglas-reid

run it 100 times. see 2 failures. investigating...
go test -v -run TestPersistBatches ./mixer/adapter/solarwinds/internal/appoptics/... -count 100 -race > /tmp/persistBatches.out


Started switch-case for different Action events; extracted pull_request event handling to a function

Current dependencies on/for this PR:

main

PR #320   👈

This comment was auto-generated by Graphite.

Graphite Merge Job
Current status: 🔄 Waiting for checks to pass
This pull request is currently waiting for CI and mergeability checks to pass before being merged.
This comment was auto-generated by Graphite.

Job Reference: KzUHOYBmkg9kxvwCyQOp


Typescript Update

Hi! can you update typings for typescript? i've been working with sharepoint framework, using your table that look's amazing, but typings aren't for v.3.0 and i cant import custom module, like "InsertButton" for instance. Thanks for your job,

HI @MarianoPrz, I dosen't support the TypeScript and I think maybe there's some people to do it?!   Let me know your concern because I'm not familiar with ts. thanks


coqPackages.paramcoq: enable for Coq 8.13

Motivation for this change
Add support for latest version of Coq.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build coqPackages_8_13.paramcoq


(Request) Allow individual character sheets to have a custom name for spell points

I use a reworked sorcerer model that casts using sorcery points directly and I would very much like to be able to call it sorcery as opposed to spell points. This is not so much an issue as it is a feature request.

thank you for your interest, that's a nice feature, but one that would require a lot of work. I can't promise this will be implemented soon.

with the new version you should be able to do that, just change the item name on it.


feat: support maxAge for public assets

Allow using maxAge for publicAssets: [] option to provide caching headers:
  publicAssets: [
    {
      baseURL: "dist",
      dir: "public/dist",
      maxAge: 3600,
    },
  ],

Remarks:

Using route rules in production we can also map caching to native providers
Default (and unused) 60sec is removed for public dirs allowing opt-in control of this feature
This feature is auto-disabled for / prefix and fallthrough paths since another handler might respond
This feature is only effective on production to reduce chance of misconfiguration and development mode issues
immutable and public conditions enabled
One can directly use routeRules to apply for development or any other custom beahior

Another fix is also included that allows to modify nitro.options.routeRules after init syncing with runtimeConfig object.

what is fallthrough in this context?

When a request comes to a public asset dirs prefix with fallthrough enabled, and not matching, router continues to make a SSR request (useful for cases when a base URL is shared for public assets and API routes)

Cool, greate stuff!!

@pi0 is this supposed to work for SSG as well? if yes, is there anything regarding the dir and baseUrl paths I have to be aware of?

in SSG, there is no Nitro server running. Alotugh since we integrate with route rules, for the supported platforms (vercel, netlify, cf pages) we generated static rules for maxAge to be handled by their edge CDN.
Default TTL is not set for base asset dirs with / only to prevent unwanted caching issues.


More specific search for the keys of userid and roleid in FindUserRoleAsync

My UserRole-Table was created by the following auto-generated migration code:
migrationBuilder.CreateTable(                 name: "UserRole",                 schema: "Security",                 columns: table => new                 {                     RoleId = table.Column<int>(nullable: false),                     UserId = table.Column<int>(nullable: false)                 },                 constraints: table =>                 {                     table.PrimaryKey("PK_UserRole", x => new { x.RoleId, x.UserId });                     table.UniqueConstraint("AK_UserRole_UserId_RoleId", x => new { x.UserId, x.RoleId });                     table.ForeignKey(                         name: "FK_UserRole_Role_RoleId",                         column: x => x.RoleId,                         principalSchema: "Security",                         principalTable: "Role",                         principalColumn: "Id",                         onDelete: ReferentialAction.Cascade);                     table.ForeignKey(                         name: "FK_UserRole_Users_UserId",                         column: x => x.UserId,                         principalSchema: "Security",                         principalTable: "Users",                         principalColumn: "Id",                         onDelete: ReferentialAction.Cascade);                 });
I am using int-based Id-Fields.
This code specifies my primary key like this:
table.PrimaryKey("PK_UserRole", x => new { x.RoleId, x.UserId }); .
The UserStore searches for UserRole like this:
UserRoles.FindAsync(new object[] { userId, roleId }, cancellationToken);
The keys of the primary key are swapped, leading to random behaviour of some user manager functions e.g. RemoveFromRoleAsync(..), AddToRoleAsync(..), ..
My solution with
SingleOrDefaultAsync(r => r.UserId.Equals(userId) && r.RoleId.Equals(roleId)
searches for the UserRole independent of the primary key order.

The code has moved to https://github.com/aspnet/AspNetCore/tree/master/src/Identity please file an issue if you want to discuss this further


Build failure: poetry

Steps To Reproduce and Build Logs
[user@system:~]$ nix run nixpkgs#poetry
error: builder for '/nix/store/0l35ir5wsvaxlx533v6ymi8xs9fnisp8-python3.10-poetry-core-1.7.0.drv' failed with exit code 1;
       last 10 log lines:
       > source root is source
       > setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/vendors/pyproject.toml
       > patching sources
       > applying patch /nix/store/b4w2fblzs0xfpmr6wp4abka4cmnipr51-0bdf29e9631fda9436066a07ca8e69a4aa97a31e.patch
       > patching file Makefile
       > patching file src/poetry/core/_vendor/pkgutil_resolve_name.LICENSE
       > patching file src/poetry/core/_vendor/pkgutil_resolve_name.py
       > patching file src/poetry/core/_vendor/vendor.txt
       > Hunk #1 FAILED at 2.
       > 1 out of 1 hunk FAILED -- saving rejects to file src/poetry/core/_vendor/vendor.txt.rej
       For full logs, run 'nix log /nix/store/0l35ir5wsvaxlx533v6ymi8xs9fnisp8-python3.10-poetry-core-1.7.0.drv'.
error: 1 dependencies of derivation '/nix/store/jgsky3npdajsib388vfxfxxkwdn10ifn-python3.10-iso8601-1.1.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/yf4156dv2ad2c3gwbnp2mwc5npx2z5y1-python3.10-pkgconfig-1.5.5.drv' failed to build
error: 1 dependencies of derivation '/nix/store/p0igifqj08r9jl9fvag5lmr85l7y14yq-python3.10-poetry-plugin-export-1.5.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/pqxgl0wrblyy4f707adccb89bm2j26h1-python3.10-pytest-httpserver-1.0.7.drv' failed to build
error: 1 dependencies of derivation '/nix/store/bmdi2r0lm0wzhy8paa9yxysp3vgb98gx-python3.10-sh-2.0.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/hy3mka6wk0wcq69zkyaybw3np2f7iva2-python3.10-tomlkit-0.12.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/d3fprycwhd5j85jrdd4pahyivijiw037-python3.10-faust-cchardet-2.1.19.drv' failed to build
error: 1 dependencies of derivation '/nix/store/kfk82bwlkhwp1m63zig5m9796bkfdp0d-python3.10-python-dotenv-1.0.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/v0a98p9r2bz7k53maya7l3r991slijcb-python3.10-responses-0.23.3.drv' failed to build
error: 1 dependencies of derivation '/nix/store/ffdpkgnhkcnzysq589za82vnspjq3lnb-python3.10-flit-3.9.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/242bbqry0mf3ygza38b24dwbpp4z1n0w-flit-build-hook.drv' failed to build
error: 1 dependencies of derivation '/nix/store/p9qvvcf931zy8m2wljwymsj02xcwfjld-python3.10-more-itertools-9.1.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/9jmfqbdwidq6gpvijfqiq94z7j1hwbk8-python3.10-jaraco-classes-3.1.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/mi2g7nkxys09ly1syrc459dra30949x9-python3.10-jaraco-functools-3.6.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/7cgpajy2yz48qqr55sy0cx5lirjk2hcx-python3.10-keyring-24.2.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/vaniv9smv7s4jqai9xzlw7m6bb03ia8s-python3.10-tempora-5.5.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/vnwwvvwbg99ki9f54lz9dp73nzh7njcj-python3.10-portend-3.1.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/6a1wlayz3ldlx3cla9ac52xwazs6zw0d-python3.10-cleo-2.0.1.drv' failed to build
error: 1 dependencies of derivation '/nix/store/7cyf8b3iq9c2nkn1ns60v9770a7g47ic-python3.10-clevercsv-0.8.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/d8x531qky94q601knzpsykkr16ca39fq-python3.10-deepdiff-6.3.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/1dvbj63njl5wyg2q01l534yf7z1f71k8-python3.10-cryptography-41.0.3.drv' failed to build
error: 2 dependencies of derivation '/nix/store/yglfnf17qk1ab5rysxcil2c3n1i5c2cs-python3.10-dnspython-2.4.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/y99gkglfj433zb86iyx194q5si02dj3k-python3.10-pyopenssl-23.2.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/fky8cyhq1q0pg0f4s4r17hd7i8dm08fb-python3.10-service-identity-23.1.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/r7ssvvy49qp5q80q540d2mfsb3rvqndh-python3.10-email-validator-1.3.1.drv' failed to build
error: 3 dependencies of derivation '/nix/store/sqvxkfhcpimfwc76q7qqzg9iaxjy1g5a-python3.10-trustme-0.9.0.drv' failed to build
error: 2 dependencies of derivation '/nix/store/gxl5dj96qkjzp7pzrwd054m0yal3j8np-python3.10-pydantic-1.10.9.drv' failed to build
error: 2 dependencies of derivation '/nix/store/c6gs85x3dm505p8yfinkdw64iwczhzk5-python3.10-requests-toolbelt-1.0.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/rli1vm4qjy273m5n38vbj62jldkiy7x0-python3.10-inflect-6.0.4.drv' failed to build
error: 2 dependencies of derivation '/nix/store/vfrrwx19pzs4546qnm4yv4mbazvc66c3-python3.10-jaraco-text-3.11.1.drv' failed to build
error: 5 dependencies of derivation '/nix/store/1y8y7npx14vd90601kzi1wpc9z1f2gp8-python3.10-cheroot-9.0.0.drv' failed to build
error: 2 dependencies of derivation '/nix/store/xnv8m2bacpdwfh429bafpp5ww2y5vgra-python3.10-jaraco-collections-4.3.0.drv' failed to build
error: 5 dependencies of derivation '/nix/store/lfhqj0qkmlp0ywrgy2lqrisq5dwyxgn4-python3.10-cherrypy-18.8.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/1f9vr9h69ih6pfr6mwv85sn161wa172y-python3.10-cachecontrol-0.13.1.drv' failed to build
error: 8 dependencies of derivation '/nix/store/0xn2584qxcykaji4n8443qba81vvin71-python3.10-poetry-1.6.1.drv' failed to build

[user@system:~]$ nix log /nix/store/0l35ir5wsvaxlx533v6ymi8xs9fnisp8-python3.10-poetry-core-1.7.0.drv
Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing pypa-build-hook
Using pypaBuildPhase
Sourcing pypa-install-hook
Using pypaInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing pytest-check-hook
Using pytestCheckPhase
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/9z8f8cqkhbdq6pr4xcmx2c77byk3nfc2-source
source root is source
setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/vendors/pyproject.toml
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
applying patch /nix/store/b4w2fblzs0xfpmr6wp4abka4cmnipr51-0bdf29e9631fda9436066a07ca8e69a4aa97a31e.patch
patching file Makefile
patching file src/poetry/core/_vendor/pkgutil_resolve_name.LICENSE
patching file src/poetry/core/_vendor/pkgutil_resolve_name.py
patching file src/poetry/core/_vendor/vendor.txt
Hunk #1 FAILED at 2.
1 out of 1 hunk FAILED -- saving rejects to file src/poetry/core/_vendor/vendor.txt.rej

Additional context
Only happened to me on Darwin (x86_64).
Notify maintainers

@jbaum98 @dotlambda
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-darwin"`
 - host os: `Darwin 22.6.0, macOS 10.16`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.17.0`
 - nixpkgs: `/nix/store/xrj5ikp417580r5g9m1shz9dk787szns-source`

Can confirm that I faced the same issue, with essentially identical output, on x86_64-darwin.

error: builder for '/nix/store/0l35ir5wsvaxlx533v6ymi8xs9fnisp8-python3.10-poetry-core-1.7.0.drv' failed with exit code 1;
       last 10 log lines:
       > source root is source
       > setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/vendors/pyproject.toml
       > patching sources
       > applying patch /nix/store/b4w2fblzs0xfpmr6wp4abka4cmnipr51-0bdf29e9631fda9436066a07ca8e69a4aa97a31e.patch
       > patching file Makefile
       > patching file src/poetry/core/_vendor/pkgutil_resolve_name.LICENSE
       > patching file src/poetry/core/_vendor/pkgutil_resolve_name.py
       > patching file src/poetry/core/_vendor/vendor.txt
       > Hunk #1 FAILED at 2.
       > 1 out of 1 hunk FAILED -- saving rejects to file src/poetry/core/_vendor/vendor.txt.rej
       For full logs, run 'nix-store -l /nix/store/0l35ir5wsvaxlx533v6ymi8xs9fnisp8-python3.10-poetry-core-1.7.0.drv'.

[user@system:~]$ nix-store -l /nix/store/0l35ir5wsvaxlx533v6ymi8xs9fnisp8-python3.10-poetry-core-1.7.0.drv
Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing pypa-build-hook
Using pypaBuildPhase
Sourcing pypa-install-hook
Using pypaInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing pytest-check-hook
Using pytestCheckPhase
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/9z8f8cqkhbdq6pr4xcmx2c77byk3nfc2-source
source root is source
setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/vendors/pyproject.toml
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
applying patch /nix/store/b4w2fblzs0xfpmr6wp4abka4cmnipr51-0bdf29e9631fda9436066a07ca8e69a4aa97a31e.patch
patching file Makefile
patching file src/poetry/core/_vendor/pkgutil_resolve_name.LICENSE
patching file src/poetry/core/_vendor/pkgutil_resolve_name.py
patching file src/poetry/core/_vendor/vendor.txt
Hunk #1 FAILED at 2.
1 out of 1 hunk FAILED -- saving rejects to file src/poetry/core/_vendor/vendor.txt.rej


Mecrisp Peripherals?

The irresistable draw of the MeCrisp family is the large installed base, and the promise that many of those implemented peripherals will also work on Mecrisp-Ice.  The problem is that I do not know what will work on Mecrisp-Ice and what will not work.  I do not know which MeCrisp libraries are dependent on C routines, or on specific microcontroller hardware.  Are the different flavors of Mecrisp Forth really compatible?  So a list of which peripherals actually work on this FPGA would be a killer elevator pitch!
I recently returned to graduate school, my master's thesis will be on a Forth processor.  Step 1 was to review what is out there, and Mecrisp-ice looks very promising.  Here re the slides for a talk on "Review of Forth Processors" which I will be presenting at the August SVFIG meeting, and at the September FPGA World Conference in Stockholm.
https://pythonlinks.info/presentations/ForthPresentation.pdf
If you had a list of what peripherals work with Mecrisp-Ice I would include it, and that would be a big reason for people to use  Mecrisp-Ice.
What would be even better if  there were a list of peripherals which could connect to Mecrisp-Ice, along with the size of the Mecrisp solution and the size of the dedicated hardware solution.   I suspect that there are a number of FPGA cores which could be made smaller, or more flexible with a Mecrisp Forth cores.

On the list of notable peripherals, these vary by target, and include:
LCD with text mode in logic, and atomic clear/set/invert on GPIO pins:
mecrisp-ice-2.6c/mch2022/icestorm/mch2022.v
Configurable interrupts on GPIO pins:
mecrisp-ice-2.6c/icebreaker/icestorm/j1a.v
USB terminal, taken from https://github.com/ulixxe/usb_cdc
mecrisp-ice-2.6c/fomu/icestorm/j1a.v
mecrisp-ice-2.6c/common-verilog/usb_cdc
FOMU also comes with Ledcomm, a bidirectional optical terminal with handshake over a singe LED, nice for adding a debug connection somewhere.
mecrisp-ice-2.6c/fomu-ledcomm/icestorm/j1a.v
mecrisp-ice-2.6c/common-verilog/ledcommflow.v
One could use VGA text mode as featured in Mecrisp-Quintus (RISC-V) together with Mecrisp-Ice, similar to the LCD code for the MCH2022 badge, but the Nandland Go HX1K FPGA just does not have enough BRAM memory for Mecrisp-Ice and VGA together:
mecrisp-quintus-1.0.5/nandland/nandland-verilog/nandland.v
Yes, I follow the issues, but by the way, the zuloloxi/mecrisp-ice repository is not the upstream branch of Mecrisp-Ice. Find the official packages here: https://sourceforge.net/projects/mecrisp/files/ We are at Mecrisp-Ice 2.6c at the moment.
On the slides... I forgot to update the passage in the README. I would not recommend Nandland Go anymore, because it is a very small FPGA, and everything is a sizecode challenge on that. My current recommendation is to use the Icebreaker (with UP5K FPGA).

Thanks for the great answer.
Sadly currently the Icebreaker is sold out.
https://1bitsquared.com/collections/fpga/products/icebreaker
I am still digging through your answer.  I think part of the problem is that I was not clear in my own mind.   Many of your links were .v files.  For someone interested in Mecrisp Ice connections to various hardware circuitry is critical.
I have a different perspective.  If someone wants to use software on forth for bit banging control of peripherals, what they are looking for is the software which runs on Mecrisp Ice cores.  Any fpga designer can find ip cores for I2C, or uart.  What would be very interesting to them if they could do that on a forth core, and either save space, or get more functionality.

I understand your desire - I usually hook up new peripherals to GPIO lines for bit-banging while doing experiments and determining my requirements before I rewrite it in Verilog for exact timing. The prototypes are just hacked together Forth files that I drop as soon as the Verilog one works as expected, with Forth doing the high-level or non-critical stuff, gluing the action of the peripherals together. That is the point of an FPGA with a softcore.
Because of lack of gates and memory, I bit-banged a valid VGA signal on Nandland Go, with a 16x16 resolution. It is hard to bit-bang video signals if the CPU runs at the pixel clock, but one needs more than one cycle for generating the pixel and is very short on RAM.
mecrisp-ice-2.6c/nandland/examples/vga.fs
More useful is a mixed design with low-level parts reading an analog-digital converter in Verilog and all the other parts done in Forth:
mecrisp-ice-2.6c/ulx3s/signallab/capture.txt
mecrisp-ice-2.6c/ulx3s/signallab/asciisignal.txt
mecrisp-ice-2.6c/ulx3s/signallab/live.txt
Also see bit-banged access to a SD card:
mecrisp-ice-2.6c/ulx3s/examples/sdcard.fs
Technically you just put nicely choreographed values into GPIO registers from within Forth.
By the way, I am curious on how you are going to implement communication between multiple cores, as the Mecrisp-Ice processor does not feature wait/busy signaling.
Both the Transputer and the Greenarrays GA144 provide nice features for interprocessor communication, have a look at these! I love the idea of pointing the CPU to a peripheral port on reset that does handshaking in logic, and disables the address increment, so one just feeds an instruction stream into a port, and concludes with a jump instruction into the freshly loaded RAM area. But this obviously requires memory mapped IO and wait/busy signaling.

PS: If you cannot find an Icebreaker for a first start, try getting the ECP5-based ULX3S board from Radiona. That one will be large enough to support multiple instances of Mecrisp-Ice.

PS2: The Nandland Go itself is capable of up to 800x600 video output... But then Forth does not fit into BRAM anymore: https://github.com/Mecrisp/Nandland-RISC-V/tree/main/800x600

More useful is a mixed design with low-level parts reading an analog-digital converter in Verilog and all the other parts done in Forth:

Thank you.   As a newbie to digital design that is just the kind of advice I need.    Yes bit-banging sounds like a great idea, but a more careful study suggests that it is subject to glitches.  So dedicated hardware makes more sense.  And so your previous response with verlilog links also makes more sense.
And maybe that explains why the GA144 had communication problems.  It tried to do bit banging.   I think you have it right.  Use dedicated circuits, working closely with a higher level processor .  I am converted.
Thank you for the links to files.  The three files look really interesting.  I will be digging into them.   Just the kind of examples I need.   Where does one submit pull requests?   The URL mecrisp-ice-2.6c does not seem to work.
The transputer, cooperating sequential processes, coroutines and pauses feature strongly in my thinking.  I will look more closely at the transputer and the GA144.  I like how Axi does handshaking.  Both the sender and receiver have to be ready.  Sure I need to make some changes to your cpu.  The reputation of the J1, is that it is not many lines of code, quite easy to customize.  I have already read the code verilog very carefully.  Should be easy to add a pause.  Both the microcore and the Core-1 have pauses.

I love the idea of pointing the CPU to a peripheral port on reset that does handshaking in logic, and disables the address increment, so one just feeds an instruction stream into a port, and concludes with a jump instruction into the freshly loaded RAM area. But this obviously requires memory mapped IO and wait/busy signalling.

Thank you.  I had no idea how the details worked.  But I am not quite sure why memory mapped IO would be needed.  The J1 can read and write to the TOS, NOs, return stack, and from memory.  Should be easy to create another port, and have it read from there.
As for the GA144, I was quite inspired by it.  But too little memory, and reportedly communication problems, which I have yet to fully understand.
As for the GA144 matrix, the lesson from the leader of the Core-1 group is that these are FPGA's.  No need to do a fixed matrix of cores, just connect them however your application wants to connect them.

Thank you. As a newbie to digital design that is just the kind of advice I need. Yes bit-banging sounds like a great idea, but a more careful study suggests that it is subject to glitches. So dedicated hardware makes more sense. And so your previous response with verlilog links also makes more sense.

A well designed GPIO port for bit-banging does not glitch either, that isn't the problem. It is all about timing in an FPGA. See, you can easily bit-bang one analog-digital-converter or handle communication over RS232, but what about handling terminal, five ADCs and three DACs with a stable sample rate generated by a numerically controled oscillator for signal processing applications? You need either wizard level programming skills on a microcontroller (and hope for requirements never change), or a bit of additional logic that simply generates the control signals and puts all the data into ring buffers for a Forth program to handle without the need for exact timing, as long as it is fast enough in total to handle all buffers without over- and underflows.
Most FPGA designs therefore combine low-level, fixed function logic specific for driving the electronics that one soldered on, and a softcore processor that orchestrates these parts and handles user-configurable settings and choices.
Yes, it is possible to have multiple processor cores, each bit-banging their peripheral, but this will take much more resources than simply having a counter, a few gates and a buffer. But why, if you are already using an FPGA that can do any logic you wish? The idea with multiple processors will become more interesting in an ASIC where users cannot add their own logic. A very good example is the Parallax Propeller! This is a multicore-microcontroller (look both at the old and the new one) with a really clever mechanism for communication between cores, which are intended for precisely bit-banging as much peripherals as you have cores available. There are many great bit-bang examples for the Propeller, like ethernet, S/PDIF audio, RFID...
The J4A (the barrel Forth processor by James Bowman) steps in a similar direction. These designs are very useful if you cannot simply load a new bitstream if you want to change the functionality available in logic.
Also interesting: See the RP2040 microcontroller, which has small programmable IO helper state machines with buffers (called "PIO", programmable IO) to offload timing-critical tasks from the two main processor cores. These are all variations on the theme.

Thank you. I had no idea how the details worked. But I am not quite sure why memory mapped IO would be needed. The J1 can read and write to the TOS, NOs, return stack, and from memory. Should be easy to create another port, and have it read from there.

Yes, thats perfectly possible, then you have initialised memory with a classic bootloader that runs on the core on boot, and takes a memory image from whatever means of communication you choose. This is what the Transputer does. See chapter 2.10 in http://transputer.net/iset/isbn-063201689-2/inside.pdf
What I tried to describe is the idea used in the GA144 of directly executing a memory mapped IO port, without copying the instructions to RAM first. Then the core does not need initialised memory (expensive in ASIC), and logic for that is minimal - disable incrementing program counter when executing address in IO range, and the port needs to provide handshake, stopping the core until the next instruction arrives at the port.
https://mschuldt.github.io/www.colorforth.com/b900.htm
https://mschuldt.github.io/www.colorforth.com/ef.htm
https://mschuldt.github.io/www.colorforth.com/etherCode.htm

As for the GA144, I was quite inspired by it. But too little memory, and reportedly communication problems, which I have yet to fully understand.

As for the GA144 matrix, the lesson from the leader of the Core-1 group is that these are FPGA's. No need to do a fixed matrix of cores, just connect them however your application wants to connect them.

I have not used a real GA144, but only studied its datasheets. In my opinion, the problem of the GA144 is that the individual core memories are too small to run common algorithms that are not really suited for parallelisation, and there are too few cores to think of these at the (multiple) gate level. It is somewhere in between of multicore microcontroller and programmable logic. While its capabilities are outstanding, getting it to work is solving a complicated puzzle. In addition, there are many perfectly valid, but oddball choices everywhere one needs to wrap the mind around. Toolchain research would be necessary to fully unlock its potential. My recommendation: Study it in detail for very interesting ideas!

Thank you for the links to files. The three files look really interesting. I will be digging into them. Just the kind of examples I need. Where does one submit pull requests? The URL mecrisp-ice-2.6c does not seem to work.

These are relative paths into the upstream releases you can get in the download section at mecrisp.sourceforge.net and extract on your local storage. For the equivalent of a pull request, send me an E-Mail to the official address<EMAIL_ADDRESS>with the files to be included. If you want to discuss your changes first, go here: https://sourceforge.net/p/mecrisp/discussion/general/

Thank you for the brilliant GA144 and Transputer links.  And the most needed lattice board link.   You went way beyond providing Mecrisp tech support and went a long way towards supporting my project.   Most appreciated.  There are so few people who have any idea at all about what I am talking about.   Let alone who can provide me with good technical guidance.
So here is the million dollar question.  Do you know of any good applications for 100s of Forth cores?

Chris

I had to spin my head on this for a while.
For high performance parallel scientific computing, one needs shared memory and/or extremely high performance crosslinks - see "NUMAlink" for example. The Mecrisp-Ice cores are not suited by design for large and/or shared memories, so high performance computing is out.
For peak IO performance, decicated logic is hard to beat.
We still have applications on the table that are complicated to drive, need reconfigurability on-the-fly, require data processing that does not require a lot of data exchange with neighbour cores, or benefits from computation-in-fabric.
Ideas:

Particle accelerator detectors, in which many, many sensors need to be monitored and realtime data needs to be synced and compressed with fancy algorithms before it can be transfered to data storage

Special purpose image sensors, maybe for hyperspectral imaging

Swarm simulations, multi-agent behavioural models in bioinformatics

Network simulation to test new link topologies

Particle accelerator detectors, in which many, many sensors need to be monitored and realtime data needs to be synced and compressed with fancy algorithms before it can be transferred to data storage

Agreed.  Although physics is not that big a market.  Basically real time control, where every I/O gets a dedicated tiny processor and no interrupts.  That makes life easy for the programmer.  timing becomes simple.  This will be my second cpu, the Hana II.  A 3 x 3 grid.  One supervisory computer in the middle talking to all of the others.  the others can talk to their two neighbors, but mostly just to their dedicated i/o ports.
The obvious competition is the Propeller Parallax.  And it only has 8 cpus.  And while Forth is in the Propeller's ROM, each core, only gets 1024 x 32 bits of dedicated memory.

Special purpose image sensors, maybe for hyperspectral imaging

Totally agreed.  But it needs to be real time to justify an FPGA.  I was only thinking of RGB images.  Anything where computation is on a plane, so that the cores only have to talk to their neighbors is a great place to be.  And for demos, nothing beats vision.  Should be quite doable to do a 20x20 grid.   Each core can do convolution algorithms at the same time.   With the Altera boards, I can get 444 hard core multipliers, so I could even do a 21 x 21 grid.  441 cores.
I used to be vision impaired, and once tried an edge detection glasses, a great idea, but the CV libraries do not work that well.  Quite easy to do edge detection by recognizing regions of the same color.  Basically map from RGB to polar coordinates, amplitude and angles,  strip out the amplitude, and you can segment the world by color, goes a very long way to providing big blobs for vision impaied people to get around. And if not, someone else will figure out some other vision algorithm.  And the processors can interrupt their neighbors once they have figured out something they need to share. Like a sharp edge going in the direction of the neighbor.
Vision impaired is not a big market, but a very poorly served market, and any niche is enough to get ones foot in the door.

. Swarm simulations, multi-agent behavioral models in bioinformatics.

And of course that is the other one I came up with.  The actor model, lots of actors interacting with each other, even if it is not nearest neighbors.  The conventional microprocessors do not pass messages to each other quickly, and furthermore they have a cache coherency problem, when many are operating on the same data.  I wish I knew how GoLang dealt with all of this.
I am not quite sure how to do the networking on such a device.  Maybe a hypercube?  It would need something like a DNS server and a way to shovel actors back and forth from DDRAM.
In any case it is such a pleasure to be able to chat with people who have good instincts about all of these issues.

It happens that I am a biophysicist, so applications in physics is my natural habitat :-)
Yeah, on how and in which pattern to link cores to each other... That is a research question. The solution of the Parallax Propeller does not scale beyond a few handful. You could take inspiration by diving into the Transputer manuals or into the early Cray designs. Another source of inspiration might be wireless mesh networking. Of course, you do not have to handle moving nodes with unreliable connections, but the routing algorithms are worth a look. Maybe https://en.wikipedia.org/wiki/B.A.T.M.A.N. is a starting point, and you will find active research in that area.
I think your first task is to implement the basic point-to-point link between two Mecrisp-Ice cores. Experiment a little with it, see how it integrates into Forth, make sure it is works under all circumstances, and find an elegant way for handling the link in a handfull of definitions. Keep in mind that every core will have more than one link later. I am interested in this, and I am happy to discuss link implementation with you.
Then scale up, arrange a handfull of cores in, lets randomly say a hexagon pattern, and start thinking on routing. While you are at the routing part, you will discover which link topology will fit your chosen application best.
FPGAs for example have links to neighbours, and links further down. Lattice ECP5 comes with rectangular grid, with span 1 (neighbour), span 2, and span 6 wired: https://prjtrellis.readthedocs.io/en/latest/architecture/general_routing.html


AlaaSabbagh

thank you

I'm quite elated about your pull request. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a pull request and learned that I merged it?
We’ve recently added Facebook share and tweet feature to our web app. Could you please go to https://roshanjossey.github.io/first-contributions/#social-share and share your first contribution to open source?
Also, check out projects with easy issues while you’re there.

Thank you Roshan for helpful guide you provided, I learned about it through
pocket discover part of the app.
I would like to tell you that there one step is missed that could confuse
some people with no experience with command line (personally confused me as
experienced)
The step is :

user name and password

Thank you again ❤
On Mon, 6 Aug 2018, 07:53 Roshan Jossey<EMAIL_ADDRESS>wrote:

I'm quite elated about your pull request. I wanna evolve this project to
addresses various problems faced by first-time contributors. I'd love to
learn about your journey in open source community, the problems, pain
points you had etc.
Could you explain how you felt when you went through the tutorial, made a
pull request and learned that I merged it?
We’ve recently added Facebook share and tweet feature to our web app.
Could you please go to
https://roshanjossey.github.io/first-contributions/#social-share and
share your first contribution to open source? Also, check out projects with
easy issues while you’re there.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/Roshanjossey/first-contributions/pull/5803#issuecomment-410596479,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASzspx2uMCdvJ8f3h8zz1yY9q6fDfDelks5uN9m-gaJpZM4VvnHo
.

I’d urge you to continue contributing to other open source projects.
We also have a slack team to help/mentor people trying to contribute to open source projects.
You can join the team by going to https://goo.gl/PM1Jdh


[LinkingIOS] Add support for Universal Links

Adds support for Universal Links.

Subscribe

:shipit:

@facebook-github-bot shipit

Is it on a FB's internal review?


DM-37584: add proposal from the Great Calibration Refactor discussions

Thanks Jim and Eli for a great talk today! From reading through your proposals, here are my initial thoughts on the refactor proposal:

I'm concerned that merging of many smaller PipelineTasks into a small number of "SuperPipelineTasks" may limit the discoverability of exactly what data reduction is happening within a task. The concept of SuperPipelineTasks  to my eye seems somewhat analogous to the use of subsets within a pipeline definition file, however, having data reduction grouped into a smaller number of SuperPipelineTasks limits the flexibility of subsets (and to some extent, replaces the need for subsets). If anything, I'd prefer to break some of the larger PipelineTasks up into smaller tasks, and then rely on subsets to link them together for the end-user to interact with. However, if the win from I/O optimization is significant, then I can see the logic to going this way instead of leaning so heavily on subsets.
I agree with/fully support pretty much all of the proposed naming conventions, except for:

I would prefer all table types to have an appropriate suffix, in contrast to your proposal that "the final thing does not need a suffix". I.e., I would prefer to see initial_source_visit instead of the proposed initial_source. This makes it clearer immediately as to what level of data processing this initial source table belongs to (and also saves us from any future unexpected 'initial_source' datasets which we may want to construct). This logic may also be advocating for unforced_source in place of just source, but that may not be necessary.
The use of initial_ and final_ for certain dataset type names inherently locks-in these dataset types as being the 'initial' and 'final' versions of these data. If this is really our last big change to the data reduction pipeline, then this may be fine. However, for example, if at some future point we add a new task that sits after bootstrapImage that produces an updated initial_pvi output, I don't see how we could appropriately name this output unless we go down the route of switching the existing initial_pvi to an initial_pre_pvi, or similar. I personally prefer how isr does this right now, using a post... syntax for output data products, but I accept that that may not be desirable for long task name outputs. However, initial_ and final_ may not be important considerations in the first place, as I note that you don't intend any of these data products to be persisted on-disk (so this may all be an internal feature and therefore just an implementation detail). You may also argue that any new task should instead be merged into bootstrapImage, removing the problem outlined here, which is also a valid point.

The term bootstrap to me does not seem to convey what these proposed super tasks are doing (I instead think of bootstrapped errors). I like the idea of reusing characterizeImage here, but I accept this may not be desirable if we wish to remove any possibility for confusion post-refactor. I think John mentioned that calibrateImage is also available, which may work well too.

I know nothing about this discussion but:

if the win from I/O optimization is significant,

The idea from the beginning was that for some cases where we go from one pipeline task to another and it's clustered into a single process and we don't need the intermediate, we would use the in-memory datastore and there wouldn't be any I/O. This design makes it very easy to configure datastore to allow those intermediates to be persisted for debugging if you want to do that.

I was going to chime in and say the same thing as @timj . I think since we were talking about middleware changes being needed anyway, we should put that effort into the clustering algorithm / in-memory datastore instead. I understand the point of a small change to characterize/calibrate possibly being appropriate, but as a generality the more tightly coupled larger tasks are, the harder it is to possibly change the behavior in the future, by inserting things in between stages. The pipeline system was not just a system to manage batch production issues, but also a tool to be leveraged by developers.
All this said I just wanted to chime in on that discussion above. I still need to finish reading through the proposal, and will have more detailed thoughts later.


Always refresh token when calling test_authentication(); add admin to delete NotificationSources

Fixes #162, in theory (as usual it's really not feasible to actually test the OAuth workflow locally).

Add capability in the Admin UI to manually delete NotificationSource records, forcing their recreation when Nautobot is restarted (useful in the case where a NotificationSource has a bad token and it's not feasible to access nbshell)
Add a force_refresh flag to the load_credentials() method and set this flag to True in the case of test_authentication calling it.

Fixes #162, in theory (as usual it's really not feasible to actually test the OAuth workflow locally).

do you think it would be worthy to implement proper mocking for testing OAuth?

do you think it would be worthy to implement proper mocking for testing OAuth?

To be honest, I'm not sure what that would look like here - the API calls for OAuth are pretty abstract (self.credentials.refresh(Request()) being the main one) so there's not much to mock unless we want to dig into the guts of the google.oauth2 library.

do you think it would be worthy to implement proper mocking for testing OAuth?

To be honest, I'm not sure what that would look like here - the API calls for OAuth are pretty abstract (self.credentials.refresh(Request()) being the main one) so there's not much to mock unless we want to dig into the guts of the google.oauth2 library.

I agree


Fix can't find RCTBridgeModule.h for RN 0.40 and higher

Thanks to https://github.com/yamill/react-native-orientation/issues/159#issuecomment-287311619

A similar PR has been merged at 5a16ac8a3f96e12969d86a1dd1f6d548efc213b2. Cheers.


Change rate limit algorithm

Instead of using a

limit per address per block

Use a

limit per address over the entire interested block range.

Done: https://github.com/yzernik/squeaknode/pull/1102


Alexa Guard stays enabled

Just FYI guys, started using the API calls to arm/disarm the guard mode and after one day, the white/blue spinning guard mode light is stuck on my five dots. Even if I turn off Alexa Guard via voice, and reboot the Echo dots the light stays on. I've disabled Guard completely, rebooted the Dots, forgot all devices from alexa.amazon.com, etc, etc -- hard rebooted dots -- all in various iterations. Still spinning blue/white light.
Originally posted by @walthowd in https://github.com/keatontaylor/alexa_media_player/issues/186#issuecomment-506572944

@walthowd I'm not sure there's much we can do with you but I can see if perhaps something we can help with.
Can you go to this url and see if there is more than one applianceId with AAA_OnGuardSmartHomeBridgeService?
We look for those entries figure out if there is an AlexaGuard to control. I'm guessing perhaps something happened to spawn more than one instance and that's the one that is stuck on.
If there are multiple entires, I'll probably need to get the relevant json data to figure it out. You might need to DM me in the HA community forum with a gist of the log so I can look.  Posting here you'd have to remove any serial numbers, etc.
One question may be did you try to rename the Alexa Guard entity or do anything beyond arming and disarming? Someone reported an issue with renaming in #230

Thanks for the suggestions. This is most likely more of a Amazon related bug then related to this component, but I wanted to share just in case it started affecting anyone else.
I only have one applianceId with AAA_OnGuardSmartHomeBridgeService visible via the phoenix API. I sent you the complete output via the HA forums.
I also have a call into Amazon support (surprisingly nice and super helpful over the phone), so we will see if anything develops there.
I didn't rename or change the HA entity in anyway -- I had also seen that issue reported.
Only two other things come to mind:

I've had Guard turned on for several weeks now and I have been using TTS via Google homes to turn it on. I upgraded the alexa_media_player component at the same time I upgraded to HA 0.95. To play with the new Alexa entity exposure feature in HA, I used the alexa.amazon.com website to forget all smart home entities. This had the effect of removing the redrock panel entity from Alexa and disabled Guard. I had to turn it back on today.

I've been using the alarm_disarm service call instead of alarm_arm_home service call as that seemed more semantically correct to me.

Finally, there are a few reports on reddit of the same issue. The resolution there was to completely remove the Alexa devices from the Amazon account and then factory reset the device and rejoin it to the account. I may try that tomorrow.

Thanks for the detail. I'm reviewing the output now, but since it's only the one, my first theory doesn't seem to apply.
I just wanted to address your point about alarm_disarm vs alarm_arm_home.  It's the same underlying API call. I just left both functions in since:

They're in the default HA component.
Alexa actually uses an API call ARM_STAY for the disarm which further made me think Alexa may decide to implement additional functionality for that in the future that is similar to a home setting.

You may want to link the reddit thread in here in case anyone else runs into this problem.

Similar reports of this issue on reddit:
https://www.reddit.com/r/amazonecho/comments/bp5wbu/echo_guard_disabled_spinning_ring_wont_turn_off/
https://www.reddit.com/r/amazonecho/comments/btnadl/echo_dot_has_white_rotating_ring_constantly_how/

Leaving this open for now so others who run into this can report. Otherwise, I don't think it's something we can fix.

FWIW, I unregistered five of my Echo dots and the whole process was pretty painless.

Use the Alexa app and unregister each device from your account.
Wait on the dots until the light is spinning blue.
Hold down Mute and Volume Down until the device factory resets and the light is spinning orange.
Use the Alexa app to re-register the device to your account.
Name the device the same name it had before.

After that process, there weren't any side effects or extra devices or duplicated media players, etc using this component or others.


Pagination on root index.html page

Hiya
Trying to put pagination on the home page of my site:
Please see Gist for code so far:
https://gist.github.com/iwarner/9884f2aee164ebc57dc2 - its really the next and previous links that are the issue, using the standard code.
The Next Link is changed to the following and works fine.
http://localhost:4567/page/2/index.html
But this breaks the rule in the docs
should it now be : http://localhost:4567/page/2.html or http://localhost:4567/index/page/2.html
Now I have created a pagination
PREV - 1 - 2 - 3 - 4 - NEXT
So the rules for my links to individual pages follow the rule I expect and so break they all link to
http://localhost:4567/index/page/2.html
Any help appreciated
Many thanks
Ian

Please also share your config.rb. You can add it to the same gist.

Thx added

Beautified gist with code and configuration: https://gist.github.com/lolmaus/13314995b326be27c957
So you've got directory indexes disabled?
Try setting blog.page_link to "page/{num}" and page/{num}.html, does this change anything?

Thx for the gist example - looks better for sure - will try the suggestion ASAP
Many thanks

Result in testing Next and Previous Links:

page/{num} = http://localhost:8080/page/2/index.html
page/{num}.html = http://localhost:8080/page/2.html/index.html

I will start a brand new project now and test code on index page of that also.

Ok this is important:
I had
set :strip_index_file, false
and page/{num}
When set to true the rest of links are more functional - so the issue is around using strip index false on the home page. The next and previous will work but will distort the general pattern of pagination
LOL hard to explain this.

Seems like strip_index_file and pagination don't get along well.

Hiya yeah I will have to put workarounds in, affects breadcrumbs etc also. Basically anything that relies on paths.
Will investigate and feedback with code on how I solved these.
Thanks


Fix noir ecdsa verification in acc contract.

Description
Detailed hackmd: https://hackmd.io/9QRzytElQE2sMLf4S7qR1A?view
TLDR: ECDSA signing in bberg and verification in noir has a minor "difference". Signature construction and verification should operate consistently on the message.

The noir ecdsa verification takes in the hashed message $z$ as an argument. So we need to hash the message before calling std::ecdsa_secp256k1::verify_signature.
The reason this worked with the noble curves package was: in the noble package, the message is never hashed. It is used as is for signing a message. Therefore the noir-ecdsa-verify works as we don't need to hash the message in verification.
Checklist:

[ ] I have reviewed my diff in github, line by line.
[ ] Every change is related to the PR description.
[ ] I have linked this pull request to the issue(s) that it resolves.
[ ] There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
[ ] The branch has been merged or rebased against the head of its merge target.
[ ] I'm happy for the PR to be merged at the reviewer's next convenience.

What could be done is: instead of defining: message = hash(payload), we can directly set message = payload.

I think that makes sense, so we don't need the extra hash in the contract. Note that this may break the schnorr account contract, since it uses the same base StoredKeyAccountContract class just swapping the signer.
Also, we'll need to make sure we document this properly in noir-lib!

Just remove the use ... debug_log; at top of noir file.

This issue could have been resolved with 1 loc:
secp256k1.sign(msg, privateKey.value, { prehash: true });

Hashing the message in ECDSA signature construction is critical for security and efficiency. That's non-negotiable.

@suyash67 libsecp256k1, that empowers bitcoin -- had unhashed API since inception. Also eddsa (ed25519ph). Hashed api is terrible in embedded envs with very limited RAM.

Well, it isn't every day that you find the maintainer of a package you're working with that drops in the conversation. Thanks so much @paulmillr for chiming in, I'm now wondering how you stumbled upon this thread.

This issue could have been resolved with 1 loc

Absolutely true, but our goal here was to remove dependencies on third party crypto libraries when possible, and since barretenberg (Aztec's cpp crypto library) covered ecdsa, we wanted to leverage it. noble was a stopgap solution to get an e2e working, and to validate that our own library was working as expected.

@suyash67 it's actually negotiable.

Now this is interesting. Given we'll need to optimise as much as possible in our circuits to reduce user's proving times, maybe it makes sense to keep the verify_signature_prehashed_message version exposed in Noir, just with documentation around it?

It's wise to use cpp bindings if your constraints and environments allow it: it's safer and faster. Less deps is also great.

I'm now wondering how you stumbled upon this thread.

I regularly check noble GitHub dependents and dive into the projects and its issues.

Thanks for your inputs @paulmillr and @spalladino! Well I thought it'd be easy to forge signatures if we use the un-hashed signature construction in ECDSA. Particularly, any signature for message $0 \le m \le 2^n - r$ is also valid for message $m' := m + r$. To avoid such a forgery, we'll have to enforce that: $m \in (0, r)$. That said, I think hashing doesn't necessarily guarantee this constraint (unless we ensure that the output of the hash function is truncated to bit-size less than the subgroup field bit-size). I should agree that this is more involved than I thought it was, see Yehuda's answer on crypto stackexchange.


Fix typo in custom-query-builder.md

Coverage remained the same at 97.061% when pulling 983bb4fc53e1896cead4fb5496fc5948e289cc26 on loteoo:patch-1 into ad9fa22c1f6ed0f894f85f9e04bdb94f8dc779ef on Vincit:master.

@loteoo Cheers!


Untracked file handling

The view private list needs requires some minor fixes:

add a view private file to that list if it gets opened and not already listed
the internal handling of the list requires some work

@OpenNingia  When do you plan to deliver an updated version of the extension?

next week, probably thursday (30/04)


Refactor dispatching transactions so "Reclaim all" keeps full precision

could you add a test for 9,999,999,999,999,999,999 shares
the APIs these come from, they all round, don't they?

Oh, we lose precision when parsing from API..

Will revisit in another year.


Added custom logger

We'll have fancy logs now

Also, this isn't strictly required, but it might be nice to add a success and debug logging options.

How do you mean

This is no longer needed as we're using loguru.


[Document-3268][doc] Update dinky_principle.png

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

close #3268


Pop modal from code?

Hi
I am trying to navigate from one modal to another in my user registration process and can't seem to get a modal to show from code? Is this possible?
I have tried:
rte.get('signup').toggleVisibility();
rte.get('template:modal/create-account').toggleVisibility();
rte.get('modal/create-account').toggleVisibility();

where rte is the controller of the 1st modal that has been popped.

I also noticed there is no way to pass params to the modal beinb popped from the template. Is that correct? If that is the case I will have a go at creating a PR

@wayne-o First, please use ember-idx-modal project.
You can toggle modal visibility through code, you can do it via the Close-If/Open-If params

@wayne-o U can pass params to the modal's template with standard property binding,
just do {{em-modal someProperty=foo}}

Appologies, I am using ember-idx-modal.
This doesn't really sit well with me - I'd like to have one modal which behaves differently depending on who was clicked - so ideally the configuration that goes into the modal would come from em-modal-toggler.
The modal I am popping needs to act a bit like a wizard:

open login modal

sign in with social auth

does user already have account?

yes: close modal
no: open registration modal setting "requiresPassword" false

So, the opening of the registration modal would need to come from the controller for the login modal.

Anyone able to help?


V2 to V3 fragment changes for http and access_log folders under test/..

Signed-off-by: Abhay Narayan Katare<EMAIL_ADDRESS>Commit Message: changes for http and access_log folders
Additional Description: V2 to V3 APIs fragment changes and forcing ParseFoofromV2Yaml for V3. this commit focuses on changes for http and access_log folders under test/common/..
Risk Level:NA
Testing: Unit and format testing
Docs Changes: NA
Release Notes:
[Optional Runtime guard:]
Optional Fixes #10843
[Optional Deprecated:]

@ankatare do you mind editing to a more descriptive title and description. Also looks like tests are failing?

/wait

@junr03 Hi, thanks for review. i updated details ( title and description ) as per suggestions. regarding test cases failing  in CI it seems environment issues in build. please help.

@junr03 i checked the code which is failing.  i have not touched it while working and also that test file "test/common/access_log/access_log_impl_test.cc"is passing in my local build. please suggest how to proceed here.

@ankatare do you mind merging master again? We have had some CI issues, but it should be resolved on master now.

@junr03  Sure , i will do it ASAP .  thanks for help.

@junr03 done. please review


*: add multi-namespace support to Prometheus Operator

This is a large PR broken into two logical commits that can be separate PRs if needed.
I have tested these changes on an Openshift cluster as part of https://github.com/openshift/cluster-monitoring-operator with several different configurations:

single namespace, i.e. --namespaces=x
multiple namespaces, i.e. --namespaces=x,y and --namespaces=x --namespaces=y
all namespaces, i.e. no --namespaces flag so v1.NamespaceAll is used

First:
This commit adds multi-namespace support to the Prometheus Operator. PO
now allows all informers to react to changes to multiple, individually
configured, namespaces, i.e. without specifying v1.NamespaceAll. This is
important for cases where the Prometheus Operator does not have
privileges to List all namespaces but should still administer multiple
namespaces. This capability is accomplished by abstracting the
cache.ListerWatchers for the various informers the PO uses.
Second:
This commit ensures that all informer caches are synced before the
eventhandlers are added. This is important whenever one informer's
eventhandler depends on the cache of a different informer. Without this,
eventhandlers will complain that certain objects don't exist. This is
important now that the namespace informer still runs for a single
namespace, where previously it was only run for v1.NamespaceAll.
Otherwise, e.g. the secret eventhandler could fail until the namespace
handler had synced.
cc @brancz @mxinden @s-urbaniak

@mxinden sure, let's add some e2e tests tomorrow :+1:

thanks for taking a look @s-urbaniak. Plz take another look when you can.

@s-urbaniak thanks for the thorough review!

lgtm :+1: nice work!


Restart controller/invoker by docker-compose tool does not work

Hi Openwhisk team, I tried docker-compose to build, deploy openwhisk locally and it works fine, however, when I tried restarting the controller or invoker by the command:
sudo make restart-controller
All docker containers are stopped and the cluster ended up with the following information:
xiaosuGW@node-0:~/openwhisk-devtools/docker-compose$ sudo make restart-controller
Stopping openwhisk_controller_1 ... done
Stopping openwhisk_apigateway_1      ... done
Stopping openwhisk_kafka-topics-ui_1 ... done
Stopping openwhisk_invoker_1         ...
Stopping openwhisk_kafka-rest_1      ...
Stopping openwhisk_kafka_1           ...
Stopping openwhisk_invoker_1         ... done
Stopping openwhisk_kafka-rest_1      ... done
Stopping openwhisk_redis_1           ...
Stopping openwhisk_minio_1           ...

It stucked here. I checked the Makefile and I cannot find any problems:
.PHONY: restart-controller
restart-controller:
        $(shell cat $(TMP_HOME)/tmp/openwhisk/local.env) docker-compose --project-name openwhisk stop controller
        $(shell cat $(TMP_HOME)/tmp/openwhisk/local.env) docker-compose --project-name openwhisk rm -f controller
        $(shell cat $(TMP_HOME)/tmp/openwhisk/local.env) docker-compose --project-name openwhisk up controller 2>&1 >> $(TMP_HOME)/tmp/openwhisk/docker-compose.log &
        echo "waiting for the controller to see the invoker is 'up' ... "
        until (curl --silent http://$(DOCKER_HOST_IP):8888/invokers | grep "up"); do printf '.'; sleep 5; done

Since it is waitting for invoker to start up, but it stopped, so it won't proceed any more. But I still don't understand why docker-compose --project-name openwhisk stop controller stops everything.

this can be resolved by https://github.com/apache/openwhisk-devtools/pull/262


[Game Crash] regression: startup crash on Linux since alpha 4.9.7 (Ubuntu 20.04 LTS, NVIDIA NVS 5100M)

Describe how it crashed by giving us those informations:

What you were doing before it crashed and what action made the game to crash.
didn't do anything: tried launching the game, crashes on startup

Upload the crashinfo.txt (GameFolder/crashinfo.txt)
didn't find crashinfo.txt anywhere

Upload the info.txt and log.txt (GameFolder/Logs)
I'll attach info.txt, log.txt and console output from 4.9.6 (no crash), 4.9.7 (first version that crashes) and 4.9.8 (still crashes)

no-crash-4.9.6-console-output.txt
no-crash-4.9.6-info.txt
no-crash-4.9.6.log.txt
crash-4.9.7-console-output.txt
crash-4.9.7-info.txt
crash-4.9.7-log.txt
crash-4.9.8-console-output.txt
crash-4.9.8-info.txt
crash-4.9.8-log.txt
Explain how we can reproduce the error

delete ~/.stepmania-5.3 folder, everything straight from the factory, no customizations whatsoever, "first startup ever"
Start the game
Game crashed

Sreenshots/Videos
I've included console output from 4.9.6 (no crash), 4.9.7 and 4.9.8
4.9.7 and 4.9.8 say this at the bottom:
Fatal: crash from within the crash signal handler
Fatal: crash from within the crash signal handler
Additional information
4.9.6 doesn't crash and works perfectly, 4.9.7 and 4.9.8 crash on startup.
I also tried explicitly only allowing opengl (not glad) and forcing high-res textures off, didn't help, can't think of anything else to try (if you have any suggestions, I'm happy to try them)
The laptop is old, from the year 2010 (HP EliteBook 8540p)
Ubuntu 20.04.2 LTS (Focal Fossa) (fully updated)
old NVIDIA GPU, "GT216M [NVS 5100M]" so probably this: https://www.techpowerup.com/gpu-specs/nvs-5100m.c1466
the driver package is nvidia-340 (340.108) (legacy, but the latest version I believe)
Linux kernel version 5.4.0-74-generic (nvidia-340 won't support anything after 5.4), x86_64

Hiya, thanks for the bug report!
We were having our annual leave break, so apologies for the delay in responding to your issue.
It looks like the Nvidia Driver is unable to create a window in 4.9.7/4.9.8, which is the source of the crash.
I'll have our linux developer do some testing on the fix i've written, and hopefully we can squash this annoying bug!

Thanks! If it helps, I can also try running test/debug builds. Just let me know if I can help somehow.

Are you able to join our discord?

Sure, I've joined there, just tell me what to do next! Can I message you there?

send a message to Squirrel in one of the channels, so i can see it, just ping me

I can't reproduce this crash anymore with 4.9.9HF, so this is fixed at least for me!

...just double-checked with 4.9.9HF2, no crash there either. Thanks for caring about old hardware!

Pretty sure this is fixed now. Please reopen if necessary. Thanks!


[question] how to use the system version

After choose a version using fin how can I roll back and start to use the system version?

You can (1) remove the selected version with: fin rm VERSION or
(2) use command node or command npm.

fin rm VERSION will uninstall or will remove the node from PATH ?

It will remove it from the configuration so that both the node and npm shims can't find it, so you'll get the system version (if there is one).
Note that downloaded versions are always available in the cache too, so re-installing takes less than half a second.

@robsonpeixoto Can we close? :)

Yep @bucaran. But I prefer a command fin system to disable the shim.