Variable transformation doesn't work if undefined variables are used in the same snippet

Issue Type: Bug
Consider the following snippet:
{
  "Class": {
    "prefix": "myclass",
    "body": [
      "class ${TM_FILENAME_BASE/(^|_)([a-zA-Z0-9])/${2:/upcase}/g} : public ${BaseClass} {\n",
      "\t$0",
      "};\n"
    ]
  }
}

The transformation ${TM_FILENAME_BASE/(^|_)([a-zA-Z0-9])/${2:/upcase}/g} would normally remove the underscores and capitalize the filename, but in the snippet above, the file name is directly inserted without any transformation. However, after replacing ${BaseClass} with ${1:BaseClass},
the snippet works as expected.
VS Code version: Code 1.24.0 (6a6e02cef0f2122ee1469765b704faf5d0e0d859, 2018-06-06T17:37:01.579Z)
OS version: Linux x64 4.16.14-300.fc28.x86_64

@Chingyat I actually cannot reproduce anymore... Can you give it a try with latest insiders please https://code.visualstudio.com/insiders/. We did make some changes in the variables world and this might have been fixed by that.

I tried the snippet above with insiders in file my_class.cpp.
It should inserts:
class MyClass : public BaseClass {

};

But it actually inserts:
class My_class : public BaseClass {

};

Yeah, it looks like the /g-flag is getting lost


Register Share

I just missed the register share action in the SDK: https://tenor.com/gifapi/documentation#endpoints-registershare
So I could try to contribute this endpoint maybe this week / weekend.

@obrunsmann
Awesome I would be waiting. 🥳
And yeah I will be discontinuing the non null-safe code and making master as null-safe and will be working on it only.

Okay great, so we are not yet un null-safe (cause of too many deps 🙄) so I would implement that on the current branch without null safe.
Are you already working on null-safety for this package? Maybe we could document this into an issue :))

@obrunsmann
Null-safe version is already published.

Aah sorry, I see. Misunderstood this

@obrunsmann
It's okay, Chillax, It happens

@obrunsmann I have implemented registershare functionality. I hope you it might same you some time,
Also I have done some changes in whole package so as to easily manage the functions internally


Is there a reason for not following the Semantic Version convention for braking changes?

From the change log I can see that you introduced a few breaking changes without incrementing the major value of your version since 1.0.0.
Bellow is a list of all the versions and how they should be treated according to semver.

current
semver

1.1.0
2.0.0

1.1.0+1
2.0.0+1

1.1.0+2
2.0.0+2

1.1.1
3.0.0

1.2.0
4.0.0

1.3.0
5.0.0

1.4.0
5.1.0

1.4.0+1
5.1.0+1

1.4.1
5.1.1

1.4.1+1
5.1.1+1

1.4.2
5.1.2

1.4.3
5.1.3

1.4.4
5.1.4

1.4.4+1
5.1.4+1

Using this versioning system ensures that my code doesn't suddenly stop work and that I can safely put a constrain like this >=1.0.0 <2.0.0 being sure that everything will work as expected. Also this allows me to migrate the the newer version the I see fit.
https://semver.org/

If there's a standard, It doesn't means everyone should follow it.

If there's a standard, It doesn't means everyone should follow it.

Thank you for your explanation.

Thank you for your explanation.

I'd like to reopen this discussion. I found this issue because I was concerned that the null safety changes are planned to have a bump the minor version rather than the major.
I understand your rationale regarding the relative meaning of semver, but Dart pub is opinionated and will upgrade minor versions automatically if they're specified with the caret style, as most people do: hive: ^1.4.4
Uploading a breaking change as a minor version bump will break builds for anyone using the above notation, which is why the Dart team recommends major version upgrades in those cases.
Reference: https://dart.dev/null-safety/migration-guide#package-version

I'd like to reopen this discussion. I found this issue because I was concerned that the null safety changes are planned to have a bump the minor version rather than the major.
I understand your rationale regarding the relative meaning of semver, but Dart pub is opinionated and will upgrade minor versions automatically if they're specified with the caret style, as most people do: hive: ^1.4.4
Uploading a breaking change as a minor version bump will break builds for anyone using the above notation, which is why the Dart team recommends major version upgrades in those cases.
Reference: https://dart.dev/null-safety/migration-guide#package-version

@cachapa I agree

@cachapa I agree

But I think nullsafety versions will not break the exists users cause they are considered as prerelease and should be explicitly opted in to get those updates. Btw, I've already published 1.6.0-nullsafety.1 yesterday 👉👈
reference: https://dart.dev/tools/pub/publishing#publishing-prereleases

But I think nullsafety versions will not break the exists users cause they are considered as prerelease and should be explicitly opted in to get those updates. Btw, I've already published 1.6.0-nullsafety.1 yesterday 👉👈
reference: https://dart.dev/tools/pub/publishing#publishing-prereleases

No if there are no API changes, null safety will not break existing code.

Btw, I've already published 1.6.0-nullsafety.1 yesterday

Amazing work :+1:

No if there are no API changes, null safety will not break existing code.

Btw, I've already published 1.6.0-nullsafety.1 yesterday

Amazing work :+1:

But I think nullsafety versions will not break the exists users cause they are considered as prerelease and should be explicitly opted in to get those updates.

My understanding is that this is true only for as long as you keep the -nullsafety tag after the version number.
Once the new version of Dart is released and you remove the tag, all clients will pull the 1.6 dependency regardless of their local Dart version, and that will be a breaking change for those who haven't upgraded their SDK.

But I think nullsafety versions will not break the exists users cause they are considered as prerelease and should be explicitly opted in to get those updates.

My understanding is that this is true only for as long as you keep the -nullsafety tag after the version number.
Once the new version of Dart is released and you remove the tag, all clients will pull the 1.6 dependency regardless of their local Dart version, and that will be a breaking change for those who haven't upgraded their SDK.

and that will be a breaking change for those who haven't upgraded their SDK.

Isn't nullsafety supposed to be backwards compatible in unsound mode?

My understanding is that if you're in a very old SDK, your compiler won't understand all of those ? ! and late keywords and will fail to compile.
I suspect this wouldn't affect the vast majority of users since they're using Flutter which includes the latest Dart SDK, but it would affect anyone who hasn't touched their setup for a long while, and I would argue that those are exactly the type of users that shouldn't have their builds suddenly break.
My point is that build stability is important and we as package developers have the shared responsibility to do our parts in maintaining it.
To be fair, I also share a dislike for bumping the major version and wish Dart pub would stop upgrading automatically at minor, but at the end of the day it's just a number.

Yes, because of the syntax changes, the migration to null safety is always considered breaking. According to Dart's Migration Guide, null-safe packages should be published under versions indicating breaking changes:

Update the version of the package to indicate a breaking change and include a nullsafety suffix:

If your package is already at 1.0.0 or greater, increase the major version. For example, if the previous version is 2.3.2, the new version is 3.0.0-nullsafety.0.
If your package hasn’t reached 1.0.0 yet, either increase the minor version or update the version to 1.0.0. For example, if the previous version is 0.3.2, the new version is one of the following:

0.4.0-nullsafety.0
1.0.0-nullsafety.0

For subsequent updates to the null-safe prerelease of the package, increment the prerelease suffix. For example, if the first null-safe version is 3.0.0-nullsafety.0, then the next one is 3.0.0-nullsafety.1.
You can maintain a stable release and null-safe prerelease at the same time. For example, if you have a stable release that’s 1.0.0 and a prerelease that’s 2.0.0-nullsafety.0, you can still publish new versions of the stable release (1.0.1) and null-safe prerelease (2.0.0-nullsafety.1).
Once null safety is available in a stable release of the Dart SDK, we encourage you to publish a stable version of your null-safe package.

I'm closing this issue since Hive null-safety stable releases is versioned as 2.X.Y (with major version increase).


Fill in the blank with placeholder text

Challenge http://freecodecamp.com/challenges/waypoint-fill-in-the-blank-with-placeholder-text has an issue. Please describe how to reproduce it, and include links to screenshots if possible.

put kitty ipsum text in the p elemment


Admin Dashboard Layout Discussion

I forgot to put a moderation section.
Comments On/Off
Market Approval On/Off
If Market Approval is On, All Submitted (or Edited) Markets Go Into Pending Queue Prior to Being Approved for Public
If Not Approved, Can Submit Back With Notes to Submitter
Submitter Can Attach Explainer Note if Re-Submitting with Edit

What about...Unresolve Markets? Re-Resolve...?

Other

Delete users
Minimal theming (instance name, logo, set currency name)
Minimal economic control (market creation cost, standard bet sizes.)

Unresolve, re-resolve, etc would all be on the question page itself I think.

How about:

Sandbox Users ... because if a user creates bets, that messes with the history if you, "delete it."  Is your concern people creating offensive/toxic user display names? Or not wanting erroneously created users which open up for accidental, non-controlled betting...for example you, create 101 users instead of 100 and the last one somehow gets emailed to someone twice, allowing them to double bet?
Theming is no problem.
Economic Controls: What needs to be part of a dashboard, meaning it gets changed on the fly, vs. what needs to be set at the start of the game and not changed?

Currently everything is configurable at the start of the game/server and all calculations depend upon these constants.
https://github.com/openpredictionmarkets/socialpredict/blob/main/backend/setup/setup.yaml
Another question...what about exporting data (apart from backups)?
One would think you would want to be able to export all markets with a button, bets, users at any time so you have a record in .csv format?
What about a, "Halt Game," ... "Halt Betting" "Halt Market Creation" button(s) for the end of a tournament/semester?  Perhaps Halt Game would halt everything, whereas the other two options would halt the requisite items. E.g. sometimes stock markets have trading holidays?
Backups...I see this as a different problem than exporting data. I think there needs to be backups of the database on a regular basis in case something happens, e.g. if the game is lost, it can be recovered. Backups should just be a given and ideally there should be an optional plugin to S3. Whereas exports I see more as, "it's in CSV format, for ease of research and data analytics usage."
There's CSV, or a flatfile with json, whatever format that could be exports whereas backups would be a dump file compatible with postgres.

We had a couple of questions come in about what the, "Send Bailout," and "Change Debt Limit" features are, or just more clarity around those.

The idea behind, "Send bailout," comes from the use of SocialPredict as teaching a tool in a forecasting class. This anticipates the eventuality that a few students might just completely blow up their accounts in the first few weeks.

SocialPreidct overall would cache as little as possible in the entire platform to minimize the usage of databases (e.g. make it as stateless as possible) - except one's balance. This was after discussions with Andreas Zwinkau, who is the guy who implemented this while he was a phyics PhD student: https://github.com/qznc/prema

So basically, "Send bailout," would be a way to up an individual users' cached, "wallet," - intended for the instance in which they blow up their account. In the interests of transparency, there would need to be a /stats page which records and publicizes this transaction, showing which accounts received bailouts and what the exact transaction date was for that bailout. Optionally an administrator could never send a bailout...but my thought is, it would be better to publicize sent bailouts rather than the alternative, which would be to create a new shadow account, or multiple shadow accounts. It's like being able to say, "OK, well this person A still wants to play, let's send them a bailout...boom there's the record of the transaction," ... as opposed to, secretly letting them have another account.

This user's profit calculation would still be consistent, so basically you could calculate profitability over time and a bailout payment would not be entered into the profitability ledger (though obviously if they were not bailed out they would not have been able to continue to make profit).

The other form of bailout which was proposed is, "change individual debt limit," ... Which is a form of, "bailing everyone out." So basically, let's say you had a small number of users, e.g. 2/30 who sucked up all of the profit and everyone's cached wallet balance is low...well, you could just give everyone the ability to borrow way more points and start over again. So if you initially started a tournament out giving everyone the ability to borrow 500 points (which is similar to Manifold giving everyone 500 free credits at the start, but with a 0% interest rate), you could later change this to 1000 points to bail everyone out, thereby injecting cash into the economy. Obviously this is going to cause inflation. But again, my thought was that this could all be reported on the stats/ page, if we have a consistent way of calculating inflation over time.

Started forum style discussion. https://github.com/orgs/openpredictionmarkets/discussions/321

Over time, the notion of creating a more robust user model has come up, with the concept perhaps of creating MODERATOR type user accounts rather than just ADMIN.
MODERATORS may have different tiers, there could be an ECONOMIC_MODERATOR and a USER_MODERATOR.
The USER_MODERATOR could be responsible for content and user conduct, e.g. preventing or flagging toxic content. The ECONOMIC_MODERATOR could have more to do with actual economic decision making, such as raising the debt level or sending bailouts, which might be considered much more drastic, non-every-day decisions.
Whereas the ADMIN user type might be a more secure level, that is really in charge of adding users and setting permissions, fundamental application level stuff. Hypothetically there should only be one ADMIN level account and its access should be very secure, and it controls all other user types, including the USER_MODERATOR and ECONOMIC_MODERATOR, however it doesn't have the powers of the moderators, to keep a separation of concerns.
There might be also a, MARKET_MAKER user type which is not a MODERATOR but is designed to play the functions of a traditional market maker, e.g. take positions in exchange for liquidity. Hypothetically the ECONOMIC_MODERATOR can send continual bailouts to the MARKET_MAKER which would be one way of increasing the supply of points into the system beyond just changing the debt level.
If the application were designed this way, then bailouts paid to the MARKET_MAKER could be more transparent and be reported on the /Stats page.


[ScrollArea] Scrollbar presence or size isn't updated on viewport resize

Bug report
Scrollbars don't auto show/hide nor resize when viewport size changes
https://github.com/user-attachments/assets/28a9a753-2e55-4b9a-8781-1071a0e11e04

There is already a resize and ResizeObserver for this 🤔

Can't reproduce it in the /experiments/scroll-area demo, with adjusted styles:
https://github.com/user-attachments/assets/719187e0-7238-4a8a-bcbf-6b2d7918aac3
<div
  style={{
    width: 1500,
    height: 1000,
    background: 'linear-gradient(to bottom, red, white)',
  }}
/>

const ScrollAreaRoot = styled(ScrollArea.Root)`
  width: 700px;
  max-width: 100%;
  height: 80vh;
  border-radius: 6px;
  background: #f5f5f5;
`;

+ conditionally removing the &:hover, &[data-scrolling] selector on the visibility of the scrollbars.

Dug in a bit more, looks like it happens in the docs when spreading the props inside the render element
https://github.com/mui/base-ui/blob/69619428a2e45f9135eb20e07c4be6c7e4dc0ae6/docs/src/components/CodeBlock.tsx#L84
Here's a PR where the scrollbars are always shown: https://github.com/mui/base-ui/pull/1202
To reproduce, resize the window until a code block in any anatomy section should get overflow
Feel free to close this issue if this is an invalid way to use the render prop.


Make DiagnosticEngine thread safe

This allows consumers to emit diagnostics from multiple threads.
Primarily motivated by https://github.com/apple/swift-format/pull/117

Thanks!


Handle unicode characters in vSphere object names

What does this PR do?
Handle unicode in external host tags
Motivation
vSphere support unicode in VM names
Review checklist

[ ] PR has a meaningful title or PR has the no-changelog label attached
[ ] Feature or bugfix has tests
[ ] Git history is clean
[ ] If PR impacts documentation, docs team has been notified or an issue has been opened on the documentation repo

Additional Notes
Anything else we should know when reviewing?

Codecov Report

Merging #2596 into master will decrease coverage by 1.05%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2596      +/-   ##
==========================================
- Coverage   83.88%   82.82%   -1.06%
==========================================
  Files         629       17     -612
  Lines       35753     1345   -34408
  Branches     4363      158    -4205
==========================================
- Hits        29990     1114   -28876
+ Misses       4471      195    -4276
+ Partials     1292       36    -1256


checkpatch.pl incorrect ERROR:POINTER_LOCATION

Describe the bug
-:1733: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1733: FILE: arch/x86/core/x86_mmu.c:535:
+	page_pool[CONFIG_MMU_PAGE_SIZE * CONFIG_X86_MMU_PAGE_POOL_PAGES];

-:4233: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#4233: FILE: include/arch/x86/mmustructs.h:45:
+#define Z_X86_PT_AREA  ((uintptr_t)CONFIG_MMU_PAGE_SIZE * Z_X86_NUM_PT_ENTRIES)

Found in checks for #27001.
Impact
It's leaving a -1 on my patch because this is treated as an error and not a warning.

@pabigot is this an upstream checkpatch.pl issue or did one of our local changes cause this? I don't recall ever running into this before, but I recall we recently pulled up to a new version..

I don't know, but I can tell you that checkpatch thinks that in the given contexts CONFIG_MMU_PAGE_SIZE is a non-pointer type, and that the version of checkpatch before 5b10fac97e emits the same diagnostic.
It treats CONFIG_MMU_PAGE_SIZE as a possible type because it appears in an __aligned() specifier in:
static uint8_t __noinit __aligned(CONFIG_MMU_PAGE_SIZE)
	page_pool[CONFIG_MMU_PAGE_SIZE * CONFIG_X86_MMU_PAGE_POOL_PAGES];

If you change that to:
static uint8_t __noinit __aligned(0+CONFIG_MMU_PAGE_SIZE)

it becomes unconfused.

I sent a patch to turn off the check until this sorts out.
Wondering why it flagged Z_X86_NUM_PT_ENTRIES?
Also seems weird that being inside __aligned() would make this thing think it's a type, since __aligned() takes a size. Anyway, I hate reading Perl code so maybe I'll never know why

checkpatch doesn't care that it's inside __aligned(); it parses that horrific declaration and misinterprets it as a prototype for for a function __aligned with a single CONFIG_MMU_PAGE_SIZE parameter.
The diagnostic can also be eliminated by moving the __aligned() attribute to the end of the declaration, though I haven't confirmed gcc interprets it properly there.
This is upstream checkpatch behavior, not specific to Zephyr.  Modifying the script to detect this situation isn't something I'd take on.

Also from #26785:
-:767: ERROR:SPACING: need consistent spacing around '*' (ctx:WxV)
117
#767: FILE: drivers/pinmux/pinmux_mcux_lpc.c:47:
118
+	IOPCTL_Type *base = config->base;

is an expected failure.  Because Linux and Zephyr disallow typedefs checkpatch can't recognize that IOPCTL_Type is a type, so it complains about a multiplication that's spaced as A *B.

Fixing the diagnostics to be correct is not reasible with checkpatch.pl which is a perl script that cannot accurately parse C code.  It may be possible to disable the check entirely if/when we move to clang-format, but that's some months away.
2020-07-21 Triage suggested two paths to resolving this:

Convert the error to a warning so that failures do not mark a PR as unmergeable;
Acknowledge that checkpatch.pl is not perfect and document known situations where its diagnostic is incorrect and may be ignored.

Taking the first path risks increased introduction of constructs that violate Zephyr's coding style by not attaching the * symbol to the declarator that follows.
The second is addressed by #27035.

Taking the first path risks increased introduction of constructs that violate Zephyr's coding style by not attaching the * symbol to the declarator that follows.

How much of a concern is this really, given the costs of false positives in CI runs which leave a -1? Converting to a warning seems very reasonable to me. But it's also true that this issue has been around for a while and works most of the time, at least.
Ultimately I leave to your discretion how we want to deal with it, I appreciate you taking time to look into this.
I can try to massage my patch to get the warning to go away in the immediate term.


Close#143 | Create dataset loader for Abui WordNet

Closes #143
Checkbox

[ ] Confirm that this PR is linked to the dataset issue.
[ ] Create the dataloader script seacrowd/sea_datasets/my_dataset/my_dataset.py (please use only lowercase and underscore for dataset naming).
[ ] Provide values for the _CITATION, _DATASETNAME, _DESCRIPTION, _HOMEPAGE, _LICENSE, _URLs, _SUPPORTED_TASKS, _SOURCE_VERSION, and _SEACROWD_VERSION variables.
[ ] Implement _info(), _split_generators() and _generate_examples() in dataloader script.
[ ] Make sure that the BUILDER_CONFIGS class attribute is a list with at least one SEACrowdConfig for the source schema and one for a seacrowd schema.
[ ] Confirm dataloader script works with datasets.load_dataset function.
[ ] Confirm that your dataloader script passes the test suite run with python -m tests.test_seacrowd seacrowd/sea_datasets/<my_dataset>/<my_dataset>.py.
[ ] If my dataset is local, I have provided an output of the unit-tests in the PR (please copy paste). This is OPTIONAL for public datasets, as we can test these without access to the data files.

Not sure which task to store the feature, only run the source_only test script output
# yuz @ null in ~/workspace/seacrowd-datahub on git:abui_wordnet o [16:38:53]
$ ls
CONTRIBUTING.md             Makefile                    REVIEWING.md                example                     setup.py                    test_example_source_only.sh
DATALOADER.md               POINTS.md                   UPLOADING.md                requirements.txt            task_schemas.md             tests
LANGUAGES.md                PRIVATE.md                  conda.yml                   seacrowd                    templates                   update_readme.py
LICENSE                     README.md                   docs                        setup.cfg                   test_example.sh
(ani)
# yuz @ null in ~/workspace/seacrowd-datahub on git:abui_wordnet o [16:39:05]
$ python -m tests.test_seacrowd_source_only seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py
INFO:__main__:args: Namespace(path='seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py', schema=None, subset_id=None, data_dir=None, use_auth_token=None)
INFO:__main__:self.PATH: seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py
INFO:__main__:self.SUBSET_ID: abui_wordnet
INFO:__main__:self.SCHEMA: None
INFO:__main__:self.DATA_DIR: None
INFO:__main__:Checking for _SUPPORTED_TASKS ...
module seacrowd.sea_datasets.abui_wordnet.abui_wordnet
INFO:__main__:Found _SUPPORTED_TASKS=[<Tasks.WORD_SENSE_DISAMBIGUATION: 'WSD'>]
INFO:__main__:Checking load_dataset with config name abui_wordnet_source
/Users/yuz/anaconda3/envs/ani/lib/python3.10/site-packages/datasets/load.py:2479: FutureWarning: 'use_auth_token' was deprecated in favor of 'token' in version 2.14.0 and will be removed in 3.0.0.
You can remove this warning by passing 'token=<use_auth_token>' instead.
  warnings.warn(
/Users/yuz/anaconda3/envs/ani/lib/python3.10/site-packages/datasets/load.py:922: FutureWarning: The repository for abui_wordnet contains custom code which must be executed to correctly load the dataset. You can inspect the repository content at seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py
You can avoid this message in future by passing the argument `trust_remote_code=True`.
Passing `trust_remote_code=True` will be mandatory to load this dataset from the next major release of `datasets`.
  warnings.warn(
Generating senses split: 3606 examples [00:00, 45213.43 examples/s]
/Users/yuz/anaconda3/envs/ani/lib/python3.10/site-packages/datasets/load.py:2479: FutureWarning: 'use_auth_token' was deprecated in favor of 'token' in version 2.14.0 and will be removed in 3.0.0.
You can remove this warning by passing 'token=<use_auth_token>' instead.
  warnings.warn(
/Users/yuz/anaconda3/envs/ani/lib/python3.10/site-packages/datasets/load.py:922: FutureWarning: The repository for abui_wordnet contains custom code which must be executed to correctly load the dataset. You can inspect the repository content at seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py
You can avoid this message in future by passing the argument `trust_remote_code=True`.
Passing `trust_remote_code=True` will be mandatory to load this dataset from the next major release of `datasets`.
  warnings.warn(
INFO:__main__:Dataset sample [source]
{'sense': '13152742-n', 'pos': 'n', 'lang': 'abz:lemma', 'lemma': 'waa ata', 'form': ''}
.
----------------------------------------------------------------------
Ran 1 test in 1.064s

OK
(ani)
# yuz @ null in ~/workspace/seacrowd-datahub on git:abui_wordnet x [16:39:44]
$ make check_file=seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py
black --line-length 250 --target-version py38 seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py
All done! ✨ 🍰 ✨
1 file left unchanged.
isort seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py
flake8 seacrowd/sea_datasets/abui_wordnet/abui_wordnet.py --max-line-length 250

Hello, need advice on what seacrowd features we should use for wordnet. Thanks.


[WIP] Feature/state router

What is the purpose of the change
XXXXX
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field 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.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test 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 sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #6844 (f349c9d) into 3.0 (8a4a6b5) will decrease coverage by 0.46%.
The diff coverage is 51.15%.

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


set keyboard type for EditableText

Make the CartStepper only can input with the number keyboard.

Thanks for your suggestion!


Where to specify filename

The protocol implementations I've seen store the chunked data in a .bin file. No where in the protocol does it mention how a client should provide a target file name to move the upload to once complete.
Video and audio files, among others no longer work/are recognized when they've been renamed from something like my_video.mp4 to 036f1378006746bcb40a0e3981257552.bin. Has the protocol left this out for a reason?

When 1.0 will be release the metadata extension should be used for this task.

@MarkMurphy just to clarify

If the metadata is kept out of the body then that would leave the protocol free to use whatever method it wants: stick with the current implementation or go with what I suggested above.

This is what's happening in 1.0 now : )


Fix missed dependency

Fixed error:
POCO ERROR: Exception: Could not determine local time zone: boost::filesystem::canonical: No such file or directory: "/usr/share/zoneinfo/"
terminate called after throwing an instance of 'Poco::Exception'
  what():  Exception

Can one of the admins verify this patch?


Is it recommended to write fuse configuration in TypeScript?

Is it recommended to write fuse configuration in TS, i.e. fuse.ts?
I can't find anything about that in official documentation. Do we have a update to date example repo for that purpose?
I love TS as fusebox did, so really want to know how is it officially supported as for configuration file.
Thanks!

hi @athrunsun
Of course you can use fuse.ts in fact many people do so with ts-node
I had ideas on making cli understand either or fuse.ts or fuse.js. But this is just in plans. If you have further questions please use our Gitter channel ;-)


Wip/firecracker

Motivation for this change
Version bump of firecracker from 0.24.5 to 0.25.2 .
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.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.

My apologies, I'm new to this: Can I fix that whitespace error during this pull request somehow, or should I create a fresh one?

Made superfluous by b93e9e495ea262479e8493baa4002019e44e7abb .


add dcgm daemonset for nvidia

Closed PR: https://github.com/aws/amazon-cloudwatch-agent-operator/pull/81
Previous PR has been closed to move changes to a new feature branch by following the branch naming convention.
Description of changes:

Add new dcgm-exporter daemonset to support NVIDIA GPU metrics with k8s
Add new service that uses dcgm-exporter pods where the traffic is limited within node (no cross nodes communication)
new serviceaccount and role to be used by dcgm-exporter daemonset

The new dcgm-exporter pod has nodeAffinity config that spins up itself in only GPU nodes. The supported GPU instances are hard coded into values.yaml which can be extended when there are more GPU instances/types supported.
Below is the list of pods in test cluster where 1 GPU and 1 non-gpu nodes are.
NAME                                                              READY   STATUS    RESTARTS   AGE
amazon-cloudwatch-observability-controller-manager-xxxxxx   1/1     Running   0          4m17s
cloudwatch-agent-xxxxxx                                            1/1     Running   0          4m16s
cloudwatch-agent-xxxxxx                                            1/1     Running   0          4m17s
dcgm-exporter-xxxxxx                                               1/1     Running   0          4m18s
fluent-bit-xxxxxx                                                 1/1     Running   0          4m18s
fluent-bit-xxxxxx                                                  1/1     Running   0          4m17s

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

integration failure doesn't seem to be related to the changes in PR


Python support

User platform support for Python-based services

I think Python support would be awesome for a variety of use-cases. If someone hesitates or shy to start with, I have a branch here:
https://github.com/marcellanz/cloudstate_python-support/tree/feature/python-support
that establishes in the most simple way first circles between a User Support Library and the CloudState Proxy and also makes part of the TCK happy.
My Python days are way (way) over, but if someone wants to collaborate or even take over I'm happy if this can help to start serious Python support sooner. Everything starts in cloud_state.py

(CloudStateEntityDiscovery for the Shopping Cart TCK Example responding to the CloudState Proxy)

(CloudState TCK with Python having two Tests green)

While working on CRDT support for the go user library progresses, and sometimes working on multiple issues is fun, I started to get working on python support more seriously.
The repository I started last year with minimal TCK success and a "how to get started":
https://github.com/marcellanz/cloudstate_python-support/tree/feature/python-support
has gotten some interest mainly because of the how to start documentation, but not so much that anyone picked it up. After having also support for languages like Kotlin, Swift and C#, Python is an important language because of its (necessary and preffered) usage in certain fields.
I'd like to see help in getting a idiomatic python API for it which is key for a to be used library. I have opened an issue for that and tagged it with a "help wanted":
https://github.com/marcellanz/cloudstate_python-support/issues/1
So Pythonistas, if you have opinions how python APIs should be crafted or want to join in any other way this is the time :)

@viktorklang I think we can close this issue, as we have started with the new python repository and also have a 100% pass of the TCK.

@marcellanz Agreed—thanks @marcellanz!


Should use request.get_json(silent=True)

On line 59, I think it would be better to use:
request.get_json(silent=True)
instead of:
request.json
Then you won't get those The browser (or proxy) sent a request that this server could not understand errors.

.json is now deprecated and raises a warning. See http://flask.pocoo.org/docs/0.11/changelog/:

Deprecated request.json in favour of request.get_json().

I find that if I use
request.get_json(silent=True)

I will get None, but if I use
request.get_json()

I will get the right data.


snap: Make external dependencies actually work

Git:

Set GIT_EXEC_PATH and include usr/lib/git-core so that git can find the git-remote-https helper (needed by e.g. go mod download).

Go:

Put Go in its own snap part, and use stage-snaps instead of build-snaps so that it is included in the final snap.
Set GOCACHE to a writable directory. (In a previous commit, HOME is set to $SNAP_REAL_HOME which is unwritable.)

Hugo:

Patch config/security/securityConfig.go [security.exec] osEnv whitelist (during snap build) so that external dependencies can use the required environment variables to run properly from within the snap.

Asciidoctor:

Replace shebang line in asciidoctor so it can find the ruby executable.
Set RUBYLIB so that Ruby can find its libraries.
Caveat/TODO: The Ruby version is hardcoded in our custom RUBYLIB.

Embedded Dart Sass:

Download from GitHub and install it, for amd64 and arm64 only.

Node.js:

Remove my incomplete include list so that npx is actually installed.
Set npm_config_{cache,init_module,userconfig} to writable locations.

Pandoc:

Set pandoc_datadir so that Pandoc can find its data files.

rst2html:

Install python3-docutils package for rst2html, rst2html5, etc.
Set PYTHONHOME so that Python can find its libraries.
Patch Python docutils so it can find the Docutils HTML templates.

Note that asciidoctor, pandoc and rst2html are not in Hugo’s default [security.exec] allow whitelist, and the snap package does not change that default, so they still needed to be whitelisted manually in config.toml if necessary by the end user.
(The snap size for extended increased from 58 MB to 101 MiB.)
Special thanks to Joe Mooring (@jmooring) for meticulously diagnosing the issue and providing a comprehensive test repository at https://github.com/jmooring/hugo-snap-test without which I would not have been able to understand and resolve the issue.
Fixes #9078

Note to self:
For the git part in snapcraft.yaml, do not replace usr/lib with usr/lib/git-core in prime, or else the libraries that git depends on won't be installed:
The 'git' part is missing libraries that are not included in the snap or base. They can be satisfied by adding the following entries to the existing stage-packages for this part:
- libasn1-8-heimdal
- libbrotli1
- libcurl3-gnutls
- libgssapi3-heimdal
- libhcrypto4-heimdal
- libheimbase1-heimdal
- libheimntlm0-heimdal
- libhx509-5-heimdal
- libkrb5-26-heimdal
- libldap-2.4-2
- libnghttp2-14
- libpsl5
- libroken18-heimdal
- librtmp1
- libsasl2-2
- libssh-4
- libwind0-heimdal

See https://launchpadlibrarian.net/618071831/buildlog_snap_ubuntu_focal_amd64_hugo-extended_BUILDING.txt.gz for the full log.

Hi @jmooring,
Thank you for the review!
I have actually committed the same fix to v0.101.0 in the stable branch, and is now on snapcraft.io.  Please install/refresh the hugo snap to v0.101.0+git4.d7294751 (13802) in the extended/stable channel for testing.
Due to the recently improved security model in Hugo, the following patch needs to be applied to https://github.com/jmooring/hugo-snap-test for the test to pass:
diff --git a/config/_default/config.toml b/config/_default/config.toml
index 3bf5e3a..6306b75 100644
--- a/config/_default/config.toml
+++ b/config/_default/config.toml
@@ -15,3 +15,7 @@ target = 'content'

 [params]
 transpiler = 'dartsass'  # dartsass or libsass
+
+[security]
+  [security.exec]
+    allow = ['^asciidoctor$', '^dart-sass-embedded$', '^go$', '^npx$', '^pandoc$', '^postcss$', '^rst2html$']

Many thanks!

@anthonyfok
This looks like a git error...
jmooring@vm-joe-ubuntu:~/code/hugo-snap-test (main)$ /snap/bin/hugo version
hugo v0.101.0-d729475172621286ea48868f942de645bfcc16fa+extended linux/amd64 BuildDate=2022-08-13T17:30:23Z VendorInfo=snap

jmooring@vm-joe-ubuntu:~/code/hugo-snap-test (main)$ /snap/bin/hugo
go: no module dependencies to download
go: github.com/jmooring/hugo-content@upgrade: module github.com/jmooring/hugo-content: git ls-remote -q origin in /tmp/hugo_cache/modules/filecache/modules/pkg/mod/cache/vcs/e44c3fb411a597d9244a8f9d0a81fbc7bf888ecfaff91f60e787bf01190fb606: exit status 128:
        fatal: unable to find remote helper for 'https'
hugo: collected modules in 627 ms
Error: failed to get ["-d" "github.com/jmooring/hugo-content@upgrade"]: failed to execute 'go [get -d github.com/jmooring/hugo-content@upgrade]': failed to execute binary "go" with args [get -d github.com/jmooring/hugo-content@upgrade]: go: github.com/jmooring/hugo-content@upgrade: module github.com/jmooring/hugo-content: git ls-remote -q origin in /tmp/hugo_cache/modules/filecache/modules/pkg/mod/cache/vcs/e44c3fb411a597d9244a8f9d0a81fbc7bf888ecfaff91f60e787bf01190fb606: exit status 128:
        fatal: unable to find remote helper for 'https'
 *errors.errorString

@jmooring, thank you for testing!
Hmm... strange... I thought I explicitly fixed the fatal: unable to find remote helper for 'https' error by setting GIT_EXEC_PATH to $SNAP/usr/lib/git-core, and by patching Hugo to whitelist GIT_EXEC_PATH so Hugo would not hide GIT_EXEC_PATH from go and git.
Could you please try running the following commands and see if you get what I got?
ubuntu@primary:~/code/hugo-snap-test$ snap run --shell hugo
bash: /home/ubuntu/.bashrc: Permission denied
ubuntu@primary:~/code/hugo-snap-test$ echo $GIT_EXEC_PATH
/snap/hugo/13802/usr/lib/git-core
ubuntu@primary:~/code/hugo-snap-test$ ls -l $GIT_EXEC_PATH/git-remote-https
lrwxrwxrwx 1 root root 15 Jul  5 09:13 /snap/hugo/13802/usr/lib/git-core/git-remote-https -> git-remote-http
ubuntu@primary:~/code/hugo-snap-test$ ls -l $GIT_EXEC_PATH/git-remote-http
-rwxr-xr-x 1 root root 1839328 Jul  5 09:13 /snap/hugo/13802/usr/lib/git-core/git-remote-http
ubuntu@primary:~/code/hugo-snap-test$ git ls-remote -q origin
1ddbce712b9ea231fccb2ecb85f79de4edf74fc4	HEAD
1ddbce712b9ea231fccb2ecb85f79de4edf74fc4	refs/heads/main
ubuntu@primary:~/code/hugo-snap-test$ exit
ubuntu@primary:~/code/hugo-snap-test$ echo $GIT_EXEC_PATH

ubuntu@primary:~/code/hugo-snap-test$

Next, please share your output of /snap/bin/hugo config | grep ^security.  Here is what I got:
ubuntu@primary:~/code/hugo-snap-test$ /snap/bin/hugo config | grep ^security
security: map[enableinlineshortcodes:false exec:map[allow:[^dart-sass-embedded$ ^go$ ^npx$ ^postcss$ ^pandoc$ ^rst2html$ ^asciidoctor$]]]

Also, please double check in config/_default/config.toml (or similar) and see if you have customized [security.exec] osEnv in your config file(s).  The snap version of hugo has this patched osEnv whitelist built-in:
[security]
  enableInlineShortcodes = false
  [security.exec]
    allow = ['^dart-sass-embedded$', '^go$', '^npx$', '^postcss$']
    osEnv = ['(?i)^(PATH|PATHEXT|APPDATA|TMP|TEMP|TERM|GIT_EXEC_PATH|LD_LIBRARY_PATH|npm_config_(cache|init_module|userconfig)|pandoc_datadir|PYTHONHOME|RUBYLIB|SNAP)$']

where the GIT_EXEC_PATH|LD_LIBRARY_PATH|npm_config_(cache|init_module|userconfig)|pandoc_datadir|PYTHONHOME|RUBYLIB|SNAP regex snippet is newly added.
And, please share with me the version of Ubuntu of vm-joe-ubuntu.
(I tested on Debian (bare-metal), on Ubuntu 20.04 LTS in QEMU/KVM (launched with multipass), and on Ubuntu 22.04 LTS in LXD; I am going to try the same test on a bare-metal 22.04 LTS next.)
And, one more experiment that you might like to try, but only if you are sure there is no important user, system and configuration data inside the hugo snap:

Run snap saved to list existing snapshot
Use snap forget to remove old snapshots related to hugo, see https://snapcraft.io/docs/snapshots and its "Deleting a snapshot" section.
Run sudo snap remove hugo --purge which "removes the snap without saving a snapshot of its data"
Run sudo snap install hugo (the extended/stable channel is the default now.)
Test with your hugo-snap-test repo again.

Many thanks for your help!

@anthonyfok
Everything looks good. I had exported HUGO_SECURITY_EXEC_OSENV from ~/.bashrc, and it did not include:

GIT_EXEC_PATH
LD_LIBRARY_PATH
npm_config_(cache|init_module|userconfig)
pandoc_datadir
PYTHONHOME
RUBYLIB
SNAP

So I added all of them, and the test was successful.
Then I removed each, one at a time, re-sourced ~/.bashrc, and tested again. On my system I found that I did not need:

GIT_EXEC_PATH
npm_config_(cache|init_module|userconfig)

Or to put it another way, this works:
export HUGO_SECURITY_EXEC_OSENV="(?i)^(PATH|PATHEXT|APPDATA|TMP|TEMP|TERM|DISPLAY|HOME|LD_LIBRARY_PATH|pandoc_datadir|PYTHONHOME|RUBYLIB|SNAP)$"

@anthonyfok
By the way, GREAT WORK! Thank you!

Hi @jmooring,
Thank you so much for sharing your thorough testing results!
(And I didn't know of HUGO_SECURITY_EXEC_OSENV!  Cool!  I learned something new today!)

Then I removed each, one at a time, re-sourced ~/.bashrc, and tested again. On my system I found that I did not need:

GIT_EXEC_PATH

Looks like the Hugo modules are cached in /tmp/hugo_cache from a previous successful run, and go is satisfied with the cached modules that it does not invoke git again.  However, if you were to do this:
$ snap run --shell hugo
----- entering the hugo snap environment -----
$ chmod -R u+w /tmp/hugo_cache
$ rm -rf /tmp/hugo_cache
$ exit
----- leaving the hugo snap environment -----
$ /snap/bin/hugo

(or if you were to add a new Hugo module that has not been cached yet), you'll see the fatal: unable to find remote helper for 'https' error returns.

npm_config_(cache|init_module|userconfig)

Interesting!  It looks like whitelisting HOME negates the need to whitelist npm_config_cache, npm_init_module and npm_userconfig.
Thank you for your insights!  I think this does show that some kind of documentation would be helpful, especially if the end user has customized [security.exec] osEnv in config.toml or has defined HUGO_SECURITY_EXEC_OSENV, they wouldn't have known what extra environment variables need to be whitelisted for Hugo snap.  I should file an issue on gohugoio/hugoDocs.  :-)

Hi @bep!  For completeness, I wrote a test GitHub workflow to see if the latest Hugo snap passes jmooring/hugo-snap-test, see the test results here: https://github.com/anthonyfok/test-github-workflows/runs/7841718472?check_suite_focus=true
Please take a quick look of this PR when you are free, and let me know if anything needs to be changed, and please merge it if it is OK.  Many thanks!  :pray:

@anthonyfok

Looks like the Hugo modules are cached in /tmp/hugo_cache from a previous successful run, and go is satisfied with the cached modules that it does not invoke git again.

You are correct. GIT_EXEC_PATH is required. Thanks for the explanation.
For completeness, I spun up a virgin Ubuntu 22.04 VM, installing only:

Git (to clone the test repo)
Node.js (to install the test repo's Node dependencies)
Hugo snap (to build the site)

It worked perfectly.


undefined behavior

/lib/jxl/dec_huffman.cc line 73
Maybe here is a shift of a negative value possible.
Code:
 old_repeat = repeat;
  if (repeat > 0) {
    repeat -= 2;
    repeat <<= extra_bits; // shift if repeat == -1
  }

The next line is
repeat += (int)br->ReadBits(extra_bits) + 3;

repeat can never be 1, or 2, since it starts from 0, then it is at least 3, and from then on it can only increase until it is set to zero again. Note that extra_bits is at least 2, therefore (repeat - 2) << extra_bits is greater than repeat.


The "Find step definition usages" command is not visible for SpecFlow projects

Used Visual Studio
Visual Studio 2022
Are the latest Visual Studio updates installed?
Yes
Content of reqnroll.json (if present)
No response
Issue Description
The "Find step definition usages" command is not visible for SpecFlow projects
Steps to Reproduce

Open a SpecFlow project
Go to a valid step definition method
Check the context menu: the "Find step definition usages" command is missing

Link to a project repository that reproduces the issue
No response

Fixed by #12, thans @clrudolphi!


CardVault available for Android TV

CardVault available for Android TV

Rotation on CardVaultActivity gets locked according to the previous activity. The same happens in GuessingCardActivity, BankDealsActivity, IssuersActivity, InstallmentsActivity and TermsAndConditionsActivity
All the views in GuessingCardActivity are focusable with a dpad on Android TV. Previous and Continue buttons are also available to select with a dpad.
All the items in the issuers and installments lists are focusable and selectable with a dpad on Android TV
The list in BankDealsActivity is focusable to be able to navigate it with a dpad on Android TV, and the items can be selected to show its terms and conditions

Demo Videos
Seeing promotions
Navigation in guessing form
Selecting issuer and installments
Closes issue #154
Requirements

[ ] Coverage > 90%

Note:
Can't make tests to run specifically in Android TV emulator.

[X] Android Lint check

Note:

[ ] Code Style checked

Note:
Waiting for Codacy
If impacts documentation (new components, inputs or outputs?)

[ ] PR to develop-docs

Note:
It doesn't

👍


Setup with Gradle

You may wanna check that https://github.com/UnAfraid/TelegramBotAPI/commits/feature/gradle


Rebuild docs automagically with Travis

Need to dig into this a bit more, but this would probably mean moving docs to the gh-pages branch, and rebuilding every time there's a commit to master.

Doing the gh-pages on locopy if you want to steal anything.
https://capitalone.github.io/Data-Load-and-Copy-using-Python/developer.html#generating-documentation

No longer using Travis. Closing


Hyperlink DOIs against preferred resolver

Hello :-)
The DOI foundation recommends this new resolver. Yes, a bit ironic that they would change the URL of their service, but it's now encrypted. Because the old links with the dx subdomain continue to work, there is no urgent need to do anything.
However, I'd hereby like to suggest to follow the new recommendation and update the baseurl.
Cheers!
PS: Maybe in this repo's description also. Can't change that through a PR ;-)

Thank you! :D

You're welcome, and thanks for merging :-)