feat: option configure partition with env var

Adds support for deployment to aws-cn partition by checking an optional environemt variable, CDK_AWS_PARTITION. The partition is currently not available to the pipeline in the jobForDeploy, adding the environment variable is a non-breaking change to get the pipeline to deploy to aws-cn.
This has been verified with stacks and nested stacks in multiple stages in aws-cn.
Fixes #820

#868

looks good, can we unit test this just for posterity?

Absolutely. I'll see what I can do.

also, maybe a reference in the README would be helpful. doesn't have to be front and center, i don't imagine that many people in aws-cn are using this :)

Of course. I don't know why I didn't add it in the first place 🤦
Any suggestion under what section this would belong?

@kaizencc I've updated the documentation, I'm not a technical writer though so feel free to update it.
I've also added test suites, I figured it would get good coverage by duplicating the current test suites that are relevant for the changes here, and tweaking them for the aws-cn case.

@kaizencc Is this ok to be merged?


Version 4 - validation result retrieval

This is a follow-up of #383.
It adds a sync API validationResult(req), which returns an object of the same shape as v3 req.getValidationResult().

Coverage decreased (-0.4%) to 97.586% when pulling 8c49ee489d000c6ed98a94a437e66ff43a42269b on v4-result into 22311b40560eb2f5e7430bbc52f90f709b5678ef on master.


Question: Set ContextId instead of ActivityId

Hi,
I wanted to know if there is way to use Microsoft.Diagnostics.Tracing.EventSource to set the ContextId instead of the ActivityId. I see  Microsoft.Diagnostics.Tracing.EventSource  has SetCurrentThreadActivityId and I'm trying to accomplish something similar but with the ContextId. The motivation behind this is that I want my events to line up a bit nicer with the asp.net events in Perfview.
What I've got now is this:

Which works, but I want to see if I can do a bit better and only use ContextId to 'stitch' events together.
Any guidance (an example you can point to for instance) would be greatly appreciated
Thanks
cc: @vancem

ContextId is simply a field in the AspNetReq/Start event.  This field does not exist for other events (in particular your Portala-EventSource/Count.  Of course you could make such a field in your event (just make a parameter called ContextId, and pass it the current activity ID), and it would show up in the events view.
Note that the ASPNetTrace provider is old and uses conventions (like ContextId) that are not recommended (and don't set the ActivityID which is recommended).    Thus realize that you are building on unrecommended conventions....  That can be OK, but you should be aware of it.


tweak java settings per jboss tuning script

java tuning tweaks per recent exchange with jboss folks
@bparees ptal
@openshift/devex fyi

@gabemontero please update https://github.com/openshift/jenkins/blob/master/slave-base/contrib/bin/run-jnlp-client too.

run-jnlp-client updated

[test]

lgtm


documentation missing

I just added the basin app to the documentation app list (https://github.com/openforis/sepal-doc/pull/154). As the d.rst file is still empty I left the generated one for now.

It was done by cca2ba3083fc32e1c839988c67648ae6849e2221


Reformatting a string containing both single and double quotes breaks down

What happened?
If you use prqlc fmt on a triple-quoted string, typically it strips the triple-quotes and gives back a string with escape sequences for things like newlines.
let foo = """first
second"""

formats to let foo = "first\nsecond".
If you also include a set of double quotes in the triple-quoted string, the formatting output quotes the string in single quotes.
let foo = """first
and "second" here"""

formats to let foo = 'first\nand "second" here'
But if you include both single and double quotes in the triple-quoted string, the formatting output goes off the rails, using two double quotes to quote the string:
let foo = """first's
and "second" here"""

formats to let foo = ""first's\nand "second" here"" -- which is invalid PRQL.
This is also not limited to triple-quoted string input -- if you try to format an escaped version of the string, you get the same output.
let foo = 'first\'s\nand "second" here'

also formats to let foo = ""first's\nand "second" here"".
Perhaps prqlc fmt should emit triple-quoted strings when both single and double quotes are in the string?
PRQL input
let foo = """formatting's "failing" here"""
from employees

SQL output
let foo = ""formatting's "failing" here""

from employees

# Generated by PRQL compiler version:0.13.0-25-g53f747c1 (https://prql-lang.org)

Expected SQL output
let foo = """formatting's "failing" here"""

from employees

# Generated by PRQL compiler version:0.13.0-25-g53f747c1 (https://prql-lang.org)

MVCE confirmation

[X] Minimal example
[X] New issue

Anything else?
No response

This I think is now fixed, by #4850. Thanks for the issue @kgutwin .
I added a couple of TODOs in the code around more minor issues (we could open a new issue if this is salient to anyone). Copying below for reference. I also would like to add some more tests for escapes in raw strings; any bug reports there are very welcome.

TODO: one problem here is that we don't remember whether the original
string contained an actual line break or contained an \n string,
because we immediately normalize both to \n. This means that when
we format the PRQL, we can't retain the original. I think three ways of
resolving this:

Have different tokens in the lexer and parser; normalize at the
parsing stage, and then use the token in the lexer for writing out
the formatted PRQL. Literals are one of the only data structures we
retain between the lexer and parser. (note that this requires the
current effort to use tokens from the lexer as part of prqlc fmt;
ongoing as of 2024-08)
Don't normalize at all, and then normalize when we use the string.
I think this might be viable and maybe easy, but is a bit less
elegant; the parser is designed to normalize this sort of thing.


install with --no-index does not work

I need to install the package with --no-index after I downloaded all the packages
To Reproduce

setup a virtual environment
download wheel packages for setuptools, urllib3, certifi and elastic_apm
install them with

pip install --no-index setuptools-50.3.2-py3-none-any.whl certifi-2020.11.8-py2.py3-none-any.whl urllib3-1.26.2-py2.py3-none-any.whl

try to install elastic_apm with

pip install --no-index elastic-apm-6.6.0.tar.gz

I'm getting error
  Installing build dependencies ... error
  ERROR: Command errored out with exit status 1:
   command: /Users/massimoc/Projects/python/foo/.venv/bin/python3.9 /private/var/folders/2h/hz8sm1hn36lcmcmnpcpz98v80000gn/T/pip-standalone-pip-yb62v9ey/__env_pip__.zip/pip install --ignore-installed --no-user --prefix /private/var/folders/2h/hz8sm1hn36lcmcmnpcpz98v80000gn/T/pip-build-env-chofgdlh/overlay --no-warn-script-location --no-binary :none: --only-binary :none: --no-index -- 'setuptools>=40.8.0' wheel
       cwd: None
  Complete output (2 lines):
  ERROR: Could not find a version that satisfies the requirement setuptools>=40.8.0 (from versions: none)
  ERROR: No matching distribution found for setuptools>=40.8.0
  ----------------------------------------

Environment (please complete the following information)

OS: macOS
Python version: 3.9
Framework and version [e.g. Django 2.1]:
APM Server version:
Agent version:

Additional context
Add any other context about the problem here.

Agent config options

Click to expand
replace this line with your agent config options
remember to mask any sensitive fields like tokens

requirements.txt:

Click to expand
replace this line with your `requirements.txt`

This seems like a pip bug. You obviously installed setuptools>=40.8.0 since you installed setuptools-50.3.2-py3-none-any.whl -- maybe you need to install them all in one command? I've never used --no-index.

hello, looks like I fixed installing wheel as well

Excellent. Thanks for the update!


Notifications don't work when using gateways.

Hello,
I'm playing around with the Hooks examples in https://github.com/moul/assh/blob/master/examples/readme-full-example/assh.yml and notifications on macOS 10.15.6. All our connections require a bastion host, so I do the following:
hosts:
  bastion:
    Hostname: <hostname>
  server:
    Hostname: <hostname>
    Gateways: bastion

I also have the following from the examples I mentioned:
defaults:
  Hooks:
    AfterConfigWrite:
      # Alert me with a Desktop notification
      - notify "{{.SSHConfigPath}} has been rewritten"

    OnConnect:
      # Alert me with a Desktop notification
      - notify "New SSH connection to {{.Host.Prototype}} at {{.Stats.ConnectedAt}}."

    OnDisconnect:
      # write on terminal and in a Desktop notification some statistics about the finished connection
      - "write SSH connection to {{.Host.HostName}} closed, {{.Stats.WrittenBytes }} bytes written in {{.Stats.ConnectionDuration}} ({{.Stats.AverageSpeed}}bps)."
      - "notify SSH connection to {{.Host.HostName}} closed, {{.Stats.WrittenBytes }} bytes written in {{.Stats.ConnectionDuration}} ({{.Stats.AverageSpeed}}bps)."

I always get the "{{.SSHConfigPath}} has been rewritten" notification correctly, but I do not get the others at all.
I tested with another server that has a direct ssh connection (so no bastion) and I do get the notifications for that connection consistently.
Any idea what I might be doing wrong?

same issue for me too


[CI] Temporarily disable microtvm demo

A temporary workaround to unblock CI.

See https://github.com/apache/tvm/issues/16963

Closing as the issue with the repository has been resolved.


cleanup(libsinsp): remove unused member from threadinfo

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
This removes an unused member from the threadinfo class.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: therealbobo
Once this PR has been reviewed and has the lgtm label, please assign incertum for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, therealbobo
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 62c8aa45d776defbd9c00320a1aa27d55e256626

/milestone 0.17.0

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, therealbobo
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Merged external modules break protected member access checking

Having some difficulty utilizing the external module augmentations feature merged in #6213. Here is a test case to demonstrate the problem:
// a.ts
export class A {
    protected protected: any;

    public setProtected(val: any) {
        this.protected = val;
    }
}

// b.ts
import {A} from './a'; // Only here to make b.ts an external module

declare module "./a" {
    interface A { }
}

This results in the following error:

a.ts(5,9): error TS2446: Property 'protected' is protected and only accessible through an instance of class 'A'.

It looks like the problem is that checkClassPropertyAccess in checker.ts ends up obtaining the merged interface as the enclosing class of the property access, rather than the actual enclosing class, then tries to ensure that this interface is derived from the class which declares the property, which isn't the case.

this is not specific to module augmentations and can be reproduced with two script files:
// file1.ts
class A {
    protected protected: any;

    public setProtected(val: any) {
        this.protected = val;
    }
}

// file2.ts
interface A { }

@vladima Not sure if this is related, but overrides of protected members are still broken:
// a.ts
export class A {
    protected protected: any;

    protected setProtected(val: any) {
        this.protected = val;
    }
}

// b.ts
import {A} from './a';

declare module "./a" {
    interface A { }
}

export class B extends A {
    protected setProtected() {

    }
}

This results in:

b.ts(7,14): error TS2415: Class 'B' incorrectly extends base class 'A'. Property 'setProtected' is protected but type 'B' is not a class derived from 'A'.

the crux of the problem is the same but in different part of the checker - have a fix for it.

filed #6762 to track it.


backport: bitcoin#18867, #19247, #19222, #18363, #18190, #18393, partial #18047, #18314, #19143 (fuzzing harness backports: part 3)

Depends on

https://github.com/dashpay/dash/pull/4829

utACK for merging via merge commit utACK for merging via merge commit

@PastaPastaPasta Thanks for reviewing. Your response was a little vague though. My only question is, could you let us know if you will utACK this for merging via a merge commit? :trollface:


crop max size

Until version 1.0.5 you ware able to define the max crop size. This was
a good feature we miss in our Project.
With crop(maxWidth, maxHeight) you can define the max crop size. I just
used the same idea from the old implementation.
Signed-off-by: Tinsaye Abye<EMAIL_ADDRESS>

@jerryshew Do you plan to merge this feature in the future? It would be very handy for my project.

I think this is a required PR we need some way to restrict the max height and max width of the cropper.


TsConfig missing for Vue 2

Click on the link but don't see how to fix this tip
how can i fix it?
Vue Language Features (Volar): v1.0.0
Vetur Extended: v0.0.20
vscode: v1.72.0
win11
wsl1

This report message incorrect and fixed in https://github.com/johnsoncodehk/volar/commit/17c50caacb0802462965b5998b12d703c77edff0, you can fix by install @vue/runtime-dom to devDependencies .

It doesn't look fixed

Can you provide me a reproduction demo repo?

Please open new issue if still not working on v1.0.1.

It doesn't look fixed

Please check your node_modules directory to ensure the @vue/runtime-dom package was installed successfully.
For me, the issue is caused by the taobao registry which no longer worked.
I changed the registry to https://registry.npmmirror.com/ and installed the package finally. Then the issue was solved.


proposal: Go 2: allow importing the main function from a main package

Go Programming Experience
Experienced
Other Languages Experience
C, Python
Has this idea, or one like it, been proposed before?
No, not to my knowledge.
Does this affect error handling?
No.
Is this about generics?
No.
Proposal
Currently, using the standard Go compiler, if you try to import a main package you will get this error:

multitool.go:7:2: import "cmd/go" is a program, not an importable package

This proposal is to allow importing of main functions from Go programs under two conditions:

The import of a main package must be qualified with a package name, and
The only exported identifier is Main, which is an alias to the main function inside the main package.

Motivation
The gobusybox project uses a source-to-source transformation step to bundle up many separate package main Go programs into a single monolithic executable. Each individual subprogram can then be separately invoked, whether by being specified as the first command-line argument, or by being invoked through a symlink (with the name of the symlink corresponding to the subprogram to invoke). This can yield significant storage savings, since all the bundled programs in one executable would share a single copy of compiled common code such as the Go runtime, standard library and third party packages. The alternative is to compile each program individually, leading to the duplication of compiled code. These savings can be very meaningful in resource constrained contexts such as embedded systems with limited storage.
Further, there is now a huge ecosystem of Go programs and utilities, and many of them were not written to have any other way of importing and invoking them other than as programs via their main entrypoint, with the os package Args, Environ, Stdout, Stderr, Stdin being the expected process-oriented invocation interface. None the less, it would be incredibly useful to be able to import these existing programs without modification and bundle them into a single monolithic Go executable. There is no guarantee that those programs will "play nice" when invoked under different assumptions, but then there never is when using a third party package.
Example
package main

import (
    "fmt"
    "os"

    gocmd "cmd/go"
    gofmtcmd "cmd/gofmt"
)

var programs = map[string]func(){
    "go":    gocmd.Main,
    "gofmt": gofmtcmd.Main,

    /*
        Include your favourite programs into your Go multi-tool build. Examples:

        golang.org/x/tools/gopls
        github.com/jsha/minica
        k8s.io/kubernetes/cmd/kubectl
        github.com/docker/cli/cmd/docker
    */
}

func main() {
    if args := os.Args; len(args) > 1 {
        var (
            exe      = args[0]
            prog     = args[1]
            progArgs = args[2:]
            newArgs  = append([]string{exe}, progArgs...)
        )

        if mainFunc, ok := programs[prog]; ok {
            // This will not work for programs that `os/exec` themselves as
            // child processes.
            //
            // Use symlinks to the main executable, and dispatch based on name.
            os.Args = newArgs

            mainFunc()
            return
        }

    }

    for name := range programs {
        fmt.Println(name)
    }
}

Language Spec Changes
I could not find any text in The Go Programming Language Specification (as of language version go1.22, dated Feb 6, 2024) that would suggest that main packages MUST NOT be importable. My first question is, is the standard compiler behaviour just an implementation choice, or does that behaviour reflect something that was actually intended to be included in the Language Specification? If the current proposal is therefore not a change to the language but rather the standard compiler, then this proposal should be recategorized.
Assuming that the current behaviour was intended to be included in the Language Specification, and this proposal should be evaluated in the context as being a change to that behaviour, here are the further changes required.
In the section "Program Execution", it states:

When that function [referring to the function main in the package main of a Go program] invocation returns, the program exits. It does not wait for other (non-main) goroutines to complete.

While this statement would remain true for the actual main function of the program, it would not be true for a main that was imported and invoked like a regular function. But this proposed change would not break any existing programs.
In the section "Import declarations", the following addition is suggested:

If the imported package is a program, which is to say the identifier specified in the package clause of the imported package is main, then the ImportSpec must specify a PackageName that is not the blank identifier.

In the section "Exported identifiers", adding a 3rd point to the list:

the identifier is Main and the package clause of the imported package is main, in which case the identifier is a reference to the main function.

Informal Change
In Go, program execution starts by calling your main function inside a package main source file. Currently you are now allowed to import another package main, and even if you could, you would be able to call the main function, since by the rules of exported identifiers the main function does not qualify because of the lowercased starting letter. But since there are so many useful Go programs out there, what if we could get access to their main functions, and bundle their functionality into our own programs? Not all third party programs will work as expected this way (have you ever thought about what it would be like for someone else to call your program main as a function?), but compiling one big monolithic program together might be easier than having to deal with multiple executables.
Is this change backward compatible?
Yes. Since importing a main package is currently not allowed in practise, no valid programs have been doing this. Existing programs would be unaffected.
By aliasing the main function to an exported identifier Main, as a special case behaviour for main packages, the rules around exported identifiers would be unchanged.
The main function from existing programs may not necessarily be well-behaved from the perspective of being imported and called from another. But this situation is no different than importing a third party package and finding that it, for example, calls panic when returning an error would have been more convenient for the caller. It simply may not be convenient or practical to import another program and actually make it useful.
There is no requirement on programs, new or old, to change anything about how they behave or interact with the operating system. It is entirely the callers responsibility to provide a suitable state when calling main (for example, by manipulating os.Args to still be meaningful).
Orthogonality: How does this change interact or overlap with existing features?
I think it's a fairly conservative extension to current practise. Since the import must include an explicit package name, the compiler would still return an error if someone accidentally tried to import an main package without a package name qualifier. The user would have to be quite intentional to access this capability.
Would this change make Go easier or harder to learn, and why?
While I do understand the argument against being able to import another main package, it always struck me as a a bit irregular that the rules around importing main were so different to any other package. A lot of projects put a large amount of code into their main packages, because they are intending to process a program, and not a reusable/importable package. But they still intended to be invokable, as programs, which is very similar in concept to being able to call their main function.
With the rise of a robust module system and wider ecosystem, perhaps this restriction made more sense in an earlier era of Go's development?
But this proposal could lead to unintuitive behaviour for those who use it. Why are other seemingly legitimately exportable identifiers not in fact exported?  What if a program contained both a main and Main function? Only the main function should be exported as Main, otherwise existing programs may be unimportable (i.e. if Main had a different function signature, or if it was not a function at all), but this could be extremely confusing.
Cost Description
I am not aware of anywhere else in Go where an identifier without an uppercase first character can be exported (i.e. main), or where one imported identifier is an alias for another (Main => main). This would require even more special case rules for how the main package is handled.
Changes to Go ToolChain
Entire compiler, from parser to linker, plus any tool that interacts with source code (such as vet, gopls, gofmt and goimports)
Performance Costs
None (to the best of my knowledge!)
Prototype
Work in progress. I'm working this out by first relaxing this error condition and seeing what happens next.

I would humbly submit that this is not a Go 2 proposal, since the current standard compiler behaviour is not actually called for in the Go Programming Language Specification, and even if it was intended to be, this proposal is not a backwards compatibility breaking change to current practise.

Can't we already effectively do that ?
I mean, ok you can't literally do what you are proposing, but you could have the Main function but in it's own non main package and have your program and have both the mega-main and unique main packages both import that.
I imagine something like this:
// cmd/go/go/go.go
package main

import gocmd "cmd/go"

func main() {
 gocmd.Main()
}

The examples you gave would be identical.
That would allows to not complexify the current simple-ish rules around importing main.

I think it is a language change, as it defines new visibility rules for main packages (an alias Main, no other "exported" identifiers actually exported).

I think this may be an unsafe thing to do in general:

main programs may often be written to assume it has full control, e.g. registering global resources in package initialization, just importing the packages can lead to conflict.
#56986 allows main control over //go:debug, but this proposal means the program may run under unintended configurations by default.

While it's true that similar issues can arise with poorly written importable packages, I'd argue that the importable / unimportable separation of intent is important, and for the effort needed to fix those main packages it isn't much more work to move the code into an importable one.

Hi @Jorropo,

Can't we already effectively do that ?

I completely agree! For my own programs I also like to use the structure of a main function in cmd/program/main.go that just calls a single exported identifier from cmd/program/programcmd.
But what about third party programs, and being able to bundle them into a single monolithic binary? If they could be changed to adopt that structure, all the better. But what if that's not possible?
I'd even be happy if there were some kind of compiler-specific mechanism to support this use case:
go build -bundlemain cmd/go -bundlemain cmd/gofmt -bundlemain you/pkg/cmd/program ... multitool.go

... and then some kind of func RunMain(package string) call to actually invoke them. Even if there were lots of further restrictions, such as RunMain will never return to the calling function (so more like an exec style syscall), if that made things easier to implement.

@griesemer ever want to support this, but @rsc denied it.
So the possibility is gone now.
I couldn't find the related issue now.

Hi @seankhliao,

I think it is a language change, as it defines new visibility rules for main packages (an alias Main, no other "exported" identifiers actually exported).

I agree that it is a language change, but I believe it could be backwards compatibility preserving change to Go 1. Maybe I am misunderstanding the meaning of "Go 2" in this context (which I thought would refer to truly breaking changes, such as if I were proposing that the main function should in practise be renamed to Main, which I am most certainly not).
I think it would be helpful to clarify the current intention of the language spec:

Have I simply missed the part where it talks about the non-importability of package main?
Is the non-importability of main something that the language spec intentionally has no opinion about, and hence implementations are free to impose additional restrictions if they wish (as the standard compiler does)?
Setting this proposal aside for the moment, should the spec be updated to explicitly mention the non-importability of main, to align with current practise?

I think this may be an unsafe thing to do in general:

I completely agree! There are zero guarantees that, once your program calls into another main function (if it were possible to do so), that the function will ever return back to the caller, or even if it did, that the system won't be in a very strange state. There are also no guarantees that importing two different main's won't just by themselves have unintended consequence, such as with respect to init execution order and global mutable state.
But those issues would be the callers responsibility to sort through. It would not affect the behaviour of any existing programs.
If an open source project received a bug report about "strange behaviour when importing your main" they could quite fairly say "we don't support that, won't fix".

@pdmccormick The "Go 2" term in issue titles, as well as the v2 label, are to facilitate triage and search. They don't imply that a proposal is not backward compatible.

@pdmccormick The "Go 2" term in issue titles, as well as the v2 label, are to facilitate triage and search. They don't imply that a proposal is not backward compatible.

Thank you for the clarification @zephyrtronium ! I appreciate it.

Thank you all for you input.
Starting from the origin point of the current import "cmd/foo" is a program, not an importable package error message, and searching back through the history, I came across issue #4210 . It looks like in Go pre-1.5, it was possible to import main, as @kevinwallace commented:

I'm currently using this to build busybox-style binaries. Each command's main package exports a reference to its main function, and a wrapper command imports them all and selectively calls one, switching on os.Args[0].

Further comments in the thread refer to solving the newly introduced restriction by reorganizing programs to split between the package main and an importable implementation package.
Later in that thread, @ianlancetaylor commented:

CL 4126053 is a change to the spec, which describes the language. The language permits importing a package named main. That can be used, for example, when writing unit tests for functions in commands that use package main.
This issue here is about the go tool, not the language. The question is whether the go tool should permit packages to import a package that defines a command. The general consensus is that it should not.

CL 4126053 specifically removed a spec-level prohibition against importing a main package. Therefore I would conclude that what I am proposing is actually a behaviour change to the standard compiler, not a language specification change.
Given this, would it be worth creating a new issue proposing some kind of "busybox-style multi-program build" support in the standard compiler? Whether by permitting restricted main imports, or by some other way of invoking another programs main. Would there be any willingness to consider such a proposal, @rsc ?

As you say, this seems to be a reversal of #4210.  The discussion there included the busybox case.  What has changed that we should reconsider that earlier decision?

As you say, this seems to be a reversal of #4210. The discussion there included the busybox case. What has changed that we should reconsider that earlier decision?

The comment in #4210 that first mentioned Busybox-style binaries also mentions that they had the alternative remedy of splitting their main function implementations out into importable packages, which has always been an option when working within a project you have some influence over.
But what about the case of bundling together existing & unmodified third party programs, to share the cost of common code that would otherwise be duplicated across multiple binaries? With the rise of Go-based Linux userlands such as u-root and gokrazy, a Go-based Linux distribution (or embedded system image) could pull together an entire suite of system tools and useful applications with a single go build command.
I probably jumped too quickly to suggesting a specific solution (allow importing main packages again) when really the question I'm grappling with is, could the Go compiler help me in my quest to build multiple programs into a single executable, and offer a Go exec(3)-like mechanism to replace the currently running program with a new one?
At the risk of jumping to solutions again, perhaps something like the combination of allowing import _ "some/pkg/cmd/foo" from main (to pull the contents of some/pkg/cmd/foo into the current program build, and to help ensure that go mod tidy will include referenced packages in go.mod) plus a runtime API such as func ExecProgram(package string, args, environ []string) error to reboot and reinitialize the runtime?

It seems like this proposal hinges on a more philosophical question about the design goals of the language:
Should it be possible for someone to embed someone else's standalone Go program as if it were a library in someone else's Go program without first negotiating an explicit library API with the author of the first program?
Everything else in Go so far seems to have tilted toward giving authors control over their exported API: package symbols can be either exported or unexported, and the internal directory convention allows entire packages to be either exported or not. The language does not offer any explicit means for a caller to override those decisions, although I will concede that there are some seemingly-accidental workarounds available for those willing to depend on implementation details of the Go toolchain.
As an author of one such program that has intentionally not exported any library API, I would say that I would prefer this not to be accepted in the current form. I would not be opposed to an alternative that makes it opt-in for the author of the program being embedded, but I'm not really convinced such a thing is needed because it's already possible for a Go module to offer both a package main entry point and a library endpoint at the same time if an author decides to do so. This proposal seems to be largely motivated by doing something in spite of the author of the program it's being done to, which doesn't seem consistent with the design goals of the language so far.
For the specific use-case of "build something like BusyBox", I would suggest that the author of such a thing ought to design an explicit API through which a Go module can expose one or more entry points with a specified signature, and then encourage authors of programs that would make sense to include in such a bundle to expose those entry points. Not all authors would want to participate in such a thing, but I expect that many would if the argument for it were compelling enough.

Indeed, my concern is that running a program that expects to be in full control of its process as if it were a library inside another process would likely cause it to behave differently in that context, and that those different behaviors would then implicitly become part of the functionality that program is offering and create (possibly undesirable) pressure to keep it working in that context, despite the differences.
If you were able to create an execution environment that is completely indistinguishable from the program being launched directly as a child process then I would not consider that to be problem, but I'm not convinced that the proposal as currently written would guarantee that outcome.
From what you've described in your latest comment, I'm imagining something that is more like a replacement for the Go runtime's startup code, presumably not actually written in Go so that it can run before a Go execution environment is available, which does whatever special logic it needs to decide which of many package main to use, and only then prepares the runtime in the same way that the current implementation does, taking care to ensure that there is no way that the program being launched could observe that it's being launched by that different runtime once it's up and running.
In particular (but not limited to):

The multiple linked programs are unlikely to agree on exactly which version of each dependency they are linking. Therefore the linker and loader would need to tolerate having multiple versions of the same symbol in the program and select the appropriate versions to dynamically link based on which specific program was selected.
(I'm assuming it would be a goal to be able to share the code for dependencies between multiple programs in cases where they do agree, because otherwise this would not have significant advantages over just executing the target programs directly using the facilities provided by the OS, such as exec on Unix systems.)

All of the init functions must run in exactly the same sequence as they would when the program is executed normally, including the implicit init steps that result from assigning an expression to a package-level variable.

No additional Goroutines or OS threads are running compared to what would happen if the program were executed directly.

panic behaves in exactly the same way when not intercepted by a recover, printing exactly the same messages to the same handles and exiting with the same exit code.

I realize that this is quite a pedantic set of requirements and that many programs would not actually be affected by differences here in practice, but nonetheless all of these things could materially affect a specific program's behavior, in ways that the author of that program may not be aware of until it's too late.

@apparentlymart Great points, especially about the need to preserve init execution order.
Keeping with the idea of a program invocation style interface, what about a mechanism for restarting the current Go runtime into a different program? Similar to how an exec(3) syscall replaces the currently running OS level process with a new one. In the runtime package, something like func ExecProgram(package string, args, environ []string) error. The only data you can pass across the call would be values for os.Args and os.Environ (plus OS level process state such as open file descriptors and namespaces).
You raise an excellent point about multiple package versions. If a project opted-in to this kind of arrangement, and split out an importable cmd package for its programs, the module system would have to work out the dependency versioning when combining multiple cmds. There's no guarantee that a program would work with those requirements compared to its own local go.mod. If the compiler needed to build multiple versions of the same packages, the compiled code sharing and executable size savings start to go out the window, so why bother with any of this.
Assuming that the bundled programs would still function correctly when their package requirements were resolved together, specifying the programs to bundle could be provided as flags to go build:
go build -bundle pkg1/cmd/foo -bundle pkg2/cmd/bar ./cmd/gopherbox/

In this program, pkg1/cmd/foo, pkg2/cmd/bar and main could be passed to ExecProgram.
Alternatively, at the risk of circling back to this topic, maybe a special case of main importing could be permitted, not for initializing side effects but just to declare that it should be bundled into the given build:
package main

import (
	"os"
	"runtime"
	_ "cmd/go"
)

func main() { runtime.ExecProgram("cmd/go", os.Args, os.Environ()) }

This is introducing an irregularity to how imports are to be treated, and that may require a change to the Language Specification (although, as I have learned in this process, the Go language spec does not actually disallow main imports, just the standard compiler). At least this way go mod tidy and tooling would be aware of the dependencies.

Note that at least on Unix systems we do have https://pkg.go.dev/syscall#Exec .

Note that at least on Unix systems we do have https://pkg.go.dev/syscall#Exec .

If I'm not mistaken, the Go runtime does not currently have a notion of multiple main entrypoints within a single executable, or does it have something along those lines?

No, it does not.  It always starts at main.main.  Perhaps I misunderstood the suggestion.

No, it does not. It always starts at main.main. Perhaps I misunderstood the suggestion.

I'm sorry for jumping around with ideas in this thread, but thank you for engaging with the ideas.
To summarize, I'm wondering if it would be possible to enable:

go build to include multiple program entrypoints, and
Give programs the ability to teardown the current Go runtime and restart it back up again fresh but from a different entrypoint (and with new argv/envv)

So a Go runtime level exec call, if you will, all from within the same executable and same running process.

I think I get what you're thinking about here, and maybe the following set of analogies would both allow you to confirm whether I've understood correctly, and if so help others in this thread reach a similar point of understanding.

kexec is a Linux kernel system call that effectively makes Linux behave as a bootloader for another version of itself, effectively replacing the running kernel with a new kernel but without the overhead of rebooting the computer. The intent is that nothing about the original kernel survives, and the new kernel believes it was booted normally.

exec is a system call on many Unix-derived systems that effectively replaces the current process memory image with a new process image and begins executing it. The intent is that nothing about the original process image survives, and the new program believes it was started normally. (In this case, it was started normally, because exec is the normal way of starting programs!)

The evolved form of this proposal (now quite different than the original writeup) is a Go runtime function runtime.ExecProgram that replaces the running Go program with another Go program that was somehow linked into the same executable image as the caller, with the new program believing it was launched directly.
However, this new idea differs from the previous one by promising that if two of the programs linked into the same executable agree on a particular dependency version then that dependency will be included in the executable only once, as an executable file size optimization. So it's a sort of Go-specific exec that allows the target program(s) to be bundled inside the same executable.
Presumably that means that this new runtime function is subsuming some of the responsibilities that would normally be handled by the linker at build time, since it'll need to decide what to map into memory and fix up calls between packages at runtime instead of at build time.

(I'm intending this comment only as an attempt to confirm that I'm understanding the new proposal correctly, not as any specific opinion on the new proposal.)

In terms of a concrete example for this Busybox-style multitool executable, and possible storage savings:
Two Docker plugins that are typically installed together are buildx and compose (I have no affiliation with Docker). When I build each of these, the binaries are 77 MiB and 75 MiB respectively. Next, I have locally modified each of these projects to move the contents of their primary main.main into an importable subpackage, github.com/docker/buildx/cmd/buildx/buildxcmd and github.com/docker/compose/v2/cmd/composecmd. Then, in a new program I have imported both of these, and dispatch to each depending on the contents of os.Args[0]. Finally, after compiling, I created symlinks, buildx => multitool and compose => multitool, which I use to invoke the specific program. This resultant binary is only 80 MiB, for a savings of 72 MiB compared to two separate executables.
This might be a bad idea for other reasons as discussed above, but it's basically those savings that I am chasing. I will be trying to see if the authors of the particular programs relevant to me would be willing to accept that kind of main/cmd split, but the motivation for this entire proposal was, could this be supported in the toolchain itself, to allow bundling together collections of Go programs into single executables.

I think I get what you're thinking about here, and maybe the following set of analogies would both allow you to confirm whether I've understood correctly, and if so help others in this thread reach a similar point of understanding.

Yes, you've understood me perfectly, thank you!
And you're absolutely right, the discussion has moved on quite a bit from the original proposal. I am happy to withdraw it, or have it withdrawn by someone else, if that is the appropriate course of action for this process?

Presumably that means that this new runtime function is subsuming some of the responsibilities that would normally be handled by the linker at build time, since it'll need to decide what to map into memory and fix up calls between packages at runtime instead of at build time.

This is a great point: if any kind of runtime patching would be required to switch between programs then I'm definitely thinking that this is starting to seem like a bad idea.
If the results were not the equivalent to what I did in my Docker example above, existing programs which are modified to explicitly opt-in by adding a boilerplate main/importable cmd split, and then having those program packages pulled into a new program as dependencies, if it would not be possible to get some level of compiler support for achieving that without the boilerplate, with the least possible changes to anything else in the ecosystem or runtime, then I think this idea should be abandoned.

Importing main packages was in the distant past permitted, but the tools were changed to disallow it, and the rationale for that change applies to this proposal too.
Therefore, this is a likely decline. Leaving open for four weeks for final comments.
— adonovan for the language proposal review group

No further comments.


Add compiler configuration

With an error-format specification which attempts to extract the appropriate information out of a standard gleam error message.
This the standard way to populate the quickfix list to make it easer to navigate between them with standard shortcuts.
Initially based on the rust vim compiler file:
  https://github.com/rust-lang/rust.vim/blob/master/compiler/rustc.vim

Though I'm not sure how much we need to bring across.

What a cool idea! Could you share how this is used?
The CLI output is not a reliable API as it will change. We could add a fixed format for this, one that is easier to parse.

So it ties into the vim :make functionality. I've got a personal .vim/ftplugin/gleam.vim file with:
" Gleam Specific
" --------------

" Only do this when not done yet for this buffer
if exists("b:did_ftplugin")
  finish
endif

compiler gleam
map <leader>m :make build .<CR>

This tells vim to use the gleam compiler configuration which I guess gets it to go and source the compiler/gleam.vim file in this PR. This file sets it so that when I run :make build . it runs gleam build . and then it uses the error format we've specified by setting efm to parse the error messages from gleam and populate the quickfix list with files, lines, columns and error messages and allows you to jump to the first error with :cc and to the last/next one with :cp/:cn. It actually jumps to the first error automatically which is nice.
Writing this I imagine that it would be a little clearer to use 'errorformatinstead of the short handefm. it is possible that it would also be better with setlocalinstead ofset`. I am not a vim expert :/
The errorformat string is like a little (horrible) parsing language and so, yeah, it'll have to be changed if the error format changes. I've also not tested the functionality on a situation with more than one error. I'm very new to gleam and couldn't find a combination of mistakes that would create more than one error. That said, writing this, I realise I could have made mistakes in multiple different files and seen how that was handled.

I'm very new to gleam and couldn't find a combination of mistakes that would create more than one error.

At present we only return a single error.
Thank you for the detail! Would you mind adding some comments to the file to that effect as I'm likely going to forget and get confused later 😅

Understandable. It is certainly a dark corner of things. Best to document it as well as possible.

No trouble. Thanks for being so quick :)


Waveform is only display after zooming

I have a wav file played with wavesurfer. When I try to play it I can hear the file but the waveform is not displayed.

It only appears after I change the zoom.

Any ideas why is this happening?

@lararogu are you using the latest version?

Yes,I have the latest version of the code. I dont understand because the file seems to be loaded fine because I hear it but the waveform is not displayed until I change the zoom.

@lararogu can you try the following sample I have created here,
http://codepen.io/entonbiba/pen/xgmqmv

I fixed the problem.It was not a problem of the wavesurfer. I have the container for the waveform inside a modal that appears when I click a button and I was making it visible after I loaded the audio file,that is why it was not appearing immediately.


Switch from Travis CI to GitHub Actions

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

I assume you're probably not blocking on me to review this, but in any case seems fine :)


e2e tests compiled with different tsconfig.json

We want to build rich suite of e2e tests leveraging async/await feature of TypeScript which is only available for ES2015+ target
To do that we need separate tsconfig.json used for building e2e specs. But it's currently not seem to possible with the current seed structure.
Do you have plans to address this problem in the near future? Can you share your thoughts how would you implement that? We probably will be able to contribute that back to the seed project

@VladimirMakaev That sounds exciting and fun.
You could take a look here:
Instead of using the makeTsProject function https://github.com/NathanWalker/angular-seed-advanced/blob/master/tools/tasks/seed/build.js.e2e.ts#L16, you could export a new function that uses a different tsconfig.json specified here https://github.com/NathanWalker/angular-seed-advanced/blob/master/tools/utils/seed/tsproject.ts#L21 which you could put anywhere you see fit, but likely inside tools might make sense as it would be a custom config used only by e2e specs for instance.

@NathanWalker Thanks for your suggestion.
I was thinking about reusing makeTsProject. I can extend it to add optional argument of projectName which could be tsconfig.json by default.
Another thing is that for VSCode to properly recognize another tsconfig.json we need to move e2e-specs outside of src/client folder. (E.g. src/e2e). I would move all e2e specific framework stuff (e.g. e2e/dropdown.ts) there as well
Let me know your thoughts on this

On master now 👍


Patch 6

@Rajani-Janaki-Ram : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Subspaced Saga - React to global action

Is it a bug, feature request or question?
Question
Which package(s) does this involve?
redux-subspace-saga
Input Code
Subspaced saga:
function* doThings() {
 // not firing
}

export default function* rootSaga() {
    yield all([
        takeEvery(GLOBAL_ACTION, doThings),

Root saga:
export default function* rootSaga() {
   call(subspaced(state=>state.a, "mySubspace")(selector)),
}

Expected Behavior
I would like to catch actions fired in the global space.
Current Behavior
Subspaced saga reacts only to namespaced actions.
Possible Solution
Maybe there is a way to do that. Of course I can takeEvery(GLOBAL_ACTION); in global saga and re-yield them as namespaced.

All namespace boundaries (whether they be for reducers, sagas or anything else) are supposed to process any relevantly namespaced actions and global actions.
How are you dispatching the global action? As a plain action into the global store or using the globalAction utility/globalActions middleware?

I'm just dispatching plain action but I'll try with the globalAction utility, thanks!

Yeah, that would explain it. Let me know how you go.

It works


Issue on a dependency - CVE-2023-26136

Hi,
Good day.
Just wanted to inform that we encountered a security issue on one of request-promise dependency for its version 4.2.6:
Dependency: tough-cookie
Version: 2.5.0
It is raised under this CVE ID:  CVE-2023-26136
If this was already discussed and resolution was already delivered. Let us know.
Thank you.

Hi, As this package has been deprecated. We decided to just migrate to an alternative. Closing this now.


Test redux

Waiting on reconnect issue #10 to merge

Will be pulling this in with the reconnect branch #10 #92


Do not raise if Docker image cannot be pulled

Only emit a warning if Docker image is not found on Dockerhub.
This is useful for Docker images built locally, so that we do not always have to type "--no-pull"
when running aiidalab-launch start
Closes #153
I verifies locally that things still work as expected.

The current logic in this PR is

Try to download the image.
If the download fails, print the warning, and use the local image.
If download fails and there is no local image, raise the error and exit.
This happens in main.py

Dne pá 25. 11. 2022 7:31 odp. uživatel Jusong Yu @.***>
napsal:

@.**** commented on this pull request.
In aiidalab_launch/instance.py
https://github.com/aiidalab/aiidalab-launch/pull/159#discussion_r1032661174
:

       LOGGER.warn(f"Unable to pull image: {self.profile.image}")

       return None

Why it cannot be raised?
—
Reply to this email directly, view it on GitHub
https://github.com/aiidalab/aiidalab-launch/pull/159#pullrequestreview-1194730821,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACIY64K2HEBEIUZ2IF6KQPDWKEHZVANCNFSM6AAAAAASIMAWCU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Okay, thanks for the explanation, clear to me.


fix: import guid context var from context module

This fixes two problems:

Some tools complain that django_guid.middleware do not export guid symbol
Importing from django_guid.middleware requires Django to be initialized. Importing from django_guid.context does not. This is useful to add the CorrelationId to Gunicorn access logs.

Thanks!  😊
What tool, if I may ask?

Thanks! 😊 What tool, if I may ask?

VSCode/pylance/pyright, for instance, emit a reportPrivateImportUsage


Delete form

iIf yo ucan take a look and fix the DELETE endpoint that would be great @theodormoroianu


[web3t] Run e2e test against deployed apps

converts e2e tests for w3t to read in target app url via new env var
new circle job e2e-test-w3t-production

only runs on deploy branch, and after apps have been redeployed
does not start any servers of its own
runs e2e tests (headful, dappeteer enabled) against specified environment (assumes servers are running)

Closes #1620 .
Tested against this branch (temporarily). Test runs and fails due to known issues.

Is there any way we can produce some sort of "report" with referenced transaction IDs somewhere? i.e., etherscan links, maybe in the CI artifacts, that I can click on to view successful transactions?

@snario I'm sure something like that would be possible. For what purposes would you want to see that? Debugging?


hack classes not grouped at hacks (placed in general)

our only hack ._min-flex-wrapper also has a typo on example.

closed by 7bb19bd


Allow disabling the default gopass create wizard templates

Currently, the two default wizard templates for gopass create ("Website login" & "PIN Code (numerical)") seem to always load in as options for the wizard.
It would be nice to have a config option to turn this off so that only custom templates appear as options in that wizard menu. I particularly want this because both stock templates are marked "priority: 0", which forces you to use negative priority values in custom templates if you want them to appear first in the list (important if you want to change the default option).

Sounds like a valid feature request. But we'll need to figure out how to handle this cleanly.

Would you prefer to configure this per password store or per user?


wkhtmltopdf: cannot connect to X server

Hi here
This is working Ok from console Centos 6.x:
wkhtmltopdf --print-media-type --use-xserver --quiet www.google.com ~/google.pdf

But when working from pdfkit v0.5.3 gem in RoR v3.2.1
RuntimeError (command failed: "/usr/local/bin/wkhtmltopdf" "--print-media-type" "--use-xserver" "--quiet" "-" "-"

And Apache error:
wkhtmltopdf: cannot connect to X server

We're using Xvfb as Xserver

I'm sorry that this is an incredibly old thread, but I've been trying to overcome the same error. On Red Hat (64-bit). wkhtmltopdf: cannot connect to X server No matter what I do. Ive installed via the steps above and have installed via sudo yum, both success. But when running the wkhtmltopdf command, it shoots out that error message.

I think I've figured it out need to have xorg-x11-server-Xvfb installed for Redhat. I'll continue to see if everything else functions as normal.

wget http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.9.9-static-amd64.tar.bz2
--2017-12-06 19:23:04--  http://wkhtmltopdf.googlecode.com/files/wkhtmltopdf-0.9.9-static-amd64.tar.bz2
Resolving wkhtmltopdf.googlecode.com (wkhtmltopdf.googlecode.com)... 2607:f8b0:400e:c00::52, <IP_ADDRESS>
Connecting to wkhtmltopdf.googlecode.com (wkhtmltopdf.googlecode.com)|2607:f8b0:400e:c00::52|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-12-06 19:23:04 ERROR 404: Not Found.


setMax / getMax unavailable

The methods setMax and getMax are unavailable when adding this library to the project remotely using Gradle. I had to download a zip of the master and add the library manually as a module dependency to access these methods.

Those guys were added after the 1.1 release, so to pick them up you'd just need to change your Jitpack coordinates to look like:
compile 'com.github.Triggertrap:SeekArc:83ecbbd'

You can leave your dependency locked to that commit for now, and then move it once the next release happens.

Tried that but when it sync gives a Failed to resolve error. From 1.1 works fine though.

use longer commit id like this:
compile 'com.github.Triggertrap:SeekArc:83ecbbd5be'

This worked for me:
compile 'com.github.neild001:SeekArc:83ecbbd5be9b9ae5780dc6d78cf952001091a6fb'

How do i Use the setMax method in MainActivity.java?
I have build the gradle using
compile 'com.github.neild001:SeekArc:83ecbbd5be9b9ae5780dc6d78cf952001091a6fb'
but the setMax method is still unavailable?
Any help guys please


sed and echo not working as intended.

Thank you for this script, it is exactly what I needed.  However, these lines do not seem to be working as intended:
https://github.com/theGeeBee/DocumentServerOnFreeBSD/blob/3302a0a507bd1d61ad11a82f1132383e3e723c2d/install.sh#L81-L82
The sed line adds an [include] at the beginning of uncommented lines, replacing the first letter.  The echo doesn't seem to go anywhere.  I'm not sure what either of these are supposed to do.  Please let me know what the intention is so I can try some fixes.  Thank you.

Hi,
I've actually been out of action for a while.
I just pushed the latest commit which makes more sense of what you just pointed out.
Try the latest now.

Thank you.  QUite a bit has changed so this issues no longer applies.  I'm trying the new script now.


Backup won't run after running utility

I had the same problem as everyone else after reverting from Win 10 pro 64 bit back to win 7 ultimate 64 bit.  The utility seemed to restore all my tasks, but when I attempted to run a backup I got an error as follows "Windows backup failed while determining libraries location of one of the users included in backup.
Details: The filename, directory name, or volume label syntax is incorrect. error code 0x81000031"
Any ideas to fix this. Thanks!
Attachments
2016-04-04_1843.png
This work item was migrated from CodePlex
CodePlex work item ID: '2'
Vote count: '1'

[Dijji@30/04/2016]
Sorry about the lack of response, I don’t seem to get notified when an issue is raised. Discussions work better for problems of this sort.
This is not an uncommon problem, and relates to inaccessible folders being included as part of the library. Select the library in Windows Explorer, right click and choose properties. You should see a list of the folders included in the library. The chances are that one or more of them is not reachable.
Dijji


Bug: losing all peers with peer switch stopped error

CometBFT peer issue
Bug Report
For the last two months, nodes on Osmosis are frequently halting with:
ERR Won’t start a peer – switch is not running module=p2p peer={“Data”:{}, “Logger”:{}}

(presumably coming from: https://github.com/cometbft/cometbft/blob/877b0629578c7695dec77b16cf0021563e060d82/p2p/switch.go#L817-L821C3 )
Validators are saying that they are having issues such as:
We have a working node, that then stops progressing and faces the same error every 2hrs. Node is getting stuck connecting to peers.
Updating live peers and restarting is working, but have to keep doing it often to keep the node alive.

Setup
CometBFT version Tendermint v0.44.22
Have you tried the latest version: no (trying to upgrade to it, working through some SDK dependency issues)
ABCI app: Osmosis
Environment:

OS (e.g. from /etc/os-release): Ubuntu 20.04
Install tools:
Others:

node command runtime flags:
Config
https://pastebin.com/Xs6nKUku
What happened?
Nodes halt frequently facing peer issues. They appear to be working fine with peers prior to this halt point. They halt with the error previously explained.
Some interestings notes:

Validators / node operators seem to experience it together (i.e. for an unknown reason, the last couple days validators / node operators have not experienced the issue)
I have not experienced this issue on our testnet despite utilizing the same binary

What did you expect to happen?
Node to continue running.
How to reproduce it
Run a node on mainnet Osmosis (I have been told it happens on other networks as well, but can not personally confirm).
The current "fix" is to continuously restart the node at regular intervals to prevent this error, which is not ideal.
Logs
ERR Won’t start a peer – switch is not running module=p2p peer={“Data”:{}, “Logger”:{}}

dump_consensus_state output
Not a consensus bug

Hi, can you provide a full log of the problematic node for our analysis? The error is very likely produced where you pointed out, but I couldn't understand why the Switch would not be running (i.e., why it was stopped) on the reported situation.
Moreover, can you confirm the adopted CometBFT/Tendermin version?

another useful information that might be helpful for troubleshooting is the P2P configuration under:
#######################################################
###           P2P Configuration Options             ###
#######################################################
[p2p]

in the /.osmosis/config/config.toml file

It was not possible to further investigate this issue because we couldn't caught the exact instant where this has happened (on logs or other monitoring interfaces).
Having said so, the issue was not observed once the operators had reduced the maximum inbound and outbound peers parameters. The suspect is that the Switch was overloaded, due to an excessive number of concurrent peers, causing it to be somehow "killed". This is not really expected, but it could happen in an overloaded process, leading the node to crash.


"UP" key doesn't show UI on bash

Hello,
I have the (wonderful) UI chen I use ctrl+R, but not when I use the up key. According to the readme : "rebind up and ctrl-r with a full screen history search UI"
How can I make sure the "up" key has the same UI that ctrl+r ?
Thanks in advance

This was fixed by #445 but that hasn't made it into a release yet. The PR also fixed an issue where typed text wasn't populated when pressing up. Until a new release is cut, you could download https://github.com/ellie/atuin/blob/main/src/shell/atuin.bash and instead of running eval "$(atuin init bash)" in your shell profile, you could source that init script directly.

Perfect, thanks a lot !


Fix that "Allowed Scopes" and "Allowed Grant Types" cannot be displayed properly in Client Basics when published as an application

Hello, I am very glad that you have developed this system. I think it is perfect to improve it here
change
<picker id="AllowedScopesItems" multiple-select="true" min-search-text="2"
<EMAIL_ADDRESS>url="/Configuration/SearchScopes?scope"
        search-input-placeholder="Enter 2 and more characters" selected-items-title="Selected: ">
</picker>

to
<picker id="AllowedScopesItems" multiple-select="true" min-search-text="2"
<EMAIL_ADDRESS>url="@Url.Action("SearchScopes","Configuration")?scope"
        search-input-placeholder="Enter 2 and more characters" selected-items-title="Selected: ">
</picker>

NOT PERFECT: url="/Configuration/SearchScopes?scope"
PERFECT: url="@Url.Action("SearchScopes","Configuration")?scope"
There are a few other places I didn't list

Hello @RiccoYuan
Nice! 👍 I will change it in other places.
If you have any other suggestions, please let me know. :)
Thank you.


bug: Neovim disconnected frequently in jupyter notebook file.

Check the following:

[X] I have checked the behavior after setting "vscode-neovim.neovimClean" in VSCode settings.
[X] I have read the vscode-neovim docs.
[X] I have searched existing issues.

Neovim version (nvim -v)
0.10.0
Operating system/version
MacOS 14.5
Describe the bug
Neovim disconnected frequently in jupyter notebook file.
Steps To Reproduce

open a Jupyter notebook file and wait. (might need a medium size file)

Expected Behavior
Not disconnected.

Probably related to #2000. Does it persist if you downgrade to 0.95?

Duplicate of #2000


Passing spark-defaults.conf values as part of spring cloud task modules

From @rejurs on April 29, 2016 20:9
Hi Team,
Could you please help me to pass the spark-defaults.conf values when we are running java -jar sparkapp-yarn/target/sparkapp-yarn-task-1.0.0.BUILD-SNAPSHOT-exec.jar.
Copied from original issue: spring-cloud/spring-cloud-task-modules#36

@sabbyanandan : Is this resolved? / Is there any timeline ? / Ami I making any mistake? Could you please update me.

This issue was moved to spring-cloud-task-app-starters/spark-yarn#1


subscription ListComplete() returns inconsistent results

Bug Report

import path .../services/preview/subscription/mgmt/2019-10-01-preview/subscription
SDK version: v45.0.0
go version: go1.14.6 darwin/amd64

What happened?
When retrieving a list of subscriptions for a given tenant, occasionally the first run returns no results and no errors, but subsequent runs all return the correct subscriptions.
What did you expect or want to happen?
The results would be consistent regardless if it was the first run or not.
How can we reproduce it?
It's hard to reproduce.  Usually only happens for the first run of the day, or late after work.  Our guess is this might be some sort of cache miss for cold data not being handled correctly.
Anything we should know about your environment.
We use a an app principal to authenticate into the tenant to query the subscriptions.

type Subscription struct {
	DisplayName    string `json:"displayName"`
	SubscriptionID string `json:"subscriptionID"`
	State          string `json:"state"`
}

azureAuth, err := auth.NewClientCredentialsConfig(APPID, APPSecret, TenantID).Authorizer()
	if err != nil {
		fmt.Println(err)
	}

client := subscription.NewSubscriptionsClient()
client.Authorizer = azureAuth

subs := []Subscription{}

for iter, err := client.ListComplete(context.Background()); iter.NotDone(); err = iter.Next() {
	if err != nil {
		fmt.Println(err)
	}

	sub := Subscription{
		DisplayName:    *iter.Value().DisplayName,
		SubscriptionID: *iter.Value().SubscriptionID,
		State:          string(iter.Value().State),
	}
	subs = append(subs, sub)
}

fmt.Println(subs)

Following up.

Routing this to ARM and removing Subscription tag

Routing this to ARM and removing Subscription tag

@anuragdalmia Any update?

the RP here is Microsoft.Subscription


Realm Crash: Opening Realm files of format version 5 is not supported by this version of Realm

Bugs:
We are seeing crashes reported with the following message:
Opening Realm files of format version 5 is not supported by this version of Realm
This is occurring after we updated from Realm v5.3.5 to v5.4.2
Expected Results
Realm file format updates without crashing.
Actual Results
It appears that Realm upgrading/backwards compatibility is failing.
Fatal Exception: RLMException
Opening Realm files of format version 5 is not supported by this version of Realm
Fatal Exception: RLMException
0  CoreFoundation                 0x19f451114 __exceptionPreprocess
1  libobjc.A.dylib                0x1b2c77cb4 objc_exception_throw
2  Realm                          0x1043fb008 RLMSetErrorOrThrow(NSError*, NSError* __autoreleasing*) + 366 (RLMUtil.mm:366)
3  Realm                          0x1043cfd28 RLMRealmTranslateException(NSError* __autoreleasing*) + 394 (RLMRealm.mm:394)
4  Realm                          0x1043d0e8c translateSharedGroupOpenException(NSError* __autoreleasing*) + 421 (RLMRealm.mm:421)
5  Realm                          0x1043d0ddc +[RLMRealm realmWithConfiguration:queue:error:] + 509 (RLMRealm.mm:509)
6  Realm                          0x1043cffc4 +[RLMRealm realmWithConfiguration:error:] + 426 (RLMRealm.mm:426)
7  myApp        0x105e1b09c +[MyAppRealm getRealmByName:] + 29 (MyAppRealmRealm.m:29)
Version of Realm and Tooling
Realm framework version: 5.4.2
Xcode version: 12.0
iOS/OSX version: 14.0
Dependency manager + version: Cocoapods 1.9.3

@jmschindele Would you be able to send us the Realm file that reproduces this error?

@leemaguire I'm unable to include the Realm file as this is a production issue that is being reported via crashlytics.
I have found that we are getting an error mentioning version 11 as well:
Fatal Exception: RLMException
Opening Realm files of format version 11 is not supported by this version of Realm

5.4.0 and above generates a v11 Realm file file format, which is not backward compatible with anything less than 5.4.0. It's unusual you are getting 'version 5 is incompatible' do you have any more stack traces that we could take a look at?

@leemaguire I have the following, which yields the v11 error but is otherwise identical:
Fatal Exception: RLMException
Opening Realm Files of format version 11 is not supported by this version of Realm
0  CoreFoundation                 0x19e9b5114 __exceptionPreprocess
1  libobjc.A.dylib                0x1b21dbcb4 objc_exception_throw
2  Realm                          0x1015c0398 RLMSetErrorOrThrow(NSError*, NSError* __autoreleasing*) + 366 (RLMUtil.mm:366)
3  Realm                          0x101594eb8 RLMRealmTranslateException(NSError* __autoreleasing*) + 394 (RLMRealm.mm:394)
4  Realm                          0x101596028 translateSharedGroupOpenException(NSError* __autoreleasing*) + 421 (RLMRealm.mm:421)
5  Realm                          0x101595f7c +[RLMRealm realmWithConfiguration:queue:error:] + 509 (RLMRealm.mm:509)
6  Realm                          0x101595154 +[RLMRealm realmWithConfiguration:error:] + 426 (RLMRealm.mm:426)
7 myApp        0x102ffab68 +[MyAppRealm getRealmByName:] + 29 (MyAppRealm.m:29)
We are also seeing quite a few instances of this stack:
Fatal Exception: RLMException
File corrupted by previous upgrade attempt
0  CoreFoundation                 0x189b17654 __exceptionPreprocess
1  libobjc.A.dylib                0x189839bcc objc_exception_throw
2  Realm                          0x103b48398 RLMSetErrorOrThrow(NSError*, NSError* __autoreleasing*) + 366 (RLMUtil.mm:366)
3  Realm                          0x103b1ccbc RLMRealmTranslateException(NSError* __autoreleasing*) + 411 (RLMRealm.mm:411)
4  Realm                          0x103b1e028 translateSharedGroupOpenException(NSError* __autoreleasing*) + 421 (RLMRealm.mm:421)
5  Realm                          0x103b1df7c +[RLMRealm realmWithConfiguration:queue:error:] + 509 (RLMRealm.mm:509)
6  Realm                          0x103b1d154 +[RLMRealm realmWithConfiguration:error:] + 426 (RLMRealm.mm:426)
7  myApp         0x105582b68 +[MyAppRealm getRealmByName:] + 29 (MyAppRealm.m:29)

@jmschindele Would you be able to update to version 5.4.4 as it includes quite a few fixes to the underlying Core library. Unfortunately for corrupted Realms there is not much that can be done to save them unless they were synced.


Themes

The insights pane should follow the selected Outlook theme.  eg: Dark mode.

Hi Derek,
I've relayed your comment to the MyAnalytics team. I'll let you know if I find out about adjusting the theme for the Insights panel.
Thank you,
-- paul9955

Hello again Derek,
You're right that the Insights panel does not currently recognize and adhere to the Outlook theme. I've let the team know of this as a customer request. I cannot estimate a date for a corresponding product enhancement but if I find out that it's happening, I'll replay here to let you know.
Thank you for letting us know about this concern!  - paul9955

This would be awesome, was just going to post the same suggestion.
Now when Outlook on Mac have dark mode everywhere, even on the reading pane, it looks off to have an add-on on the right side with white color.


3.1.0

v 3.1.0
Checklist

[x] I checked the Contributing Guidelines before creating this request.
[x] New extensions are written in Swift 3.
[x] New extensions support iOS 8.0+ / tvOS 9.0+ / macOS 10.10+ / watchOS 2.0+.
[x] I have added tests for new extensions, and they passed.
[x] All extensions have a clear comments explaining their functionality, all parameters and return type in English.
[x] All extensions are declared as public.

This PR fixes #187, #188 and #205

We should probably throw deprecated extensions in their own folder and then tell CodeCov to ignore it. This way we don't reduce test coverage percentage and can still be user-friendly.

@SD10 Sure, let me do this


[FEATURE] Footer

Description
how about adding a footer to the website with the application name and the same links that are in the navbar.
Screenshots
No response
Additional information
No response
🥦 Browser
Google Chrome
👀 Have you checked for similar open issues?

[X] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

[X] I have read the Contributing Guidelines

Are you willing to work on this issue ?
Yes I am willing to submit a PR!

i can work on this if it gets approved:)

Yeah, so i was thinking maybe we can add logo and the 4 links that are in the navbar to the footer. Also there is no link to the github of the project so we can also add that in the footer along with other links(instagram,twitter,etc.). What do you think about this?

There's already a designed footer in the repo. What things do you want to change in this?

@rohinish404 Let the report button stay as it is

The left side can be minimised ,to We are an Opensource product, feel free to contribute and then add the Gh link
At the end, center we can add something like (replace with Milan) :

okay..so i made few changes. How's it's looking?

How about centering the join us column so that it appears directly above the links?
And should i make the background white?

How about centering the join us column so that it appears directly above the links? And should i make the background white?

Yep the centering is needed, make a PR too, we can review that way easily !
Also i think the dark BG is good so that people knows that this is a footer !

Yeah sure!! I'll make a pr after centering that portion:)


set experiment to finished if there are no answers to rate for

Noone will ever get notified for a empty experiment, and noone will ever finish a empty experiment. so do it when calling creative-stopp.

creative stopped means that nobody can submit new answers anymore. There can still be ratings/answers pending. Ignore the pending answers and put a TODO there, this is an issue that can only resolved with a slight db update (scheduled for today or tomorrow). We still have to wait 2 hours if there are ratings pending.

Wee need to solve this problem more genericly, this is a issue here and for the ratings.


Added a job board for frontend remote jobs

I've added a job board search website for frontend remote jobs in the /Frontend-Development/Job-Boards folder while keeping the alphabetical order of the folder unchanged. This is in reference to issue #77  which I've closed by mistake.

Thanks for the review and feedback.


Line chart:  hovering and selecting improvements

[x] Hovering over a line should highlight data on other viewers (basically implement  for a line hovering over a group)
[x] Implement Ctrl+click, Shift +click, and Ctrl+Shift +click selection toggling actions for lines
[ ] If feasible, indicate a line selection with color or highlighting

Can't cancel the Ctrl+click action result

DG 1.17.0


Make team id strings, allow to specify id on creation

Fixes #247
I have a question: how should the app behave if on creation is specified an id that already exists on the db?
At the moment we just return 500 bad implementation due to the db constraint, my feeling is that we should manage the error and return the proper status code and message.
@p16 how did you implement this on the users?
@feugy thoughts?

@paolochiodi

how did you implement this on the users?

As of now 500, as per db constraint. Nothing more.


DialogHost background color is transparent

3.0.0 release,The DialogHost  background color is transparent！

Can confirm this is happening in the latest nightly release.

This is probably DialogHost bug due to colors name change. I'll take a look.


[BEAM-11859] Fixed bug in python S3 IO

Fixed missing parenthesis which causes an error to be thrown when using S3IO writer.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @pabloem

fyi @AldairCoronel

thanks for the PR @nirga - LGTM


Fixes and Additions

Hello,
I have found your list searching for some applications - excellent work and thank you for providing it!
Here are some fixes:

Coda2 is a a web-developement IDE and not really a general purpose text editor. It probably should be under "Web Development Tools".

Here are some suggestions for additions:

Rider is a non-free, non-opensource cross-platform C# IDE from Jetbrains - it is an alternative to Visual Studio by Microsoft with the additional benefit of getting Resharper features that are not available on Visual Studio for Mac.
Expressions is non-free, non-opensource regular expression checker. It has a nice interface and it can dissect a regex.
Navicat is a non-free, non-opensource database editor that supports very many databases. It is a large program that has become more of a database IDE due to the very many features.
JavE is a free and opensource ASCII text editor with very many features.

I highly recommend GrandPerspective in "System Related Tools" - it is an open-source and free (beautiful and beautifully simple!) application that can analyze any folder and display files as clusters of blocks depending on the file size.
Under "Game Emulation" you probably would like to add Wineskin - it is a wrapper for wine and can be used to run Windows games as well as create self-standing applications.
If useful, please add! (ﾉ◕ヮ◕)ﾉ*:･ﾟ✧

@evacomaroski Coda in the IDE category.

Added Rider from list above in PR #488


$ prefix signs shouldn't be inserted before example outputs in terminal examples

Describe the bug
The expected outputs in our bash code block examples in docs aren't rendered properly. Unnecessary $ characters are being added.
To Reproduce
Currently, the $ character is being inserted before every line of code in our docs' terminal examples (screenshot from basics.md below.

What's interesting, when running yarn run start from my local machine, the $ characters seem to be completely missing.

Expected behaviour
$ characters should only be inserted before non-output (uncommented) lines in bash code blocks in our docs.

@romanowski suggested we rely on the ChainedSnippets UI component, which is used in the Getting Started guide.
Looks like that'd solve the issue.


[shared_preferences]Remove null check assert of a non-null value

Fix the issue #99145
pana result
Before
## ✗ Pass static analysis (20 / 30)
### [~] 20/30 points: code has no errors, warnings, lints, or formatting issues

<details>
<summary>
INFO: The operand can't be null, so the condition is always true.
</summary>

`lib/shared_preferences.dart:165:23`

    ╷
165 │     assert(fromSystem != null);
    │                       ^^^^^^^
    ╵

To reproduce make sure you are using the [lints_core](https://pub.dev/packages/lints) and run `flutter analyze lib/shared_preferences.dart`
</details>

After
## ✓ Pass static analysis (30 / 30)
### [*] 30/30 points: code has no errors, warnings, lints, or formatting issues

Pre-launch Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[x] I read and followed the [relevant style guides] and ran [the auto-formatter]. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the [CLA].
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or this PR is [exempt from version changes].
[x] I updated CHANGELOG.md to add a description of the change, [following repository CHANGELOG style].
[ ] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is [test-exempt].
[ ] All existing and new tests are passing.

Thanks for the submission, but per my comment in the issue this is intentional.


Make Voila Dashboards work with Voila 0.3.5

Dashboards don't seem to work with Voila 0.3.5, probably due to new security in Voila.
Something like this might be needed: https://github.com/ideonate/cdsdashboards/commit/148770ed7aca672c8eb38931ed1857072b45d525

I found that if Voilà was run with --preheat_kernel=False (the default, with True being a new feature in ~0.3) then jhsingle-native-proxy's ready-check fetch of the / URL would be connection refused, so we never believe Voilà is running. With --preheat_kernel=True I did not see the same problem.
This must be because the --preheat_kernel=False is not exactly backwards-compatible, although it is possible that increasing the timeout in Simpervisor would get around this (although maybe not for larger notebooks). Anyway, the simpler solution was to change the --ready-check-path=/voila/static/ passed to jhsingle-native-proxy in the Voilà case because that more immediately returns a valid response (albeit a 404).
I have changed this in cdsdashboards and released 0.6.1. When this is available on conda-forge I will update in QHub via a PR.


bug: Page with TS codeblocks causes Internal Server Error

Starting a few days a go one of the react-native-google-mobile-ads pages started showing the following error message:

The page used to work flawlessly before, so I assume this has something to do with #359. Checking the browsers dev tools reveals that the GET request to https://docs.page/invertase/react-native-google-mobile-ads/impression-level-ad-revenue results in an internal server error (status 500).
I narrowed the problem down to the following two codeblocks in our docs:
https://github.com/invertase/react-native-google-mobile-ads/blob/b4443b473bba2322b8b7f0b80ed9cd7689af8f0a/docs/impression-level-ad-revenue.mdx?plain=1#L26-L39
Removing them OR(!) switching their language from ts to tsx resolved the problem, which can be verified by looking at the preview of the branch I used for debugging.

@DoctorJohn Thanks for reporting. This was because of the twoslash rendering which has now been removed. Unfortunately it can't handle external types without them being explicitly installed which won't work for docs.page.
The page is live again.


Version bump

Changes since release 1.97.2:

Use export-method = 'development' by default
Update AvailablePlugins.md (#5424)
[fastlane] Updated gym dependency (#5413)
[fastlane] Update number of available actions (#5411)
Add Xcode 8 support: rename "OS X" to "macOS" (#5385)
Added support for relative file paths (#5354)
[add_git_tag] adding force option (#5348)
Fix missing last_git_commit_message to last_git_commit (ref #5213) (#5342)
Fixed misspell. (#5349)
Update AvailablePlugins.md (#5345)
There was 4 single checks not 3 and this was causing issues on markdown parsing (#5330)
Added missing () (#5303)
crash if the appropriate target is not found (#5338)
Improve error message for black_list for invalid lane names
Fix confusing error message when lane name is :test
Improve instructions for publishing plugin (#5328)
Update xcode-install version to 2.0.0 (#5322)
Added instructions on how to make fastlane fast again (#5308)
Fix link to PluginsTroubleshooting.md (#5314)
Update AvailablePlugins.md
Updated AvailablePlugins.md (#5305)
Added warning when a lane name is already taken by an action
Refactored how actions are loaded to a central point

#overtheshoulder 🚢

Why is the changelog different from https://github.com/fastlane/fastlane/releases/tag/1.98.0? To make it easier and faster to read?

This is the literal changelog from fastlane show_changelog, while the changelog for the release tag was edited down to be more concise for human readability. Do you prefer a different approach?
/cc @asfalcone @mfurtak

The public release notes were edited down to remove trivial fixes. This list represents the full set of commits as generated by the lane, as @mpirri said

I removed things like the updates to README files, reworded some messages to include the action name and condensed some of the commits into 1 comment.

Sounds perfect, thanks for clarifying 👍


⚠ Secret Website 3 has degraded performance

In db961f4, Secret Website 3 ($SECRET_WEBSITE_3) experienced degraded performance:

HTTP code: 200
Response time: 7208 ms

Resolved: Secret Website 3 performance has improved in d6cae7d.


[BUG] Set-PnPListItem -Batch fails on update of Managed Metadata Column

Expected behavior
Set-PnPListItem allows batching as per the documentation.
Any Set-PnPListItem that works without "-Batch" is expected to also work with "-Batch".
Actual behavior
Set-PnPListItem used to update a multivalued managed metadata column works outside a batch but fails when added to a batch. The Set-PnPListItem call ends with the following error:
Set-PnPListItem : Specified argument was out of the range of valid values.
Parameter name: lcid
At xxx...xxx.ps1:nn char:n
+ Set-PnPListItem -List "BI" -Identity 45934 -Values @{
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (:) [Set-PnPListItem], ServerException
    + FullyQualifiedErrorId : EXCEPTION,PnP.PowerShell.Commands.Lists.SetListItem

Steps to reproduce behavior
Assuming a library "BI", document 45934 and two terms "f5d4baae-6d12-42bf-b3f1-76f06ef0f037", "bca7c6ab-a948-4cd1-b1b6-38d9001b47bc" from the terms set linked to a multivalued managed metadata column named "Tags". The following code fails:
$Batch = New-PnPBatch
Set-PnPListItem -List "BI" -Identity 45934 -Values @{
    "Tags" = "f5d4baae-6d12-42bf-b3f1-76f06ef0f037", "bca7c6ab-a948-4cd1-b1b6-38d9001b47bc"
} -Batch $Batch
Invoke-PnPBatch -Batch $Batch

Although this one works:
Set-PnPListItem -List "BI" -Identity 45934 -Values @{
    "Tags" = "f5d4baae-6d12-42bf-b3f1-76f06ef0f037", "bca7c6ab-a948-4cd1-b1b6-38d9001b47bc"
}

What is the version of the Cmdlet module you are running?
Version          Name                                   Repository
-------          ----                                   ----------
1.3.14-nightly   PnP.PowerShell                         PSGallery

On PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      17763  1490

Which operating system/environment are you running PnP PowerShell on?

[X] Windows

I just tried exactly what you tried, e.g. I created a column called Tags on a new list, managed metadata, marked is as a multi-value column.
I try in two ways to add two values to the list item, and that succeeded twice...

What is the error message you are receiving?

As the document library  I am working on is more complex, I simplified and did the same you did.
I created "ItemTest" list with Tags column pointing to the same terms set.
I noticed you used Add-PnPListItem (I was referring to Set-PnPListItem) but it is the same behavior -
Here is what I get - 1st call (without batch is ok); 2nd call with batch, I get a Specified argument was out of the range of valid values. Parameter name: lcid error:

I have a guess where it goes wrong: the current locale you're running in, is that different from the actual term store? E.g. you're running in English (1033) but the termstore does not have labels available for that locale? In order for us to add the value to the field, we need to retrieve a label. We default to the label for the current culture you're using in the current session.
I'm looking at a solution now.

I just merged a change, which my guess is will solve your problem. Please check it out if you can, this will be available in tomorrows nightly build: 1.3.16-nightly.

I'll certainly do - thanks a lot for this - I will report here the results.

I just merged a change, which my guess is will solve your problem. Please check it out if you can, this will be available in tomorrows nightly build: 1.3.16-nightly.

Tested on 1.3.15-nightly, works perfectly - thanks a lot.


Massive duplication of datasources

I still can't get my head around why we have so much duplication of data sources in org.bridgedb.bio vs org.bridgedb.rdf:

https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.bio/resources/org/bridgedb/bio/datasources.txt
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/BioDataSource.ttl
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/DataSource.ttl
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/IdentifiersOrgDataSource.txt
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/IdentifiersOrgDataSource.ttl
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/MiriamRegistry.ttl

Fixing a data source name, URI pattern or system code in any one of these files seems to require editing all the others.
This means it is basically impossible to edit.
What is the point of this duplication?

https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.bio/resources/org/bridgedb/bio/datasources.txt is the historical source for non OPS/rdf based Bridgedb projects

https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/MiriamRegistry.ttl
is a download form Miriam / Identifiers.org

https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/DataSource.ttl
is for datasource informaton NOT found in either of the two above.

These are the three read in!
The others are generated from the above purely for information and never used read by the system
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/BioDataSource.ttl is 1 in ttl format.
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/IdentifiersOrgDataSource.txt is 2 in the format used for 1
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/IdentifiersOrgDataSource.ttl is 3 in the ttl format.

The general OPS rule has been.

Never change *.txt but to use the settings there where ever applicable.

Attempt to get as much as possible into miriam and the grab a new copy of their register

Only if info is not in 1 and either not applicable for miriam or too slow is it added to https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/resources/DataSource.ttl

Also in 3 goes the case where the datasource part of the URI set in 1 is too short
For example CHEBI where not all URI have the capital "CHEBI" so that can not be part of the ID.
===
So if a datasource exists in 1. Use the bridgeDB short code
If it does not exist in 1 but does in Miriam use their code
Only make up a new Datasource code if not in 1 or 2

Thanks for clarifying the historical aspect.. I am not sure why we need to keep the "infomation" ones around as they just give me misinformation :)
I don't know how to update from Miriam or Identifiers.org, or what would break if I did. IdentifiersOrgDataSource.* contain some manual patches from when identifiers.org was wrong or breaking stuff. (which was reported upstream, but as that takes a long time changes were also done locally here)

I've tried to summarize this in the README  - but I think I still don't quite get the implied or expected data flow here..
@Christian-B  - do you think you could clarify:

Which files are meant to be updated how?
Which files are generated from what
Which files can be removed, if any
How can we avoid all these files?

DataSoucre init is done by
https://github.com/bridgedb/BridgeDb/blob/master/org.bridgedb.rdf/src/org/bridgedb/rdf/UriPattern.java
refreshUriPatterns() method

Ideal would be for all BridgeDB users to agree to use only the ttf method.
Which would allow merging the functionality and files from
DataSourceTxt.init();
DataSourceMetaDataProvidor.assumeUnknownsAreBio();
BridgeDBRdfHandler.init();
This should now be possible as the RDF stuff is in the main branch!
I would not recommend removing or merging
IdentifersOrgReader.init(); and the files it depends on.
As this is an independent source of metadata which is a useful and near free addition.
Either way I would suggest OPS developers and anyone wanting to do thing the OPS way to do all updates via
BridgeDBRdfHandler.init();
and the files it uses ONLY
Grabbing a new miriam register on a regular basis.

Some more history.

we need a small datasources.txt for use of BridgeDb on WikiPathways (or used to)
we want a richer identifiers.org-based version
we may want to support other files
we currently support two formats, but in the future (near or later) use RDF if the overhead is not too large

That said, that should not inhibit us from cleaning things up, which, IMHO, is the right time for to do in the master branch. After all, we have the bridgedb2.x branch for (current) stable releases.

A nice compromise could be.
Use the RDF as an offical source of this information.
But include the required DataSource data in any Derby file.
Then for shipping the RDF code would not be required.
Also as the DataSource stuff is tightly packed with the links there is no danger of breaking the links with later dataSource changes.

we need a small datasources.txt for use of BridgeDb on WikiPathways (or used to)

For the WikiPathways frontend, bridgedbjs currently depends on datasources.txt, but that code could be easily changed to use another format, as long as the same information is available. Then there wouldn't be any frontend dependencies on datasources.txt.
Do you know whether PathVisio (Java) depends on datasources.txt?


[Quickdraw] I am here to learn how to open and close issues on Github! 🤠

I am here to learn how to open and close issues on Github! 🤠
I will close it in 10 seconds 🤞

I will close it in 10 seconds 🤞


Added Martian theme (v1.0)

Hello!
I'm hoping to add my first theme to ColorSublime! This is a great plugin for sublime text, so thank you for helping to maintain it.
As for my changes, all 6 tests passed as expected.

Since issuing the pull request, I have made very slight changes to the Martian theme. Will reopen when the changes are implemented.


L-PDFT Gradients with Aux Basis

Implement details needed for the auxiliary basis response. Should modify the Hellmann-Feynman functions. Add and pass the df test for LiH.

Not sure if it really makes sense to include the aux_basis since regular MC-PDFT does not have it. It is only for CMS-PDFT. I think for now I will not include it.

I need to understand what I need to include for the auxbasis_response. Might be worthwhile to check with our prior MC-PDFT paper on how it was done.

This is actually not a trivial task as the response will need to depend on both the state and zero-order density matrix. Perhaps I will leave this for a future issue/development then.