Add capability to restrict flag values to a set of allowed values

I have a use-case where I need to perform validation on flag values. In other words, I need to check that the value passed in by the user belongs to some set of valid values. I end up writing a lot of code that looks like this:
package main

import (
	"fmt"
	"os"

	flag "github.com/spf13/pflag"
)

var color string

func main() {
	addFlags()
	flag.Parse()
	if err := validateFlags(); err != nil {
		fmt.Fprintf(os.Stderr, "Error: %v", err)
		os.Exit(1)
	}
	fmt.Printf("Selected color is %s\n", color)
}

func addFlags() {
	flag.StringVar(&color, "color", "", "The color for the example")
}

func validateFlags() error {
	validColors := []string{"red", "blue", "yellow"}
	for _, validColor := range validColors {
		if color == validColor {
			// color is valid
			return nil
		}
	}
	// if we're here, color is invalid
	return fmt.Errorf("Value '%s' is invalid for flag 'color'. Valid values "+
		"come from the set %v", color, validColors)
}

I'd like to be able to do something like the following:
	flag.StringVarRestricted(
		&color,                            // pointer to variable
		"color",                           // flag name
		"",                                // default value
		"The color for the example",       // description
		[]string{"red", "blue", "yellow"}) // Allowed values

I wouldn't mind taking a shot at implementing something like this if it sounds acceptable.

Just dropping a comment noting that this is the most thumbs-upped issue in this repo, and I'd love to see it come to fruition 🙂
Right now I do some reflection-gymnastics based on pre-defined types to validate and define flags, so if this were added in this project it'd obviate the need for that custom logic and make my codebase that much easier to maintain. I see #237 was opened, but looks like it didn't get much traction?

@macintacos I'll take a swing at implementing something like this on my fork.

Python's argparse supports flags with predefined choices. I want to replicate the same behaviour in Cobra, and think it would be a great addition.

This is would be so useful. Is there anything keeping this from getting merged? 🙏

This is would be so useful. Is there anything keeping this from getting merged? 🙏

I think this feature would be awesome, I would like to suggest a change, instead a slice of valid values could be a bool function that validates the value 😃

I think this feature would be awesome, I would like to suggest a change, instead a slice of valid values could be a bool function that validates the value 😃

@felipe-avelar  that is a better approach as it is more flexiable, so using the initial example it would become:
	flag.StringVarValidated(
		&color,                            // pointer to variable
		"color",                           // flag name
		"",                                // default value
		"The color for the example",       // description
		func (s string) bool { ... }(),    // Function to evaluate valid values

@felipe-avelar  that is a better approach as it is more flexiable, so using the initial example it would become:
	flag.StringVarValidated(
		&color,                            // pointer to variable
		"color",                           // flag name
		"",                                // default value
		"The color for the example",       // description
		func (s string) bool { ... }(),    // Function to evaluate valid values

Alternative POV: If you provide a slice of valid values, then help output can tell the user what they are, and shell autocomplete integration can leverage that information.
Of course, not all cases can be handled by a slice, so this is probably a case of "yes, and". For example, could have the validation function, and an (optional) slice of "suggested" values?

Alternative POV: If you provide a slice of valid values, then help output can tell the user what they are, and shell autocomplete integration can leverage that information.
Of course, not all cases can be handled by a slice, so this is probably a case of "yes, and". For example, could have the validation function, and an (optional) slice of "suggested" values?

@fastcat You make a great point.
@pmenglund I like your suggestion and think it should be a feature either way..
I will try to find time soon to implement this on my fork, which also has other features, and works with cobra (instructions in the readme).

@fastcat You make a great point.
@pmenglund I like your suggestion and think it should be a feature either way..
I will try to find time soon to implement this on my fork, which also has other features, and works with cobra (instructions in the readme).

Is this project dead? How come this issue is still open and stale? Where are the repo admins?

Is this project dead? How come this issue is still open and stale? Where are the repo admins?
cc: @spf13

@thalesfsp last I check this is an open source project, so you either avoid looking a gift horse in the mouth and accept the free software with its limitations, or you implement the missing feature you want on your own (or pay someone to do it for you).

@thalesfsp last I check this is an open source project, so you either avoid looking a gift horse in the mouth and accept the free software with its limitations, or you implement the missing feature you want on your own (or pay someone to do it for you).

Why is this snarky reply so popular? The question is completely valid given the neglect this library sees and the outright hostility everyone encounters when touching the subject on the cobra repos.
A fork has been floated on so many issues with this repo and everyone keeps shooting it down and complaining when people mention it, so please don't act like that's a real solution for the average user. If you have any experience in the industry, you know that's a straw argument.

It is popular because so many put demands on people who devote their free time to maintaining open source projects, with no compensation but the "fame". My guess is that @spf13 has a demanding day-job, and probably a family, so any sliver of spare time is probably spent on something to unwind.
So what are the alternatives? You can whine or you can do something to fix it. Whining gets you snarky comments from people who have maintained open source projects.
That said, I should not have posted the snarky comment. Instead I should have offered advice, but my patience quota had run out.
Now it has been refilled, so here goes:
Go makes it easy very to fork this repo and use a replace directive in your go.mod to swap it out for your own fork, where you merged #237. That is a solution the average user can use. Not optimal but workable.
Since @cornfeedhobo has forked it, @thalesfsp can just add this to go.mod and get all benefits from the fork:
replace (
    github.com/spf13/pflag => github.com/cornfeedhobo/pflag
)

@pmenglund thanks for such a thoughtful reply. Re-reading my comment and I can see I was more incensed than I meant to be. Thanks for reading through that, and my apologies.

I think this is achievable with custom flags (type), as flag is only an interface:
Sample code:
package main

import (
	"fmt"
	"strings"

	flag "github.com/spf13/pflag"
)

type enum struct {
	Allowed []string
	Value   string
}

// newEnum give a list of allowed flag parameters, where the second argument is the default
func newEnum(allowed []string, d string) *enum {
	return &enum{
		Allowed: allowed,
		Value:   d,
	}
}

func (a enum) String() string {
	return a.Value
}

func (a *enum) Set(p string) error {
	isIncluded := func(opts []string, val string) bool {
		for _, opt := range opts {
			if val == opt {
				return true
			}
		}
		return false
	}
	if !isIncluded(a.Allowed, p) {
		return fmt.Errorf("%s is not included in %s", p, strings.Join(a.Allowed, ","))
	}
	a.Value = p
	return nil
}

func (a *enum) Type() string {
	return "string"
}

// Main program starts here

func main() {
	color := newEnum([]string{"red", "green", "blue"}, "green")
	flag.VarP(color, "color", "c", "the color you want")
	flag.Parse()
	fmt.Printf("You have selected %s\n", color)
}

@frankywahl is the best answer here. Trivial to extend and presumably exactly what the author intended.

While enumflag is not a generic add-on for spf13, it covers the use case of enumeration flags (and slices). Maybe that might be of some help in such cases?

The addition of Func/FuncP in #350 (disclaimer: i'm the PR author) would also fix the issue in a more generic (and indirect) manner in the case of only one or two flags:
package main

import (
	"fmt"
	"os"
	"sort"
	"strings"

	flag "github.com/spf13/pflag"
)

func main() {
	color := ""
	flag.Func("color", "use `COLOR` for the example, or \"help\"",
		func(s string) error {
			// NOTE: keep sorted!
			validColors := []string{"blue", "red", "yellow"}

			if s == "help" {
				// special case: --color=help
				fmt.Fprintln(flag.CommandLine.Output(), "Valid colors:", strings.Join(validColors, ", "))
				os.Exit(2) // "invalid argument" error if `return flag.ErrHelp` is used :(
			}

			// sort.SearchStrings can be used since validColors is already sorted.
			i := sort.SearchStrings(validColors, s)
			if i < len(validColors) && validColors[i] == s {
				color = s
				return nil
			}
			return fmt.Errorf("invalid color %q; use --color=help to list valid colors", s)
		},
	)
	flag.Parse()
	if color == "" {
		flag.Lookup("color").Value.Set("") // stay DRY
	} else {
		fmt.Printf("Selected color is %s\n", color)
	}
}

For many such flags, however, a custom Var implementation as suggested by @frankywahl is a much better solution, though i would sort enum.Allowed before returning from newEnum to allow faster searches with sort.SearchStrings.
Of course, that is merely the most straightforward implementation; there may be better alternatives to consider.
Naturally you'll have people asking if one can extend this to yet another Var implementation with a one-to-one mapping from a restricted value to a custom function, or a way to restrict a range of int values without storing all possible int values in enum.Allowed, or some other request to add more code to pflag just so their own code does not need to do it.
I would not be surprised if an author/maintainer/contributor of pflag is especially wary of adding such Var implementations since pflag already has significantly more Var implementations than Go's standard flag package, even excluding the P variants:
bash$ topfuncs() { go doc $1 | grep '^func.*name.*usage' | grep -v '^func[^(]*P' ; }
bash$ wc -l <(topfuncs flag) <(topfuncs github.com/spf13/pflag)
      19 /tmp//sh-np.azCogP
      65 /tmp//sh-np.MqaD5O
      84 total

That said, i agree an implementation of Var that allows you to restrict flag values is general enough and popular enough to be a useful addition with the caveat that enum is a bad name as various proposals exist to add typed enums to Go, meaning enum might become a keyword or a built-in at some point in the future.

Hi, an ther one solution i choosed can be to add a PersistentPreRunE qualifier to your root command to operate on all general flags, or on the command linked flags concerned by.
Then you can check for the variable that has catched the value and operate a regex or a switch/case or what ever you want.
This way should add a "clean" solution (i mean... readable and splitable easy in a MVC design too)  to contourn the lake of time interest from the owner of this nice repo.
If you need an example, please ask, i will modify my comment to show you that (but i think you got the point there).


Record performance metrics

check https://github.com/metrics-rs/metrics
make metrics visible to tests and refactor tests in https://github.com/vitorenesduarte/fantoch/blob/master/fantoch_ps/src/protocol/mod.rs

Addressed in #75 and #76


error: Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file

This happens at least with Flow 0.63.1 when using with IntelliJ or Webstorm and macOS 10.13.2 High Sierra:
Jan 10 15:47:20.320 [info] argv=/path/to/project/node_modules/flow-bin/flow-osx-v0.63.1/flow server /path/to/project
Jan 10 15:47:20.320 [info] Creating a new Flow server
Jan 10 15:47:50.393 [error] Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file
Jan 10 15:47:50.394 [error] backtrace:
Jan 10 15:47:50.394 [error] Raised at file "map.ml", line 122, characters 16-25
Jan 10 15:47:50.394 [error] Called from file "src/unix/lwt_engine.ml", line 309, characters 8-36
Jan 10 15:47:50.394 [error]
Jan 10 15:47:50.394 [error] Failed to shutdown socket client: Unix.Unix_error(Unix.ENOTCONN, "shutdown", "")
Jan 10 15:48:20.405 [error] Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file
Jan 10 15:48:20.405 [error] backtrace:
Jan 10 15:48:20.405 [error] Raised at file "map.ml", line 122, characters 16-25
Jan 10 15:48:20.405 [error] Called from file "src/core/lwt.ml", line 802, characters 20-60
Jan 10 15:48:20.405 [error]
Jan 10 15:48:20.406 [error] Failed to shutdown socket client: Unix.Unix_error(Unix.ENOTCONN, "shutdown", "")
Jan 10 15:48:50.415 [error] Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file
Jan 10 15:48:50.415 [error] backtrace:
Jan 10 15:48:50.415 [error] Raised at file "map.ml", line 122, characters 16-25
Jan 10 15:48:50.415 [error] Called from file "src/core/lwt.ml", line 802, characters 20-60
Jan 10 15:48:50.415 [error]
Jan 10 15:48:50.415 [error] Failed to shutdown socket client: Unix.Unix_error(Unix.ENOTCONN, "shutdown", "")
Jan 10 15:49:21.716 [error] Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file
Jan 10 15:49:21.716 [error] backtrace:
Jan 10 15:49:21.716 [error] Raised at file "map.ml", line 122, characters 16-25
Jan 10 15:49:21.716 [error] Called from file "src/unix/lwt_engine.ml", line 309, characters 8-36
Jan 10 15:49:21.716 [error]
Jan 10 15:49:21.716 [error] Failed to shutdown socket client: Unix.Unix_error(Unix.ENOTCONN, "shutdown", "")

same issue here

same (webstorm + high sierra +<EMAIL_ADDRESS>

same here

I was experiencing this issue on WebStorm 2017.1<EMAIL_ADDRESS>and macOS Sierra 10.12.6.
After updating WebStorm to 2017.3, the issue has gone away and flowjs intregration is working as expected.

Same here (IntelliJ Ultimate 2017.3.4 + Windows 10 +<EMAIL_ADDRESS>

flow, 64bit windows 10 - vscode
Closing connection 'server #1' due to uncaught exception in read loop: Unix.Unix_error

flow-bin/flow-osx-v0.66.0; JetBrains IDEA 2018.1; macOS High Sierra 10.13.3

Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file

Mar 30 11:14:06.232 [info] Creating a new Flow server
Mar 30 11:14:37.608 [error] Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file
Mar 30 11:14:37.608 [error] backtrace:
Mar 30 11:14:37.608 [error] Raised at file "map.ml", line 130, characters 10-25
Mar 30 11:14:37.608 [error] Called from file "src/core/lwt.ml", line 817, characters 20-60
Mar 30 11:14:37.608 [error]
Mar 30 11:14:37.608 [error] Failed to shutdown socket client: Unix.Unix_error(Unix.ENOTCONN, "shutdown", "")
Mar 30 11:14:37.608 [error] backtrace:
Mar 30 11:14:37.608 [error] Raised by primitive operation at file "src/unix/lwt_unix.cppo.ml", line 1533, characters 2-38
Mar 30 11:14:37.608 [error] Called from file "src/monitor/socketAcceptor.ml", line 180, characters 18-49
Mar 30 11:14:37.608 [error]
Mar 30 11:15:40.232 [error] Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file
Mar 30 11:15:40.232 [error] backtrace:
Mar 30 11:15:40.232 [error] Raised at file "map.ml", line 130, characters 10-25
Mar 30 11:15:40.232 [error] Called from file "src/core/lwt.ml", line 817, characters 20-60
Mar 30 11:15:40.232 [error]
Mar 30 11:15:40.232 [error] Failed to shutdown socket client: Unix.Unix_error(Unix.ENOTCONN, "shutdown", "")
Mar 30 11:15:40.232 [error] backtrace:
Mar 30 11:15:40.232 [error] Raised by primitive operation at file "src/unix/lwt_unix.cppo.ml", line 1533, characters 2-38
Mar 30 11:15:40.232 [error] Called from file "src/monitor/socketAcceptor.ml", line 180, characters 18-49
Mar 30 11:15:40.232 [error]

same here

Also still getting this, running latest version of RubyMine.

Run flow check and it will tell you which file is crashing flow.  Add this file to the [ignore] section of .flowconfig (or fix the error if it's your code) and run flow check again.  Repeat until flow runs without crashing.

This one is still not fixed. 😞

Yeah that's not the solution to this problem, if only it were that straightforward.

I mean how do we motivate people to use flow or typescript when it is so freaking complicated to make flow work correctly? 🙂

same here

Same here:
flow-bin/flow-osx-v0.74.0; WebStorm 2018.1.5; macOS High Sierra 10.13.6
Any other info I can provide?

@zdrazil that's good, thanks! Out of curiosity, when did the problem start? Was it there from the beginning or did it come once your project reached a certain size / you imported some package / etc?

Also curious-- has anyone submitted this bug report to WebStorm and got a response? I haven't seen reports for this bug pertaining to VSCode or Atom, so I'm almost certain this is an issue with the editor.

@mrkev the issue is logged as https://youtrack.jetbrains.com/issue/WEB-30296 on the WebStorm tracker.
There’s a comment above mentioning the problem occurring in VS Code as well.
To our knowledge, the problem lies on the Flow side. It seems that WebStorm uses some Flow’s methods in its integration with the Flow service that trigger the problem. Probably other editors don’t use these methods as much as we do, but we can’t say for sure what exactly should be changed on our side to work around the problem.
We are considering re-implementing the integration using the new LSP APIs introduced in Flow recently. And we hope that it will help us resolve this issue. Please note that we haven’t started working on that yet and we don’t know the state of the new API.

Same here, details:
IntelliJ IDEA 2018.2.2 (Ultimate Edition)
Build #IU-182.4129.33, built on August 21, 2018
Windows 10 10.0
"flow-bin": "^0.80.0"

.flowconfig in the project root:
[ignore]
<PROJECT_ROOT>/.idea/.*
<PROJECT_ROOT>/android/.*
<PROJECT_ROOT>/docs/.*
<PROJECT_ROOT>/ios/.*
<PROJECT_ROOT>/node_modules/.*
<PROJECT_ROOT>/plugins/.*

[include]

[libs]

[lints]

[options]

[strict]

Also Flow console reports about Sep  3 20:28:59.101 [info] File watcher reported 19 files changed when only one file has been changed as in #6424

Similar problem still happens with 0.84.0:
/Users/path/to/project/node_modules/flow-bin/vendor/flow server /Users/villesaukkonen/code/frontend
Nov  2 11:29:11.758 [info] argv=/Users/path/to/project/node_modules/flow-bin/flow-osx-v0.84.0/flow server /Users/path/to/project
Nov  2 11:29:11.759 [info] Creating a new Flow server
Nov  2 11:29:24.421 [info] File watcher reported 4 files changed
Nov  2 11:29:41.854 [error] Closing connection 'some ephemeral connection' due to uncaught exception in read loop: End_of_file
Nov  2 11:29:41.854 [error] backtrace:
Nov  2 11:29:41.854 [error] Raised at file "map.ml", line 130, characters 10-25
Nov  2 11:29:41.854 [error] Called from file "src/unix/lwt_engine.ml", line 318, characters 8-36
Nov  2 11:29:41.854 [error]
Nov  2 11:29:41.854 [error] Failed to shutdown socket client: Unix.Unix_error(Unix.ENOTCONN, "shutdown", "")
Nov  2 11:29:41.854 [error] backtrace:
Nov  2 11:29:41.854 [error] Raised by primitive operation at file "src/unix/lwt_unix.cppo.ml", line 1533, characters 2-38
Nov  2 11:29:41.854 [error] Called from file "src/monitor/socketAcceptor.ml", line 148, characters 18-49
Nov  2 11:29:41.854 [error]
Nov  2 11:29:46.673 [error] Closing connection 'server #1' due to uncaught exception in read loop: End_of_file
Nov  2 11:29:46.673 [error] backtrace:
Nov  2 11:29:46.673 [error] Raised at file "map.ml", line 130, characters 10-25
Nov  2 11:29:46.673 [error] Called from file "src/unix/lwt_engine.ml", line 318, characters 8-36
Nov  2 11:29:46.673 [error]
Unable to obtain kernel buffer: Operation not permitted
usage: sudo dmesg
Nov  2 11:29:46.690 [error] Flow server (pid 34338) exited with code Unknown_error (110)
Nov  2 11:29:46.690 [info] Monitor is exiting (Dying along with server)
Nov  2 11:29:46.690 [info] Broadcasting to threads and waiting 1 second for them to exit

I think this might not happen anymore? 🤔Anyone still experiencing this?

I am getting this error on my machine now:
Flow, a static type checker for JavaScript, version 0.121.0
IntelliJ IDEA 2019.3.3 (Ultimate Edition)
Build #IU-193.6494.35, built on February 11, 2020
Licensed to

Runtime version: 11.0.5+10-b520.38 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.6
GC: ParNew, ConcurrentMarkSweep
Memory: 4012M
Cores: 12
Registry: javascript.flow.use.lsp=false (I tried with both true and false)
Non-Bundled Plugins: CheckStyle-IDEA, R4Intellij, com.alayouni.ansiHighlight, com.google.bamboo.id, com.intellij.ideolog, com.intellij.lang.jsgraphql, com.jetbrains.plugins.ini4idea, org.intellij.plugins.hcl, org.jetbrains.kotlin, some.awesome


router.navigate is not a function

I'm trying to navigate through code! I have seen an example in tests but it seems I can't do that in my code!
Is there any other way to navigate in code?

The tests and code on this branch are for the next version of the router. There is no other way to navigate through code than manually clicking a router link.

Uh! thanks!


Consider depending on primitive

We try hard to limit dependencies, but it seems unfortunate that Data.HashMap.Array and Data.Primitive.Array are so very similar. How bad would it be to use it? There are a few serious bugs in the released Data.Primitive.Array right now, but fixes have been merged and a test suite is on its way.

I tried to use it initially and it didn't work out well. I believe there
was some issues with inlining.
On Wed, Mar 21, 2018, 11:34 David Feuer<EMAIL_ADDRESS>wrote:

We try hard to limit dependencies, but it seems unfortunate that
Data.HashMap.Array and Data.Primitive.Array are so very similar. How bad
would it be to use it?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tibbe/unordered-containers/issues/197, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AABDfcmhI-LUUf5trwwot5OpmkK6dPMaks5tgdhGgaJpZM4SzAHC
.

Hrmf. Well, if it won't work it won't work, but it might be worth seeing if it can be brought up to snuff. Speaking of inlining, I'm wondering what, if anything, that is currently marked INLINE should actually be marked INLINABLE. At the moment, any code using HashMap heavily is likely to end up very large.

Inlinable is very tricky. For example, a function marked inline calling a
function marked inlinable will make specialization fail due to optimization
pass ordering. I filled a GHC bug about it long time ago.
On Wed, Mar 21, 2018, 11:39 David Feuer<EMAIL_ADDRESS>wrote:

Hrmf. Well, if it won't work it won't work, but it might be worth seeing
if it can be brought up to snuff. Speaking of inlining, I'm wondering what,
if anything, that is currently marked INLINE should actually be marked
INLINABLE. At the moment, any code using HashMap heavily is likely to end
up very large.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tibbe/unordered-containers/issues/197#issuecomment-374832530,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDfc3fIDuScz5fdFWf0oFk1eCXR3OIks5tgdmagaJpZM4SzAHC
.

At some point after the next version of primitive is released, I'd like to give depending on primitive a try. At this point, nearly everything in primitive is explicitly given an INLINE pragma. I don't know how long ago the original attempt at doing this was, but maybe things in primitive have changed in the meantime. In particular, I cannot see any reason why the functions in Data.HashMap.Array would inline any better than their equivalents in Data.Primitive.SmallArray.
@tibbe Let's say that I am able to depend on the array implementation from primitive, and the benchmark suite shows no degradation in performance. Are there other reasons for which this change would be unwanted?

By "other reasons for which this change would be unwanted", what I'm mostly asking is whether there's an objection to depending on primitive at all. Such a dependency would lessen control over some of the source code and would make it possible for regressions in primitive to affect unordered-containers. I just want to make sure that if I have a go at this, that there aren't other factors outside of the aforementioned inlining failures that are preventing the primitive dep from happening.

Personally I think primitive is fine if it doesn't hurt performance but I'll leave it up to the primary maintainer to decide.

Johan, if I create a haskell-unordered-containers github organization,
would you transfer the repository there? Organizations make it a lot easier
to deal with maintainers coming and going.
On Fri, Apr 20, 2018 at 11:23 AM, Andrew Martin<EMAIL_ADDRESS>wrote:

The only maintainer listed on hackage is you. I was not aware that there
was another, but looking through the commit history makes me suspect it's
David. If so, we should update this information in the cabal file.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tibbe/unordered-containers/issues/197#issuecomment-383131526,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABzi_TAyjGKP-8pgowpyhFOMkvY1o_VQks5tqf1ogaJpZM4SzAHC
.

I'm working on depending on primitive on https://github.com/tibbe/unordered-containers/pull/206

I used to be undecided about this idea, but I'm pretty positive now:

We get rid of a bunch of tricky code with a weird naming scheme.
Instead we'll use code that has more users and is therefore more likely to be performant and correct.
If we run into any SmallArray-related issues, we can potentially get help from the primitive maintainers and other users.

@andrewthad Could you rebase your PR #206?
Regarding the risk of subtle performance regressions: I plan on reviewing the Core and STG diffs for #206 and I'm fairly optimistic that this will catch most issues.

I'll give this a "yes, but". I actually think the Right Thing is to start by modifying primitive to implement the operations in ST (in separate modules) and then lift them into the primitive classes. Then there won't be regressions here or elsewhere. I did this for the experimental and I think currently broken primitive-unlifted package, and it was quite nice all around.

@treeowl Can you clarify why this approach is better? It might also be helpful to link to the work you mention.

The tricky thing with primitive is inlining decisions. It's critical to specialize to the right MonadPrim (or whatever it's called) instance, and to do it early. But there's only so much control a library has over that. Building primitive on a solid, monomorphic foundation of ST, and exposing that foundation, means that when working with something that is definitely ST s (which is really the fundamental instance) you don't have to worry about specialization. It's trivial to also expose a monomorphic version for IO ~= ST RealWorld which just coerces the ST versions. The "classy" versions can be built on top quite mechanically (with a few exceptions, I think).


fixes issue #1: slashes in IDs not encoded.

This was a moderately complicated fix.  The old CouchDB wiki has this to say about slashes in document IDs:

You can have / as part of the document ID but if you refer to a document in a URL
you must always encode it as %2F. One special case is _design/ documents, those
accept either / or %2F for the / after _design, although / is preferred and %2F is still
needed for the rest of the DocID.

(https://wiki.apache.org/couchdb/HTTP_Document_API#line-75)
I initially modified couchdb.go to break up the document ID on slash characters and reassemble it with %2F separators, with a special case for IDs that start with _design, where I prefixed _design/ and assembled the rest of the ID with escaped slashes.  Here are some examples of the transformed IDs:
user/34734612 -> user%2F34734612
AC/DC/240V -> AC%2FDC%2F240V
_design/lookup/users -> _design/lookup%2Fusers

I added new unit tests to couchdb_test.go with handlers that responded to the escaped document IDs and found that these tests failed.  After some investigation, I found issue #5684 in the golang repo, which was filed because url.URL was decoding escape sequences in URL paths.  My encoding code converted slashes to %2F but url.URL converted them back to slashes, which caused the test to fail.
The documentation for url.URL contained a workaround for this issue: the Opaque field of a URL struct can be set with the value of the encoded URL path, and that encoded value will be used in http.Request as the request path.  Unfortunately, this involved replacing the call to http.NewRequest in the newRequest function with code that constructs a Request structure manually.  This is the part of the PR that should be reviewed most strictly to make sure I didn't inadvertently miss anything in the request construction.  All the unit tests, including my new ones that test getting document IDs containing slashes, are passing.
Let me know what you think or if there is anything I can do to improve this code.

I added another commit which refactors the ID encoding into a new function in http.go named encid().  This was necessary because I discovered that database names also need to have slashes converted to %2F.
You might be wondering at this point why it is so important to us to make so many large changes just to support a minor feature of CouchDB.  For me, I need slashes in database names and document IDs in order to be compatible with Hoodie, a web application development platform based on CouchDB.  Hoodie expects document and database identifiers to be in the format <type>/<id> instead of using opaque generated IDs.  For example, if I have a document that holds address information, that document's ID might be address/2x345b, and it might be stored in a database named user/3tn32s1.  You can find more details about Hoodie's behavior in this FAQ entry.

Fixed in 9bc16a45318b1103f4938079b9725703404fb976.


Pierre allows a PR to self-reference

Should not be able to do that, creates a cyclic reference

Good catch @mosheeshel thanks!

Hi.
I have difficulty in understanding what this issue and which section of the code base this issue deals with.
I am new to the open source environment so please give me some directions.
Thanks :)

Alright @rajalakshmi-v15 I can help you with that.
First of all, this issue is about cyclic dependency. Given a PR with id XYZ, if one adds "Depends on #XYZ" as a comment, Pierre will include it as a dependency that most likely will make developers wonder what's wrong, since it's depending on itself to be met.
As for where in the code this can be fixed, well, there are some places, depending on the strategy one would think is the best:

Have a look at get_dependency_state. That's where Pierre retrieves each dependency's status (it's either open or closed per GitHub specification) and could be used to consider always the current PR status as closed.
One could simply ignore the dependency from the start, and that could be accomplished on get_dependencies_from_bodies

Or if you have another suggestion, we can discuss it here. Be my guest. 😁

Thank you, @alvarocavalcanti (and sorry for the delayed response). I would like to work on this issue.

@rajalakshmi-v15 go ahead!

Hi, @mosheeshel. If there a way to get the id of the current PR? If we can get that, that particular id can be excluded from the set(dependencies)  part in 'get_dependencies_from_bodies` function.

Have a look in payloads you can see some samples of what's returned by github. I'm guessing you can find some useful identifications.

@mosheeshel, I have opened a new pull request with the branches aligined.
Kindly review it.

It was fixed by #52


regression v1.16: OpenCL.dll was not found

I'm using Basisu on a ryzen server (using onboard gpu) and having this OpenCL.dll was not found error:

Only v1.16+ having this error, v1.15 works fine.

Can you try installing the latest AMD driver?
You can also building basisu with the OPENCL flag set to 0, to disable all OpenCL usage.


Corrected ms.topic value for VB refs

Summary
Corrected ms.topic value for VB refs:

"docs/visual-basic/language-reference/**/*.md": "reference",
"docs/visual-basic/reference/**/*.md": "reference",
"docs/visual-basic/misc/bc*.md": "reference"

Related to #23694

On second thought, bc*.md should be error-reference.


Doc/capps2/release edits

Summary
This PR updates the documentation of the release process.
Don't squash merge!  And make sure to run make_release_tarball.sh from the top level directory.

I meant to have this up some weeks ago, but apparently I forgot.  Sorry about that.


Filemin not access after  install latest version

I am trting to install latest version.It's says sucessfully installed but when i try to access it's says followng error:
Can't locate JSON/PP.pm in @INC (@INC contains: ./lib /usr/libexec/webmin /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . /usr/libexec/webmin/ ..) at lib/Mojo/JSON.pm line 6.
BEGIN failed--compilation aborted at lib/Mojo/JSON.pm line 6.
Compilation failed in require at ./filemin-lib.pl line 12.
BEGIN failed--compilation aborted at ./filemin-lib.pl line 12.
Compilation failed in require at /usr/libexec/webmin/filemin/index.cgi line 4.
Operating System:Operating system CentOS Linux 7.2.1511
Webmin version 1.801

You should be able to fix this by running yum install perl-JSON-PP


Fix TestDaemonRestartWithKilledRunningContainer failures on RHEL systems

On RHEL system TestDaemonRestartWithKilledRunningContainer is currently failing due to a few races in containerd and docker.
This PR pulls in a new version of containerd fixing the found race (i.e. event were generated before their effect were reflected) and rework the restore code to ensure that we correctly get missed events for running containers during docker restore phase.

cc @tonistiigi @crosbymichael

:grimacing:
14:15:51 FAIL: docker_cli_run_test.go:2999: DockerSuite.TestRunPidHostWithChildIsKillable
14:15:51
14:15:51 docker_cli_run_test.go:3018:
14:15:51     c.Fatal("Kill container timed out")
14:15:51 ... Error: Kill container timed out

Panic in the experimental test:
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x5f4c64]

goroutine 14 [running]:
panic(0x1b235a0, 0xc820014080)
	/usr/local/go/src/runtime/panic.go:481 +0x3e6
github.com/docker/docker/libcontainerd.(*client).Restore(0xc820016ae0, 0xc820012c80, 0x40, 0xc820015f20, 0x1, 0x1, 0x0, 0x0)
	/go/src/github.com/docker/docker/libcontainerd/client_linux.go:508 +0x324
github.com/docker/docker/plugin.(*Manager).restore(0xc82005c480, 0xc82007f680, 0x0, 0x0)
	/go/src/github.com/docker/docker/plugin/manager_linux.go:57 +0x31a
github.com/docker/docker/plugin.(*Manager).restorePlugin(0xc82005c480, 0xc82007f680, 0x0, 0x0)
	/go/src/github.com/docker/docker/plugin/manager.go:83 +0x142
github.com/docker/docker/plugin.(*Manager).init.func1(0xc820015f00, 0xc82005c480, 0xc82007f680)
	/go/src/github.com/docker/docker/plugin/manager.go:311 +0x81
created by github.com/docker/docker/plugin.(*Manager).init
	/go/src/github.com/docker/docker/plugin/manager.go:327 +0x353

all :green_heart:

LGTM

All :green_heart: again :sweat_smile:

LGTM :green_heart:

LGTM


[stable 1.73] Update serde

This updates serde on the stable branch from 1.0.171 to 1.0.188. This fixes a problem preventing cargo from being published. The problem is that I published cargo-credential 0.3.0 from the master branch after serde had been updated, causing it to depend on 1.0.180. That breaks with cargo 1.73's lock file which is locked to 1.0.171.

@bors r+

:pushpin: Commit b27ef128fc08c842732fd8cb2868cb95c76204a1 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit b27ef128fc08c842732fd8cb2868cb95c76204a1 with merge a1ec4f1b5da5b32811c94fe4f023b3f3e7713ec7...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing a1ec4f1b5da5b32811c94fe4f023b3f3e7713ec7 to rust-1.73.0...


Rethink data model + navigation: make it more hierarchical?

There are three main types of documents: sites, lists (newsletters), and posts. Currently Platypub's schema does not model any relationships between these. When a site is rendered, all the documents are passed to the theme code, which is responsible for deciding which posts and lists should be included on the current site. The default theme does this by looking at the :site/tag, :list/tags and :post/tags attributes. e.g. you'd set it to example-site on your site, then you'd add example-site to the list's tags and the posts' tags.
This makes things flexible. You could share a single post between multiple sites, for example. However I'm not really sure if that will ever actually be needed. If we added a :post/site and a :list/site attribute--i.e. make it so every post belongs to a single, specific site, and same for lists--would anything actually be lost?
Regardless, we probably want to restructure the UI so that lists and posts are grouped under a specific site by default. If we decide to continue with the flexible data model, then we can have a way to break out of that UI model.
Maybe we add the :post/site and :list/site attributes and just let it be an optional field. Or allow a special value like :system or :none. Or even just... make a another site for any "orphaned" posts and lists and just don't publish it.
So yeah I think I'm leaning towards making posts and lists be children of sites. If anyone can actually think of any scenarios where you wouldn't want that kind of relationship, please comment.

The flexibility of having no strict hierarchy is nice, I think.  Posts hold the actual content with sites and lists providing means of dissemination. Sites provide stationary references to content while lists involve a more dynamic time element and may bundle posts into a newsletter based on tags.
Sharing a post across sites might be useful when the post involves the joint effort of multiple groups with distinct identities and sites. The content can be cross-linked to highlight and reinforce the combined efforts.
I agree :post/site and :list/site attributes are helpful to insure content is anchored to a site, as long as it doesn't feel like a strict coupling and alternates can be added.
BTW, I'm already feeling the need to support an event model around posts:

pre-event announcement
pre-event status changes (rain delay or postponement, new location etc)
post-event recap for those unable to attend.
post-event announcement of follow-up event, if it's a recurring thing.
This might mean creating a set of related posts that get displayed and disseminated based on how their time attributes relate to the current time.

My original thoughts around having posts be independent from sites and lists may have been influenced by thinking of Platypub sort of as an aggregator for all your personal content across the web. E.g. at some point maybe we integrations that pulls in all your tweets + hacker news comments + etc, so you could render them on your site/in an rss feed or something...
Maybe we should have :post/sites and :list/sites attributes which accept multiple values, for the sake of flexibility--worst-case scenario, no one actually uses multiple values. At least the flexibility will be there if someone does want it. And you can always leave it empty.
I'm thinking for the UI we could have multiple views. Something like:
My Site
├── Posts
└── Newsletters
All Newsletters
All Posts

If you go to My Site -> Posts and hit "new post" from there, then the :post/sites field would be set to "My Site" by default. It'd also show up under All Posts though. There'd be a multi-select input so you can add or remove sites. If you remove all the sites, then the post would only be visible under All Posts.

BTW, I'm already feeling the need to support an event model around posts:

Hm, so events as in physical/zoom events right? Are you thinking of using Platypub as an alternative to meetup.com or eventbrite?

Hm, so events as in physical/zoom events right? Are you thinking of using Platypub as an alternative to meetup.com or eventbrite?

I'm writing posts promoting awareness of recurring physical community events: getting the word out beforehand and doing a write-up afterwards; nothing as involved as meetup or eventbrite.
The goal is to show a chronological list of events with the current/next event highlighted much like https://wfmu.org/#schedule-playing-today (of course, much sparser) so people can decided to join at the last minute.
Event start time and event schedule status attributes may be all that's needed really.  I'm finding it's fine to just prepend the follow-up in the original post,

Ah got it. Perhaps it'd be helpful to support custom schema for posts instead of just for sites? Then you could write a custom theme that says "posts should additionally have a event start time field of type instant and a schedule status field of type enum with possible values ..."
In some cases you can get by with tags. e.g. for the event schedule status you could add a tag of upcoming, finished etc. of course that wouldn't handle non-boolean attributes like event start time, unless you included a really creative tag like start-time:2022-06-21T12:00:00 🙂. In this case sounds like custom schema would be better.
I haven't given this the requisite hammock time yet, but it might be in-scope at some point to allow entirely custom document types, like standalone event documents, instead of just post documents with custom attributes.

May be a little off topic but I am more concerned about various types of posts - which may be do able with tags now -- so ie events could be displayed on a calendar page or posts could serve as text for a static page -This is getting into CMS territory -  maybe even have an option for a menu/submenu  tag for a post --  ie my About post becomes my ABout page from the top level menu - About/Tom generates a sub menu

Hmmm... yeah I'm thinking having the theme define a custom schema for posts would be best. (and maybe rename "posts" to the more general "items"). The theme could then define multiple types of items, e.g. events vs posts. Already we have two types, posts and pages, that are currently mixed together. The Platypub UI could have separate navigation sections for each type of item. Maybe something like this, to extend the example above:
My Site
├── Pages
├── Posts
└── Newsletters
Another Site
├── Events
├── Posts
└── Newsletters
All Events
All Pages
All Posts
All Newsletters

Yeah, that would probably be reasonable. We might just leave that to the themes rather than putting schema for events in Platypub's schema.clj file. (i.e. if we enable custom schema for posts, like the custom schema we currently support for sites.)
In general I think we'll want to be conservative with the document types we bake into Platypub, probably leave it at Posts and Pages for a while. Then if a lot of themes end up using a certain additional type of document (like Events) we could think about if it makes sense to pull the schema into "core."
Another hammock thought: going the opposite direction, maybe all document types should be "custom" and defined by themes. The default theme could define Posts and Pages, which would then be a de facto standard for other themes. (This is getting into SOLID Project territory.)

It makes sense to me to just have a document type with a generic schema and just have one of the attributes be a type so you could label it a post, page, event whatever then leave it up to the Theme to deal with it - I am not sure ho you would deal with the situation where items have different numbers of attributes

I looked into applying custom-schema.edn to posts by following the site implementation.
The issue is that posts are only associated to themes by matching tags to sites and newsletters, so post tags need to be supplied before any custom schema is known.  A post can potentially be associated with more than one site or newsletter through tags so custom-schema definitions from more than one theme may get included for a post.
We'd need to know which custom-schema fields in a post are relevant for which themes it seems.

Oh yeah, forgot about that. I'm still feeling good about the :post/sites idea I described above, so I think we should go ahead and do that. After that's done we could add custom schema for posts. I'll make a couple issues for these.

A post can potentially be associated with more than one site through tags so custom-schema definitions from more than one theme may get included for a post. We'd need to show which custom-schema fields in a post are relevant for which themes it seems.

Maybe we should make fields visible based on your navigation context? e.g. say you have a post ("Some Post") under "Site A" and "Site B", both with different themes that define different post schema. If your navigation context is "Site A" -> "Posts" -> "Some Post", then we show the schema for Site A's theme but not the schema for Site B's theme, and vice versa. If the context is "All Posts" -> "Some Post", then we should schema for both themes.

Just added five new issues: #39, #40, #41, #42, #43. In particular #43 has some unresolved questions.


In quantization, why we must ensure that 0 is is in the activation/weight range.

In function update_quantization_param, there are two lines of codes:
rmin = torch.min(rmin, torch.Tensor([0]).to(rmin.device))
rmax = torch.max(rmax, torch.Tensor([0]).to(rmin.device))

I understand that if it is for quantization of activation, we must make sure that 0 is in the range, because there might be zero padding. However, if it is for quantization of weight, I can not figure out why we should keep 0 in the range.

Make sense! The implementation of current NNI quantization refers to gemmlowp and it extends range to include 0 in both weights quantization and activation quantization. But it doesn't mean that this implementation is optimal. Since weights have nothing to do with padding, I think keeping the original min and max value maybe more reasonable. We will discuss it and find better way to handle it. We also look forward to your PR submission to improve this topic.

I'll handle the topic later this weekend

@chenbohua3 / @linbinskn / @ultmaster - has the above fixed got in the recent candidate release?

close this issue because this is a default behavior in PyTorch quantization observer.


[manual-sync] Log "forbidden" update errors

Manual sync of:

https://github.com/open-cluster-management-io/config-policy-controller/pull/219

Closes #768

/cherry-pick release-2.10

/cherry-pick release-2.10


[FLINK-33908][ci] Adds custom action for moving data in Flink's CI Docker image

Based on the following PR(s):

https://github.com/apache/flink/pull/23961
https://github.com/apache/flink/pull/23962
https://github.com/apache/flink/pull/23963
https://github.com/apache/flink/pull/23964
https://github.com/apache/flink/pull/23965

What is the purpose of the change
See FLINK-33908 for further context.
Brief change log

Adds custom action

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

I need to reorganize the workflow-related PRs


feat(lint): do not warn on changes in packages that satisfy the semver range

Current dependencies on/for this PR:

main

PR #34

PR #35   👈

PR #36

This comment was auto-generated by Graphite.

Graphite Merge Job
Current status: ⏳ Queued to merge
This pull request is currently queued to be merged as part of a stack.
This comment was auto-generated by Graphite.

Job Reference: Lq6fAFaN1fLnSbVbBggu


[feature] Implement alternate bases

Fixes #147.
This PR provides the new --base/-b argument which specifies the base that the bytes should be printed in. The base options exposed by the standard library are binary, octal, decimal, and hexadecimal. If we were to add more options, then we would need to pull in some kind of dependency.
For ease of use, the argument accepts either a number (2, 8, 10, 16), a single character abbreviation (b, o, d, x), a three-character abbreviation (bin, oct, dec, hex), or the full base name (binary, octal, decimal, hexadecimal).
Part of this PR is adjusting the --panels=auto option to account for both base and byte grouping from #170. Now it is guaranteed to give the correct number of panels regardless of options.
I have also added a simple integration test.
Questions for review:

Should more bases be allowed?
What should the help text suggest for the argument format?
Should there be more tests?

This will be my last PR until the next release of hexyl.

Should more bases be allowed?

I think the supported set is completely reasonable. I don't expect anyone to require base 5 or similar.

What should the help text suggest for the argument format?

You're talking about the value_name? I think B is fine. Maybe for the values, we could support either the name (hexadecimal) or a number (16), but that's not really important for now. I'm completely fine with your proposal.
It seems pretty obvious, but maybe we could mention the default (hexadecimal).

Should there be more tests?

I think we're good for now - thank you!


Update kokkos files from catalyst repo

Before submitting
Please complete the following checklist when submitting a PR:

[ ] All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to the
tests directory!

[ ] All new functions and code must be clearly commented and documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running make docs.

[ ] Ensure that the test suite passes, by running make test.

[ ] Add a new entry to the .github/CHANGELOG.md file, summarizing the
change, and including a link back to the PR.

[ ] Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

Context:
The lightning kokkos files in the Catalyst repo has changed since #770. We make a small update to track these changes.
The Catalyst PR that made the changes added seeding to qjit: https://github.com/PennyLaneAI/catalyst/pull/936
Description of the Change:
Benefits:
Possible Drawbacks:
Related GitHub Issues:

So this seed is only used for the measure RNG. Is that intended? Otherwise looks good to me, but please update the change log.

This is intended (sampling could not be seeded from the catalyst repo as it is done through Pennylane::LightningKokkos/Qubit::Measures::Measurements)
https://github.com/PennyLaneAI/catalyst/blob/a49e0bc9f828a28aa8cae7d07c64d09d84713ef4/runtime/lib/backend/lightning/lightning_dynamic/LightningSimulator.cpp#L304

Hmm... SetDevicePRNG is a virtual function with default impl. The first method of this kind in the QuantumDevice API.

This is because not all devices can be seeded, so in the device base class we need to supply a default implementation of doing nothing, and let the seedable devices override them.


Order-preserving slice of a Fortran-ordered array results in an A-ordered array

Numba seems to infer an incorrect order from an order-preserving slice of a Fortran-ordered array.
This example illustrates the problem:
import numba
import numpy as np

@numba.jit()
def foo():
    X = np.asfortranarray(np.empty((4, 6)))  # X is a Fortran-ordered array.
    y = X[:, :3] @ np.random.randn(3)  # X[:, :3] should be a Fortran-ordered slice, yet Numba says it's A-ordered.
    return y

>>> foo()
NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 1d, C))
  y = X[:, :3] @ np.random.randn(3)

Thanks for the report, I can reproduce.
MWR:
import numba
import numpy as np

@numba.jit()
def foo():
    X = np.asfortranarray(np.empty((4, 6)))
    y = X[:, :3]

foo()
foo.inspect_types()

note in the annotated IR y is:
    #   y = static_getitem(value=X, index=(slice(None, None, None), slice(None, 3, None)), index_var=$32build_tuple.16, fn=<built-in function getitem>)  :: array(float64, 2d, A)

Debugging this probably needs to start from here:
https://github.com/numba/numba/blob/f5e0e83d188c1947fc0648c41b9e39674e9f1f32/numba/core/typing/arraydecl.py#L138-L147


OTBR 1.3 reference device DUA issue

I'm trying to validate the OTBR 1.3 reference device as Thread Certification compliant, but some Commercial tests are failing.
This branch https://github.com/openthread/ot-reference-release/compare/main...edmont:pr-add-ncs-1-3 has been used to build the reference device, with this command: REFERENCE_PLATFORM=ncs REFERENCE_RELEASE_TYPE=1.3 ./script/make-reference-release.bash
What I found to be the problem in the test C5.9.1 is that the BR_1 device is not forwarding DUA traffic towards the Thread Network. Frame 347 in the attached PCAP. The test logs show the proper solicited Neighbor Advertisement in line 2017, but nothing about the incoming Echo Request.
C_5_9_1-fail2.zip

Gave a try with BORDER_ROUTING=0 and the test is still failing in the same way.

Closing stale issue.


Quic Server/Client Version negotiation

Currently, Version negotiation in QUIC isn't supported, and our ability to test server interoperability using the quic-interop-runner with openssl as a server is non-functional (as the interop-runner checks for server availablilty by sending an Initial packet with a bogus version number).  So, lets implement it.
This PR does several things:

Adds the ability to detect when a packet header isn't decoded due to a malformed version
Adds the ability to specify a channel packetisers version number when encoding headers
Checks in the server code for the presence of an invalid/unsupported version, and responds with a version negotiation packet
Augments the client to detect version negotiation packets, and restart a connection in the event that a more suitable version is found
Augments the test code to send an invalid version and exercise the negotiation path.

Checklist

[x] documentation is added or updated
[x] tests are added or updated

waiving style due to test macro style in multistream test

@Sashan the client side response is actually exercised by the modified tests in this PR.  The updated tests do the following:

Sends an initial packet with an attached mutator that sets the initial version to something invalid
attempts a connect operation

by doing so, the server triggers the sending of a version negotiation packet, and the client then selects and sends the correct version.
Without being able to do that, we can't really test that the server side sending of the version negotiation works.

rebased to newly rebased feature branch

@Sashan please reconfirm

ping @Sashan

This pull request is ready to merge

merged to quic-server branch, thanks for the reviews


Deprecation warning: ++ is deprecated

There are some deprecation warnings received when compiling the Commander package with the latest version of Swift 2.2-dev Feb 3, 2016.
 warning: '++' is deprecated: it will be removed in Swift 3
Sources/ArgumentParser.swift:121:9
Sources/ArgumentParser.swift:163:7
Sources/ArgumentParser.swift:189:7
Sources/ArgumentParser.swift:214:9

Sorry, I did not notice that this was already fixed in master. Do you think it warrants tagging a new release 0.4.1?

I don't think removing a warning for a snapshot of Swift is warrants an additional release.


⚠ Bofrost.be has degraded performance

In 267ffd9, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1835 ms

Resolved: Bofrost.be performance has improved in 8a82901 after 11 minutes.


Wide swings can hit and break grills underneath fullwindows

Description
Wide swing attacks somehow break grills that are underneath windows and you don't get shocked from it. This is a problem because it can nullify the added protection of an electrified grill.
Oddly enough, this only seems to happen when fullwindows are placed before the grills in mapping or player construction.
Reproduction

Place down fullwindow.
Place a grill on top of the fullwindow.
Charge up a wide swing and attack it.

Dupe https://github.com/space-wizards/space-station-14/issues/9129


Question: Parsing output of "scoop list" in Powershell.

Hi!
I was just trying to get a very small personal script going to easily check out websites in the scoop buckets.
I basically wanted to (for now) parse the output of scoop list, do some regex on the output to only find the application names, then do something with scoop home for them.
The problem I am having is that it doesn't seem possible to parse the output of the scoop list command.
Doing things like:

scoop list | Tee-Object -Variable scoopList
echo $scoopList

or:
Doing things like

$scoopList = scoop list
echo $scoopList

doesn't seem to work, as the variables are empty.
I have barely any knowledge with pwsh scripts, but I believe this is not the "default" behaviour for commands like this.
Anyone have any ideas to help me with this?

https://github.com/lukesampson/scoop/issues/1543#issuecomment-341551437

Thank you! I tried to search for it but was unsuccessful. I have used scoop export before, so I should have tried that myself.


yargs cannot be found

With<EMAIL_ADDRESS>if I run npx j2w, I see the following:
><> npx j2w
node:internal/modules/esm/resolve:854
  throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
        ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'yargs' imported from<EMAIL_ADDRESS>    at packageResolve (node:internal/modules/esm/resolve:854:9)
    at moduleResolve (node:internal/modules/esm/resolve:927:18)
    at defaultResolve (node:internal/modules/esm/resolve:1157:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:390:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:359:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:234:38)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:87:39)
    at link (node:internal/modules/esm/module_job:86:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

Node.js v20.12.2

This is resolved if I run npm install -D yargs.
><> npm install -D yargs

added 13 packages, and audited 411 packages in 706ms

148 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
><> npx j2w
Options:
      --help                Show help                                  [boolean]
      --version             Show version number                        [boolean]
  -i, --input               Path to the input file                    [required]
  -d, --wit-path            Path to wit file or folder                [required]
  -o, --output              Path to the output file  [default: "component.wasm"]
      --trigger-type, ---n  Spin trigger to target
                                               [required] [choices: "spin-http"]

Missing required arguments: input, wit-path, trigger-type

I'm wondering if yargs should be added as a dependency of this project rather than a devDependency. What do you think?
https://github.com/fermyon/spin-js-sdk/blob/feat/sdk-v2/package.json#L19

I am not able to reproduce this locally. The template does specify a devDependency on yargs https://github.com/fermyon/spin-js-sdk/blob/99a38550a608c768f4d0bdb413acad102bb35fb0/templates/http-ts/content/package.json#L20
But I think you are correct in suggesting that it needs to be a dependency and not a devDependency.  I think we can remove yargs and componentize-js from the dev dependency list on the template once those 2 are added as prod dependencies to the SDK package.

It works if you use the ts template, but it doesn't work if you try to install this package in a standalone app (choose your own adventure style 😄).
Here is how I was able to reproduce this locally:
><> mkdir myapp
><> cd myapp
><> npm init
><> npm install @fermyon/spin-sdk
><> npx j2w
node:internal/modules/esm/resolve:854
  throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
        ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@bytecodealliance/componentize-js' imported from<EMAIL_ADDRESS>    at packageResolve (node:internal/modules/esm/resolve:854:9)
    at moduleResolve (node:internal/modules/esm/resolve:927:18)
    at defaultResolve (node:internal/modules/esm/resolve:1157:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:390:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:359:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:234:38)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:87:39)
    at link (node:internal/modules/esm/module_job:86:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

Node.js v20.12.2

Fix for ^^:
><> npm install -D @bytecodealliance/componentize-js
><> npm install -D yargs

Ah! We should add both those packages as prod dependencies on the SDK package. That should fix it.

This works on the latest release. Closing.


refactor with hooks❗❗

❗❗❗❗❗❗IMPORTANT NOTE: If you already use functional components, you can create a GitHub issue in which you describe how you use functional components and ask for a code review based on your issue.
=>  Today's project was to use functional components by applying hooks if the previous components are class components. I used functional components by doing the following things.

I created two functional components which are Button and Calculator.

Button component is A child component that receives data from its parent element which is Calculator.

I used useState hook to add state to a calculator  component

In this project case I used one state variable called calculatorObj and state modifier setCalculatorObj which is a function that can modify the state variable calculatorObj

I initialized the value of calculatorObj as an empty object { }  by using useState as const [calculatorObj, setCalculatorObj] = useState({});

Then I define anevent handler function in which is handleClick(e) and it will update calculatorObj by calling its updater function (setCalculatorObj).

I send this event handler function to the child component which is Button as a props for it, and this will handle the event for each button click in the calculator and it updates the calculatorObj accordingly.

I also applied defualtPropes  and PropTypes in the child component which is Button, since it accepts all state variables(properties of calculatorObj) object as props.

These things describe more or less how I used functional components in my project

STATUS: APPROVED ✅

Hi @fithamlak , 🥰

Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit: Congratulations! 🎉

Highlights
✅ ... Good commit messages
✅ ... Green linters

Optional suggestions

Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.

Cheers and Happy coding!👏👏👏

Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me(@joskalenda) in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Support rate-limited item insertion

This was requested by @nathanwl88
I propose adding a wrapper around the work queue that would have essentially the same methods, except that the method for adding an item takes both an item and a new rate limiting tag (a string).
Each rate limiting tag would have an optional rate limit (in items per second, items per minute, or some similar unit).
If the rate of item insertion exceeds the limit, new items would be placed in a separate queue, and only added into the main queue at the rate specified by the rate limit.
Example
Let's suppose there are two rate limiting tags, foo (with a rate limit of 10 items per minute) and bar (with a rate limit of 20 items per minute).
In the first minute, if 15 items are added with tag foo, and a further 30 with tag bar, then the first 10 with the tag foo would enter the main queue, along with the first 20 with the tag `bar.
Then, in the second minute, the overflowing items from the previous minute are added. If 10 items were added with the foo tag, 5 of those would end up in the main queue (after those from the first minute).
Finally, in the third minute, the final 5 items with the foo tag would be added to the main queue.

@nathanwl88 would that do everything you need it to?

@JOT85 this sounds perfect


Overlay BlackScreen in cs2 example code

When I run this script I just have a black screen and I had tried to clicking and pressing any buttons it doesn`t work for me idk. My friend said that its working for him. Can anyone help?

For BlackScreen issue:
https://github.com/raysan5/raylib/issues/2932


[BUG] (type-safe-api) generated hooks don't compile for mismatching parameter names

Describe the bug
The following Smithy model generates hooks code which doesn't compile, since the name used in the @httpQuery("myInToken") trait is the actual name used in the generated clients/handlers (since this in the generated OpenAPI spec), but the value from the paginated trait is used in the generated hooks which points to the Smithy member name.
@readonly
@http(method: "GET", uri: "/my-list-operation")
@handler(language: "typescript")
@paginated(inputToken: "inToken", outputToken: "outToken", items: "messages")
operation MyListOperation {
    input := {
        @httpQuery("myInToken")
        inToken: String
    }
    output := {
        @required
        messages: Messages

        outToken: String
    }
}

list Messages {
    member: String
}

Expected Behavior
Code to compile
Current Behavior
api-typescript-react-query-hooks: src/apis/DefaultApiClientProvider.tsx(39,42): error TS2322: Type '{ children: Element; client: QueryClient; context: Context<QueryClient>; }' is not assignable to type 'IntrinsicAttributes & QueryClientProviderProps'.
api-typescript-react-query-hooks:   Property 'context' does not exist on type 'IntrinsicAttributes & QueryClientProviderProps'.
api-typescript-react-query-hooks: src/apis/DefaultApiHooks.ts(54,96): error TS2345: Argument of type '{ inToken: any; name: string; myInToken?: string; }' is not assignable to parameter of type 'SayHelloRequest'.
api-typescript-react-query-hooks:   Object literal may only specify known properties, but 'inToken' does not exist in type 'SayHelloRequest'. Did you mean to write 'myInToken'?
api-typescript-react-query-hooks: src/apis/DefaultApiHooks.ts(54,119): error TS2554: Expected 1-2 arguments, but got 3.
api-typescript-react-query-hooks: 👾 Task "build » compile" failed when executing "tsc --build" (cwd: /Users/jacsteve/stuff/random/tsapi-test-3/packages/api/generated/libraries/typescript-react-query-hooks)

Reproduction Steps
Use Smithy operation above and enable the hooks library.
Possible Solution
Either validate away this case or map the values in the rendered x-paginated extension to point to the OpenAPI name.
Additional Information/Context
No response
PDK version used
0.22.13
What languages are you seeing this issue on?
Typescript, Java, Python
Environment details (OS name and version, etc.)
OSX

It happens during the walkthrough in doc https://aws.github.io/aws-pdk/getting_started/your_first_aws_pdk_project.html
myapi-typescript-react-query-hooks: 👾 build » compile | tsc --build myapi-typescript-react-query-hooks: src/apis/DefaultApiClientProvider.tsx(39,42): error TS2322: Type '{ children: Element; client: QueryClient; context: Context<QueryClient>; }' is not assignable to type 'IntrinsicAttributes & QueryClientProviderProps'. myapi-typescript-react-query-hooks:   Property 'context' does not exist on type 'IntrinsicAttributes & QueryClientProviderProps'. myapi-typescript-react-query-hooks: src/apis/DefaultApiHooks.ts(54,71): error TS2554: Expected 1-2 arguments, but got 3. myapi-typescript-react-query-hooks: 👾 Task "build » compile" failed when executing "tsc --build" (cwd: /Users/pengcao/workspace/my-project/packages/api/generated/libraries/typescript-react-query-hooks)

Thanks! It looks like the error here is due to some breaking changes in a new version of React query that was released last night: https://tanstack.com/blog/announcing-tanstack-query-v5
I'm working on a fix for both of these issues and will raise a PR shortly! :)

For now, as a workaround you can add the following to your .projenrc.ts after creating the TypeSafeApiProject:
api.library.typescriptReactQueryHooks!.addDeps("@tanstack/react-query@^4");

The fix has been released in version 0.22.17! You can upgrade an existing project with the command:
npx npm-check-updates -u --deep @aws/pdk

You'll then need to re-synth before building again:
pdk
pdk build


FileSystemException,Show Blank Screen on mac m1 after issuing flutter run -d macos

OS: macOS 11.4 20F71 arm64
Flutter version 2.2.2

2021-07-04 07:31:04.445 Sidekick[38573:441063] NSWindow warning: adding an unknown subview: <NSVisualEffectView: 0x7fd5b176d310>. Break on NSLog to debug.
2021-07-04 07:31:04.469 Sidekick[38573:441063] Call stack:
(
	0   AppKit                              0x00007fff22b89d55 -[NSThemeFrame addSubview:] + 112
	1   AppKit                              0x00007fff22bcdf6c -[NSView replaceSubview:with:] + 154
	2   Sidekick                            0x0000000104f56d27 $s8Sidekick17MainFlutterWindowC12awakeFromNibyyF + 1623
	3   Sidekick                            0x0000000104f5706b $s8Sidekick17MainFlutterWindowC12awakeFromNibyyFTo + 43
	4   CoreFoundation                      0x00007fff2042c25c -[NSSet makeObjectsPerformSelector:] + 215
	5   AppKit                              0x00007fff22b3f086 -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] + 1368
	6   AppKit                              0x00007fff22b33778 loadNib + 392
	7   AppKit                              0x00007fff22b32d84 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 693
	8   AppKit                              0x00007fff22b329da -[NSBundle(NSNibLoading) loadNibNamed:owner:topLevelObjects:] + 201
	9   AppKit                              0x00007fff22b327b8 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 394
	10  AppKit                              0x00007fff22b25382 NSApplicationMain + 566
	11  Sidekick                            0x0000000104f57e9d main + 13
	12  libdyld.dylib                       0x00007fff20359f5d start + 1
	13  ???                                 0x0000000000000001 0x0 + 1
)
[ERROR:flutter/lib/ui/ui_dart_state.cc(199)] Unhandled Exception: FileSystemException: Cannot copy file to '/Users/uriah/Library/Application Support/app.fvm.sidekick/settings_box.lock', path = '/Users/uriah/Documents/settings_box.lock' (OS Error: Interrupted system call, errno = 4)
#0      _File.throwIfError (dart:io/file_impl.dart:635:7)
#1      _File.copySync (dart:io/file_impl.dart:340:5)
#2      checkMigration (package:sidekick/src/modules/common/utils/migrateFiles.dart:28:12)
<asynchronous suspension>
#3      main (package:sidekick/main.dart:31:3)
<asynchronous suspension>

Hey! Seems that there was an issue migrating the settings to the new location. Let me investigate this


⚠ ClamAV has degraded performance

In 9c7f66b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 547 ms

Resolved: ClamAV performance has improved in ecd14b1.


[Feature][Connector-V2] Add oss source connector

Purpose of this pull request
#1946 Oss source connector

Check list

[x] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

@CalvinKirs pls review,thx.

can you add testcase into flink、spark e2e module？


feat: add Docker-only playbook

I found we must provide a way to install only Docker for the users who choose the Docker installation since they don't need ROS or CUDA in their local machine.

Build CI: https://github.com/autowarefoundation/autoware/actions/runs/1789591224


Update the DBS emulator and DBSReader

This is the PR that should run correctly
Update DBS to promote strings to unicode in some places to minimize the data we need for the mocked Emulator
Handle the special case where we ask DBS about a list of LFNs by constructing the list out of individual bits of cached data
Add more data to make WorkQueue tests happy

test this please

@ticoann please merge. Failures are pylint trying to check JSON and missing imports in init.py

I don't think unicode change will affect anything but since there is change in DBS3Reader I will run the quick test before merging it.

+1 @ticoann

tested in vm for cmsweb applicaiton (GQ). Agent need to be tested (will do after merge and create rpm)


Build JoypadLinux sandbox detection method only with udev

Fixes an unused-function warning when building with udev=no.
As usual, I've tested this on my Wayland branch. I'm saying this just in case something weird happens.

Thanks!

Cherry-picked for 4.0.4.

Cherry-picked for 3.6.

Cherry-picked for 3.5.3.


Upgrade to NServiceBus v6

Any chance this is in the pipeline?

Of course. Do you have any predefined timeline? Optionally you can always contribute 😁


Can’t remove middleware from the stack

Is your feature request related to a problem? Please describe.
Currently it isn’t possible to remove a middleware from the stack even though it is added by a name.
Describe the solution you'd like
A new method should be added to remove middleware from the stack by its name. This should also clear the cached stack as it has been altered. Also consider if an exception is needed when removing something from the stack when not available or if it is allowed to fail silently.
Additional context
When using PHP 7.4 and only typed properties you don’t want to have the doc block middleware

Fixed in #32


References for AutoDan Initialization

I noticed that the references used for AutoDan in this repo (https://github.com/centerforaisafety/HarmBench/blob/7a8d195248cd73976c3317214ba584e4cc5a4e50/baselines/autodan/templates.py#L3) are different from the data in the official repo (https://github.com/SheltonLiu-N/AutoDAN/blob/main/assets/prompt_group.pth).
However, the reference in this repo seems more aligned with the examples in the paper. So I am confused now.

Hi @Jiaxin-Wen , seems like there was an update to the AutoDAN references prompt 3 weeks ago. Yet, the REFERENCES are just some initial variations from the author's intial prompt, which is initialized like this here.

Thanks, I realized that too.


Miscommunication with /droprate & BSO Wiki Custom Pets

🐛 Bug Report

seems the few pets under /droprate have the message that with each pet in cl, gets 1.5x rarer... but it doesn't match up with BSO Custom Pets .. meaning some of the pets in droprate say this when they don't have the footnote on the website & the rarer info is different than on the website.

I suggest you edit the wiki if its wrong.

I suggest you edit the wiki if its wrong.

I wasn't saying the wiki exactly was wrong. I was wondering if the command might be wrong.


Account flow PIN/notifications issue

During the account onboarding flow, after setting your PIN, we prompt you for notification permissions.

we probably don't want to pop that without asking first?
regardless, because you've set a PIN, when the system modal pops, it puts the app into background triggering PIN reauth right after you've set it which feels odd.

Is there a way to prevent auth from triggering on those system notification pops?

I'm also wondering if we want to make the pin optional during onboarding?

Pin should be required.

From: Matt Reetz<EMAIL_ADDRESS>Sent: Thursday, February 18, 2021 8:37:15 AM
To: helium/hotspot-app<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [helium/hotspot-app] Account flow PIN/notifications issue (#190)
I'm also wondering if we want to make the pin optional during onboarding?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/helium/hotspot-app/issues/190#issuecomment-781473349, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AETPRSV2AXE3XXHWSH4UMWLS7U63XANCNFSM4XPTIEXQ.


fix AtString parser

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 3 (66.67%)  changed or added relevant lines in 1 file are covered.
61 unchanged lines in 6 files lost coverage.
Overall coverage decreased (-0.7%) to 88.727%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/tokenizer.rs
2
3
66.67%

Files with Coverage Reduction
New Missed Lines
%

src/parser.rs
1
83.87%

src/tokenizer.rs
1
85.11%

tests/sqlparser_mysql.rs
1
99.5%

tests/sqlparser_snowflake.rs
3
96.39%

tests/sqlparser_postgres.rs
9
97.55%

tests/sqlparser_common.rs
46
96.82%

Totals

Change from base Build<PHONE_NUMBER>:
-0.7%

Covered Lines:
7186

Relevant Lines:
8099

💛  - Coveralls


Improve Scene and SceneManager to make rendering multi scenes much easier

First, improve the code.
Add scene.isActive property. Mostly, we needn't use sceneManager, just use scene.isActive to control which scenes should be rendered.

Can you help add unit tests for the new API?


System Stache plugin: Add dynamic imports to bundle

This updates the Stache plugin to add dynamic <can-import> statements
to the System.bundle configuration, thus making this step unnecessary
for users if using can-import for dynamic loading.

This seems to be doing some of the work that my can-stache-amd plugin does. Does this also work for amd based solutions?

No, Steal has a different plugin API than AMD.  In retrospect I wish we had made Steal fully AMD compliant and used the same plugin API.


feat: add adhoc debug logger package

This adds a new pseudo-mono-repo package for adhoc debug logging. It's meant to be pulled in across any library and/or GAPIC to provide the ability to do the equivalent of "printf debugging", but with filtering and a disable flag.
Working group spec doc available upon request :)
This is a duplicate of another PR so that we can engage the bot macguffins.

Merged the original somehow...


Access from index instead of connection

Context
I started djangoes by focusing on connections - it was my need back then. However, the more I think about my usage - and the more I use ES in real application - the more I would like something a bit different to make index management easier.
Example
$ django-admin shell
>>> from djangoes import es_index
>>> doc = es_index.get(3907, 'product')
>>> es_index.create('product', new_document_body, doc_id=7814)
>>> same_index_different_connection = es_index.using('task')

In this example I:

Get access to the default ES index,
Get a document from this ES index,
Create a document into this ES index,
Get a copy of the ES index handler with a different connection.

The last point in particular would allow one to handle different connection settings:

One with very low timeout configuration to serve HTML or end-user API (say, less than 100ms),
One with a very high timeout configuration to perform long-running task, such as huge aggregations and statistics (say, between 2 and 10s).

Problems to solve:

Keep backward compatibilities with djangoes.connections,
How to handle properly index's aliases?
And probably other issues I don't foresee.

While I want to keep an access to connections and connection, I'll break the backward compatibility with the auto-use of index/alias by a connection object: the right way to access to an index will be to use es_index.get(), and not connection.get().
The connection.get() will require one to provide an ES Index.
I plan to deprecate the index auto-use in connection in 0.4.0, and to remove it in 0.5.0.


Nonstandard\Fields implement Rfc4122\FieldsInterface?

I wonder why does Ramsey\Uuid\Nonstandard\Fields described as Nonstandard UUID fields do not conform to the RFC 4122 standard implement Ramsey\Uuid\Rfc4122\FieldsInterface that implies RFC 4122 compliance.
It seems confusing. Is the design intended?

This design is intended for backwards compatibility. If any UUIDs arise that are non-standard and have different field definitions, then I would create a separate Fields class and interface for them.

So there's no point for me trying to find any relation between non-standard and RFC 4122 UUIDs. It's just for lib BC design purposes. If it is so I guess we can close this.

The primary reason is for anyone who might get UUIDs from another source.
As part of 4.0, I increased the strictness of following RFC 4122 for standard UUIDs. As a result of this change in strictness, if anyone used Uuid::fromString() and the UUIDs were invalid (according to RFC 4122), then the library would throw an exception.
To avoid breaking everyone's apps (since many might have UUIDs that were generated somewhere else), I decided not to throw an exception and, rather, use a different type for these UUIDs (Nonstandard\Uuid). However, non-standard UUIDs (unless using some other defined standard for them) might really have intended as regular RFC 4122 UUIDs, but whatever generated them could have put the version/variant bits in the wrong places (or not set them at all).
As a result, I err on the side of caution here and assume it's supposed to have the same fields as an RFC 4122 UUID.
I hope this makes sense. 😁

Crystal clear, thanks for explanation and great lib!


Automatically promote build to MavenCentral in production job

Can't use gradle-nexus/publish-plugin to make the release (build promotion), because current implementation of said plugin requires promotion to happen at the same time as repository initialization.
Found out that Sonatype has a REST API (obviously, how else would the plugin work...) which I could just cURL, but the docs are somewhat lacking. Maybe I used the wrong keywords... https://oss.sonatype.org/nexus-staging-plugin/default/docs/rest.html

It works. Ugly, because I will hate maintaining this, but it works.
$ export stagedRepositoryId=comviliussutkus89-1149
$ curl -u token:pass --request GET https://oss.sonatype.org/service/local/staging/repository/${stagedRepositoryId} | grep profileId
<profileId>xxxxx</profileId>
$ export profileId=xxxxx

$ curl -u token:pass --request POST \
--data "<promoteRequest><data><stagedRepositoryId>${stagedRepositoryId}</stagedRepositoryId></data></promoteRequest>" \ --header 'Content-Type:application/xml' \
https://oss.sonatype.org/service/local/staging/profiles/${profileId}/promote

Promotion takes up to 10 minutes, so I cannot make the GitHub release right away.

Central sync is activated for com.viliussutkus89. After you successfully release, your component will be published to Central https://repo1.maven.org/maven2/, typically within 10 minutes, though updates to https://search.maven.org can take up to two hours.

Proper way would be splitting the release job into two and adding a timed gate of 5 minutes and doing a sleepy spinlock at the start of the second job.
export releasedVersion=1.0.something
curl --head https://repo1.maven.org/maven2/com/viliussutkus89/samplelib/${releasedVersion}/samplelib-${releasedVersion}.aar

[CD] Issue #2. Promote staging repo to MavenCentral through CD, not m… privilegedBuild #12

First automated release. Still need to split up the Release job, to not burn the CPU for 8 minutes.


Fixes #2576 by saving all attributes on the img tag.

Alright, this latest 'fail' I think is the result of a poorly written test. The test asserts that
array('Test', 'Test<concrete-picture fID="1" alt="" style="" />'),

This is failing because the new code doesn't arbitrarily add empty attributes. I'd propose changing to to:
array('Test', 'Test<concrete-picture fID="1" />'),
array('Test', 'Test<concrete-picture fID="1" alt="Woohoo" style="display: block" />'),

Alternatively, if there's a good reason why the empty attributes should be there, I can force those to already output.

:thumbsup:
I tested the code and it applies the attributes to the img tag on save as expected.
Regarding any confusion relating to the placement of attributes.
http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-picture-element
"While all of them contain source elements, the sourceelement's src attribute has no meaning when the element is nested within a picture element, and the resource selection algorithm is different. As well, thepicture element itself does not display anything; it merely provides a context for its contained img element that enables it to choose from multiple URLs"

No, there's no need to output the empty attributes. We probably just need to update the test so that it passes and then we'll get the pull request applied.

@aembler
Will this fix be part of the next release?

Thanks!


Update .gitignore files

ignore the intermediates files while generating doc locally

It'd be nice if these could get generated into _build, but I don't know if there's actually a way to make that happen.

It'd be nice if these could get generated into _build, but I don't know if there's actually a way to make that happen.

That's true. I'll think about it. If possible, might change it back later.


{App Service} az appservice ase: Fix issue with resource group in new SDK

Description
Change resource group to be fetched from the resource id of the ASE. The issue occurs if you call commands without explicitly defining the resource group.
Testing Guide
az appservice ase list-addresses -n
History Notes

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

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

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

App Service

@madsd like we discussed offline please create a task/issue for ASE to team to update the swagger to include the missing property so that the next SDK drop will have this, instead of CLI/client making the changes to handle this.
This can be a temporary work around for CLI, property missing on SDK/swagger would be a breaking change & if this is not expected, this should be fixed at the source correctly. Thanks!

/azp run


use paket for build dependency

Cool, this seems like a good plan. I guess it should be possible to make the changes to the build.fsx master and then avoid committing it locally? (.gitignore paket-files - is that the usual thing to do?)
Definitely better than git submodules if so! Thank you for doing this, it's appreciated :)

Thanks again :)


dataset structure setting

Hello, I would like to ask about the structure of the Real-IAD dataset, what specific images correspond to the 'OK' and 'NG' folders under each category? What do the 'AK', 'HS', 'PS', and other folders in the 'NG' folder represent? Why are these classifications made?

OK represents normal images, while NG represents anomalous images. AK, HS, PS, and others correspond to specific defect types. For more details, please refer to the descriptions in the paper.

I'm very sorry I found eight types of defects in the paper, but not the corresponding abbreviations


Misleading Variable-Description

Hello,
Thanks for this awesome Module.
While trying it out I ran into a problem. The description of the variable enable_manage_gitlab_token is kind of misleading.
variable "enable_manage_gitlab_token" {
  description = "Boolean to enable the management of the GitLab token in SSM. If `true` the Gitlab token will be managed via terraform state. If `false` the token will still be stored in SSM however, it will not be managed via terraform."
  default     = true
}

The first sentence of the description states, that this will enable the management via SSM. But the following sentences are implying the opposite.
As I want to manage it in terraform I thought the default-value would be great, when reading the description (aside the first sentence) in conjunction with the variable_name (since we are in terraform and i would like to enable the management via terraform)
Looking at main.tf it gets clear, that the first sentence of the description is telling the truth.
Besides the semantical point of view the description should be updated anyways imho.
Best regards

@solutionDrive-Alt thanks for the remark. Feel free to create a PR. Otherwise I will do my best to update the docs in the next weeks

@npalm I just created the PR #86 for that.

Fixed


Update to Azure Functions Python to 3.8

Update to Python 3.8 using mcr.microsoft.com/vscode/devcontainers/python:3.8
Update Azure Functions Core Tools to version 3

Resolves #270

LGTM! Thanks!


Nested gradients break colors

<gradient:#1985ff:#2bc7ff>Outer <GRAY>gray</GRAY></gradient>

Works fine, right? Now, adding an inner gradient will break the gray color:
<gradient:#1985ff:#2bc7ff>Outer <gradient:#00fffb:#00ffc3>inner</gradient> <GRAY>gray</GRAY></gradient>

You can reproduce it here: https://webui.adventure.kyori.net/
Weirdly, replacing <GRAY>gray</GRAY> with <GRAY><GRAY><GRAY>gray</GRAY> will make it work. Furthermore, once I replace any of the gradients with a solid color, it will work as well.

@zml2008 Might need to be re-opened. I'm still getting the issue on 4.10.0-SNAPSHOT with strings like <gradient:white:blue>A <gradient:yellow:black>B <WHITE>C


⚠ Bofrost.lu has degraded performance

In ba6f30b, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2330 ms

Resolved: Bofrost.lu performance has improved in a015c6f after 13 minutes.


Update RAP to 3.7.0

Currently webSpoon uses version 3.6.0 of RAP but needs to update it to 3.7.0.
Otherwise non-printable keys (Home, End, Tab, Escape, Backspace, Page Down, arrows, etc.) do not function as expected on Firefox 65 and later.
https://eclipsesource.com/blogs/2018/10/21/firefox-64-change-breaks-key-navigation-in-web-frameworks-including-eclipse-rap/
https://www.fxsitecompat.com/en-CA/docs/2018/non-printable-keys-no-longer-fire-keypress-event/

Firefox 65 is scheduled to be released on Jan. 29, 2019.
https://wiki.mozilla.org/Release_Management/Calendar


LWT does not reach Pulsar topic, short cuts QoSPublishHandlers so Qos nor Retain function properly

Describe the bug
LWT does not function as expected. LWTs never reach Pulsar topics, instead the logic seems to be that when an LWT is fired it short cuts straight to finding each MQTT Connection with a subscription on that LWT's topic and then send the LWT directly to that client. This means that LWT's never even reach the QosPublishHandlers, which means an LWT's QoS will not be respected nor will the retain feature work for LWT messages because the QoSPublishHandler is responsible for the retain logic. Most importantly the LWT only reach other MoP connected clients. Currently if you try to send a retained LWT by killing a client and waiting for the connection to timeout, and then you reconnect you will not see the message via MQTT nor Pulsar. If you have a pulsar client connected and get an MQTT conenction to fire an LWT, you will never see it. The only way I can see LWTs is if I connect 2 MQTT clients, and kill one of them while the other has an active subscription on the other topic. Reading through the source code only confirms this behavior.
To Reproduce
Steps to reproduce the behavior:

Start a Pulsar client on a given topic, eg persistent://public/default/test_lwt
Create an MQTT client with an LWT on that topic, additionally set the retain flag
Create a second MQTT client with a subscription on that topic.
Kill the first MQTT client to prevent a graceful disconnect, wait for connection to timeout
The second MQTT client will see the LWT, the Pulsar client will NOT
Connect an additional MQTT client and subscribe on the test topic, you will not see a retained LWT on that topic.

Expected behavior
LWT QoS and retain should function the same as a regular MQTT message. LWTs should reach their destination Pulsar topic.

Working towards a PR on this issue currently.

@mattisonchao @Technoboy- 5 min of your time please


Max batch size

Hello,
It would be helpful to clarify which of the quotas applies to message batches when sent using SendMessagesAsync(ServiceBusMessageBatch). I assume it's 256 KB but the "Message size for a queue, topic, or subscription entity" section does not specify that it applies to batches also.
This page is referenced from the SendMessagesAsync for the batch size limit.
Thanks,
Aleksey

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

ID: 17b26254-ce8c-76eb-c3e9-b80c3ecc45ba
Version Independent ID: fc16f0d4-dae7-8494-e25a-6c5398215b4b
Content: Microsoft Azure Service Bus quotas and limits - Azure Service Bus
Content Source: articles/service-bus-messaging/service-bus-quotas.md
Service: service-bus-messaging
GitHub Login: @spelluru
Microsoft Alias: spelluru

@Aleksey-Kudryavtsev
Thanks for your feedback! We will investigate and update as appropriate.

#reassign: EldertGrootenboer
@EldertGrootenboer

We are adding this to the quotas article. The update will go live before the end of the day.
The maximum size for batches is 256 KB for the Standard tier, and 1MB for the Premium tier.

#please-close


Implementation in mmdetection3d

Do you have any plan to implement ST3D/ST3D++ in mmdetection3d?
If not, do you have any advice for me regarding re-implementing this framework in mmdetection3d?

No. We don't have such plan as MMDet3D is highly integrated. Actually, the ST3D code can be easily decouble from original OpenPCDet. You should take care this function, we apply abs for ignored pseudo labels, whose category id is set to -1.
https://github.com/CVMI-Lab/ST3D/blob/94acba3ccc4718c4fa3a9094a732a92699568d18/pcdet/models/dense_heads/target_assigner/axis_aligned_target_assigner.py#L51-L54
For others, just take care of some functions in dataset for loading pseudo labels.


UserWarning: The name 'vnc_bp' is already registered for this blueprint. Use 'name=' to provide a unique name. This will become an error in Flask 2.1.

I have added a print statement inside flask.blueprints.register and I only see one printout for my "vnc_bp"... yet I still get this error. I've had to retain an older version that still just warns, rather than raises.

The blueprints are being registered through this websocket middleware:
https://github.com/heroku-python/flask-sockets/

I can't reproduce this issue with the information provided. I'd look at what flask.blueprints contains as you register your blueprints, to start debugging. Likely you've got two blueprints with the same name somewhere along the line.
Please use our Discord for discussion about your own code. This tracker is for issues related to the project itself.


changes for liberty-maven-plugin release

You can remove line 42 and 51 and 110 since package-server goal defaults to ${project.build.directory}/${project.artifactId}.zip for usr type package and ${project.build.directory}/${project.artifactId}.jar for runnable package type

Instruction for Running with Maven running in README.md
This project can be built with Apache Maven. The project uses Liberty Maven Plug-in to automatically download and install Liberty profile with Java EE7 Web Profile   runtime from the Liberty repository Maven Central. Liberty Maven Plug-in is also used to create, configure, and run the application on the Liberty server.