Egnn

Would you please move codes in src/layers/conv.jl to src/layers/groups.jl?

I am considering another design here. Maybe we can take two message-passing layers: one for node embedding, the other for coordinate embedding. From the paper equation (3)~(6), we can organize them into two message-passing layers:
For node embedding:

message function (3): $m_{ij} = \phi_e(h_i^l, h_j^l, ||x_i^l - x_j^l||^2, a_{ij})$
aggregate (5): $m_i = \sum_j m_{ij}$
update function (6): $h_i^{l+1} = \phi_h(h_i^l, m_i)$

For coordinate embedding (4):

message function: $y_{ij} = (x_i^l - x_j^l)\phi_x(m_{ij})$
aggregate: $y_i = \frac{1}{M-1} \sum_{j \ne i} y_{ij}$
update function: $x_i^{l+1} = x_i^l + y_i$

Thus, it form a nested message-passing layer.


panic: runtime error: index out of range

Hi
I'm trying to run the server example in order to just print the messages received on the port.
My intent is verify all messages sent by a software called M32Edit (from Behringer).
However my server application is crashing after I start my client application (the M32Edit).
I'm receiving the error: panic: runtime error: index out of range
Here is my code:
package main

import (
    "github.com/hypebeast/go-osc/osc"
    "fmt"
)
func main() {
  addr := "<IP_ADDRESS>:10023"
  fmt.Println("Starting server at:", addr)
  server := &osc.Server{Addr: addr}

  fmt.Println(server)

  /*
  server.Handle("/message/address", func(msg *osc.Message) {
    osc.PrintMessage(msg)
  })
  */

  server.ListenAndServe()
}

Here is the output:
Starting server at: <IP_ADDRESS>:10023
&{<IP_ADDRESS>:10023 <nil> 0s}
panic: runtime error: index out of range

goroutine 1 [running]:
github.com/hypebeast/go-osc/osc.readArguments(0xc0000c8030, 0xc0000cc000, 0xc00004bdb8, 0x8, 0x0)
	<suppressed>/Dropbox/sandbox/go/gocode/src/github.com/hypebeast/go-osc/osc/osc.go:719 +0x143d
github.com/hypebeast/go-osc/osc.readMessage(0xc0000cc000, 0xc00004bdb8, 0xc0000ce000, 0x1, 0x1000)
	<suppressed>/Dropbox/sandbox/go/gocode/src/github.com/hypebeast/go-osc/osc/osc.go:701 +0xd3
github.com/hypebeast/go-osc/osc.readPacket(0xc0000cc000, 0xc00004bdb8, 0x8, 0xc0000ce000, 0x1000, 0x1000, 0xc0000c8000)
	<suppressed>/Dropbox/sandbox/go/gocode/src/github.com/hypebeast/go-osc/osc/osc.go:628 +0x116
github.com/hypebeast/go-osc/osc.(*Server).readFromConnection(0xc00000c0c0, 0x56bd60, 0xc00000e038, 0x56ade0, 0xc000074630, 0x0, 0x0)
	<suppressed>/Dropbox/sandbox/go/gocode/src/github.com/hypebeast/go-osc/osc/osc.go:602 +0x230
github.com/hypebeast/go-osc/osc.(*Server).Serve(0xc00000c0c0, 0x56bd60, 0xc00000e038, 0xd, 0x56bd60)
	<suppressed>/Dropbox/sandbox/go/gocode/src/github.com/hypebeast/go-osc/osc/osc.go:559 +0x4a
github.com/hypebeast/go-osc/osc.(*Server).ListenAndServe(0xc00000c0c0, 0x1, 0x1)
	<suppressed>/Dropbox/sandbox/go/gocode/src/github.com/hypebeast/go-osc/osc/osc.go:551 +0xa0
main.main()
	<suppressed>/Dropbox/sandbox/go/gocode/src/osc_server/main.go:27 +0x121
exit status 2

I believe this is an issue with the library.
Can you please help me to solve this issue?

 if typetags[0] != ',' { is being run where typetags is an empty string - this produces the index out of range error. This is a bug in the library, and additional checks should be added.

 if typetags[0] != ',' { is being run where typetags is an empty string - this produces the index out of range error. This is a bug in the library, and additional checks should be added.

In the current code, it does a length check on typetags before it tries to check its values.
	if len(typetags) == 0 {
		return nil
	}

@cioban, is this still an issue with the current version of the library?


Tagged union type declarations

Is your feature request related to a problem? Please describe.
When declaring an object parameter, a template author may wish to accept a strict enumeration of object shapes that are not necessarily mutually compatible. This is most likely to come up in conjunction with #9229, as resource types within the az namespace frequently use discriminated object types.
Describe the solution you'd like
There should be a simple way to declare a custom tagged union within a template. Following TypeScript's example, this might look something like:
type snap = {
  type: 'snap'
  value: string
}

type crackle = {
  type: 'crackle'
  value: int
}

type pop = {
  type: 'pop'
  value: bool
}

type cereal = snap | crackle | pop

The above approach requires the compiler to detect that the union can be collapsed to a tagged union of objects, as other union types that would be permitted in TypeScript (e.g., string | int) are not permitted in the ARM runtime. This syntax might strike users not accustomed to TypeScript as verbose since the tag name needs to be repeated in each union member.
Another possible syntax would borrow from Rust's enums:
@discriminator('type')
type cereal = {
  snap { value: string }
  crackle { value: int }
  pop { value: bool }
}

The distinction between an enum with three members and an object with three properties might be a bit subtle (both for users and for the compiler), as it's only communicated here via the lack of colon (:) tokens following each tag value.
There will also need to be a way to express such a constraint in the compiled JSON template.

Alternative syntax proposal from @WhitWaldo in #9369:

What I'd really like to have is something like the following similar to what I previously requested in my interfaces request, but modified to reflect the current custom types styling. I suggest borrowing TypeScript's 'extends' keyword to allow a type to inherit all the properties of another type as well as abstract to indicate that instance cannot be created of the abstract type itself, but one can only use those types that inherit from it.

abstract type partitionScheme = { //Note the use of abstract here because we don't want any values simply passing in a plain > partitionScheme
 partitionScheme: string
}

type namedPartitionScheme extends partitionScheme = { //Note the use of TypeScript's 'extends' keyword
 partitionScheme: 'Named' //I can set constants today, but here it would be required per its existence in partitionScheme
 names: string[]
}

type singletonPartitionScheme extends partitionScheme = {
 partitionScheme: 'Singleton'
}

type uniformInt64RangedPartitionScheme extends partitionScheme = {
 partitionScheme: 'UniformInt64Range'
 count: int
 low: -9223372036854775808
 high:<PHONE_NUMBER>854775807
}

type serviceFabricService = {
 name: string
 properties: {
   partitionDescription: partitionScheme //Allowing anything that implements partitionScheme to be set here, absent partitionScheme itself because of the abstract keyword
 }
}

Just wanted to add some strawman syntax variations for comparison. To give a more complete example, each snippet describes the shape of the CertificateProperties shape from Microsoft.AppPlatform@2022-12-01.
Unions via inheritance
Based on the proposal in #9369
abstract type CertificateProperties = {
  type: string
  activateDate: string
  dnsNames: string[]
  expirationDate: string
  issuedDate: string
  issuer: string
  provisioningState: 'Creating' | 'Deleting' | 'Failed' | 'Succeeded' | 'Updating'
  subjectName: string
  thumbprint: string
}

type ContentCertificateProperties extends CertificateProperties = {
  type: 'ContentCertificate'
  content: string
}

type KeyVaultCertificateProperties extends CertificateProperties = {
  type: 'KeyVaultCertificate'
  certVersion: string
  excludePrivateKey: bool
  keyVaultCertName: string
  vaultUri: string
}

TypeScript-style discriminated unions
type ContentCertificateProperties = {
  type: 'ContentCertificate'
  activateDate: string
  dnsNames: string[]
  expirationDate: string
  issuedDate: string
  issuer: string
  provisioningState: 'Creating' | 'Deleting' | 'Failed' | 'Succeeded' | 'Updating'
  subjectName: string
  thumbprint: string
  content: string
}

type KeyVaultCertificateProperties = {
  type: 'KeyVaultCertificate'
  activateDate: string
  dnsNames: string[]
  expirationDate: string
  issuedDate: string
  issuer: string
  provisioningState: 'Creating' | 'Deleting' | 'Failed' | 'Succeeded' | 'Updating'
  subjectName: string
  thumbprint: string
  certVersion: string
  excludePrivateKey: bool
  keyVaultCertName: string
  vaultUri: string
}

type CertificateProperties = ContentCertificateProperties | KeyVaultCertificateProperties;

TypeScript-style discriminated union (but with structural inheritance via &)
type CertificatePropertiesSharedProps = {
  activateDate: string
  dnsNames: string[]
  expirationDate: string
  issuedDate: string
  issuer: string
  provisioningState: 'Creating' | 'Deleting' | 'Failed' | 'Succeeded' | 'Updating'
  subjectName: string
  thumbprint: string
}

type ContentCertificateProperties = CertificatePropertiesSharedProps & {
  type: 'ContentCertificate'
  content: string
}

type KeyVaultCertificateProperties = CertificatePropertiesSharedProps & {
  type: 'KeyVaultCertificate'
  certVersion: string
  excludePrivateKey: bool
  keyVaultCertName: string
  vaultUri: string
}

type CertificateProperties = ContentCertificateProperties | KeyVaultCertificateProperties;

Inspired by Rust enums
type CertificateProperties = {
  activateDate: string
  dnsNames: string[]
  expirationDate: string
  issuedDate: string
  issuer: string
  provisioningState: 'Creating' | 'Deleting' | 'Failed' | 'Succeeded' | 'Updating'
  subjectName: string
  thumbprint: string

  discriminator type: {
    ContentCertificate: {
      content: string
    }

    KeyVaultCertificate: {
      certVersion: string
      excludePrivateKey: bool
      keyVaultCertName: string
      vaultUri: string
    }
  }
}

This feature still needs be reenabled. It is temporarily disabled while backend features wait to go out to support it.


Perf optimization: Eliminate allocations from cache-hit case.

Outline a nested function that was being allocated as a closure.
Convert a get! + do-closure to a get() with MISS default value, to prevent the side-effect is_first_task variable from being Boxed.

Before:
julia> using MultiThreadedCaches, BenchmarkTools

julia> c = MultiThreadedCache{Int,UInt64}()
MultiThreadedCache{Int64, UInt64}(Dict{Int64, UInt64}())

julia> init_cache!(c)
MultiThreadedCache{Int64, UInt64}(Dict{Int64, UInt64}())

julia> foo(c,x) = get!(c, x) do
           UInt64(2)
       end
foo (generic function with 1 method)

julia> @btime foo($c, $10)
  88.013 ns (1 allocation: 16 bytes)
0x0000000000000002

After:
julia> @btime foo($c, $10)
  75.891 ns (0 allocations: 0 bytes)
0x0000000000000002

Before:
julia> using MultiThreadedCaches, BenchmarkTools

julia> c = MultiThreadedCache{Int,UInt64}()
MultiThreadedCache{Int64, UInt64}(Dict{Int64, UInt64}())

julia> init_cache!(c)
MultiThreadedCache{Int64, UInt64}(Dict{Int64, UInt64}())

julia> foo(c,x) = get!(c, x) do
           UInt64(2)
       end
foo (generic function with 1 method)

julia> @btime foo($c, $10)
  183.950 ns (1 allocation: 16 bytes)
0x0000000000000002

After:
julia> @btime foo($c, $10)
  168.394 ns (0 allocations: 0 bytes)
0x0000000000000002

Thanks both!


Add : A*search algorithm

Hello, @Kumar-laxmi , I as going through the repo and was unable to find A* search algorithm which is famous in game theory and robotics for path finding. Could you please allow me to do so!
I am contributor under SSOC'23
Thank You!

refer #787

Okayy!


(Fix) remove background color and center icons from Tabs component

Closed #86

Travis automatic deployment:
https://pr87--safereactcomponents.review.gnosisdev.com

Travis automatic deployment:
https://pr87--safereactcomponents.review.gnosisdev.com

there's a border-bottom prop, that must be removed:

hmm... now that I see the requirements, it seems to be required. But I'm not sure if the width is correct (@alongoni, thoughts?)

there's a border-bottom prop, that must be removed:

hmm... now that I see the requirements, it seems to be required. But I'm not sure if the width is correct (@alongoni, thoughts?)

Travis automatic deployment:
https://pr87--safereactcomponents.review.gnosisdev.com

Travis automatic deployment:
https://pr87--safereactcomponents.review.gnosisdev.com


Add 503 status code to maintenance template

Q
A

Bug fix?
no

New feature?
no

BC breaks?
no

Deprecations?
no

Fixed tickets

Related issues/PRs

License
MIT

Documentation PR

What's in this PR?
It sets the 503 status code in the maintenance template.
Why?
A maintenance page should be from status cod 503.
To Do

[x] added changelog

This seems easy enough of a change. Should we merge this? Could you squash your commits?

sorry didnt see the comment did rebase the branch!


Freezes and blacklist not working

Emacs freeze for a couple of seconds a second after the cursor stops moving. The problem goes away when disabling intero. I have version ;; Package-Version: 20180806.2145.
I don't intend to use intero for this project at all, but I'm unable to blacklist it. I've tried
  (setq intero-blacklist '("/home/simendsjo/code/haskell/base/" "/home/simendsjo/code/haskell/ghc" "~/code/haskell/ghc")) ;; yes, I've tried both with and without ~
  (add-hook 'haskell-mode-hook 'intero-mode-blacklist) ;; seems this is deprecated
  (intero-global-mode) ;; but using this instead doesn't seem to work either

Not sure if these issues are related, but I haven't noticed freezes like this for projects where intero works.

I cannot see any intero-mode in the hooks, but then again, I'm an emacs newbie and using spacemacs which might have magic I'm unable to locate.
haskell-mode-hook’s value is (spacemacs//init-jump-handlers-haskell-mode)
From the init-jump-handlers-haskell-mode function:
(setq haskell-modes '(haskell-mode literate-haskell-mode))

Could it be this line in my config: (setq haskell-completion-backend 'intero)?
I see this in the spacemacs haskell setup:
(when (configuration-layer/package-usedp 'company)
    (pcase haskell-completion-backend
      (`ghci (spacemacs-haskell//setup-ghci))
      (`ghc-mod (spacemacs-haskell//setup-ghc-mod))
      (`intero (spacemacs-haskell//setup-intero)))))

And the setup-intero function:
(defun spacemacs-haskell//setup-intero ()
  (add-to-list 'company-backends-haskell-mode
               '(company-intero company-dabbrev-code company-yasnippet))
  (push 'intero-goto-definition spacemacs-jump-handlers)
  (intero-mode)
  (dolist (mode haskell-modes)
    (spacemacs/set-leader-keys-for-major-mode mode
      "hi" 'intero-info
      "ht" 'intero-type-at
      "hT" 'haskell-intero/insert-type
      "rs" 'intero-apply-suggestions
      "sb" 'intero-repl-load))

Notice the (intero-mode) line here. I found that removing (setq haskell-completion-backend 'intero) from my config seems to work, but on the other hand, it seems strang that (intero-mode) doesn't honor intero-blacklist.


Fix #1475 (--global installs to ~/.local)

:information_source: Does not fix https://github.com/pypa/pipx/issues/1443 (pipx install --global order broken), which is a completely different problem with the --global flag.

[x] I have added a news fragment under changelog.d/ (if the patch affects the end users)

Summary of changes

[x] Changed setup/initialization order of pipx.paths and pipx.shared_libs to correctly account for the global flag.
[x] Added PIPX_GLOBAL_[HOME|BIN_DIR|MAN_DIR] the output of pipx environment.
[x] Extended and updated documentation related to --global.

Test plan
Tested by running
$ docker run -it --rm python:3 bash
$$ pip install git+https://github.com/viscruocco/pipx.git@fix-global-path-handling
$$ pipx install --global cowsay
$$ which cowsay
/usr/local/bin/cowsay
$$ ls /opt/pipx/
py  shared  venvs
$$ ls ~/.local/state/pipx/
log       # --> pipx logs are still in ~/.local
$$ ls ~/.local/
state     # --> nothing else from pipx is in ~/.local

Moved to https://github.com/pypa/pipx/pull/1476


bazel test is not working in the command prompt

I am  unable to find the "rasterize_triangles_kernel.so file in my folder and also bazel test is not working unable to proceed further can you please  check and let me know.

Hi, could you post the error message of bazel test here?

INFO: Build completed, 2 tests FAILED, 3 total actions
//mesh_renderer/kernels:rasterize_triangles_impl_test           (cached) PASSED in 0.4s
//mesh_renderer:mesh_renderer_test                                       FAILED in 2.3s
/home/preksh/.cache/bazel/_bazel_preksh/887e388b830f4415bdb0c32c0787f49a/execroot/tf_mesh_renderer/bazel-out/k8-fastbuild/testlogs/mesh_renderer/mesh_renderer_test/test.log
//mesh_renderer:rasterize_triangles_test                                 FAILED in 2.6s
/home/preksh/.cache/bazel/_bazel_preksh/887e388b830f4415bdb0c32c0787f49a/execroot/tf_mesh_renderer/bazel-out/k8-fastbuild/testlogs/mesh_renderer/rasterize_triangles_test/test.log
Executed 2 out of 3 tests: 1 test passes and 2 fail locally.
INFO: Build completed, 2 tests FAILED, 3 total actions

If you pass the first test (kernels:rasterize_triangles_impl_test), the library should be able to use.  Similar to #117.

 You can find rasterize_triangles_kernel.so following the instruction of our repository and run the demo code as well as the training code.
The following two failed tests seem to cause by incompatibility between different versions of tf_mesh_renderer.


feat: 🎸 use mempool nonce when creating a mock-cdd claim

JIRA Link
N/A
Changelog / Description
Use mempool nonce when calling mock-cdd.
Should allow for concurrent cdd creation and reduce the chance of getting the too low priority error.
Checklist -

[ ] New Feature ?
[ ] Updated swagger annotation (if API structure is changed) ?
[ ] Unit Test (if possible) ?
[ ] Updated the Readme.md (if required) ?

Reference: https://polkadot.js.org/docs/api/cookbook/tx/#how-do-i-take-the-pending-tx-pool-into-account-in-my-nonce

:tada: This PR is included in version 2.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


feat: enable typed linting feature of typescript-eslint

Summary

This PR enables the strictTypeChecked and stylisticTypeChecked configurations and rulesets for the typescript-eslint package to use.
It also fixes all of the new errors identified by the typed linting configs.
All non-src/ unit test files are now centralized in the __tests__/ directory to work around typescript-eslint errors, and this __tests__/ folder is in the tsconfig.json includes array now as well.

:tada: This PR is included in version 1.8.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Feature request: add --cleanup option to brew cask install

Description of feature/enhancement
The feature consist in adding a --cleanup parameter to brew cask install, which will remove all temporary assets like downloads, once a package is successfully installed or upgraded.
This will mirrors the same --cleanup option from vanilla Homebrew.
This feature seems to depends on the completion of #23398 (ex-#21763).
Justification
This feature helps to keep a system clean and tidy without regular call to the broader brew cask cleanup command.
Example use case
Here is an example from vanilla Homebrew:
$ brew upgrade --cleanup
==> Upgrading 1 outdated package, with result:
node 6.3.0
==> Upgrading node
==> Downloading https://homebrew.bintray.com/bottles/node-6.3.0.el_capitan.bottle.tar.gz
Already downloaded: /Users/kdeldycke/Library/Caches/Homebrew/node-6.3.0.el_capitan.bottle.tar.gz
==> Pouring node-6.3.0.el_capitan.bottle.tar.gz
==> Caveats
Please note by default only English locale support is provided. If you need
full locale support you should either rebuild with full icu:
  `brew reinstall node --with-full-icu`
or add full icu data at runtime following:
  https://github.com/nodejs/node/wiki/Intl#using-and-customizing-the-small-icu-build

Bash completion has been installed to:
  /usr/local/etc/bash_completion.d
==> Summary
🍺  /usr/local/Cellar/node/6.3.0: 3,829 files, 39.8M
Removing: /usr/local/Cellar/node/6.2.2... (3,771 files, 38.7M)

Has this been successfully integrated?


#1436: [Documentation] Add a flask error handler complete example

Fixes # 1436
Changes proposed in this pull request:

Add a small flask error handle example in the docs/exceptions.rst

done!


[FEAT]: Ownership Functionality - How the entities can login?

1. Field Mapping in Ownership Attributes:

In the field mapping section, users must select one or more checkboxes from the options: userId, email, mobile number, and password.
Upon selecting checkboxes, a corresponding multiselect dropdown will be enabled, containing all the mandatory fields of the entity.
Users can choose from the dropdown to map fields to the selected checkboxes.
This will be stored in the "ownershipAttributes" object within the schema, facilitating ownership mapping.
"ownershipAttributes": [     {                                                                                "email": "/email",                                                                                "mobile": "/contact",                                                                               "userId": "/contact"                                                                                "password": "/password"                                                                            }   ]

2. Authorizations for Issuance:

Within the "Who Can Authorize for Issuance ?" section, users can select authorization roles by choosing specific roles through radio buttons , either as "Anonymous" or  "Roles".
A multiselect dropdown will be available to select roles from entities within the schema.
Additionally, users can create new roles by inputting a role name below the dropdown. These new roles will be added to the roles dropdown.
The selected roles will have the authority for certificate issuance, and this role information will be stored in the "roles" object of the schema.
Example - "roles" : ["teacher"]

3. Authorization to Invite Roles:

Similarly, within the "Who Is Authorized to Invite Roles ?" section, the same functionality as described above will apply.
Users can select roles, both predefined and newly created, through a multiselect dropdown and input field.
The roles authorized to invite other roles will be stored in the "inviteRoles" object in the schema.
Example - "inviteRoles" : ["anonymous"]
"inviteRoles" : ["teacher"]

@holashchand Please check and confirm the ownership workflow.

@suvarnakale
For ownership attributes no field is multi select, all are single select. Just they can have multiple such configuration as many as they want, since this is of kind list.
Other thing is one of mobile/email fields is mandatory, and password field is optional


interop: add equality helpers

Close #2249.

How about updating our examples to use it? onNEPXX checks for token hash, from/to checks in Transfer, oracle callback --- all of them can benefit from the helper already.

    --- FAIL: TestCompileExamples/nft-d (0.30s)
panic: interface conversion: ast.Expr is *ast.CallExpr, not *ast.Ident [recovered]
	panic: interface conversion: ast.Expr is *ast.CallExpr, not *ast.Ident

Hmm.

That's if !runtime.GetCallingScriptHash().Equals(gas.Hash). runtime.GetCallingScriptHash() is obviously not an identificator.

That's if !runtime.GetCallingScriptHash().Equals(gas.Hash). runtime.GetCallingScriptHash() is obviously not an identifier.

Fixed by creating identifier firstly. Should we create an issue to solve this in the compiler?

https://github.com/nspcc-dev/neo-go/issues/2592.


Log parser sessions

Ah know the conflict that is occurring here. Will need to remove some files via command line to fix.


Alpine Legs failing to build CoreCLR

The Alpine legs are failing due to issues building runtime's CoreCLR component. There are many errors for this component, but most of them are related to null values and null pointers. Below are two examples of errors that appeared in the build:

error: value of type 'std::nullptr_t' is not implicitly convertible to 'UINT_PTR' (aka 'unsigned long')
error: cannot initialize a member subobject of type 'COUNT_T' (aka 'unsigned int') with an rvalue of type 'std::nullptr_t'

I believe that https://github.com/dotnet/runtime/pull/98336 may have introduced these errors.
Link to failing build (internal Microsoft link)

cc @khushal1996 - pinging since I believe you originally opened the PR linked into the issue. Let me know if I should ping someone else.

@ellahathaway How did you determine that https://github.com/dotnet/runtime/pull/97529 might be at fault?
This seems very likely related to https://github.com/dotnet/runtime/pull/98336 -- @jkoritzinsky

Ah you're right. The commit hash pulled from the VMR build doesn't even include https://github.com/dotnet/runtime/pull/97529 in the log history yet (hadn't been synced to the VMR as of that build).
I had looked through the git history of the files and saw that https://github.com/dotnet/runtime/pull/98336 was merged two days ago, so I assumed that this would've gone into the VMR yesterday given that runtime syncs to sdk every day which syncs to installer every day. I've updated the issue comment to reflect the correct PR.

Ill take a look. I'm amazed this is only causing failures in the VMR. Don't know why that would be.

Looks like it's failing due to Clang 17 introducing more strict checking for nullptr->integer conversions in compile-time-constant scenarios. I was hoping to avoid having to handle this now (and instead rewriting the infrastructure that hits this) but it should be fixable without too much trouble.


ENH: coordinate descent minimizer

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like.
Add coordinate descent as a method for minimization
Describe alternatives you've considered.
I can write a quick version with minimize_scalar though it won't be up to the coding standard, and that function should have a starting point.
Additional context (e.g. screenshots, GIFs)
No response

A few thoughts:
First, we do have support for the Powell method for the minimize() function. From the docs:

Method Powell is a modification of Powell’s method [3], [4] which is a conjugate direction method. It performs sequential one-dimensional minimizations along each vector of the directions set (direc field in options and info), which is updated at each iteration of the main minimization loop. The function need not be differentiable, and no derivatives are taken. If bounds are not provided, then an unbounded line search will be used. If bounds are provided and the initial guess is within the bounds, then every function evaluation throughout the minimization procedure will be within the bounds. If bounds are provided, the initial guess is outside the bounds, and direc is full rank (default has full rank), then some function evaluations during the first iteration may be outside the bounds, but every function evaluation after the first iteration will be within the bounds. If direc is not full rank, then some parameters may not be optimized and the solution is not guaranteed to be within the bounds.

That sounds pretty close to what you'd want - the optimization process cycles through each coordinate, optimizing each one in succession.
Second, I'm not sure what you mean by this:

I can write a quick version with minimize_scalar though it won't be up to the coding standard, and that function should have a starting point.

Specifically, if we're optimizing a scalar function, then there is only one coordinate to choose from, so it's not clear what it would mean to only optimize one coordinate at a time. Can you clarify this point?
Third, I think it would be good for you to talk in more detail about how SciPy's users would benefit from using this algorithm. What benefits would someone gain in using this algorithm versus using, e.g. BFGS? Can you give examples of problems where coordinate descent solves the problem in less time than our existing optimizers, for example?

My understanding was Powell's method uses direction vectors, and when direc is not specified it'll use basis vectors (not well documented) as the first search direction.
I found out using minimize_scalar isn't appropriate because it doesn't have a starting point to specify. What I meant is that minimize function with a starting point can be applied each coordinate. Here is a quick-and-dirty version to demonstrate the idea:
def coordinate_descent(f, x0, rounds=1000):
    x = x0
    def f_coord(x_i):
        x[i] = x_i[0]  # x and i from outer scope, can also use *args
        return f(x)

    for r in range(rounds):
        for i in range(len(x0)):
            x[i] = minimize(f_coord, x[i]).x[0]

        print(x, f(x))

    return x

Coordinate descent is a useful baseline for comparing optimization methods.
If you want a concrete example, strangely coordinate descent works for https://projecteuler.net/problem=897 (maximizing n-gon area between y=1 and y=x^4) with an explicit formula for each coordinate when its partial derivative set to 0, meaning you explicitly tell it an update rule x_i := somefunc(x[i-1],x[i],x[i+1]), while other methods fail without 2nd order Hessian info. I'm not sure this counts as optimization any more since it's more like an iterative relaxation method?


Ability to pass callable as logLevel to Middleware::log()

Hi!
Sometimes we want to choice different levels for different Requests/Response pair.
Especially for different response status codes.
This PR brings an ability to pass callable as logLevel param of Middleware::log().

I'll assess why the PHPStan task failed... It works fine locally with the same version of PHPStan.

Thanks for the PR, but I think we should leave this out of the core.


No such image

Step 18/20 : RUN crontab /root/crons.conf
---> Running in 295af4b1ed3d
---> 604fa3023129
Removing intermediate container 295af4b1ed3d
Step 19/20 : EXPOSE 80
---> Running in 733fef6c0637
---> 33ce8a2efb79
Removing intermediate container 733fef6c0637
Step 20/20 : ENTRYPOINT /usr/local/bin/init.sh
---> Running in 7ce6628aa212
---> 0b19f1da8aa6
Removing intermediate container 7ce6628aa212
Successfully built 0b19f1da8aa6
WARNING: Image for service sugarcrm was built because it did not already exist.
To rebuild this image you must use docker-compose build or docker-compose up --build.
Starting dockersugarcrm_db_1
Recreating dockersugarcrm_sugarcrm_1
ERROR: for sugarcrm  No such image: sha256:b1a7dd2dec63136d1c638103b181575d6d3b2
f31ff1cd238548d882329532b16
ERROR: Encountered errors while bringing up the project.

I tried to do docker-compose build and docker-compose up --build but still doesn't work.
dockersugarcrm_db_1 is up-to-date
Recreating 74fd97527816_74fd97527816_74fd97527816_dockersugarcrm_sugarcrm_1

ERROR: for sugarcrm  No such image: sha256:b1a7dd2dec63136d1c638103b181575d6d3b2
f31ff1cd238548d882329532b16
ERROR: Encountered errors while bringing up the project.


Using ID scalars type converting error

when i using scalar type of ID ,and my kotlin argument type is Int or Long
I found a type mismatching exception in DataFetcherInvoker
I know scalar ID, as Int or String
is that right?

These are treated as String types, not Int or Long.

Thank you for answer.


Useframe causes error:=Unrecoverable HMR error in =

First of all, really well made plugin and docs!
I am experiencing issues with the useFrame hook. Error:
[HMR][Svelte] Unrecoverable HMR error in <Three>: next update will trigger a full reload
I got this when trying to make my mesh rotate. Howver, I found that a function like this gives the same error:
    useFrame(() => {
      console.log('frame')
    })

In case it's useful, here's my complete component:
<script>
  import { SphereGeometry, MeshStandardMaterial } from 'three'
  import {
    AmbientLight,
    Canvas,
    Mesh,
    PerspectiveCamera,
    PointLight,
    useTexture,
    useFrame,
  } from 'threlte'

  const geometry = new SphereGeometry(1, 32, 32)
  let rotation = {
    x: 0,
    y: 0,
    z: 0,
  }

  const textures = useTexture({
    map: '/assets/img/maps/colorMap.jpg',
    normalMap: '/assets/img/maps/NormalMap.jpg',
    roughnessMap: '/assets/img/maps/RougnessMap.jpg',
    displacementMap: '/assets/img/maps/DisplacementMap.jpg',
  })
  const material = new MeshStandardMaterial({ ...textures })
  material.displacementScale = 0.02

  useFrame(() => {
    console.log('frame')
  })
</script>

<div class="w-1/2 aspect-1">
  <Canvas>
    <PerspectiveCamera position={{ x: 0, y: 0, z: 2.4 }}>
      <!-- <OrbitControls autoRotate /> -->
    </PerspectiveCamera>

    <PointLight position={{ x: 50, y: 40, z: 50 }} intensity={0.5} />
    <AmbientLight color={0x0d1321} />

    <Mesh {geometry} {material} {rotation} />
  </Canvas>
</div>

Hi @silveltman,
The docs definitely need to be more clear about this, but here's the relevant part: There are hooks that rely on the context provided by the <Canvas> component, see the docs for details. All hooks that do so are marked with a box that says so.
Hope that helps!

If you look at the code of a lot (all?) examples, you see there's a Wrapper.svelte component that is just wrapping the whole scene and its logic so that you don't need to worry about context.

Also, any wya to support hot module replacement (HRM)?

HMR should work out of the box, at least it does so for regular SvelteKit.

That did the trick, thanks!
Also fixed my color issue https://github.com/grischaerbe/threlte/issues/75#issuecomment-1175564163


Installation of Dragonfly2 service components dragonfly-client, 	dragonfly-seed-client health check failed

dragonfly-client, dragonfly-seed-client  issue  :   Liveness probe failed: timeout: failed to connect service "unix:///var/run/dragonfly/dfdaemon.sock" within 1s

Kubernetes : v1.28.15
OS: debian12
Containerd： 1.6.20

Kubernetes : v1.28.15
OS: debian12
Containerd： 1.6.20

@caisheng821 Can you provide the log of kubectl describe po dragonfly-seed-client and kubectl logs dragonfly-seed-client.

kubectl describe po    dragonfly-seed-client-0 -n dragonfly-system
Name:             dragonfly-seed-client-0
Namespace:        dragonfly-system
Priority:         0
Service Account:  default
Node:             cdsf/<IP_ADDRESS>
Start Time:       Mon, 25 Nov 2024 11:51:01 +0800
Labels:           app=dragonfly
apps.kubernetes.io/pod-index=0
component=seed-client
controller-revision-hash=dragonfly-seed-client-85c644b4f9
release=dragonfly
statefulset.kubernetes.io/pod-name=dragonfly-seed-client-0
Annotations:      checksum/config: 140c96bc815d67ab002f38b32efa512dd48948518016d079fbe0329d252efdd8
Status:           Running
IP:               <IP_ADDRESS>
IPs:
IP:           <IP_ADDRESS>
Controlled By:  StatefulSet/dragonfly-seed-client
Init Containers:
wait-for-manager:
Container ID:  containerd://4d9680d81f9e89e11a33b6b0ee1583132ec4305d297772cf868b154be71ea3ce
Image:         busybox:latest
Image ID:      busybox@sha256:c121a8a6392cffd1288512fb51bf828dffb7969d6ee5f63ae56937bacb5dc7ce
Port:
Host Port:
Command:
sh
-c
until nslookup dragonfly-manager.dragonfly-system.svc.cluster.local && nc -vz dragonfly-manager.dragonfly-system.svc.cluster.local 8080; do echo waiting for manager; sleep 2; done;
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Mon, 25 Nov 2024 11:51:02 +0800
Finished:     Mon, 25 Nov 2024 11:51:02 +0800
Ready:          True
Restart Count:  0
Limits:
cpu:     2
memory:  4Gi
Requests:
cpu:        0
memory:     0
Environment:
Mounts:
Containers:
seed-client:
Container ID:  containerd://36923af718dd34e1e0721450786f0085a6b5449d308954f1d16ab53022451df1
Image:         dragonflyoss/client:latest
Image ID:      dragonflyoss/client@sha256:6571b0b1d206237bfec7eca6e9177c72a3d362b77e1a338dad816dbbe672e02b
Ports:         4000/TCP, 4001/TCP, 4003/TCP, 4002/TCP, 4004/TCP
Host Ports:    0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
Args:
--log-level=info
--verbose
State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       Error
Exit Code:    137
Started:      Thu, 28 Nov 2024 09:24:52 +0800
Finished:     Thu, 28 Nov 2024 09:26:52 +0800
Ready:          False
Restart Count:  936
Limits:
cpu:     2
memory:  4Gi
Requests:
cpu:        0
memory:     0
Liveness:     exec [/bin/grpc_health_probe -addr=unix:///var/run/dragonfly/dfdaemon.sock] delay=15s timeout=5s period=30s #success=1 #failure=3
Readiness:    exec [/bin/grpc_health_probe -addr=unix:///var/run/dragonfly/dfdaemon.sock] delay=5s timeout=5s period=30s #success=1 #failure=3
Environment:
Mounts:
/etc/dragonfly from config (rw)
/var/lib/dragonfly/ from storage (rw)
/var/log/dragonfly/dfdaemon/ from logs (rw)
Conditions:
Type              Status
Initialized       True
Ready             False
ContainersReady   False
PodScheduled      True
Volumes:
storage:
Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName:  storage-dragonfly-seed-client-0
ReadOnly:   false
config:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      dragonfly-seed-client
Optional:  false
logs:
Type:        EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
QoS Class:       Burstable
Node-Selectors:
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type     Reason     Age                        From     Message

Warning  Unhealthy  12m (x2803 over 2d21h)     kubelet  Liveness probe failed: timeout: failed to connect service "unix:///var/run/dragonfly/dfdaemon.sock" within 1s
Warning  BackOff    7m12s (x11584 over 2d21h)  kubelet  Back-off restarting failed container seed-client in pod dragonfly-seed-client-0_dragonfly-system(a6b881a8-b34a-449a-bb7f-0c876694ff24)
Warning  Unhealthy  2m22s (x6434 over 2d21h)   kubelet  Readiness probe failed: timeout: failed to connect service "unix:///var/run/dragonfly/dfdaemon.sock" within 1s

kubectl describe po  dragonfly-client-lgx66 -n dragonfly-system
Name:             dragonfly-client-lgx66
Namespace:        dragonfly-system
Priority:         0
Service Account:  default
Node:             cdsf/<IP_ADDRESS>
Start Time:       Mon, 25 Nov 2024 11:27:19 +0800
Labels:           app=dragonfly
component=client
controller-revision-hash=896f66885
pod-template-generation=5
release=dragonfly
Annotations:      cattle.io/timestamp: 2024-11-25T03:01:32Z
checksum/config: d0d38701744b259ae47121c4a0429cda1090e7b581094aa168709256f8bbc838
Status:           Running
IP:               <IP_ADDRESS>
IPs:
IP:           <IP_ADDRESS>
Controlled By:  DaemonSet/dragonfly-client
Init Containers:
wait-for-scheduler:
Container ID:  containerd://13e22d8b5a3f211be8de2f73e44007d3231f62095d1d84bdb521c6520c74ad5e
Image:         busybox:latest
Image ID:      busybox@sha256:c121a8a6392cffd1288512fb51bf828dffb7969d6ee5f63ae56937bacb5dc7ce
Port:
Host Port:
Command:
sh
-c
until nslookup dragonfly-scheduler.dragonfly-system.svc.cluster.local && nc -vz dragonfly-scheduler.dragonfly-system.svc.cluster.local 8002; do echo waiting for scheduler; sleep 2; done;
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Mon, 25 Nov 2024 11:27:19 +0800
Finished:     Mon, 25 Nov 2024 11:27:19 +0800
Ready:          True
Restart Count:  0
Environment:
Mounts:
dfinit:
Container ID:  containerd://3997ea845d16a93c79849e3261e2e10c30ace898b379415f84278af9008d4ac7
Image:         dragonflyoss/dfinit:latest
Image ID:      dragonflyoss/dfinit@sha256:0f63c8458db216412471a24449be4f994b9d3bd0fb4f67f95e60923a1bde9bf8
Port:
Host Port:
Args:
--log-level=info
--verbose
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Mon, 25 Nov 2024 11:38:01 +0800
Finished:     Mon, 25 Nov 2024 11:38:01 +0800
Ready:          True
Restart Count:  7
Limits:
cpu:     2
memory:  4Gi
Requests:
cpu:        0
memory:     0
Environment:
Mounts:
/etc/containerd from containerd-config-dir (rw)
/etc/dragonfly from dfinit-config (rw)
restart-container-runtime:
Container ID:  containerd://c9f3415a53a0a8a3b0703aad2b755ce4ca74afb2ba1e22ecb5d4b48e4821512b
Image:         busybox:latest
Image ID:      busybox@sha256:c121a8a6392cffd1288512fb51bf828dffb7969d6ee5f63ae56937bacb5dc7ce
Port:
Host Port:
Command:
/bin/sh
-cx
nsenter -t 1 -m -- systemctl restart containerd.service
echo "restart container"
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Mon, 25 Nov 2024 11:38:02 +0800
Finished:     Mon, 25 Nov 2024 11:38:02 +0800
Ready:          True
Restart Count:  0
Limits:
cpu:     2
memory:  4Gi
Requests:
cpu:        0
memory:     0
Environment:
Mounts:
Containers:
client:
Container ID:  containerd://4b603f7d5c4c5499925c09b93480e29b9f1489fcc402fa394d22c8497fd18ed2
Image:         dragonflyoss/client:latest
Image ID:      dragonflyoss/client@sha256:6571b0b1d206237bfec7eca6e9177c72a3d362b77e1a338dad816dbbe672e02b
Ports:         4000/TCP, 4003/TCP, 4002/TCP, 4004/TCP
Host Ports:    4000/TCP, 4003/TCP, 4002/TCP, 4004/TCP
Args:
--log-level=info
--verbose
State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       Error
Exit Code:    137
Started:      Thu, 28 Nov 2024 09:27:10 +0800
Finished:     Thu, 28 Nov 2024 09:29:10 +0800
Ready:          False
Restart Count:  941
Limits:
cpu:     2
memory:  4Gi
Requests:
cpu:        0
memory:     0
Liveness:     exec [/bin/grpc_health_probe -addr=unix:///var/run/dragonfly/dfdaemon.sock] delay=15s timeout=5s period=30s #success=1 #failure=3
Readiness:    exec [/bin/grpc_health_probe -addr=unix:///var/run/dragonfly/dfdaemon.sock] delay=5s timeout=5s period=30s #success=1 #failure=3
Environment:
Mounts:
/etc/dragonfly from config (rw)
/var/lib/dragonfly/ from storage (rw)
/var/log/dragonfly/dfdaemon/ from logs (rw)
Conditions:
Type              Status
Initialized       True
Ready             False
ContainersReady   False
PodScheduled      True
Volumes:
config:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      dragonfly-client
Optional:  false
dfinit-config:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      dragonfly-dfinit
Optional:  false
containerd-config-dir:
Type:          HostPath (bare host directory volume)
Path:          /etc/containerd
HostPathType:  DirectoryOrCreate
storage:
Type:          HostPath (bare host directory volume)
Path:          /var/lib/dragonfly/
HostPathType:  DirectoryOrCreate
logs:
Type:        EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
QoS Class:       Burstable
Node-Selectors:
Tolerations:     node.kubernetes.io/disk-pressure:NoSchedule op=Exists
node.kubernetes.io/memory-pressure:NoSchedule op=Exists
node.kubernetes.io/network-unavailable:NoSchedule op=Exists
node.kubernetes.io/not-ready:NoExecute op=Exists
node.kubernetes.io/pid-pressure:NoSchedule op=Exists
node.kubernetes.io/unreachable:NoExecute op=Exists
node.kubernetes.io/unschedulable:NoSchedule op=Exists
Events:
Type     Reason     Age                       From     Message

Warning  Unhealthy  41m (x6424 over 2d21h)    kubelet  Readiness probe failed: timeout: failed to connect service "unix:///var/run/dragonfly/dfdaemon.sock" within 1s
Warning  Unhealthy  6m44s (x2824 over 2d21h)  kubelet  Liveness probe failed: timeout: failed to connect service "unix:///var/run/dragonfly/dfdaemon.sock" within 1s
Warning  BackOff    104s (x11652 over 2d21h)  kubelet  Back-off restarting failed container client in pod dragonfly-client-lgx66_dragonfly-system(f0f5b4a1-d9ac-4d3f-8fb7-1662606d18ab)

@caisheng821 Can you provide the log of kubectl describe po dragonfly-seed-client and kubectl logs dragonfly-seed-client.

already been posted on the log


fix: add zh readme

Translated according to these 3 docs.
https://raw.githubusercontent.com/kubernetes/website/4bb98f739582d0653060e281061e2abdb78f1eaf/README.md
https://github.com/kubernetes/website/blob/master/README.md
https://github.com/kubernetes/website/blob/master/README-de.md

fix #14773

@tengqm Please take a look. Thanks.

cc @markthink

Looks good in general. Please include the original text in your localized version for change management and review. Thanks.

#14562

@tengqm @chenrui333 Please take a look. Thanks.

Thanks for your update @zhangqx2010 ! :blush:
/lgtm

I will take a look later, nice work at first!!

need lgtm @chenrui333

/lgtm
/approve
Thanks!!

/assign @kbarnard10

@kbarnard10, It is ready to ship!

/approve


CB-1239 Extract HA services to the flow module

@keyki pls review

PR for the helm charts: https://github.com/hortonworks/dps-k8s/pull/380

@schfeca75 I don't see the node id change for periscope, isn't it required also?


Add Configuration Options for SharePoint in PCF

Overview
I would like to request the addition of configuration options in the PCF control for attachments to enhance its usability and flexibility. The requested features include:

Enable/Disable SharePoint Option: Allow the Maker to decide whether the option to use SharePoint as the storage location is available to end users.
Predefine SharePoint Location: When SharePoint is enabled, provide a configuration setting to predefine the SharePoint location. This removes the need for end users to select a SharePoint location, thereby streamlining the process and reducing potential errors.

Benefits

Improved Control: Makers will have more control over how attachments are managed, ensuring consistency across the application.
Enhanced User Experience: End users will experience a more straightforward and error-free process when dealing with attachments, as the SharePoint location can be predefined.
Reduced Configuration Overhead: By allowing Makers to predefine settings, the configuration process becomes more efficient and less prone to mistakes.

Implementation Suggestions

Add a toggle option in the PCF control configuration to enable or disable the SharePoint option.
Include a field in the configuration settings where the SharePoint location can be specified by the Maker when the SharePoint option is enabled.

Thank you for your suggestions, Thomas.
Both are excellent ideas. I will work through this to fit your request in the next release.

2. Predefine SharePoint Location: When SharePoint is enabled, provide a configuration setting to predefine the SharePoint location. This removes the need for end users to select a SharePoint location, thereby streamlining the process and reducing potential errors.

If I may I add to this. User (such as an Admin) may belong to multiple departments and would need a list of SharePoint sites available to choose from. Maybe a checkbox with "Remember My Choice" so it stays on that selection for next time.
@GorgonUK — do you have a timeline for the next release? If not, we will do this internally and force SharePoint (no need for a toggle) as Dataverse storage is expensive

@WilbertWalrus Enabling cross SP site functionality requires major rework in the PCF. You can select it individually for now. There is a possibility I might incorporate a "Save my choice" functionality in the future if there is enough demand for it.

User's preference is now saved to local storage.


Exception when creating a model with a firecape

The issue stems from the use of the model dumper code written by bram91 Model Dumper. In the readme of the github repository it states that the model dumper does not support color for "firecape/infernal cape textures" *
After using the Model Exporter plugin to exporting the models of a player wearing a fire cape and a different cape that doesn't have an animated texture, it becomes clear were the issue comes from.

Other projects that also use bram91 code for model dumping circumvent this issue by putting in checks to ensure the user doesn't try to upload a model with an animated cape (or even animated weapons that are also unsupported). An example of this is the Osrs Profile plugin, They use a list of blacklisted capes and weapons as seen here.
The black list they use is the following:

6570 - Fire Cape
21285 - Infernal Max Cape
21295 - Infernal Cape
12788 - Magic shortbow (i)


Optimize lock file format for git merge conflicts

This commit is an attempt to refine Cargo's lock file format to generate
less git merge conflicts for lock file updates as well as make it easier
to manage lock file updates. The new lock file format has a few major changes:

The [metadata] table is no longer used to track checksums. The
packages themselves now list checksum fields directly.

The entries in the dependencies key no longer unconditionally
mention the version/source of the dependency. When unambiguous only
the name or only the name/version are mentioned.

As mentioned before the goal here is to reduce git merge conflict
likelihood between two cargo updates to a lock file. By not using
[metadata] the updates to package checksums should only happen on the
package itself, not in a shared metadata table where it's easy to
conflict with other updates. Additionally by making dependencies
entries shorter it's hoped that updating a crate will only either add
entries to a lock file or update lines related to just that package.
It's theorized that the amount of updates necessary to a lock file are
far less than today where the version has to be updated in many
locations.
As with all lock file format changes this new format is not turned on by
default. Support is added so Cargo will preserve it if it sees it (and
tests are added too), and then some time down the road we can flip the
switch and turn this on by default.

r? @ehuss
(rust_highfive has picked a reviewer for you, use r? to override)

Ah meant to do this earlier, but here's a diff of the old vs new format for Cargo's own Cargo.lock

Nice!
Do you think this will be solid enough that eventually rust-lang/rust can remove the -merge git attribute on Cargo.lock?
Is there any way to test this from the command-line locally?  I couldn't see a way to force it to generate a new lock file.

I'd hope so yeah! I wanted to get this up as an idea before I completely forgot about it and it's something I've been meaning to do for a long time. A perfect analysis of this PR would scrape github for a set of Cargo.lock changes over time. We could then compare the diff to a diff as-if the lock file were encoded with this proposed encoding. In theory we could even objectively conclude that this produces small diffs and infer that the likelihood of a merge conflict goes down.
For testing locally there's no configuration to generate the new format, just preservation of the new format if it's found. If you edit a Cargo.lock though to remove the version/source information in one of the dependencies entries (just one, no need to do the entire lock file) then Cargo will think it's the new format and change it. For example with Cargo I changed memchr 2.2.0 (registry+https://github.com/rust-lang/crates.io-index) to memchr and then ./target/debug/cargo fetch generated a new lock file.
To be clear as well, I'm in no rush to land this. I wouldn't mind taking more time to evaluate this (or rather finding time to properly evaluate this). Additionally it's probably worthwhile to at least try to brainstorm better encodings than the one I randomly invented here, as there's surely better things we could do too!

I probably not the only one with code that depends on the lockfile's format. Maybe the lockfile could at some point get a version-field so the need for format detection does not ripple downstream?

Ok so I've done a bit of initial analysis of this. I walked the entire history of the rust-lang/rust repository, found all commits that changed Cargo.lock, recorded the before/after files, and then regenerated the lock files using this new algorithm. I then compared the diff (as calculated by diff -u CLI tool) of the old format (what's actually in the history) and the new format (what's proposed here). The statistics I got were:

V2 format generates 22% smaller diffs on average, with a 29% standard deviation
V2 format diff was 5x larger in one commit. This commit removed a duplicate version of lazy_static, so the V1 format deleted one entry where the V2 format had to update all the lazy_static 0.2.x dependencies to lazy_static
V2 format diff can be up to 85% smaller. In this commit the version of getopts was updated and the V2 diff was very small since the update was localized.

A historgram of the new diff size over the old diff size as a percent looks like

Looks like there's a huge spike of basically creating the same sized diff. That seems to happen a lot in rust-lang/rust due to additions/removals of dependencies. The lock file is so big that it's mostly just dependency edges getting removed and the checksum section doesn't change much. Additionally rust-lang/rust has a lot of path dependencies which aren't listed with a checksum.

Now all of this is only a proxy really for the actual metric we care about here, which is reducing the likelihood that two modifications to Cargo.lock will conflict according to git. I'm not actually sure how to measure that directly in an easy-ish fashion. I could try though to maybe test a few by hand whenever a PR conflicts in rust-lang/rust and see if it works. @ehuss do you have thoughts on perhaps more data you'd like to see?

How much of a concern is it that after a clean git merge, the resulting Cargo.lock is not "complete".  That is, if you run with --locked it will fail?
Here's an example.  A workspace with members a, b, and c.  a has a dependency on foo 1.0.0. In a branch, c adds a dependency to foo 1.0.0.  Independently on master, b adds a dependency on foo 2.0.0.  When c merges to master, it will merge cleanly.  However its dependency is still listed as just foo.  This will fail with --locked because it should be listed as foo 1.0.0.

The same thing happens when there are multiple versions of a package.  Say there are dependencies on foo 1.0.0 and foo 2.0.0.  A branch adds a dependency to foo 2.0.0.  Then on master, foo is updated to 2.0.1.  When the branch merges, it still references foo 2.0.0 when it should reference 2.0.1.
These should still be functional, but will fail with --locked.
I'm wondering if this will be pretty rare, at least on repos the size of rust-lang/rust?  When a rust-lang/rust PR attempts to be tested with bors, it should fail within a couple minutes so it may not be too painful?

FWIW, I simulated a bunch of Cargo.lock merge conflicts I've received on rust-lang/rust over the past year using the V2 format.  None of them failed, and they are all valid and pass with --locked.

How much of a concern is it that after a clean git merge, the resulting Cargo.lock is not "complete".  That is, if you run with --locked it will fail?

An excellent question! I would personally say that this is not a concern, but with nuance.
In general I think we want Cargo.lock to get out of the way as much as possible in most workflows, in general being entirely automatically managed. I would take this to mean that Cargo should as aggressively as possible try to recover from a git merge creating a bad lock file.
An example of this is that historically Cargo would return a parse error for a lock file that was semantically valid. For example if you had a dependency edge pointing to a nonexistent package Cargo would fail parsing that (because Cargo would never itself produce that). We ended up landing a PR though that basically swallowed the errors. The goal with it was to take as much valid information as possible from the lock file but if it doesn't all match up then we'll re-resolve anyway.
There's a separate issue in this repository for we should literally handle lockfiles with git merge markers (think >>>>>>>>>>>>>> and friends). I actually think it'd be pretty cool to do this, and the basic idea would be that we would largely automatically handle git merge conflicts (to the best extent that we could). I think there's existing prior art for this in package managers like yarn. (IIRC)
Overall I see this as a general extension of Cargo's "incremental updates" feature. If you get a bad git merge then Cargo should still accept the lock file and just automatically update it, but when doing so we shouldn't shake up the entire world. Instead we'll just try to extract as much that's valid as we can and progress with that.
Does that make sense and sound reasonable?

I'm wondering if this will be pretty rare, at least on repos the size of rust-lang/rust? When a rust-lang/rust PR attempts to be tested with bors, it should fail within a couple minutes so it may not be too painful?

I suspect it'll definitely come up over time, but yeah the failure should happen pretty quickly since it shows up as soon as you try to build anything basically.

FWIW, I simulated a bunch of Cargo.lock merge conflicts I've received on rust-lang/rust over the past year using the V2 format. None of them failed, and they are all valid and pass with --locked.

To clarify, were these git merge conflicts reported by bors or by git? I think we've got that binary attribute which causes any changes to be considered a git merge conflict, but git may be able to already merge some things today that bors rejects.

To clarify, were these git merge conflicts reported by bors or by git?

The initial list was from bors (using this query).  Some of them are legitimate conflicts (that is, even without the -merge attribute) due to the structure of the V1 format.  With the V2 format, IIRC there were no git conflicts detected.

Nice! And thanks for checking that!
That plus what I was seeing makes me pretty confident in this PR, so in that sense I don't have much more investigation I'd like to do :)

//! * Wait a "long time" (e.g. 6 months or so)

I can recall two prior changes of Cargo.lock format:

#4571 has removed [root]
#6180 has added a @generated comment at the top

The second change was backwards compatible. Older rustcs would only remove it but they'd still parse the Cargo.lock. Here, there was a 12 week period.
The first change was not backwards compatible. There was a year long period. It was still too short for multiple people when the switch was eventually done.
This change is, similar to the first change, not backwards compatible. I want to discuss the following options for handling the switch:
Option A: waiting six months like suggested in the PR.
Option B: waiting one year. This would be analogous to the [root] removal. A point against is that [root] removal didn't bring a benefit while this change actually is beneficial.
Option C: using the powers of opt-ins. There seems to be a zero sum situation if the decision of the format is hardcoded into Cargo.lock between people who want backwards compatibility and people who want to avoid merge conflicts. One group wants it to be earlier, the other group wants it later, classical zero sum. The situation becomes positive sum with opt-ins. At the start, it would be opt-in for people who want to avoid merge conflicts, one year (or some other time period) later defaults switch and it's opt-in for people who want backwards compatibility. Both groups would gain most with option C: the people who don't want merge conflicts can easily switch immediately after it becomes stable (without having to patch their Cargo), while the people who want backwards compatibility can use the old format indefinitely. A strawman proposal for exposed syntax is cargo check --lock-file-format latest for opting into the new Cargo.lock format and lock-file-format = "1" in Cargo.toml for opting into the old format (number increasing for newer Cargo.lock formats).
I'd personally prefer option C over option B over option A. A variant of option C would be to tie everything to editions but I doubt that the people who don't want merge conflicts want to wait three years :).

Is it correct that this will remove the [metadata] table entirely? Is there an easy replacement for checking duplicate crates in the dependencies of a project? For this I currently usually scroll over the [metadata] table, which is sorted and hence makes it fairly easy to visually spot duplicate crate names. In particular this is possible in diffs to quickly spot if a cargo update introduced crate duplication.

:umbrella: The latest upstream changes (presumably #7127) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung yes, this will remove [metadata] entirely and you'll have to scan adjacent [package] annotations or use something like grep/cargo-tree/etc.
@est31 I'll create a tracking issue for this if it lands and the roll-out strategy can be discussed there.

I agree with the earlier comment that it'd be nice to have a version field. Or, alternatively, a features field would work.

Ok we discussed this at the cargo triage meeting today and the conclusion was that there's no major blockers that came up. I've opened a separate issue about versioning and version numbers, which we decided is orthogonal from this PR it doesn't need to block this PR.
r? @ehuss for a final review of the bits and pieces?

@alexcrichton can you cargo +stable fmt?
Do we need to expedite the creation of a rustfmt bot? 😄
Just beware, there's an issue with nightly rustfmt treating some zalgo text differently from stable (in test_progress_status).  The nightly version is more correct (it's a bug fix), but does make it awkward. I've considered changing the text to be unicode escapes, but it is hundreds of bytes long.

Oh oops, right. Formatted!

@bors r+

:pushpin: Commit 34bca035ae133abe7e62acd0e90698943d471080 has been approved by ehuss

:hourglass: Testing commit 34bca035ae133abe7e62acd0e90698943d471080 with merge 767ecea0b407431a3472fa351944ebf2438d1e24...

:sunny: Test successful - checks-azure
Approved by: ehuss
Pushing 767ecea0b407431a3472fa351944ebf2438d1e24 to master...

@alexcrichton any news on the tracking issue?

I've opened https://github.com/rust-lang/cargo/issues/7144 for that.

Is there any way to turn this on? I see that it will use ResolveVersion::V2 if it detects it was already encoded in that format, but is there a way to tell Cargo to generate a V2 lock file?

@metajack optimally, there'd be an opt in to do it, but for now I think you need to patch cargo to emit this lock format and generate the initial v2 lock file. You can ask @alexcrichton how he did it for https://github.com/rust-lang/rust/commit/093ede240ab8bb4ec6720301619dda831b5690fd .

Would it make sense to have a cargo.lock file version attribute inside cargo.lock?
Something like:
# It is not intended for manual editing.
[package] # or [lock]/[[lock]]
version = "2.0"

[[package]]
name = "version_check"
version = "0.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "914b1a6776c4c929a602fafd8bc742e06365d4bcbe48c30f9cca5824f70dc9dd"

@rlabrecque See #7144.


Could you provide an osx-arm64 or noarch conda package?

Comment:
On conda-forge, there are only conda packages for pyannote.database for osx-64, linux-64 and win-64 but not for osx-arm64.
Could you please provide a conda package for osx-arm64 as well?
From the pypi source it even seems as if this could be a noarch package: https://pypi.org/project/pyannote.database/#files

I'll see what I can do.

@FriederikeBrezing I have a change for pyannote.core to convert it to noarch (and 5.0.0). Once that is done I'll convert this over to noarch and 5.0.0 as well.


TeachingTip: Fix bug where empty title/subtitle was not respected in ApplyTemplate leading to gap

Description

Add checks when in ApplyTemplate to collapse the textblocks if necessary.
Motivation and Context

Closes #1396
How Has This Been Tested?

Add new API test
Screenshots (if appropriate):

Go ahead and change the member variable name.

/azp run

Go ahead and change the member variable name.

Done :)

The test failure was a layout cycle issues which was caused by directly changing visibility of elements inside OnApplyTemplate. I switched to visual states for that now and updated the TeachingTip testhooks function to get the Title/Subtitle textblock through GetTemplateChild instead of requesting that once in OnApplyTemplate. That way, we are able to store two elements less inside the TeachingTip that aren't used beside the test hooks.

I'm looking forward to this landing so the Terminal can use this too - I don't think we're going to always need a TeachingTip with both a title and subtitle, so right now we always end up with some weird space.
Hopefully we can see this land in 2021 ☺

/azp run

/azp run

/azp run


Fix broken shadow docs after first attach

Forwards fix from https://github.com/choumx/amp-pwa/issues/8.
/cc @pbakaus @sebastianbenz

Nice one, thanks much!


Tried a Pull Request

Hi!
I've done some little fine-tuning on MokshaRadiance.
Instead of report on Bodhi Forum, tried to use github. After all is the correct platform to do this.
Here's the changes:
First, change the gray of the border to match exactly with the GTK menu bar. It is just a simple change on rad_conf.edc, of course.
Before

After

Second, make the temperature module monochromatic. It is not super cool, but it seems more readable than the default one.

Looks great!


Refactor extension to completely remove old way of spawning python processes

Fixes #354

Code refactoring to remove execPythonFile function and use the new execution layer

@brettcannon all issues have been addressed. Thanks

@brettcannon all issues have been addressed. Thanks

@brettcannon Thats fine, I'll leave the PR open. Lets get it reviewed correctly in the new year. I'll base other PRs off this branch.


[WIP] Adding doc for release process v2

Signed-off-by: rachitchauhan43<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Type of changes
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevent result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

[ ] Test A

[ ] Test B

Logs

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

[ ] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Release note:

@rachitchauhan43 Are we ready to get this in?

@yuzisun : Apologies for the delay. Will close it this week.

@yuzisun : Apologies for the delay. Will close it this week.

@rachitchauhan43 Is there any more changes need to be made on this PR?

@yuzisun : Apologies for the delay. Will close it this week.

@rachitchauhan43 Is there any more changes need to be made on this PR?

@rachitchauhan43 Let's just get this in and improve with the 0.11 release?

@yuzisun : Apologies for the delay. Will close it this week.

@rachitchauhan43 Is there any more changes need to be made on this PR?

@rachitchauhan43 Let's just get this in and improve with the 0.11 release?

Hey @yuzisun , I am done with the changes. Please review

Thanks @rachitchauhan43 !!
/lgtm
/approve


Publish docker image

I believe someone else also asked for this. It would make hosting easier

Certainly. I'll look into it. Thanks.


:gift_heart: PR Previews!

While working on https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/1 I've wanted to have a PR preview, so I made one using https://daiyi.co/blog/pr-previews-for-github-pages as inspiration.
It works really well, and I thought to share it with the upstream template as well.
It generates a preview build, and publishes it on GH Pages in a subdirectory. The PR is commented to allow easy access to the preview link.
After the PR is merged, the preview is removed. The generation of the main documentation, doesn't remove the PR previews, so it's safe to work in parallel.
Refs:

https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/2
https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/3
https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/4
https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/5
https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/6
https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/7
https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/8

FYI @jayachristina for updating https://github.com/redhat-solution-patterns/solution-pattern-website-template as well

This will work here as well, but because I'm sending the change across forks, the workflow needs to be approved to be executed.

You can see a preview comment here: https://github.com/cardil/solution-pattern-event-mesh-for-microservices/pull/1#issuecomment-2551584257


Register package

@JuliaRegistator register()

Registration pull request created: JuliaRegistries/General/29952
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" eccdac35c6e11e849cc7b7038c4c7a772a5c4700
git push origin v0.1.0

Registration pull request created: JuliaRegistries/General/42609
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.1 -m "<description of version>" b1da65a80badbceb2045f730f69d7d096d77a54f
git push origin v0.1.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/52466
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.1 -m "<description of version>" 1f55d261874063b3e4c4a7e201c5f538a2a5a606
git push origin v0.2.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/53214
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.3.0 -m "<description of version>"<PHONE_NUMBER>e695be63efbaac4322a5d142f45fbd
git push origin v0.3.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/60207
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.3.2 -m "<description of version>" 9199770dc5025782a09416fc02fc95102d0ec30a
git push origin v0.3.2


OpenCL | | syCL | | HIP support ?

The Apple i/GPU usebase is mostly made of Intel and AMD. Yet you've chosen to follow that irational trend of going for the ridiculously little minority (watch the JPR stats) that are nvidia gpus, because 1) they invest ton of money for brainwashing developpers, 2) some tools like Tensorflow do not yet support the standards because of the 1) reason.

If you weren't aware, AMD has designed an impressive tool for translating existing modern CUDA code in OpenCL code. Often it take less than one week to convert à project with this tool.
https://github.com/ROCm-Developer-Tools/HIP
I'm not even talking of the fact that AMD hardware is far more suited for machine learning than Nvidia because for example it support full FP16...
So, will you choose the rational way that let choice to the consumer, and to the PC maker ?

Thanks for the feedback @LifeIsStrange. We are aware of this and working hard (as we speak) to make this happen. Stay tuned for updates!

That's amazing, thank YOU for participating to inverting the CUDA monopoly trend !


Add Review Reminder

Reviews are in here https://github.com/mention-me/pivotal-lint/pull/1

@edhgoose I decided to create a new branch with better name. Unfortunately the review comments will only be in the old PR


add topics

I suggest adding topics such as static-analysis, python in the About section at https://github.com/quora/pyanalyze

Good idea, added a few.


EventsResource.ListRequest TimeMin property do not correctly filter events if set to DateTime.MinValue

What steps will reproduce the problem?

Add Public Holidays calendar to list of available calendars

request calendar events and set TimeMin and TimeMax properties
Set TimeMin to DateTime.MinValue
Set TimeMax to DateTime.UtcNow.AddYears(1)

What is the expected output? What do you see instead?
Expect to return all calendar entries up to a year from today.

Instead - no public holiday events are returned.

If TimeMin is set to actual date e.g. DateTime.UtcNow.AddYears(-1) then all
valid public holiday events are returned.

What version of the product are you using? On what operating system?
Calendar API v3, Win 7 64-bit

Please provide any additional information below.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 16 Aug 2012 at 10:15

No action has been made on this issue in several years. Closing out as stale. I assume the problem lies in the conversion from "the year 1" to a Unix timestamp.


feat: support bot project's ui schema

Description
Adds support for loading a bot project's ui schema as well as any user overrides. The schema has been defined here.
This also includes a refactor to support the new ui schema and adds some utilities to consume the merged result. Also introduces the composer ui plugin that houses the default ui schema. The ui schema will be migrated into the sdk shortly.
Task Item
Closes #3583

Coverage decreased (-0.7%) to 55.76% when pulling 2a96ed4698d781ac8954f07eaf397b1a17b0bdae on abrown/feat/bot-project-ui-schema into 2b1c72106bbe76b2584884baceec363556e936d8 on main.

@a-b-r-o-w-n in the server, we check-in the sdk.schema and serve it to the client when we don't have one supplied with the open bot. Should we do something similar with the merged uischema?

@cwhitten I'll update. For now, I'll just add an empty file which will eventually be replaced by the sdk ui schema.


while doing pod install, encountering following error Invalid Podfile file: /node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:39: syntax error, unexpected <<     template =<<~EOS

New Version
0.71.11
Old Version
0.68.7
Build Target(s)
iOS, while doing pod install
Output of react-native info
System:
OS: macOS 13.2.1
CPU: (12) arm64 Apple M2 Pro
Memory: 112.66 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 18.16.1 - /usr/local/bin/node
Yarn: 1.22.19 - /opt/homebrew/bin/yarn
npm: 9.5.1 - /usr/local/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.5.2 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1
Android SDK: Not Found
IDEs:
Android Studio: 2022.2 AI-222.4459.24.2221.10121639
Xcode: 14.1/14B47b - /usr/bin/xcodebuild
Languages:
Java: 20.0.1 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.2.0 => 18.2.0
react-native: 0.71.10 => 0.71.10
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Issue and Reproduction Steps
run command - pod install
error -
[!] Invalid Podfile file: /node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:39: syntax error, unexpected <<
template =<<~EOS
^
/node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:40: unknown regexp options - ll
/node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:41: dynamic constant assignment
RCT_SCRIPT_POD_INSTALLATION_ROOT=$(pwd)
^
/node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:41: `$(' is not allowed as a global variable name
/node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:41: syntax error, unexpected end-of-input
RCT_SCRIPT_POD_INSTALLATION_ROOT=$(pwd)
^.
from ios/Podfile:1
-------------------------------------------

require_relative '../node_modules/react-native/scripts/react_native_pods'

require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

That's an unexpected error.  Before we go any deeper can you:

node_modules and run yarn install or npm install (whichever you normally do)
exactly follow the INFO steps in the guide.

That way we'll have a good baseline to figure out what's happening.

even after crating a new project getting same issue

A couple of more steps will be really helpful 😀, I appreciate your patience.
From inside your project folder can you share the output of these commands exactly (copy and paste please):
❯ bundle exec pod --version
1.12.1
❯ bundle exec ruby --version
ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [arm64-darwin21]
❯ cd ios
❯ bundle exec pod install
Framework build type is static library
[Codegen] Generating ./build/generated/ios/React-Codegen.podspec.json
Analyzing dependencies
[Codegen] Found FBReactNativeSpec
[Codegen] Found rncore
Downloading dependencies
Generating Pods project
Setting REACT_NATIVE build settings
Setting CLANG_CXX_LANGUAGE_STANDARD to c++17 on /Users/blakef/src/rn/RN073/ios/RN073.xcodeproj
Pod install took 8 [s] to run
Integrating client project
Pod installation complete! There are 63 dependencies from the Podfile and 53 total pods installed.

Well, with Blake's suggestion the root cause will be clear which is likely due to a version mismatch (wrong version) of the pod or something else.
P.S. As a last go, you may try 2nd and 3rd answer from the below thread only after verifying :)
https://stackoverflow.com/questions/72130276/invalid-podfile-file-unexpected-template-eos

bundle exec pod --version

1.5.2
bundle exec ruby --version
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin22]
cd ios && bundle exec pod install
[!] Invalid Podfile file: node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:39: syntax error, unexpected <<
template =<<~EOS
^
node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:40: unknown regexp options - ll
node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:41: dynamic constant assignment
RCT_SCRIPT_POD_INSTALLATION_ROOT=$(pwd)
^
node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:41: `$(' is not allowed as a global variable name
node_modules/react-native/scripts/react_native_pods_utils/script_phases.rb:41: syntax error, unexpected end-of-input
RCT_SCRIPT_POD_INSTALLATION_ROOT=$(pwd)
^.

ios/Podfile:1
-------------------------------------------

require_relative '../node_modules/react-native/scripts/react_native_pods'

require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
-------------------------------------------

issue is fixed. https://stackoverflow.com/a/75890143


Actually use security framework

Describe the solution you'd like
It'd be nice to actually apply the security framework when building.
Describe alternatives you've considered
Ignoring security problems won't help.

So, what I am thinking is a settings configuration  in tauri.conf.js that looks something like this:
security: {
  rust: {
    check: [warn, throw, fix],
    service: [cargo-audit, antivuln, snyk],
    command: ''
  },
  node: {
    check: [warn, throw, fix],
    service: [npm, yarn, antivuln, snyk],
    command: ''
  }
}

As well as a CLI command tauri audit that hooks into the same logic.

Here are some nice rust resources
https://github.com/rust-secure-code/projects

Some of this stuff will be built into the prop testing that I am implementing.  Others can be manually attached to it later. Conditional compilation will allow us to build a pipeline to be able to compose and attach these tools to a dev or even production build to see some of these elements.

Security plug-in

Bumping this issue, because its time to manufacture tauri audit.

I'll start to work on this issue

@dobleuber status?

@dobleuber status?

Hey, Sorry! Many things happened to me. I haven't continued working on this.


update deps

This PR updates Docusaurus packages to v2.0.0-beta.18.

@xaviergonz Did you accidentally close this PR instead of merging it? :thinking:


Amazon SQS automatic queue creation

As suggested in https://github.com/bernardphp/bernard/pull/295#issuecomment-316026902

@holtkamp can you rebase onto the current master?

@acrobat yeah, tried it locally, did not work out 😞 , GitHub allowed to resolve the conflicts, is it ok now?

Mmm, sorry for this mess, guess I have to start from scratch to create a clean PR

@acrobat sorry for the confusion, it seems to be mergeable now. You can squash commits using GitHub interface I suppose?

Changes look good to me. @holtkamp is it possible to add a test for this?

Well, I stared at it for some time, but really got no clue how to test this... Suggestions? The whole mocking stuff is kind of new for me... 😥

I will think about it (maybe implement a test for this when moving the drivers to a separate repo). But for now let's just merge it!

Thanks @holtkamp!

Please try to avoid having merge commits like this: Merge branch 'master' of...
If you still do end up having one, please use the squash feature of Github merge.

I will try to setup an amazon account for integration tests.

Yeah rebasing a branch is better but no big issue as it indeed can be merged with the squash feature of github (as was done with the merge https://github.com/bernardphp/bernard/commit/28e5b261d5566ac57e40758ad9ec4f6b98b3d467)

aah, great, thanks guys. Yeah my GIT skills are still quite basic. Rebasing seemed to fail so I relied on the "squash commits" feature when merging...
Any plans for a newly tagged release? 😇

Any plans for a newly tagged release?

Sorry, no plans in the near future. Things will break in the near future, so I don't see any point in releasing now.

and a bumped alpha release like 1.0.0-alpha7, just to point our composer.json to in order to incorporate the improved SQS functionality?

Things will break in the near future, so I don't see any point in releasing now.

Would you consider my "point" to do tag a new minor release: functionality was added?

@sagikazarmark what do you think, have a last alpha release with these (and some other) fixes and after that focus on work for stable 1.0.0, with possible breaking changes?

Since we are not working towards 1.0 with these "alpha" releases, I don't see any point in them as alpha releases of 1.0. We can of course tag releases, but I think that's a huge mistake from versioning point of view. Not to mention how fragile it is to rely on alpha versions.
If I were you, I would rather maintain a custom version of the driver until 1.0 is tagged.
That's my opinion on the matter. That being said, alpha releases are already kinda abused, so it won't really hurt more than it already does. Feel free to tag an alpha release @acrobat.

Ok, I will try to do it in the next days!

@holtkamp I've just released a new alpha with these changes included. See https://github.com/bernardphp/bernard/releases/tag/v1.0.0-alpha7
/cc @sagikazarmark


HTTP Repository use of FileInputStream/FileOutputStream

Similar to #1790 (and somewhat to #456, since it's java.nio)
add() method in org.eclipse.rdf4j.repository.http.HTTPRepositoryConnection
and getRepositoryConfig() in org.eclipse.rdf4j.repository.manager.LocalRepositoryManager
use FileInputStream instead of Files.newInputStream  (slightly faster for smaller files, and without finalizer method)

This issue can be closed because both of this points are already using FileInputStream.
https://github.com/eclipse/rdf4j/blob/84a6f7b59e19e15d7876f76aa2e0eb7f59088459/core/repository/http/src/main/java/org/eclipse/rdf4j/repository/http/HTTPRepositoryConnection.java#L380
https://github.com/eclipse/rdf4j/blob/b849630bfac9c84e0444390179409456da043b15/core/repository/manager/src/main/java/org/eclipse/rdf4j/repository/manager/LocalRepositoryManager.java#L259


URLs do not change when programs in editor are changed

Currently using
http://stg-cadet-frontend.s3-website-ap-southeast-1.amazonaws.com/playground#chap=1&prgrm=FAFgHAbA3MxA
in Chrome on macbook pro. Editing the program in the editor does not change the URL.
The updating of the URL as the user types is not critical. What is critical is to have an easy way to get the URL when needed, if necessary with a button.

Woah! Great! My bad!


Upload .mov video extension.

I'm tying to upload video file in .mov file extension other video file such as mp4, flv is working but when tyring to upload .mov it doesn't work.
here is my code :
public function add_video(){
    if (isset($_FILES['video']['name']) && $_FILES['video']['name'] != '') {
        unset($config);
        $date = date("ymd");
        $configVideo['upload_path'] = './video';
        $configVideo['max_size'] = '9000000000';
        $configVideo['allowed_types'] = 'mov|avi|flv|wmv|mp3|mp4';
        $configVideo['overwrite'] = FALSE;
        $configVideo['remove_spaces'] = TRUE;
        $video_name = $date.$_FILES['video']['name'];
        $configVideo['file_name'] = $video_name;

        $this->load->library('upload', $configVideo);
        $this->upload->initialize($configVideo);
        if(!$this->upload->do_upload('video')) {
            echo $this->upload->display_errors();
        }else{
            $videoDetails = $this->upload->data();
            $data['video_name']= $configVideo['file_name'];
            $data['video_detail'] = $videoDetails;
            $this->load->view('/upload_video/show', $data);
        }

    }else{
        echo "Please select a file";
    }
  }

The error message that I'm getting after upload .move video is this
The filetype you are attempting to upload is not allowed.
I would love to ask how to fix this in Codeigniter, yes using the * sign in allowed type fix the issue but that would be allowing user to upload all the extention file.
Thank you
NOTE : I'm using Codeigniter 3.0.4

This is a common problem that depends on your server environment, not a CodeIgniter bug.
Please open a thread on our forums instead.

Oh okay, thanks for the link that lead me to the forum.


Incorporate "pipline" package into discovery tiers

Current Behavior
All fingerprinters run when MeshSync is invoked. They run without order of precedence defined or controlled sequence or concurrent operation defined.
Desired Behavior
Incorporate stages and steps of the pipeline package into design of MeshSync discovery process; create discovery tiers.

Resources

https://github.com/myntra/pipeline

Incorporated. @kalradev any documentation that we want to capture as part of the closing of this issue?

Gents,
Will you perform a quick update of the MeshSync docs prior to July 31st?

Gents,
Will you perform a quick update of the MeshSync docs prior to July 31st?

Updated them with log viewer and interactive terminal


Docker file fails to load on Mac OS X; problem with workspace?

Hey,
I couldn't get the docker image to start (though this is my first foray into containers). From what I understand of the logs, the problem is with this line in the configuration. Is that something DLS-specific?
"workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind,Z",
"workspaceFolder": "/workspace",

Hi Brain,
I've managed to re-produce the issue on our iMac. The Z tag at the end of the workspaceMount is specific to Security Enhanced Linux (SELinux) where it reserves a volume for a single container. I have created a pull request #117 with an updated devcontainer.json which should work for you. Please let me know if this resolves the issue


How to set XYchart yAxis rangepadding

Hi, is there a way to set the rangePadding of the yAxis in an XYchart? I saw that XYchart sets the xAxis rangePadding to xScale.offset, but the yAxis rangePadding to null.
I want to create space at the top of the chart above the highest data point (i.e. want the yAxis to extend somewhat above the data range). Thanks!

👋  @mcassels, thanks for checking out @data-ui. Looks like you're correct that we override rangePadding to null which I'd consider a 🐛.
I pushed a quick fix in #190 , as a temporary work around until I can release a new version (next few days) you could explicitly define the desired domain in XYChart.props.yScale object with the desired extra padding. This will be annoying if you don't already know the extent of data but might be better than nothing.

Great, thank you!!

this should be fixed in<EMAIL_ADDRESS>


Plugin CoreMetrics

This plugin intends to support core metrics for the Blockchain.
Currently, it contains a method for getting last timestamps of blocks based on height and number of requested blocks.
This current API is quite needed because front-end services are currently relying on other db services for querying blocks timestamps (because it is impracticable to query block header and then filter).

The prefix getmetrics sounds good, @igormcoelho.
Thanks for the project organization @erikzhang.


Add numpy dependency to python wrapper.

There was an issue with the existing PR, so I'm submitting a separate PR that resolves the Numpy dependency issue.

Modify pyproject.toml.
Add numpy to package dependencies. When installing this package with pip, numpy will be installed additionally if it is not in the Python environment.

Modify python-related workflows.
Modify each python workflow to explicitly install the dependencies (pyproject.toml) required for the build.

close #1919

Can I ask what's the rationale for adding a dependency on numpy? Technically someone could use any other libraries that have a compatible numpy like array types.

Actually, never mind we indeed need to add it as a runtime dependency because pybind11::array is used instead of pybind11::buffer.
But it only needs numpy>=1.7.0.

Note that pybind11/numpy.h does not depend on the NumPy headers, and thus can be used without declaring a build-time dependency on NumPy; NumPy>=1.7.0 is a runtime dependency.

https://pybind11.readthedocs.io/en/stable/advanced/pycpp/numpy.html#arrays
But still, my comment about the build time dependency is still valid. We don't need numpy to build openexr.

But I think I'll try to build locally and test locally, because I'd like to get a better traceback/backtrace.

Can I ask what's the rationale for adding a dependency on numpy? Technically someone could use any other libraries that have a compatible numpy like array types.

@JeanChristopheMorinPerso, thank you for your review. I agree with what you said and have modified the code.


Razor Pages responding to all HTTP verbs

I've been noticing some exceptions being logged on a Razor Pages application. The exceptions looked to be random, and were logged on pages that are incredibly simple and always worked perfectly when tested in a browser.
Eventually I tracked the errors down to when pages are requested with HEAD or OPTIONS HTTP verbs. The exceptions are thrown as the view is executed, because the page's OnGet() has not prepared the view model and it is in an uninitialised state.
Some quick testing on an MVC project shows that things just seem to work as expected out of the box. If the action is decorated with any standard HTTP verbs ([HttpGet], [HttpPost]) then a HEAD or OPTIONS request returns a 404 status response, which makes good sense. If there are no HTTP verb attributes present then a HEAD or OPTIONS request returns an empty 200 status response, which again seems fine.
Is there a suggested best practice for dealing with the above with Razor Pages?

Hi. Thanks for contacting us. @NTaylorMullen, any thoughts regarding this one?

@pranavkm is better suited to answer this one 😄

If the action is decorated with any standard HTTP verbs ([HttpGet], [HttpPost])

Could you share a snippet of what you're doing to make this happen? Handlers on Razor Pages do not support method constraints the same way controller actions do, so I'm not entirely sure what your set up looks like.

@pranavkm That paragraph is talking about me testing using a traditional MVC controller and action.

The behavior you're seeing is by design. Razor Pages do a best effort to find a handler and fall back to rendering the page sans handler when it cannot find a match. There's a couple of recommendations here to organize your code

Write your code defensively assuming no handler was selected
Initialize things you always expect to be present in the model's OnPageHandlerExecuting method. This should run for all methods.

Another alternative might be to use a filter to 404 requests if no handler is selected. You can register a global filter along the lines of:
private class NoHandlerPageFilter : IPageFilter
{
    public void OnPageHandlerExecuted(PageHandlerExecutedContext context)
    {
    }

    public void OnPageHandlerExecuting(PageHandlerExecutingContext context)
    {
        if (context.HandlerMethod == null && context.ActionDescriptor.HandlerMethod.Count > 0)
        {
            context.Result = new NotFoundResult();
        }
    }

    public void OnPageHandlerSelected(PageHandlerSelectedContext context)
    {
    }
}

Yet another option might be add a page route model convention that adds a method based action constraint to your page selectors.

Closing the issue as it's by design. If you think there is something we haven't answered or considered, feel free to reopen it and leave your comments.

Thanks for the responses. I noticed that @shanselman bumped in to this same issue and documents it in a blog post (with further examples of people bumping into the same issue in the comments, and only noticing due to pen testing):
https://www.hanselman.com/blog/SettingUpApplicationInsightsTook10MinutesItCreatedTwoDaysOfWorkForMe.aspx

THOUGHT: I think this behavior is sub-optimal. While GET and POST are distinct and it makes sense to require an OnGet() and OnPost(), I think that HEAD is special. It's basically a GET with a "don't return the body" flag set. So why not have Razor Pages automatically delegate OnHead to OnGet, unless there's an explicit OnHead() declared? I'll file an issue on GitHub because I don't like this behavior and I find it counter-intuitive. I could also register a global IPageFilter to make this work for all my site's pages.

I'd agree with the above. It still needs to be possible for developers to override it with a specific handler, but it seems like the out of the box experience could be improved - in reality I would expect that a very high percentage of Razor Pages applications will break on HEAD requests, and that it won't be noticed unless the site is being tested or monitored thoroughly.

@svallis I think @rynowak is working on adding support for HEAD and OPTIONS requests mapping to GET as part of preview2. He's promised to file an issue for this soon.

@pranavkm @rynowak That sounds great, providing you can still override the handler on a per-page basis should the need ever arise. It would be fantastic to see it make the release of v2.1.0 - thanks for all the hard work!

Yep. Self-assigning myself.
This is working as we intended it to, but we still got it wrong in this case.  That's something that needs to 'just work'

@rynowak I'm still seeing exceptions for OPTIONS requests after upgrading to 2.1.0. Did this fix make it into the release?

This is attached to a compatibility switch. Add AddMvc().SetCompatibilityVersion(Microsoft.AspNetCore.Mvc.CompatibilityVersion.Version_2_1); to startup
Like: https://github.com/aspnet/Mvc/commit/14429721d933104e17bd5cae0b7f2399ca55ab2d#diff-85ae0edbe5e347e453bfdfc8467ce8f5R28
Let us know if you're still having problems after doing this

@rynowak We're experiencing this using CompatibilityVersion.Latest, I'm assuming that would currently equate to CompatibilityVersion.Version_2_1?

I'm reopening this for consideration. We didn't do anything about OPTIONS
@svallis - who's sending you OPTIONS requests and what for? is it a crawler?

@rynowak The frequency of logged exceptions is massively down now HEAD isn't causing them, but I still see a couple a week for OPTIONS requests. I'm not logging user agent with the exception currently, but my assumption would be that it's a crawler of some sort. It's possibly there's some weird browser/client out there that does it I suppose, too. I see the exceptions on different, random content pages on the site in question.
Sorry I don't have any more definite information; if it's important I can look into logging additional relevant data for you.

Yeah, this is kinda in no man's land. Traditionally in MVC OPTIONS would be handled by any method-neutral action - usually the same one that handles GET. However this isn't really correct, since you're not supposed to just treat OPTIONS the same ways.
We didn't want to double-down on that incorrectness, so we didn't lump it in with the fix for head. We might just want to automatically handle OPTIONS for pages (obviously allowing CORS to still work).

@mkArtakMSFT - clearing fields so this can be reconsidered