Add New Column - Invalid default value for the integer column

I built an OctoberCMS site on a Local VirtualBox LAMP server and moved it and the MySQL database to A2 Shared Hosting.

Error
The live site is working fine, but when I use the Builder plugin to add a new database column and save, I get the error:
Invalid default value for the integer column 'sort_order'. The allowed formats are '10', '-10'.

But the value is 10.

Server
My Local VirtualBox Server is running MySQL 5.7.29-0ubuntu<IP_ADDRESS>.
The A2 Hosting Server is running MySQL 10.3.22-MariaDB-cll-lve.

Database Connection
The database.php config file looks like this, with the database name, username, and password filled in.
'mysql' => [
    'driver'     => 'mysql',
    'engine'     => 'InnoDB',
    'host'       => 'localhost',
    'port'       => 3306,
    'database'   => '',
    'username'   => '',
    'password'   => '',
    'charset'    => 'utf8mb4',
    'collation'  => 'utf8mb4_unicode_ci',
    'prefix'     => '',
    'varcharmax' => 191,
],

Question
Why does saving the new column not work?
Does it have something to do with MySQL on the local server and MariaDB on the A2 server?

Set the default value of the sort_order column to 0.


⚡ feat(cms): working CRUD operations for courses and classes

Pog topic completed.

Could you explain how it works on Tuesday?

Could you explain how it works on Tuesday?

yessirrr! i'll walk you guys through it 😁👍


Changed typo in variable name on line 240, which caused -o flag to fail

Changed the variable passed to writeOutfile() as this referenced a non-existing variable.

Good catch, thanks for the PR!


参考sql server 更新统计信息算法(https://learn.microsoft.com/en-us/sql/relational-databases/statistics/statistics?view=sql-server-ver16),更新触发算法

参考sql server 更新统计信息算法(https://learn.microsoft.com/en-us/sql/relational-databases/statistics/statistics?view=sql-server-ver16),更新触发算法

@qiuwenhuifx hi, seems that your are trying to PR to a wrong branch. This PR is not mergeable.

@qiuwenhuifx closed due to not mergable.

/close

@mrdrivingduck ,which branch correct ?

Hi @qiuwenhuifx, you should raise PR to POLARDB_15_STABLE instead of master.


Add cairo tests as a project to use with cairo-native-test

Checklist

[ ] Linked to Github Issue
[ ] Unit tests added
[ ] Integration tests added.
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

Codecov Report
Attention: Patch coverage is 50.00000% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 79.34%. Comparing base (3d9ecb8) to head (4446dc4).

Files
Patch %
Lines

src/bin/cairo-native-test.rs
50.00%
8 Missing :warning:

Additional details and impacted files
@@                   Coverage Diff                   @@
##           implement_all_casts     #465      +/-   ##
=======================================================
+ Coverage                76.97%   79.34%   +2.37%
=======================================================
  Files                      111      111
  Lines                    32750    32763      +13
=======================================================
+ Hits                     25208    25997     +789
+ Misses                    7542     6766     -776

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


Fix build on GHC 7.8, 7.10, 8.0, 8.2

Note, I just uploaded testing-feat-<IP_ADDRESS> to Hackage, which supports GHC 8.6 through 9.2.

Note, I just uploaded testing-feat-<IP_ADDRESS> to Hackage, which supports GHC 8.6 through 9.2.


Remove table AS alias.

Fixes compatibility with Laravel Oracle. This is backward compatible to other RDBMS.
Please merge so that I don't have to maintain a fork just for compatibility with Oracle. And my fork is not updated too. :(
Thanks a lot! 🍻

Coverage remained the same at 89.802% when pulling 87343f2079a05170f07f4a04c3ba9dd7350c3311 on yajra:patch-oracle into 8c947f2ceb336f2fb0b5e5d1d0a2eb8a177e6f0e on gazsp:master.

Not sure why travis is failing but it's definitely not related to this PR. Thanks!

Fixed in develop/2.0 branch


build script deletes DLLs added by vcpkg to OUT_DIR

The build script deletes everything in OUT_DIR. The vcpkg helper copies all of the DLLs required by the application into OUT_DIR which allows cargo run etc to be able to start the app without adjusting the path. (I tested and for me it works if the DLLs do not get deleted.) If you'd like to change the existing behavior, cargo run works if the cleanup deletes everything but DLLs. It might be better to just to make the glob more specific about what to delete. If you'd like that changed I can do it - let me know if you want to only leave the DLLs, or what specific files you'd like to delete.
https://github.com/twistedfall/opencv-rust/blob/7e13d0ccf55a58655abb30cc3a267dea597a746c/build.rs#L549-L553

Oh, I see. Well, the source of the problem here is that vcpkg does its job before we call build_wrapper. I'll need to check if it's possible to fix that. In the meantime I'm more than happy to accept a workaround PR. Either way (removing everything but dlls or removing only specific files) is fine.

Not that I'm recommending you do it this way, but if you need to you can call vcpkg more than once, and on the early pass use it's config flags in order to not emit metadata and copy the dlls around.


Windows 10 x86 or Vista x86 support?

Hello, I would like to ask if it's possible to sumulate a battery on a 32bit Windows 10, or perhaps Vista.
I need to simulate battery on a laptop with that doesn't have one.
All I need is for windows to think there is a battery and that is has a charge.
Thank you, and sorry if this is unrelated to you project.

I haven't tested, but the simbatt project is most likely also compatible with 32bit Windows back to Windows 10. However, 32bit support was removed in 312d16301ef128947520e99a35b09995d7b21d33 so you'll need to add it back again yourself. Alternatively, you can build the official https://github.com/microsoft/Windows-driver-samples/tree/main/simbatt sample project from Microsoft, where 32bit support is still present.


Mistake in Hindi Version of Website

There is a small mistake in Hindi Version of the website. The same sentence is written in both English and Hindi, which doesn't make sense at all.
Screenshots of the issue

Would you like to work on the issue?
Yes, I would love to contribute a bit.

You can go ahead with a fix. Thanks.


Fix: multiscreen webview tray popup 152

Fixes issue #152 - allows to select screen to display webview tray popup.

I'll have a few review comments here and there but can we do the same exercise as we did with the other fix? (based at least on 2.1.0)

@amadeo-alex - sounds like a plan, I will do that in the next few days and let you know once done. :-)


Fix golang 1.10 build on Ubuntu with snap packages

Using -i in the "go build" arguments with Golang 1.10 on Ubuntu using
a snap package results in this error:
$ make -C daemon
  CHECK contrib/scripts/bindata.sh
  GO    daemon/cilium-agent
go build runtime/cgo: open /snap/go/2130/pkg/linux_amd64/runtime/cgo.a: read-only file system

According to the upstream issue, this is because it's attempting to rebuild
the core Golang packages on the system, and snap is preventing this via a
read-only file system to ensure consistency for the base Golang version.
The workaround suggested in the following issue is to remove -i.
https://github.com/golang/go/issues/24674
For more information, see the Golang 1.10 release notes:
https://golang.org/doc/go1.10#build

This change is

test-me-please

probably needs backport as will backport go 1.10?

Does this only affect developer builds or also the container image builds?

@tgraf Just developer builds.


Messages are not separated by line breaks when copied to the clipboard

Description
Copying and then pasting multiple messages does not insert newlines between comments. All messages are run together on a single line.
Proposed fix
When copying multiple messages, insert line breaks in between messages so that when pasted, each message occupies its own line.
OS and Chatterino Version
Windows 10
Chatterino 2.3.3 (commit c8c28d7f5)

This is the sort of issue that is well known but I assume everybody just accepted, as when I read this issue my first thought was
"Yeah it's been like that forever".
So opening this issue is a 👍

Fixed in https://github.com/Chatterino/chatterino2/pull/4812.


No devices found in 1-Wire mode

Hi all,
I just updated the firmware of my BP5 rev10 to @bbcff78 from @82d86ab.
Afterwards, BP doesn't find devices when in 1-Wire mode:

I have attached a ds18b20 (1-Wire) which works fine with the @82d86ab firmware:

1-Wire already stops working with the @ab07ef0 commit (various bug fixes, new bugs introduced probably 😁) so I guess something was broken there.
Would be great if someone could have a look.
Thanks!

I believe this was due to issues in PICO SDK2.0. I reverted to manually assigning the PIO resources and 1-wire has been tested to work on all hardware.


[NEW OSS PROJECT]: Virtual Finland Development

Are you a maintainer, or core-contributor, to the project?

[X] Yes

We already have a Pulumi.com account?

[X] Yes, we have created an account

Do you agree to regular check-ins, no more than once every 90 days, with a Developer Advocate from the Pulumi team?

[X] Yes

What's your Open Source project called?
Virtual Finland Development
What's your GitHub organization or repository?
https://github.com/Virtual-Finland-Development
What's Pulumi.com team ID?
virtualfinland
Do/would you like any assistance with your Pulumi adoption from the DevRel team?

[ ] Yes

The main Pulumi code we should link to is here right? https://github.com/Virtual-Finland-Development/infrastructure

Sounds about right: most (if not all) of the VFD-organization projects depend on the Pulumi tools. The infrastructure code repository project is a "root project" where other projects rely on and as such could be considered the main.

Sounds great. Will let you know when access is granted.

@lsipii ok, you are approved for a 1 year subscription of Team Edition for Open Source. Please make a pull request to add your org to the README.


999: Fix for xcode 15

Short description
Fixes builds with XCode 15
Proposed changes

add post install script

Resolved issues

Fixes: #999

fixed with xcode 15.0.1. no need for this pr


please make package.json version on github more useful

What is the suggested path for taking the github version of typescript as npm package dependency?
For instance, there are some small issues with the latest npm package 1.4.1, which are fixed in master, but master package.json still has version 1.4.0. So even if I npm install from the git repo, the version for the dependency can't be specified correctly.
My (naive?) suggestion would be:

master version should always be at least as high as latest npm version
add a build number to the version in master, and bump it every time the LKG is updated,

Btw, does anyone know how to specify a github dependency in package.json, without npm install being wasteful? Using
  "dependencies": "git+ssh://git@github.com:Microsoft/TypeScript.git"

npm (1.4.3) seems to clone the whole repo, when a shallow clone would be sufficient, and I don't want to think whether it is going to be more clever on updates. And while npm accepts tarballs, github offers zipfiles.
My best guess would be to specify the dependency with name and version only, then manually do something like
(cd ..;git clone --depth 1 git@github.com:Microsoft/TypeScript.git)
npm install ../TypeScript

If anyone has a good solution, that should perhaps go into the docs/readme somewhere?

Welcome back claus :smile:
We've been talking about doing a rolling-build style thing on NPM and should roll the above recommendations into that.

@clausreinke Meanwhile, you can use https://github.com/Arnavion/typescript-github
"dependencies": {
    "typescript-github": "https://github.com/Arnavion/typescript-github/tarball/2015-01-28-67023a83d520fe72cf723359198a931e36def0de"
}

@DanielRosenwasser just pump up the version to 1.5 everywhere.

@mhegazy  @DanielRosenwasser as long as version bump + fresh LKG always go together, that should help. If you don't like to spend a "real" version number for every build, add a build number.
(Since I raised concerns about npm github dependencies above: after the initial (too deep) clone, subsequent installs have been fast.)

grmpf. Now that you've been so helpful, npm is driving me crazy: even though I've got typescript 1.5.0 installed globally, it refuses to accept that as a dependency, no matter what I try to convince it to ignore the registry. But that seems to be an npm bug: npm/npm#5509 (and no, the workaround doesn't for me).

Labels:

bug
i-wanna-be-the-very-best

We should definitely adopt that label for some issues.

Should we consider this Fixed now?

submitter here: sure.
Is there a tracking issue for the npm build automation?
@DanielRosenwasser I wondered about the purpose of that label: since it isn't self-descriptive, it has the feeling of an inside joke.

Is there a tracking issue for the npm build automation?

Not currently, I'll set one up.

Since it isn't self-descriptive, it has the feeling of an inside joke.

It's a Pokémon reference. The intro song starts off with the lyrics "I wanna be the very best". The tag is basically as if to say "this is a very hard task, you must be very determined to figure out a solution".


Intro QuantitativeValueArray

@apdavison & @Peyman-N please double check if this would fit. This PR is related to #189

@apdavison @Peyman-N sorry for the errors in the JSON... it should be correct now

Seems ok to me too. Should I merge it?

if you both agree feel free to merge it yes :)


invokeai wip

Good job @TheAlpha0ne , but in order to qualify for rewards in this task, in addition to a working deploy.yml, you need to provide:

Full README.md with deployment description and links to the main project repository.
Image Dockerfile
Video demonstration of deploying your image on Akash Network.

Thank you!

Hey @TheAlpha0ne, tagging you here for visibility.
I just wanted to make sure you're aware of @Dimokus88's edited comment above, quote:
"@TheAlpha0ne Since you are using the custom image ghcr.io/ebr/invokeai:latest-cuda in your Dockerfile, you also need to provide Dockerfile image ghcr.io/ebr/invokeai:latest-cuda , so that we can make sure it is secure."

@TheAlpha0ne  thank you for your contribution!
Please update the top README.md file

Hey @TheAlpha0ne !
Can you add the necessary information so that the merge can be completed?

Not answer long time @TheAlpha0ne .
I think we can close this PR @brewsterdrinkwater


Update headers for missing transitive includes

🦟 Bug fix
Needed by https://github.com/gazebosim/gz-transport/pull/315
Summary
It turns out that gz-transport has been including gz/msgs.hh from a public header, so many downstream packages may be implicitly using the msgs header files without explicitly including them. That is certainly the case for gz-sim. As such, merging https://github.com/gazebosim/gz-transport/pull/315 would break any downstream packages without explicit include statements.
This pull request uses a neat trick enabled by https://github.com/gazebo-tooling/release-tools/pull/583 that allows the homebrew and windows jobs to build against the branch from https://github.com/gazebosim/gz-transport/pull/315 by using the ci_matching_branch/ prefix and updating the metadata in https://github.com/osrf/homebrew-simulation/commit/e08e0472bc15c129eb04a76e5b3a26afddfd199c and https://github.com/gazebo-tooling/gazebodistro/commit/7cbdc431d487a8a8e77e98fee6307abec67d4676 accordingly.
Checklist

[ ] Signed all commits for DCO
[ ] Added tests
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

I think we need fixes to gz-gui before this will build cleanly


TEAMNADO-4699 - Show product details pages in Prod

This removes the subscription number column from the table - to enable in prod we will need to flip the feature flag once this is deployed there

Codecov Report
Base: 93.91% // Head: 93.88% // Decreases project coverage by -0.03% :warning:

Coverage data is based on head (de11f26) compared to base (9a348fe).
Patch coverage: 100.00% of modified lines in pull request are covered.

:exclamation: Current head de11f26 differs from pull request most recent head b0879b1. Consider uploading reports for the commit b0879b1 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
- Coverage   93.91%   93.88%   -0.03%
==========================================
  Files          36       36
  Lines         460      458       -2
  Branches       98       95       -3
==========================================
- Hits          432      430       -2
  Misses         25       25
  Partials        3        3

Impacted Files
Coverage Δ

...onents/ExportSubscriptions/ExportSubscriptions.tsx
100.00% <ø> (ø)

...components/SubscriptionTable/SubscriptionTable.tsx
87.65% <100.00%> (-0.30%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Update Readme examples

importer.ImportCoco(Annot).ExportToYoloV5()

does not work.
importer.ImportCoco(Annot).export.ExportToYoloV5()

should be listed instead to make it easier for new users to get started.

Thank you for catching that and reporting it. I have made the change so I will close the issue.


Cloudp 185931

h4. WHY
Run e2e in debug mode to be able to reason the issues that are happening in e2e tests.
We are consuming a large amount of time trying to understand e2e flakiness and also some of the changes that happen in the backend
h4. How
We need to be able to enable debug flag on demand and disable this for certain methods. Meaning that debug cannot be applied globally due to some of the commands might print out dev env links that we do not want to be visible.

We will:
Inspect output
Remove debug from tests that might not be desired to run in debug.
Rerun entire test suite.


Chore: Update DevOps tooling from central repository [skip ci]

Update repository with content from upstream: os-climate/devops-toolkit

Not needed, there is a subsequent update.


Tests deadlock for 2.0.0-rc.1, phoenix and postgres

Environment

Elixir version (elixir -v):

Erlang/OTP 18 [erts-7.3] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]
Elixir 1.2.4

Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.): postgres (PostgreSQL) 9.5.1
Ecto version (mix deps): 2.0.0-rc.1
Database adapter and version (mix deps): postgrex(0.11.1)
Phoenix version: 1.1.4 (phoenix_ecto: 3.0.0-rc.0)
Operating system: OS X 10.11.4 MacBook Pro (Retina, 13-inch, Late 2013)

Current behavior
I updated ecto to 2.0.0-rc.1 from 2.0.0-rc.0 and change all tests to async based on this blog http://blog.plataformatec.com.br/2016/04/ecto-2-0-0-rc-is-out/ . Then the tests failed.(Sometimes it passed) The commit is here: https://github.com/tony612/exchat/commit/0097479d792b413c38468de01ec96f1fc06c812d
The error is like this:
     test/controllers/channel_controller_test.exs:35
     ** (Postgrex.Error) ERROR (deadlock_detected): deadlock detected

     Process 67939 waits for ShareLock on transaction 11786; blocked by process 67935.
     Process 67935 waits for ShareLock on transaction 11782; blocked by process 67939.

And I put the logs of three random failed tests in three gists:
https://gist.github.com/tony612/d8c713cef3c409d3a5b2ff38927d7b64
https://gist.github.com/tony612/dce4541d2e7ee6a36372bb801fe23c29
https://gist.github.com/tony612/88ada2da7f18ca36185d214013fc4640
Someting I found: The tests pass if I change Exchat.ChannelControllerTest to sync.

That's a very cool example, you can check you server log and try to understand more about it. I got this:
ERROR:  deadlock detected
DETAIL:  Process 18673 waits for ShareLock on transaction 42018; blocked by process 18679.
	Process 18679 waits for ShareLock on transaction 42023; blocked by process 18673.
	Process 18673: INSERT INTO "users" ("inserted_at","updated_at","email","password_hash") VALUES ($1,$2,$3,$4) RETURNING "id"
	Process 18679: INSERT INTO "channels" ("inserted_at","updated_at","name") VALUES ($1,$2,$3) RETURNING "id"
HINT:  See server log for query details.
CONTEXT:  while inserting index tuple (0,33) in relation "users_email_index"
STATEMENT:  INSERT INTO "users" ("inserted_at","updated_at","email","password_hash") VALUES ($1,$2,$3,$4) RETURNING "id"

The issue seems to be on the unique indexes. You have two or more transactions waiting for different indexes. One possible solution is to make sure you are using different e-mails per test. All of them seem to use the same e-mail, I would make sure to use a counter. Something like System.unique_integer([:positive]) is enough.

@josevalim I think so. And I write two simple cases to reproduce this error:
  # in one test file
  @tag :lock
  test "case1" do
    insert_channel
    insert_user
  end

  # in another test file
  @tag :lock
  test "case2" do
    insert_user
    insert_channel
  end

I change the log level to debug then I got the log:
15:42:46.076 [debug] begin [] OK query=0.2ms
15:42:46.077 [debug] begin [] OK query=18.4ms
15:42:46.103 [debug] INSERT INTO "channels" ("inserted_at","updated_at","name") VALUES ($1,$2,$3) RETURNING "id" [{{2016, 4, 23}, {7, 42, 46, 84957}}, {{2016, 4, 23}, {7, 42, 46, 84951}}, "general"] OK query=1.6ms
15:42:46.103 [debug] INSERT INTO "users" ("inserted_at","updated_at","email","password_hash") VALUES ($1,$2,$3,$4) RETURNING "id" [{{2016, 4, 23}, {7, 42, 46, 0}}, {{2016, 4, 23}, {7, 42, 46, 0}}<EMAIL_ADDRESS>"$2b$04$fnobMTs1pnVaPeWka7wHTOKANvfURzHiqH85QUQYeOS3kiSQWmPtG"] OK query=1.8ms
# ------> These two commits are not real commits, right? <-----
15:42:46.103 [debug] commit [] OK query=0.2ms
15:42:46.103 [debug] commit [] OK query=0.3ms
15:42:46.104 [debug] begin [] OK query=0.1ms
15:42:46.106 [debug] begin [] OK query=0.1ms
15:42:47.106 [debug] INSERT INTO "channels" ("inserted_at","updated_at","name") VALUES ($1,$2,$3) RETURNING "id" [{{2016, 4, 23}, {7, 42, 46, 104332}}, {{2016, 4, 23}, {7, 42, 46, 104330}}, "general"] ERROR query=1002.2ms
15:42:47.107 [debug] rollback [] OK query=0.4ms
15:42:47.108 [debug] INSERT INTO "users" ("inserted_at","updated_at","email","password_hash") VALUES ($1,$2,$3,$4) RETURNING "id" [{{2016, 4, 23}, {7, 42, 46, 0}}, {{2016, 4, 23}, {7, 42, 46, 0}}<EMAIL_ADDRESS>"$2b$04$grtD.b7FdQipDyZ8mSkOrevzrMkVDr.k8pfpANKzLCoT0bt9snSc6"] OK query=1001.8ms
15:42:47.108 [debug] commit [] OK query=0.3ms

  1) test user channel (Exchat.ChannelUserServiceTest)
     test/services/channel_user_service_test.exs:7
     ** (Postgrex.Error) ERROR (deadlock_detected): deadlock detected

     Process 49970 waits for ShareLock on transaction 12425; blocked by process 49969.
     Process 49969 waits for ShareLock on transaction 12424; blocked by process 49970.
     stacktrace:
       (ecto) lib/ecto/adapters/sql.ex:405: Ecto.Adapters.SQL.struct/6
       (ecto) lib/ecto/repo/schema.ex:373: Ecto.Repo.Schema.apply/5

I have only one question left for this problem: Though there're two commit log above but it's not real commits, right? It's still in a transaction and the lock is not released, so I got the deadlock, isn't it?

No, they are not real commits but rather savepoints (and savepoint rollbacks). Did you try using different e-mails?

@josevalim Got it. Yeah, it works. Thank you!


Ensure go vet works with the current Grafeas setup and add it back

Is your feature request related to a problem? Please describe.
Currently, vet command in the Makefile fails due to the missing files that are generated by the build command:
Makefile:37: recipe for target 'vet' failed
make: *** [vet] Error 1
aysylu@aysylu:~/go/src/github.com/grafeas/grafeas$ make
go/v1beta1/api/validators/build/build.go:24:2: no Go files in /usr/local/google/home/aysylu/go/src/github.com/grafeas/grafeas/proto/v1beta1/build_go_proto
go/v1beta1/api/validators/deployment/deployment.go:23:2: no Go files in /usr/local/google/home/aysylu/go/src/github.com/grafeas/grafeas/proto/v1beta1/deployment_go_proto
go/v1beta1/api/validators/discovery/discovery.go:24:2: no Go files in /usr/local/google/home/aysylu/go/src/github.com/grafeas/grafeas/proto/v1beta1/discovery_go_proto
go/v1beta1/api/validators/package/package.go:23:2: no Go files in /usr/local/google/home/aysylu/go/src/github.com/grafeas/grafeas/proto/v1beta1/package_go_proto
go/v1beta1/api/validators/provenance/provenance.go:23:2: no Go files in /usr/local/google/home/aysylu/go/src/github.com/grafeas/grafeas/proto/v1beta1/provenance_go_proto
go/v1beta1/project/project.go:23:2: no Go files in /usr/local/google/home/aysylu/go/src/github.com/grafeas/grafeas/proto/v1beta1/project_go_proto
Makefile:37: recipe for target 'vet' failed
make: *** [vet] Error 1

There were several other incompatibility issues discovered in the Grafeas codebase with go vet that haven't yet been addressed.
Describe the solution you'd like
Ensure all issues detected by go vet are fixed in the Grafeas codebase, and re-enable vet in the Makefile: build: vet fmt go_protos swagger_docs.
Describe alternatives you've considered
For now, the vet command is disabled in the build command.
Additional context
The issue is also reported in https://github.com/grafeas/grafeas/issues/308

I've run into other issues with vet, which is why we have -composites=false in the Makefile. I think it's best to re-enable this after a more thorough investigation into incompatibility.

Hi, I'm interested in looking into this issue. Can I get some context into this issue?

Hi @rxbchen, great to hear about your interest! This was filed, because when running make vet or go vet it'd fail with composite literal uses unkeyed fields. The first step would be to remove the flag overwrite and see if it's still failing, given the recent changes to the codebase.

Hey @aysylu I have make vet on macOS and a vagrant ubuntu image, it seems like it's working for me.

@rxbchen great! In that case, could you send a PR that removes this flag? Thanks.

@aysylu my bad, once I set -composites=true it breaks again :/ (I forgot to test that case)
I will continue to look into the issue and look for a fix.

@rxbchen sounds good, thank you!

Thanks, @rxbchen, for fixing this!


Incorporate kriging methods and documentation

This (draft) PR includes changes to the primary kriging methods and calculations up to estimating areal biomass densities and subsequent total biomass calculations as well as sex- and age-specific estimates. There are high-priority discrepancies in the final kriged coefficient of variation (CV) and areal biomass density estimates that require further investigation and changes (#202). The complete implementation of the stratified algorithm (i.e. Jolly Hampton, 1990) for the kriged results are forthcoming.

I tracked the above part about factoring blocks into functions in #203. We can address them there.
@brandynlucca : There are a few small comments (like paths) that can probably be addressed easily without this PR. Otherwise, feel free to merge this. Great that we have the kriging and downstream incorporated!

I'll merge this now so that #206 that is built on top of this can be cleaned up and merged too. I will create another issue to track the vectorizing comments.


Warning from fancyhdr package when document option twoside not specified

Here is the issue to fix:
WARNINGS:
tenth.cls:327: Package Fancyhdr Warning: \fancyhead's `E' option without twoside option is useless on input line 327.
tenth.cls:328: Package Fancyhdr Warning: \fancyhead's `E' option without twoside option is useless on input line 328.
tenth.cls:329: Package Fancyhdr Warning: \fancyfoot's `E' option without twoside option is useless on input line 329.

Fixed.


Building on Windows

Minimum set of support files to build on Windows. Use build_msvc.bat in a Visual Studio Command x64 Prompt to build with MSVC.
See #19 for some comments re /fp:fast and /O
https://github.com/karpathy/llm.c/issues/19#issuecomment-2053990872

@azret - thanks but there are still some other changes needed to support OpenMP 5.2. Will create a new PR for this per comments in https://github.com/karpathy/llm.c/pull/118

OpenMP

Yeah. We'll need add the Open ML option as well. For now just copy this files locally and add it in the build_msvc.bat.
I'll add the CUDA build scripts later tomorrow. (For now in Visual Studio create a new CUDA project and add the needed files)

@azret - the changes are in the PR already. Just creating a smaller version. Thanks.

Is \dev\win referenced in the batch file an official msvc path?

Closing this. See #19


Adding one parameter to deployment parameters file

In attempting to build the environment using the supplied azuredeploy.paramenters.json I noticed the InstallADFS sub-deployment was failing, this was due to the $cert variable in InstallADFS.ps1 being blank, as the domainFQDN eventually passed as a parameter was not present. Adding it here along with a cautionary note to avoid placing the wildcard, as installADFS.ps1 does this alrady.

Hello @jorlamd ! The parameter exists in the main template:
https://github.com/Azure/SimuLand/blob/main/2_deploy/aadHybridIdentityADFS/azuredeploy.json#L184-L190
It was not in the parameters file which would be good to add it yes. However, I do not think the issue is that it is blank. The issue might be that your CERT domain does not align with the domain that is provided by default 'simulandlabs.com' (You have to change that).
In the deployment steps, I explain what parameters need to be modified depending on the environment:
https://github.com/Azure/SimuLand/tree/main/2_deploy/aadHybridIdentityADFS#deploy-arm-template
I still believe this PR is valid because we did not have the domainFQDN parameter in the parameters file. Can you please add this description to this PR? :
https://github.com/Azure/SimuLand/blob/main/2_deploy/aadHybridIdentityADFS/azuredeploy.json#L187

Ah, you mean that the default value would've been populated by default and resulted in 'simulandlabs.com' not aligning with the provided CERT? If so, understood. Makes complete sense. Thanks for clarifying that detail.
re the description. Do you mean putting that text in the "value" field of the parameters file to make it match the description in the main template?

Correct, the default value would have been populated by default by the domainFQDN parameter in the main template.
Yes, I was wondering if you can modify the file that you have in the PR and basically have the same description as the parameter in the main template. Yes in the value:
https://github.com/Azure/SimuLand/blob/main/2_deploy/aadHybridIdentityADFS/azuredeploy.json#L184-L190
"domainFQDN": {
            "type": "string",
            "metadata": {
                "description": "The FQDN of the Active Directory Domain to be created"
            },
            "defaultValue": "simulandlabs.com"
        }

Please and thank you! then it should be good to merge.

Thank you @jorlamd !


Allow to configure "padding-line-between-statements" rule with the "yield" operator

Description
Allow to configure "padding-line-between-statements" rule with the "yield" operator.
By instance:
'padding-line-between-statements': [
  'error',
  {
    blankLine: 'always',
    prev: '*',
    next: ['break', 'continue', 'return', 'throw', 'yield']
  }
]

To Do

[ ] Validate if the proposed implementation is acceptable;
[ ] Add tests.

Hi :wave:
As I'm not sure if the proposed implementation is acceptable or it is pointing to the right direction, I'd love to receive some feedback before going further.
Thank you!


Implement Docker discovery

Implementation for #8173

I noticed that I completely missed the port option in my implementation. The value is currently ignored. Should I remove the port configuration option or add it as a fallback for containers which have no exposed ports?

Can you please add it?

Sorry for the "swarms" still left in the code, should have grepped before creating the PR.

Zero issue with this, this is why we do code review :)

Am I correct in assuming that you'll squash&merge the PR and so should not squash the code-review commits myself?

Yes

Am I correct in assuming that you'll squash&merge the PR and so should not squash the code-review commits myself?

Yes please :)

Can you please add tests in the config package?

Thanks for the implementation ! I'm glad to hear that the policy on integrations has changed <3
Code looks good for me, i don't have the time now to test it, but ASAP.

Thanks!


Improve Platform Event Channels query

I believe Platform Event channels entities start with an e (KeyPrefix in EntityDefinition).
So instead of querying all entities with QualifiedApiName ending with and e and then excluding the records that are not platform events, it should be more efficient to simply query entities with KeyPrefix starting by e.

Thanks for the PR @mehdisfdc, this is a great idea.
Could you run prettier on the Apex file that you modified?

Thanks for the PR @mehdisfdc, this is a great idea. Could you run prettier on the Apex file that you modified?

My bad. Done!

Perfect, thanks again for the contribution. I'll create a new release.


Updated .gitattributes

added missing .coveralls.yml and composer.lock
changed /docs/book to /docs (we don't need to include files like ISSUE_TEMPLATE.md, PULL_REQUEST_TEMPLATE.md, ...)

Thanks, @webimpress


Automated cherry pick of #2424: fix: 允许更改私有云region名称

Cherry pick of #2424 on release/2.10.0.
#2424: fix: 允许更改私有云region名称

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.10.0@3e99a2d). Click here to learn what that means.
The diff coverage is 0%.

@@               Coverage Diff                @@
##             release/2.10.0   #2427   +/-   ##
================================================
  Coverage                  ?   7.51%
================================================
  Files                     ?     410
  Lines                     ?   63882
  Branches                  ?       0
================================================
  Hits                      ?    4800
  Misses                    ?   58670
  Partials                  ?     412

Flag
Coverage Δ

#aFlag
7.51% <0%> (?)

Impacted Files
Coverage Δ

pkg/compute/models/cloudregions.go
2.31% <0%> (ø)

Continue to review full report at Codecov.

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

/lgtm

/approve


ci: migrate to ubuntu 22.04 with gcc-12

Codecov Report

Merging #70 (197369d) into main (d060669) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #70   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         1    -1
  Lines           91        27   -64
  Branches         4         4
=========================================
- Hits            91        27   -64

Flag
Coverage Δ

macos-12-clang
100.00% <ø> (ø)

ubuntu-22.04-clang
100.00% <ø> (?)

ubuntu-22.04-gcc
100.00% <ø> (?)

ubuntu-latest-clang
?

ubuntu-latest-gcc
?

windows-2022-cl
?

windows-2022-clang
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

lib/math/include/math/math.hpp
100.00% <0.00%> (ø)

test/math/math-test.cpp

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Spacer to blast

I have made some progress on this issue... However, It is not ready for merging.

I have set up the script to check for the presence of the spacer file based on accession_id
I have set up the script to check if the geneome file is current based on user specified parameter

A few import tasks need to finish.

Fetch file is not downloaded or not up-to-date
Perform Spacer Blast
Add default blast parameters
Convert file to command-line tool
Add unit-tests
Choose more appropriate file name

Thanks @lwgray! I could be missing something entirely, but it looks like these two commits overwrote each other somehow? I can't find the file that was changed.

Sorry about that I forgot to push my changes


Chrome on Ubuntu is detected as unsupported browser

Google Chrome version 69.0.3497.100 64 bit.

I have the same issue. Once this gets resolved, I can test changes on my local machine. Hopefully I'll be able to contribute to this awesome project!

Sorry Linux is not tested. But as @hugopeeters says, enabling chrome flag may work.


Migrate start.spring.io to use Track 2 libraries

Update "Getting Started" section in Spring Cloud Azure (https://spring.io/projects/spring-cloud-azure) section to use Track 2 libraries.
At the moment, they point to track 1 libraries.

Related to: #20681

@chenrujun  I think this one is duplicated by one of issue you created?

@stliu yes.
Closing this issue, because it's duplicated with #21295


Silent failure when Mistral API key not defined

If no API key is available in the keys.json file or LLM_MISTRAL_KEY environment variable, get_model_ids() fails silently when called in the register_models hook. This results in what appears to be a successful installation of the plugin, but no Mistral models are available.
❯ llm -m "mistral-large" hey
Error: 'mistral-large' is not a known model

I think this behavior is reasonable, but a bit hard to understand as an end user. I propose either documenting that this is what happens if the API key is missing or somehow using the models from the DEFAULT_ALIASES dict rather than relying on the API to generate the model list.
For the former, documenting that LLM_MISTRAL_KEY is the environment variable name used by the plugin would help. I was using the Python API, so I skipped the llm key set mistral step and naively assumed setting the API key as MISTRAL_API_KEY would work.
For the latter approach, the root issue will be more obvious to the end user, since the models would register without the API key then fail on the inference API request:
❯ llm -m "mistral-large" hey
Error: Client error '401 Unauthorized' for url 'https://api.mistral.ai/v1/chat/completions'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401

I tested this by deleting the mistral_models.json file and removing the mistral key from keys.json, then:
llm -m ministral-3b hi
Error: Client error '401 Unauthorized' for url 'https://api.mistral.ai/v1/chat/completions'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401

But if I do:
llm keys set mistral
# Paste key here

... then I get this, because it turns out API keys take a few minutes to "go live"
llm models

...
  File "/Users/simon/.local/share/virtualenvs/llm-mistral-LjsSd8B3/lib/python3.10/site-packages/httpx/_models.py", line 749, in raise_for_status
    raise HTTPStatusError(message, request=request, response=self)
httpx.HTTPStatusError: Client error '401 Unauthorized' for url 'https://api.mistral.ai/v1/models'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401

A few minutes later it worked - llm models returned:
Mistral: mistral/ministral-3b-2410
Mistral: mistral/ministral-3b-latest (aliases: ministral-3b)
Mistral: mistral/ministral-8b-2410
Mistral: mistral/ministral-8b-latest (aliases: ministral-8b)
Mistral: mistral/open-mistral-7b
Mistral: mistral/mistral-tiny (aliases: mistral-tiny)
Mistral: mistral/mistral-tiny-2312
Mistral: mistral/open-mistral-nemo (aliases: mistral-nemo)
Mistral: mistral/open-mistral-nemo-2407
Mistral: mistral/mistral-tiny-2407
Mistral: mistral/mistral-tiny-latest
Mistral: mistral/open-mixtral-8x7b
Mistral: mistral/mistral-small (aliases: mistral-small)
Mistral: mistral/mistral-small-2312
Mistral: mistral/open-mixtral-8x22b
Mistral: mistral/open-mixtral-8x22b-2404
Mistral: mistral/mistral-small-2402
Mistral: mistral/mistral-small-2409
Mistral: mistral/mistral-small-latest
Mistral: mistral/mistral-medium-2312
Mistral: mistral/mistral-medium (aliases: mistral-medium)
Mistral: mistral/mistral-medium-latest
Mistral: mistral/mistral-large-2402
Mistral: mistral/mistral-large-2407
Mistral: mistral/mistral-large-latest (aliases: mistral-large)
Mistral: mistral/codestral-2405
Mistral: mistral/codestral-latest (aliases: codestral)
Mistral: mistral/codestral-2405-blue
Mistral: mistral/codestral-2405
Mistral: mistral/codestral-latest (aliases: codestral)
Mistral: mistral/codestral-mamba-2407
Mistral: mistral/open-codestral-mamba
Mistral: mistral/codestral-mamba-latest (aliases: codestral-mamba)
Mistral: mistral/pixtral-12b-2409
Mistral: mistral/pixtral-12b
Mistral: mistral/pixtral-12b-latest

So one more bug to fix: if the API key is invalid the llm models command should still work.


Keyboard support

As far as I can tell, the panels can only be resized by using a pointer device, like a mouse. It would be awesome if the panels could also be resized using a keyboard!
I imagine that the dividers could be buttons instead of divs, and when focused, the arrow keys could resize the panels (maybe it could jump in increments of 10px at a time, to make it a bit less tedious).
I'm excited about this project and I'd be happy to promote it, if it was a bit more accessible!
Thanks for open-sourcing your work 😄

Support for the keyboard is actually planned! We're using Splitter in the next version of Devbook and we want almost everything to be controllable using a keyboard.
When you say if it was a bit more accessible do you have something else on your mind besides the keyboard use-case you described?

Awesome 😄 Thrilled to hear it! Thanks for the quick reply.
And nope — the keyboard stuff I mentioned is the only accessibility issue I'm aware of (though I'm definitely not an expert).

This could also be achieved by having a controlled Splitter and changing the tile sizes when manually when the correct keyboard shortcut is pressed.


Reference to archived repository

The answer to the question "Where can I get the source code for the code samples?" links to an archived repository.
It would be helpful if the linked repository were replaced with a link to an up-to-date repository.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 4abeff84-74e7-7fd3-db28-fa92683143c8
Version Independent ID: 9d289096-4cf9-cb30-0893-e9ae5a72a34d
Content: REST API samples - Azure DevOps
Content Source: docs/integrate/get-started/rest/samples.md
Service: azure-devops
Sub-service: azure-devops-ecosystem
GitHub Login: @chcomley
Microsoft Alias: chcomley

Unfortunately, we have been unable to address this issue in a timely manner. We sincerely apologize for the delay and are closing this issue. As we phase out GitHub issues for this repository, we encourage you to propose changes using public PRs or submit feedback through our updated control at the top of the page. For more information on our feedback systems, see https://aka.ms/contentuserfeedback.


add dnGREP v2.9.482

PR for #7719

[x] I have read the Contributing Guide.

Hey could you please rebase so that the PR doesn't include all the github actions bot's updates?

Please create a new PR from an up-to-date, specific branch.


drop sql test

Coverage decreased (-0.1%) to 65.167% when pulling 5e19f8c83e0dca672e5e9b79d6ff0f965e55c36a on AngLi-Leon:master into 8366c6c0c0ab7aab279aeb524409b34f2ab965a3 on cmu-db:master.

Why did you close this?

I find a mistake in my test case. Will change it and PR again.

No, just keep the same PR and push a new commit. No need to close/open a new one.

Coverage increased (+0.9%) to 66.172% when pulling 6c11ff7489d088d31b47cf99a12a6ce0ebb52626 on AngLi-Leon:master into 8366c6c0c0ab7aab279aeb524409b34f2ab965a3 on cmu-db:master.

Coverage increased (+0.02%) to 66.02% when pulling dfa3cf5424cf787f110077602c9a5904a64131ed on AngLi-Leon:master into 839406b90dcea7318002004183b6c18d7dbe0d6f on cmu-db:master.

Coverage increased (+0.2%) to 66.179% when pulling dfa3cf5424cf787f110077602c9a5904a64131ed on AngLi-Leon:master into 839406b90dcea7318002004183b6c18d7dbe0d6f on cmu-db:master.

Coverage increased (+0.5%) to 66.187% when pulling b16a8f2f33cbebe2181b28033e1861445069720f on AngLi-Leon:master into 6d7f8232224488277878ae1f47ec5152f6656c47 on cmu-db:master.


docs: elaborate on cluster failure scenarios

SRV:

when do you need to set up the record
what happens if this is done incorrectly
what do you need to do when a node fails
what happens during a DNS outage

Discovery:

what happens when the service is down

(note to self: related and/or Cf. https://github.com/coreos/etcd/tree/master/contrib/systemd/etcd2-backup-coreos)

related https://github.com/coreos/docs/pull/734

Moved to 3.0 milestone to re-examine after 2.3.0 release. The links in my previous comments show where we've solved about half of this issue already.

/cc @heyitsanthony Probably you can take over this work?


Feature Request: Store selected_unit along with base_units to determine appropriate value for display

On first edit of a form page, you can select the unit to enter.  Django-Pint will then convert it to the base_units to be stored.
The challenge with that is, the next time you edit the value, it defaults back to the base unit.
For example:
Edit1 for field with "minutes" as base_unit, entered:
8 days
After Save 1, the model stores 11520 (in minutes)
Edit2 for field:
value shows 11520 in minutes.  The user says "no, that should be 'days'" and selects that.  Doesn't realize the data doesn't auto update, and now you store 11520 days into the DB.
Or, the value shows 11520 minutes, but the end-user doesn't know that's 8 days.

Duplicate of #38


Make pep517 zip-safe when using Python 3.7.

NOTE: This does not add any new dependencies.
pep517 being zip-safe without an external dependency requires importlib.resources, which first became available in Python 3.7. With older Python versions, this PR falls back to the old behavior.
h/t to @jaraco for #50 which gave me most of the information I needed to figure this out.
Fixes #6.

Also if you have a better/preferred way to track if importlib.resources is available than the _HAVE_IMPORTLIB_RESOURCES thing, lmk and I'll be happy to change it.

@chrahunt looks like using your suggestion verbatim gives flake8 warnings (for assigning lambda to a variable + >79 characters on a line). About to try a variant of it and hoping 2.7 doesn't explode. :sweat_smile:

@chrahunt okay, it took a few tries (mostly because I only have Py3.7 on this system, so wasn't able to test everything locally), but I think I got it!

Love it. Thanks!

From what I see this makes finding _in_process.py work, but when it executes it I get
Traceback (most recent call last):
  File "/tmp/tmp8w05syzc", line 26, in <module>
    import compat
ModuleNotFoundError: No module named 'compat'

Is this expected?

FWIW I can certainly tell from looking here that the current _in_process.py is not going to work when run from a zipfile, because it's going to extra _in_process.py to a temporary location. For this to work _in_process.py is going to need to, as a rule, be self contained OR do some fallback thing like:
try:
    from pep517 import compat
except ImportError:
    import compat

However, it's probably a lot simpler and easier to reason about that it just stays self contained.

@lazka @dstufft can you provide more context on your environment, or a testcase? Because looking at it again, yeah, I'd expect problems. But I've been using this in a zipapp as part of a PEP517-compatible build system since January without issue, and now I'm not sure how I was doing so lmao

The context where this came up was in Debian where we unvendor the pip vendored dependencies as wheels (which is supported by pip).  In this case pip is trying to use pep517 as a wheel, running the script and failing.  The details are in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954256
There's a debian:unstable docker image you can fire up that makes it trivial to reproduce it (although that's about to change because I just uploaded a change to go back to the vendored pep517 as a work around until this is resolved).
Scott K

What @kitterma said (thanks, and thanks for the quick Debian fix!)
@kitterma from what I see you never uploaded python-pip-whl to unstable with an updated pep517, so the error there is the one you get before this PR.

@kitterma To be fair, while pip supports unvendoring the bundled dependencies, I don't think we've ever suggested that we support debundling them as wheels. We wouldn't do that, precisely because the wheel spec says clearly "while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged".

@pfmoore OK.  The current approach was developed in coordination with pip developers (@dstufft and maybe others, I don't know - it was before I was involved in maintaining pip in Debian).
Historically we had not debundled pep517 because it was not zip safe (I know now).  So this was started by me trying to use pep517 0.7.0 (the version pip bundles) as a wheel and it not working out well.  Fair enough, distro mistake, distro problem.
The upstream issue is that this update was supposed to make pep517 zip safe, but it didn't.  It's incomplete.  If it had, then updating to the current version would have worked.  Since the additional change needed to achieve the goal of this PR is small, I think it makes sense to go ahead and do it.
I'll be glad to prepare a new request that either inlines compat or adds the fallback import that @dstufft suggested was an option above.  Please let me know which you'd prefer.

@pfmoore That's not true actually, our unbundling logic explicitly looks for wheels, and when we still had tests that explicitly tested the unbundled configuration, we were testing them as wheels not as unzipped directories. The process for unbundling is documented here, which also explicitly documents the use of wheel files.
We can of course change that, and look for something different, but our unbundling logic is setup the way it is because we don't want distros to just do the simplest thing to unbundle (just unbundle like a normal python package and use the versions installed into site-packages) but instead we want them to effectively re-vendor their patched versions of our dependencies (so that like, pip install requests still doesn't actually break pip to the point you can't use pip anymore). When I worked with barry on this, this was the simplest thing we could get to work that satisfied both of our constraints.

Also this bug doesn't just happen inside wheels, the bug is effectively that pip517 is not zip safe in it's current form. It has some code to make it zip safe, but that code isn't sufficient-- so either pep517 should go the rest of the way and become fully compatible with zip import, or it should rip out the zip import support logic that currently exists and declare zipped imports as unsupported.
A middle ground with some overtures to working under zip import, without actually working under zip import seems like the worst of all possible options.

@dstufft @kitterma My apologies, I was obviously commenting without knowing what I was talking about 🙁 I don't really have a view on how this gets fixed, TBH (or even if it gets fixed) - I'll leave the decision to someone who understands the trade-offs better.

Given that the lack of zip safety seems specific to use of compat.read_json() and compat.write_json(), and how small those functions are, I think inlining it (like @dstufft suggested) is a reasonable approach.
@dstufft @pfmoore would you like me to submit a PR for this?

It has some code to make it zip safe, but that code isn't sufficient

In so far as people look to me to maintain this project: I don't personally care about zip-safety - I think the idea that you can put arbitrary packages in a zip file and then import them is a ship that sailed many years ago. But I don't object if other people want to make this package zip-safe, so long as what's necessary to do so isn't too drastic.

@takluyver I wouldn't expect it to be too drastic, but if I make a PR for it I'll be sure to @-mention you so you can provide feedback. :+1:

Thanks, go for it :-)
On Wed, 1 Apr 2020, 18:15 Ellen Marie Dash<EMAIL_ADDRESS>wrote:

@takluyver https://github.com/takluyver I wouldn't expect it to be too
drastic, but if I make a PR for it I'll be sure to @-mention you so you can
provide feedback. 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pep517/pull/55#issuecomment-607378919, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACQB5PDSYNPNRX5URJOVADRKNZDVANCNFSM4H7K3DKQ
.

Just opened #78 to fix this.

I've confirmed that it does fix it.  Thanks.


🔄 Synced file(s) with jhudsl/OTTR_Template

Synced local file(s) with jhudsl/OTTR_Template.

Changed files

Synced local  .github/workflows/docker-build-test.yml with remote  .github/workflows/docker-build-test.ymlSynced local  .github/workflows/transfer-rendered-files.yml with remote  .github/workflows/transfer-rendered-files.ymlSynced local  .github/workflows/style-and-sp-check.yml with remote  .github/workflows/style-and-sp-check.yml

This PR was created automatically by the repo-file-sync-action workflow run #1608525675

Please carefully review these changes and decide which are useful for your course.
See the release notes: https://github.com/jhudsl/OTTR_Template/releases

If you don't want the changes from a particular file, you can always revert that particular commit before merging the sync PR.
If you will not want any updates on this file in the future, you may want to remove a file from being synced in your repo by reconfiguring the sync file.

If you want only some changes, but they are not on a whole file basis, you could check out the branch and make manual edits. To checkout the branch, navigate to your own repository you should be able to run:

git checkout repo-sync/OTTR_Template/default

If you don't want any of the changes you can close the PR entirely.

You may want to unenroll your repository from the sync GitHub actions by filing a PR on OTTR_Template
to delete your repo name from this file if this will continue to be the case.


Add per-capita option

Addresses #1

This is ready for a review. I've added a dropdown where you can choose between cases "absolute" and "per capita".

Your math is off by three to six orders of magnitude (1000-1000000)
US doesn't have 93% of its population infected!
Neither does Andorra have 603% of its population infected!
Check your math and units, and take special attention to formatting of your population size data source.

I was going to add a pro capita toggle! I'm happy you're already working on it! It would be great!

FYI, you should read the comment @aatishb wrote on this topic some time ago: https://github.com/aatishb/covidtrends/issues/30#issuecomment-607927252

Thank you Noël Macé, but I have already read it some time ago.
If the point of the graphic is to onley see the shape of the curves, and
not to compare them in lots of different ways, then why display them
together and not one by one, or just throw them in all together without
option to select anything?
IMHO the comment brings up valid but still not quite convincing points, and
is on a "personal decision of the autor" level.
Anything You want to add to #30 (comment), or are you just a messenger to
all of us unenlightened ones?
On Wed, 15 Apr 2020 at 22:51, Noël Macé<EMAIL_ADDRESS>wrote:

FYI, you should read the comment @aatishb https://github.com/aatishb
wrote on this topic some time ago: #30 (comment)
https://github.com/aatishb/covidtrends/issues/30#issuecomment-607927252
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aatishb/covidtrends/pull/25#issuecomment-614273599,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANIFIGMEW5WCVIDJ2A257T3RMYM6LANCNFSM4LWCJMHQ
.

Just want to remind folks of our code of conduct, which I’m excerpting here.
Be respectful. Disagreement is not an opportunity to attack someone else's thoughts or opinions. Although views may differ, remember to approach every situation with patience and care.

@mrelg this was just an FYI. Nothing more than "hey BTW, there is a discussion about that, maybe it could be useful to read it". I personally run this branch locally on a daily bases, as it's useful to me alongside the version on the master. Yet, I understand and respect @aatishb  work and opinion. Anyone who doesn't is free to run their own fork or better, to contribute to the discussion respectfully.

Ok Noël, duly noted, can I go now and mind my own business elsewhere and be
part of conversation of my own choosing?
Miloš Radovanović
On Thu, 16 Apr 2020 at 16:43, Noël Macé<EMAIL_ADDRESS>wrote:

@mrelg https://github.com/mrelg this was just an FYI. Nothing more than
"hey BTW, there is a discussion about that, maybe it could be useful to
read it". I personally run this branch locally on a daily bases, as it's
useful to me alongside the version on the master. Yet, I understand and
respect @aatishb https://github.com/aatishb work and opinion. Anyone
who doesn't is free to run their own fork or better, to contribute to the
discussion respectfully.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aatishb/covidtrends/pull/25#issuecomment-614697155,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANIFIGKZJK2MWYCNZPKQCK3RM4KQVANCNFSM4LWCJMHQ
.

Sorry Aatish, didn't mean to offend or attack anyone.
I'm just highly allergic to unsolicited FYI-s that don't actually say
anything.
I may disagree about things with people but when I don't have anything to
say I prefer to keep myself away from conversations, and hate being drawn
back into them.
Nothing but respect from
Miloš Radovanović
On Thu, 16 Apr 2020 at 16:16, Aatish Bhatia<EMAIL_ADDRESS>wrote:

Just want to remind folks of our code of conduct, which I’m excerpting
here.
Be respectful. Disagreement is not an opportunity to attack someone else's
thoughts or opinions. Although views may differ, remember to approach every
situation with patience and care.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aatishb/covidtrends/pull/25#issuecomment-614681076,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANIFIGJWDVQ6FWFIDUQHRVTRM4HM3ANCNFSM4LWCJMHQ
.

@mrelg We have deleted your comments for being off-topic and not living up to our code of conduct.
Just to be clear, all of these comments are being posted on a public thread. As far as we can tell, @noelmace’s comment was not addressed to you but to the whole audience on this thread. You may inadvertently be getting email notifications from this comment thread, which you are free to unsubscribe from.
We will also be deleting any further off-topic comments. Just as a heads up, repeated code of conduct violations will result in being blocked from this repository.
– @aatishb & @mustpax


Confusing/misleading information about Throughput Unit limit for a partition

[The section "How many partitions do I need?" quotes that "There is no specific throughput limit on a partition, however the aggregate throughput in your namespace is limited by the number of throughput units". I think this is wrong because there is a limit of 1TU per partition. And thereby it is recommended to have more number of partitions than the total TU's one is buying. ]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 51c58d87-83ad-9328-d98e-ffd1b608cc1d
Version Independent ID: 14f3b461-c371-311d-b311-91610c8fc6db
Content: Azure Event Hubs FAQ
Content Source: articles/event-hubs/event-hubs-faq.md
Service: event-hubs
GitHub Login: @sethmanheim
Microsoft Alias: sethm

@bidyut1990 Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@TravisCragg-MSFT Please assign to @ShubhaVijayasarathy.

@bidyut1990 - there is no limit on the partition. A single partition can do at least 1 TU. This is the reason, we recommend to do 1:1 mapping with the number of TUs to the partitions. The charge is on the number of TUs you purchase and only ingress is charged. Although we do not charge your egress, we do not let you egress more than two times your purchased TUs.

I have a question regarding number of partitions. In the first sentence you say 'The partition count on an event hub cannot be modified after setup. With that in mind, it is important to think about how many partitions you need before getting started.' but then 'As you increase the number of throughput units in your namespace, you may want additional partitions to allow concurrent readers to achieve their own maximum throughput.' Can you please comment?

Confirmed with the product team that the partition count can only be increased for event hubs in the dedicated tier. I will update the statement to reflect this.

Confirmed with the product team that the partition count can only be increased for event hubs in the dedicated tier. I will update the statement to reflect this.

Thanks for the update @spelluru.

Thanks for the update @spelluru.

Thanks for the update @spelluru.

Thanks for the update @spelluru.

Statement is updated with "in all tiers except the dedicated tier".
#please-close

Statement is updated with "in all tiers except the dedicated tier".
#please-close


Updated Age Verification proposal aligned with Spring25

What type of PR is this?
Add one of the following kinds:

enhancement/feature

What this PR does / why we need it:
This PR include all the changes and suggestions that haven been made these past months regarding Age Verification in PR #50.
It is a clean version with errors and descriptions aligned with the latest version of Commonalities for Spring25 meta release.
Additionally, it contains a proposal to include two new fields in the response: contentLock and parentalControl. Both fields come from the feedback of our partners in the UK.
This PR is ment to replace PR #50 as it seems easier to work on a updated fresh copy.
Please leave any comments or changes you feel appropriate.
Thanks!

I'm happy with this, so approving. A couple of comments for you to think on:

Linting is not enabled for this repository, so you might like to run that separately
You might like to add some guidance around providing the birthdate information. If an API consumer really knew the date of birth of the customer, they wouldn't need to use this API! So I assume this information is useful only in that it allows us to verify the customer more quickly in case they API consumer knows the correct date of birth. But if it is incorrect, it will be ignored and other parameters used to verify the identity of the customer.

@fernandopradocabrillo Thanks for this consolidated PR
The latest API Design guidelines add requirements for api-name and using it in file name and servers url .
I would also take the location-verification API as the reference.
Hence I suggest to set api-name=kyc-age-verification then we get:

filename:  kyc-age-verification.yaml
url: "{apiRoot}/kyc-age-verification/vwip"
path: (verb)

paths:
 /verify:

security:

   - openId:
          - kyc-age-verification:verify

operationId - OperationIds are defined in lowerCamelCase
verifyAge - in line with location verification

tags - Title Case
Age Verification

I'm happy with this, so approving. A couple of comments for you to think on:

Linting is not enabled for this repository, so you might like to run that separately
You might like to add some guidance around providing the birthdate information. If an API consumer really knew the date of birth of the customer, they wouldn't need to use this API! So I assume this information is useful only in that it allows us to verify the customer more quickly in case they API consumer knows the correct date of birth. But if it is incorrect, it will be ignored and other parameters used to verify the identity of the customer.

@eric-murray Thank you for the review! I will pass the linter locally, and I'll raise a PR to include it in the repo later (after Holidays probably haha)
Regarding the birthdate, from TEF we agree... It was in the original proposal and I just left it there, but you are right, it doesn't make much sense.
wdyt about the birthdate @GillesInnov35 @ToshiWakayama-KDDI

@fernandopradocabrillo Thanks for this consolidated PR
The latest API Design guidelines add requirements for api-name and using it in file name and servers url . I would also take the location-verification API as the reference. Hence I suggest to set api-name=kyc-age-verification then we get:

filename:  kyc-age-verification.yaml
url: "{apiRoot}/kyc-age-verification/vwip"
path: (verb)

paths:
 /verify:

security:

   - openId:
          - kyc-age-verification:verify

operationId - OperationIds are defined in lowerCamelCase
verifyAge - in line with location verification
tags - Title Case
Age Verification

Thanks @rartych, I have applied the changes to align with commonalities guidelines

I'm happy with this, so approving. A couple of comments for you to think on:

Linting is not enabled for this repository, so you might like to run that separately
You might like to add some guidance around providing the birthdate information. If an API consumer really knew the date of birth of the customer, they wouldn't need to use this API! So I assume this information is useful only in that it allows us to verify the customer more quickly in case they API consumer knows the correct date of birth. But if it is incorrect, it will be ignored and other parameters used to verify the identity of the customer.

@eric-murray Hi Eric, this  birthdate information is what the use claims it to be. If it it does not match, you are sure the end user is not the contract owner, and you can not return a reasonable answer.  We propose to reply with "not_available" and not provide an identityMatchScore. See also the proposal I made here: https://github.com/camaraproject/KnowYourCustomer/issues/81#issuecomment-2425951384

@HuubAppelboom

If it it does not match, you are sure the end user is not the contract owner, and you can not return a reasonable answer.

OK. So the API also allows the API consumer to confirm whether the DoB they have been given by the customer is correct.

@eric-murray Yes, the DoB is then used as a first tollgate check. If it matches, you continue to processing the other input parameters that have been provided with which you can calculate the aggregate identity match score.

@fernandopradocabrillo Thanks for this consolidated PR
The latest API Design guidelines add requirements for api-name and using it in file name and servers url . I would also take the location-verification API as the reference. Hence I suggest to set api-name=kyc-age-verification then we get:

filename:  kyc-age-verification.yaml
url: "{apiRoot}/kyc-age-verification/vwip"
path: (verb)

paths:
 /verify:

security:

   - openId:
          - kyc-age-verification:verify

operationId - OperationIds are defined in lowerCamelCase
verifyAge - in line with location verification
tags - Title Case
Age Verification

Thanks @rartych, I have applied the changes to align with commonalities guidelines

Hi @Fernando, @Rafal, all,
Thank you for intensive review of Age Verification API.
But, from KDDI side, I cannot accept all of this kind of last minute fundamental changes.  We have already started implementation work, as this API has been discussed since January and the discussion had become stable before.
From KDDI side, I would like to ask to revert url and path to the previous ones, i.e.

url: {apiRoot}/kyc-ageverify/vwip
path: /ageverify
Consecurtly I would propose to change the filename to: kyc-ageverify.yaml.

I do not think the above is not against commonalities guidelines.
Sorry for the late response due to the time difference, but your understanding would be appreciated.
Best reagrds,
Toshi
KDDI

Hi all,
I am checking other changes e.g. error responses, made by European colleagues during my night.  Please allow me to take some time and comments.
Best regards,
Toshi
KDDI

Hi @fernando, @rafal, all,
Thank you for intensive review of Age Verification API.
But, from KDDI side, I cannot accept all of this kind of last minute fundamental changes. We have already started implementation work, as this API has been discussed since January and the discussion had become stable before.
From KDDI side, I would like to ask to revert url and path to the previous ones, i.e.

url: {apiRoot}/kyc-ageverify/vwip
path: /ageverify
Consecurtly I would propose to change the filename to: kyc-ageverify.yaml.

I do not think the above is not against commonalities guidelines.
Sorry for the late response due to the time difference, but your understanding would be appreciated.
Best reagrds, Toshi KDDI

Hi @ToshiWakayama-KDDI,
Sorry, I think you mentioned this before. For me there is no problem in reverting to the previous name and aligning the filename.
I like this one better, by I can live with it 😄

Hi @GillesInnov35 , @ToshiWakayama-KDDI , are you happy with the PR?
Let us know if you have any additional comment, as I understood the objective would be to close the RC within this week
Many thanks in advance
Clara

@ToshiWakayama-KDDI

But, from KDDI side, I cannot accept all of this kind of last minute fundamental changes. We have already started implementation work, as this API has been discussed since January and the discussion had become stable before.

The registered name for this API in the API Backlog WG is, and always has been, "KYC Age Verification". If you want it to be known as "KYC Age Verify", then you should submit a PR to that WG to get it changed. Even then, the name in the URL should be /kyc-age-verify (i.e. url: {apiRoot}/kyc-age-verify/vwip) following Commonalities rules.

hi @claraserranosolsona, I've discussed internally with my team. Regarding parentControl and contentBlock, they submitted those ideas

each country should have possibility to decide/manage if those kind of information should be returned
the requester should indicate clearly if information are expected (scope or claims).
I've scheduled a point this afternoon. I guess I'll have a decision from our side
Thanks a lot
BR
Gilles

@claraserranosolsona, after an discussion at Orange see bellow our quick comments

those information are not determinist while the other are determinist (ageCheck, verifiedStatus).
if we decide to include those information, they should be returned only if the developer ask for them (request body or claims)
some countries will probalbly decide not to return those information. In that case, will the returned value be unavailable ?
Thanks
BR
Gilles

Hi @GillesInnov35 , @ToshiWakayama-KDDI , are you happy with the PR? Let us know if you have any additional comment, as I understood the objective would be to close the RC within this week Many thanks in advance Clara

Hi @claraserranosolsona ,
I should comment it is not possible for us to complete checking of these big bunches of changes from the previous version.  I am still discussing with my implementation / product teams.  Fortunately, I do not think we have to close the RC within this week now, and I think we should extend the target date of the RC.
Regarding the addtional paramters, 'contentLock' and 'parentalControl', as our quick response, we should be fine with them as long as they are optional and they don't add mandatory logic to the API backend.  (In addition, I am not sure if they are related to verifying age, but it is fine with me.)
Many thanks,
Toshi


Fixes issue 405 - adds ability to disable version cleanup

This addresses the issue #405 - using a value of -1 for RetainedVersions to disable the cleanup of deployed versions.
I'm opening a related issue around refactoring this behavior, but this one seemed clear.
I also added some tests that allow us to test the private methods of the function package. If someone wants to do this in a better way, please modify or make suggestions! I just needed to get some coverage in for this logic since it's sort of... odd.
Finally, I added a default RetainedVersions value as a const in function and will separately propose that we do the same for a couple of const values in project
🔬

LGTM other than the pointer thing you mentioned in the issue

Is this PR still needed if there is https://github.com/apex/apex/pull/408?

@mthenw it depends on how you guys wanna go with it.
I submitted #405 to address that Issue, then submitted this one for discussion. If you guys are ok with some pointer vs value refactoring, I think there may be a few things I can shift in a different issue...
But yeah, ultimately, you're right: this and #405 are mutually-exclusive.
Keep in mind that this one may be a "breaking change" because the value map is different (0 means zero, there is no -1, and default is nil and subs to 10).
That would require at very least some prominent changelog visibility, so we may want to be conservative about it... Your call, guys!


chore: use set instead of export in windows batch

Fixes: Build complains about export command
What was the problem/requirement? (What/Why)
Test phase under win-64 platform uses the batch file and complains about export command
What was the solution? (How)
Use set instead of export in windows batch
What is the impact of this change?
Environment variables are set
How was this change tested?

Build package under win-64, observe test phase complains about export, build succeeds anyways
Change export to set
Build package again, output is cleaner

If this is a sample, then please describe the steps that you took to test it.
Include output from your testing to demonstrate it working as expected if possible.

Was this change documented?
Not applicable

For instance, if applicable, has the sample's description been updated?

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

We have a couple different patterns for conda build scripts in our samples and packages. In some cases for Windows, we've made .bat files that are meant to be run as Windows batch files. In some cases like this one, we've made a .sh file for Windows that's intended to be run with Git Bash for Windows. Using bash for both Linux and Windows scripts makes it a bit easier to support platforms at the same time.
So TLDR: I think these commands are correct and should be run with Git Bash.

Reviewing this older PR, it looks like it is correct and we should apply it. The change is modifying the .bat files produced. Apologies for the confusion and delays in getting this in!


build(dependabot): ignore minor and patch github-actions updates

See https://github.com/pinojs/pino/pull/1224

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
42

Relevant Lines:
42

💛  - Coveralls


CIP-1694 update | Introduce governance action fee instead of deposit

(summary) - (all changes)

Here are some concerns I have about this:

People are now disincentivized to make proposals.
DReps can hold something hostage by voting No, since it collects the fees and anyone making a good change (whatever that means) has to put up more and more money.
What about Abstain voters? Should they be rewarded? I think not, since then there's an incentive to just vote Abstain on everything, giving you a second staking income.
The previous issue arguably also applies to voting No every time, only voting Yes on something that will give you a direct profit. But only rewarding Yes voters has a strong feeling of buying votes.

Thanks for sharing this proposal @KtorZ.
If fees or any direct, quantitative incentive are introduced, it might prompt a majority of DReps to vote on as many governance actions as possible to maximize rewards. Consequently, the merit-based review of governance actions by DReps could become obsolete. The silver lining is that such behaviors would be visible on-chain, allowing delegators to assess their DReps' actions and determine whether they make informed decisions or merely farm rewards.
I still think it is an interesting approach, and I would strongly prefer a visible on-chain "bribery" system over a hidden black market for buying DRep votes.
It's probably not feasible for MVG, but could a system be introduced that slashes the deposits of DReps that always vote Yes, No or Abstain to farm rewards?


Gradio Demo doesn't work

The demo at https://huggingface.co/spaces/xunsong/Moore-AnimateAnyone fails, even when using the example inputs.

When clicking the animate button, we only see the word "Error". Chrome reports this message:
iframeResizer.contentWindow.js:171 [iFrameSizer][iFrameResizer0] No tagged elements (data-iframe-height) found on page

The online demo is unstable, we have restart the workspace.

its still not working, could you check please @lixunsong

@Praenei thanks, I have access to my university A100, so I will try to check the inference/demo code in a while later after setting it up..


Update upgrade schedule files and gitignore

Description
When BABEL_4_X_DEV was originally cut for 16.4 development, the upgrade schedule file for 15.7 and 16.3 were mistakenly copied from 15.6 and 16.2 instead of using the (at the time) latest schedule files. This commit updates the 15.7 and 16.3 schedule files to match the previous latest schedule files.
Also update the gitignore file to properly ignore the autogenerated upgrade scripts, as we have now hit double digits for the minor versions.
Issues Resolved
[List any issues this PR will resolve]
Test Scenarios Covered

Use case based -

Boundary conditions -

Arbitrary inputs -

Negative test cases -

Minor version upgrade tests -

Major version upgrade tests -

Performance tests -

Tooling impact -

Client tests -

Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 73.21%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
42888

Relevant Lines:
58582

💛  - Coveralls


Add reporter in BackgroundTask.

Tested new created session with custom timeout.
Extend types formating.

Changes

How to test these changes?

Related issues

Need add new variable in aws env storage: MOONSTREAM_QUERY_API_DB_STATEMENT_TIMEOUT_MILLIS


Fixed attaching messages to message box global

Without en, it currently just returns "invalid fieldName" when denyUpdate errors are triggered.
Also added periods to errors, personal preference possibly.

@aldeed - Take a look at this when you get the chance, thanks


Localize tooltips

https://github.com/Parker8283/IguanaTweaks/blob/master/src/main/java/iguanaman/iguanatweaks/events/IguanaEventHook.java

And I would've gotten away with it, If it weren't for you meddling lang contributors :P
I'll fix that later today.


Failure to use save_obj() function to save mesh model with textures

Hi, I tried to save style transferred mesh using save_obj() function like following.
...

# draw object
model.renderer.background_color = (1, 1, 1)
loop = tqdm.tqdm(range(0, 360, 4))
for num, azimuth in enumerate(loop):
    loop.set_description('Drawing')
    model.renderer.eye = neural_renderer.get_points_from_angles(2.732, 30, azimuth)
    images = model.renderer.render(*model.mesh.get_batch(1))
    image = images.data.get()[0].transpose((1, 2, 0))
    scipy.misc.toimage(image, cmin=0, cmax=1).save('%s/_tmp_%04d.png' % (directory_output, num))
make_gif(directory_output, args.filename_output)

# save model using save_obj() function
vertices = model.mesh.vertices.data
faces = model.mesh.faces
textures = model.mesh.textures.data
neural_renderer.save_obj("output.obj", vertices, faces, textures=textures)

But outputted texture is not same as renderred image.

Renderred image(gif)

Outputted mesh (I used Meshlab to view this.)

My environment is

Ubuntu16.04
Python3.5
Chainer4.1.0
Cupy4.1.0
Cuda9.2,
Cudnn <IP_ADDRESS>
nccl2 2.3.5-2

Do you have any idea to solve this?

I also encountered the same problem exactly, could you please tell me how to solve this issue? Thanks!

I am trying to replicate the same command, unfortunately, the save_obj function is throwing a compilation error.

Same problem aswell. Please help!

Can I get the complete code for drawing objects?


Update Set-LabelPolicy.md

NextLabel and PreviousLabel param updates per email thread.

Docs Build status updates of commit f31805e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Set-LabelPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

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


Issue 497: Ignore full scan settings when doing peak picking in SRM result files

Fixed so Skyline ignores Transition Full Scan settings when doing peak picking in SRM result files (reported by Brendan)
This required adding a flag to ChromFileInfo and ChromCachedFile so that we can tell which files we extracted by ChromatogramDataProvider, and which came from SpectraChromDataProvider.
Added a unit test which makes sure that library retention times are never used for peak scoring in SRM runs regardless of the Transition Full Scan settings.

Obviously need to fix the warnings in your new test to pass code inspection.


Which model is better for modern French as a pre-training model

The target language is not relevant since no (strong) language model is learned. Select the model that was trained on fonts that look similar to your target font.

Thank you so much. I didn't make myself clear. Now my situation is like this:
I have 500 French data with labels. I want to label more French data, so I want to fine-tune a model as a start. (This method works well in English with 'uw3-modern-english' as pre-training model ).
So do you have any suggestions, I am very grateful.

there are several somewhat suitable models and all have some advantages and disadvantages. personally, i would try uw3 or one of the two french ones. if you want to train a voting ensemble i recommend using a mixed ensemble as a starting point. for example using model 0 from each of the french, uw3, and idiotikon ensembles.

Thank you so much. I have tried that.
I finetuned those related to French, and then ensembled all of them.
Maybe my font is quite different from these, and the final effect is not very good.

Thank you very much, I will close this issue and try something else.


Extract inferred external Props from a React Component with defaultProps

Search Terms
ElementProps, ElementConfig, "component props with defaultProps"

Suggestion
Now that TypeScript infers the external Props API for a Component with defaultProps, it would be helpful to add a type that returns the inferred props from a component. Flow accomplishes this with "React.ElementConfig".

Use Cases

Extending React components and re-using their prop types without re-writing them.

Examples
class Test extends React.Component<{ foo: string, bar: number }> {
  static defaultProps = {
    foo: 'baz',
  }

  render() {
    ...
  }
}

type TestProps = React.ElementConfig<Test>; // { foo?: string, bar: number }

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)

Would be nice to put that in the React .d.ts file for consistency

class Test extends React.Component<{ foo: string, bar: number }> {
  static defaultProps = {
    bar: 'baz', <-- Error, Type 'string' is not assignable to type 'number'.
  }

  render() {
    ...
  }
}

So we don't have to declare defaultProps as Partial<{ foo: string, bar: number }> or something like that.
(Sorry, if this should be an issue on its own I will gladly create it)

Yeah, exactly, and that's the bug I would like TypeScript to detect :-) Sorry, that I didn't made that clear! At the moment you can set whatever key value pairs you want in defaultProps. TypeScript should know that keys of the declared Props interface are allowed here. Or am I missing something why this shouldn't be the case?

@cheeZery Yes, please file a new issue as this is unrelated to the current issue.

use JSX.LibraryManagedAttributes<typeof MyComp, React.ComponentProps<typeof MyComp>> for Functional components as MyComp["props"] only works for class based components


Create multi-region concept diagrams

Some people (myself included) learn things faster from a diagram than reading paragraphs of text.  Or at least, they (I?) might need multiple paths to the learning that includes a visual.
So we should create some diagrams/visuals that are helpful for understanding the multi-region concepts.
Details TBD.

one idea is this choose your adventure workflow for table locality that I whipped up recently:

@awoods187 FYI since we chatted about diagrams recently


flutter add-to-app sample build error

I open the anroid_fullscreen project in add-to-app sample, at first the build failed with error log below:
FAILURE: Build failed with an exception.

* Where:
Settings file '/Users/will/Documents/dev/project/samples/experimental/add_to_app/android_fullscreen/settings.gradle' line: 4

* What went wrong:
A problem occurred evaluating settings 'AndroidFullScreen'.
> /Users/will/Documents/dev/project/samples/experimental/add_to_app/flutter_module/.android/include_flutter.groovy (/Users/will/Documents/dev/project/samples/experimental/add_to_app/flutter_module/.android/include_flutter.groovy)

then I add an import statement due to the hint
import javax.naming.Binding
this time the build failed with an different error:
FAILURE: Build failed with an exception.

* Where:
Settings file '/Users/will/Documents/dev/project/samples/experimental/add_to_app/android_fullscreen/settings.gradle' line: 5

* What went wrong:
A problem occurred evaluating settings 'AndroidFullScreen'.
> Could not find which method <init>() to invoke from this list:
    public javax.naming.Binding#<init>(java.lang.String, java.lang.String, java.lang.Object, boolean)
    public javax.naming.Binding#<init>(java.lang.String, java.lang.String, java.lang.Object)
    public javax.naming.Binding#<init>(java.lang.String, java.lang.Object, boolean)
    public javax.naming.Binding#<init>(java.lang.String, java.lang.Object)

Does anyone knows what's wrong?
below is the flutter doctor info:
[✓] Flutter (Channel master, v1.13.1-pre.99, on Mac OS X 10.15.1 19B2106, locale zh-Hans-CN)
• Flutter version 1.13.1-pre.99 at /Users/will/Documents/dev/flutter
• Framework revision 354f80b84a (15 hours ago), 2019-12-11 16:36:03 -0800
• Engine revision 12bf95fd49
• Dart version 2.7.0 (build 2.7.0-dev.2.1 8b8894648f)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
• Android SDK at /Users/will/Library/Android/sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-29, build-tools 29.0.2
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
• All Android licenses accepted.
[✓] Android Studio (version 3.5)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 42.0.1
• Dart plugin version 191.8593
• Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

umm we haven't see this one before. I can't repro locally. Perhaps @blasten may have some thoughts

I’m not sure why it was needed to add an import. It might help if you could share the steps to reproduce this issue starting from flutter create -t module. Which file did you modify?

Duplicate of https://github.com/flutter/flutter/issues/41350


create-payload-app not installing into existing Next.js app

Link to reproduction
No response
Payload Version
3.0 beta
Node Version
22.5.1
Next.js Version
14
Describe the Bug
npx create-payload-app@beta  is not being integrated into existing nextjs app
Reproduction Steps
tried to integrate payload 3.0 into an existing project, but it seems to always ask for project name to create new project
Adapters and Plugins
db-mongodb

Payload only supports specific Next.js 15 versions. Because you are on Next 14, it will not be able to install inside of it.
That being said, I will be adding a check to notify the user that this is the case.

I upgraded to 15.0.0-canary.53 and react to 19.0.0-rc-6230622a1a-20240610 but same thing
Get Outlook for iOShttps://aka.ms/o0ukef

From: Elliot DeNolf @.>
Sent: Tuesday, July 30, 2024 2:19:59 PM
To: payloadcms/payload @.>
Cc: Joseph Chukwudi Henry @.>; Author @.>
Subject: Re: [payloadcms/payload] create-payload-app not installing into existing Next.js app (Issue #7430)
Payload only supports specific Next.js 15 versions. Because you are on Next 14, it will not be able to install inside of it.
That being said, I will be adding a check to notify the user that this is the case.
—
Reply to this email directly, view it on GitHubhttps://github.com/payloadcms/payload/issues/7430#issuecomment-2258335048, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQQYSRZDTUFJRVYX5YGHP73ZO6HH7AVCNFSM6AAAAABLWA5DO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJYGMZTKMBUHA.
You are receiving this because you authored the thread.Message ID: @.***>

I've tested this by using the following commands, and it properly detects the Next app:
pnpm create next-app@canary --yes
cd <dir-name>
mkdir src/app/\(app\) && mv src/app/*.* src/app/\(app\)
pnpm create payload-app@beta

Alright thanks
Get Outlook for iOShttps://aka.ms/o0ukef

From: Elliot DeNolf @.>
Sent: Tuesday, July 30, 2024 2:31:30 PM
To: payloadcms/payload @.>
Cc: Joseph Chukwudi Henry @.>; Author @.>
Subject: Re: [payloadcms/payload] create-payload-app not installing into existing Next.js app (Issue #7430)
I've tested this by using the following commands, and it properly detects the Next app:
pnpm create @.*** --yes
cd
mkdir src/app/(app) && mv src/app/. src/app/(app)
pnpm create @.***
—
Reply to this email directly, view it on GitHubhttps://github.com/payloadcms/payload/issues/7430#issuecomment-2258360386, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQQYSR4PI4F4FSLGYOGZDODZO6ITFAVCNFSM6AAAAABLWA5DO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJYGM3DAMZYGY.
You are receiving this because you authored the thread.Message ID: @.***>

Closed by #7434


Ambassador can not refresh istio certs when workload certs get rotated

Scenario: Using ambassador(0.33.1) with mTLS enabled istio (0.8.0) pods
Docs followed
Description:
Istio rotates workload certs by default every 90 days or every x minutes as defined in citadel config. When this happens istio.default secret in each namespace gets refreshed with new workload certs.
Expected: Ambassador would detect this change and re-load itself/envoy to use new certs.
Observed: Ambassador keeps expired certs in memory and keeps on using them. This breaks down the communication with exception upstream error....
How to reproduce:
There can be many approaches as setting the TTL of workload certs to very low.
But we followed:

Change the root cert of istio  - Documentation followed
kubectl apply -f install/kubernetes/istio-citadel-plugin-certs.yaml
Delete istio.default secret in all namespaces
Ambassador could not re-load the changed certs and communication broke, until i deleted the ambassador pod.

p.s. Setting up istio and ambassador on minikube, we documented our approach:

Get git repo
2.Run  https://github.com/ajit-dev-ops/k8s-istio/blob/master/deploying-on-minikube/deploy-istio-0.8.0.sh
Run https://github.com/ajit-dev-ops/k8s-istio/blob/master/deploying-on-minikube/istio_demo_on_minikube-2.sh
Run https://github.com/ajit-dev-ops/k8s-istio/blob/master/istio-root-certs/gen_istio_certs.sh
Run https://github.com/ajit-dev-ops/k8s-istio/blob/master/istio-root-certs/create_secret.sh

Related/possible dup of #474

Fixed in 0.50.