If I use the vault name when defining an item, and rerun terraform, it wants to recreate the item as it has a diff with the vault name versus vault UUID

Terraform 1.7.4
Provider 1.4.2
OnePassword CLI 2.25.0
I use this code:
resource "onepassword_item" "item" {

  vault = "example-vault"

  category = "login"
  username = "mylogin"
  password = "mypassword
}

This works, but when I rerun an apply it says the resource must be replaced and shows this as a diff.
~ vault    = "khubz3ahotlrg2ze2xveqkijhy" -> "example-vault" # forces replacement
To fix this I must use the vault UUID rather than the vault name when creating the resource.
I should be able to use the vault name OR the vault UUID and not get a diff.

Closing this as a duplicate of #131.


[RIP-9] Add API_Reference_Python.md for Python

What is the purpose of the change
Python API Reference
Brief changelog
Add API_Reference_Python.md for python
Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

@ShellPaul it would be nice if you can pull this request to rocketmq-client-python repo, and as this PR has been no longer active for several months，so I will close this PR temporarily, please feel free to reopen it.


Remote debugging: error connecting via Kubernetes port forwarding with a secret

I have a Python Web server with the following statement:
ptvsd.enable_attach(None, address=('<IP_ADDRESS>', 3000))
I deploy the Web server to a Kubernetes cluster, and set up port forwarding for port 3000:
kubectl port-forward pythonmeup-805807444-x9hx2 3000:3000
I can then attach to the remote process via localhost:3000, in my case from Visual Studio Code, and it all works great.
Now I change the enable_attach to include a secret (and redeploy to Kubernetes):
ptvsd.enable_attach("my_big_secret", address=('<IP_ADDRESS>', 3000))
and add that secret to my VS Code configuration ("secret": "my_big_secret"), I can no longer attach to the remote process via the forwarded port - when I try, the port forwarder reports this error and the debug adapter process terminates:
C:\Users\itowlson>kubectl port-forward pythonmeup-805807444-7kr31 3000:3000
Forwarding from <IP_ADDRESS>:3000 -> 3000
Forwarding from [::1]:3000 -> 3000
Handling connection for 3000
E0308 16:37:32.196247   21836 portforward.go:314] error copying from local connection
to remote stream: read tcp4 <IP_ADDRESS>:3000-><IP_ADDRESS>:64876: wsarecv: An existing
connection was forcibly closed by the remote host.

I realise this may be a Kubernetes issue, but it seems like Kubernetes is just tunnelling the ports, and it works when there is no secret.  What part of the attach protocol might be breaking due to the presence of a secret?  Is there anything I need to set up in the server environment or the port forwarding options to allow the use of a secret?

There shouldn't be. Though if you're using VS Code then you may need to ask on their issue tracker rather than ours - while we are responsible for ptvsd, we don't currently test against VS Code, and their configuration may do something different.
Alternatively, if you test using Visual Studio 2017 and it's still a problem, we can try looking into it. But the secret is just passed through as data (insecurely, I might add, but probably good enough for most uses), so there shouldn't be anything special.

@zooba Thanks Steve. I can confirm that it works fine in Visual Studio 2015 (haven't tried with 2017 but sure it won't be any different).  So this is definitely something to do with the way either I have configured VS Code, or the way VS Code (or the Python extension for it) attaches the Python debugger to the remote process.  I'll investigate further and update the issue if I find a resolution.


FW-2057 Add Statistics Endpoint

Definition of Done

[ ] Reviewer can follow the flow of the code
[ ] Variables, methods are named properly and clearly
[ ] Methods are documented using comments (where not self-explanatory)
[ ] Any suggestions for refactoring have been implemented
[ ] Tests are created and cover at least 85% of the functionality
[ ] Code is unlikely to introduce new regressions
[ ] Acceptance criteria has been met

(please wait with merge until after 3.5.5 is released)


Replace OR with AND operator

Changed the operators in flexboxIE.js and flexboxOld.js
The issue with the 'OR' operator is that it will create issues in pages which does not have a display property.
Changing the OR operator with AND will do the work.
Closes https://github.com/rofrischmann/inline-style-prefixer/issues/70

@rofrischmann : I do not understand the reason for the tests failure. Could you guide me ?

@tintin1343 Heyhey, just check out the issue again :) I ve posted something about it.
To validate my fix you could add this to the tests:
Current tests
describe('Prefixing display', () => {
  it('should not remove display property', () => {
    expect(new Prefixer({ userAgent: MSIE10 }).prefix({
      display: 'block'
    })).to.eql({ display: 'block' })
  })
})

New tests
describe('Prefixing display', () => {
  it('should not remove display property', () => {
    expect(new Prefixer({ userAgent: MSIE10 }).prefix({
      display: 'block'
    })).to.eql({ display: 'block' })
  })
  it('should not throw if display is null or undefined', () => {
    expect(new Prefixer({ userAgent: Chrome45 }).prefix({
      display: null
    })).to.eql({ display: null })
    expect(new Prefixer({ userAgent: Chrome45 }).prefix({
      display: undefined
    })).to.eql({ display: undefined })
  })
})

@rofrischmann : Ok. I saw your comment on the issue. Let me make the necessary changes and edit my pull request.

Alright thanks a lot! Tests seem to pass now :P The only reason for the failed status is actually an issue with codeclimate which I am not sure how to fix right now.

@rofrischmann : Cool. I was wondering why that was happening when my npm test passed. You are welcome.

Does the prefix-all package also need part of this patch?

@necolas Actually it should work for your usecase as far as I know you do not have null or undefined values right? Still I will add this right away.

@necolas https://github.com/rofrischmann/inline-style-prefix-all/releases/tag/1.0.2 here we go. I actually could remove this display check at all as we already use the full flex plugin :P


Run Error

I have an error when I'm trying to build:
user@user-HP:~/Downloads/atom$ script/build

fatal: not a git repository (or any of the parent directories): .git

/home/user/Downloads/atom/script/lib/spawn-sync.js:17
      `Command ${result.args.join(' ')} exited with code "${result.status}"`
                             ^

TypeError: Cannot read property 'join' of undefined
    at module.exports (/home/user/Downloads/atom/script/lib/spawn-sync.js:17:30)
    at computeAppVersion (/home/user/Downloads/atom/script/config.js:89:20)
    at Object.<anonymous> (/home/user/Downloads/atom/script/config.js:24:28)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)

I just download it from Github. I didn't make any change to the project, locally.

me too

@mojombo @NikolaTesla13 @defunkt @caged


Corbett/formatting

Switch to using "snake_case" everywhere. Closes #17

@mtfishman not sure you really want to look at all my fun search-and-replace changes, but thought I'd ping you.

Looks good to me, thanks.


[FAKE TEST] Having build issues on Windows

When running cargo build on Windows, the tarball does not work. Please fix by not cloning the static tree sitter query every time.

Just testing https://github.com/apps/issuedigger .


Add check_extractable argument to high_level.extract_text

Is your feature request related to a problem? Please describe.
When using pdfminer.high_level.extract_text on some files, I get pdfminer.pdfdocument.PDFTextExtractionNotAllowed: Text extraction is not allowed
Describe the solution you'd like
Add a keyword argument check_extractable to pdfminer.high_level.extract_text, and pass it to PDFPage.get_pages

Is it possible for you to give us a sample PDF so we can reproduce this issue?

asw_oct06_p33-41.pdf

Hi all,
I am against adding the check_extractable() parameter to the high-level functions extract_text() and extract_text_to_fp(). I think these function signatures are already bloated, especially extract_text_to_fp().
The high-level functions (should) cover the most common use-cases. Changing the check_extractable flag is not imho a common use-case. Instead, you should use the more adaptable composable api instead. Also see the (currently minimal) docs for this.
In your case, I recommend something like this:
from io import StringIO

from converter import TextConverter
from layout import LAParams
from pdfinterp import PDFResourceManager, PDFPageInterpreter
from pdfpage import PDFPage

layout_parameters = LAParams()

with open('asw_oct06_p33-41.pdf', "rb") as fp, StringIO() as output_string:
    resource_manager = PDFResourceManager()
    device = TextConverter(resource_manager, output_string,
                           laparams=layout_parameters)
    interpreter = PDFPageInterpreter(resource_manager, device)

    for page in PDFPage.get_pages(fp, check_extractable=False):
        interpreter.process_page(page)

    print(output_string.getvalue())

You could even wrap it as a function.

Of course rewriting the high level extract_text myself with check_extractable=False would suit my needs, but I think that if adding an argument is a problem, a more reasonable default for the high level extract_text would be to work even on pdfs like the attached one.
Also, I think we might want to streamline the parameters of extract_text and extract_text_to_fp (and remove its unused kwargs parameter)

Of course rewriting the high level extract_text myself with check_extractable=False would suit my needs

Great! I'm closing this issue and the corresponding PR, let me know if you disagree.

but I think that if adding an argument is a problem, a more reasonable default for the high level extract_text would be to work even on pdfs like the attached one.

A PDF is not extractable if the document itself signals that it is not allowed to extract the content if opened with user-level permissions. In my opinion, we should respect the choice of the application that created the PDF, and consequently check_extractable=True is a great default.

Also, I think we might want to streamline the parameters of extract_text and extract_text_to_fp (and remove its unused kwargs parameter)

I agree! The function signature of extract_text_to_fp is been around for long and changing it would be a breaking change. The extract_text() function is only recently created, and its arguments are much more concise and understandable.
If this bothers you, you can create a new issue for this. We could deprecate the use of extract_text_to_fp and create some new  methods.

I kind of disagree on closing this, as the main purpose of the high level API is to extract text from pdfs and in my tests pdfs that raise PDFTextExtractionNotAllowed are not that rare (happened to both me and another user).
But it's not a big of deal as it's easy to rewrite the high level api
I would argue that laparams, codec and caching and maxpages are all less useful parameters (especially the last one as a user can just specify a range of pages)

Then I will reopen this. Lets see what others think.

While I think that the high level functions should be a no brainer to use in most situations, where you just pass the file and it extracts the text without problems, I do think that we should adopt some sane defaults that would at least throw a warning about something as a PDF not meant to be extractable.
Passing another parameter to a method that is meant to be simple doesn't sound right to me, so maybe we should just change check_extractable's default to False and issue a warning of some kind, since people will want to extract its contents anyway.

I would agree with the warning

I like it too.
In summary:

Set the default value for check_extractable to False.
If check_extractable is True we throw an Error, if False we raise a warning.
Remove the explicit arguments for check_extractable from the high_level module.

As an alternative; we could also drop the check_extractable argument completely and always raise a warning. Ignoring them can be done with the warnings module.

As an alternative; we could also drop the check_extractable argument completely and always raise a warning and never an error.

I really like that.

Encountered this too
Or just make a ignore flag, there's many tools that ignore this, hell even opening the .pdf in firefox allows me to copy the text of protected .pdf's

@Filip98, if you feel like creating a PR, I'll make sure that it gets reviewed and merged.

Can't believe this problem still exists.
In my opinion, some users have suffered for this problem. There are also some discussion on stackoverflow.
I mean, "add an optional argument" is simple and doesn't have any bad effect on old codes.
I agree with the optional argument, check_extractable.

Hi @HeroadZ, feel free to work on this. I can review, merge and publish the code.

You can still merge #351

Encountered this error today causing me to redo a batch job :<
Submitted this PR #453  to change the error to a warning with a descriptive message to the user.

Hi @madhurcodes, thanks for your work on this. I'll review the PR.


Print HtmlErrorReport location

Fix #592

Codecov Report

Merging #612 into master will increase coverage by 0.05%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #612      +/-   ##
============================================
+ Coverage     76.25%   76.31%   +0.05%
- Complexity      605      606       +1
============================================
  Files            81       81
  Lines          2283     2284       +1
  Branches        324      324
============================================
+ Hits           1741     1743       +2
+ Misses          325      323       -2
- Partials        217      218       +1


HRW: Adds an optional list of query params to remove/keep

This also adds the [I] / [INV] modifier to operators, where the logic should be INVerted. In this case, inverted means "remove all but the listed query parameters".

I'm adding this to Project 10.0.x, but I think this would be fine to go into v10.1.0 as well.

[approve ci rocky]
[approve ci autest]

[approve ci rocky]

[approve ci]

[approve ci autest]

[approve ci autest]

[approve ci autest]

@shukitchan I'm going to make a small change to the tokenizer, I think swoc::TextView has a more powerful mechanism here. I'll have it done tonight or tomorrow.

[approve ci autest]

[approve ci autest]

[approve ci autest]

Cherry-picked to v10.0.x


Influx writer

Hi, maybe that code is of interest for somebody else as time series logging. feel free to decline the proposed example

Again, thanks! I agree this is a useful addition for many people. I've added your script with a few minor changes and additions as example_influxdb.py.


chore(reth-storage-errors): no_std support

Towards #9478
Adds no_std support to reth-storage-errors.
Stacking PRs no longer necessary as implementing source for errors wrapped in error enum variants fixed the issues that were breaking tests.

Whoops I was trying to pull latest changes since this branch fell so behind.... maybe I should have done git pull -> merge main into my branch instead of rebase?

@mattsse I think this is good to go if you could please take a look when you get a chance


Expand heapster metric backend to expose all available metrics

Currently heapster exposes cpu, memory and network stats. It needs to expose filesystem, diskio and container load stats. More details on the metrics can be inferred from the cadvisor API here

Exposing filesystem usage and network usage of pods is required for v1.0. The rest can be added post v1.0


Exposing very hacky Wasm httplib replacement

Idea is for wasm_httplib_replacement.hpp (or a less hacky version of it) to be part of duckdb/duckdb for 1.2, and expose a subset of HttpLib interface.
This will not, as of now, work in DuckDB-Wasm + node, I have the code also there but this is good enough to get started.
This is a simpler problem than https://github.com/evidence-dev/duckdb_gsheets/issues/35, where a slightly more complex API needs to be mocked.
I have tested this in limited ways locally, and error detection / handling should likely improve (HandleHttpError just do nothing).
Demo:

Note that CORS is not correctly set up on gist.github.com, BUT there is a mirror with CORS enabled.
Once this is merged and in community extensions,
INSTALL webmacro FROM community;
LOAD webmacro;
SELECT load_macro_from_url('https://gist.githubusercontent.com/lmangani/518215a68e674ac662537d518799b893/raw/5f305480fdd7468f4ecda3686011bab8e8e711bf/bsky.sql') as res;
SELECT * FROM search_posts('qxip.bsky.social', text := 'quack');

Should work (but not the query on the readme)
But
SELECT load_macro_from_url('https://gist.github.com/lmangani/518215a68e674ac662537d518799b893/raw/5f305480fdd7468f4ecda3686011bab8e8e711bf/bsky.sql') as res;

will crash badly (since failures are not handled), let me fix it.

Too late, anyhow, can also go in a separate PR, basically something need to be thrown in HandleHttpError, I will send a PR in a bit.

Sorry I saw the tests complete and merged! Ready for the next PR and halted the community update until then

I updated the readme example as suggested with githubusercontent


e2e org page test

Adds e2e tests for org page

@bcaton85 Looks like the repository list tests are failing - they're using different mock data than what I see with MOCK_API=true. Any thoughts on how to get npm run start:integration to use MOCK_API=true?

MOCK_API: true is already set in the CI here. What is the difference in data that you are seeing?


Runtime errors have the wrong line numbers.

Repro instructions: Go to the reverseWords problem, and type the code seen in the screenshot below.
Observed behaviour: Runtime errors have the wrong line numbers. For example, in the screenshot below, the error is shown as being on line 15, whereas the actual error is on line 3.
Expected behaviour: The error message should show the correct line number.

Fixed in #57


NuGet Installer Task - App is not compatible with monoandroid81 (MonoAndroid,Version=v8.1). Project App1 supports: netstandard2.0

Source - TFVC
Pipeline : Hosted VS2017
Issue Description
Xamarin.Android Build Task fails with following errors. Seems The task try to compile the Portable app (.Net standard) using the Target platform of Native app (Android/iOS).
Project App1 is not compatible with monoandroid81 (MonoAndroid,Version=v8.1). Project App1 supports: netstandard2.0 (.NETStandard,Version=v2.0)
One or more projects are incompatible with MonoAndroid,Version=v8.1.
Project App1 is not compatible with xamarinios10 (Xamarin.iOS,Version=v1.0) / win. Project App1 supports: netstandard2.0 (.NETStandard,Version=v2.0)
One or more projects are incompatible with Xamarin.iOS,Version=v1.0 (win).
Task logs

[Enable debug logging and please provide the zip file containing all the logs for a speedy resolution]

Task Warnings
and also I have following warnings..
[warning]Can't find loc string for key: Info_ResolvedToolFromCache
[warning]Can't find loc string for key: Info_UsingVersion
Error logs
log_8_15814.zip
Can you please explain what is the issue ?

Hi, the logs show this is not an issue in Packaging (all responses to restore are OK), but rather an error in the compatibility check after downloading the packages. The warnings are also not related to the failure in the compatibility check. Removing Area: Packaging label.
Unfortunately, my team doesn't have much expertise building for Android, so we can't provide much guidance here. From what I know, the framework that NuGet should restore for should be inferred from the project's target (in this case the frameworks targeted by App1.Android.csproj and App.UITest1.csproj). It would be strange if these are not specifying MonoAndroid v8.1 as the target, yet NuGet is attempting to restore packages for it, but I'm not familiar enough with this to say if this is actually unexpected.
My suggestion is to take this issue to the NuGet team; it looks like a similar question has been answered in that area before: https://stackoverflow.com/questions/50905545/xamarin-android-package-xx-is-not-compatible-with-monoandroid81-monoandroid-ve


Ibzrx iooki migrate

Do you want to keep anything from this PR still since we decided not to migrate to iOOKI? @RomanHiden


Support for CDRV resources?

there's one in:
https://macintoshgarden.org/apps/finderhack
they seem to be code resources.

I suspect CDRV is a nonstandard alias for DRVR - the code in INIT 10 looks like it just copies the contents of the CDRV to an allocated block in the system heap, then calls DrvrInstall on it. I've added an alias in resource_dasm anyway, so it should now disassemble just like a DRVR.

It should work if you build from master; I didn't build a new release (yet). In the meantime, you should be able to get CDRV disassembly by using the option --copy-handler=DRVR:CDRV (which is essentially what my change does).


java: Simplify complexity of atomic copies by ensuring sync

Description
Title says it all
How Has This Been Tested?
CI

What was the motivation for this PR? Have we encountered any problems with the current libap copy?

What was the motivation for this PR? Have we encountered any problems with the current libap copy?

I saw some errors in a log of one of the profiler. Stuff like:
FileExistsError: [Errno 17] File exists: '/proc/1/root/tmp/gprofiler_tmp/async-profiler-v2.6g1/glibc.5596' -> '/proc/1/root/tmp/gprofiler_tmp/async-profiler-v2.6g1/glibc'

too much complexity for no good reason. It's been a while that I wanted to get rid of this code lol.


DBZ-3918 Update RELEASING.md to current process

closes https://issues.redhat.com/browse/DBZ-3918

@gunnarmorling you mentioned changes on development_docs branch process. I didn't do the manual release so can you give me a small hint what needs to be changed in these paragraphs?

@rk3rn3r, re "development_docs", we used to push the docs for the release currently under development to that branch, but that's no longer the case. So any reference to this branch should be removed.

@gunnarmorling so instead of development_docs we now use normal PRs to the develop branch?


Requirements & Dependencies

Hello,
In order to run the code and reproduce results, one would need the specific package versions you used for the development and experiments.
Could you provide requirements.txt or some other specification of the packages and version?
In the README the dependencies appear to be underspecified. Especially with regards to the Tensorflow version 1.12.0, the required packages are crucial.
Thank you in advance.

Upvote. Requirements are crucial.

Sorry about that. Now requirements.txt is included


Add octocat-rs to Rust libraries

Why:
Closes #16360

What's being changed:
Octocat-rs is being added to the table of Rust API libraries available for GitHub's REST API.

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@proudmuslim-dev
Thanks so much for opening a PR! I'll get this triaged for review :zap:

@proudmuslim-dev Thanks so much for opening a PR! I'll get this triaged for review ⚡

No problem, thanks :)

Awesome, thanks!


transformix usage

Hello,
I would like to ask you some specific doubt about using transformix.
I have a set of points that define a high-resolution field of view of a specific region on my fixed image and my goal is to determine the "correspondent" field of view coordinates in the moving image. After running elastix in a coarse-to-fine mode by increasing resolutions i run:
transformix -def [file with 16 index coordinates defining the FOV of the fixed image] -out [directory] -tp [final transformation file of the above explained workflow]
Am I doing it right? Or should the -def file include index coordinates of the moving image in order to correspond the fixed image?I am asking this because even changing drastically or not my parameter files during the registration workflow the correspondence obtained seems to be quite bad.
Sincerely,

You are doing it right. The transformation is defined from the fixed image to the moving image (see section 2.6 in the manual), so points are warped from the fixed to the moving image. Make sure the file has "index" and not "point" in the first line as you are specifying index coordinates.
Anecdotally, I have always given transformix points in world coordinates. I have found this to be more robust and easier to debug when something goes wrong.


Kyuubi-1.6.0 not supported

./aio/Dockerfile on line 89: Kyuubi 1.6.0 should be changed to Kyuubi 1.6.1 since the old version is not downloadable anymore.

I've fixed this in the main branch. Thank you, Peter!


Sans IO version

Add InHstsPreload and CachedInHstsPreload classes
Add in_hsts_preload_async function

Some notes:

There is a new python file : hstspreload/lrucache.py
In test_hstspreload.py, the test_in_hsts_preload function checks the sync and async functions to avoid two calls to load_test_cases
_in_hsts_preload_cache leaks the case outside the package, it was not the case before.

Going to close this due to inactivity.

Sorry it was not clear in my initial message : what had stopped me is the asyncio version.

f = await loop.run_in_executor(executor, _open_data) seems not right.
the only reasonable way seems to include a dependency to aiofiles  ?

In this case, the dependency has to be added, but may has to be optional ?
( moreover the code seems to complicated for it is dealing with )


ship docker container with git

Tested locally.  Fixes auto refresh site listing issue on the dashboard.

fixes #435


Add conditional macro to support encodeIfPresent and decodeIfPresent

Hey @jordanekay 👋 Thx for your contribution. Everything looks fine, but I'd like to ask you to also update the existing unit tests to make sure the macro works correctly with everything that's already there. You can leave updating the README.md to me.


Address serialization in PayForBlobs event

Summary of Bug
In celestia.blob.v1.EventPayForBlobs, the signer address is represented incorrectly:

It does not match the signer address in the corresponding PayForBlobs message
It is a string containing quotes, which is not how addresses are usually represented in messages
It is an invalid address format

For example take this transaction. In the event, the signer is: "celestia1vdjkcetnw35kzvtpwye8gdtvxfu8jcmh8y685emcvuenydekxp5rj6mxx36ksctn0y6rywfswahq0lqt35". This is has quotes and too long to be a valid address. By contrast, in the message, the address is represented as celestia1aq2t5l2xycw94zgxg32760h9kf4uhasy4290wn.
Version
v1.1.0
Steps to Reproduce

Visit https://celestiascan.com/mocha/transaction/e38d16712833ba89de7b37d269a92215528e62b6ceabd31c55090821e949f491 and click the source data icon in the top right (or just use this link: http://consensus-full-mocha-4.celestia-mocha.com:26657/tx?hash=0xe38d16712833ba89de7b37d269a92215528e62b6ceabd31c55090821e949f491)
Find the EventPayForBlobs in the events

{
                    "type": "celestia.blob.v1.EventPayForBlobs",
                    "attributes": [
                        {
                            "key": "YmxvYl9zaXplcw==",
                            "value": "WzEyMzI5Ml0=",
                            "index": true
                        },
                        {
                            "key": "bmFtZXNwYWNlcw==",
                            "value": "WyJBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQWVOSTllb2gvN3dWSHM9Il0=",
                            "index": true
                        },
                        {
                            "key": "c2lnbmVy",
                            "value": "ImNlbGVzdGlhMXZkamtjZXRudzM1a3p2dHB3eWU4Z2R0dnhmdThqY21oOHk2ODVlbWN2dWVueWRla3hwNXJqNm14eDM2a3NjdG4weTZyeXdmc3dhaHEwbHF0MzUi",
                            "index": true
                        }
                    ]
                }

Decode the last entry from base64
Key: signer
Value: "celestia1vdjkcetnw35kzvtpwye8gdtvxfu8jcmh8y685emcvuenydekxp5rj6mxx36ksctn0y6rywfswahq0lqt35"
Find the correct signer address in the message:https://celestiascan.com/mocha/transaction/e38d16712833ba89de7b37d269a92215528e62b6ceabd31c55090821e949f491/messages (celestia1aq2t5l2xycw94zgxg32760h9kf4uhasy4290wn)

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Thanks for identifying and providing clear repro steps! This does look like a bug. I added these lines prior to here
	signer := msg.Signer
	eventSigner := sdk.AccAddress(signer).String()

	ctx.Logger().Info(fmt.Sprintf("[debug] signer %v\n", signer))
	ctx.Logger().Info(fmt.Sprintf("[debug] eventSigner %v\n", eventSigner))

and it results in
1:53PM INF [debug] signer celestia15drmhzw5kwgenvemy30rqqqgq52axf5wwrruf7
1:53PM INF [debug] eventSigner celestia1vdjkcetnw35kzvf4v3ex66r6wu6kkam8v4h8vetd0yenqun3w9ckwuf4xfshse34wamhyun4vcmsgysde8

This bug has existed since the event was first introduced here.


Usage of literal_matcher_from_pattern requires lazy_static

Using the macro literal_matcher_from_pattern! requires adding lazy_static to Cargo.toml in the consuming crate.
If I understand this stack overflow answer correctly this can be fixed by exporting lazy_static (maybe with #[doc(hidden)]?) and refer to it via $crate::lazy_static::lazy_static.

Good catch. Same for regex.


Fixes metamorphic glasses

About the PR
Metamorphic glasses are supposed to change their appearance, name and description based on the reagents inside them. At the moment, only the appearance change actually works.
This makes metamorphic glasses properly change their name and description. Additionally, the drinks that spawn around the station are proper metamorphic glasses now and no longer retain their filled sprite no matter what.
I am entirely uncertain whether the way I made this work is shitcode or not.
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl: Sigil

fix: Metamorphic glasses now properly change their names and descriptions when filled.
fix: The drinks that spawn around the station at roundstart are now proper metamorphic glasses and can change appearance.

Dupe https://github.com/space-wizards/space-station-14/pull/16550 ?

Dupe #16550 ?

Huh. Shit. I completely missed that.

Right then, I'll wait for that one to get merged and then make the fix for roundstart drinks.


[Hub Generated] Review request for Microsoft.SqlVirtualMachine to add version preview/2017-03-01-preview

If you are a MSFT employee you can view your work branch via this link.
Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

@sarangan12 One of the checks is failing because it does not recognize words from different swaggers - and the word BYOL from our CLI. This is an expected acronym, BYOL (Bring your own license).
Could you help us merging this code to start the publishing process from openApiHub?

@yareyes I am fine with the changes. But please be aware that these are breaking changes and thus needs an ARM review. Added the label for that.

The only property that is changed is sqlImageSku, which is now made 'writable'.
As it is not a required property, this should be fine. Not a breaking change.

@sarangan12 could we please merge this PR?


Adjust XCTest integration such that xctool finds Cedar specs

I'm hoping to play with this a little more to get more confidence in this change, but this seems to be a simple way to get to xctool find and execute Cedar specs. It turns out that xctool calls +[XCTestSuite allTests] when gathering the available tests. This method isn't in the public interface, but is what +[XCTestSuite defaultTestSuite] delegates to for doing all its work.
CC folks involved in #308 and facebook/xctool#417 - please give this a try!
@parse @haskelash @adamhrz

I tried this out on my current project, and it seems like it totally works.

Thanks for taking the time to test this out @pivotal-ryan-mcleod. I've merged this into master now!


Settings which are dynamically configurable

Allows to switch between mainnet and testnet with cli arguments. Might also be useful for further settings in the future.
Several files were touched, but mainly just the import changed from from neo import Settings to from neo.Settings import settings. The real changes are using a class in Settings.py, and adding cli args to prompt.py.

Coverage increased (+0.2%) to 48.525% when pulling c9585355cfe275bc2aa528e01dd8f28ac6b53880 on metachris:feature-settings into 3a4833900e37dad6f7991b344f989177aed23b6d on CityOfZion:feature-settings.


cachix,hercules-ci-{agent,cnix-expr,cnix-store}: bump nix pin to 2_11

cc. @domenkozar @roberth

cachix: pin to nix_2_11
hercules-ci-{agent,cnix-expr,cnix-store}: pin to nix_2_11

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 208233 run on x86_64-linux 1

3 packages failed to build:

cachix
hci
hercules-ci-agent

Cachix failed to build with the error:
> Setup: The pkg-config package 'nix-main' version >=2.4 && <2.11 is required
> but the version installed on the system is version 2.11.1

It seems Cachix's cabal file is out of sync from cnix-store's. I am waiting for a new release of cnix-store to bump to 2.12 and then do the same for Cachix.

I've released Cachix 1.2 that doesn't pin Nix anymore.

I've released Cachix 1.2 that doesn't pin Nix anymore.

Are you waiting for a new haskell-updates PR or will you be overwriting the src? As that will tell me whether I need to use doJailbreak in the meantime.

Result of nixpkgs-review pr 208233 run on x86_64-linux 1

3 packages built:

cachix
hci
hercules-ci-agent

Build failure on x86_64-darwin does not occur on my mac builder, so it is not caused by this pr.

Thanks @Kranzes

@domenkozar :ninja:

I encountered this error when using nix.override:
  nixpkgs.overlays = [
    (self: super: {
      nixVersions.stable = super.nixVersions.stable.override { withAWS = false; };
    })
  ];

Error:
error: attribute 'nix_2_12' missing
   at /home/home/works/nixpkgs/pkgs/development/haskell-modules/configuration-nix.nix:886:27:

      885|   hercules-ci-cnix-store = (super.hercules-ci-cnix-store.override { nix = self.hercules-ci-cnix-store.passthru.nixPackage; }).overrideAttrs (_: {
      886|     passthru.nixPackage = pkgs.nixVersions.nix_2_12;
         |                           ^
      887|   });

(use '--show-trace' to show detailed location information)

How can I fix error?

Found vorking variant:
  nixpkgs.overlays = [
    (self: super: rec {
      cachix = super.cachix.override { inherit nix; };
      nix = super.nix.override { withAWS = false; };
    })
  ];

{
nixVersions.stable =

This is the same as nixVersions = { stable = ...; }, which removes the other versions.
When doing overrides in a nested attribute set, do something like nixVersions = super.nixVersions // { stable = ...; }

I now have this variant:
  nixpkgs.overlays = [
    (self: super: {
      cachix = super.cachix.override {
        nix = pkgs.haskellPackages.hercules-ci-cnix-store.passthru.nixPackage.override { withAWS = false; };
      };
      nix = super.nix.override { withAWS = false; };
    })
  ];

When change the nix version to 2.13 cachix builds with nix version 2.12. I couldn't making a simpler variant of it.

You should override haskellPackages to make sure it's updated in all places. Also 2.13.1 still has a known regression.

You should override haskellPackages to make sure it's updated in all places. Also 2.13.1 still has a known regression.

I only tested the overlay. And I checked it in cachix using show-derivation, overlay is working - used nix 2.12.


LoLin NodeMCU V3 ESP8266 requires header patching

Greetings developers & contributors.
Header patching was removed(https://github.com/NabuCasa/esp-web-flasher/pull/86/commits/598c55678366b2e91445f52789af64068f2679fa) as it was perceived to be useless for ESP32 boards but ESP8266 boards like LoLin NodeMCU V3 uses 26MHz crystal(Including latest ones) and so without header patching the flashing results in reset loop when using esp-web-tools.
Allowing user to set the right flashing mode is perhaps the correct way to go regarding this, But for that to happen esp-web-flasher needs to accept the parameters and execute the patching as it was in version 4.0.0 and prior. Then esp-web-tools could possibly call esp-web-flasher with the correct flashing mode(https://github.com/esphome/esp-web-tools/issues/186) from user input.
Considering ESP8266 continues to be most accessible and affordable development board and its likely to remain that way for next few years due to semiconductor shortage & shipping issues; I think accepting flashing mode from user would be a valuable addition.

This is how ESPTool is currently detecting the crystal frequency (https://github.com/espressif/esptool/blob/ded13e025628d4c5ca350378b391e9b0d38bcb57/esptool.py#L1223),
    def get_crystal_freq(self):
        # Figure out the crystal frequency from the UART clock divider
        # Returns a normalized value in integer MHz (40 or 26 are the only supported values)
        #
        # The logic here is:
        # - We know that our baud rate and the ESP UART baud rate are roughly the same, or we couldn't communicate
        # - We can read the UART clock divider register to know how the ESP derives this from the APB bus frequency
        # - Multiplying these two together gives us the bus frequency which is either the crystal frequency (ESP32)
        #   or double the crystal frequency (ESP8266). See the self.XTAL_CLK_DIVIDER parameter for this factor.
        uart_div = self.read_reg(self.UART_CLKDIV_REG) & self.UART_CLKDIV_MASK
        est_xtal = (self._port.baudrate * uart_div) / 1e6 / self.XTAL_CLK_DIVIDER
        norm_xtal = 40 if est_xtal > 33 else 26
        if abs(norm_xtal - est_xtal) > 1:
            print("WARNING: Detected crystal freq %.2fMHz is quite different to normalized freq %dMHz. Unsupported crystal in use?" % (est_xtal, norm_xtal))
        return norm_xtal

I don't have enough knowledge to understand how crystal speed comes into play with flashing.

Okay I will try to study that and clarify what's really happening with the crystal frequency and the flashing modes.
But regardless of the deeper relationship, isn't getting the flashing mode as a parameter from esp-web-tools and then passing to the function which were existing earlier a straightforward fix?

We don't want to ask the user about the crystal speed of their device, it should be automatically detected.
ESP Web Tools and ESP Web Flasher shouldn't do any header patching anymore. The developer putting up the website with ESP Web Tools should create the correct firmware versions. ESP Web Tools does the selecting based on data provided by ESP Web Flasher.
It could probably become a new property for the builds specified in manifest.json such that ESP Web Tools can detect crystal speed and select a different build if a 26Mhz build is available.

I respectfully disagree, I think the  'Flashing mode' should be handled by the 'flashing tool' and not the 'firmware compilation' tool and hence both ESPTool & Adafruit's ESP tool does the patching.

The developer putting up the website with ESP Web Tools should create the correct firmware versions.

I don't think that's even possible, If so esp-sdks which compiles the firmware would have done that and wouldn't be handled during flashing like I mentioned above.
I think this was not brought before in earlier discussions on this subject(https://github.com/NabuCasa/esp-web-flasher/issues/83, https://github.com/esphome/esp-web-tools/issues/151) because the users were using ESP32 and the current default flashing mode works for them i.e. No one is supplying different firmware versions based on the crystal now.

Maybe I misunderstand, but this is not about 'flashing mode' but about flashing the correct bootloader?
ESP Web Flasher has no knowledge if something is a bootloader. It just flashes what it is told to flash. It's up to the tool using ESP Web Flasher to provide the right files (in your case ESP Web Tools).
Now ESP Web Tools doesn't generate/patch any files either but instead relies on the manifest file to point at the right data for each ESP variation.

The misunderstanding is because unlike ESP32, the bootloader is not flashed separately(it's not a multi-stage) for ESP82666(It's a single firmware.bin as  in the manifest for ESP Web Tools) and header patching 4th byte to 0x20 was done to set the 'Flashing Mode' to DIO and 'Flashing Speed' to 40 Mhz(40m).
More information about the flashing modes can be found here and here.
During the earlier discussion(https://github.com/NabuCasa/esp-web-flasher/issues/83)  @TD-er raised concern that removing header patching could affect ESP82666 boards but wrongly concluded that all ESP boards after 2017 doesn't use this flashing mode as they don't contain 26 MHz crystal;  That might be the case with ESP32 but not with ESP8266.
My board uses the latest revision of ESP8266 i.e. ESP8266EX so it's likely that removal of header patching prevents all recent ESP8266 boards from being flashed by esp-web-flasher.

I have not seen ESP8266 boards using a crystal other than 26 MHz (as far as I can remember), so building for 26 MHz crystal should work on (almost?) all boards out there.
This can be set in the IDE or PlatformIO when selecting the board. (or define your own config where you explicitly set the xtal freq. to 26 MHz)
I am not entirely sure whether the web flasher should patch it, but on the other hand esptool.py and the Espressif download tool patch it. (Espressif download tool has a flag to no change the bin to disable this)
Do you have an example of an ESP8266 board that does have a crystal other than 26 MHz?

Now esp-web-flasher being a flashing tool as well, In theory one might expect it behave similar to Espressif's tools.

Sure, but my point is that if there is only 1 crystal frequency for all ESP8266 boards, then the bin files should be made for 26 MHz and thus no patching is needed.
If there are multiple crystal frequencies, then the flash tool should at least be able to detect the frequency and either pick the right one, or patch it, or fail to flash with a proper error message.

That's a reasonable assessment from your position.

but my point is that if there is only 1 crystal frequency for all ESP8266 boards

But are we 100% certain that this is the case?
Espressif's documents, specs, tools suggests that there can be ESP82666 boards with cyrstal frequencies other than 26MHz. Shouldn't we adhere to the specs, rather personal experience?
Besides projects like micropython depend upon the flashing tool for patching and doesn't expect the average developer to build the firmware(let alone setting the correct crystal frequency, which I haven't found yet).  So web flashing using esp-web-flasher is out of the scope for such developers and projects now.
I have found at least one project using esp-web-tools(6.1.1) in the wild to flash official micropython build to ESP8266,  Now they have to resort to building custom micropython firmware with hard coded crystal frequency if that's possible.
Removing header patching has made the barrier for entry much higher for using esp-web-tools.

Your conclusion is incorrect. Header patching was removed because it was breaking installs and causing a high barrier. Instead of developers relying on magic in ESP Web Flasher, we prefer developers create the right images and we can help with the selection process.

I didn't mean the issue which caused ESP32 devices from being flashed correctly shouldn't be fixed, I meant the solution for fixing it has increased barrier for entry i.e. developers should know how to build custom firmware to use esp-web-tools.

ESP Web Tools is meant for firmware creators to help users install and update devices. Creating custom builds is what firmware creators do? I guess MicroPython is the only exception here as it's a generic platform.

Disclaimer: I myself use esp-web-tools to flash my custom micropython firmware to my customers device.
That said, I see scenarios where people would like to flash a generic firmware to their customer devices to offer other services like education(IDE), configuration(IoT) etc.

I guess MicroPython is the only exception here as it's a generic platform.

There are at least about dozen such generic firmwares.

ESP Web Tools is meant for firmware creators to help users install and update devices.

No contention there, It's your choice as a project maintainer.

I do not understand what the problem is. Since the header patching was removed we had not a single user of Tasmota complaining that the flashed firmware is NOT working.
We us the webflasher for flashing all Tasmota variants (esp8266, esp32, esp32-s2 and esp32-c3). @balloob any news for supporting the ESP32-S3? Official Arduino support will be the next days ;-)

Which tool?

Sorry, I'll rephrase; What's the crystal frequency of the esp8266 board you're able to flash successfully after the header patching was removed in esp-web-flasher.

26MHz

If it does not work for you have either a very rare board with 40Mhz and builded the firmware without setting the crystal speed to 40Mhz. It is no problem to flash this firmware with webflasher too. Just do a extra manifest and provide the according firmware.

Just flash Tasmota and it will work https://arendst.github.io/Tasmota-firmware/

Flashing Tasmota firmware through that website on the board in question(LoLin NodeMCU Lua V3) works fine, The flashing mode (DIO) seems to have been set in the firmware itself during compilation(likely via PlatformIO) as  @TD-er  mentioned earlier.
Unfortunately PlatformIO doesn't support Micropython(I'm using esp-open-sdk to build mine) and I haven't figured out a way for setting the flashing mode during firmware compilation if that's possible. So for those in my position, Using esp-web-flasher v4.0.0 is the temporary solution.

Thats the point. Your platform generating the firmware has to generate a valid firmware for flashing. Do not expect other tools fixes issue caused by a faulty tool generating a firmware.

Do not expect other tools fixes issue caused by a faulty tool generating a firmware.

That's harsh and inaccurate.

I am not entirely sure whether the web flasher should patch it, but on the other hand esptool.py and the Espressif download tool patch it. (Espressif download tool has a flag to no change the bin to disable this).

At least your title of this opened issue is not correct. Patching is NOT required.

Going to close this as it's not a ESP Web Flasher issue and should be fixed when firmware created.


Filter memory per vcpus

It will be nice to have the ability to filter instance providing an amount of memory per vCPUs considering that all vCPUs will be utilized.

You are able to query a ratio of memory to vcpus but not a specific memory quantity per vcpu. Does that take care of your use-case or are you looking for the latter?
      --vcpus-to-memory-ratio string                   The ratio of vcpus to GiBs of memory. (Example: 1:2)


Update CodeClimate integration

After running a bundle update I was getting this message, which
aborted the specs:

This usage of the Code Climate Test Reporter is now deprecated.
Since version 1.0, we now require you to run SimpleCov in your
test/spec helper, and then run the provided
codeclimate-test-reporter binary separately to report your results
to Code Climate.
More information here:
https://github.com/codeclimate/ruby-test-reporter/blob/master/README.md

It sounds like there are more steps we need to take according to that link,
but this at least gets specs working again.

Looks good


Problem with postgresql-dart when working with FLUTTER WEB

I am getting an error when I am trying to connect and work with a Postgresql database via a flutter web app.
Is there a solution?
Error: Unsupported operation: Socket constructor
    at Object.throw_ [as throw] (http://localhost:56797/dart_sdk.js:4339:11)
    at Function._connect (http://localhost:56797/dart_sdk.js:57607:17)
    at Function.connect (http://localhost:56797/dart_sdk.js:57590:26)
    at connection.PostgreSQLConnection.new.open (http://localhost:56797/packages/postgres/src/query_queue.dart.lib.js:3214:46)
    at open.next (<anonymous>)
    at runBody (http://localhost:56797/dart_sdk.js:37699:34)
    at Object._async [as async] (http://localhost:56797/dart_sdk.js:37730:7)
    at connection.PostgreSQLConnection.new.open (http://localhost:56797/packages/postgres/src/query_queue.dart.lib.js:3205:20)
    at brandbody._BrandBodyState.new.uploadDatatoDatabase (http://localhost:56797/packages/watch_store_datainput_web/screens/brand/components/brandbody.dart.lib.js:434:25)
    at uploadDatatoDatabase.next (<anonymous>)
    at runBody (http://localhost:56797/dart_sdk.js:37699:34)
    at Object._async [as async] (http://localhost:56797/dart_sdk.js:37730:7)
    at brandbody._BrandBodyState.new.uploadDatatoDatabase (http://localhost:56797/packages/watch_store_datainput_web/screens/brand/components/brandbody.dart.lib.js:433:20)
    at http://localhost:56797/packages/watch_store_datainput_web/screens/brand/components/brandbody.dart.lib.js:449:277
    at ink_well._InkResponseState.new.[_handleTap] (http://localhost:56797/packages/flutter/src/material/icon_button.dart.lib.js:50678:42)
    at http://localhost:56797/packages/flutter/src/material/icon_button.dart.lib.js:50787:668
    at tap.TapGestureRecognizer.new.invokeCallback (http://localhost:56797/packages/flutter/src/gestures/recognizer.dart.lib.js:189:18)
    at tap.TapGestureRecognizer.new.handleTapUp (http://localhost:56797/packages/flutter/src/gestures/tap.dart.lib.js:395:40)
    at tap.TapGestureRecognizer.new.[_checkUp] (http://localhost:56797/packages/flutter/src/gestures/tap.dart.lib.js:201:12)
    at tap.TapGestureRecognizer.new.handlePrimaryPointer (http://localhost:56797/packages/flutter/src/gestures/tap.dart.lib.js:148:23)
    at tap.TapGestureRecognizer.new.handleEvent (http://localhost:56797/packages/flutter/src/gestures/recognizer.dart.lib.js:448:16)
    at pointer_router.PointerRouter.new.[_dispatch] (http://localhost:56797/packages/flutter/src/gestures/pointer_router.dart.lib.js:74:9)
    at http://localhost:56797/packages/flutter/src/gestures/pointer_router.dart.lib.js:109:26
    at LinkedMap.new.forEach (http://localhost:56797/dart_sdk.js:24816:11)
    at pointer_router.PointerRouter.new.[_dispatchEventToRoutes] (http://localhost:56797/packages/flutter/src/gestures/pointer_router.dart.lib.js:106:29)
    at pointer_router.PointerRouter.new.route (http://localhost:56797/packages/flutter/src/gestures/pointer_router.dart.lib.js:98:37)
    at binding$5.WidgetsFlutterBinding.new.handleEvent (http://localhost:56797/packages/flutter/src/gestures/binding.dart.lib.js:306:26)
    at binding$5.WidgetsFlutterBinding.new.dispatchEvent (http://localhost:56797/packages/flutter/src/gestures/binding.dart.lib.js:289:24)
    at binding$5.WidgetsFlutterBinding.new.dispatchEvent (http://localhost:56797/packages/flutter/src/rendering/layer.dart.lib.js:5973:13)
    at binding$5.WidgetsFlutterBinding.new.[_handlePointerEventImmediately] (http://localhost:56797/packages/flutter/src/gestures/binding.dart.lib.js:260:14)
    at binding$5.WidgetsFlutterBinding.new.handlePointerEvent (http://localhost:56797/packages/flutter/src/gestures/binding.dart.lib.js:233:43)
    at binding$5.WidgetsFlutterBinding.new.[_flushPointerEventQueue] (http://localhost:56797/packages/flutter/src/gestures/binding.dart.lib.js:222:14)
    at binding$5.WidgetsFlutterBinding.new.[_handlePointerDataPacket] (http://localhost:56797/packages/flutter/src/gestures/binding.dart.lib.js:212:65)
    at Object._invoke1 (http://localhost:56797/dart_sdk.js:176547:7)
    at _engine.EngineWindow.new.invokeOnPointerDataPacket (http://localhost:56797/dart_sdk.js:172276:15)
    at _engine.PointerBinding.__.[_onPointerData] (http://localhost:56797/dart_sdk.js:159053:24)
    at http://localhost:56797/dart_sdk.js:159442:26
    at http://localhost:56797/dart_sdk.js:159401:16
    at http://localhost:56797/dart_sdk.js:159154:11

same here


No support for combination of Nuxt 2 and vue-class-component?

I'm actually somewhat confused right now. I am using Volar in a Vue 2 / Nuxt 2 + TypeScript project. I've installed @vue/runtime-dom and built-in components work just fine. Components are written in class style with property decorators.
There seem to be a number of issues (closed) suggesting various things to get this working but I haven't found a way. I have created a minimal reproduction repository here: https://github.com/barfurth/volar-no-types-repro
Namely I have tried things suggested here with no success:

https://github.com/johnsoncodehk/volar/issues/753#issuecomment-985528289
https://github.com/johnsoncodehk/volar/issues/705

My question can be boiled down to: What is the definitive way to get prop and event type checking (aka. types in templates) working when using Vue 2, vue-property-decorator and vue-class-component. I feel like I have tried everything that has been suggested without any luck.

Maybe this thread help you: https://github.com/johnsoncodehk/volar/pull/750#issuecomment-1023947885

Very helpful @johnsoncodehk, I will try that.
Will this work with globally defined components at all (i.e. Vue.component or Nuxt)? I didn't get anywhere with global type definitions for @vue/runtime-dom before, so I was wondering if that is still the correct way to use global components. The documentation only talks about global components from third party packages (the example has vue-router).

I have updated the example repository with a definition file that should work (my understanding) but does not.
https://github.com/barfurth/volar-no-types-repro/blob/main/components.d.ts
Usage happens here: https://github.com/barfurth/volar-no-types-repro/blob/main/pages/index.vue
With the above example repository, the type of the HelloWorld component is still showing as any. According to the comment https://github.com/johnsoncodehk/volar/issues/705#issuecomment-974773353 this was working at the end of last year. Is it possible something has changed that is preventing global component definitions from working with Vue 2?

Thank you @johnsoncodehk, it appears prop type checking with global components is working properly now. Sadly your link to https://github.com/johnsoncodehk/volar/pull/750#issuecomment-1023947885 does not work fully anymore. It seems the type of $emit may have changed, since I cannot assign anything to it. I believe this is a separate issue though. Using the exact example:
export default class Foo extends Vue {
  $emit!: {
    (e: 'my-event-1'): void
    (e: 'my-event-2', arg1: string, arg2: number): void
  }
}

This results in an error:

Type '{ (e: "my-event-1"): void; (e: "my-event-2", arg1: string, arg2: number): void; }' is not assignable to type '(event: string, ...args: any[]) => this'

Thank you for your quick support with the issue. :)


Adding default slack channel mapping

Resolves AB#502

This mandates teams to have slack mapping in jenkins-config .

Thanks @hmcts-flux-demo

You're welcome @adusumillipraveen


New Ingress Template (helm new) might be wrong / or at least hard to understand

in template/ingress.yaml
the name of the service is generated by the _helper using the release name
{{- $fullName := include "chart.fullname" . -}}
{{- $svcPort := .Values.service.port -}}
  rules:
    {{- range .Values.ingress.hosts }}
    - host: {{ .host | quote }}
      http:
        paths:
          {{- range .paths }}
          - path: {{ .path }}
            backend:
              serviceName: {{ $fullName }}
              servicePort: {{ $svcPort }}
          {{- end }}
    {{- end }}
  {{- end }}

but in values.yaml, the recommended way seems to overwrite the whole path object including backend:
https://github.com/helm/helm/commit/1e126ff4d1f09b806c1952757516f6fc67506ce0
  hosts:
    - host: chart-example.local
      paths:
      - path: /
        backend:
          serviceName: chart-example.local
          servicePort: 80

I'm not entirely sure, but I think this backend setting would be ignored anyway using the generated ingress template...
with the ingress v1 warning on helm install, this topic might get more important for customers
what is your recommended way now to specify a simple/minimal ingress with v1 in mind?
Thanks for clarifying,
Adrian

what is your recommended way now to specify a simple/minimal ingress with v1 in mind?

I'm sorry, I don't fully understand your question. What do you mean by "with v1 in mind"?
Helm templates are generated based on the values provided by the user. In this particular case, the ingress rules will read what's in values.yaml and generate an ingress route. Add another route to values.yaml and the ingress routes will be updated.

with a change in the last release, the template got changed what "helm create" generates for values.yaml:
https://github.com/helm/helm/commit/1e126ff4d1f09b806c1952757516f6fc67506ce0
I do have the feeling the change was not a good idea - since the actual generated ingress (template/ingress.yaml) will not work with this suggesting in the values.yaml.
furthermore, the Kubernetes CLI throws warnings when installing/upgrading such charts generated with "helm create".
infos here: https://kubernetes.io/blog/2020/09/03/warnings/
Your template currently generates ingress in version v1beta1. In the meantime v1 has been released and changes the section quite a lot. So I think it's worth to refactor the whole helm create template for ingress

Thank you for pointing this out. PRs welcome to fix this.

https://github.com/helm/helm/blob/543364fba59b0c7c30e38ebe0f73680db895abb6/pkg/chartutil/create.go#L219-L223

see, I think this issue should not be classified as "bug" and not "support".
and I suggest to revert the mentioned change.
helm create example

ingress:
  enabled: false
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths:
      - path: /
        backend:
          serviceName: chart-example.local
          servicePort: 80
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

when I edit this part:
        backend:
          serviceName: my-fancy-backend
          servicePort: 9090

if I install the chart with enabled ingress
helm install svc1 . --set ingress.enabled=true  --dry-run

the installed ingress element does not contain my intended config
# Source: example/templates/ingress.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: svc1-example
  labels:
    helm.sh/chart: example-0.1.0
    app.kubernetes.io/name: example
    app.kubernetes.io/instance: svc1
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  rules:
    - host: "chart-example.local"
      http:
        paths:
          - path: /
            backend:
              serviceName: svc1-example
              servicePort: 80

I'm happy to create a pull request for a new idea about the default template of an ingress.
I have the feeling that there are many ideas around for best ideas of a chart config when I look at various helm charts of popular vendors. Since the Helm CLI might be considered kind as the Authority how to create a good Helm Chart, changes to the "helm create" command should be done carefully.
the new kubectl command can now create ingress objects
kubectl create ingress simple --rule="foo.com/bar*=svc1:8080,tls=my-cert" --dry-run=client -o yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  creationTimestamp: null
  name: simple
spec:
  rules:
  - host: foo.com
    http:
      paths:
      - backend:
          service:
            name: svc1
            port:
              number: 8080
        path: /bar
        pathType: Prefix
  tls:
  - hosts:
    - foo.com
    secretName: my-cert

I could imagine to go into this direction
ingress:
  enabled: false
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  rules:
    - host: chart-example.local
      path: /
      pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

Would be nice to add ingressClassName support as well. Dex has an experimental, backwards compatible implementation here: https://github.com/dexidp/helm-charts/blob/256796084cbe900421822b266c9d60dc7f3e2455/charts/dex/templates/ingress.yaml#L14-L26

thanks alot for reading through this issue, your interest and linking!
ingressClassName absolutely makes sense. thanks for this hint
variant A
ingress:
  enabled: false
  # className: nginx
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  rules:
    - host: chart-example.local
      path: /
      pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

variante B:
ingress:
  enabled: false
  # class:
  #   name: nginx
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  rules:
    - host: chart-example.local
      path: /
      pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

I vote for variant A

this is a first draft:

I removed support for K8s 1.13 and below (ingress in extensions/v1beta1 group)
based on capabilities, I try to add / skip feature (ingressClassName, pathType); the handy dex workaround is implemented

it's currently pretty untested on older versions of Kubernetes. But I think it could be a first discussion basis.
cheers, Adrian
ingress.yaml
{{- if .Values.ingress.enabled -}}
{{- $fullName := include "chart.fullname" . -}}
{{- $svcPort := .Values.service.port -}}
{{- $kubeVersion := .Capabilities.KubeVersion.GitVersion -}}
{{- if semverCompare ">=1.19-0" $kubeVersion -}}
apiVersion: networking.k8s.io/v1
{{- else -}}
apiVersion: networking.k8s.io/v1beta1
{{- end }}
kind: Ingress
metadata:
  name: {{ $fullName }}
  labels:
    {{- include "chart.labels" . | nindent 4 }}
  {{- if and .Values.ingress.className (not (semverCompare ">=1.18-0" $kubeVersion)) }}
    {{- if not (hasKey .Values.ingress.annotations "kubernetes.io/ingress.class") }}
    {{- $_ := set .Values.ingress.annotations "kubernetes.io/ingress.class" .Values.ingress.className}}
    {{- end }}
  {{- end }}
  {{- with .Values.ingress.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
spec:
  {{- if and .Values.ingress.className (semverCompare ">=1.18-0" $kubeVersion) }}
  ingressClassName: {{ .Values.ingress.className }}
  {{- end }}
  rules:
    {{- range .Values.ingress.rules }}
    - host: {{ .host | quote }}
      http:
        paths:
        - path: {{ .path }}
          {{- if and .pathType (semverCompare ">=1.18-0" $kubeVersion) }}
          pathType: {{ .pathType }}
          {{- end }}
          backend:
            {{- if semverCompare ">=1.19-0" $kubeVersion }}
            service:
              name: {{ $fullName }}
              port:
                number: {{ $svcPort }}
            {{- else -}}
            serviceName: {{ $fullName }}
            servicePort: {{ $svcPort }}
            {{- end }}
    {{- end }}
  {{- if .Values.ingress.tls }}
  tls:
    {{- range .Values.ingress.tls }}
    - hosts:
        {{- range .hosts }}
        - {{ . | quote }}
        {{- end }}
      secretName: {{ .secretName }}
    {{- end }}
  {{- end }}
  {{- end }}

NOTES.txt
1. Get the application URL by running these commands:
{{- if .Values.ingress.enabled }}
{{- range $rule := .Values.ingress.rules }}
  http{{ if $.Values.ingress.tls }}s{{ end }}://{{ .host }}{{ .path }}
{{- end }}
{{- else if contains "NodePort" .Values.service.type }}
  export NODE_PORT=$(kubectl get --namespace {{ .Release.Namespace }} -o jsonpath="{.spec.ports[0].nodePort}" services {{ include "chart.fullname" . }})
  export NODE_IP=$(kubectl get nodes --namespace {{ .Release.Namespace }} -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT
{{- else if contains "LoadBalancer" .Values.service.type }}
     NOTE: It may take a few minutes for the LoadBalancer IP to be available.
           You can watch the status of by running 'kubectl get --namespace {{ .Release.Namespace }} svc -w {{ include "chart.fullname" . }}'
  export SERVICE_IP=$(kubectl get svc --namespace {{ .Release.Namespace }} {{ include "chart.fullname" . }} --template "{{"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}"}}")
  echo http://$SERVICE_IP:{{ .Values.service.port }}
{{- else if contains "ClusterIP" .Values.service.type }}
  export POD_NAME=$(kubectl get pods --namespace {{ .Release.Namespace }} -l "app.kubernetes.io/name={{ include "chart.name" . }},app.kubernetes.io/instance={{ .Release.Name }}" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace {{ .Release.Namespace }} $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://<IP_ADDRESS>:8080 to use your application"
  kubectl --namespace {{ .Release.Namespace }} port-forward $POD_NAME 8080:$CONTAINER_PORT
{{- end }}

a minimal sample would be this:
ingress:
  enabled: true
  className: nginx
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  rules:
    - host: chart-example.local
      path: /
      pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-chart
  labels:
    helm.sh/chart: chart-0.1.0
    app.kubernetes.io/name: chart
    app.kubernetes.io/instance: test
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  ingressClassName: nginx
  rules:
    - host: "chart-example.local"
      http:
        paths:
        - path: /
          pathType: ImplementationSpecific
          backend:
            service:
              name: test-chart
              port:
                number: 80

Looks good to me!

I started with a pull request to ask for community acceptance
https://github.com/helm/helm/pull/9585


fix(UI): replace button with icons in challenge lower jaw

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #47157

replaced the text inside help and reset buttons with icons
added title and aria-label for tooltip - the tooltip uses the translate function to have a localised text
removed the btn-block class to allow a more compact UI which will allow more icons in the future

Solid work here. Here are a few things that need to be addressed before this gets merged.

Are the icons your design. If so, please look in client/src/assets/icons for custom svg samples and usage. If not, what is the license?
Please add data-cy to the icon buttons and select the reset button accordingly from the related cypress test so the tests pass
Could you right align the buttons for consistency with mobile's new learn UI.

@ahmadabdolsaheb
I modified accordingly but I could find the proper test in cypress, I don't think the tests for these two buttons were written yet. The previous buttons I replaced were also missing data-cy.
I'm not familiar with writting cypress tests so maybe it needs a new issue ?

Hi @Sboonny, thanks for the remarks! I used {condition ? : : <></>} instead of {condition && } because I read some time ago that the ternary version should be prefered to avoid bugs, after struggling with a bug myself. This article discusses the issue but suggest to use {condition ? : : null} instead. I'll let you decide which solution you prefer :)
The missing () around the condition is an error on my part, I'll fix it in the next commit.

Hey @mehdibouaziz, I read the article you shared, there is no harm in using short circuit expression, you just have to make sure that the condition evaluates to boolean and not truthly/falsy.

@ahmadabdolsaheb  I found the selector error in the failing cypress test and put the correct one.
@nayabatir1 Hi, thanks for your feedback. True, but I tried with the short circuit and in this case one of the conditions as it was written evaluates to 0 and causes a 0 to render:

I switched to ternary with null just to be sure :)

You can refer to this article https://www.codingem.com/javascript-double-exclamation-operator/

All done :)
note that I tried to add parenthesis to the condition for the conditional display of the button, but when committing prettier removes them, they are unnecessary I suppose.
 {isAttemptsLargerThanTest && !challengeIsCompleted ? (

Just a minor nitpick. Do we need to float the get help button to the left of the reset button? Usually the tab sequence goes left to right so it seems a little odd to have it go right to left for these two buttons. This isn't technically an accessibility failure though, so I'm not demanding anything here. Although I would highly recommend that we add our own custom focus outline on these buttons (instead of relying on the browser's default, which isn't always so great) so that it is perfectly clear which one has focus. I've been using the outline color --blue-mid for things I work on because it has accessible contrast with both our light and dark themes. But I understand that that is not necessarily an official policy.

Hi, thanks for the review!
You mean that with the current solution when using tab the focus is moving from right to left because of float:right ?
I can switch to a flexbox instead if it would improve accessibility, there's already a container bar for the buttons.
Since the help button is hidden at first and appears after a few fails, I thought it would be better to have it appear on the left so it doesn't shuffle around the reset button.
For the focus color I'll let the owners decide, it's easy to add.

No need to switch to flexbox for accessibility, this is purely about DOM order of element, which flexbox won't change. Although if we eventually add more buttons then I think flexbox would be the better solution here.
Another option might be to place the buttons on the left side instead of the right. Then when we add the help button it would be placed to the right of the reset button and wouldn't cause a shift and the tab order would follow the DOM order.

Nice catch @bbsmooth, I just simplified the styles and the buttons should show up on the left side of the button jaw in the correct DOM order.
@mehdibouaziz, once the tests pass LGMT.


Comprehensive status

Now eden status reflects only whether something is running or not.
Suggested:
If something is running display (except name & status):

IP/Port (how to connect) 2) log file location
If something is not running display (except name & status):
Likely cause (if possible) 2) log file location 3) last error from log (something like tail -f)

Funny you should mention it @mydatascience -- I was running into a few issues with that myself. In fact, one suggestion I have is to perhaps consider getting rid of PID file tracking -- that's super unreliable anyway -- and make sure to launch processes with some kind of a fake command line flag that you can reliably grep for in the ps -ale output (or the equivalent).

Btw, @mydatascience -- please take a look at #41 -- I think these issues are identical. Lets pick one and close the other one.


Absence of a scroll-to-top button in index page

I think adding a scroll-to-top button to the index page will make the website more convenient and responsive.
I could help you with the adding of the button.

Is the code for this already in @RaghavK16 ?

Yes, I've created a pull-request just now.


terraform: bump to the latest version

2 changes:

Added RHEL 8.7 and 9.1 GA definitions
All CI machines now have a hard timeout of 4 hours, preventing us from having rogue machines that run forever.

See https://github.com/osbuild/gitlab-ci-terraform/compare/04c82e2156dfee54181e10eac317957a8426f091...89fb25d15bc49e1463aec2ba6ea3c32957ab6c4d

Are the CI errors relevant? I don't see any connections between them and the change...

Nope, we can merge now. It's messy but those jobs are ignored for now, we are waiting on other teams to provide the appropriate image


Rich Presence not working with newest sdk

I don't know what causes the issue but i will try to find what causes this

okay so ue5 is getting responses from discord as seen in the log
LogDiscord: Display: Timer Start Result: Ok LogDiscord: Display: Timer Start Result: Ok LogDiscord: Display: State Set Result: Ok LogDiscord: Display: Details Set Result: Ok
So either the discord client isn't picking up the game, or discord itself has some issues on their end


Why xs:documentation on fields ignored?

Why generated java-classes don't contain javadoc or some annotation with content of <xs:documentation> tag on fields???
In my *.xsd file I have:
    <xs:element minOccurs="0" name="Party" type="PartyType">
        <xs:annotation>
            <xs:documentation>Info about client</xs:documentation>
        </xs:annotation>
    </xs:element>

but in generated class there is only:
    @XmlElement(name = "Party")
    protected PartyType party;

// another fields

    /**
     * Gets the value of the party property.
     *
     * @return
     *     possible object is
     *     {@link PartyType }
     *
     */
    public PartyType getParty() {
        return party;
    }

    /**
     * Sets the value of the party property.
     *
     * @param value
     *     allowed object is
     *     {@link PartyType }
     *
     */
    public void setParty(PartyType value) {
        this.party = value;
    }

That javadoc ("Gets/sets the value of ...") is absolutely useless! And really useful data ("Info about client") is absent!
This situation crushes my mind :exploding_head:

Was meaning to open the same bug. Ignoring the documentation tag is like going to the trouble to make a printed manual, but leaving all the pages blank.

@MikePryadko and @minfrin :
The xs:documentation is actually processed by some external xjc plugins.
We are currently implementing a plugin in jaxb-tools due to old issue but there's also other existing plugins that are available, the most well known is the apache cxf's one
Depending the tool you use for generating java code from xsd, the configuration might be different.
Regards

I'll try to provide a PR to create javadoc for fields too in xjc directly since already handled for some fields.

@MikePryadko and @minfrin
Provided a PR to make xjc standalone handle this
Tested on basic examples, works like a charm without any additional tool / command line option / plugin
Regards


Unable to build for release

Good afternoon everyone, i'm experiencing the inability to build for release cargo build --release any version of the substrate framework after the tagged v3.0.0.
This error is caused by the chain_spec code
error[E0783]: trait objects without an explicit `dyn` are deprecated
  --> bin/node/cli/src/chain_spec.rs:54:50
   |
54 | #[derive(Default, Clone, Serialize, Deserialize, ChainSpecExtension)]
   |                                                  ^^^^^^^^^^^^^^^^^^ help: use `dyn`: `<dyn ChainSpecExtension>`
   |
   = note: this error originates in the derive macro `ChainSpecExtension` (in Nightly builds, run with -Z macro-backtrace for more info)

It seems not to throw until you first try building for release. After the first building for release, the compilation in debug mode will throw the same error too.
I'm trying to build the code using the latest stable release at the time of writing, moving to a previous release (1.56.1) does not seem to solve the issue.

EIther use master or downgrade to a rustc version that isn't failing because of this. (Try some stable of when 3.0 was released)


Review 'Getting started' Unity tutorial series

Docs Build status updates of commit 5c73f7d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/mr-learning-base-02.md
:bulb:Suggestion
View
Details

mixed-reality-docs/mr-learning-base-02.md

Line 12, Column 1: [Suggestion-duplicate-h1s] H1 '2. Initializing your project and first application' is duplicated with other articles: 'mr-learning-base-02.md(12,1), unreal-uxt-ch2.md(12,1)'. First level headings must be unique within a docset. NOTE: This Suggestion will become a Warning in late September, 2020.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

@martinwilter

We use the Readability Check (https://marketplace.visualstudio.com/items?itemName=jemcclin.readabilitycheck) extension in VSCode to vet all our technical writing.
Readability scores should ideally be between 60-70, but with very technical docs it's ok to be in the mid-'50s.

Could you update the tutorials then ping me so I can review it.

@martinwilter

We use the Readability Check (https://marketplace.visualstudio.com/items?itemName=jemcclin.readabilitycheck) extension in VSCode to vet all our technical writing.
Readability scores should ideally be between 60-70, but with very technical docs it's ok to be in the mid-'50s.
You might also want to use something like Grammarly, as I noticed a lot of sentence fragments/structure issues in a lot of the tutorials.

Could you update the tutorials then ping me so I can review it.

Thanks @hferrone, sure, I'll check out the extension. We already ran all pages in these three tutorial series through Grammarly and they consistently show an overall score above 90.

@hferrone, what particular scoring model do you want us to use and which grade level is you target?

Flesche scoring model and 60-70 score ideally.
On Fri 3. Jul 2020 at 1:13 PM, Martin Wilter<EMAIL_ADDRESS>wrote:

@hferrone https://github.com/hferrone, what particular scoring model
do you want us to use and which grade level is your target?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/mixed-reality/pull/2324#issuecomment-653654471,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6WRK72JJAYJSX5G76OD53RZYUW3ANCNFSM4OP6VWMA
.

--
Harrison Ferrone
Unity & iOS Instructional Author
*+49 152 2404 6557 *
*"The mediator between brain and muscle must be the heart." *

@hferrone we've been trying to target the readability score you specified. I wonder if some of the unique MRTK- and Unity-based names are negatively impacting the scoring algorithm? I ran a quick experimentt replacing MRTK/Unity item names with placeholders (for example, replacing "Microsoft.MixedReality.Toolkit.Unity.Foundation.2.4.0.unitypackage" with "package") and we got a readability score of 54, which you've specified as being ok for technical documents. @martinwilter has been doing some passes, I think we got grammerly in the upper 90's range. He's doing a quick pass to make sure everything else looks good and then you can begin your full review.

Hi @hferrone,
We've made a pass on all the tutorial pages and were able to make some significant improvements:

Increased the overall Grammarly Pro score from above 90 to 99-100 out 100
Increased Flesh score from generally being in the low 40ies to the high 40ies

Re Flesch score, as Sean mentioned, we believe the unavoidable use of MR related terms skews the score a bit. As an example that is still available, you can look at base-03. Compared to other pages, base-03 has a low score because it's covering configuring MRTK profiles, so the majority of the words will have a lot of syllables.
I made a new PR https://github.com/MicrosoftDocs/mixed-reality/pull/2330.

Docs Build status updates of commit 7efeb84:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/mr-learning-asa-01.md
:bulb:Suggestion
View
Details

mixed-reality-docs/mr-learning-base-01.md
:bulb:Suggestion
View
Details

mixed-reality-docs/mr-learning-sharing-01.md
:bulb:Suggestion
View
Details

mixed-reality-docs/mr-learning-asa-02.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-03.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-04.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-05.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-02.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-03.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-04.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-05.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-06.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-07.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-08.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-09.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-02.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-03.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-04.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-05.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-01.md

Line 12, Column 1: [Suggestion-duplicate-h1s] H1 '1. Introduction' is duplicated with other articles: 'mr-learning-asa-01.md(12,1), mr-learning-base-01.md(12,1), mr-learning-sharing-01.md(12,1)'. First level headings must be unique within a docset. NOTE: This Suggestion will become a Warning in late September, 2020.

mixed-reality-docs/mr-learning-base-01.md

Line 12, Column 1: [Suggestion-duplicate-h1s] H1 '1. Introduction' is duplicated with other articles: 'mr-learning-asa-01.md(12,1), mr-learning-base-01.md(12,1), mr-learning-sharing-01.md(12,1)'. First level headings must be unique within a docset. NOTE: This Suggestion will become a Warning in late September, 2020.

mixed-reality-docs/mr-learning-sharing-01.md

Line 12, Column 1: [Suggestion-duplicate-h1s] H1 '1. Introduction' is duplicated with other articles: 'mr-learning-asa-01.md(12,1), mr-learning-base-01.md(12,1), mr-learning-sharing-01.md(12,1)'. First level headings must be unique within a docset. NOTE: This Suggestion will become a Warning in late September, 2020.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 5ca1a8c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/mr-learning-asa-01.md
:bulb:Suggestion
View
Details

mixed-reality-docs/mr-learning-base-01.md
:bulb:Suggestion
View
Details

mixed-reality-docs/mr-learning-sharing-01.md
:bulb:Suggestion
View
Details

mixed-reality-docs/mr-learning-asa-02.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-03.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-04.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-05.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-02.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-03.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-04.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-05.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-06.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-07.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-08.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-base-09.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-02.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-03.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-04.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-sharing-05.md
:white_check_mark:Succeeded
View

mixed-reality-docs/mr-learning-asa-01.md

Line 12, Column 1: [Suggestion-duplicate-h1s] H1 '1. Introduction' is duplicated with other articles: 'mr-learning-asa-01.md(12,1), mr-learning-base-01.md(12,1), mr-learning-sharing-01.md(12,1)'. First level headings must be unique within a docset. NOTE: This Suggestion will become a Warning in late September, 2020.

mixed-reality-docs/mr-learning-base-01.md

Line 12, Column 1: [Suggestion-duplicate-h1s] H1 '1. Introduction' is duplicated with other articles: 'mr-learning-asa-01.md(12,1), mr-learning-base-01.md(12,1), mr-learning-sharing-01.md(12,1)'. First level headings must be unique within a docset. NOTE: This Suggestion will become a Warning in late September, 2020.

mixed-reality-docs/mr-learning-sharing-01.md

Line 12, Column 1: [Suggestion-duplicate-h1s] H1 '1. Introduction' is duplicated with other articles: 'mr-learning-asa-01.md(12,1), mr-learning-base-01.md(12,1), mr-learning-sharing-01.md(12,1)'. First level headings must be unique within a docset. NOTE: This Suggestion will become a Warning in late September, 2020.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

@martinwilter Thanks for the updates!
A few things that still need to be addressed with the writing:

"With the MixedRealityToolkit object still selected in the Hierarchy window, in the Inspector window, verify that the MixedRealityToolkit configuration profile is set to DefaultMixedRealityToolkitConfigurationProfile:"
"In the Build Universal Windows Platform window, choose a suitable location to store your build, for example, D:\MixedRealityLearning\Builds, create a new folder and give it a suitable name, for example, GettingStarted, and then click the Select Folder button to start the build process:"

Sentences like these have other sentences inserted into them, for instance "selected in the Hierarchy window, in the Inspector window, verify that the" and "store your build, for example, D:\MixedRealityLearning\Builds, create a new"

These are prevalent throughout all the updated tutorials and need to be ideally changed to something like:
"With the MixedRealityToolkit object still selected in the Hierarchy window, verify that the MixedRealityToolkit configuration profile is set to DefaultMixedRealityToolkitConfigurationProfile in the Inspector window:"
"In the Build Universal Windows Platform window, choose a suitable location to store your build, create a new folder and give it a suitable name, and then click the Select Folder button to start the build process:

In the example below, we've saved the build to D:\MixedRealityLearning\Builds and named it GettingStarted,"

Hi @hferrone, thanks for the feedback.
"With the MixedRealityToolkit object still selected in the Hierarchy window, verify that the MixedRealityToolkit configuration profile is set to DefaultMixedRealityToolkitConfigurationProfile in the Inspector window:"
The problem with this suggested change is that the focus point is mentioned at the very end, in this case the Inspector window, thus the reader needs to read the entire sentence or multiple sentences before they even know what general area they should focus on.
The methodology we have taken throughout these three and the four live tutorials is to first mention the focus area, then tell the reader what to do.
The suggested structure is to first tell the readers what to do, then where to do it.
I can see that algorithms for general reading suggest these kinds of changes, but when considering instructions for humans, isn't it much better to first tell them 'where' and then 'what'?

That's a good point. Considering that, the sentences still are not easily readable and could be changed to something like:
"With the MixedRealityToolkit object still selected in the Hierarchy window, go to the Inspector window and check that the MixedRealityToolkit configuration profile is set to DefaultMixedRealityToolkitConfigurationProfile:"

@martinwilter How are the writing updates coming along?

@hferrone Thanks for checking in! Quick update: we're looking closely at restructuring the sentence structures throughout the tutorials. It's looking like this will take some time across all the module chapters. Since the tutorials that are currently live are out of date, and this tutorial series is an overall improvement over the previous series, I'm thinking that we should proceed with merging in this update and in parallel continue to fine tune / polish out the sentence structures as needed. I really appreciate your reviews+recommendations and I'm excited for developers dive in!

@jessemcculloch let me know if we're good to merge this in

@mr0ng When do you think the restructuring could be done? If it's a few days, I'd rather wait to merge this in. If it's longer, then we'll go ahead with how it is now.

@hferrone given the number of chapters/modules, I estimate 1 - 2 weeks. Martin did a first pass, but it's looking like there may need to be additional iterations.

Ok, then @jessemcculloch this one is ready to merge.
@mr0ng Please keep me in the loop when a new PR is created with the requested changes.