tool: add rds probe in pilot_cli

Redefine arg res
Add arg proxytag
See examples below
./debug  --type=lds --proxytype=sidecar --proxytag=pod1
./debug  --type=cds --proxytype=sidecar --proxytag=pod1

./debug  --type=eds --proxytype=sidecar --proxytag=pod1 --res="outbound|80||heapster.kube-system.svc.cluster.local"
./debug  --type=rds --proxytype=sidecar --proxytag=pod1 --res=9090

Signed-off-by: Yuchen Dai<EMAIL_ADDRESS>Please provide a description for what this PR is for.
And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[x] Developer Infrastructure

@silentdai: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
b8b9b5c260db0f86f0168d71f07402969424f722
link
/test integ-new-install-k8s-presubmit-tests-master

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

@silentdai: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test integ-new-install-k8s-presubmit-tests-master

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

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test integ-new-install-k8s-presubmit-tests-master

istio-pilot-multicluster-e2e-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-pilot-multicluster-e2e-master

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

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test integ-new-install-k8s-presubmit-tests-master

istio-pilot-multicluster-e2e-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-pilot-multicluster-e2e-master

istio-unit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-unit-tests-master

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

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test integ-new-install-k8s-presubmit-tests-master

istio-pilot-multicluster-e2e-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-pilot-multicluster-e2e-master

istio-unit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-unit-tests-master

istio-racetest-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-racetest-master

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

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test integ-new-install-k8s-presubmit-tests-master

istio-pilot-multicluster-e2e-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-pilot-multicluster-e2e-master

istio-unit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-unit-tests-master

istio-racetest-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-racetest-master

istio-codecov-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-codecov-master

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

/retest

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-pilot-multicluster-e2e-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-pilot-multicluster-e2e-master

istio-unit-tests-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-unit-tests-master

istio-racetest-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-racetest-master

istio-codecov-master
8833420b919616d16d358ba2652f08349d270b78
link
/test istio-codecov-master

integ-new-install-k8s-presubmit-tests-master
eacdf84ef5ccb8974444e16d2b2be64621c4016e
link
/test integ-new-install-k8s-presubmit-tests-master

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


Add mention to PREVRANDAO as a possible source of randomness

Since the merge, the Ethereum network has replaced block difficulty with the random number that determined which validator gets to validate a block.
It's used by OpenSea's SeaDrop when trying to shift all token IDs by some random number to ensure a fairer distribution:
https://github.com/ProjectOpenSea/seadrop/blob/main/src/extensions/ERC721PartnerSeaDropRandomOffset.sol#L68
More about it here: https://soliditydeveloper.com/prevrandao

Thanks for the valuable info. Unfortunately I do not intend to maintain this repo as I do not find the time to actively follow the recent developments.


⚠ Bofrost.fr has degraded performance

In 2cb5d85, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1573 ms

Resolved: Bofrost.fr performance has improved in b0fcffb after 6 minutes.


variables and more step types for workflow

This is probably as big a chunk as we should consider in one go.  It builds on #1358 (also including the small #1359 and #1360) to add:

step types around {set,clear}-{sensor,config,workflow-variable}
inputs and outputs to workflow and individual steps
expression resolution (using freemarker templates) for inputs, outputs, workflow variables
a workflow for defining custom steps and nested workflow
tidy up to log framework for testing

The new and updated test cases are probably the best place to start, to understand this.


chat section needs to improve for further support. It shows unavailability multiple times

Is your feature request related to a problem? Please describe.
Just for better performance and availability
Describe the solution you'd like.
needs to upgrade using processing languages or maybe AI
Describe alternatives you've considered.
No response
Additional context.
No response
Show us the magic with screenshots
No response
Checklist

[X] I have checked the Existing Issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue. (optional)

Can you plz assign me for this?

Give proper description of what you want to do to the chatbot please

Give proper description of what you want to do to the chatbot please

Yes! wanna improve chatbot section for better performance

what is wrong with it now ??

what is wrong with it now ??

see this

okay i am assigning this to you but books on what exactly you want to add in this chatbot

sure go ahead
Make sure to join the discord server for further communication
Don't forget to star the repository
Complete the task in next 2 days and kindly mention your issue # in your pr like this:
Closes #IssueNumber
Note: the level of the issue may change based on the quality of the PR code

sure go ahead
Make sure to join the discord server for further communication
Don't forget to star the repository
Complete the task in next 2 days and kindly mention your issue # in your pr like this:
Closes #IssueNumber
Note: the level of the issue may change based on the quality of the PR code

Sure!

Its been weeks and no pull request was made so we are closing this issue.


Invalid memory address or nil pointer dereference on server.Finish()

All of my tests in a single main_test.go file at the root of my project. They run cleanly until the very end, when I get this error:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1a4cea]

goroutine 1 [running]:
panic(0x5846e0, 0xc42000c0e0)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/adams-sarah/test2doc/test.(*Server).Finish(0x0)
        /Users/robinkim/irisvr/irisvr_go/src/github.com/adams-sarah/test2doc/test/server.go:42 +0x3a
irv_orgs.TestMain(0xc42637fee8)
        /Users/robinkim/irisvr/irisvr_go/src/irv_orgs/main_test.go:31 +0x4f
main.main()

I'm using gorilla mux and have set up my tests as follows:
var server *test.Server

func TestMain(m *testing.M) {
	setup()
	tests := m.Run()
	DropDatabase()
	server.Finish()  // <--- fails here
	os.Exit(tests)
}

func setup() {
	...
	test.RegisterURLVarExtractor(mux.Vars)
	server, err := test.NewServer(routes)
	if err != nil {
		panic(err.Error())
	}
	...
}

UPDATE
According to the stack trace, the finish command fails at this line: https://github.com/adams-sarah/test2doc/blob/master/test/server.go#L42
It says that the s *Server argument is <nil>. Will continue digging.

@Robinnnnn
this is because you are instantiating a new server variable in setup(). So your package-level server variable at the top is never being set.
Your setup func should instead read:
	test.RegisterURLVarExtractor(mux.Vars)
	var err error
	server, err = test.NewServer(routes)
	if err != nil {
		panic(err.Error())
	}

You're right, my bad about that


When using  component, the first [1] element has an unnecessary, extra line

Describe the Bug

I'm on safari.  There is a minor artefact with how [1] is rendered. Link: https://humanloop.com/docs/v5/guides/evals/create-dataset
Information to Reproduce
Open https://humanloop.com/docs/v5/guides/evals/create-dataset in safari and check [1] element

Confirming that I've reproduced this issue and can see the small extra line above the [1].
I don't plan to prioritize this work given the low impact. @olehvell-h if you want to contribute the fix, here's a link to the step component


Support embrace-io/embrace-apple-sdk.

Related Slack thread.
There are two issues:

The EmbraceObjCUtilsInternal module has two module map files. The existing rules_swift_package_manager code treats this as an error. The fix is to warn the client and just use the first one that is found.
The GRDB.swift package, a transitive dependency, defines a systemLibrary target. rules_swift_package_manager does not yet support these target types.

@cgrindel what does it take to support packages with system library targets? Is the change complex?

what does it take to support packages with system library targets? Is the change complex?

Probably not. I have not dug into it. I would look at how SPM builds targets linked to these libraries. There is a flag which tells SPM to output its build commands. Then, it is a matter of generating the appropriate targets here.

I'll have some time next weekend to attend this issue. Thank you both for references.

SystemLibrary Support Draft PR: #1323

Duplicate of #248, thanks for working on this @lucasmarcal-faire!


Add python 3.11 to CI

Possible issue: pickles are created with the fractal-server python (e.g. py3.11), but their read with the remote-worker python (always 3.9, in the slurm CI). And "Cloudpickle can only be used to send objects between the exact same version of Python.".

Indeed, we hit a problem like this (notice that this is only for CI, we don't know whether it would work in real life):
fractal_server/app/runner/_slurm/executor.py:520 FractalSlurmExecutor._completion
    outdata: (
        b'\x80\x05\x95\xb0\x05\x00\x00\x00\x00\x00\x00\x89\x8c\x17cloudpickle.cloudpickle\x94\x8c\x14_make_skeleton_class\x94\x93\x94(\x8c\x08builtins\x94\x8c\x04type\x94\x93\x94\x8c\x0eExceptionProxy\x94h\x03\x8c\x06obje'
        b'ct\x94\x93\x94\x85\x94}\x94\x8c\n'
        b'__module__\x94\x8c\x08__main__\x94s\x8c 7aeb4d0fe0624bae924337e16c9ec0b1\x94Nt\x94R\x94\x8c\x1ccloudpickle.cloudpickle_fast\x94\x8c\x0f_class_setsta'
        b'te\x94\x93\x94h\x0f}\x94(h\x0bh\x0c\x8c\x07__doc__\x94Xj\x01\x00\x00\n'
        b'    Proxy class to serialise exceptions\n'
        b'\n'
        b'    In general exceptions are not serialisable. This proxy class saves the\n'
        b'    serialisable content of an exception. On the receiving end, it can be used\n'
        b'    to reconstruct a TaskExecutionError.\n'
        b'\n'
        b'    Attributes:\n'
        b'        exc_type_name: Name of the exception type\n'
        b'        tb: TBD\n'
        b'        args: TBD\n'
        b'        kwargs: TBD\n'
        b'    \x94\x8c\x08__init__\x94h\x00\x8c\x0e_make_function\x94\x93\x94(h\x00\x8c\r'
        b'_builtin_type\x94\x93\x94\x8c\x08CodeType\x94\x85\x94R\x94(K\x03K\x00K\x00K\x05K\x02KOC\x1e|\x01j\x00|\x00_\x01|\x02|\x00_\x02|\x03|\x00_\x03|\x04|\x00_\x04d\x00S\x00\x94N\x85\x94(\x8c\x08__name__\x94\x8c\r'
        b'exc_type_name\x94\x8c\x02tb\x94\x8c\x04args\x94\x8c\x06kwargs\x94t\x94(\x8c\x04self\x94\x8c\x08exc_type\x94h"h#h$t\x94\x8cQ/usr/local/lib/python3.9/dist-packages/frac'
        b'tal_server/app/runner/_slurm/remote.py\x94h\x16K*C\x08\x00\x03\x08\x01\x06\x01\x06\x01\x94))t\x94R\x94}\x94(\x8c\x0b__package__\x94\x8c fractal_server.app.runner._slu'
        b'rm\x94h h\x0c\x8c\x08__file__\x94h)uNNNt\x94R\x94h\x10\x8c\x12_function_setstate\x94\x93\x94h2}\x94}\x94(h h\x16\x8c\x0c__qualname__\x94\x8c\x17ExceptionProxy.__init__\x94\x8c\x0f__'
        b"annotations__\x94}\x94(h'\x8c\t_operator\x94\x8c\x07getitem\x94\x93\x94\x8c\x06typing\x94\x8c\x04Type\x94\x93\x94h\x03\x8c\r"
        b'BaseException\x94\x93\x94\x86\x94R\x94h"h=h>\x8c\x04List\x94\x93\x94h\x03\x8c\x03str\x94\x93\x94\x86\x94R\x94u\x8c\x0e__kwdefaults__\x94N\x8c\x0c__defaults__\x94Nh\x0bh\x0ch\x14N\x8c\x0b__closure__\x94N\x8c\x17_'
        b'cloudpickle_submodules\x94]\x94\x8c\x0b__globals__\x94}\x94u\x86\x94\x86R0\x8c\r'
        b'__slotnames__\x94]\x94u}\x94\x86\x94\x86R0)\x81\x94}\x94(h!\x8c\tTypeError\x94h"\x8c8TypeError: code() takes at most 16 arguments (18 given)\n'
        b'\x94h#\x8c,code() takes at most 16 arguments (18 given)\x94\x85\x94h$}\x94ub\x86\x94.'
    ) (bytes) len=1467
FAILED                                                                                [100%]
tests/test_backend_slurm.py:109 test_slurm_executor_submit - TypeError: code() argument 13 must be str, not int…

                from devtools import debug
                debug(outdata)
>               success, output = cloudpickle.loads(outdata)
E               TypeError: code() argument 13 must be str, not int

Note: the CI issue could be greatly simplified via https://github.com/fractal-analytics-platform/fractal-server/issues/686, but we still would not be able to run tasks with python 3.11 if fractal-server runs with <=3.10

Possible solution (to be checked): replace the cloudpickle.dump statement (which is currently executed as part of fractal-server) with the following procedure:

From fractal-server, call pickle.dump for the given object (note: pickle has better compatibility across python versions)
In a script (to be executed via subprocess.run, or even via FractalSlurmExecutor) that uses the correct python (that is, the one to be used to run the tasks): load the pickle and save it as a cloudpickle object.
Proceed as we currently do.

In this way (if we verify that it works) a fractal-server running for instance with python 3.9 would be able to run tasks with python 3.9, 3.10 and even 3.11 (the currently problematic one).

Additional info about pickle/cloudpickle:

It is to be checked whether pickle is not sufficient for our preliminary serialization, as opposed to cloudpickle.
Re: compatibility:

The pickle serialization format is guaranteed to be backwards compatible across Python releases provided a compatible pickle protocol is chosen and pickling and unpickling code deals with Python 2 to Python 3 type differences if your data is crossing that unique breaking change language boundary.
(https://docs.python.org/3/library/pickle.html)

Yet another (simpler) solution: when running the CI with python 3.11, always use 3.11 (rather than setting up tasks venvs with 3.9).

Also to do: check whether the current install of py 3.9 in the SLURM node in docker is needed, since we now moved to ubuntu-22 images.

We are now introducing Python3.11 in some tests, as of #1669.
Most of this was enabled by https://github.com/fractal-analytics-platform/fractal-server/pull/1663, and then we had a small gotcha with the representation of Enum values:
$ cat x.py
from enum import Enum

class MyEnum(str, Enum):
    KEY = "VALUE"

print(f"{MyEnum.KEY}")

$ python3.10 x.py
VALUE

$ python3.11 x.py
MyEnum.KEY


Remove dependency on Win32_Product in SPInstallPrereqs

Details of the scenario you try and problem that is occurring:
Currently the SPInstallPrereqs resource depends on the Win32_Product class to determine what is installed and what isn't. As per this article this query isn't optimised and can trigger some additional consistency checks, which should be avoided. All the checks in the get method for this resource should therefore use alternative approaches to determine what is installed and what isn't (either registry or file system checks)
The DSC configuration that is using the resource:
SPInstallPrereqs
Version of the Operating System and PowerShell the DSC Target Node is running:
n/a
Version of the DSC module you're using:
0.12 (but issue has existed since the very beginning at 0.2)

Linking this to an issue in the main DscResources repo

Made a fix for this issue: Pull request #340


Moved all tests into appropriate subpackages

Reorganizes unit tests so they are in the appropriate subpackages.

Ready to merge once tests pass.

There isn't really anything to review here since it just reorganizes existing tests and since this affects most other PRs I'm going to merge this myself now.


Notate the dashboards

The plots on the dashboards have no explanation and are often meaningless unless one knows how the numbers were produced (i.e. how is network delay measured?).

Let's use little tooltips/question mark icons.


strconv: incorrect bit size in ParseComplex code

This is not a bug, but a mistake in the code that made me think "how does this work?", and could be a bug waiting to happen. In the code for strconv.ParseComplex() (added in Go 1.15), it sets size to 128 by default (instead of 64), and passes that size to parseFloatPrefix. That function should really receive 64 for this case, but it currently happens to work with anything that's not 32, so this doesn't actually cause a bug. Here's the code for ParseComplex:
func ParseComplex(s string, bitSize int) (complex128, error) {
	size := 128
	if bitSize == 64 {
		size = 32 // complex64 uses float32 parts
	}
        // ...
	re, n, err := parseFloatPrefix(s, size)
        // ...
}

And parseFloatPrefix is defined as follows -- it handles anything other than bitSize == 32 as 64, so the invalid size of 128 happens to work:
func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
	if bitSize == 32 {
		f, n, err := atof32(s)
		return float64(f), n, err
	}
	return atof64(s)
}

So the minimal change would be to change the size := 128 to size := 64 in ParseComplex. But there were a couple of other things I saw while in there:

There don't seem to be any tests for ParseComplex with bitSize == 64 (two float32's): https://golang.org/src/strconv/atoc_test.go -- it doesn't seem good that we're not testing the code paths for each size. many of the bitSize 128 tests should work the same (and we could reuse those), but the range/overflow ones will need to be different.
There don't seem to be any tests at all for FormatComplex. I know it's pretty trivially defined in terms of FormatFloat, but there is some logic in it, and we should still have tests to avoid regressions.
It seems to me that parseFloatPrefix (and ParseFloat) should panic if bitSize is anything other than 64 or 128. FormatComplex already does this (code here), and so it seems for consistency (and to catch issues like this one) the other functions should do similar checks. ParseFloat and FormatFloat are clearly documented to only allow 32 and 64. Alternatively they could return an error for this case, but it seems to me errors should only be returned for bad input, not invalid types, so the panic is the right thing to do.

If folks agree, I'd be happy to put up a CL for these changes.

CC @griesemer

Fixing ParseComplex sounds fine.
I think it would be strange for ParseFloat to panic when it has an error return specified. Reporting errors in two different ways would just lead to confusion.
FormatFloat would need to panic, though (or return a "bad bit size" string).
More tests are always welcome.

@griesemer Thanks. I'm not sure how the Go project uses GitHub "assignees" -- but I'm hoping the fact you assigned yourself doesn't mean I can't submit a CL. :-) So I've submitted https://go-review.googlesource.com/c/go/+/248219/ with this fix and the addition of some tests -- see what you think. Details in commit message.


[Multiple File Upload] Bad screenreader feedback after adding a file

With VoiceOver on Chrome, after uploading a file, the screen reader says "Change file" rather than providing feedback after the action.
I'm not sure of the best fix for this, it's happening due to the default behavior on the USWDS widget. I imagine there is a javascript hack we would do to try to make this better.

I tried to fix this in a couple ways, mostly by putting various "live" roles on the "Uploading" tag that we show when someone presses add file. It didn't work. I think the problem is it's difficult to override the screen reader announcing the change to the USWDS widget.


ci: fix bin builds

The publish-github-release workflow wasn't working since we can't use interpolated environment variables in circleci paths. To get around this and keep the git tag in the name, I move each binary archive to a subdirectory named after its target, and then flatten these sub-directories before running ghr.
Successful workflow run: https://app.circleci.com/pipelines/github/shuttle-hq/shuttle/1391/workflows/8ce94b4f-d14f-456f-bf10-b1fd15575082

No problem, I got a much needed crash-course in the intricacies of circleci :smile:


Why is C++ used rather than C

Compared to most other tree sitter grammars, the Python one uses C++, i. e. scanner.cc which makes it much harder to use (because of the requirements to link the application with libstdc++) . I haven't managed to get it working using the Rust bindings on stable. Is there a good reason? It contradicts one of stared goals of tree sitter:

Dependency-free so that the runtime library (which is written in pure C) can be embedded in any application

I use it from Rust myself and have found it painless, since libc++/libstdc++ is available in almost every environment where a C compiler is available. C++ is also used in external scanners of other languages.
In the case of that file, we use C++ because of std::vector and std::string.

Thanks for this @maxbrunsfeld , would you mind sharing your build.rs that links with libstdc++? Have you tried linking statically (musl  needs some shimming as it doesn't support C++ out of the box)? On nightly, the following build directive is useful, but still won't just work:
println!("cargo:rustc-link-lib=static=stdc++");

Did you try the cpp method? It should just work.

Ha! Thanks for that, it does help set up the env for dynlib case (static linking against C++ still requires recompiling libstd++ against musl, I think).
However, it seems that compiling parser.c with a C++ compiler rather than C doesn't work
...
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
...

This seems to be as parser.c uses designated initializers syntax (i.e. .field = value) which is not valid C++ according to the standard:

Note: out-of-order designated initialization, nested designated initialization, mixing of designated initializers and regular initializers, and designated initialization of arrays are all supported in the C

Yeah, I think you need a c build and a C++ build.

Gotcha, makes sense -- I got it to work, thank you for the help.

FWIW, using C++ does seem to preclude static linking using musl

Yeah, if you're trying to avoid dependencies on libc/libc++, I can see how this would complicate things.
One reference I might use is Emscripten, which compiles code written in both C and C++ into self-contained WebAssembly bindings using mostly-unmodified source files from libc++.
I think that you could probably use the same approach to create a statically-linked native binary, by adding several source files and include flags from libc++ to your build.


arangosh --server.authentication false gives me 401: Unauthorized

I have a fresh install of ArangoDB 3.1.9 on Win10 64 bits. The server is up & running with auth enabled:
PS C:\Users\andre> arangod
2017-02-04T08:13:23Z [135116] INFO ArangoDB 3.1.9 [win64] 64bit, using VPack 0.1.30, ICU 54.1, V8 <IP_ADDRESS>, OpenSSL 1.0.2a 19 Mar 2015
2017-02-04T08:13:23Z [135116] INFO using SSL options: SSL_OP_CIPHER_SERVER_PREFERENCE, SSL_OP_TLS_ROLLBACK_BUG
2017-02-04T08:13:23Z [135116] INFO Authentication is turned on
2017-02-04T08:13:23Z [135116] INFO Authentication system only
2017-02-04T08:13:24Z [135116] INFO JavaScript using startup 'C:\ArangoDB\/usr/share/arangodb3/js', application 'C:\ArangoDB\var/lib/arangodb3-apps'
2017-02-04T08:13:39Z [135116] INFO In database '_system': Database is up-to-date (30109/standalone/existing)
2017-02-04T08:13:39Z [135116] INFO using endpoint 'http+tcp://<IP_ADDRESS>:8529' for non-encrypted requests
2017-02-04T08:13:44Z [135116] INFO ArangoDB (version 3.1.9 [win64]) is ready for business. Have fun!

Could not connect to endpoint 'http+tcp://<IP_ADDRESS>:8529', database: '_system', username: 'root'
Error message: '401: Unauthorized'

Type 'tutorial' for a tutorial or 'help' to see common examples
<IP_ADDRESS>:8529@_system>

I was not expecting that 401 error above. I thought --server.authentication false would take precedence over the default setting.
So far I have only the root user with a non-empty password.

Hi @andregs,
arangosh is a client for ArangoDB. A client can not disable the auth from ArangoDB.
If you have enabled auth in ArangoDB every client, including arangosh, have to authentificate itself.

Oh, it totally makes sense. But now I'm wondering what's the use of  --server.authentication false

If you have disabled authentication in the server, then arangosh would still always ask for a password when starting up. You can suppress this using --server.authentication false.

Thank you for your time, guys!


Bluetooth: gatt: allow disabling subscription enforcement

This introduces a new option that allows the user to disable the
subscription checking when notifying or indicating.
Some users might have use-cases where they would like to send notifications
or indications without the peer having to go through the subscription
process, as that is allowed by the Bluetooth specification.
Signed-off-by: Jonathan Rico<EMAIL_ADDRESS>

This introduces a new option that allows the user to disable the subscription checking when notifying or indicating.
Some users might have use-cases where they would like to send notifications or indications without the peer having to go through the subscription process, as that is allowed by the Bluetooth specification.

Can you provide an example of such a use case?

This introduces a new option that allows the user to disable the subscription checking when notifying or indicating.
Some users might have use-cases where they would like to send notifications or indications without the peer having to go through the subscription process, as that is allowed by the Bluetooth specification.

Can you provide an example of such a use case?

Not something I've seen in the wild. I don't remember the discussion exactly but I think it was so a low-mem device didn't need to perform discovery and subscription. Maybe it was with @alwa-nordic , did you suggest that?
Ah I think I found it, it was @Vudentz suggesting we leave the behavior as-is: https://github.com/zephyrproject-rtos/zephyr/pull/46136#discussion_r906855137

This introduces a new option that allows the user to disable the subscription checking when notifying or indicating.
Some users might have use-cases where they would like to send notifications or indications without the peer having to go through the subscription process, as that is allowed by the Bluetooth specification.

Can you provide an example of such a use case?

Not something I've seen in the wild. I don't remember the discussion exactly but I think it was so a low-mem device didn't need to perform discovery and subscription. Maybe it was with @alwa-nordic , did you suggest that? Ah I think I found it, it was @Vudentz suggesting we leave the behavior as-is: #46136 (comment)

Discovery cannot really be ignored; the notification will always just provide a handle, and without knowing what the handle refers to, this will most likely be impossible to use (unless the GATT server only has a single known notifiable characteristic).
If the handle is known, subscribing to it should be very easy (and does not require more than a single write).
I'll be happy to approve if we can come up with an actual usecase :)

Yeah I don't actually have one :) . Hence closing the PR. If anyone needs that option, GH has linked to the original PR introducing the check so people can easily find it.

There is no concrete use case for now, so we can wait until someone requests this.
The reasoning for why we want to allow this is that, in principle, the spec does not specify that CCC is the only mechanism for solicitation of notifications/indications. And I can for example easily imagine an alternative CCC where the client writes the desired notification frequency.

I believe I have a real world valid use case.
ZMK uses BAS, which works great against latest macOS and Linux, but Windows seems to simply read the value on pairing and then never updates.
Some users have used low level tools to force a subscription to the GATT characteristic, and then Windows properly updates the UI with the updated levels.
I don't have a Windows host to test, but everything points to Windows never subscribing to the notifications, but happily receiving them to update the peripheral battery level if it gets the notification.

alright then, reopening.

alright then, reopening.

It is still TBD if this will actual fix the issue, since it is only a theory so far.

Yeah, I've asked a couple folks to test this patch + Kconfig setting to see if it helps.

Ok, have had a user confirm by simply manually checking out that CCC check (since the patch here doesn't cleanly apply against our fork of Zephyr 3.0, and confirmed that Windows now properly updates the battery level when it changes.
So yes, Windows doesn't bother with the CCC subscription, just happily waits to receive notifications on that characteristic of BAS.

Ok, have had a user confirm by simply manually checking out that CCC check (since the patch here doesn't cleanly apply against our fork of Zephyr 3.0, and confirmed that Windows now properly updates the battery level when it changes.
So yes, Windows doesn't bother with the CCC subscription, just happily waits to receive notifications on that characteristic of BAS.

Interesting. I guess that does state a proper case for this PR (although it's clearly odd behavior from Windows...).

This is probably the tool @petejohanson mentioned earlier: https://github.com/joelspadin/BleBatterySubscribe
It does nothing but watch for new BLE devices, look for a battery level characteristic, and write GattClientCharacteristicConfigurationDescriptorValue.Notify to it. Then the battery level starts updating correctly, which seems to be a pretty good indication that Windows doesn't do that normally. I don't have any other standard BLE devices readily available to check their behavior with or without my hacky background service though.

This is probably the tool @petejohanson mentioned earlier: https://github.com/joelspadin/BleBatterySubscribe
It does nothing but watch for new BLE devices, look for a battery level characteristic, and write GattClientCharacteristicConfigurationDescriptorValue.Notify to it. Then the battery level starts updating correctly, which seems to be a pretty good indication that Windows doesn't do that normally. I don't have any other standard BLE devices readily available to check their behavior with or without my hacky background service though.

I wonder if the Microsoft Windows people are aware of this issue. Should be a quick fix, and since most BLE devices are battery powered, it's surprising that this isn't the case for them.
@joelspadin @petejohanson have we seen this with other OSes too? MacOS, Android, iOS?

I wonder if the Microsoft Windows people are aware of this issue. Should be a quick fix, and since most BLE devices are battery powered, it's surprising that this isn't the case for them.
@joelspadin @petejohanson have we seen this with other OSes too? MacOS, Android, iOS?

No, only Windows so far has behaved this way.
If someone knows the right place to report this to MSFT, probably would be a good idea. I don't have much confidence in that being an efficient process to fix though.

I wonder if the Microsoft Windows people are aware of this issue. Should be a quick fix, and since most BLE devices are battery powered, it's surprising that this isn't the case for them.
@joelspadin @petejohanson have we seen this with other OSes too? MacOS, Android, iOS?

No, only Windows so far has behaved this way.

Hmm, from this post (https://answers.microsoft.com/en-us/windows/forum/all/fixed-bluetooth-headset-and-battery-indicator/75bf5d5c-0341-4575-9b45-a7a3cdb32cad) it seems to be an issue only if you are using the headset with A2DP, and possibly should work with HFP. Which profile are you using?

If someone knows the right place to report this to MSFT, probably would be a good idea. I don't have much confidence in that being an efficient process to fix though.

Bug reports should, AFAIK, be filed via the Microsoft Feedback Hub app (https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332)


Fix node auto-configuration code

The node_size configuration option is used to automatically configure various parameters (cache sizes, timeouts, etc) for the server.
A previous commit included changes that caused incorrect values to be returned which can result in sub-optimal performance that can manifest as difficulty syncing to the network, or increased disk I/O and/or memory usage. The problem was introduced with commit 66fad62.
This commit, if merged, fixes the code to ensure that the correct values are returned and introduces a compile-time check to prevent this issue from reoccurring.

Codecov Report

Merging #3188 into develop will decrease coverage by <.01%.
The diff coverage is 57.14%.

@@             Coverage Diff             @@
##           develop    #3188      +/-   ##
===========================================
- Coverage    70.67%   70.67%   -0.01%
===========================================
  Files          689      689
  Lines        54121    54123       +2
===========================================
- Hits         38252    38250       -2
- Misses       15869    15873       +4

Impacted Files
Coverage Δ

src/ripple/core/ConfigSections.h
100% <ø> (ø)
:arrow_up:

src/ripple/app/misc/SHAMapStoreImp.cpp
74.72% <ø> (ø)
:arrow_up:

src/ripple/nodestore/impl/Shard.cpp
0% <0%> (ø)
:arrow_up:

src/ripple/app/main/BasicApp.cpp
100% <100%> (ø)
:arrow_up:

src/ripple/core/Config.h
100% <100%> (ø)
:arrow_up:

src/ripple/app/ledger/impl/LedgerMaster.cpp
42.47% <100%> (ø)
:arrow_up:

src/ripple/core/impl/Config.cpp
67.16% <33.33%> (+0.74%)
:arrow_up:

src/ripple/app/main/Application.cpp
59.07% <69.23%> (ø)
:arrow_up:

src/ripple/server/impl/BaseHTTPPeer.h
86.93% <0%> (-3.98%)
:arrow_down:

src/ripple/core/impl/Workers.cpp
100% <0%> (+1.06%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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

windows debug build unit test are crashing (repeatable), so I think that needs investigation.

windows debug build unit test are crashing (repeatable), so I think that needs investigation.

Hmm. OK, I'll take a closer look, thanks! Probably something silly.


Remove explicit type arguments appears, but i can not delete it

The inscription "Remove explicit type arguments" appears, but if removed, the bind method ceases to see the current elements of the list. It doesn't always happen

Hello Timuriy! How can i help you?

Fix the problem pls

you can make merge request, dude, it open source lib, what do you want? if you wonna nice lib make your own lib!

and you can delete android studio pls

you are so angry developer, dislike, unsubscribe.

i am the Angry Epic Architect!


trying to config Monacoin on 2nd server.

Hi,
I am trying to config Monacoin on 2nd server.
My second server ip : <IP_ADDRESS>
Miningcore server ip : <IP_ADDRESS>
And my Monacoin conf file:
server=1
daemon=1
rpcuser=****
rpcpassword=*****
rpcbind=<IP_ADDRESS>
rpcport=3999
rpcallowip=<IP_ADDRESS>/24
and this my config.json miningcore :
"daemons": [ {
"host": "<IP_ADDRESS>",
"port": 3999,
"user": "",
"password": "**",
Port 3999 open also on <IP_ADDRESS>, and telnet check ok also.
After all I am still get “waiting for daemon to come online…”
What is wrong or missing o my config ?
Thank.

I found the issue with help from kryotoking.com,
need also rpcbind=<IP_ADDRESS>


modified the site description for seo

👷 Deploy Preview for boostlabunipd processing.

Name
Link

🔨 Latest commit
add50fdc8ade9bcff444146cbd933da38438aded

🔍 Latest deploy log
https://app.netlify.com/sites/boostlabunipd/deploys/6414612a3b6d3d000787fdcd


consider making compression optional

something like
asreview simulation start --data van_de_Schoot_2017.csv --compression none ./out/project.asreview

e.g. --compression click choice with options zip, none, default zip

most integration tests already use --no-zip, maybe a tests for the default behavior of not using the --no-zip flag could still be added


how to generate a new ciphertext based on a few existing ciphertexts

Hi,
Suppose we have 3 ciphertexts, each representing 10 elements in each ciphertext, then how can we create a new ciphertext whose size is 3 with i-th element retrieving each first element of the 3 ciphertexts?
for example, we have c1, c2, c3. c1 represents 10 elements, c2 represents 10 elements, c3 represents 10 elements.
then how can we create a c* with size 3, c*[0] retrieves the first element of c1, c*[1] retrieves the first element of c2, c*[2] retrieves the first element of c3.
BR

You will have to do:
Mask (multiply with a plaintext that encrypts 1 at the position to extract else zero) each c_i to create a new ciphertext c'_i which encrypts the value you want else zero.
The rotate each c'_i to move the value to the desires slot.
Add all c'_i together and rescale.

Converting this to a discussion since this is not a question about Lattigo, but about about SIMD FHE schemes.


fix for page heap

fix stack capturing for which page heap partially enabled
fix for memprotect page heap configuration, not sharing the config with chakra. there's still some other shared recycler configs, like LeakDetect etc. may seperate out those in the future.

@digitalinfinity @curtisman

LGTM


Cooldown bug

/quests list don't show me quest with cooldown what i finished even if cooldown ended.

And tell me please what is difference between "repeat" and "cooldown" at planner? English is my second lang and i can't understand it.

This is probably intentional since the list only shows quests which can currently be taken, but I'll look into it.
For the followup question, please see https://github.com/PikaMug/Quests/wiki/Beginner-‐-Planner

Thank you very much. But what about "redo-delay"? I can't find information about it.

“Redo-delay” is the “cooldown”.  It was renamed many versions ago.
Sent with GitHawk

So I created a block-break quest with a cooldown of 60 seconds, and it shows up in /quests list before accepting, during the quest, after completing it, and after the cooldown expired. Then, I repeated the quest and it continued to appear in /quests list just fine.
Note that if you have ignore-locked-quests: true set in config.yml, then the behavior you've described is intentional.

But after all, when the cooldown has passed and the quest is available again, it is no longer considered locked, therefore it should be shown

In my testing, the quest did show after the cooldown expired with ignore-locked-quests: true set. However, it seems that only worked correctly for the first cycle - taking the quest multiple times results in the bug you've described.

Use https://ci.codemc.org/job/PikaMug/job/Quests/22/ once available
Warning: The build linked above is experimental. Make sure to back up your Quests folder before attempting to use it. Alternatively, wait until the final release on Spigot.


Cannot override date formats

At the moment there is no way to override the dateFormats which are processed by the converters, this is because the config.getProperty method is passed the list of default formats rather than the settings key.
Field formats
        try {
            formats = DataBindingGrailsPlugin.getDeclaredField('DEFAULT_DATE_FORMATS')
        } catch (NoSuchFieldException e) {
            formats = Settings.getDeclaredField('DATE_FORMATS')
        }
        String dateFormatProperty = formats.get(null)

        List dateFormats = config.getProperty(dateFormatProperty, List, DataBindingGrailsPlugin.DEFAULT_DATE_FORMATS)

        jsr310DataBinding(Jsr310ConvertersConfiguration) {
            formatStrings = dateFormats
        }

This can be fixed by reducing the above to
List dateFormats = config.getProperty(Settings.DATE_FORMATS, List, DataBindingGrailsPlugin.DEFAULT_DATE_FORMATS)
            jsr310DataBinding(Jsr310ConvertersConfiguration) {
                formatStrings = dateFormats
            }

Using Grails 3.3.1

Closing as this is fixed in 1.2.2 release.


Move fields that are only sometimes needed to the cache?

Okay, how about this?
We reduce fields to the minimum, and everything that is only needed when some method is used goes to the cache. Then we define
@inline function color(system)
    @assert haskey(system.cache, :color) "`color` of a `$(nameof(typeof(system)))` accessed, but there is no color method defined for this system"
    return system.cache.color
end

We could do the same for example with buffer, which is only needed by open boundaries and set to nothing in most simulations. I think this could make the system structs more readable.
What do you think, @LasNikas?
Originally posted by @efaulhaber in https://github.com/trixi-framework/TrixiParticles.jl/pull/539#discussion_r1856702070

Yes, that's a good idea.
Also, the constructor of the systems is starting to grow with argument error checking and creating caches etc.
Should we discuss a solution for this as well? I was thinking of something like in Semidiscretization with the check_configuration. It's clear and doesn't mess the constructor.

Yes, check_configuration is a good idea for the systems as well.
I suggested earlier that we add a kwarg techniques or so to be used as follows.
WeaklyCompressibleSPHSystem(..., techniques=(DensityDiffusionMolteniColagrossi(delta=0.1),
                                             KernelGradientCorrection(),
                                             TransportVelocityFormulation())

Most of our current kwargs are optional techniques to improve simulations.

One downside is that it is not clear which system supports which fields. So this seems to me more a thing that should be done maybe in a 0.3 refactor?

Well, it should come with a nice table in the docs listing all available techniques vs all available systems, and then shows ✅  or ❌.

You can even make this type stable if you want, by adding type-based traits. Similar to what we have done with have_nonconservative_terms in Trixi.jl.
That's an optimization though and should only be used when type stability is (can be) an issue.

Why wouldn't the Tuple be type stable?

I'm pretty sure that the @assert does some Weird Stuff under the hood. At least the code path for a system not containing color I suspect of being not type stable. But it also depends on how you use it - if it is strictly for catching errors then it might be ok

Ah you were referring to the code in the first comment. I checked the LLVM when passing a tuple, and the check is indeed optimized away.


Files downloaded with Chrome cannot be used in Android Pie

Which platform(s) does your issue occur on?

Android version 9
Pixel 2

Please, tell us how to recreate the issue in as much detail as possible.

Download a file using Chrome.
Open Image Picker demo.
Go to Downloads, select file.
App crashes with the following exception:

JS: Error: java.lang.IllegalArgumentException: Unknown URI: content://downloads/public_downloads/24
JS:     android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:165)
JS:     android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:135)
JS:     android.content.ContentProviderProxy.query(ContentProviderNative.java:418)
JS:     android.content.ContentResolver.query(ContentResolver.java:802)
JS:     android.content.ContentResolver.query(ContentResolver.java:752)
JS:     android.content.ContentResolver.query(ContentResolver.java:710)
JS:     com.tns.Runtime.callJSMethodNative(Native Method)
JS:     com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1116)
JS:     com.tns.Runtime.callJSMethodImpl(Runtime.java:996)
JS:     com.tns.Runtime.callJSMethod(Runtime.java:983)
JS:     com.tns.Runtime.callJSMethod(Runtime.java:967)
JS:     com.tns.Runtime.callJSMethod(Runtime.java:959)
JS:     com.tns.NativeScriptActivity.onActivityResult(NativeScriptActivity.java:66)JS:     android.app.Activity.dispatchActivityResult(Activity.java:7454)
JS:    ...

In imagepicker.android.ts we have:
    private static getDataColumn(uri: android.net.Uri, selection, selectionArgs) {
        let cursor = null;
        let columns = [android.provider.MediaStore.MediaColumns.DATA];
        let filePath;

        try {
            cursor = this.getContentResolver().query(uri, columns, selection, selectionArgs, null);
            if (cursor != null && cursor.moveToFirst()) {
                let column_index = cursor.getColumnIndexOrThrow(columns[0]);
                filePath = cursor.getString(column_index);
     ......
     ......

On Android 7, the columns for the rows of cursor are:
_id, _data, _size, _display_name, mime_type, title, date_added, date_modified.............
On Android 8.1 (I have a Go edition) the _data and a lot of the other columns are not there anymore.
So in the query it is looking for _data, but it does not exist.
I guess the only way to fix this is to copy the contents to a stream and save it in a cache directory or something.

I'm also having this issue. What workaround would you suggest for now?

 I replaced ..../node_modules/nativescript-imagepicker/imagespicker.android.js with the file in the zip below. As you know with the next tns plugin add... it will be gone.
imagepicker.android.js.zip

Thanks @leoncc! I replaced the contents of the file, but I'm still getting the error. Is there some other npm command I need to run to register the changes? If not, I'll just hold out for the next release.

Try deleting the platforms folder and then do tns run android again.

I also run into the same issue as described. The temporary fix posted in the file by @stevenspiel is working for me but it would by nice to have a more permanent solution in the repo.

I'm having the same problem the plugin will be updated with this solution above?

Same issue here!

Hi all,
This issue has not been added to our immediate plans so if anyone is upto the task if contributing to this project we will be more than happy to review and merge a PR that resolves the above issue. For details on how you could contribute read this section.

The fix is published in<EMAIL_ADDRESS>


remove double ,, in package.json template

this was breaking the npm install command that runs immediately after stepping through the generator options

Thanks @jpdriver! Will publish it to npm now

@jpdriver v1.4.1 has now been published to npm


Attempting to unpack a V10 NEDB database fails because it is looking for a V11 LevelDB lockfile

The isFileLocked function is called regardless of whether the dbMode is "nedb" or "classic-level" but this lock file will only exist if the dbMode is classic-level. This prevents pack/unpack operations from being possible in a pure v10 environment.

Closed as of v0.0.8


[ti] extract threat intel to helper

to @jacknagz or @mime-frame
cc @airbnb/streamalert-maintainers
From @chunyong-lin :

This refactoring will help users have more control when they use Threat Intel feature. For example, users can whitelist IOCs if they are false positive.

From @ryandeivert :

Small fix for pylint warnings and making streamalert:ioc a constant on the StreamThreatIntel class.

Coverage increased (+0.1%) to 94.607% when pulling a67f835fe59c81bbf7d0338e6e0d88aed5e3afe0 on cl-rd-extract_threat_intel_to_helper into f5af5ae843bd6e376f1db9679af41e64093f93c5 on master.

@jacknagz rebased and made that a constant. @mime-frame seriously debating deleting your comment...

Coverage increased (+0.1%) to 94.607% when pulling 10be8e75b82229476a33db2fb72489e7bfe6fc8d on cl-rd-extract_threat_intel_to_helper into b806cf8fbe6cf7f42bf812ced82993796d4fb9fd on master.

Coverage increased (+0.1%) to 94.607% when pulling 10be8e75b82229476a33db2fb72489e7bfe6fc8d on cl-rd-extract_threat_intel_to_helper into b806cf8fbe6cf7f42bf812ced82993796d4fb9fd on master.


Bug report, Feature request and PR templates

Hello!
I hope you're all doing well. I would like to propose the introduction of issue templates, pull request (PR) templates, and feature request templates in the repository. These templates will bring several benefits to the collaborative development process.

Bug report template: By using a standardized bug report template, we can ensure that all bug reports include essential information such as steps to reproduce, expected behavior, and current behavior. This will help us reproduce and resolve issues more efficiently and provide a better experience for our users who encounter bugs.

Feature request template: Implementing a feature request template will provide a structured format for users to communicate their ideas and requirements for new features. This will help us understand the use case, evaluate the feasibility, and prioritize feature requests effectively. It also encourages users to provide additional context and alternative solutions, fostering valuable discussions.

PR template: The addition of a PR template will streamline the pull request process. Contributors can provide clear descriptions of their proposed changes, reference related issues, and verify that they have followed coding style guidelines, added tests (if applicable), and tested their changes locally. This will enhance the quality of the codebase, simplify the review process, and ensure that contributions align with the project's standards.

Having these templates readily available will benefit both contributors and maintainers by providing clear guidelines and reducing ambiguity when submitting and reviewing issues, feature requests, and pull requests.
I am willing to take the responsibility of creating and implementing these templates if it's ok. Please share your thoughts and let me know if you have any suggestions or concerns.
I'll PR / proposal soon.

Hi @AyeOne 👋
First of all, thank you for your interest in contributing to Basti 🤝
Slowly but steadily, people are starting to contribute to Basti. It would be great to have these templates in place.


TreebankWordDetokenizer inverting order of tokens

Steps to reproduce
from nltk.tokenize.treebank import TreebankWordDetokenizer
detokenizer = TreebankWordDetokenizer()
s = ['``', 'Shippers', 'are', 'saying', '`', 'the', 'party', "'s", 'over', ',', "'", "''", 'said', 'Mr.', 'LaLonde', '.']
detokenizer.detokenize(s)
# '"Shippers are saying ` the party\'s over,"\' said Mr. LaLonde.'

This should produce
'"Shippers are saying ` the party\'s over,\'" said Mr. LaLonde.'

Note the inversion of \' and "
The fix seems to be to change:
https://github.com/nltk/nltk/blob/8c233dc585b91c7a0c58f96a9d99244a379740d5/nltk/tokenize/treebank.py#L291
To
        (re.compile(r"([^'\s])\s(\'\')"), r"\1\2"),

Thanks @jmccrae, your solution avoids inverting the single and the double quote. It is not a real fix though, because it does not suppress the extraneous space between the quotes, which was the purpose of the edited substitution in L291.
However, suppressing that space may be very hard, and eventually impossible, when the double quote is represented as two single quotes, because once you have three single quotes in a row, there is no way of knowing where the double quote begins or ends, and this explains why the substitution in L296 puts the double quote first.


Minor fix in DrawLineBezier*

When i starts with 0, t is also 0, which results in previous == startPos == current, this segment is not only redundant, but it also causes division-by-zero since sqrtf(dx*dx + dy*dy) is zero.

@eternalStudent thanks for the review! :)


Make it multilingual

Thanks for your app!
Would it be possible to make it handle other languages than English?

Hi @ensag-dev , yes it should be doable as the emoji-mart web component already support internationalization: https://github.com/missive/emoji-mart#-internationalization
All those languages are supported: https://github.com/missive/emoji-mart/tree/main/packages/emoji-mart-data/i18n
But it seems to be only for the UI elements, I am not sure if it includes also internationalization of the emojis keywords
Currently I don't really have a system to enable configuration through the UI (I would like to keep it as minimal as possible at the moment), but this could be done using the command line
e.g. with flatpak: flatpak run io.github.vemonet.EmojiMart --lang fr
Would that work for you?
If we notice that internationalization is not supported for emojis keyword we can check to improve the emoji-mart web component directly

Complete translation is done using this script: https://github.com/vemonet/EmojiMart/blob/main/resources/internationalize.js checkout the readme for detail on how to use localization


Gracefully handle missing uglify-js dependency

closes #1391
uglify-js is an optional dependency and should be treated as such.
This commit gracefully handles MODULE_NOT_FOUND errors while loading
uglify.

I'll merge this request to 4.x and master on Monday evening (Europe) if nobody objects. Please let me know if you need it earlier.

@nknapp thanks a lot for looking into this. we've addressed this issue on the Ember CLI end already too so this is not time critical anymore, but probably still good to fix it :)

I thought it would be better for the readability of the code if the require was at the beginning. But you are probably right. There is no need to load uglify when the user does not want to minify in the first place.

Have added another commit and I will squash them before merging. Thanks for reviewing :smirk:


Vertex query for edges does not filter edges based on starting vertex

Given:
v1->v2
v1->v3
v2->v3
Running v1.query().edges() should return only edges v1->v2 and v1->v3. It currently returns all edges.

Fixed f213b10449cf09227d3ef48b32da0001a8762709


KAFKA-13959: Controller should unfence Broker with busy metadata log

More detailed description of your change
The reason is a little complex, the two keys to this problem are:

KafkaRaftClient.MAX_FETCH_WAIT_MS==MetadataMaxIdleIntervalMs == 500ms. We rely on fetchPurgatory to complete a FetchRequest, in details, if FetchRequest.fetchOffset >= log.endOffset, we will wait for 500ms to send a FetchResponse.
The follower needs to send one more FetchRequest to get the HW.

here is the event sequence:

When starting the leader(active controller) LEO=m+1(m is the offset of the last record), leader HW=m(because we need more than half of the voters to reach m+1)
follow(standby controller) and observer(broker) send FetchRequest(fetchOffset=m)
3.1. leader receives FetchRequest, set leader HW=m and waits 500ms before send FetchResponse
3.2. leader send FetchResponse(HW=m)
3.3 broker receive FetchResponse(HW=m), set metadataOffset=m.
leader append NoOpRecord, LEO=m+2. leader HW=m
looping 1-4

After change MAX_FETCH_WAIT_MS=200(less than half of MetadataMaxIdleIntervalMs), this problem can be solved temporary.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@jsancio This is what I find about this problem, this solution is just temporary, let's first ensure the reason.

@dengziming Thanks for the investigation. One idea I was considering is only letting observers fetch up to the high watermark. Then the records would be returned to brokers as they become committed. Would that address this issue (at least when controllers are not colocated with brokers)?

only letting observers fetch up to the high watermark

@hachikuji Not sure did I understand correctly, the problem is that observer HW is always less than leader HW because the observer needs to send one more request to update HW and the request will wait an extra 500ms before response, and after 500ms, the leader will append a NoOpRecord so leader HW will plus one.
If we only let observers fetch up to the high watermark, observer HW is still less than leader HW, so this problem can't be solved.

I think we should increase the MetadataMaxIdleIntervalMs to something like 800ms or 1000ms

@showuon Neither changing MetadataMaxIdleIntervalMs nor changing KafkaRaftClient.MAX_FETCH_WAIT_MS is the right way to go forward here because it's still possible that we append metadata log more frequently in a dynamic system, for example, if the metadata is updated every 50ms. We may draw lessons from how we update ISR.

@dengziming The difference is that advancing the high watermark would then be the trigger for fulfilling the Fetch. If the observer does not have the latest high watermark, then it means data is available.

@hachikuji I saw what you mean, just change fetchPurgatory.await(fetchPartition.fetchOffset()) to fetchPurgatory.await(Math.min(fetchPartition.fetchOffset(), highWatermark)) ? sadly it still not work, I'm still checking the reason.
but I also tried a similar solution in my PR that can solve the issue, which is to return directly if fetchPartition.fetchOffset() >= highWatermark.

Yes, I think this is the best solution under current design, although it will break the purpose of fetchPurgatory when there's temporarily no new records in metadata. I agree with Jason that we can adopt this solution right now, and create another JIRA to aim to come out a solution which is not super sensitive to timing-related configurations.

@hachikuji In this PR I tried your suggestion and it does solve this problem, however, this will make the logic in RaftClient very complex and we need to save more states in LeaderState and it's also difficult to test. I made another solution according to how we add a follow replica into ISR to check followerEndOffset >= leaderLog.highWatermark.
here is the code change: https://github.com/dengziming/kafka/pull/new/KAFKA-13959-2, @showuon @hachikuji  WDYT?

here is the code change: https://github.com/dengziming/kafka/tree/KAFKA-13959-2

Hey @dengziming, I took at look at the commits in this tree.  Can you maybe share a diff/compare. For example, something like<EMAIL_ADDRESS>
Never mind. I understand now. The broker sends the active controller the local LEO instead of the last applied offset by the broker listener. I think this will unfence the broker at startup even if the broker hasn't applied the snapshot or any of the log records, right?

In this PR I tried your suggestion and it does solve this problem, however, this will make the logic in RaftClient very complex and we need to save more states in LeaderState and it's also difficult to test

@dengziming Do you have a diff for this solution? I am interested in this solution as it would work in both REMOTE and COLOCATED configuration for KRaft.

I think this will unfence the broker at startup even if the broker hasn't applied the snapshot or any of the log records, right?

Currently, we will replay the metadata records when metadata listener got new records. So yes, if we just return the current LEO, the records/snapshots might have not applied, yet.
Sorry, it's easy to reject other's proposal, but difficult to come up another solution. If we don't have any other better solution, maybe we can try the original proposed one?
One solution to this problem is to require the broker to only catch up to the last committed offset when they last sent the heartbeat. For example:

    Broker sends a heartbeat with current offset of Y. The last commit offset is X. The controller remember this last commit offset, call it X'
    Broker sends another heartbeat with current offset of Z. Unfence the broker if Z >= X or Z >= X'.

And again, thanks for keeping trying to fix this difficult issue, @dengziming !

Do you have a diff for this solution?
@jsancio  I havn't flesh it, the basic idea is shown in this PR, only read up to Isolation.COMMITTED when reading from observer and invoke fetchPurgatory.maybeComplete(highWatermark.offset, currentTimeMs) on onUpdateLeaderHighWatermark.

maybe we can try the original proposed one?
@showuon This solution can only take effect if the problem is that the heartbeat period is much bigger than NoOpRecord, it may not work now since main the problem is from RaftClient.fetchPurgatory, so we should try a new solution.

I havn't flesh it, the basic idea is shown in this PR, only read up to Isolation.COMMITTED when reading from observer and invoke fetchPurgatory.maybeComplete(highWatermark.offset, currentTimeMs) on onUpdateLeaderHighWatermark.

I see. This would not work for co-located Kafka servers, right? Co-located Kafka server are servers that are running both a controller and a broker. In that case the replica will read uncommitted data and the leader will not send a FETCH response when the HW changes.

I see. This would not work for co-located Kafka servers, right?

@jsancio you are right, this is why I'm trying to find a simpler solution, for example, letting the broker send the local LEO instead of the last applied offset, this is the logic how we expand topic-partition ISR, the problem is that the broker may haven't applied the LEO as you mentioned.
maybe we should allow the lastAppliedOffset to be behind by A records (or time) to unfence the broker.

maybe we should allow the lastAppliedOffset to be behind by A records (or time) to unfence the broker.

@dengziming Here are my thoughts
Improve logic for unfencing brokers
How about the controller unfence the broker when the broker's high-watermark has reached the broker registration record for that broker? The a controller first registers for a given incarnation, the controller write a broker registration record. The controller can remember this offset as returned by the raft client. The controller can unfence the broker when the broker's high-watermark is greater than this registration offset.
Propagate the HWM to the replicas as quickly as possible.
I think that the solution above it would allow us to de-prioritize this. Here are my observations anyways.
Looking at the KafkaRaftClient implementation we would have to have an index for both the fetch offset and the last sent high-watermark for that replica.
Another issue here is that we changed the KafkaRaftManager so that it doesn't set the replica id when it is an observer/broker. Since the HWM is not part of the Fetch request the leader would have to keep track of this in the LeaderState
      val nodeId = if (config.processRoles.contains(ControllerRole)) {
        OptionalInt.of(config.nodeId)
      } else {
        OptionalInt.empty()
      }

We would need to find a better solution for https://issues.apache.org/jira/browse/KAFKA-13168 or improve the FETCH request so that it includes the HWM.

How about the controller unfence the broker when the broker's high-watermark

This is a good idea, however, the offset of each registration record is a soft state(not persist to metadata log) and will be lost during leader change, so we should move this judgment to the broker side, to be clear, let the broker unfence itself when seeing registration record of itself.

We would need to find a better solution for https://issues.apache.org/jira/browse/KAFKA-13168 or improve the FETCH request so that it includes the HWM.
We already have a Jira for it: https://issues.apache.org/jira/browse/KAFKA-13986

This is a good idea, however, the offset of each registration record is a soft state(not persist to metadata log)

@dengziming The offset is persistent along with the record. This offset is provided to the inactive controllers in handleCommit. When processing handleCommit the inactive controllers can use the Batch::lastOffset of the batch that contains the registration record. When processing handleSnapshot the inactive controllers can use the SnapshotReader::lastContainedLogOffset of the snapshot if the snapshot contains registration records. What do you think?

@jsancio I think the last question is that there may be more than one registration record for each broker after restarting it, so can we rely on the broker epoch? I think I need some time to check the logic before make a final decision.

@jsancio I think the last question is that there may be more than one registration record for each broker after restarting it, so can we rely on the broker epoch? I think I need some time to check the logic before make a final decision.

Yes. I think you can rely on broker epoch and broker id. Also the active controller is guaranteed to have read all of the records on the log before handling RPCs like heartbeat.

@dengziming I marked this issue as a blocker to 3.3.0. Let me know if you want to work on this issue. I don't mind.

@dengziming I marked this issue as a blocker to 3.3.0. Let me know if you want to work on this issue. I don't mind.

@jsancio Thank you for reminding me, I'm working on this now, the solution is not difficult but it's trying to figure out how to test it.

@dengziming take a look at the tests failures. All of the failures in ClusterControlManagerTest seems related to this change.

Thank you for your good suggestions, @jsancio , I have resolved them.

Build failed with test errors. Rerunning:
[Build / JDK 8 and Scala 2.12 / org.apache.kafka.connect.mirror.integration.IdentityReplicationIntegrationTest.testOffsetSyncsTopicsOnTarget()](https://ci-builds.apache.org/job/Kafka/job/kafka-pr/job/PR-12274/9/testReport/junit/org.apache.kafka.connect.mirror.integration/IdentityReplicationIntegrationTest/Build___JDK_8_and_Scala_2_12___testOffsetSyncsTopicsOnTarget__/)
[Build / JDK 8 and Scala 2.12 / org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationBaseTest.testReplication()](https://ci-builds.apache.org/job/Kafka/job/kafka-pr/job/PR-12274/9/testReport/junit/org.apache.kafka.connect.mirror.integration/MirrorConnectorsIntegrationBaseTest/Build___JDK_8_and_Scala_2_12___testReplication__/)
[Build / JDK 8 and Scala 2.12 / kafka.server.KRaftClusterTest.testIncrementalAlterConfigs()](https://ci-builds.apache.org/job/Kafka/job/kafka-pr/job/PR-12274/9/testReport/junit/kafka.server/KRaftClusterTest/Build___JDK_8_and_Scala_2_12___testIncrementalAlterConfigs__/)
[Build / JDK 11 and Scala 2.13 / org.apache.kafka.controller.QuorumControllerTest.testNoOpRecordWriteAfterTimeout()](https://ci-builds.apache.org/job/Kafka/job/kafka-pr/job/PR-12274/9/testReport/junit/org.apache.kafka.controller/QuorumControllerTest/Build___JDK_11_and_Scala_2_13___testNoOpRecordWriteAfterTimeout__/)


Wrong data passed into custom renderer in 2.9.x

Expected Behavior
Expected behavior as it was in Chart.js 2.8.x.
draw method in my applyCustomRenderer should get correct data in this._model.x and this._model.width.
See values in the console in following codepen, there are correct float values.
https://codepen.io/Misticek/pen/jOOJNgv
Current Behavior
Chart.js 2.9.x
draw method getting NaN values in this._model.x and this._model.width instead of correctly calculated values as it is in 2.8.0.
https://codepen.io/Misticek/pen/jOOJNvx
Steps to Reproduce (for bugs)
Codepen links above, see console.log for both code pens.
Context
Trying to render rounded corner bars like this (version 2.8.0):

With version 2.9.x I am unable to render these rounded bars because of NaN values in this._model.x and this._model.width. No bars are being rendered at all.
Environment

Chart.js version: 2.9.x
Browser name and version: All browsers

This is a very nice looking chart!
This seems like a duplicate of https://github.com/chartjs/Chart.js/issues/6636. Please see there for details on how to solve
Also make sure you've read the documentation on this page: https://www.chartjs.org/docs/latest/developers/charts.html#bar-controller

Hey Ben,
yes you are right, it's duplicate. Sorry, did not notice that one.
So yeah, I have fixed that by adding default dataset for new bar type.
Here is my fixed codepen for other users, new added line is commented.
https://codepen.io/Misticek/pen/XWWGqWK
Thanks!


Add debugging information for Firestore integration tests

Add an assertion to verify the expected number of events are delivered
to the queryWatch test. Awaiting the semaphore now has a 60sec timeout.
If not satisfied within that timespan the test will fail, and provide
an assertion message of the progress.
Updates to allow running builds locally

Update build script to cd to checkout directory relative to itself
instead of using a hard-coded path.
Update build script to be tolerant of absolute paths specified for
GOOGLE_APPLICATION_CREDENTIALS

An example of the new diagnostic assertion:
java.lang.AssertionError:
did not receive all expected messages within the deadline.
expectedOperations = [case 0, case 1, case 2, case 3, case 4, case 5]
  actualOperations = [case 0]
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at com.google.cloud.firestore.it.ITSystemTest.queryWatch(ITSystemTest.java:968)

So does this mean it failed on case 0, or finished case 0 and failed in case 1? I would add clarifying language in the error message to demonstrate this.

So does this mean it failed on case 0, or finished case 0 and failed in case 1? I would add clarifying language in the error message to demonstrate this.

It's saying that it expected 6 cases to be performed, but only 1 of them was performed. The cases reported in actual are what actually happened. The main thing is that the number of expected async operations didn't happen during the test run. What would you expect as the reported message?

@kolea2 Updated message per our offline conversation.

@chingor13 Can you take a look at my changes to .kokoro/build.sh and give it a +1. All of the builds are running in this PR so I think everything should be working well.


orphaned running docker container used for build

What happened?
Ran pulumi up with a pulumi-docker-build Image resource.
A moby/buildkit:buildx-stable-1 docker image was started.
pulumi up completed successfully.
The docker image is still running.
Please tidy up and destroy it once it's no longer needed.
Example
N/A
Output of pulumi about
shed@ip-192-168-1-91 deployment % pulumi about
CLI
Version      3.113.2
Go Version   go1.22.2
Go Compiler  gc

Plugins
NAME          VERSION
aws           5.43.0
docker        4.5.3
docker-build  0.0.2
python        unknown

Host
OS       darwin
Version  14.4.1
Arch     arm64

This project is written in python: executable='/Users/shed/.venvs/myproject/bin/python3' version='3.9.19'

Additional context
Thanks so much for pulumi-docker-build . It finally delivers caching and secret support so my deployments are now taking seconds instead of minutes
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

This one is a little tricky because Pulumi doesn't currently have graceful shutdown hooks for the provider (https://github.com/pulumi/pulumi/issues/9780), so we don't know when to clean things up because we don't know when the whole update is finished.
We could clean things up within the lifecycle of an individual resource's update, but that would give each Image its own builder and that would be really inefficient. (BuildKit is very good at handling parallel builds, so we want to use one builder for the whole pulumi up.)
If it's any consolation, the container that's left around shouldn't be using many resources at all. Some users might also prefer the container to stick around to make subsequent builds faster.
If this is causing problems, as a workaround you can manage the builder's lifecycle outside of Pulumi: create a builder when you need it, and pass its name to your Image resource (builder.name), then tear it down when you're done.

Thanks so much for pulumi-docker-build . It finally delivers caching and secret support so my deployments are now taking seconds instead of minutes

Very glad to hear this!

This issue and bug report is similar to a feature request for supporting lifecycle management of Builders. Suppose we have a kube cluster and configure a builder on it.
$ kubectl create ns buildkit # Docker won't do this for you
$ docker builder create --name kube --driver kubernetes --driver-opt=namespace=buildkit --bootstrap --use
[+] Building 5.6s (1/1) FINISHED
 => [internal] booting buildkit                                                                                5.6s
 => => waiting for 1 pods to be ready                                                                                5.5s
kube

This command, creating the builder, both changes the local docker engine state by creating a file here: ~/.docker/buildx/instances/kube (named the name of the builder).
$ cat ~/.docker/buildx/instances/kube
{"Name":"kube","Driver":"kubernetes","Nodes":[{"Name":"kube0","Endpoint":"kubernetes:///kube?deployment=buildkit-5e15d39f-50ca-4fd0-b973-4a9407c1c3f1-xpmd8\u0026kubeconfig=%2Ftmp%2Fesc-1975623452","Platforms":null,"Flags":null,"DriverOpts":{"namespace":"buildkit"},"Files":null}],"Dynamic":false}

And it creates a Deployment on the Kubernetes cluster. This is a durable, permanent change on the remote cluster:
$ kubectl get deployment -n buildkit
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
kube0   1/1     1            1           46s

I think the issue here, and with Kubernetes builders, is that users may want to manage the durable part of this (the long-lived Kubernetes deployment, a container on a remote Docker Engine) separate from the local part (the local Docker configuration connecting to it.)
Such that they can declare a single builder in one stack and use it from multiple other stacks. That is, a stack can declare a docker-build.Builder which is used for zero or many docker-build.Image resources in that stack, or used via StackReference from other stacks.
A pulumi destroy on the docker-build.Builder should be equivalent to docker builder rm ..., that is, the Builder becomes a lifecycle managed resource.
This would be useful whether the Builder is a Kubernetes builder, a Docker container builder, etc.

users may want to manage the durable part of this (the long-lived Kubernetes deployment, a container on a remote Docker Engine) separate from the local part (the local Docker configuration connecting to it.)

Use the Kubernetes provider to provision a Deployment, and omit --bootstrap when creating the local builder config.

A pulumi destroy on the docker-build.Builder should be equivalent to docker builder rm ..., that is, the Builder becomes a lifecycle managed resource.
This would be useful whether the Builder is a Kubernetes builder, a Docker container builder, etc.

What you're asking for would leave a local container running until the stack is destroyed. This issue is asking for the opposite.
@AaronFriel please create a separate issue with a concrete proposal.

Why does it require a separate docker builder in the first place and not just use the in-built?

Why does it require a separate docker builder in the first place and not just use the in-built?

@benedikt-mue please elaborate. What do you mean by "in-built"?

The default docker builder that comes with docker?

@benedikt-mue
https://docs.docker.com/build/builders/#default-builder

The default builder created by the daemon uses the docker driver.

We require a docker-container builder because the default docker driver isn't compatible with modern features like caching, multi-platform, etc.


Allow for adding a word to the C11y

Especially for abbreviations or words specific for a use case. Users should be able to add words.
$ POST /v1/c11y/words -d { TBD }
Users should be able to define and weigh them accordingly based on a properly defined interface (TBD).

Adding could be realized by synonyms.
The c11y knows kebab but not kebap so a synonym could be created.
What would be even nicer than just 1 to 1 synonyms, would be a combined vector e.g.:
5starHotel -> ['hotel', 'expensive', 'star', 'aaa']
This could for the start be just implemented as a usual camelCase concat synonym.

Proposal
API assumes Weaviate API, what the actual c11y API to Weaviate looks like doesn't matter from a user's perspective:
The endpoint acts as an idempotent upsert, i.e. it doesn't know or care if the synoym already exists, if yes it will overwrite it:
PUT /v1/c11y/synonyms/<nameOfSynonym>
{
  "concepts": []string
}

This would work for both the exact synonym case:
PUT /v1/c11y/synonyms/kebap
{
  "concepts": ["kebab"]
}

as well as for the description:
PUT /v1/c11y/synonyms/5starHotel
{
  "concepts": ["hotel", "expensive", "star", "aaa"]
}


Use OpenJade to improve parsing/remove the need to BeautifulSoup?

Got a tip from a user that OpenJade could be used to upgrade the OFX file to XML, then standard Python XML tools could parse the OFX file.  Sounds really promising, look into it!
http://openjade.sourceforge.net/
Pros:

Remove BeautifulSoup dependency
Would enable this library to run on Python 3
Probably less effort than a from-scratch OFX format parser

Cons:

Adds a dependency on a C++ program.  Creates cross-platform issues

BeautifulSoup seems to be alive and well again.  Stick with BeautifulSoup for now.


cks: assorted fixes, test refactoring

Description
Fixes #4265
Fixes for:

template selection
network cleanup
capacity check

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[x] Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):
How Has This Been Tested?

@shwstppr is this ready for testing?

Packaging result: ✔centos7 ✔centos8 ✔debian. JID-1793

Trillian test result (tid-2524)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 1338 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4269-t2524-kvm-centos7.zip
Smoke tests completed. 0 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

Trillian test result (tid-2526)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 1296 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4269-t2526-kvm-centos7.zip
Smoke tests completed. 0 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-1816

@blueorangutan package

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-1834

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Packaging result: ✔centos7 ✔centos8 ✔debian. JID-1853

Packaging result: ✔centos7 ✔centos8 ✔debian. JID-1854

Packaging result: ✔centos7 ✔centos8 ✔debian.  JID-1881

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔centos8 ✖debian. JID-1883

@blueorangutan package

@shwstppr a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔centos8 ✔debian. JID-1908

Packaging result: ✔centos7 ✔centos8 ✔debian. JID-1909

Changed base branch, moved master related regression fix in #4309

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-1919

Packaging result: ✖centos7 ✖centos8 ✖debian. JID-1921

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

@blueorangutan test

@shwstppr a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

@shwstppr is this in progress or ready for review/testing?
@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-1947

@rhtyd changes are okay while deploying k8s clusters manually but Trillian run of smoke tests is taking over 2.5 hrs and double if there are failures in first run. I'm trying to reduce number of cluster deployments to reduce time

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-1957

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2015

@blueorangutan test

@shwstppr a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-2751)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 56453 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4269-t2751-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_clusters.py
Smoke tests completed. 82 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_deploy_kubernetes_cluster
Error
3613.82
test_kubernetes_clusters.py

test_02_invalid_upgrade_kubernetes_cluster
Error
3616.58
test_kubernetes_clusters.py

test_03_deploy_and_upgrade_kubernetes_cluster
Error
0.05
test_kubernetes_clusters.py

test_04_deploy_and_scale_kubernetes_cluster
Error
0.06
test_kubernetes_clusters.py

test_05_delete_kubernetes_cluster
Error
0.05
test_kubernetes_clusters.py

test_07_deploy_kubernetes_ha_cluster
Error
0.05
test_kubernetes_clusters.py

test_08_deploy_and_upgrade_kubernetes_ha_cluster
Error
0.06
test_kubernetes_clusters.py

test_09_delete_kubernetes_ha_cluster
Error
0.06
test_kubernetes_clusters.py

ContextSuite context=TestKubernetesCluster>:teardown
Error
130.63
test_kubernetes_clusters.py

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2019

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2025

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-2777)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 67746 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4269-t2777-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_clusters.py
Intermittent failure detected: /marvin/tests/smoke/test_outofbandmanagement.py
Smoke tests completed. 81 look OK, 2 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_deploy_kubernetes_cluster
Failure
3625.80
test_kubernetes_clusters.py

test_04_deploy_and_scale_kubernetes_cluster
Failure
31.88
test_kubernetes_clusters.py

test_07_deploy_kubernetes_ha_cluster
Failure
54.85
test_kubernetes_clusters.py

test_08_deploy_and_upgrade_kubernetes_ha_cluster
Failure
0.07
test_kubernetes_clusters.py

test_09_delete_kubernetes_ha_cluster
Failure
0.06
test_kubernetes_clusters.py

ContextSuite context=TestKubernetesCluster>:teardown
Error
99.27
test_kubernetes_clusters.py

test_oobm_issue_power_cycle
Error
15.95
test_outofbandmanagement.py

test_oobm_issue_power_soft
Error
16.42
test_outofbandmanagement.py

test_oobm_zchange_password
Error
9.84
test_outofbandmanagement.py

@shwstppr unfortunately, tests are still intermittently failing

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2057

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2067

Trillian test result (tid-2838)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 34704 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4269-t2838-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_pvlan.py
Smoke tests completed. 82 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_create_pvlan_network
Error
0.04
test_pvlan.py

@davidjumani the pvlan test seems to be failing sometimes, can you help debug if it's env related or an intermittent failure?

@rhtyd Looks like it's because the same vlan id is used elsewhere. Will change it in another PR

@blueorangutan test centos7 vmware-67u3

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-67u3) has been kicked to run smoke tests

Trillian test result (tid-2848)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 43270 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4269-t2848-vmware-67u3.zip
Intermittent failure detected: /marvin/tests/smoke/test_vpc_router_nics.py
Smoke tests completed. 79 look OK, 0 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File


Clean cache

Hi
can I disable cache for current yaml file?

https://learn.getgrav.org/16/content/headers#cache-enable


SimpleOpenGLView sample -- "Invalid constructor arguments for Float32Array"

It looks like something has changed recently and now the SimpleOpenGLView sample isn't running for me. It dies in renderView with the message
Error : Invalid constructor arguments for Float32Array
I think this might be a pretty recent change. I haven't worked out how this can be fixed.

Could you try upgrading your copy of Lime and OpenFL? I believe it should work with the latest versions

I cloned the openfl-samples repository just in case the haxelib version is out-of-date.
Here's my haxelib list:
actuate: 1.8.6 [1.8.7]
babylonhx: git [dev:/usr/local/lib/haxelib/babylonhx/git]
format: [3.2.1]
hxcpp: 3.2.205 [3.3.49]
hxsl: [2.0.6]
hxtelemetry: 0.3.3 [0.3.4]
lime: 2.9.0 2.9.1 3.0.3 3.1.0 [3.2.1]
linc_dialogs: git [dev:/usr/local/lib/haxelib/linc_dialogs/git]
nme: 5.5.7 [5.6.4]
oimohx: git [dev:/usr/local/lib/haxelib/oimohx/git]
openfl-samples: 3.3.1 [4.0.0]
openfl-texturepacker: [1.0.0]
openfl: 3.6.1 4.0.3 4.1.0 [4.2.0]
poly2trihx: [0.1.4]
random: [1.4.1]
thx.core: [0.40.1]

I ran haxelib upgrade before trying this again, so it should be completely up to date.
I still get Error : Invalid constructor arguments for Float32Array.
Have I missed something?

Ah, I've found some discussion which looks relevant


api network/graph  error

Environment
Kubernetes
Describe the bug
when the nodes is 500+,access  api network/graph is error
To Reproduce
when the nodes is 500+,access  api network/graph is error
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

With 500+ node, you will need more powerful node to run the controller, we recommend running dedicated nodes for controllers. What is the size of your nodes?


CultureInfoCache ignores custom supported cultures

Hi all,
In some cultures, the academic decimal separator is comma.
For web users, it is nevertheless more convenient to use the numpad dot in decimal form inputs, but dots are rejected by form validator.
I tried to create an hybrid CultureInfo, based on the french one, except NumberFormat overridden by english culture NumberFormat.
Everything works fine when I only declare a default request culture with the hybrid culture, but it breaks when I add it to the lists of supported cultures.
            CultureInfo hybridCulture = new CultureInfo("fr");
            hybridCulture.NumberFormat = new CultureInfo("en").NumberFormat;
            services.Configure<RequestLocalizationOptions>(options =>
            {
                CultureInfo[] supportedCultures = new[]
                {
                    hybridCulture,
                    new CultureInfo("en"),
                };
                options.DefaultRequestCulture = new RequestCulture(hybridCulture);
                options.SupportedCultures = supportedCultures;
                options.SupportedUICultures = supportedCultures;
            });

The trouble seems to be in CultureInfoCache, which cache a brand new culture based on the same name, instead of the one passed in supportedCulture.
I fixed it in rewriting CultureInfoCache.GetCultureInfo static method like that
        public static CultureInfo GetCultureInfo(string name, IList<CultureInfo> supportedCultures)
        {
            if (name == null || supportedCultures == null)
            {
                return null;
            }
            CacheEntry entry = _cache.GetOrAdd(name, n =>
            {
                CultureInfo cultureInfo = supportedCultures.FirstOrDefault(supportedCulture => string.Equals(supportedCulture.Name, name, StringComparison.OrdinalIgnoreCase));
                if (cultureInfo != null)
                {
                    return new CacheEntry(CultureInfo.ReadOnly(cultureInfo));
                }
                return new CacheEntry(null);
            });

            return entry.CultureInfo;
        }

but I need to make a perfect local copy of the RequestLocalizationMiddleware, and a custom ApplicationBuilder extensions to be able to use it.
Is it possible to have this kind of modification in the future version ?
This is my first contrib to Github, I don't really know how to use pull requests in the proper way...
Anyway, thank you for your great job !

@fdaunizeau I think this is a duplicate for #203, I'm glad that you find a bug and trying to solve it, please be free to add a PR after reading this. It's better to discuss with the others before you submit your PR
Thanks

Closing as a dup of https://github.com/aspnet/Localization/issues/203. We'll take another look at the other bug to see what we can do there.


chore: Fix unnecessary scrollbar in entity explorer during onboarding

Description
Remove unnecessary scrollbar that appears on the entity explorer during onboarding.
Fixes #7425
Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions, so we can reproduce.
Please also list any relevant details for your test configuration.

Test A
Test B

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

@ramsaptami Could you test 7425 on this DP?

Tested ok on deploy preview. Please push changes to release.


Is this plugin still in development?

The last commit was half a year ago, is floobits intelliJ discontinued?

Both the founder and co-founder now work elsewhere, so yeah, does look pretty dead.