chore: move templates to this repo

Describe your changes
Issue ticket number and link
Checklist before requesting a review

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] If it is a core feature, I have added thorough tests.

Codecov Report
Base: 70.30% // Head: 70.30% // No change to project coverage :thumbsup:

Coverage data is based on head (3990dda) compared to base (e738788).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           master      #62   +/-   ##
=======================================
  Coverage   70.30%   70.30%
=======================================
  Files          56       56
  Lines        2694     2694
=======================================
  Hits         1894     1894
  Misses        800      800

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.


test raftstore::test_tombstone::test_server_tombstone failed

thread 'raftstore::test_tombstone::test_server_tombstone' panicked at 'state: Tombstone region {id: 1 start_key: "" end_key: "" region_epoch {conf_ver: 3 version: 1} peers {id: 1 store_id: 1} peers {id: 2 store_id: 2} peers {id: 3 store_id: 3}} != state: Tombstone region {id: 1 start_key: "" end_key: "" region_epoch {conf_ver: 4 version: 1} peers {id: 1 store_id: 1} peers {id: 3 store_id: 3}}', tests/raftstore/test_tombstone.rs:91
test raftstore::test_transfer_leader::test_node_basic_transfer_leader ... ok
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: tikv::util::panic_hook::track_hook::{{closure}}
             at ./src/util/panic_hook.rs:61
   1: <std::thread::local::LocalKey<T>>::with
             at /checkout/src/libstd/thread/local.rs:253
   2: tikv::util::panic_hook::track_hook
             at ./src/util/panic_hook.rs:55
   3: core::ops::Fn::call
             at /checkout/src/libcore/ops.rs:2511
   4: std::panicking::rust_panic_with_hook
test raftstore::test_transfer_leader::test_server_pd_transfer_leader ... ok
             at /checkout/src/libstd/panicking.rs:550
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: tests::raftstore::test_tombstone::test_tombstone
             at ./tests/raftstore/test_tombstone.rs:91
   8: tests::raftstore::test_tombstone::test_server_tombstone
             at ./tests/raftstore/test_tombstone.rs:125
   9: <F as test::FnBox<T>>::call_box

It may be caused that the removed peer receives the GC message before applying ConfChange Remove command.

Another failed case https://internal.pingcap.net/idc-jenkins/blue/organizations/jenkins/tikv_ghpr_test/detail/tikv_ghpr_test/8471/pipeline/167

Given that the current Long Term Support (LTS) versions have resolved this issue, it is now considered outdated and can be safely closed.


Mechanisms for more useful usage text

I see two main areas to improve

Allow FieldParsers to be self-describing, so they can give hints as to the format in which they expect input.
Field-level annotations to add a wordier description.

I'd say (1) is highest priority, as it creates benefit for the general case; whereas (2) increases the complexity of the API and only helps in specific cases. Both should probably be possible though.

Actually did (2) first, via the Hint mechanism


Potential bug in tests.mk file

This PR aims to fix a potential bug in tests.mk file (#24909). This PR should be reviewed together with https://github.com/istio/test-infra/pull/2727. The default value of _INTEGRATION_TEST_SELECT_FLAGS is updated to be the env variable TEST_SELECT from here. If TEST_SELECT is not provided, such as post-submit tests integ-k8s-116, integ-k8s-117 and integ-k8s-119, the test select flags will be set to -postsubmit,-flaky,-multicluster
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[X] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

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

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

/ok-to-test

@ZhengzheYang: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/ok-to-test

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

/ok-to-test

/retest

I think this makes sense to me. BTW, the tests we are looking at are explicitly setting TEST_SELECT to -multicluster when they should probably just not set anything

Yes, it appears that only integ-k8s-116 sets the -multicluster flag. Should I create a PR to test-infra repo to get rid of this flag?

Yeah makes sense
On Mon, Jun 22, 2020, 5:47 PM Zhengzhe Yang<EMAIL_ADDRESS>wrote:

I think this makes sense to me. BTW, the tests we are looking at are
explicitly setting TEST_SELECT to -multicluster when they should probably
just not set anything
Yes, it appears that only integ-k8s-116 sets the -multicluster flag.
Should I create a PR to test-infra repo to get rid of this flag?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/24876#issuecomment-647840794, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXOTY7G6BVZ3UXF74JDRX73QRANCNFSM4OFD4MTA
.

I will create an issue and reference this PR.

@ZhengzheYang: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-tests_istio
67f03b0c0731d4de27f9f4fceadd0a82b69c02b2
link
/test integ-mixer-k8s-tests_istio

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

/retest

/cherrypick release-1.6

@jwendell: new pull request created: #25558

In response to this:

/cherrypick release-1.6

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


It doesn't seem to be working after installation

Hello!
First of all, thanks for this tool since it covers a gap which is critical for my organization :)
I have installed the tool in my sandbox environment and apparently everything went well. I managed to create a new rollup field and I set it up without errors. I even did the "manage child trigger" thing before activating it following your instructions. However it doesn't seem to work correctly.
This rollup field is intended to count the number of assets attached to an account.
I am attaching a screenshot of the field configuration and another screenshot of an account showing that even though there is 1 asset (assets have been renamed as "policies" in my org) attached to an account, the rollup field is empty.
Any ideas about what I am doing wrong?
Thanks!

If this is in your production environment did you remmber to deploy via the Change Set the Apex Trigger and Apex Test class associated with the child object? They start with dlrs

It was occurring in a sandbox environment. I have uninstalled and re-installed everything and now it works as a charm :D
I must have done something wrong the first time I did it.
Thanks for this excellent tool!

Your welcome! :+1:


run the example but failed

panic: reflect.Set: value of type *func(http.ResponseWriter, *http.Request) is not assignable to type func(http.ResponseWriter, *http.Request) [recovered]
panic: interface conversion: string is not error: missing method Error

Thanks for this found and I fixed it.
please pull latest code to test.


Envelope enhancements

Hi @nblumhardt,
PR that's intended to follow #81. I figured it would be okay to queue it up for when you get to it 😊
Feature enhancements:

Add Priority, with optional priority property mapping and default
CC, BCC, and ReplyTo added as optional envelope options with handlebars template
Added optional plain text alternate body template
Enhance email logging

Notes:

This will close #65 and pulls in the final (viable) thoughts from #77.
This is the last set of updates from the mega PR #78 that we broke into pieces.

Incorporates the merge of #86 with #81 while preserving the envelope enhancements from this PR, making this a full featured email application.

Hi @liammclennan and @nblumhardt,
As with #81, merging the changes from #93. This sustains the use of SmtpOptions.GetSocketOptions while retaining the added envelope functionality.
Cheers,
Matt

Updated dependencies

App comprising the enhancements from #81 and #83 is currently published to Nuget as https://www.nuget.org/packages/Seq.App.EmailPlus-Enhanced while this is pending review/merge.
This is working well in a production environment. More information on the features was published at https://mattmofdoom.com/seqappemailplus-enhanced-available/


When changing a building type, address fields are lost

При изменении типа здания пропадают адресные строки, надо заново открывать точку

Buildings don't have addresses in the first place. Related to #628: the editor should take into account an address field mentioned in a preset.

Done in 4.0.


fix: have ssl handshake check hostname

For Cloud SQL we need to disable checking hostname of ssl handshake because IP address does not match SAN. However, for AlloyDB this is not the case and the IP address can be validated as the host name.
Fixes #313

We need to hold off on this until PSC DNS is populated in all existing certificates.

Via @jackwotherspoon

"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client.  The hostname is represented as a byte
string using ASCII encoding without a trailing dot.

https://datatracker.ietf.org/doc/html/rfc6066#section-3

TLDR;
For wrap_socket and passing it to SSLContext, the trailing dot is invalid. However, the hostname match requires a perfect match to the DNS entry in the SAN which has the trailing dot. Thus, here we are, stuck with the hostname match failing.

Going to close this for now. We'll need to revisit some server settings I think.


Add the crds test suite to test CRD-based workflows

Is there a related GitHub Issue?
 #1566
What is this change about?
 This PR adds a new test suite that uses the kubernetes API to drive korifi (via kubectl). For now it only tests org creation.
Does this PR introduce a breaking change?
 No
Acceptance Steps
 Run the new tests locally against a kind cluster and verify that they pass
Tag your pair, your PM, and/or team
 @clintyoshimura @tcdowney

Have we considered using client-go? The CLI seems a bit clunky and is just a wrapper on top of client-go in the end, so maybe we could go with that and avoid dealing with stdin/stdout?

@gcapizzi The AMER team has been discussing these tests as a way to document workflows for users, which is part of why we chose to use the kubectl CLI directly. It lets us do things like call kubectl wait like a real user would, rather than use an Eventually to poll the CLI, for example. @tcdowney, is this what you had in mind?

@tcdowney, is this what you had in mind?

Yeah, I agree that it's a bit clunky, but I do believe that using kubectl is more representative of what users will actually be doing here (I've seen people like to store this configuration in git and apply it with tools like kubectl and kapp). My worry with client-go is that our tests may just end up reimplementing Korifi API logic in a way that's not realistic for end users.


New (faster and more efficient) implementation of the "sieve" exercise

It runs orders of magnitude faster than the previous implementation, specially with large numbers (i.e.: with a value of 100000, the old implementation took over 14 seconds, while this new one only takes 0.33 seconds).

This is great, thanks!


ONBOARDING.md

Create a onboarding docs
What to do next after joining?
Step by step instruction

follow twitter
sub YT
join discord
fork github
first pr
second pr
third pr

@piratelicorne

I'm on it

update in README
open links in new tab

Super fast response and awesome docs @piratelicorne 🥳


CI for Node

all passes

passed

Starts the game with a random player

Contains the compiled JavaScript

Contains the compiled JavaScript

Initializes with two players

tests


fix: enable stable config schema

🔗 Linked issue
https://github.com/nuxt/nuxt/issues/15592
❓ Type of change

[ ] 📖 Documentation (updates to the documentation or readme)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[x] ✨ New feature (a non-breaking change that adds functionality)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
Changes:

Enable schema without experimental flag to advocate using by module authors
Generate schema with nuxt prepare
Remove unnecessary markdown schema generation (integrations can still do the same!)
Always write .nuxt/schema directory to avoid confusion and removal
Extend AppConfig and AppConfigInput from internal _AppConfig to allow merging

📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Apologies for delay in reviewing properly. I'm planning to merge this in for v3.3 release (so ideally 1 Mar merge directly after patch release, then a week of testing on edge). Does that work for you @Atinux?

@danielroe I think we should start thinking of semver/patch release branches this way we have more time for edge testing not blocked by patches :)

If you need more time to test, we can release the changes in next patch as long as we preserve default flag value as false.

No i need to test the default behavior via edge channel on main branch :) Patch shouldn't be blocker will continue this on discord later today.

Disabled flag for now to land into edge/patch without being blocked.
Checking (more generic) non blocker edge testing next week 👍🏼


Uncaught Error: Assertion Failed  Error: Assertion Failed     at v (vscode-file://vscode-app//out/vs/base/worker/workerMain.js#editorWorkerService:13:8295)     at o.computeDiff (vscode-file://vscode-app//out/vs/base/worker/workerMain.js#editorWorkerService

Uncaught Error: Assertion Failed

Error: Assertion Failed
at v in src/vs/base/common/assert.ts:47:21
at o.computeDiff in out/vs/base/worker/workerMain.js:16:122418
at _.l in src/vs/editor/common/services/editorSimpleWorker.ts:421:32
at _.computeDiff in src/vs/editor/common/services/editorSimpleWorker.ts:412:29
at r.d in src/vs/base/common/worker/simpleWorker.ts:470:56
at Object.handleMessage in src/vs/base/common/worker/simpleWorker.ts:451:71
at M.k in src/vs/base/common/worker/simpleWorker.ts:204:32
at M.h in src/vs/base/common/worker/simpleWorker.ts:168:17
at M.handleMessage in src/vs/base/common/worker/simpleWorker.ts:160:8
at r.onmessage in src/vs/base/common/worker/simpleWorker.ts:457:18

Go to Errors Site

Not fixable without a repro.


Use spaces not working in Swift 2

Use spaces instead of tabs setting is not producing any changes in the comment block.
I'm on Xcode7 using swift2.

Any clue of what it may be?

@onevcat any ideas on this issue? I'm on XcodeVersion 7.1.1 (7B1005).
Thank you.

It is only used for align the parameters. If you try a method with multiple parameters, you may see the difference.


output contexts added to SessionReviewStep

Outdated: the generated code was already added in the PR for "is_prompt"


Parse uint64 to int64

Hmmm, I would argue that unsupported types should all return an error. MarshalBinary should be updated to return ([]byte, error).
Automatically converting types has caused a bunch of confusion with people using the library. If I'm reading this correctly, the reason you're adding uint64 here to begin with is that they're getting written as strings and that's messing people up.
Better to just have the list of types we support and throw errors for everything else.

@pauldix @sparrc  If we want to return an error for uint64, it needs to be higher up in point code than MarshalBinary I think.  The reason MarshalBinary does not return an error is that there is an invariant within the point struct that all fields it references are able to be marshaled.  Instead of making MarshalBinary return an error (which will ripple as a big change everywhere), I'd suggest making NewPoint and ParsePoint return an error instead so you can't create a point with an invalid field type.
From an end user's perspective, not handling uint64 is kind of annoying.  We cast the other uint types to a int64 so it's odd that we don't allow uint64 even though we can store values that are less than math.MaxInt64 without issue.  I think it would be better to allow uint64 and have the value overflow if you write something larger than math.MaxInt64.  Alternatively, allow uint64 but return an error on overflow.  With the latter, we'd have to make sure write endpoints don't start failing whole batches of writes because one point is invalid.

If the user is passing in a uint64 then they're working in a typed language. Otherwise they're trying to parse a value for which int64 would overflow. In this latter case, we should return an error on parse.
In the former, it makes sense to force them to use a type that we actually support. Thus they can make the explicit conversion from uint64 to int64 and deal with the consequences themselves.

@pauldix With that reasoning, then we should disallow all integer types other than int64 as well.  Just to frame this, this issue is only for the Go client.  Other languages would get an error parsing the line protocol because the value exceeds the int64 range.  We lose whatever type they stored when it's serialized to a string over the wire.
My main issue with the uint64 case is consistency.  Disallowing it makes it a special type that you have to handle as a one-off everywhere.  That is annoying as a go client end-user right now because you can add anything as a field since it's just an interface{}.

I'm fine with being explicit that the other uint types would return an error as well.  That would be consistent as a client API.

I think there are two issues here that need to be handled separately. First, parsing the line protocol. I think that if the value exceeds what can be represented as an int64 we should be throwing an error. I don't like the idea of silently overflowing the value. It's better for the user to get a response back that says there was an error.
The second issue is about the Go client and how it behaves. I see the point that it takes an interface, but the truth is that we really only support 4 underlying types. I would prefer to only support those and return an error if the type is anything other than those. That way we avoid doing automatic conversion or casting that may not be obvious to the user.
Let them determine how to manage types that we don't support.
We could refine the client so that a point has field values added to it and there's a different method for each type. e.g.
point.SetInt64Field(fieldName string, value int64)
point.SetFloat64Field(fieldName string, float64 int64)
point.SetBoolField(fieldName string, value bool)
point.SetStringField(fieldName string, value string)

Although I think that approach is kind of ugly, it would limit what people do with the Go client and make things much more clear.

Based on the benchmarks I saw, we could just reflect to detect the type and return an error if it wasn't a supported type with virtually no more overhead.  A few more benchmarks to test this theory would be good though.

@pauldix The line protocol parser returns and error for integer outside the int64 range currently so that case is already handled.
For go client, I'm good with returning an error for all unsupported field types and forcing users to make the conversion.  I think we can just validate the fields in NewPoint and return an error as opposed to adding settings though.  I'd rather we move towards a model where Points are immutable once created personally.

@jwilder sounds good +1

I still find it confusing that we support all primitive data-types except uint64, but should I close this PR?
In my opinion, rolling over the value is a behavior that is completely understandable, and I think anyone who is writing software will also understand. There is also the fact that you can query the value back and recast to uint64 to get the original (non-negative) value.
FWIW: MySQL and MongoDB also just roll-over uint64 types

@sparrc -- by rolling-over, I presume you mean the conversion to int64 (casting). "Rolling over" sounds like it is related to overflow.

@otoolep correct, casting to int64. I was saying "rolling over" because if uint64 is above the max int64 value, it will overflow to a negative int64

I believe we've decided not to do this


fast rtps run on the qnx

Hi guys:
I have compiled FAST-RTPS for QNX , The step can find at:
https://github.com/eProsima/Fast-RTPS/issues/new
But In one machine  which run on qnx system, I compiled a HelloWorld example to test FAST-RTPS.
The HelloWorld example  can be found at
https://github.com/eProsima/Fast-RTPS/tree/master/examples/C%2B%2B/HelloWorldExample
I did not change anything in the example code.
In one console I run
./HelloWorldExample  publisher
In another console I run
./HelloWorldExample Subscriber
But very sad. Nothing happened. They did not communicate with each other.
                    LISTEN
  tcp        0      0  <IP_ADDRESS>.ssh      <IP_ADDRESS>.45254    ESTABLISHED
 tcp        0      0  *.ssh                  *.*                    LISTEN
 tcp        0      0  *.8000                 *.*                    LISTEN
 tcp        0      0  *.telnet               *.*                    LISTEN
 tcp        0      0  *.ftp                  *.*                    LISTEN
 udp        0      0  *.*                    *.*
udp        0      0  *.65463                *.*
udp        0      0  *.7413                 *.*
udp        0      0  *.7412                 *.*
udp        0      0  *.7402                 *.*
udp        0      0  *.bootpc               *.*
Active Internet6 connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6       0      0  *.ssh                  *.*                    LISTEN`

netstat -g
` .   root# netstat -g
   Virtual Interface Table is empty

    Multicast Forwarding Cache is empty
    IPv6 Multicast Interface Table is empty
    IPv6 Multicast Routing Table is empt. `

please let me know if you need any more information.
address  : IN one machine
I really don't know how to solve the problem, any help is appreciated.
thanks all.

# uname -a
QNX I 7.0.0 2017/02/14-16:05:38EST R-Car_H3_rev_1.1 aarch64le

1st console:
# HelloWorldExample subscriber
...
Message HelloWorld 275 RECEIVED
Message HelloWorld 276 RECEIVED
Message HelloWorld 277 RECEIVED
Message HelloWorld 278 RECEIVED
Message HelloWorld 279 RECEIVED
Message HelloWorld 280 RECEIVED
Message HelloWorld 281 RECEIVED
Message HelloWorld 282 RECEIVED
Message HelloWorld 283 RECEIVED
Message HelloWorld 284 RECEIVED
Message HelloWorld 285 RECEIVED
Message HelloWorld 286 RECEIVED
Message HelloWorld 287 RECEIVED
Message HelloWorld 288 RECEIVED
Message HelloWorld 289 RECEIVED
Message HelloWorld 290 RECEIVED
Message HelloWorld 291 RECEIVED
Message HelloWorld 292 RECEIVED
Message HelloWorld 293 RECEIVED
Message HelloWorld 294 RECEIVED
Message HelloWorld 295 RECEIVED
Message HelloWorld 296 RECEIVED
Message HelloWorld 297 RECEIVED

2nd console:
# HelloWorldExample publisher
...
Message: HelloWorld with index: 271 SENT
Message: HelloWorld with index: 272 SENT
Message: HelloWorld with index: 273 SENT
Message: HelloWorld with index: 274 SENT
Message: HelloWorld with index: 275 SENT
Message: HelloWorld with index: 276 SENT
Message: HelloWorld with index: 277 SENT
Message: HelloWorld with index: 278 SENT
Message: HelloWorld with index: 279 SENT
Message: HelloWorld with index: 280 SENT
Message: HelloWorld with index: 281 SENT
Message: HelloWorld with index: 282 SENT
Message: HelloWorld with index: 283 SENT
Message: HelloWorld with index: 284 SENT
Message: HelloWorld with index: 285 SENT
Message: HelloWorld with index: 286 SENT
Message: HelloWorld with index: 287 SENT
Message: HelloWorld with index: 288 SENT
Message: HelloWorld with index: 289 SENT
Message: HelloWorld with index: 290 SENT
Message: HelloWorld with index: 291 SENT
Message: HelloWorld with index: 292 SENT
Message: HelloWorld with index: 293 SENT
Message: HelloWorld with index: 294 SENT
Message: HelloWorld with index: 295 SENT
Message: HelloWorld with index: 296 SENT
Message: HelloWorld with index: 297 SENT
...

Hi @darbee
Using the info provided on #272, I have created commit 85521132a53486688ec8430449f4b73c30aa361c to avoid the need of patching asio to enable multicast. That should solve the problem you are having on QNX.


npth: add musl regression test

Description of changes
Would have caught the issue fixed by 180b5c1c8c1a ("pkgsMusl.npth: backport patch to fix build").
I used pkgsCross instead of pkgsMusl so it does something useful on non-Linux.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Does it need to be in Staging, since it isn't triggering mass rebuilds?

Probably the changes it depends on is on staging, so that's fine.


Implemented Last Resort Translation With Gemini AI

Added  lastResort function in utils.
-Makes API call to Gemini w/prewritten prompt to translate a single term
-Harmful filter for negative content is set to NONE
-Sets output field to "No valid content found in the response from Gemini AI." if no response is gotten
Edited handleSearch function
-Imported lastResort
-Calls last resort only if the switch in TranslateSection is enabled and the database would report that no entry is found
TranslateSection/index
-changed variable isFeatureEnabled -> isLastResortEnabled for better clarity
*Don't forget to put Gemini API key in your .env

The API calls will definitely go to the backend. Good point about the static app, it does expose environment variables in the  generated code, so we have to avoid putting any secrets in the frontend.


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Abhijeet-Mali sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Type 'ViewController' does not conform to protocol

JTAppleCalendar Version: 7.1.5
Deployment Target: iOS 11.2
Error Message:
Type 'ViewController' does not conform to protocol. Do you want to add protocol stubs
Code:

remember, dont just take a look at the videos, they may be out of date.
On the main page there is an update. A new function called willDisplayCell is added.
You have to correctly implemented.
An explanation of why it was added and how to implement it is located here -> #553

closing issue.
But let me know if you youre still having trouble.


stacker clean with --storage-type=overlay may fail

In playing around with overlay and #115, I found an issue where I'm not able to 'clean'.
$ stacker --debug --storage-type=overlay --stacker-dir=/tmp/xx/test.d/stacker --oci-dir=/tmp/xx/test.d/oci --roots-dir=/tmp/xx/test.d/roots clean
stacker version v0.5.0-297-g3755182
using storage backend overlay
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go check-overlay]
problem cleaning roots couldn't clean rootfs dir: unlinkat /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64: permission denied
problem cleaning roots unlinkat /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64: permission denied
error: cleaning failed
main.doClean
    /home/smoser/src/stacker/cmd/clean.go:57
github.com/urfave/cli.HandleAction
    /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/app.go:524
github.com/urfave/cli.Command.Run
    /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/command.go:173
github.com/urfave/cli.(*App).Run
    /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/app.go:277
main.main
    /home/smoser/src/stacker/cmd/main.go:221
runtime.main
    /snap/go/6745/src/runtime/proc.go:204
runtime.goexit
    /snap/go/6745/src/runtime/asm_amd64.s:1374

$ ls -ld /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64
lrwxrwxrwx 1 smoser smoser 9 Nov  3 07:22 /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64 -> usr/lib64

$ ls -ld /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/usr/lib64
dr-xr-xr-x 24 smoser smoser 16384 Dec  4 09:37 /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/usr/lib64

I think this is also best fixed by #111. The underlying issue is that the overlay clean code doesn't run in a user namespace, so non-root owned files in the container can't be removed by the user stacker is running as by default.
We could make a usernsexec wrapper for this if it's really bothering people, but IMO fixing #111 is a better path forward since it will fix this and a lot of other related issues.
Here's a testcase that reproduces it:
diff --git a/test/clean.bats b/test/clean.bats
index 8f9dd2f..8399924 100644
--- a/test/clean.bats
+++ b/test/clean.bats
@@ -97,3 +97,17 @@ EOF
     [ ! -d roots ]
     [ ! -f .stacker/btrfs.loop ]
 }
+
+@test "clean of unpriv overlay works" {
+    require_storage overlay
+
+    cat > stacker.yaml <<EOF
+test:
+    from:
+        type: oci
+        url: $CENTOS_OCI
+EOF
+    sudo chown -R $SUDO_USER:$SUDO_USER .
+    unpriv_stacker build
+    unpriv_stacker clean
+}

I think this is also best fixed by #111. The underlying issue is that the overlay clean code doesn't run in a user namespace, so non-root owned files in the container can't be removed by the user stacker is running as by default.
We could make a usernsexec wrapper for this if it's really bothering people, but IMO fixing #111 is a better path forward since it will fix this and a lot of other related issues.
Here's a testcase that reproduces it:
diff --git a/test/clean.bats b/test/clean.bats
index 8f9dd2f..8399924 100644
--- a/test/clean.bats
+++ b/test/clean.bats
@@ -97,3 +97,17 @@ EOF
     [ ! -d roots ]
     [ ! -f .stacker/btrfs.loop ]
 }
+
+@test "clean of unpriv overlay works" {
+    require_storage overlay
+
+    cat > stacker.yaml <<EOF
+test:
+    from:
+        type: oci
+        url: $CENTOS_OCI
+EOF
+    sudo chown -R $SUDO_USER:$SUDO_USER .
+    unpriv_stacker build
+    unpriv_stacker clean
+}


util/metrics: collect threads state

Now ThreadsColletcor can monitor TiKV's threads state.

What's the difference between the old one and the new one? Can we know more information than before?

Oh forgive me. So.. in addition to thread cpu usage, we can collect thread state now?

@breeswish Yes, besides CPU usage, it collects threads state.

A friendly ping.

LGTM

A friendly ping.

/run-all-tests


Problem to use the draw component in some browsers as PWA app

Hello, we are developing a application for farmers evaluate their land and in the  map component we are using the leaflet map component to draw the plots location.
Our application is a PWA and runs the draw component perfectly in firefox.
However the draw map component in the google chrome, brave, opera doesn't work.
There any type of configuration to do? or it seems as a bug?
If you are interested in try:
1 - access the http://dapp.agryo.com
2 - install as a PWA app
3 - close the browser and enter by the pwa icon in the mobile.
Try in firefox and google crhome/brave/opera and others.

Hi, great to hear that you find Leaflet useful!
However, this issue tracker is used for reporting bugs and discussing new features. For questions on using Leaflet, please use gis.stackexchange.com or stackoverflow.
If you are really sure that this is a bug in leaflet, or a feature request, please change the wording to make it look like a bug report.


BUG: Formula on Address.Mailing Street Address is always inserting comma on end

The formula is currently:
npsp__MailingStreet__c + IF(ISNULL(npsp__MailingStreet2__c), '', ', ' + TRIM(npsp__MailingStreet2__c))
This is adding a comma to the end no matter what is in the Mailing Street 2 field. It should be:
npsp__MailingStreet__c + IF(ISBLANK(npsp__MailingStreet2__c), null, ', ' + TRIM(npsp__MailingStreet2__c))

Included in beta release version 3.39 (Beta 2) and higher

Included in production release version 3.39


New Connector - Drift Perpetual DEX

Description
Create perpetual DEX connector to Drift (Solana)
https://app.drift.trade/

use CEX perpetual template
use Solana Trader API from bloxroute https://docs.bloxroute.com/solana/trader-api-v2/api-endpoints/drift/perpatural-future
provide option to use subaccounts
handle PnL settlement
test coverage

The connector should be delivered as private fork.
Bounty

Sponsor: lazyquant
Bounty amount: 2400 USDT
Developer portion: 80% (2000 USDT)

Foundation team @cardosofede will check the exchange if compatible with hummingbot

I would like this take this if possible

hi @andrewlfc7 this bounty is not funded

This still open?

hi @xeroc this bounty is not funded (not Opened for devs)

hi @xeroc this bounty is not funded (not Opened for devs)

you mind updating the Opening post then. It says

Bounty

Sponsor: lazyquant
Bounty amount: 2400 USDT
Developer portion: 80% (2000 USDT)

Anyways. Is there any progress on the issue (maybe being made behind the scenes)?

@xeroc
lazyquant created it but not funded


Change GetK8sContext according to new API response change

Notes for Reviewers
This PR updates GetK8sContext func according to new changes made in connection API
This PR fixes #
Signed commits

[ ] Yes, I signed my commits.

// @Yashsharma1911


save_checkpoint fails with the most recent orbax release

Hello, flax team!
In past few days we observed a call to save_checkpoint failing with the most recent orbax release (0.5.17). When downgrading to orbax-checkpoint==0.5.16 everything works again.
The example to reproduce can be obtained from flax docs. For convenience it's copied below.
With orbax-checkpoint==0.5.17 this code fails with an exception. With orbax-checkpoint==0.5.16 it works.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): seen on both Ubuntu and Mac
Flax, jax, jaxlib versions (obtain with pip show flax jax jaxlib: flax 0.8.4, jax 0.4.30, jaxlib 0.4.30
Python version: 3.11

Logs, error messages, etc:
Traceback (most recent call last):
  File "/tmp/min_example.py", line 46, in <module>
    checkpoints.save_checkpoint(ckpt_dir='/tmp/flax_ckpt/flax-checkpointing',
  File "/tmp/.venv/lib/python3.11/site-packages/flax/training/checkpoints.py", line 697, in save_checkpoint
    orbax_checkpointer.save(
  File "/tmp/.venv/lib/python3.11/site-packages/orbax/checkpoint/checkpointer.py", line 165, in save
    tmpdir = utils.create_tmp_directory(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.venv/lib/python3.11/site-packages/orbax/checkpoint/path/step.py", line 607, in create_tmp_directory
    if multihost.is_primary_host(primary_host):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.venv/lib/python3.11/site-packages/orbax/checkpoint/multihost/utils.py", line 246, in is_primary_host
    if primary_host is None or primary_host == process_index():
                                               ^^^^^^^^^^^^^^^
  File "/tmp/.venv/lib/python3.11/site-packages/orbax/checkpoint/multihost/utils.py", line 252, in process_index
    if EXPERIMENTAL_ORBAX_USE_DISTRIBUTED_PROCESS_ID.value:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.venv/lib/python3.11/site-packages/absl/flags/_flagvalues.py", line 1426, in value
    val = getattr(self._flagvalues, self._name)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.venv/lib/python3.11/site-packages/absl/flags/_flagvalues.py", line 498, in __getattr__
    raise _exceptions.UnparsedFlagAccessError(
absl.flags._exceptions.UnparsedFlagAccessError: Trying to access flag --experimental_orbax_use_distributed_process_id before flags were parsed.

Steps to reproduce:
import os
from typing import Optional, Any
import shutil

import numpy as np
import jax
from jax import random, numpy as jnp

import flax
from flax import linen as nn
from flax.training import checkpoints, train_state
from flax import struct, serialization

import optax

ckpt_dir = '/tmp/flax_ckpt'

if os.path.exists(ckpt_dir):
    shutil.rmtree(ckpt_dir)  # Remove any existing checkpoints from the last notebook run.

key1, key2 = random.split(random.key(0))
x1 = random.normal(key1, (5,))      # A simple JAX array.
model = nn.Dense(features=3)
variables = model.init(key2, x1)

# Flax's TrainState is a pytree dataclass and is supported in checkpointing.
# Define your class with<EMAIL_ADDRESS>decorator to make it compatible.
tx = optax.sgd(learning_rate=0.001)      # An Optax SGD optimizer.
state = train_state.TrainState.create(
    apply_fn=model.apply,
    params=variables['params'],
    tx=tx)
# Perform a simple gradient update similar to the one during a normal training workflow.
state = state.apply_gradients(grads=jax.tree_util.tree_map(jnp.ones_like, state.params))

# Some arbitrary nested pytree with a dictionary and a NumPy array.
config = {'dimensions': np.array([5, 3])}

# Bundle everything together.
ckpt = {'model': state, 'config': config, 'data': [x1]}

# Import Flax Checkpoints.
from flax.training import checkpoints

checkpoints.save_checkpoint(ckpt_dir='/tmp/flax_ckpt/flax-checkpointing',
                            target=ckpt,
                            step=0,
                            overwrite=True,
                            keep=2)

They pushed some new releases today and it's 0.5.19 now - should fix this error.

thanks @IvyZX ! it's getting quite scary... it's 0.5.20 now! guess it's probably best to wait for the things to stabilise


Replace achiexplorer.com with achihub.com

Hi!  Achihub.com will be integrated in the next release.


Add/Fix multiple airplane images

Quite new to creating PRs so please let me know if I should change things moving forward. If images should be different please let me know as well!

@spencerm updated to latest commits to master. This shouldn't cause any issues to merge but if you could take a look I'd appreciate it!

@spencerm updated to latest commits to master. This shouldn't cause any issues to merge but if you could take a look I'd appreciate it!

Sorry for the delay!! And no I appreciate these PRs! Delay is I want to get it into my local and make sure they actually load. I might need to add one attribute to the Model definitions

@spencerm updated to latest commits to master. This shouldn't cause any issues to merge but if you could take a look I'd appreciate it!

Sorry for the delay!! And no I appreciate these PRs! Delay is I want to get it into my local and make sure they actually load. I might need to add one attribute to the Model definitions

No worries at all, not trying to hound or anything! Also just realized this branch had changes to the sql config that I meant to make to a local testing branch. I reverted those commits so this should just affect the airplane images again.

@Lash12 Merging this, but some of the images won't appear until the planes are updated (which I'll to later)


Upgrade our hamcrest dependencies from 1.3 to 2.2

Task Description
We need to upgrade our hamcrest dependencies from 1.3 to 2.2.
Tasks
The following tasks will need to be carried out:

[ ] Update the version in the strongbox-parent project.
[ ] Apply any required code changes, or dependency excludes.
[ ] Test and confirm that there are no issues with the core projects (strongbox, strongbox-web-integration-tests, etc) after upgrading.

Task Relationships
This task:

Relates to: #1852

Help

Check our article on how to upgrade dependencies and plugins.
Our chat
Points of contact:

@carlspring
@sbespalov
@steve-todorov

Hi @carlspring! Can I take this one?

Hi Pablo!
Yes, please!

Fixed by @ptirador in strongbox/strongbox-parent#87.


[AKS] az aks check-acr: Bump canipull to 0.0.4-alpha to skip location check if cname returns only privatelink

Description

skip location check if cname returns only privatelink
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

AKS


Friends and Groups

Is there a method to initiate an invite/friend request.  Is there a method to create a group feed where an invite set of users can share and interact with same feed?

Invites aren't supported but it can be modeled via feeds actually where business logic runs on your side and you use the feed as a data store.
If you explain your use case, I might be able to help better.

Invites aren't supported but it can be modeled via feeds actually where business logic runs on your side and you use the feed as a data store.
If you explain your use case, I might be able to help better.

Awesome.  Thanks for response and offer.  That's what I figured after I did a little more research.  I will definitely take you up on a recommendation shortly here.  I appreciate that.

Great, closing this to be clean. Feel free to open when you have more.


Apps catch daemon errors.

[x] Use an app without the Radicle daemon running
[x] Use an app with the Radicle daemon but not IFPS running
[x] Use an app without internet
[x] Use a non-exsiting machine ID
[x] Use a machine where the IPNS name resolves but the data cannot be reached
[x] What happens when a send does not receive an ack in time (might need to tweak daemon code to simulate)
[x] cloning a non existing project

@MeBrei

Only thing I noticed is that the messages for IPFS related errors are less descriptive ie are not hinting to any possible reason or ways to fix it.

The IPFS errors come directly from the IPFS daemon, but yeah I agree they can be a little cryptic. It's still better to keep them verbatim to improve googleability, but I agree we should add some hints as to how to resolve the issues as a next step.


Update mockito-scala-scalatest to 1.16.29

Updates org.mockito:mockito-scala-scalatest from 1.16.2 to 1.16.29.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (1.16.2).
You might want to review and update them manually.
build.sbt

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.mockito", artifactId = "mockito-scala-scalatest" } ]

labels: test-library-update, semver-patch, old-version-remains

Superseded by #2105.


SP Blacklist

retest this please

SonarQube analysis reported 17 issues

 9 blocker
 2 critical
 4 major
 2 info

Watch the comments in this conversation to review them.
10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 BlackListWhiteListDAO.java#L115: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L310: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L363: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L390: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L480: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L514: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L548: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L579: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L612: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListService.java#L151: Define and throw a dedicated exception instead of using a generic one.

SonarQube analysis reported 18 issues

 9 blocker
 3 critical
 4 major
 2 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 BlackListWhiteListDAO.java#L115: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L310: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L363: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L390: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L480: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L514: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L548: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L579: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L612: Use a variable binding mechanism to construct this query instead of concatenation.
 BlackListWhiteListDAO.java#L141: Define a constant instead of duplicating this literal " FROM " 4 times.


Invalidate worker cache on ACL update

This PR invalidates the worker cache when we update the ACL on the bus. While writing a test I realised we currently don't take the ACL into account when downloading. I think this was by design, but I propose to change this and extend the contract filter modes with a new download mode that only returns usable contracts.
Related to https://github.com/SiaFoundation/renterd/pull/1587

Closing this due to https://github.com/SiaFoundation/renterd/issues/1639 which is a change of plans for our overall caching strategy


carthage update

warning: 'AsyncSocket' is deprecated: The RunLoop versions of CocoaAsyncSocket are deprecated and will be removed in a future release. Please migrate to GCDAsyncSocket.

This has nothing to do with NEKit.


Improve memory cleanup functionality and document

Right now manual memory management with this lib is not straightforward, and not everything required is correctly exposed. Also, nothing is documented in the READMEs
This needs fixing!
todo:

add destroy() methods where appropriate
expose emscripten _free and destroy in @recast-navigation/core for more advanced use cases
add memory management information to READMEs

Progressed by: https://github.com/isaac-mason/recast-navigation-js/commit/273c456051a6a4ad7f0deb13d7c391842c552d47
Still requires documenting

Right now recast-navigation has some functionality for attempting to automatically free memory when c++ objects aren't correctly destroyed via FinalizationRegistry.
I'm not 100% convinced the feature is a good idea though. It should be removed at least for now.

https://github.com/isaac-mason/recast-navigation-js/commit/257e98842487b586428f3f0af5d97ac0cd17040c


improve performance

hi @sdcb
sorry for that I didn't noticed they have variety size in last PR.
I thought they already have the same size after padding and resize.
I looked into your implementation of  PaddleOcrRecognizer.
https://github.com/sdcb/OpenVINO.NET/blob/6b99f896651c5b7336a8ee33a7670cfcb6703f21/projects/PaddleOCR/Sdcb.OpenVINO.PaddleOCR/PaddleOcrRecognizer.cs#L129-L144
the input of model must have the same shape in one batch.
I think you have no doubt about this.
It should be like the image below after invoked the method PrepareAndStackImages.
four images stack

Am I right? Here's my question.
the implementation of PrepareAndStackImages invoked the method ResizePadding
why not the method of ResizePadding resize and pad image to maxWidth directly?
then we can invoke VConcat immediately.
https://github.com/sdcb/OpenVINO.NET/blob/6b99f896651c5b7336a8ee33a7670cfcb6703f21/projects/PaddleOCR/Sdcb.OpenVINO.PaddleOCR/PaddleOcrRecognizer.cs#L208-L239
according to what you mentioned in  last PR (#5) , I made this new PR ,
It fixs all problem, you can take a look.
I confirmed It keeps exactly the same OCR result compared with your commit (same input and same model).
meanwhile we also can get some improvement as shown below.

BenchmarkDotNet v0.13.10, Windows 10 (10.0.19044.3693/21H2/November2021Update)
  [Host]     : .NET 7.0.14 (7.0.1423.51910), X64 RyuJIT AVX2
  Job-PARHUX : .NET 7.0.14 (7.0.1423.51910), X64 RyuJIT AVX2
  Job-YLHAAW : .NET 8.0.0 (<IP_ADDRESS>103), X64 RyuJIT AVX2

IterationCount=10  LaunchCount=1  WarmupCount=1

Method
Runtime
modelHeight
maxWidth
Mean
Error
StdDev
Ratio
RatioSD
Allocated
Alloc Ratio

StackingVerticallyBySdcb
.NET 7.0
48
320
415.2 μs
15.14 μs
10.01 μs
1.00
0.00
1.93 KB
1.00

StackingVerticallyByAven
.NET 7.0
48
320
252.8 μs
8.97 μs
5.93 μs
0.61
0.02
1.79 KB
0.93

StackingVerticallyBySdcb
.NET 8.0
48
320
408.3 μs
11.43 μs
7.56 μs
1.00
0.00
1.93 KB
1.00

StackingVerticallyByAven
.NET 8.0
48
320
248.5 μs
12.37 μs
8.18 μs
0.61
0.02
1.79 KB
0.93

StackingVerticallyBySdcb
.NET 7.0
48
512
423.3 μs
18.53 μs
12.26 μs
1.00
0.00
1.54 KB
1.00

StackingVerticallyByAven
.NET 7.0
48
512
361.4 μs
14.72 μs
9.74 μs
0.85
0.04
1.62 KB
1.05

StackingVerticallyBySdcb
.NET 8.0
48
512
419.8 μs
14.95 μs
9.89 μs
1.00
0.00
1.54 KB
1.00

StackingVerticallyByAven
.NET 8.0
48
512
360.3 μs
14.88 μs
9.84 μs
0.86
0.03
1.62 KB
1.05

I agreed that we can use the method of ResizePadding resize and pad image to maxWidth directly in previous code, but I believe the StackingVertically method should keeps the same behavior of not constraint the input srcs width, which allows input srcs able to be different width.

hi @sdcb
All suggestions you mentioned are adopted.
please review.

@AvenSun Hi AvenSun, I created a branch and did some necessary work that I believe, can you merge my upstream https://github.com/sdcb/OpenVINO.NET/tree/mat-ext branch into your PR's branch? After that, I'll go ahead and merge the PR.

hi @sdcb
I just did what you said, you can have a try.

Thanks, merged.


Invite me to organization

I'm open source advocate and love to do open source contributions

Please see the community membership guidelines for information on becoming an org member.
/close


fix datepicker

Should solve the issue with the DateField throwing an exception when opened in docs.
Not sure exactly why it works, but I tried to build and serve the docs locally:
pnpm website-build
npx serve packages/website/build

and it seems to work fine.

Seems to work fine also in the deployed docs 🤷♂


Restructure documentation

Restructure documentation tree as per outline proposed on 13/9/22

@vikram-dagger is there a PR specific to the outline or should we just make comments on that getting started PR?
@jpadams has some updates on how to structure the extensions section.

Blocked by #3318


[HOLD for payment 2024-12-11] [$250]  mweb - Netsuite - Offline indicator is below the text in Auto-sync page

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.63-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause - Internal Team
Issue found when executing PR https://github.com/Expensify/App/pull/51949
Action Performed:
Precondition:

Workspace is connected to NetSuite

Go to staging.new.expensify.com
Go to workspace settings
Go to Accounting
Tap Advanced
Tap Auto-sync
Go offline

Expected Result:
Offline indicator will be at the bottom of the page
Actual Result:
Offline indicator is below the text instead of bottom of the page
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Standalone
[ ] Android: HybridApp
[x] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/ad25a3d1-bfe6-46ee-a207-7cf0d1963a25
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021857460821129435659
Upwork Job ID:<PHONE_NUMBER>129435659
Last Price Increase: 2024-11-15
Automatic offers:

rojiphil | Contributor | 104956911

Issue OwnerCurrent Issue Owner: @akinwale

Yeah doesn't look like a blocker to me.

@yuwenmemon Since this is a regression, the C+ who reviewed the initial PR can be assigned here as well, unless they're currently unavailable.

Since this is a regression, the C+ who reviewed the initial PR can be assigned here as well, unless they're currently unavailable.

Yeah! That makes sense. @yuwenmemon Please assign me here. Thanks.

@twilight2294 When can you raise a PR for this?

@yuwenmemon I think we can close this as we can consider this to be part of the implementation here

@rojiphil are you indicating payment doesn't need to be issued on this issue?

@OfstadC yeah. you can close this out


in post-game color blocked items differently

might need to add a little key or note somewhere

currently not in the data, requires a lookup for each word to see if the other player played it too


The error should be fixed by #28551 in the 17.2.0 release. NullInjectorError: No provider for InjectionToken CDK_TABLE!

          The error should be fixed by #28551 in the 17.2.0 release.

Originally posted by @crisbeto in https://github.com/angular/components/issues/28626#issuecomment-1959427524
i still get the same error

Angular CLI: 17.3.8
Node: 20.16.0
Package Manager: npm 10.8.1
OS: win32 x64
Angular: 17.3.12
... animations, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router
Package                         Version
@angular-devkit/architect       0.1703.8
@angular-devkit/build-angular   17.3.8
@angular-devkit/core            17.3.8
@angular-devkit/schematics      17.3.8
@angular/cdk                    17.3.10
@angular/cli                    17.3.8
@angular/google-maps            17.0.1
@schematics/angular             17.3.8
rxjs                            7.8.1
typescript                      5.4.5
zone.js                         0.14.10

ERROR NullInjectorError: R3InjectorError(_AppModule)[InjectionToken CDK_TABLE -> InjectionToken CDK_TABLE]:
NullInjectorError: No provider for InjectionToken CDK_TABLE!
at NullInjector.get (core.mjs:1654:27)
at R3Injector.get (core.mjs:3093:33)
at R3Injector.get (core.mjs:3093:33)
at ChainedInjector.get (core.mjs:15723:36)
at lookupTokenUsingModuleInjector (core.mjs:5730:39)
at getOrCreateInjectable (core.mjs:5778:12)
at ɵɵdirectiveInject (core.mjs:11050:19)
at ɵɵinject (core.mjs:1106:42)
at inject (core.mjs:1192:12)
at new _HeaderRowOutlet (table.mjs:1528:19)

and i upgrade anguale-cdk to     "@angular/cdk": "^17.3.0",
and get the same error

Duplicate of https://github.com/angular/components/issues/29704.


Padding script mode has bug

Bug
Description

Description of bug
When use -ps option, there is a error: IndentationError: unexpected indent.
I guess the codes about padding script need to think more case of different indent, especially complex and huge Python codes.
btw, ths for your project, better than pyminifer much.

I had very few error like this, sometimes is was be my setting indentation defined in my text editor, try to do defined indentation to space (in sublime text per example), and have you defined the indentation parameter like -ind 4 per example

hi, I find a case:
when codes exist swap line, like
v1 + v2  /
= v3

If option adds -ps, execute program will raise error:  IndentationError: unexpected indent

I will study this

I don't know this type of syntax in python :
v1 + v2  /
= v3

but I know :
v3 = v1  \
+ v3

Is this really the correct syntax that you notified above ?

I don't have IndentationError: unexpected indentation with these models, see my first msg in this issue, I close it


Do not import (scheme write) library in compiler

It's actually used for debug printing of values...


Update LFX project control center to match the community repo

There seem to be a lot of tools provided by LFX that we as a community are currently not using to their full potential. I'm mainly talking about the Security and Insights dashboards. To properly use these tools it seems like we need to use LFX Project Control Center to associate repositories with projects (maybe per working group or area): https://docs.linuxfoundation.org/lfx/project-control-center/tools/security/onboarding-projects-from-github#associating-individual-repositories-to-the-project
Another aspect that needs to be taken into account is providing access to the appropriate people. It seems like this is managed via the creation of committees: https://community.lfx.dev/t/set-up-project-committees-to-improve-coordination-reporting-and-meeting-management/128
As a first step we probably first want a TOC committee and maybe groups per working group area so that approvers can triage security scanning reports.

cc @cloudfoundry/toc

@rkoster I've followed up with the LF about getting Cloud Foundry's subprojects to correlate with working groups, which will enable Insights and LFX Security dashboard by working group.  I'm hoping to have this done before EOY, and will keep you posted here.

Hi @christopherclark,
do we have the LFX Insights and Security dashboards in place or the plans here changed? I saw that there a new version of the LFX dashboards available yet. If not applicable any more we can close this.

Still relevant and Chris will provide updates.

Update: I have been told this feature is ready and should roll out in December

The LFX projects boards could be find in https://insights.lfx.linuxfoundation.org/foundation/cloud-foundry/projects. Closing this for now.


TRPO code is not performing well compared to Other implementations

Pearlmutter method only gives "good" value of hessian vector product in the first two iterations in conjugate gradient loop

Some other implementation has much better performance half cheetah.
https://arxiv.org/pdf/1708.04133.pdf


Non-zero entries marked as dropouts

Hey guys, when I run scVI I get a lot of non-zero entries with probability of dropout > 0.5. This doesn't seem right. How can it be prevented? I did not find any protection against this in the code.

Hi @pedrofale,
There is a serious bug in the code. As I was tried reproducing the paper result with pytorch's implementation, I encountered that same issue. In https://github.com/YosefLab/scVI/blob/master/docs/notebooks/scVI-reproducibility.ipynb, Figure 13.b), Instead of ranging from 0.1 to 0.4, to zero probability from the negative binomial is in the 0.05 0.1 range, which is worrying.
Besides, something related with the uncertainties might be wrong as suggested by the DE plot in Figure 12, especially the null distribution which is very spiky.
I very recently realized there was no dropout in the decoder part of the scVI model in the tensorflow's implementation - in the standard default parameters, ie if n_layers = 1. (ref: https://github.com/romain-lopez/scVI-reproducibility/blob/2e6c3f9eec953ab0b7c24691911ad02a6010bd8a/scVI.py#L410)
This is now corrected, but there might still be a big difference in the model that I am not seeing. This only change that we made theorically was changing the fully connected ordering of the layers in the neural networks architecture, from:

Dropout, Dense, Batch Norm, Relu

To:

Dense, Batch Norm, Relu, Dropout

It might be something as big as that difference I hadn't spotted, or something related to the pytorch/tensorflow's different optimization/regularization schemes (AdamOptimizer, BatchNorm implementation, ect...)
I am actively looking into it, but if you are familiar with the previous tensorflow implementation and that you might have an idea on the origin of that problem, I would be glad to have your input ! 🙂
Meanwhile, there is still the reconstruction_loss='nb' parameter available in the model instanciation - though this is not a solution to that problem of course...

Good to know it’s not happening just to me. I actually ran the TensorFlow
implementation and the issue is still there. I don’t think it is due to the
optimization procedure.
Why not just add a line of code saying that if the (n,p) entry in the
observation matrix is non-zero, the dropout probability should be forced to
zero?
Eddie<EMAIL_ADDRESS>escreveu em sáb, 1/09/2018 às 00:27 :

Hi @pedrofale https://github.com/pedrofale,
There is a serious bug in the code. As I was tried reproducing the paper
result with pytorch's implementation, I encountered that same issue. In
https://github.com/YosefLab/scVI/blob/master/docs/notebooks/scVI-reproducibility.ipynb,
Figure 13.b), Instead of ranging from 0.1 to 0.4, to zero probability from
the negative binomial is in the 0.05 0.1 range, which is worrying.
Besides, something related with the uncertainties might be wrong as
suggested by the DE plot in Figure 12, especially the null distribution
which is very spiky.
I very recently realized there was no dropout in the decoder part of the
scVI model in the tensorflow's implementation - in the standard default
parameters, ie if n_layers = 1. (ref:
https://github.com/romain-lopez/scVI-reproducibility/blob/2e6c3f9eec953ab0b7c24691911ad02a6010bd8a/scVI.py#L410
)
This is now corrected, but there might still be a big difference in the
model that I am not seeing. This only change that we made theorically was
changing the fully connected ordering of the layers in the neural networks
architecture, from:

Dropout, Dense, Batch Norm, Relu

To:

Dense, Batch Norm, Relu, Dropout

It might be something as big as that difference I hadn't spotted, or
something related to the pytorch/tensorflow's different
optimization/regularization schemes (AdamOptimizer, BatchNorm
implementation, ect...)
I am actively looking into it, but if you are familiar with the previous
tensorflow implementation and that you might have an idea on the origin of
that problem, I would be glad to have your input ! 🙂
Meanwhile, there is still the reconstruction_loss='nb' parameter
available in the model instanciation - though this is not a solution to
that problem of course...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/YosefLab/scVI/issues/177#issuecomment-417813057, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AS-XVdBYkIAKFE_jMNWtSkqda5fi7DZ_ks5uWcZjgaJpZM4WV7AY
.

Ah that is interesting... thank you pointing out

Actually, we already optimize for the dropout to be zero in case of non zero entries.

I see. It makes me think of Figure 13 in the preprint where it is shown how the zero probability from the ZI is correlated with the qc metrics. Perhaps we should include this kind of information from the raw metadata in the decoding.

My thoughts exactly. Let me know if you end up changing something regarding
this problem.
Eddie<EMAIL_ADDRESS>escreveu em sáb, 1/09/2018 às 01:33 :

I see. It makes me think of Figure 13 in the preprint where it is shown
how the zero probability from the ZI is correlated with the qc metrics.
Perhaps we should include this kind of information from the raw metadata in
the decoding.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/YosefLab/scVI/issues/177#issuecomment-417819716, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AS-XVQwtM-bji4mxvtxy-dSFW3gEZJtqks5uWdXQgaJpZM4WV7AY
.

Pedro and Eddie, I'm not sure you're talking about the same issue.  Perhaps because "dropout" has two meanings, both related to scVI? As I understand it, Pedro is concerned about the number of biological dropout events that scVI detects (that is, where the observed gene expression level is zero but the real expression level isn't zero). I think Eddie is talking about a bug he just fixed, where we were applying dropout regularization to the wrong layer of our neural network. Is that right?
The bug Eddie fixed only affected our pytorch implementation (i.e. this repo). Pedro, you say the tensorflow code had the same issue? Why does the zero-inflation seem too high?
Thanks for reporting the issue!

Yes I am talking about biological dropouts. I do not know what the source
of the problem is, but when you fit the Tensorflow scVI model to the Zeisel
data for example and look at the posterior probability that a given entry
is dropout (i.e., Bernoulli probability > 0.5), there are non-zero entries
for which this probability is indeed > 0.5.
Jeffrey Regier<EMAIL_ADDRESS>escreveu em ter, 4/09/2018 às
23:11 :

Pedro and Eddie, I'm not sure you're talking about the same issue. Perhaps
because "dropout" has two meanings, both related to scVI? As I understand
it, Pedro is concerned about the number of biological dropout events that
scVI detects (that is, where the observed gene expression level is zero but
the real expression level isn't zero). I think Eddie is talking about a bug
he just fixed, where we were applying dropout regularization to the wrong
layer of our neural network. Is that right?
The bug Eddie fixed only affected our pytorch implementation (i.e. this
repo). Pedro, you say the tensorflow code had the same issue? Why does the
zero-inflation seem too high?
Thanks for reporting the issue!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/YosefLab/scVI/issues/177#issuecomment-418534591, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AS-XVTzBT9h4q7Kimzh_fXo-H6bQabcjks5uXvqPgaJpZM4WV7AY
.

That doesn't seem wrong to me, necessarily. I don't think that value can be interpreted as a posterior probability (or an approximate posterior probability). Is that what you're doing? I agree that if the observed expression level isn't zero, then, in the posterior, the probability of a biological dropout event having occurred is zero.

Yes that’s what I am doing. How do you suggest obtaining the posterior
probability of dropout then?
Jeffrey Regier<EMAIL_ADDRESS>escreveu em qua, 5/09/2018 às
01:54 :

That doesn't seem wrong to me, necessarily. I don't think that value can
be interpreted as a posterior probability (or an approximate posterior
probability). Is that what you're doing? I agree that if the observed
expression level isn't zero, then, in the posterior, the probability of a
biological dropout event having occurred is zero.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/YosefLab/scVI/issues/177#issuecomment-418563887, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AS-XVW8ZVgrn5c_fPD0POR-bVMS-EQaVks5uXyDVgaJpZM4WV7AY
.

We integrate h (the dropout event) out of the model analytically before performing variational inference. Our procedure approximates p(z, l | x), where z is the latent representation for a cell's biology (excludes batch effects) and l is the library size for a cell.
It's a bit tricky to approximate p(h | x). Is that the probability you want? That might require a different approximate inference procedure.

Yes I understand that. But while it is integrated out, the neural network
f_h that decodes from z to h is optimized, and its output is the dropout
probability, according to the manuscript. So after optimization, passing
the posterior z through f_h should give the posterior dropout probability
for each point. Right?
Jeffrey Regier<EMAIL_ADDRESS>escreveu no dia quarta, 5/09/2018
às 19:47:

We integrate h (the dropout event) out of the model analytically before
performing variational inference. Our procedure approximates p(z, l | x),
where z is the latent representation for a cell's biology (excludes batch
effects) and l is the library size for a cell.
It's a bit tricky to approximate p(h | x). Is that the probability you
want? That might require a different approximate inference procedure.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/YosefLab/scVI/issues/177#issuecomment-418839620, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AS-XVYGqpupP3aTlsN-vbT75WZbQUz-3ks5uYBxdgaJpZM4WV7AY
.

No, I don't think the procedure you describe approximates the posterior dropout probabilities p(h | x). The procedure you describe computes something that is more like the probability---if you could somehow observe that same cell twice--- that the gene would be a dropout the second time, conditioning on your first observation. We may need to revisit what we wrote about this topic in manuscript. It's a pretty subtle (and important) issue.

I see. What you say makes sense. But then the way the loss is computed kind
of contradicts that, because the dropout probability term used is exactly
the value obtained as I described.
Jeffrey Regier<EMAIL_ADDRESS>escreveu em qua, 5/09/2018 às
20:52 :

No, I don't think the procedure you describe approximates the posterior
dropout probabilities p(h | x). The procedure you describe computes
something that is more like the probability---if you could somehow observe
that same cell twice--- that the gene would be a dropout the second time,
conditioning on your first observation. We may need to revisit what we
wrote about this topic in manuscript. It's a pretty subtle (and important)
issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/YosefLab/scVI/issues/177#issuecomment-418859652, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AS-XVUN9S-8Oks8d3DQp0IcCvCqn4cohks5uYCtlgaJpZM4WV7AY
.

Which loss do you mean, when you say "the way loss is computed"? Not the loss that optimized at training time, right? Do you mean the loss in one of the tables/figures in the paper on biorxiv?

@romain-lopez Any idea what loss Pedro might be referring to? Let's close this issue if this isn't something we can fix or clarifying in manuscript.

Hi, what appear in the loss is a conditional probability p(x | z) for a fixed z and not a whole posterior distribution. Also,

The procedure you describe computes something that is more like the probability---if you could somehow observe that same cell twice--- that the gene would be a dropout the second time, conditioning on your first observation.

This looks accurate to me.


[ 🚧 WIP ] Ready for review

Why:

Closes #3104
What's being changed: I have added .py file in program folder which have a Python program to convert miles to inches.

@sushmita2109
Please link language-specific issue.
Thank you!

Issue: Write a Python program to convert centimeters to inches .
It's a python language code

done

@sushmita2109
Please remove calculate-miles-to-inches.py file in calculate-compound-interest folder

deleted


Lock the render() method, so it doesn't run multiple times at the same time

This is a fix for #28
However, I'm not convinced that this approach is the right one. Feedback is welcome.

Closing this PR in favor of #30


Different charts sizes?

Hi, Is it possible to use different chart sizes and colors for different charts based on class or data attribute or whatever?. The idea:
$('.chart').easyPieChart({
	size: 80
});

$('.chart.big').easyPieChart({
	size: 100
});

Subscribe

yes but you have to make sure the selectors are mutually exclusive.
In your case the first call
$('.chart').easyPieChart({
    size: 80
});

also creates charts for .chart.big.
This should work:
$('.chart.small').easyPieChart({
    size: 80
});

$('.chart.big').easyPieChart({
    size: 100
});

Oh right that makes sense, thanks


Bugfix/issue 724 post detail on site only

Description
Do not show a post on Site B if it is only published on Site A.
References
Fix #724
Checklist

[x] I have read the contribution guide
[x] Code lint checked via inv lint
[x] changes file included (see docs)
[x] Usage documentation added in case of new features
[ ] Tests added

@adrien-delhorme develop is now back in shape and pipeline is working good, could you please update this PR? thanks a lot

@adrien-delhorme we cherry-picked the relevant commit with #742 can you make a quick review of the new PR?

👍 Grazie mille @protoroto e @yakky !
I'm ok with the new PR.


Fix version file parsing

Fixes https://github.com/JuliaLang/BumpStdlibs.jl/issues/61 ?
Untested

Ok. It fails on nightly though, so the regex still needs work

No, the CI Julia version refers only to the Julia binary we run. The Julia source repo we use for CI (https://github.com/bcbi-test/julia) is the same for all CI jobs.

Instead of @assert (which may be disabled by default in the future), can you use conditionals?

I should probably document this better somewhere. Anyway, in production we have the upstream repository (https://github.com/JuliaLang/julia), but the bot user (DilumAluthgeBot) does not have commit permissions on the upstream, so it makes PRs from its fork (https://github.com/DilumAluthgeBot/julia).
In CI, we replicate this situation by having an "upstream" and a "fork" just for the purposes of CI.
The "CI upstream" (https://github.com/bcbi-test/julia) is not automatically kept in sync with the real upstream (https://github.com/JuliaLang/julia), but we should probably add a function at the beginning of the test suite that syncs the "CI upstream" with the "real upstream".

Row
CI or production
Upstream or fork
Owner
Repo

1
Production
Upstream
JuliaLang
JuliaLang/julia

2
Production
Fork
DilumAluthgeBot
DilumAluthgeBot/julia

3
CI
Upstream
bcbi-test
bcbi-test/julia

4
CI
Fork
bcbi-test-user
bcbi-test-user/julia

I was having some issues with CI on nightly. Can you comment out the "nightly" for now? We can uncomment in a separate PR.

Looks good - now let's make sure that all CI jobs pass.


[requirements] add Cython

On Tue, 03 Dec 2019 01:20:48 -0800
payno<EMAIL_ADDRESS>wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/silx-kit/silx/pull/2807
-- Commit Summary --

[requirements] add Cython

-- File Changes --
M requirements.txt (1)

what about the minimal version of Cython ?

nice catch, #2808 will fix it


Error on example/package.json

There is a line in example/package.json is incorrect, which will make folder node_modules/.2.18.0@webpack-hot-middleware/example nested recursively:"webpack-hot-middleware": "./.."。I use "*" instead of "./..", then npm install correctly

which version of node/npm produces this problem?
Although the example folder might be repeated inside the example's node_modules, this should only repeat once, not recursively.

I have found the reason. I live in China, for some political reasons, we don't have access to visit many foreign website, such as Youtube, Twitter and so on, unless use VPN. The speed of GitHub is slowly, too.
In order to get faster speed to visit Github and download packages, We use cnpm instead of npm, which is a mirror version of npmjs.org, provided by Alibaba company.
When I enter webpack-hot-middleware/example folder, i use cnpm install to download packages, that cause this problem, it made folder .2.18.0@webpack-hot-middleware nested recursively:
example/node_modules/.2.18.0@webpack-hot-middleware/example/node_modules/.2.18.0<EMAIL_ADDRESS>I turn to npm install, npm install all packages successfully.
Thanks a lot. webpack-hot-middleware is a awesome tool, improve my efficiency :)


Switch YuvToRgbConverter to take in ImageProxy

Change YuvToRgbConverter to take in an ImageProxy.
This allows us to remove the @SuppressLint("UnsafeExperimentalUsageError") annotation from bindCameraUseCases.
ImageProxy is returned by CameraX. Its documentation notes that it "has a similar interface as Image."

With this change, you are adding CameraX as a dependency for the utils library (without adding it to the gradle file, so the standalone library project won't build).
This also prevents developers from using the converter if they are using Camera2 instead of CameraX. Instead of this, you could simply call ImageProxy.getImage() (docs).

Calling ImageProxy.getImage() requires adding @SuppressLint("UnsafeExperimentalUsageError") to the function you do this in. See here.
CameraXTfLite is the only sample in this repository that uses this converter, and it already has CameraX as a dependency. Do you think it's worth having a version of the converter that doesn't use ImageProxy.getImage() so that CameraXTfLite (and other people who use the converter with CameraX) don't have to add @SuppressLint("UnsafeExperimentalUsageError")?

Calling ImageProxy.getImage() requires adding @SuppressLint("UnsafeExperimentalUsageError") to the function you do this in. See here.

That's just a lint annotation because CameraX marks the ImageProxy.getImage() method as experimental. Is the @SuppressLint declaration causing any issues for you?

CameraXTfLite is the only sample in this repository that uses this converter, and it already has CameraX as a dependency

The library should also include the appropriate dependencies regardless of what projects use it.

The @SuppressLint isn't causing issues. But it seems unnecessary when passing an ImageProxy would be an option. Doesn't CameraX mark ImageProxy.getImage() as experimental to discourage people from using it?
Would you be opposed to adding a CameraX dependency to the utils library? If so, what are your thoughts on making a separate version of the converter somewhere else that uses ImageProxy instead of Image?

Sorry for the late reply... I thought I had already replied to this, I guess I only did that in my head :-)

But it seems unnecessary when passing an ImageProxy would be an option. Doesn't CameraX mark ImageProxy.getImage() as experimental to discourage people from using it?

It's not intended as discouragement, it only indicates that the behavior or the API might change in a breaking way in the future. Currently, what we show is the recommended to go from ImageProxy to Image.

Would you be opposed to adding a CameraX dependency to the utils library? If so, what are your thoughts on making a separate version of the converter somewhere else that uses ImageProxy instead of Image?

At the moment, yes; because the utils library is being used by almost all samples and only 2 of them use CameraX. If you would like, I wouldn't be opposed to adding documentation saying "this could be changed to use ImageProxy instead" and even add a link to your commit!

No problem!

It's not intended as discouragement, it only indicates that the behavior or the API might change in a breaking way in the future.
Got it!

I was misunderstanding what the "Unsafe" in "UnsafeExperimentalUsageError" meant.

I wouldn't be opposed to adding documentation saying "this could be changed to use ImageProxy instead" and even add a link to your commit!

I have added comments saying this. Android studio highlights [Media.Image] as an error in the document string, so I changed this to [Image].

@rogerthat94 could you access https://github.com/android/camera-samples/discussions/399?

probably not a good idea to handle this PR this way after chatted internally. some more discussion in #399, thank you for the PR!


Unable to get int value using pq/postgres

We have a struct that has an int64 or uint values mapped to integer/bigint values in postgres.  We are getting back string, bigserial, etc. values properly but the bigint/integer values are always 0 in the returned data.  Is there something wrong in what we are doing?
Our code is similar to that show below:
type User struct {
Id        int64    gorm:"column:id"
OrgId  uint       sql:"column:orgid"
CreatedBy   int64     gorm:"column:createdby_id"
}
We then connect to gorm and use a call like this:
var users []User
r := db.Table("app_user").Find(&users)
if r.Error != nil {
fmt.Printf("Error getting app_user data: %+v\n", r.Error)
}
fmt.Printf("users: %+v\n", users)

Hi
Because int, int64 things would be initalized with value 0. so when save it, will insert the 0 into database. but you would change the type to things like, *uint , then it could return nil if no value found.
type User struct {
Id int64 gorm:"column:id"
OrgId *uint sql:"column:orgid"
}


Optimize release builds

Before/after:

I'm very hesitant about changing low level configurations like compiler options. The defaults are often chosen with a good reason, so I change such values only if they solve an actual issue, or if it's commonly agreed that the default values are just not optimal.
After a  quick research, I'm not convinced this is the case with the options in your PR. strip=true means stacktraces are much less useful when you run the program with RUST_BACKTRACE=full, codegen-units means compile times will be slower, even though the performance gains are not guaranteed. Not sure about opt-level and lto, but before I'm convinced that this has a noticeable impact, I'll stick with the defaults.

I'm very hesitant about changing low level configurations like compiler options. The defaults are often chosen with a good reason, so I change such values only if they solve an actual issue, or if it's commonly agreed that the default values are just not optimal.
After a quick research, I'm not convinced this is the case with the options in your PR. strip=true means stacktraces are much less useful when you run the program with RUST_BACKTRACE=full, codegen-units means compile times will be slower, even though the performance gains are not guaranteed. Not sure about opt-level and lto, but before I'm convinced that this has a noticeable impact, I'll stick with the defaults.

This isn't really meant to improve performance (although it likely does a little bit), it's mainly to reduce binary size
And wouldn't you be using a debug build when testing (so strip on the release build isn't a problem)?
I've gotten all of these flags from https://github.com/johnthagen/min-sized-rust, and this stuff isn't the compiler default because the Rust devs want compile time to be better by default for some reason (these aren't unstable options or anything)

@nroi pinging you in case my previous comment didnt send a notification or something (idk if it still sends notifications after the PR is closed)

This isn't really meant to improve performance (although it likely does a little bit), it's mainly to reduce binary size

Storage is cheap these days, so I don't see a big advantage of that. I understand that Arch users tend to strive for minimalism, so if it were possible to make the binary smaller without any drawbacks, that would be nice. But there are tradeoffs involved.

And wouldn't you be using a debug build when testing (so strip on the release build isn't a problem)?

Not necessarily. If you take a look at this file for example, this is used during testing, but I'm using the --release flag there. Those are integration tests, and I generally want integration tests to resemble the reality as close as possible, and the reality is that users compile flexo with --release.

and this stuff isn't the default because the Rust devs want compile time to be better by default for some reason

Yes, and I also want better compile times, because I recompile flexo frequently for the integration tests. Also, many users use the AUR package where they compile flexo, so they will also notice compile times.

A lot of software in rust uses these flags

I've also seen popular projects that don't use those flags, like ripgrep.
I appreciate it if people come up with suggestions to improve Flexo, and I completely understand why other maintainers choose to use those options. But binary size is just not a priority for me at the moment. I want to improve the maintainability and developer-friendliness of Flexo, and that requires decent compile times and meaningful stacktraces.

This isn't really meant to improve performance (although it likely does a little bit), it's mainly to reduce binary size

Storage is cheap these days, so I don't see a big advantage of that. I understand that Arch users tend to strive for minimalism, so if it were possible to make the binary smaller without any drawbacks, that would be nice. But there are tradeoffs involved.

And wouldn't you be using a debug build when testing (so strip on the release build isn't a problem)?

Not necessarily. If you take a look at this file for example, this is used during testing, but I'm using the --release flag there. Those are integration tests, and I generally want integration tests to resemble the reality as close as possible, and the reality is that users compile flexo with --release.

and this stuff isn't the default because the Rust devs want compile time to be better by default for some reason

Yes, and I also want better compile times, because I recompile flexo frequently for the integration tests. Also, many users use the AUR package where they compile flexo, so they will also notice compile times.

A lot of software in rust uses these flags

I've also seen popular projects that don't use those flags, like ripgrep.
I appreciate it that people come up with suggestions to improve Flexo, and I completely understand why other maintainers choose to use those options. But binary size is just not a priority for me at the moment. I want to improve the maintainability and developer-friendliness of Flexo, and that requires decent compile times and meaningful stacktraces.

The release profile should only be for release builds, if you need some optimization but not all on the devbuilds you can just make another profile called devbuild or something
We can just agree to disagree ig


[minor request] simplify function templates and enable CORS for local dev

Is your feature request related to a problem? Please describe.
2 problems:

users always run straight into CORS issues when they use our default templates. we could help them set CORS headers by default and leave a reminder to tighten it before shipping to prod
the current DynamoDB CRUD template has a A LOT going on https://github.com/aws-amplify/amplify-cli/blob/7b1f0f2c7bb67a9d154e8462643fb0fe35e88399/packages/amplify-nodejs-function-template-provider/resources/lambda/crud/app.js.ejs and is hard to use. recommend swapping for something simpler like this and pointing to our new guides.

Describe the solution you'd like
as above
Describe alternatives you've considered
do nothing

What changes need to be made (by hand) in the template right now, to enable CORS?


Angular 16 support

After installing the package with NG-16 and the --force tag the component can get imported, but is not loading the video.

Can you please share more details, like code snippet for usage or if there is an error fired in console?


Misc DQM Improvements

Closes #712 and other misc bugs.
Unfortunately does not address #714 (yet)

Codecov Report

Merging #716 into dqm will decrease coverage by 0.01%.
The diff coverage is 86.66%.

@@            Coverage Diff             @@
##              dqm     #716      +/-   ##
==========================================
- Coverage   91.87%   91.85%   -0.02%
==========================================
  Files          63       63
  Lines        4504     4545      +41
==========================================
+ Hits         4138     4175      +37
- Misses        366      370       +4

Impacted Files
Coverage Δ

dimod/discrete/discrete_quadratic_model.py
91.41% <86.66%> (-0.26%)
:arrow_down:

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 4942c33...3243c1d. Read the comment docs.


Add Install service section

This is required for systemctl enable, otherwise the service will not be started after a reboot.

0.1.1 as a bug fix?

Yes, maybe wait a bit before tagging in case there are other bugs.

Fair enough. Point to master as necessary at least from idr/deployment then.

Guess it's time to tag this... 0.1.1

Pushed


How can I create a whl file to be able to use this library directly in snowflake?

Describe the feature or improvement you're requesting
I tried creating a whl file out of the base folder extracted from the zip but I am unable to upload to snowflake as it says it's not a valid binary. Should I make the whl from a specific folder?
Additional context
No response

Hey, please feel free to post this on https://community.openai.com to get suggestions.


Unable to attach a debugger (missing mscordbi)

According to Single file deployment and executable documentation, attaching a debugger to the wacs process requires the mscordbi.dll to be present next to the executable. Could the correct version of mscordbi.dll/so be present in the release packages?

I'm eying an upgrade to .NET6 in the near future which might change some more stuff related to the single file bundle, I will consider including this. In the meantime the best way to debug is to download the source and build it yourself.

From now this .dll will be included as a seperate downloadable asset for each release, see  https://github.com/win-acme/win-acme/releases/tag/v<IP_ADDRESS>8 as an example