Nesting schemas doesn't nest defaultValues

When nesting these schemas, defaultValues aren't nested.
Schema.users = new SimpleSchema({
  stats: { type: Schema.stats  }
  // expected behavior is that nesting Schema.stats implies a nested default.  e.g.
  // defaultValue: { topicCount: 0 }
});

Schema.stats = new SimpleSchema({
  topicCount: {
    type: Number,
    defaultValue: 0
  }
});

Meteor.users.attachSchema(Schema.users);

This doesn't seem to be the case, and causes some confusion.
The best I can come up with as a work-around is to include the default value in both schemas, which is extra maintenance and not documented in defaultValue or combining schemas
Schema.users = new SimpleSchema({
...
  stats: {
    type: Schema.stats,
    defaultValue: { topicCount: 0 },
  }
});

Schema.stats = new SimpleSchema({
  topicCount: {
    type: Number,
    defaultValue: 0
  }
});

Meteor.users.attachSchema(Schema.users);

It's not the end of the world, but it would be nice to write this code in just one place.

example from #418

I'm pretty sure this should work in v2


noting much

Remove the console.logs and change your DB password bruh who pushes their DB password to a public repo


Update stable version in repo from 0.5.0 to 0.6.0

Think about update stable version to 0.6.0
Version: stable=0.5.0 (755 days old) => latest=0.6.0 (15 days old)
Installs: stable=2543 (60.45%), latest=279 (6.63%), total=4207
Click to use developer portal
Click to edit
Do not close this issue manually as a new issue will be created if condition for update still exists.
Please drop a comment if any reason exists which blocks updating to version 0.6.0 at this time.
Note: This is an automatically generated message and not personally authored by bluefox!
@mcm1957 for evidence

This issue seems to be outdated.
This issue suggests to update the stable version of this adapter to 0.6.0 but the current stable version is already 0.6.0.
So this issue should be closed.
@mcm1957 for evidence


⚠ TROJAN 🇮🇩 Indonesia IDJ 1 has degraded performance

In 1df02c2, TROJAN 🇮🇩 Indonesia IDJ 1 (https://idt-1.opensvr.net/) experienced degraded performance:

HTTP code: 200
Response time: 22066 ms

Resolved: TROJAN 🇮🇩 Indonesia IDJ 1 performance has improved in 71813a7.


Optimize Tekton Pipeline

Tekton Pipeline has matured since the inception but at the same time, the project is under active development. Many organizations have adopted Tekton Pipelines for various use cases. For the project at this level of maturity and use, reliability must be maintained. The users should be able to upgrade their pipelines to the latest release without running into any performance degradation.
We have noticed a couple of issues reported with a similar concern around efficiency - webhook timing out or the cluster is not responsive for a pipeline with large number of tasks.
Today, we have no records of how much time a certain pipeline takes to execute with the  latest release compared to N number of the past releases.
We have had a couple of PRs in the past trying to introduce some form of performance test:

https://github.com/tektoncd/pipeline/pull/4378
https://github.com/tektoncd/pipeline/pull/3554

Let's start writing performance tests to report the execution time. The performance tests can be scheduled to execute every night. We collect the execution time in logs for now until we come up with a better way of storing these numbers.
As a performance measure, we could also avoid validating task/pipeline spec in every iteration - https://github.com/tektoncd/pipeline/pull/4562.

[ ] Determine if we can avoid validating specifications every reconcile cycle.
[ ] Create a test with a complex pipeline to log time taken to validate.
[ ] Write a test to create a pipelineRun with a complex pipeline (multiple tasks with taskRef and taskSpec along with many whenexpressions).
[ ] Create multiple taskRuns in parallel - something similar to https://github.com/tektoncd/pipeline/pull/4378
[ ] Create multiple pipelineRuns in parallel and log timing.

This seems similar to https://github.com/tektoncd/community/issues/602

/assign

From the pipeline WG - it would be good to break this down in smaller items we can target to milestones.

It seems like this issue is largely scoped to benchmarking. I did a bit recently to test out a feature I was working on and want to share my progress here.
I wrote some scripts that generate N copies of a PipelineRun, wait until all N are complete, and write timing info to a file. If the script is cancelled, it will cancel any currently running PipelineRuns and report on all of them regardless of whether they have completed. This could be a good starting point for anyone who wants to implement benchmarking. Code changes are on the branch https://github.com/lbernick/pipeline/tree/perftest.
Some things that still need to be figured out:

Where would we run this? We wouldn't want to generate lots of runs on our CI cluster, and I'm not sure if a kind cluster could handle a large number of PipelineRuns.
What's the best way to output perf data so that it can be stored over time and referred to easily? We might be able to run tests using Tekton, and store results using Tekton results; we could also use prometheus but I'm not sure how we'd easily separate out metrics related to benchmarking.
What metrics do we care about specifically? I think this is what https://github.com/tektoncd/pipeline/issues/540 is trying to tackle (also some more detail in https://docs.google.com/document/d/1Rme6UQ0i03W_Fg3pefJ8aJ9G73IBnijUISTL2R9XmzU/ -- thanks @pritidesai!)

Some other tools we can look into:

https://github.com/kubernetes/perf-tests
https://kube-burner.readthedocs.io/en/latest/cli/

/lifecycle frozen

@pritidesai - we marked this as "nice to have" for v1 - please let us know if you disagree.


macos Catalina:  when starting vscode from the command line, I get output to both stdout and stderr

VSCode Version: 1.15.1
OS Version: 19.6.0 Darwin Kernel Version 19.6.0

When I start code from the command line, I get a lot of output.  I have never seen any such output on WSL, Windows 10, or Linux.
$ code .bash_profile
[main 2020-12-01T03:33:18.807Z] update#setState idle
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
(node:25689) Electron: Loading non-context-aware native module in renderer: '/Applications/Visual Studio Code.app/Contents/Resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:25689) Electron: Loading non-context-aware native module in renderer: '/Applications/Visual Studio Code.app/Contents/Resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:25734) Electron: Loading non-context-aware native module in renderer: '/Applications/Visual Studio Code.app/Contents/Resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
2020-11-30 21:33:24.465 Code Helper (Renderer)[25689:5561253] CoreText note: Client requested name ".NewYork-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-11-30 21:33:24.465 Code Helper (Renderer)[25689:5561253] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.
2020-11-30 21:33:24.470 Code Helper (Renderer)[25689:5561253] CoreText note: Client requested name ".NewYork-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
[main 2020-12-01T03:33:48.813Z] update#setState checking for updates
[main 2020-12-01T03:33:49.205Z] update#setState idle

Steps to Reproduce:

keyin code from bash in either Terminal or iTerm2

Furthermore, the following commands produce no output

keyin code --version
keyin code --help

Does this issue occur when all extensions are disabled?: Yes/No
yes

FYI, I renamed ~/.vscode, removed and downloaded vscode anew.  No changes in the behavior described above.
Version: 1.51.1
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-11T01:11:34.018Z (2 wks ago)
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0

Same happens to me on Windows 10.

Same issue on macOS Monterey.
[main 2022-06-10T00:03:38.513Z] Starting extension host with pid 31190 (fork() took 1 ms). [main 2022-06-10T00:03:45.491Z] Extension host with pid 31190 exited with code: 0, signal: null. 2022-06-10 02:03:45.711 Code Helper (Renderer)[31188:1137537] CoreText note: Client requested name ".NewYork-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. 2022-06-10 02:03:45.711 Code Helper (Renderer)[31188:1137537] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug. [main 2022-06-10T00:03:45.885Z] Starting extension host with pid 31216 (fork() took 0 ms).

Logs are from the runtime and cannot be disabled. Output should be better with recent versions.


Use a default of Any for the ImportString type variable

The runtime behavior is to allow anything if ImportString isn't parametrized. We reflect this by providing a default value to the type variable, so that type checkers don't complain on missing parametrization.
Requires:

https://github.com/pydantic/pydantic/issues/10197

Change Summary

Related issue number

Checklist

[ ] The pull request title is a good summary of the changes - it will be used in the changelog
[ ] Unit tests for the changes exist
[ ] Tests pass on CI
[ ] Documentation reflects the changes where applicable
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

I'll have to take a deeper look on how this plays with mypy..

LGTM once we resolve mypy test issues!

Might want to ping DM if you're having trouble with mypy stuff.

Closing for now as we're blocked on the mypy front. Happy to revisit later :).


chore(master): release blossom-ext 0.2.2

:robot: I have created a release beep boop
0.2.2 (2023-03-01)
Bug Fixes

buffer serialization (#114) (1616fd1)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/fairDataSociety/blossom/releases/tag/blossom-ext-v0.2.2 :sunflower:


Spell importer

Adds an importer to import spells from text.

Description on your macros needs to be updated. Says "This macro can be used to open the monster importer"
Also you seems to have included changes to a random pack file. Please remove.

Completes #680


Annotate generated classes

Description
Now that we can do id AS VALUE and version AS LOCK and there's also the json extension would it be possible to support Parcelable using an extension?
As for the syntax I'd imagine something like this:
import android.os.Parcelable;
import kotlinx.android.parcel.Parcelize;

CREATE TABLE @Parcelize foo AS Parcelable (
  id TEXT NOT NULL PRIMARY KEY,
  state INTEGER NOT NULL,
);

This only works when adding the parcelable extension similar to how the json extension works. Ideally, the same syntax can be used for CREATE VIEW.

It should also allow typealiasing to those types as when using Kotlin Multiplatform you usually do something like:
commonMain:
expect interface Parcelable

@OptIn(ExperimentalMultiplatform::class)
@OptionalExpectation
@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.BINARY)
expect annotation class Parcelize()

androidMain:
actual typealias Parcelable = android.os.Parcelable
actual typealias Parcelize = kotlinx.android.parcel.Parcelize

iosMain:
actual interface Parcelable

I would consider adding something so SQLDelight module extensions can annotate the generated type, but as I always say to feature requests like this - modifying the dialect is always always always my last resort and I don't think is necessary here, so the extension would just make every type that module is applied to extend parcelable, or you hardcode the types in your extension.
Anyways, unlikely to land a specific parcelable extension in SQLDelight but I think the ability to extend how a data class is annotated in an extension could make sense.

so the extension would just make every type that module is applied to extend parcelable, or you hardcode the types in your extension.

Sounds good

I think the ability to extend how a data class is annotated in an extension could make sense.

Sounds good as well

The biggest problem is the missing Kotlin representation. We currently use sql-psi and kotlinpoet directly. This works, but changing the generated kotlin representation is hard because kotlinpoet does not have a kotlin representation. Sure, you have typespec and all the stuff, but often we only use CodeBlock, which does not have any semantics.
Supporting parcelable by adding the annotation and the interface should be easy to implement, except advanced parcelable support.
But another use case, at least for me, is renaming the attributes of the query class. This does not only change the query class, but all usages too which is hard to implement with kotlin-poet only.

Probably a lot, this would be a major feature though and I really want to just stay focused on fixes until we get 2.0 out

Absolutely 👍🏻

Will this become a feature in future releases?

Is there no way we get SqlDelight to just Export entities to JS, via kotlin.js.JsExport. I understand you try to solve this problem generically. But i think this could be a valid use case in the future for many People.
I would like to use the same SQLite definition in my Frontend and Backend, for that the reuse of the entity would be much appreciatet. I currently also write a wrapper for each database Query to parse it to a Promise

Is there no way we get SqlDelight to just Export entities to JS, via kotlin.js.JsExport. I understand you try to solve this problem generically. But i think this could be a valid use case in the future for many People.
I would like to use the same SQLite definition in my Frontend and Backend, for that the reuse of the entity would be much appreciatet. I currently also write a wrapper for each database Query to parse it to a Promise

I'm doing the same and it eats too much time.


Discuss pros and cons in README

It would be nice to understand the pros and cons of this package's token-based approach relative to other approaches (saxix/django-concurrency and gavinwahl/django-optimistic-lock).
See, e.g.,the discussion at https://github.com/gavinwahl/django-optimistic-lock#comparison-to-django-concurrency
Thanks!

That's a good idea, I will add some explanations to the README file.
To answer quickly, here are some advantages of the package:

No need to modify your models to use the locking mechanism : you don't "pollute" your datamodel with "non-data" fields. This also means you can use the locking mechanism on third party models that cannot be modified.
No need to use sessions (but you can still use it if you need).
Mechanism to check that an object is locked BEFORE trying to modify it.
Rest API (+ javascript client to use it) out-of-the-box.
Admin interface integration

Of course the packages you mention also cover some of those points, but I could not find any package that covers all of them at once.
This package was originally developed to prevent concurrency editing of complex objects via a web interface using AJAX calls. This can help you understand what kind of issues the package tries to resolve!


git clone Filename too long

While building latest 120.0.6099.109 I encountered this error:
Cloning into 'build\src'...
remote: Finding sources: 100% (433407/433407)
remote: Total 433407 (delta 93458), reused 276340 (delta 93458)
Receiving objects: 100% (433407/433407), 1.19 GiB | 11.54 MiB/s, done.
Resolving deltas: 100% (93458/93458), done.
error: unable to create file third_party/blink/web_tests/virtual/async-script-scheduling-finished-parsing-with-dom-content-loaded-wait-for-async-script/wpt_internal/async-script-scheduling/execution-order.sub_default-expected.txt: Filename too long
I have LongPathsEnabled, but I don't that's related
Quick search, and this seems to fix it.
git config --system core.longpaths true
I suggest adding this to README build requirements.

I believe this is already part of the readme?

Make sure to lift the MAX_PATH length restriction, either by clicking the button at the end of the Python installer or by following these instructions.

Yep I had the same error when I first tried to build, I can confirm that LongPathsEnabled at 1 doesn't seem to do anything for this problem, I just moved the whole folder to a place where it would have a shorter path.

I hope your question(-s) has(-ve) been answered, otherwise please let us know.
Closing this issue for now.


[BDW][Media][Decode/Encode]The usage information of yamivpp feature is not comprehensive and not detailed

1.Testing environment:
Libva:                      (master)4763db1c2133d4e6b92355938ecb6f23a7767b6b
Libva_intel_driver:   (master)4a1c4d21f3428b08ef765d7f7de75b97006514ac
libyami:                    (master)5c64c7237e06e41d0c64b4bc97c5d74900531786
2.Test command
(1) /home/wenxin/libyami/libyami/tests/yamivpp -h
usage: yamivpp input_1920x1080.i420 output_320x240.yv12
(2) there are little detailed information for VPP.

HI Keqiao:
it's fixed by #291. Please help to verify.
thanks

hi Guangxin,
After verified, the usage for yamivpp is detailed now, list as following:
./yamivpp -h
a tool to do video post process, support scaling and CSC
we can guess size and color format from your file name
current supported format are i420, yv12, nv12
usage: yamivpp input_1920x1080.i420 output_320x240.yv12
so this bug can be closed.


Lighthouse DNS unable to handle TCP retries after truncation

What happened:
We have >200 pods behind a headless service in our fleet of clusters.
We are making DNS requests for the headless service (<service>.<namespace>.svc.clusterset.local) which is supposed to return >200 A records (one for every pod).
dig <service>.<namespace>.svc.clusterset.local @<pod IP of lighthouse DNS> works as expected.
dig <service>.<namespace>.svc.clusterset.local @<clusterIP of lighthouse DNS> does not work, returns SERVFAIL.
What you expected to happen:
Per RFC1035 and RFC2181, DNS messages over UDP are limited to 512 bytes. Messages above limit are truncated. Server sents back response with TC bit set, after which client is supposed to retry with TCP.
But lighthouse DNS clusterIP service only exposes UDP port and not TCP port: https://github.com/submariner-io/submariner-operator/blob/ee76b5244c4a3090a2f5877461e84087048ef6fb/controllers/servicediscovery/servicediscovery_controller.go#L388-L396
We manually created a copy of clusterIP service with TCP port added (updating existing service was not possible because controller would overide our changes). After which dig <service>.<namespace>.svc.clusterset.local @<copied clusterIP of lighthouse DNS> began working.
Can we make change in submariner-operator to include TCP port in submariner-lighthouse-coredns clusterIP service?
How to reproduce it (as minimally and precisely as possible):
Create many pods (>200) behind a headless service.
dig <service>.<namespace>.svc.clusterset.local @<pod IP of lighthouse DNS> works as expected.
dig <service>.<namespace>.svc.clusterset.local @<clusterIP of lighthouse DNS> does not work, returns SERVFAIL.
Anything else we need to know?:
Environment:

Diagnose information (use subctl diagnose all):
Gather information (use subctl gather)
Cloud provider or hardware configuration:
Install tools:
Others:

Can we make change in submariner-operator to include TCP port in submariner-lighthouse-coredns clusterIP service?

We welcome contributions.  Please submit a PR.


Add a new scene and connection code to receive HoloLens poses from the camera

This change has a few main parts:

A new scene (SpectatorViewCamera) that represents the application that runs on the holographic camera rig. In this PR, the app provides time-adjusted poses from the HoloLens to the compositor and transfers a JSON blob of calibration data. This data is not understood by the SpectatorViewCamera scene, it's up to the compositor to parse and understand that data blob.
UI has been added to the Compositor window to connect to the SpectatorViewCamera app using TCPConnectionManager.
There's a registry of calibration parsers (currently there are zero checked in) that can receive calibration data and attempt to parse it into an ICalibrationData.

With an internal calibration I've tested the end-to-end workflow of connecting the camera rig to the compositor and filming a cube floating in space using the rig.

    private ICalibrationData calibrationData;

Do you not get "unused variable" warning when building non-editor?

Refers to: Assets/MixedRealityToolkit.Extensions/SpectatorView/Scripts/Compositor/CompositionManager.cs:80 in a352b1c. [](commit_id = a352b1ce0850b8941186f7deaf247c3db56552bb, deletion_comment = False)


documentation / tutorial unclear usage of helpers

When reading the documentation of helpers (https://angular-meteor.com/api/angular-meteor/1.3.11/helpers) it states that helpers should be used in conjunction with collections. Mainly it says that the helper functions must return a Mongo.Cursor.

Each value of the object must be a function that returns a Mongo.Cursor.

When you look at the tutorial for the socially application in the chapter bindings (https://angular-meteor.com/tutorials/socially/angular1/bindings) the helper is used in combination with findOne()

We'll expand the PartyDetails by using helpers method, and we will use findOne method from the Mongo.Collection, which returns a single object

Can you please clarify how helpers should be used and update the docs/tutorial accordingly?
Personally I used findOne() with helpers and it always worked as expected. What would be an alternative to make the result of a findOne() reactive (when the document changes, how can I detect that change inside an autorun and/or render the new data on the screen?). I experimented quite a bit using subscriptionHandle.ready() which works, but it doesn't feel right to call findOne everytime the subscription changes).
Thank you

closing due to inactivity and cleanup after tons of new updates in the recent month.
Feel free to open a new issue if you are still affected .


Custom Thread Pool for Reconciler Execution

Currently ThreadPoolExecutor is used to manage threads for the reconciliation.
Controllers are a little bit specific since at startup all the resources are reconciled, which can mean a large initial burst, while for the rest of the execution Thread utilization might be much smaller.
This situation might be covered relatively fine with a configuration for ThreadPoolExecutor that is created similar to the  newCachedThreadPool
That provides a virtually unbound number of Threads, which are discarded from the pool if not used actively anymore. Since reconciliation is ideally fast (at least the majority on startup), the number of threads should never grow too big. Note that rejecting a task from the executor is not something that we can allow now.
On the other hand, it is not uncommon, that some controllers manage hundreds of thousands of resources and the reconciliation might not be that fast in all cases. So we would like to limit the number of threads even if that limit is quite high, and on startup have the rest of the resource queued and processed. Unfortunately, there is no such thing as, "queue the rest of incoming tasks" if the maximum thread count is reached in ThreadPoolExecutor.
So ideally the executor that we would need is very similar to the ThreadPool executor, but with an additional (maybe bounded) queue, that will queue up the tasks even if the maximum number of Threads is reached in the pool.
Notes:
see also: https://github.com/operator-framework/java-operator-sdk/pull/2262

After discussing though, ideally, when reconciliation on startup is executed there are no I/O bound operations on the reconciliation. A fixed thread pool might just be good enough to do the job in general.


--file command-line option does not change working directory for resolving relative paths in release.values

Describe the bug
Not quite sure if it's a bug or expected behavior, but using helmwave build --file deploy/helmwave.yml result in WARNING: skipping: local file not found issues.
It seems that helmwave is looking for values files inside current working directory rather than inside deploy directory where helmwave.yml is located.
** General info (please complete the following information):**

OS: any
Helmwave Version: 0.19.3

To Reproduce

Create deploy/helmwave.yml file:

project: test-project
version: 0.0.1

repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

releases:
  - name: nginx
    namespace: test-server
    chart:
      name: bitnami/nginx
      version: 13.1.0
    values:
      - nginx.yml

Create deploy/nginx.yml file:

commonAnnotations:
  test-app: test-server

Run helmwave build -f deploy/helmwave.yml
Look for warnings in the STDOUT:

[🙈 aka WARNING]: skipping: local file not found
	values src: nginx.yml
	values dst<EMAIL_ADDRESS>	release: nginx@test-server

Expected behavior
I would expect helmwave to look for values files inside deploy directory.

Nowadays we have no '--context' flag. Maybe we should add this option.
But today, you can fix it like that
project: test-project

repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

releases:
  - name: nginx
    namespace: test-server
    chart:
      name: bitnami/nginx
      version: 13.1.0
    values:
      - {{ filepath.Dir (requiredEnv "HELMWAVE_TPL") }}/nginx.yml

export HELMWAVE_TPL=deploy/helmwave.yml.tpl
export HELMWAVE_TEMPLATER=gomplate
helmwave build --yml

or use just bash
pushd deploy
helmwave build -f
popd

Yup, I am using pushd ... popd workaround for now, but at first I didn't notice the warnings about skipped values files and it was rather confusing why I have incorrect settings in final manifests. So I assumed that pointing this out in an issue could help others.
Thanks for your work on the product and prompt reply.

BTW I don't think that approach with --context is the best one. The location of helmwave.yml seems reasonable default.

On the other hand changing default context from current working directory to helmwave.yml location will break backwards compatibility, so there is a place for discussion regarding what is more important in this case.

We could introduce --context (or --chdir like terraform does) flag that would be cwd by default for backward compatibility. That wouldn't break anything.
On the flip side we haven't released 1.0.0 yet so we can break compatibility (and do it sometimes).
About skipped values - yeah, that seems to be a real issue. I don't even know why did we do that a year ago in v0.12.5. But I guess we can introduce --strict flag for strict checking (missing values, missing dependencies, etc.). I guess, that should be a separate issue.
@zhilyaev your thoughts?

@zhilyaev I guess we can close this as we did that in 0.20.0

Я что-то не смог понять как этим пользоваться - есть где-то дока?

Я правильно понимаю что фиксом является добавление флага strict и никакого --context или chdir добавлено  не было?

@Blobson Именно так, верно


Bug: Changing the current word under the cursor broken

Hey, when I use the snippet provided in the config to rename a variable it works, as long as I don't completely remove the previous variable.  Hopefully the video explains it better.
Also an aside question, does this use the AST for renaming?
https://github.com/smjonas/inc-rename.nvim/assets/17084284/3d2250b3-f97e-448e-ab75-a9dc403ed8be
This is how my config looks like right now. I'm using Lazy as my plugin manager
return {
  "smjonas/inc-rename.nvim",
  config = function()
    require("inc_rename").setup()
    vim.keymap.set("n", "<leader>rn", function()
      return ":IncRename " .. vim.fn.expand("<cword>")
    end, { expr = true })
  end,
}

This is the neovim version I'm running
➜ nvim --version
NVIM v0.9.1
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

I was using Pyright and jedi-language-server.

Hy guys, any date to fix that issue ??  I had the same problem here using the  "js/ts language server" at lazyvim

I've also had this issue constantly happening inside of TS while writing vuejs code. It somehow just deletes more than it should. Not sure why.

Hy guys, any date to fix that issue ?? I had the same problem here using the "js/ts language server" at lazyvim

@pmartinsdev Thanks for also reporting this issue. Can you please provide me with example code where this is happening? It's hard for me find out what the problem is without that.

I mentioned this in #53 too.

Something I noticed and could have the same root problem:
1. Same project, same file
2. line 92 and try renaming ParseContext.
3. Add a couple of characters and have a look at the preview. With every new character added to the rename, the previously added characters should appear again with every new character you add. Hard to describe but the number of characters shown in the preview is the factorial of the number of characters added to the rename.
(not sure if you can reproduce it tho because that behavior is a bit less predictable)

You should be able to reproduce this with the second example.

Did anyone still observe this issue? If not, this issue can be closed

I haven't used the pluggin in a while. I can try it out tomorrow and report if the issue persists. However I am not using the same machine as the one I reported the issue in.

I haven't used the pluggin in a while. I can try it out tomorrow and report if the issue persists. However I am not using the same machine as the one I reported the issue in.

I get this issue too!!! Started recently. Might have been from when i built neovim from source to update it recently.
NVIM v0.11.0-dev-782+ga0d8c2b86-Homebrew
Build type: Release
LuaJIT 2.1.1725453128


Allow channel scopes

A few developer have asked to be able to use the SDK to make channel queries. In the interim, it would be useful to expose a way to get the channel scopes and token so they can make channel queries.
This issue will track adding that to the SDK.

As a suggestion, the json file for a project could be expanded to contain a string with the scopes they'd like to request.
scopes are space delimited strings.
e.g. "interactive:robot:self channel:details:self"

An excellent idea! Thank you for that.


fix page reloading on submit empty form

Closes #123

PR-Codex overview
This PR adds a form submission handler to the TextInputForm component in the qa-rest client, allowing users to submit their input with the "Enter" key.
Detailed summary

Added formHandler function to handle form submissions
Added onSubmit prop to form element, set to formHandler
Changed Combobox.Button element to a submit button by adding type={"submit"} prop

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Codecov Report
Patch coverage has no change and project coverage change: -0.06 :warning:

Comparison is base (4a163a2) 71.08% compared to head (ebfe952) 71.02%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@             Coverage Diff              @@
##             master     #125      +/-   ##
============================================
- Coverage     71.08%   71.02%   -0.06%
  Complexity      172      172
============================================
  Files            78       78
  Lines          1231     1232       +1
  Branches        106      106
============================================
  Hits            875      875
- Misses          258      259       +1
  Partials         98       98

see 1 file with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Fix validation tests stability

Refactor ValidationError struct to use fieldError struct for better error handling
Add field validation tests in validator_test.go
Contributing to #17

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 60.15%. Comparing base (968b3fa) to head (8e01606).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
+ Coverage   59.00%   60.15%   +1.14%
==========================================
  Files          21       21
  Lines         522      522
==========================================
+ Hits          308      314       +6
+ Misses        201      197       -4
+ Partials       13       11       -2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Some mobile browsers require playsInline to be set to true for the video

Some mobile browsers require playsInline to be set to true for the video to play with the rest of the content.
To avoid WebGPU samples testing differences between mobile and desktop browsers, set playsInline = true prior to playing the video.

cc @kainino0x @greggman @beaufortfrancois who recently modified this file, are you ok with this change?

LGTM overall. I found two results in https://github.com/search?q=repo%3Awebgpu%2Fwebgpu-samples createElement('video')&type=code but I think sample/videoUploading/video.ts is not used anymore

Sure let's update the other occurrence too even though I agree, it seems unused.


Add ability to paste clipboard content into editor bar

Just when I tried the fix in 840b37e, this need arose.
May be needed in the long run.
Thanks

Do you mean like this:

It's at d1f7381 just now.


add compatibility with jQuery UI 1.12

might break compatibility with jQuery UI 1.11 and below

Thanks for the contribution. Unfortunately, as you mentionned, it's breaking backward compatibility.
The way to keep compatibility would be to add rather than replace options. Each version will take what it needs and ignore the rest.
Here is an example:
this._bSubmit=e.find('.evo-bSubmit').button({
showLabel: bLabels,
text: bLabels
})


STOREKIT_HYBRID_MODE will use Storekit 2 on iOS 13.7 Simulator

Description
When using STOREKIT_HYBRID_MODE, the fallback to Storekit 1 seems to not work (at least on iOS Simulator 13.7).
Since calling setup({ storekitMode: 'STOREKIT_HYBRID_MODE'  }) immediately logs Using Storekit 2 I assume this is just a basic internal misconfiguration.
All calls to initConnection(), getSubscriptions() and getProducts() also fail with [Error] Method only available on iOS 15 and up
Expected Behavior
The app should fallback to Storekit 1.
Screenshots

Environment:

react-native-iap: 11.0.0-rc.6
react-native: 0.68.3
Platforms iOS 13.7 Simulator (iPhone 11)

To Reproduce
Steps to reproduce the behavior:

Use setup({ storekitMode: 'STOREKIT_HYBRID_MODE'  })
Run your app on iOS 13.7 Simulator
Error is shown

Additional Context
I did switch to STOREKIT1_MODE manually, which lead to this error: https://github.com/dooboolab/react-native-iap/issues/1992#issuecomment-1257005273

Fixed as part of 11.0.0-rc.7


expect toThrow does not match empty string

Describe the bug
The toThrow method on the JestAssertion interface does not match the empty string when using a regular expression matcher (e.g., /^$/). Instead, it gives the following output:
AssertionError: expected [Function] to throw an error

- Expected:
null

+ Received:
""

Reproduction
https://stackblitz.com/edit/vitest-dev-vitest-otkry8?file=test%2Fbasic.test.ts
import { expect, test } from 'vitest';

test('should throw empty string', () => {
  expect(() => { throw '' }).toThrow(/^$/);
});

System Info
System:
    OS: Linux 5.15 Ubuntu 22.04.3 LTS 22.04.3 LTS (Jammy Jellyfish)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 5.31 GB / 7.60 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 20.11.0 - ~/.nvm/versions/node/v20.11.0/bin/node
    npm: 10.2.4 - ~/.nvm/versions/node/v20.11.0/bin/npm
    bun: 1.0.25 - ~/.bun/bin/bun
  npmPackages:
    vitest: ^1.3.0 => 1.3.0

Used Package Manager
npm
Validations

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

I think this behavior is directly coming from chai:
https://github.com/vitest-dev/vitest/blob/7d9b1fb02338beef048487ef07f6083aa5559106/packages/expect/src/jest-expect.ts#L530-L532
Here is a reproduction:
https://stackblitz.com/edit/vitest-dev-vitest-8a9pvm?file=repro-chai.mjs
Show code
import * as chai from 'chai';

try {
  chai
    .expect(() => {
      throw '';
    })
    .throws(/^$/);
} catch (e) {
  console.error(e);
}
// AssertionError: expected [Function] to throw an error
//     at eval (/home/projects/vitest-dev-vitest-8a9pvm/repro-chai.mjs:21:6)
//     at _0xba6ba0.run (https://vitestdevvitest8a9pvm-zty5.w-credentialless.staticblitz.com/blitz.a9c8a5a3.js:352:372622)
//     at _0x3775c6._evaluate (https://vitestdevvitest8a9pvm-zty5.w-credentialless.staticblitz.com/blitz.a9c8a5a3.js:352:378123)
//     at async ModuleJob.run (node:internal/modules/esm/module_job:181:2372) {
//   actual: '',
//   expected: null,
//   showDiff: true,
//   operator: 'strictEqual'
// }

try {
  chai
    .expect(() => {
      throw 'hello';
    })
    .throws(/^$/);
} catch (e) {
  console.error(e);
}
// AssertionError: expected [Function] to throw error matching /^$/ but got 'hello'
//     at eval (/home/projects/vitest-dev-vitest-8a9pvm/repro-chai.mjs:31:6)
//     at _0xba6ba0.run (https://vitestdevvitest8a9pvm-zty5.w-credentialless.staticblitz.com/blitz.a9c8a5a3.js:352:372622)
//     at _0x3775c6._evaluate (https://vitestdevvitest8a9pvm-zty5.w-credentialless.staticblitz.com/blitz.a9c8a5a3.js:352:378123)
//     at async ModuleJob.run (node:internal/modules/esm/module_job:181:2372) {
//   actual: 'hello',
//   expected: /^$/,
//   showDiff: true,
//   operator: 'strictEqual'
// }

This'll probably be fixed in chaijs/chai#1609

@43081j what if I want to throw undefined?
Just kidding 😄

Seriously though, couldn't the initial value be a dummy object, like this:
const noError = {};
var caughtErr = noError;
...
    caughtErr !== noError

we could support undefined (via a flag rather than a dummy obj most likely) but i just figured nobody should really be doing that in the first place 🤔  tbh, all thrown errors these days should be Error instances
i feel like supporting that will only lead to confusion further down the line ("expected x not to throw but it threw undefined" etc)

we released chai 5.1.1 recently which fixes this, and renovatebot already bumped the version here in vitest. this issue can be closed i think


How to set different header for the group thread request in apache jmeter?

I want to test concurrency of application, I'm using apache Jmeter for that, the endpoint I'm requesting, needs to have authorization header for authentication, in apache Jmeter HTTP Header Manager i have added a header with the name Authorization with the token value, now lets say I have 5 number of threads (users), when the test runs all the 5 users request with the same authorization token, I want each thread to request with the different token, to simulate the different users and not multiple instances of one user, I hope the question makes sense, How can I make each thread request the api with different token? that is unique header value for each thread's request. Thanks love you guys.

Hi. This question is out-of-scope of SqlTableDependency. Also, I have no experience on apache Jmeter and Java, so i have no idea how i can help you.


Warn the user if the provided driver is not recognized, before op template resolution

With nb5 run driver=stsdout workload=jsonnet-test.jsonnet, the driver is clearly invalid, although it is not sanity checked in the pre-phase before config model validation.


refactor:ScheduledThreadPoolExecutor refact to HashedWheelTimer

Ⅰ. ScheduledThreadPoolExecutor refact to HashedWheelTimer
Ⅱ. run DefaultCoordinatorMetricsTest to verfiy

Hi, can you fix the conflict?


expose popper "strategy" config to dropdown

In regards to the issue: https://github.com/twbs/bootstrap/issues/32947
It would be nice if this could be solved with a simple data attribute by exposing a data attribute for popper for strategy, like data-bs-strategy.
Popper documentation: https://popper.js.org/docs/v2/constructors/#strategy
Example using existing javascript: https://jsfiddle.net/4gpy025q/1/
Thanks

PR in #34120

I fully agree with this suggestion.
I've just upgraded to BS 5 in my Blazor app. In BS 4, the data-boundary attribute worked great for my dropdown needs, but I'm stuck in BS 5, and still haven't come up with a solution.
Having to use new bootstrap.Dropdown(...) for dropdown popper configuration in a Blazor app is highly inconvenient, as Blazor does not lend itself towards executing JS as DOM elements come in and out of existence during re-renders. The attribute approach, however, works perfectly.

alternative PR in #34259 that uses JSON parse to allow more flexibility

After more than a few hours and various attempts I found a working version:
const dropdowns = document.querySelectorAll('.dropdown-toggle')
const dropdown = [...dropdowns].map((dropdownToggleEl) => new bootstrap.Dropdown(dropdownToggleEl, {
    popperConfig(defaultBsPopperConfig) {
        return { ...defaultBsPopperConfig, strategy: 'fixed' };
    }
}));


neonavigation: 0.8.5-1 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository neonavigation to 0.8.5-1:

upstream repository: https://github.com/at-wat/neonavigation.git
release repository: https://github.com/at-wat/neonavigation-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.9.7
previous version for package: 0.8.4-1

costmap_cspace

No changes

joystick_interrupt

No changes

map_organizer
* Revert "Remove old workaround for debian stretch build (#473 <https://github.com/at-wat/neonavigation/issues/473>)" (#478 <https://github.com/at-wat/neonavigation/issues/478>)
* Contributors: Atsushi Watanabe

neonavigation

No changes

neonavigation_common

No changes

neonavigation_launch

No changes

obj_to_pointcloud
* Revert "Remove old workaround for debian stretch build (#473 <https://github.com/at-wat/neonavigation/issues/473>)" (#478 <https://github.com/at-wat/neonavigation/issues/478>)
* Contributors: Atsushi Watanabe

planner_cspace

No changes

safety_limiter
* Revert "Remove old workaround for debian stretch build (#473 <https://github.com/at-wat/neonavigation/issues/473>)" (#478 <https://github.com/at-wat/neonavigation/issues/478>)
* Contributors: Atsushi Watanabe

track_odometry

No changes

trajectory_tracker

No changes

Build cache for "noetic"
- trying to use local cache
- trying to fetch cache
- update cache
- removing invalid release package cache entries.
- fetch missing release manifests
E......
.............................................................................................................................................................................................................................................................................................................
======================================================================

ERROR: Failure: ModuleNotFoundError (No module named 'distro')
Parsing manifest files for 'dashing'
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/nose/failure.py", line 39, in runTest
    raise self.exc_val.with_traceback(self.tb)
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/nose/loader.py", line 417, in loadTestsFromName
    module = self.importer.importFromPath(
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/nose/importer.py", line 47, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/nose/importer.py", line 94, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/imp.py", line 234, in load_module
    return load_source(name, filename, file)
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/imp.py", line 171, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 702, in _load
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/runner/work/rosdistro/rosdistro/test/rosdep_duplicates_test.py", line 5, in <module>
    from scripts.check_duplicates import main as check_duplicates
  File "/home/runner/work/rosdistro/rosdistro/scripts/check_duplicates.py", line 34, in <module>
    from rosdep2.sources_list import load_cached_sources_list, DataSourceMatcher, SourcesListLoader, CachedDataSource
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/rosdep2/__init__.py", line 40, in <module>
    from .installers import InstallerContext, Installer, \
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/rosdep2/installers.py", line 36, in <module>
    from rospkg.os_detect import OsDetect
  File "/opt/hostedtoolcache/Python/3.8.2/x64/lib/python3.8/site-packages/rospkg/os_detect.py", line 42, in <module>
    import distro
ModuleNotFoundError: No module named 'distro'
-------------------- >> begin captured logging << --------------------
rosdistro: DEBUG: Load index from "file:///home/runner/work/rosdistro/rosdistro/index-v4.yaml"
--------------------- >> end captured logging << ---------------------

The error looks unrelated to this PR.


Update Expo CNG -> Expo Go recipe

Describe the bug
With Ignite 10, we've added a few more dependencies outside the Expo ecosystem. We can update this recipe to have a successful path to convert back to Expo Go (especially since it is no longer an option during setup)

Closed by #180


Data process bug

...Exporting versions...
Git command failed with args [ 'show',
  'bdfbcd52fa719d9594fcc809332823aa190773be:transitions/11104_11110_CONT' ]
fatal: Path 'transitions/11104_11110_CONT' does not exist in 'bdfbcd52fa719d9594fcc809332823aa190773be'

/var/www/twotech/process/src/Git.js:15
      throw "Git command failed. See log for reason.";
      ^
Git command failed. See log for reason.

I think this happens when an item is deleted in (for example) version 3, but in version 4 a transition still refers to the item.
We should probably add some logic to avoid the whole thing failing due to this rather simple issue.

Related https://github.com/twohoursonelife/OneLifeData7/commit/a4f4ea02f30545ea4b431d326015fca678e4ad02

My current understanding is that there was an issue in Data7 where two transitions where accidentally committed with a trailing space before the file extension. I think the twotech process scripts are somewhere splitting a string into an array at the interval of spaces, which may have some factor in this error.
Similar to another error we had, I am trying to override the data the moment before it's passed to the git command handler as I've yet been unable to find where exactly the root cause is. This is not an ideal solution, if it works at all, and issues like this take a lot of debugging to find. Ideally, twotech would be more resilient to simple mistakes that we can make with the editor due to its own issues.

Override solution https://github.com/twohoursonelife/twotech/commit/68b7654732948f447a0ac6157354b58a052dd52c


When module-info.java added, getMapper() throw org.apache.ibatis.binding.BindingException

MyBatis version
3.5.9
Database vendor and version
myslq:8.2.9
Test case or example project
Steps to reproduce
add module-info.java to a project
Expected result
no exception
Actual result
has exception

There is not enough information for us to investigate.
Are you sure you 'open' all the necessary packages?
If yes, please provide a small project that reproduces the exception and we'll look into it.
Here are some project templates if it's easier: https://github.com/harawata/mybatis-issues

here is a demo: https://github.com/LeoLuo21/mybatis-issue-demo/tree/master

Are you working on the issue now?

@LeoLuo21 ,
Thank you for the demo.
Did you verify the same exception reproduced with the project you shared?
If yes, please explain the exact commands you executed.
Even mvn clean package failed on my environment.

@LeoLuo21 ,
Thank you for the demo. Did you verify the same exception reproduced with the project you shared? If yes, please explain the exact commands you executed. Even mvn clean package failed on my environment.

I run the demo project in IntellijIdea, just clicking the run button in Main.java.

@LeoLuo21 ,
Thank you for the demo. Did you verify the same exception reproduced with the project you shared? If yes, please explain the exact commands you executed. Even mvn clean package failed on my environment.

When I run the demo, the exception messages are below:
SEVERE: Could not read package: demo.mapper
java.nio.file.FileSystemException: /home/leo/IdeaProjects/mybatis-issue-demo/target/classes/demo/mapper/ProductMapper.xml/: Not a directory
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:149)
at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.base/java.nio.file.Files.readAttributes(Files.java:1764)
at java.base/jdk.internal.module.Resources.toFilePath(Resources.java:102)
at java.base/jdk.internal.module.ModuleReferences$ExplodedModuleReader.find(ModuleReferences.java:382)
at java.base/jdk.internal.loader.BuiltinClassLoader$2.run(BuiltinClassLoader.java:407)
at java.base/jdk.internal.loader.BuiltinClassLoader$2.run(BuiltinClassLoader.java:402)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinClassLoader.java:401)
at java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLoader.java:332)
at java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1467)
at org.mybatis@3.5.9/org.apache.ibatis.io.VFS.getResources(VFS.java:190)
at org.mybatis@3.5.9/org.apache.ibatis.io.DefaultVFS.list(DefaultVFS.java:104)
at org.mybatis@3.5.9/org.apache.ibatis.io.DefaultVFS.list(DefaultVFS.java:154)
at org.mybatis@3.5.9/org.apache.ibatis.io.VFS.list(VFS.java:223)
at org.mybatis@3.5.9/org.apache.ibatis.io.ResolverUtil.find(ResolverUtil.java:249)
at org.mybatis@3.5.9/org.apache.ibatis.binding.MapperRegistry.addMappers(MapperRegistry.java:103)
at org.mybatis@3.5.9/org.apache.ibatis.binding.MapperRegistry.addMappers(MapperRegistry.java:118)
at org.mybatis@3.5.9/org.apache.ibatis.session.Configuration.addMappers(Configuration.java:860)
at mybatis.issue.demo/demo.Main.main(Main.java:37)
Exception in thread "main" org.apache.ibatis.binding.BindingException: Type interface demo.mapper.ProductMapper is not known to the MapperRegistry.
at org.mybatis@3.5.9/org.apache.ibatis.binding.MapperRegistry.getMapper(MapperRegistry.java:47)
at org.mybatis@3.5.9/org.apache.ibatis.session.Configuration.getMapper(Configuration.java:868)
at org.mybatis@3.5.9/org.apache.ibatis.session.defaults.DefaultSqlSession.getMapper(DefaultSqlSession.java:288)
at mybatis.issue.demo/demo.Main.main(Main.java:40)
Process finished with exit code 1

I'm not familiar with IntelliJ, but there may be some configuration to run JPMS aware project.
With the following steps, I could run the project successfully.

Specify a newer version of maven-compiler-plugin in the pom.xml. I sent a PR to your repo.
cd to the cloned project directory.
mkdir modules to create a new directory.
mvn clean package to build JAR file.
cp target/mybatis-issue-demo-1.0-SNAPSHOT.jar modules to copy the built JAR file into the modules directory.
Also copy mybatis-3.5.10.jar and mysql-connector-java-8.0.29.jar to the modules directory.
java --module-path modules -m mybatis.issue.demo/demo.Main to run the Main class.

Thank you for helping me. According to your steps I could run successfully, I guess It's the problem of IntellijIdea.

No problem. :)
You should search their support forum : https://intellij-support.jetbrains.com/hc/en-us/community/topics/200382555-IntelliJ-IDEA-Users
Closing as this is not a MyBatis issue.

No problem. :) You should search their support forum : https://intellij-support.jetbrains.com/hc/en-us/community/topics/200382555-IntelliJ-IDEA-Users
Closing as this is not a MyBatis issue.

Excuse me,  I still have a question:
I put all target/classes directory instead packaged jar into modules directory, then execute java --module-path modules -m mybatis.issue.demo/demo.Main and Exception occurred. Is there some difference between packaged jar between compiled .class directory.


Adding flint block support?[Feature]:

Feature Details
Just wondering if there is a reason it isn't already added?

This is a thing now.


Added Translate README.md to Bengali language #353

I have translated README.md to Bengali language, issue #353, also I changed the build file in Bengali language.
@ParthJadhav please approve this PR and give hacktoberfest-accepted label for the hacktoberfest! Awaiting your reply!

@ParthJadhav please approve this PR and give hacktoberfest-accepted label for the hacktoberfest! Awaiting your reply!

Thanks for the changes @debnath003 !


Fix null reference error if there's no built in retry support

Issue describing the changes in this PR
context.RetryCount and context.MaxRetryCount throw null exceptions since the RetryContext passed into GrpcRetryContext is set to null. This PR addresses that bug and adds a unit test.
resolves #1438
Pull request checklist

[x] My changes do not require documentation changes

[ ] Otherwise: Documentation issue linked to PR

[x] My changes should not be added to the release notes for the next release

[ ] Otherwise: I've added my notes to release_notes.md

[x] My changes do not need to be backported to a previous version

[ ] Otherwise: Backport tracked by issue/PR #issue_or_pr

[x] I have added all required tests (Unit tests, E2E tests)

@fabiocav I validated that the RetryContext is set to null in the in-proc experience. I'm assuming we'd also want to set the RetryContext to be null for the out of proc experience as well then


Makefile: proper deps for the setup target

this config is linked, but not forcefully linked, during setup.
[vbatts@getdown] (master) ~/src/github.com/istio/pilot$ make
ln: failed to create symbolic link 'platform/kube/config': File exists
make: *** [Makefile:19: setup] Error 1

With this, a user could put their own config without getting clobbered,
or no error on make when the PHONY setup runs everytime.
Signed-off-by: Vincent Batts<EMAIL_ADDRESS>

Hi @vbatts. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/ok-to-test

Thanks!

@vbatts: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/pilot-e2e-smoketest.sh
030824351fdf877da99379c92669b15de55969e2
link
@istio-testing smoke test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

these CI failures seem unrelated?

Excuse our extremely flaky e2e test :) It's like playing a lottery these days :)

oh I see :-)
On Wed, Aug 9, 2017 at 3:55 PM, Kuat<EMAIL_ADDRESS>wrote:

Excuse our extremely flaky e2e test :) It's like playing a lottery these
days :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/pilot/pull/1010#issuecomment-321363946, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEF6QSgunFMzRJh4T7uy7Jgs5rTeLz3ks5sWg6pgaJpZM4OyYMA
.

@vbatts: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/pilot-e2e-smoketest.sh
030824351fdf877da99379c92669b15de55969e2
link
@istio-testing smoke test this

prow/pilot-presubmit.sh
0834b0ab8dda1b1da1515f9e4e22ac9dafe32d61
link
@istio-testing bazel test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

force merging, since this change is not even tested by CI :)


Map concurrency retain array order

The core of this PR simply changes the _drainQueue method used by the map method called when it's run with a concurrency limit, which fetches the next Promise in the array using Array.shift() instead of Array.pop().
The point of this is to retain the standard behaviour of map and process each entry in the source array in the same order in which it was provided, regardless of whether or not a concurrent processing limit has been set, providing more consistent and predictable behaviour.

To ensure the unit tests cover this properly, I added an extra item to all typical test inputs, effectively changing [1, 2, 3] to [1, 2, 3, 4] and updated the order of the outputs for the final "big" test to match the order of the provided input.

closing this PR in favour of a better solution proposed in this comment.


FIX - updated license links in README to link to the proper license file

Description
Updated license links in README file.
Motivation and context
If it fixes an issue to point to a non-existing license file in the repository. The link led to the 'LICENSE.md' file, but that file only exists without an extension
How has this been tested?
No, only readme change.
Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have read the CONTRIBUTING document.
[x] My pull request addresses exactly one patch/feature.
[x] I have created a branch for this patch/feature.
[x] Each individual commit in the pull request is meaningful.
[ ] I have added tests to cover my changes.
[x] If my change requires a change to the documentation, I have updated it accordingly.

@gwini 👍🏻


test: Disable unsupported features on 4.9 to reduce warnings

For several of the features enabled by default (e.g., kube-proxy replacement, BPF masquerading), we probe kernel support and disable them with a warning on older kernels. This behavior generates a lot of warnings in Cilium logs on our 4.9 CI and makes it difficult to see new warnings and warnings that matter.
Ideally we would fail the build on unexpected warnings but we are still a long way from that. This commit removes three unnecessary warnings on 4.9 and 4.19 by disabling unsupported features.

test-me-please

GKE is failing with known flake https://github.com/cilium/cilium/issues/14996, K8s-1.13-Kernel-netnext with https://github.com/cilium/cilium/issues/12511. Other tests and builds are passing. Reviews are in. Marking as ready to merge.


[docs] Add info about using types also with JSDoc

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

Thank you, but this isn't anything specific to Svelte or SvelteKit and so doesn't really belong here.


Changing Control node Z Index pushes unnecessary Node configuration warning

Godot version
4.0.beta8
System information
Windows 10
Issue description
Changing the z_index of a Control node pushes a Node configuration warning to the editor:

This warning is unnecessary and also redundant, as the property description already outlines this:

Steps to reproduce

Create a Control node.
Change the Control node's z_index.
Observe Node configuration warning.

Minimal reproduction project
N/A

https://github.com/godotengine/godot/pull/68070 The warning wasn't its own PR but part of the one that implemented this in the first place.
I agree this warning is unnecessary

This warning is necessary. Not everyone will read the description and I can already imagine some angry user coming to Reddit, or worse, GitHub, saying they wasted 5 hours debugging why their Control does not work as "expected". With warning in place, chance of this happening is 90% lower.

is there a way to hide this warning?

No, there is no way to hide it.

I agree the warning is necessary, but can a way to hide this warning be added?
I think a way to disable this warning is also necessary, just as much as the warning itself.
I mean, I use a _get_configuration_warnings  on my own scripts, sometimes even add @tool to a script just to add warnings that help me not make mistakes in my own scenes, and having this warning appear on places where using z_index in control node is exactly what I want is confusing/annoying. Also, after some time I don't know anymore if that node if a warning is one that I should pay attention to and fix something or if it's just the "z_index" warning, I have to click on them to read it.
In fact, it creates a situation where I actually want to ignore a warning, and I don't think getting used to ignoring warnings is something desired, if that's the case I should be able to disable the warning so that it doesn't "weaken" the effect of other warnings.
Or at least move it to something similar to the "layout" messages, if it can't be disabled:

You'd want to suppress it per node, and we don't have a system for that yet. Moving it out of a configuration warning and into a small info banner would defeat its purpose of preventing issues for people misusing the property (or changing it by accident/without a clear idea of the effect). If there is a good reason to introduce a system to suppress configuration warnings, per node, then your case will also be covered.

Wouldn't it be possible to add a it in a similar way to the GDScript warnings we can set on ProjectSettings?
This is a warning the engine is forcing on me, and different than other warnings the engine has, like when you create an Area/PhysicsBody without a collision, this gives a warning to a perfectly plausible and valid use case.
It's like Godot is saying "hey we added this cool feature so that you can animate UI in a more friendly way, but every time you use it I'll keep nagging you that you're using it Wrong! (Even though you aren't I just don't have any way of knowing it)"
I don't want to suppress the "z_index" warning on some nodes and not on others, I want to suppress it always, because it's a warning that is not relevant to me or my project.
I mean, if there was some project settings for this like for the GDScript warnings, I suppose it would be possible to turn off this particular warning with something like this but in C++:
func _get_configuration_warnings() -> PackedStringArray:
	var warnings := PackedStringArray()
	if ProjectSettings.get_setting("debug/node_configuration/z_index_warning") == true:
		warnings.append("Changing the Z index of a control only affects the drawing order, not the input ecent handling order.")
	return warnings

Don't know if this would actually be similar in C++ but seems valid to me to add this for this case as this warning is already more of an exception since its purpose is to "prevent users from coming to complain on github" then pointing out an actual error in the way of using the node, so why not also be an exception in the sense that you can disable it?
And no new "system to suppress configuration warnings" would be needed, just like PhysicsBody has some way to check if they have a CollisionShape and stop showing their warnings, this would be the way for Control nodes to know everything is okay.

It's technically feasible to read a project setting value to decide whether to emit a node configuration warning in C++, but I don't think we should make band-aid changes like this. Eventually, people will ask to do this for every warning individually, which is a mess to maintain :slightly_smiling_face:

This is a warning the engine is forcing on me, and different than other warnings the engine has, like when you create an Area/PhysicsBody without a collision, this gives a warning to a perfectly plausible and valid use case.

Is it? For a long time I had a scene setup where root was StaticBody2D and I had all colliders under a Node2D child, because I wanted the scene to be organized (I later moved them using script). So every of my 200+ scenes had a warning in root node and 2-15 warnings for each of the colliders.
Every API has its intended usage and warnings are a way to point to that and avoid common mistakes.

It's technically feasible to read a project setting value to decide whether to emit a node configuration warning in C++, but I don't think we should make band-aid changes like this. Eventually, people will ask to do this for every warning individually, which is a mess to maintain slightly_smiling_face

Still, adding warnings for valid use cases just to prevent people that don't read documentation to come complain on github is also a band-aid change isn't it?
I agree in this case it's worth it, but if warnings like these also start to get added a lot then isn't it also a problem? I don't know, I think this particular band aid (the z_index warning) justifies another particular band aid (the option to remove this particular warning), and then if people actually start to request more things like this, then maybe it will be useful to think up a proper system for this with clear use cases and thinking on maintainability.
For now this warning seems like a band-aid that solves the "pain" of the people who would use this wrong, and the "pain" of the godot developers that don't want to keep closing bugs about controls with higher z_index not capturing input, but creates another "pain" for everyone that uses the property as it was intended.
That's why I agree this warning should continue existing, but just has as much reason to have the option to disable it: "to prevent people that use the property correctly to come to git hub complain about the warning"
I mean, like we say in brazil "if you're already in hell, might as well hug the devil"

This is a warning the engine is forcing on me, and different than other warnings the engine has, like when you create an Area/PhysicsBody without a collision, this gives a warning to a perfectly plausible and valid use case.

Is it? For a long time I had a scene setup where root was StaticBody2D and I had all colliders under a Node2D child, because I wanted the scene to be organized (I later moved them using script). So every of my 200+ scenes had a warning in root node and 2-15 warnings for each of the colliders.
Every API has its intended usage and warnings are a way to point to that and avoid common mistakes.

Your example seems a lot more "advanced" and a choice in the developer side on how they want to architecture their game in a different way than what the engine expects/recommends. You even have to add a script to "fix it" in runtime.
While the z_index is just the "default" way the engine recommends to solve draw order issues with CanvasItem nodes, and I'm getting a warning by using the API Godot provides in the way Godot expects me to use it, not by doing something "advanced". So I don't really think the two examples compare that well.
But, okay, maybe having a whole system to suppress warnings by node types like @YuriSizov  was mentioning would be more desirable, as you'd be able to use that in your project as well. Is there already some proposal for that?

See these proposals:

https://github.com/godotengine/godot-proposals/issues/550
https://github.com/godotengine/godot-proposals/issues/2519
https://github.com/godotengine/godot-proposals/issues/5068

Well, you are getting a warning precisely because the engine is not expecting you to use it. It allows you to use it, but it warns you because it's not really a safe feature to use in this case.
Also, I was talking about suppressing per node, not per node type. IMO this should never be something that you can just globally disable. And I say it as a person who uses those global GDScript warning settings to disable some default ones.

Well, you are getting a warning precisely because the engine is not expecting you to use it. It allows you to use it, but it warns you because it's not really a safe feature to use in this case.

I think this is a bit contradictory, Godot 3.x went its whole existence without this option and having z_index on Controls is a very welcomed addition that simplifies a lot of UI problems/animations, I don't see how this was added but still expected not to be used, and there are far more unsafe options that give no warnings at all, like top_level.
But, thinking about the "safe" part, maybe another suggestion then:

if mouse_filter is set to either MOUSE_FILTER_STOP or MOUSE_FILTER_PASS and z_index is different then 0, show the warning, if it's set to MOUSE_FILTER_IGNORE then hide the warning.

This option exists in Godot 3, but it's not exposed because it was not designed to be used by controls. It's just possible to use in controls, because the underlying server works with all types of canvas items.
But because it is situationally useful, we agreed to expose it but with a warning. Which is what we did. It is no more safe to use it in 4 than it is in 3, so the warning is a compromise for making it more accessible but still strictly "not really supported". This is why we closed this issue with a note that the warning is necessary.

I didn't know it was possible to set z_index in Controls in 3.x, would have saved me a lot of trouble, still, I find it weird this position that it is "still strictly 'not really supported'." when you recognize it was situationally useful and the documentation even give examples of when it is useful.
But what about the suggestion to make the warning go away when the control mouse_filter is set to MOUSE_FILTER_IGNORE?  If the "problem" is the confusion that can come from input handling, wouldn't setting mouse_filter to ignore "fix it"?
I was looking at the PR linked here and while I don't know C++ very well yet, it seems like something simple enough that even I could do, I'd just need to change the condition for the warning instead of removing the warning like the PR is doing. It would also be a cool way (for me) to start looking more into godot source code and contributing.
But I don't want to take the time to do that if it will just be summarily ignored because the official position on this is that no matter what the warning must appear.

I find it weird this position

Well, yes, this situation is a good demonstration why exposing something that is not really designed to work in a certain way but people still do it — is a bad idea. We are sending mixed signals here, and IMO having just the old way of interacting with the server directly would've been enough for something that may or may not work as expected in all cases.
extends Control

func _ready():
    VisualServer.canvas_item_set_z_index(get_canvas_item(), your_value)

But we have reached a different consensus, so here we are. People who knew the trick wanted a better way to use it. But the limitations for controls themselves cannot be so easily fixed. For example, reordering of the input handling order is an expensive operation, so doing it as z-index changes would likely result in a way worse performance across the board. But since most requested it to be exposed for animations, it was deemed to be okay not to address that issue and keep the input order as is.
And there might be other limitations. The only way we can truly get rid of the warning is to fix the underlying issues without causing more problems. As for options to hide it conditionally, I still think that we probably need a more generic way to suppress arbitrary configuration warnings.

But what about the suggestion to make the warning go away when the control mouse_filter is set to MOUSE_FILTER_IGNORE? If the "problem" is the confusion that can come from input handling, wouldn't setting mouse_filter to ignore "fix it"?

And if you don't want to ignore it? I feel like you're trying to come up with an acceptable hack that you yourself can utilize. But this is not going to be applicable to everyone, so it's not going to be a good solution IMO.

But what about the suggestion to make the warning go away when the control mouse_filter is set to MOUSE_FILTER_IGNORE? If the "problem" is the confusion that can come from input handling, wouldn't setting mouse_filter to ignore "fix it"?

And if you don't want to ignore it? I feel like you're trying to come up with an acceptable hack that you yourself can utilize. But this is not going to be applicable to everyone, so it's not going to be a good solution IMO.

No, I was really trying to think if there was any situation where a control with MOUSE_FILTER_IGNORE would cause any trouble with a changed z_index and could think of none.
So I thought it would be a valid improvement to anyone that decides to use z_index and for the engine itself not just for me or my project, as in fact it would not hide all warnings in my case.
I was asking more to see if it was a good idea or if there were other problems related to Control and z_index that are not about input handling and I'm not aware. Could have rephrased the question to be more specific.

I find it weird this position

Well, yes, this situation is a good demonstration why exposing something that is not really designed to work in a certain way but people still do it — is a bad idea. We are sending mixed signals here, and IMO having just the old way of interacting with the server directly would've been enough for something that may or may not work as expected in all cases.

I totally agree with you about the mixed signals, and even though I disagree that z_index on Controls is that harmful when it's clear it's just something related to drawing and not input handling, I'd also prefer that it wasn't exposed at all if it was going to be exposed with these mixed signals.

extends Control

func _ready():
    VisualServer.canvas_item_set_z_index(get_canvas_item(), your_value)

But we have reached a different consensus, so here we are. People who knew the trick wanted a better way to use it.

I had seen this function in the documentation before when I had to use VisualSever for a project in 3.x, but never realized I could use this for Controls, even though they are also CanvasItem, and you could just export a variable with a setter to make it more friendly. Damn, really wish I had realized this a couple years ago.

I think there's an argument here for an "Info" notification on a node alongside the "Warning" notification for things that aren't game-breaking but the user should be aware of.
Alerts are generally things that the user needs to fix, and are fixable, whereas in this case we're talking about an FYI.
The behaviour in this issue isn't wrong, it's just being communicated to the user in a slightly UX-orthogonal way.

TBH I'm just confused about this whole premise. We expose the property, but we also have a warning that always appears if you decide to use it :thinking:

TBH I'm just confused about this whole premise. We exposed the property, even though using it always leads to warnings? 🤔

Yeah, it's to avoid user confusion, which makes sense. I would probably have expected z-index to affect input event handling order if it wasn't spelt out so clearly.
I believe the reason it's communicated as a warning is a side-effect of the warning system being available when this was built, and considered a quick fix.
If we can find a nice way to keep the FYI while avoiding the use of the Warning system I'm sure it would solve the issue.

Right, but it feels like one of those things that gets added in the interest of helping new people but does nothing but annoy intermediate to advanced folks.  And there's nothing to be done about it - can't even be suppressed.

Chiming in to say that I encountered this warning today, and was quite sad to find there was no way to suppress it. I think with this large influx of new users of an intermediate to advanced level, it would be worth re-considering having an "ignore this warning" button.
Very OCD triggering to have a warning that is irrelevant but can't be removed!

I strongly agree. I think in all cases, permanent warnings should only be surfaced if they can/should be acted upon, thereby removing the warning.
The persistence of this warning is not just obnoxious, it also essentially forces me to learn to ignore Node-level warnings, because I will always be looking at yellow triangles in my Node hierarchy.
My UI proposal would be to include an "info" level icon in the Node warning system that exists for cases like these. If there are situations where information should be surfaced but not necessarily acted upon, then an "info" widget is more appropriate than a "warning" widget.

Please continue the discussion in the proposals linked here: https://github.com/godotengine/godot/issues/69895#issuecomment-1492609882

Yep, this is pretty atrocious UX. A warning that you can't fix, other than by basically not using the option. Then why does the option even exist?

Yep, this is pretty atrocious UX. A warning that you can't fix, other than by basically not using the option. Then why does the option even exist?

The Z Index property exists because it was requested in Control for a long time: https://github.com/godotengine/godot-proposals/issues/839
We will need to have dismissable node configuration warnings eventually, as there are a lot of situations where additional node configuration warnings would be useful (but only until you acknowledge them).
Until then, https://github.com/godotengine/godot/pull/69903 has been rejected in the past so I don't think we should remove the warning.

Unfortunately, we can't implement different node configuration warning levels or discarding individual warnings without breaking compatibility with the existing _get_configuration_warnings() API. That method is expected to return an array of Strings, not objects that can specify a warning code (which is required to accurately target individual warnings) or severity. The only thing we could do for now is having a way to discard all present and future warnings on a given node, which is likely a footgun in the long run.

It's possible to add a project setting to disable specific warnings. The _get_configuration_warnings() method would just check for that setting.

Would it be targeted based on a node type or warning string? I feel storing the warning string in version control is problematic, as any upstream changes would invalidate it.

No I mean the setting could be editor/controls/show_z_index_warning and Control node would check for this property specifically. We don't have a generic system to disable warnings, but we can do that on case-by-case basis.

Yep, this is pretty atrocious UX. A warning that you can't fix, other than by basically not using the option. Then why does the option even exist?

Yeah, having warnings that aren't relevant creates alarm fatigue, and means that all other warnings in Godot get degraded as a feature.

Right, but it feels like one of those things that gets added in the interest of helping new people but does nothing but annoy intermediate to advanced folks. And there's nothing to be done about it - can't even be suppressed.

Even as a very new user myself, the warning scares me more than anything, and makes me look into the reasoning behind it, only to find out that I'm using it correctly. The only reason I'm in this thread is due to the confusion and uncertainty that the warning causes.
I agree that it's certainly useful, but it also feels like there are countless other areas where using something incorrectly can cause breaks, yet there aren't constant warnings for every opportunity where things can fail

Unfortunately, we can't implement different node configuration warning levels or discarding individual warnings without breaking compatibility with the existing _get_configuration_warnings() API.

Since my PR for configuration warnings for certain properties also requires a breaking API change of some kind, I could see value in combining both approaches. So a _get_configuration_info() that returns an array of dicts with message, severity, property

Id be satisfied with a simple "Ignore Warning for this node" button if the certain warning pops up

The warning is removed in newest 4.3 release.


Add PROTOCOL.md mention that schemaString is required in first Delta log entry

The existing protocol doc mentions that a metadata action is required in the first version of a table, but it does not specify required or optional fields for the metadata action. I believe schemaString should be required at a minimum in the v1 delta log entry.
This PR adds a short and sweet mention in the first paragraph of the ### Change Metadata section to communicate that schemaString is required in the first metadata entry and transitively, the first log entry -- piggy backing on the existing mention that a metadata action is required in the first delta table version.
Ideally, additional optional/required/required-if specifications for metadata properties should be provided in the protocol doc, because as it stands, an empty metadata object (i.e. metadata: {}) is permitted by the protocol doc which is not helpful to any human or computer. With this PR, I am interested in solving for absent schema in the first table version. Unfortunately, some projects are already leveraging the under-specification. A table with no schema metadata is not useable from a reader perspective, so should not be possible to create from a writer perspective IMHO. Hopefully, this PR should discourage folks following the protocol from creating scenarios that do not include metadata schema in the first log entry.
I would like to see optional/required/required-if specifications added to the metadata section for all properties for v1 + n, but I cannot determine which properties fit which category other than that v1 must include schemaString at this time.

UPDATE
After realizing the full implications of the existing protocol statement that:

Subsequent metaData actions completely overwrite the current metadata of the table.

and also grokking the required/optional mentions by @houqp - I have changed the PR content significantly. Instead of a "short and sweet mention in the first paragraph" - I have gone all in on an optional/required column in the metadata field table + a mention that required properties must be included in every metadata action.

Would like to hear other maintainers' opinions on this as well. I think we should add a nullable/nullable/required column to the metadata schema spec table. To me it feels like only id and createdTime should be marked as required?

format might be another field worthy of being required in at least the first log entry as well.

format seems like it could be required as well so that readers know how to read.

So two proposals here:

Requiring schemaString and format in the first metadata action committed to transaction log
Adding a new nullable/optional/required column to the metadata schema spec table so we can specify what fields are optional for all metadata actions in the transaction log.

Thanks @houqp - your mention, plus my notice that the existing protocol doc already mentions that

Subsequent metaData actions completely overwrite the current metadata of the table.

has changed my PR content significantly. See updates in https://github.com/delta-io/delta/pull/610/commits/f3cdf7a4f9d91115ebe7fecbcdaa5b00596adc54.
Given the existing overwrite constraint, I think this boils down to optional vs required which can be specified for each subfield of the metadata object as rendered here.
I have also added a statement to the Change Metadata section that states:

Every metadata action must include required fields at a minimum.

@dennyglee @marmbrus would one of you happen to know who the right reviewers might need to look at this?

Including @mengtong-db - let’s review this and validate.

Hey @xianwill - any thoughts or comments per feedback?  Thanks!

@dennyglee + @zsxwing - I have made the suggested edits regarding required/optional for createdTime and configuration.


Collapse models into single one.

https://github.com/azure/azure-sdk-for-java/issues/11266

/azp run java - search - tests


HP Value is WAY off

Check

[x] HP Calculation based on HD
[ ] Conversion Validation
[ ] Check for compatibility errors when using different Calculation Methods set in the System Settings / Health Configuration

HP Total gets calculated correctly now.
The conversion validation leads to maybe unnecessary changes, like "-140hp" and "+140hp" simultaneously. Check if there is potential to alleviate this.

Fixed the conversion validation for hp, which should now lead to only a single change entered into the conversion buff.

HP gets auto adjusted when using auto hp calculation (in systemsettings).


Add the GameDB API

What does this implement/fix? Explain your changes.
Added the GameDB API. The code is not documented yet. Just putting it up now so that the engine team can start working with it. I explained to them how to work with it during meeting.
Does this reference any currently open issues?
None.
Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. This is simply a reminder of what we are going to look for before merging your code.

[ ] I have linted my code and I have run tests locally that pass
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation

Any other comments?
None.

Made changes, rebased and removed extraneous commits that were not supposed to be there @sha224

References #29


Ensure that ChocolateyInstall.ps1 script is offline-ready

Currently, @ryanrichter94 has reported that the ChocolateyInstall.ps1 script hosted in the raw Nexus repository is not fully offline-ready, as it attempts to pull down the 7za.exe executable from https://chocolatey.org for uncompressing the Chocolatey package.
As we are planning to support fully offline deployments, we need to ensure this script no longer requies access to any Internet resources to run.

There is an ENV VAR for this that can be set, namely: ChocolateyUseWindowsCompression. If this is set, the install script will use built-in compression.
We could build a try/catch into the web request for 7za.exe, with a fallback to use the builtin compression. Also, we could have a parameter that overrides this attempt altogether and just sets the ENV VAR.
@steviecoaster is already aware of this, and has picked this up.


General Store sell price

Hi guys,
Another suggestion to help out Ironmen accounts - it'd be nice if the sale value of items in your inventory could be seen when interacting with a general store. Either on hover or right-click.
The displayed value would update accordingly as you sold the item to the general store, so you always know how much the general store is buying your items for.
See: http://oldschoolrunescape.wikia.com/wiki/General_store#Sell_prices

It's fixed value, so just multiply it by w/e the difference is


Fix MergingBehaviour::Last creating unintuitive import trees

The way this behaviour currently works is actually a bit weird. Imagine the following three imports get requested for insertion in the given order:

winapi::um::d3d11::ID3D11Device
winapi::shared::dxgiformat::DXGI_FORMAT
winapi::um::d3d11::D3D11_FILTER

After the first two you will have the following tree:
use winapi::{shared::dxgiformat::DXGI_FORMAT, um::d3d11::ID3D11Device};

which is to be expected as they arent nested this kind of merging is allowed, but now importing the third one will result in:
use winapi::{shared::dxgiformat::DXGI_FORMAT, um::d3d11::ID3D11Device, um::d3d11::D3D11_FILTER};

which is still fine according to the rules, but it looks weird(at least in my eyes) due to the long paths that are quite similar. The changes in this PR will change the criteria for when to reject Last merging, it still disallows multiple nesting but it also only allows single segment paths inside of the UseTreeList. With this change you get the following tree after the first two imports:
use winapi::um::d3d11::ID3D11Device;
use winapi::shared::dxgiformat::DXGI_FORMAT;

and after the third:
use winapi::shared::dxgiformat::DXGI_FORMAT;
use winapi::um::d3d11::{ID3D11Device, D3D11_FILTER};

Which I believe looks more like what you would expect.

Perfect, I noticed these odd-looking imports showing up
bors r+


Viewer alpha public package initial checkin

This PR introduces the public package build for the alpha viewer that was previously introduced in this PR: https://github.com/BabylonJS/Babylon.js/pull/15241
The overall strategy is summarized in the comment at the top of the prepublish.cjs script:
// The alpha version of the viewer package must have a unique package name within the context of the mono repo / npm workspace
// as long as the legacy version is still being maintained and published. Therefore, the alpha package has a unique name, but this
// is not the actual name we want to publish it under. This script copies the name and version from the legacy package.json to the
// alpha package.json, appends "-alpha" to the version, and removes the private flag, scripts, and devDependencies from the alpha,
// and finally deletes the legacy package.json. This script should be run after the alpha package has been built and before it is
// published. This script is not necessary when the legacy package is deprecated and the alpha package is published under the same
// name as the legacy package.

Given this, the high level aspects of this new folder are:

Includes a rollup based build that bundles everything into a single file but still uses esm (webpack is good at creating umd bundle files, but not esm bundle files).

Bundling to esm allows us to not "ship our directory structure," which gives us the freedom to update the directory structure or file names in the viewer source without creating back compat issues.
It also bundles the d.ts files into a single d.ts
Later when we introduce dynamic imports, it won't be one bundle file but rather a handful. Technically people could import the dynamic import bundles, but it's unlikely someone would do so since rollup basically gives them random names.

Includes a prepublish.cjs script that modifies the package.json and deletes the legacy viewer package.json so the new alpha viewer can be published with the same name (with the -alpha version suffix).

Separately, @RaananW (or me with @RaananW's help) will modify the CI build to run this prepublish step and then specifically publish the new alpha viewer package. That will come in a different PR.
I also had to make a few changes to the actual viewer source code to get this all working (tested a local build of the package in a vanilla-ts Vite project).

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Reviewer - this PR has made changes to one or more package.json files.

Snapshot stored with reference name:
refs/pull/15246/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15246/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15246/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15246/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15246/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15246/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15246/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15246/merge#BCU1XR#0

WebGL2 visualization test reporter:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15246/merge/testResults/webgl2playwright/index.html

Visualization tests for WebGPU (Experimental)
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15246/merge/testResults/webgpuplaywright/index.html

Reviewer - this PR has made changes to one or more package.json files.

Reviewer - this PR has made changes to one or more package.json files.

Visualization tests for WebGPU (Experimental)
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15246/merge/testResults/webgpuplaywright/index.html


Upon updating Game System custom skills are overwritten or added on top of.

I noticed this when I updated from v1.1 to v1.2 and then to v1.3, the characters I made had their skills overwritten or added on top of with the Star Wars skills even though my custom skills were set as default.
Is this a known problem, or is there a migration strategy?

that is correct,   Most users had issues like this and had to recreate the characters.  We added skill categories, which did not translate correctly between versions.  In the current alpha we've already updated the migrations to handle theses changes but they will only be handled if going from any version to 1.4, ie 1.1 to 1.4,  we won't be going back to fix previous migrations
If you still have a 1.1 works,  I'd be interested in seeing it go from 1.1 to the alpha version

I had already performed a 1.1 -> 1.2 by now, and was excited about the 1.3 release. I'm not sure I can be much help now. I'd have to recreate the scenario. If you're interested, I can chug through that.

That's alright, was hoping you might have had a backup...


INotifyPropertyChanged

I'd like to see IChangeTracking declaratively implementing INotifyPropertyChanged, this already happens implicitly which requires many redundant casts.
Also please have IChangeTrackableCollection implement INotifyCollectionChanged, that would also be very nice.

Would love to have the IChangeTrackable interface inheriting all those interface (INotifyPropertyChanged/ing, IRevertibleChangeTracking and all the interface it actually inherits.


cmd/compile: possible liveness bug

type T [10]*int
func f(t T) {
	g = t
}
var g T

compiles to roughly:
autotmp_0 = t (using duffcopy)
if writebarriers_enabled {
    typedmemmove(&g, &autotmp_0)
} else {
    g = autotmp_0 (using duffcopy)
}

Problem: autotmp_0 is not considered live at typedmemmove.  The fact that typedmemmove (and callees) are marked as nosplit saves us, but I can't yet convince myself that there won't be other cases like this but without nosplit saving us.
$ go tool compile -live ~/go/tmp4.go
/usr/local/google/home/khr/go/tmp4.go:8: live at entry to f: t
/usr/local/google/home/khr/go/tmp4.go:9: live at call to typedmemmove: t   <- missing autotmp_0

(Another less serious issue is that autotmp_0 is unnecessary in this example, but compilers; go figure.)
Found using CL https://go-review.googlesource.com/23924
@aclements

@randall77 any movement here?

No, I have been unable to write a test that actually demonstrates a real bug.  I'm still working on it.

@randall77 should this block go1.7beta2?

No.

I've determined that typedmemmove is the only call for which this happens.  All other calls are ok.  So I'm marking this closed, I'll get my clobber code in (deactivated by default) for 1.8.