Make a more flexible task definition system

As of right now, all of the task types that are supported by RMF's out-of-the-box task management system are hard-coded and inflexible. We can improve this in two ways:
1. Expose certain phases to the public API, and have all tasks be defined as sequences of phases
Right now, all "task phases" are internal implementation details that are not accessible to users of RMF. To modify which phases are in a task or to modify how those phases work, a user would need to fork rmf_ros2 and modify the code directly. This is not good for the RMF ecosystem, because it would create splintering in the community every time a new use-case is not already supported by the code out of the box.
Instead of this rigid approach, we could expose some task phases to the public API, and allow users to define their own tasks however they'd like. Some already-existing phases that I'd recommend for the public API include:

GoToPlace
DispenseItem PickUp
IngestItem DropOff
DockRobot
Most of the other already-existing phases I would recommend remain private implementation details that will be implicitly used by the public API phases. A full list of the existing phases can be found here.

Some new phases we could consider adding as part of this improvement includes:

RepeatN: Input a sequence of ~other phases~ conditions and an integer N. The input sequence of phases will be repeated N-times.
RepeatIndefinitely: Input a sequence of other phases conditions. The input sequence of phases conditions will be repeated until an interruption signal is received or the battery runs too low.
While: Input a sequence of other phases conditions and a looping condition. The input sequence of phases conditions will be repeated while the looping condition is satisfied.
PerformAction: Input some instruction to be sent to the robot to perform a built-in action, e.g. cleaning. The phase will finish when the robot sends back a finished signal (currently we are overloading the DockRobot phase to do this).
ParkUntil: Park at some parking spot until some condition is satisfied.
(added) Call: Call a phone number and play some audio.
(added) SMS: Send an SMS to a phone number.
(added) ParallelGroup: Input a list of other phases to run in parallel with each other.

2. Allow custom phases to be defined as three components: (a) an initiation signal, (b) finishing conditions, (c) estimate of the finished robot state
(a) To truly make RMF extensible it would be good to allow custom phases with generic hooks. One of the generic hooks would be the "initiation signal" which will get triggered when the phase begins. In rmf_task this signal would likely use a pure abstract interface class (or generic std::function<void()> callback), while in rmf_task_ros2 it would use a combination of a ros2 topic name and some message payload (maybe using C++ templates to define the payload?).
(b) For the finishing conditions, these could be built from a composable set of primitives, such as the following:

received_message: Input a ROS2 topic and a message value that needs to be received. When a suitable message arrives on the topic, this condition is satisfied.
duration_elapsed: Input a time duration. When the duration is elapsed, the condition is satisfied.
time_reached: Input a time point. When the time point is reached, the condition is satisfied.
not: Input some other condition. When the condition is not met, this condition is satisfied.
and_group: Input a set of other conditions. When all those conditions are met, so is this one.
or_group: Input a set of other conditions. When at least one of those conditions is met, so is this one.

When the finishing condition of the phase is satisfied, the phase will end, and the task handler will initiate the next phase.
(c) The phase description should be able to estimate the finished state of the robot, given an initial state, so that the task planner has enough information to allocate any tasks that use the phase.

Another component of the phase could be d) error handling response
Related tickets:

https://github.com/open-rmf/rmf_task/issues/32
https://github.com/open-rmf/rmf_task/issues/33

Good point on error handling. We could also consider this:

Custom phases specify an error condition (same as finishing conditions, except when the error conditions are satisfied, an error will be raised).
For each of its phases, a task description may specify a new phase sequence that will be triggered in the event of an error.

Hi,
In the following scenario:
The kitchen prepares meals for delivery to multiple hotel rooms. Each room is assigned a compartment.
When the AMR reach the room:

AMR calls the hotel room number phone.
AMR wait for the guest to come out and tap the guest card on AMR UI
AMR open compartment
guest remove the food and close the compartment
AMR wait for the guest to close the hotel door
AMR move to the next room.

What should be the scope of a 'task' in the above scenario?

I'll propose that a single "Task" should begin from the robot being in a state that I will call "available", and the task finishes when the robot is back to being "available". In this context "available" would mean the following conditions:

The robot is not performing any task
The robot is unencumbered, meaning it does not have anything in its compartments, and it does not have any other internal state that could interfere with the performance of another task

If we go with that definition, the scope of the workflow you described would all fall into a single Task, and additionally that Task would include the initial pickup of all the meals from the kitchen. So I could imagine a task description like the following, imagining that we've created a yaml-based syntax for describing tasks:
- GoToPlace:
    location: kitchen
- IngestItems:
    items:
     - compartment: A
       item: meal_A
     - compartment: B
       item: meal_B
     - ... the rest of the meals ...
- GoToPlace:
    location: room_A
- PerformAction:
    action: call
    params:
      number: <room A phone number>
- DispenseItems:
    items:
     - compartment: A
       item: meal_A
- GoToPlace:
    location: room_B
- PerformAction:
    action: call
    params:
      number: <room B phone number>
- DispenseItems:
    items:
     - compartment: B
       item: meal_B
- GoToPlace:
 ... the rest of the rooms ...

Ideally a planner would be used to decide the order in which the rooms should be visited to minimize the amount of traveling, and then the task description can be dynamically generated to use that ordering.

Also if calling a phone number is found to be a relatively common use case and can be reasonably standardized, we could add support for it as a first-class phase rather than requiring system integrators to create a custom phase for it using the generic PerformAction phase.

calling a phone number and playing some audio recording will be common in the hospitality services industry and I could see how it may be useful for other operations where they don't have a human sitting by a console for a web notification. some users may look for SMS (or other messaging application) notification as another possible alert method

Okay! I'll add those to the list of desirable phases to have first-class support for.

i was a bit lost during the "phase refactoring" discussion, this is probably a duh clarification :man-bowing:
phase refactoring reduces code fragmentation from implementing new use cases that cannot be described by existing tasks, or sequences of tasks
2. We want to expose phases to the public, and create a tool allowing the user to string phases together to create novel tasks.
3. the variety of phases will be fixed: we aim to creatively chain phases together ( otherwise, it seems fragmentation from 1. is inevitable )
4.further, we want to limit the complexity of this new "chaining" of phases by avoiding "behavior tree" - like implementations.
so the value of this seems to narrow down to how much better it is to "chain phases", rather than to "chain tasks". Due to point 4, we limit ourselves to simple "almost-sequential" behaviors , so it seems the benefits narrow down :
it is better to chain phases instead of chaining tasks, so we can persist information from past phases ( for example, perhaps it is easier to track a delivery robot if it has multiple pickups, or we can decide on a certain route to take )
it is better to chain phases because of integrated logic for error recovery ( uniform framework described in phases, instead of ad hoc piecemeal logic based on the results of tasks ) - not too clear on this

the variety of phases will be fixed: we aim to creatively chain phases together ( otherwise, it seems fragmentation from 1. is inevitable )

Ideally I'd like us to create a system where the variety of phases is not fixed. We'll define abstract interfaces for phases which allow system integrators to implement any kinds of phases that they'd like.

so the value of this seems to narrow down to how much better it is to "chain phases", rather than to "chain tasks"

I'm not exactly sure what you mean by "chain tasks" here, but I would say one reason it's better to "chain phases" is because "chaining tasks" is just a special case of "chaining phases".
But more generally, we're just defining the concepts like this:

Task: A sequence of actions that need to happen contiguously in a specified order to satisfy the requirements of a user. A robot is not allowed to begin a new task until it is finished with its latest one.
Phase: The building block of a task. It triggers some event to begin and tracks some condition(s) to determine when the event is completed (or when an error has occurred, making the event impossible).

We don't chain tasks together because we're defining tasks as being isolated items to be accomplished independently of each other. This gives the planner freedom to identify the optimal arrangement of tasks to perform. We may attempt to add task constraints in the future (i.e. Task A needs to be completed before Task B), but that's a reach goal.

ah, thanks for explaining. I might have missed the distinction between Tasks and Phases in the docs. That clarifies a lot.
Somehow I misread point 2 "custom phases" to be referring to an interface for the new phases we will add ( as listed in 1. ), instead of being that for the SIs to implement how they like, which led me to wrongly conclude that the SI's are limited to only defining new tasks by combining phases.
It seems rather similar in terms of code fragmentation, if users / SIs freely define phases, or if they freely define new tasks, but perhaps I have not dug enough into the implementation to see the differences clearly.

If we don't provide the means for SIs to freely define their own custom tasks and phases, then we effectively guarantee code fragmentation among the community because it's effectively impossible for us to anticipate every possible future use case that an SI will encounter. By leveraging abstract interfaces, SIs are not limited to just the tasks/phases that we're providing out of the box, so they don't need to fork their own version of the code.
Of course we'll always encourage SIs to push the implementations of their custom tasks and phases upstream so the community can standardize around the useful implementations that others have developed, but I think if RMF were designed in a way that required all implementations to exist in the core code base, then we'd be alienating members of our community who cannot (or would strongly prefer not to) push their work upstream.

Correct me if I am wrong, I briefly use a py syntax to represent the high-level idea on rmf_task2.0 public APIs.
# create custom task by chaining up phases
task = rmf_task.task_creator(...)
task.phases.append(rmf_task.phase.custom_phase_factory(<ACTION1_JSON>))
task.phases.append(rmf_task.phase.GoToPhase(...))
task.phases.append(rmf_task.phase.custom_phase_factory(<ACTION2_JSON>))

# submit task to rmf
rmf_dispatcher.request_task(task)

Also, In this case, we will also need to support dynamic definition for RMF task/phase reporting, specifically for status updating and error reporting. Might also be great if we have some public observable function for this.

I'm sharing the slides here from our first discussion which includes a summary and proposed follow ups.
https://docs.google.com/presentation/d/1REdfImJymt65paReOGFYKWA7dT3Wj3cj2qx-T21SvBc/edit#slide=id.p
If anyone else would like to be part of these discussions, feel free to drop a comment. Depending on the number of interested folks, we can decide how to organize ourselves (slack channel, email thread, etc).

Correct me if I am wrong, I briefly use a py syntax to represent the high-level idea on rmf_task2.0 public APIs.
# create custom task by chaining up phases
task = rmf_task.task_creator(...)
task.phases.append(rmf_task.phase.custom_phase_factory(<ACTION1_JSON>))
task.phases.append(rmf_task.phase.GoToPhase(...))
task.phases.append(rmf_task.phase.custom_phase_factory(<ACTION2_JSON>))

# submit task to rmf
rmf_dispatcher.request_task(task)

Also, In this case, we will also need to support dynamic definition for RMF task/phase reporting, specifically for status updating and error reporting. Might also be great if we have some public observable function for this.

@youliangtan I'm a bit confused by the syntax but to summarize:

We will provide two abstract interfaces in the public API of rmf_task

rmf_task::PhaseDescription to describe the intention of the phase. Sample implementations for first-class phases such as GoToPlace, DispenseItem, Dock, etc will also be included. These descriptions will be used for task allocation planning by the TaskPlanner
rmf_task::PhaseFactory: A factory to generate the component of the phase that will manage its execution. ie, when it should start/finish, handle errors etc. Sample implementations for first-class phases will be provided within rmf_task_ros2.

User interfaces like rmf-web or CLI will submit a msg with a string field which encompasses the sequence of phases for that task in a json-like format. A schema will be drafted and made public to detail the syntax for this
This string will be parsed to generate two components for each phase in the task: 1) PhaseDescription and 2) PhaseFactory. The former will be used for planning while the latter will be submitted to the TaskManager to handle the execution if the task is assigned.

I've opened a draft PR for this topic here. It's still in the early stages of fleshing out the API, but please feel free to leave comments.

I'll close this ticket now since all the major features related to this have been merged. New tickets can be opened to discuss finer details.


cmd/go: TestScript/list_std_stale fails if CGO_CFLAGS was set to a custom value during ./make.bash

As found by @bcmills in #46292, this happens on tip (tested with commit 52d7033ff6d56094b7fa852bbdf51b4525bd6bb2).
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dmitshur/Library/Caches/go-build"
GOENV="/Users/dmitshur/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/dmitshur/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/dmitshur/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/dmitshur/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/dmitshur/gotip/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.17-52d7033ff6 Mon May 24 15:03:18 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/dmitshur/gotip/src/go.mod"
CGO_CFLAGS="-mmacosx-version-min=10.13"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/go-build1142646826=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
# Set CGO_CFLAGS in environment.
$ export CGO_CFLAGS='-mmacosx-version-min=10.13'

# Build Go and run a test.
$ cd gotip/src
$ ./make.bash
$ export PATH="$(cd ../bin; pwd):$PATH"
$ go test -run=TestScript/list_std_stale -short -count=1 cmd/go

What did you expect to see?
A test result that verifies issue #44725 is fixed, or a skipped test execution if  the current environment doesn't make it possible to run the test reliably.
What did you see instead?
The test fails if ./make.bash was run with CGO_CFLAGS set as above.
go test proxy running at GOPROXY=http://<IP_ADDRESS>:51387/mod
--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/list_std_stale (0.24s)
        script_test.go:252:
            # https://golang.org/issue/44725: packages in std should not be reported as stale,
            # regardless of whether they are listed from within or outside GOROOT/src.
            # Control case: net should not be stale at the start of the test,
            # and should depend on vendor/golang.org/… instead of golang.org/…. (0.186s)
            > ! stale net
            FAIL: testdata/script/list_std_stale.txt:7: net is unexpectedly stale

FAIL
FAIL	cmd/go	1.683s
FAIL

Unsetting the env var afterwards doesn't make a difference:
$ unset CGO_CFLAGS
$ go test -run=TestScript/list_std_stale -short -count=1 cmd/go
[...]
FAIL	cmd/go	1.605s

Probably we should either explicitly propagate or explicitly clear out every environment variable in the union of envcmd.MkEnv(), envcmd.ExtraEnvVars(), and envcmd.ExtraEnvVarsCostly(), except for the ones that aren't writable (as controlled by envcmd.checkEnvWrite).
That way we can at least make a conscious decision about which environment variables should affect the test.
CC @jayconrod @matloob

The current plan in #46292 is to rely on this testing issue being resolved to unblock the release, so transitively applying release-blocker label.

Hmm, I'm thinking about this some more.
If make.bash sets the environment variable CGO_CFLAGS='-mmacosx-version-min=10.13', won't that imply that users on MacOS will also see the net package as stale (and rebuild it) the first time they build anything that uses it?
Or does that setting somehow get baked into the resulting binaries?

The change to set CGO_CFLAGS='-mmacosx-version-min=10.13' was done as part the work to fix issues #36025 and #35459. I agree looking at it now that it seems that it might cause net package (or other cgo packages) to become stale if that environment variable is by now used as part of staleness calculation. I remember that issue had a lot of complexity and nuance, so there may be additional factors to consider here. (CC @cagedmantis, @jayconrod who worked on it last time.)
When I looked into it more recently for darwin/arm64 in CL 278435 I hadn't found a way to confirm that setting CGO_CFLAGS before make.bash was still needed to fix a problem, so that that's why the same change hasn't been applied for darwin/arm64 at this time.

I think the default -mmacosx-version-min flag probably ought to be baked into cmd/go, and then not set explicitly on the builder (CC @cherrymui for macOS and linker expertise).
I also wonder why we don't have the same problem with ARM builders from setting the GOARM flags: https://github.com/golang/build/blob/d0819edf598a7f08d0fa642ca67f9d2c094e775b/cmd/release/release.go#L421-L425

I also wonder why we don't have the same problem with ARM builders from setting the GOARM flags

It looks like cmd/go's TestScript is completely skipped on GOOS=arm via testenv.CPUIsSlow.

I think the default -mmacosx-version-min flag probably ought to be baked into cmd/go, and then not set explicitly on the builder (CC @cherrymui for macOS and linker expertise).

If that's possible, I think it would likely be an improvement. The fewer special cases we need to maintain in cmd/release specifically, the better.
I wanted to verify that the original report in this issue applies more generally, so I tested on linux/amd64, and can confirm it also reproduces with something like this:
$ export CGO_CFLAGS='-O3'
$ ./make.bash # etc.
$ go test -run=TestScript/list_std_stale cmd/go

(The same test passes if CGO_CFLAGS in unset before make.bash.)

$ CGO_CFLAGS='-mmacosx-version-min=10.13' ./make.bash
...
$ CGO_CFLAGS='' go list -f '{{.Stale}}' net
true
$ CGO_CFLAGS='-mmacosx-version-min=10.13' go list -f '{{.Stale}}' net
false

Apparently it is not reported stale if the same flag is passed at staleness check and at make.bash. Does TestScript/list_std_stale do anything special with the flags, like unsetting CGO_CFLAGS?

Does TestScript/list_std_stale do anything special with the flags, like unsetting CGO_CFLAGS?

TestScript (intentionally) only propagates a specific subset of environment variables. I think the idea is that the behavior of the toolchain ought to be independent of the user's environment — especially given that the Go toolchain may be installed by a system administrator but run by an individual user — and most users should not need to set CGO_CFLAGS explicitly.
We have another existing staleness check that is currently skipped on darwin configurations here:
https://github.com/golang/go/blob/2ebe77a2fda1ee9ff6fd9a3e08933ad1ebaea039/src/cmd/go/testdata/script/test_race_install_cgo.txt#L5
If cmd/cgo is actually stale on the macOS builds that we're distributing to users, I'm not sure exactly what that implies — we don't generally cache binaries, so is it possible that cmd/cgo is being reinstalled on users' machines, or relinked from the build cache every time a macOS user builds any package involving cgo?

I'm not sure exactly what that implies — we don't generally cache binaries, so is it possible that cmd/cgo is being reinstalled on users' machines, or relinked from the build cache every time a macOS user builds any package involving cgo?

I don't think we check binary staleness when invoking a tool binary. The go command just invokes the installed binary, whether it is stale or not.

I think the idea is that the behavior of the toolchain ought to be independent of the user's environment — especially given that the Go toolchain may be installed by a system administrator but run by an individual user — and most users should not need to set CGO_CFLAGS explicitly.

This sounds like we may want to somehow bake the make.bash-time CGO_CFLAGS into the toolchain.
On the other hand, what if a user just wants to set CGO_CFLAGS when building the standard library and toolchain, but not when building user code? Or maybe nobody wants to do that...

On the other hand, what if a user just wants to set CGO_CFLAGS when building the standard library and toolchain, but not when building user code?

I could perhaps see someone setting CGO_FLAGS for building the toolchain.
I don't think that would make sense for the standard library, though — it would just cause each cgo-enabled standard-library package to be rebuilt when the user first builds a program that imports its.

Hmm, ok. So the impact of a CGO_CFLAGS mismatch is:

Certain packages in std are reported as stale (because they might be changed by the flags).

These packages will be rebuilt, at a small one-time cost, when first needed as a go build or go test dependency.

Certain binaries in cmd are reported as stale (by go list -json and similar commands). It isn't obvious to me whether that is inherently a problem for external tools.

Certain tests in cmd may fail:

cmd/link.TestDWARF and cmd/link.TestDWARFiOS require that cmd/link itself is not stale.

At least parts of those tests are bypassed on darwin platforms due to #32218.
Parts of those tests explicitly clear out CGO_CFLAGS due to what seems to be the same problem described here — the comment links to #35459, which is the issue for which the CGO_CFLAGS on the release builder was added in the first place.

The commit message for CL 216177 in which that was added notes “the --macosx-version-min flag is incompatible with some dwarf tests”, but does not describe the nature of the incompatibility. (Perhaps @cagedmantis has more context?)
cmd/link.TestBuildForTvOS also explicitly clears CGO_CFLAGS, even though it does not check for staleness.

The staleness check itself was added in CL 38855. The reason it is needed is not obvious to me, and is not documented in the test as far as I can tell. It is currently bypassed on the darwin builders due to #33598, and the non-bypassed parts of the test pass there anyway.

Multiple tests in cmd/go assume that packages in the Go distribution are not stale:

TestScript/build_package_not_stale_trailing_slash assumes that runtime, os, and io are not stale. It is not obvious to me whether os can depend on CGO_CFLAGS, particularly on the platforms that use C libraries for system calls.
TestScript/list_std_stale assumes that net is not stale. That test uses staleness as a proxy for whether the dependencies of the package are resolved identically inside and outside of std, but it could perhaps be refactored not to do that.
TestScript/test_race_install_cgo checks that cmd/cgo is not stale at the start of the test, but that property might no longer be important to the test as of CL 68338 (Oct. 2017): the test will no longer fail spuriously even if cmd/cgo is stale, as demonstrated by the fact that the test passes on the darwin builders today.
Tests that involve the -i flag check that the runtime package is not stale, because otherwise they would attempt to install it to GOROOT. (Tests must in general not assume that they can write to GOROOT.)

TestScript/test_relative_import_dash_i tests go test -i.
TestGoTestDashIDashOWritesBinary tests go test -i.
TestInstallDeps tests go install -i.
Note that as of CL 266368 (Go 1.16) the -i flag is deprecated (#41696).

Looking at the above, several things stand out:

We have a lot of unintended technical debt surrounding CGO_CFLAGS and staleness checks. 😅
A mismatched CGO_CFLAGS setting is mostly harmless as long as the user doesn't run go test cmd.
Of the handful of cmd tests that do fail due to staleness, most (all?) arguably shouldn't, especially given that we already bypass some of those staleness checks on the darwin builders.

cmd/link.TestDWARF and cmd/link.TestDWARFiOS require that cmd/link itself is not stale.

I still think that test should not check linker staleness at all. (This was added just to help local development.)

It appears that TestScript/build_package_not_stale_trailing_slash is out-of-date anyway: the test is checking for a missed filepath.Clean, but even if I change GOROOT to a lexically-different symlink the targets are still not reported as stale.

The problem seems to be a build ID mismatch.  The build ID stored in net.o does not match with the build ID used in Builder.useCache.

The problem occurs when setting any of the CGO flags.  From cgo documentation:
When building, the CGO_CFLAGS, CGO_CPPFLAGS, CGO_CXXFLAGS, CGO_FFLAGS and
CGO_LDFLAGS environment variables are added to the flags derived from
these directives. Package-specific flags should be set using the
directives, not the environment variables, so that builds work in
unmodified environments. Flags obtained from environment variables
are not subject to the security limitations described above.

Adding an fmt.Println in the Builder.buildActionID function to print each processed package cflags, I got:
$ CGO_CFLAGS='-O3' ./make.bash
runtime/cgo [-O3 -Wall -Werror]
os/user [-O3]
net [-O3]
os/signal/internal/pty [-O3]
plugin [-O3]

and
go test -run=TestScript/list_std_stale -short -count=1 cmd/go
runtime/cgo [-g -O2 -Wall -Werror]
net [-g -O2]

On the other hand:
$ ./make.bash
runtime/cgo [-g -O2 -Wall -Werror]
os/user [-g -O2]
net [-g -O2]
os/signal/internal/pty [-g -O2]
plugin [-g -O2]

$ go env CGO_CFLAGS
-g -O2

I have a doubt: if for packages using cgo the build ID is meaningless, what's the purpose of creating a build ID for them?

The build ID is not meaningless — that determines whether the package needs to be rebuilt.
It just happens that “rebuilding a package” is not nearly as big a deal now that we always have a build cache.


Unconfirmed my Transaction

Sir i sent Bitcoin 24hour ago still Unconfirmed my Transaction.kindly solve my problem as soon as possible.Thank you. Details ---

Size
371 (bytes)

Fee Rate
0.00359574 BTC per kB

Received Time
Nov 12, 2017 11:24:40 PM

Mined Time
N/A

Included in Block
Unconfirmed

0.0272 BTC (U)
3MeDmWHD3HNuryRvCgxAnfBT4d8V3GH6pQ

I'm new at this please give me some time

Thank you.
On Sun, Nov 12, 2017 at 11:32 PM, David8377<EMAIL_ADDRESS>wrote:

I'm new at this please give me some time
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/insight/issues/823#issuecomment-343755161, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AgDCsnnVG1A858ZV5FZyt5LlWJyPxegxks5s1zLQgaJpZM4Qa-it
.

I will I'm sorry.
On Nov 12, 2017 11:59 AM, "jyoti1977"<EMAIL_ADDRESS>wrote:

Sir i sent Bitcoin 24hour ago still Unconfirmed my Transaction.kindly
solve my problem as soon as possible.Thank you. Details ---
Size 371 (bytes)
Fee Rate 0.00359574 BTC per kB
Received Time Nov 12, 2017 11:24:40 PM
Mined Time N/A
Included in Block Unconfirmed
0.0272 BTC (U)
3MeDmWHD3HNuryRvCgxAnfBT4d8V3GH6pQ
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/insight/issues/823, or mute the thread
https://github.com/notifications/unsubscribe-auth/AgAr7Iqrw2sc-226zKQi4GkDuYCR1s4Zks5s1zIOgaJpZM4Qa-it
.

Sir exactly what problem.can explain it.Thank you
On Sun, Nov 12, 2017 at 11:38 PM, David8377<EMAIL_ADDRESS>wrote:

I will I'm sorry.
On Nov 12, 2017 11:59 AM, "jyoti1977"<EMAIL_ADDRESS>wrote:

Sir i sent Bitcoin 24hour ago still Unconfirmed my Transaction.kindly
solve my problem as soon as possible.Thank you. Details ---
Size 371 (bytes)
Fee Rate 0.00359574 BTC per kB
Received Time Nov 12, 2017 11:24:40 PM
Mined Time N/A
Included in Block Unconfirmed
0.0272 BTC (U)
3MeDmWHD3HNuryRvCgxAnfBT4d8V3GH6pQ
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/insight/issues/823, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AgAr7Iqrw2sc-
226zKQi4GkDuYCR1s4Zks5s1zIOgaJpZM4Qa-it>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/insight/issues/823#issuecomment-343755524, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AgDCshOtVKSgqerzJz2WGbYO6HHsvoSFks5s1zQagaJpZM4Qa-it
.

insight https://insight.bitpay.com/

Blocks https://insight.bitpay.com/blocks

Status https://insight.bitpay.com/status

· Conn 8 · Height 494084

Scan

BTC  https://insight.bitpay.com/#

Transaction
Transaction 1256ca96c79d53ffdb7afabc2985cce938e859f76fb1a207e665593d7bfec9ac
Summary
Size 371 (bytes)
Fee Rate 0.00359574 BTC per kB
Received Time Nov 12, 2017 11:46:43 PM
Mined Time N/A
Included in Block Unconfirmed
Details
1256ca96c79d53ffdb7afabc2985cce938e859f76fb1a207e665593d7bfec9ac
https://insight.bitpay.com/tx/1256ca96c79d53ffdb7afabc2985cce938e859f76fb1a207e665593d7bfec9ac
0.32362542 BTC
34PrXVwdNEBFamKg1GRt73nEP21ZptUE67
https://insight.bitpay.com/address/34PrXVwdNEBFamKg1GRt73nEP21ZptUE67
0.2950914 BTC (U)
3DDwf8CeGGc6Y39oMZzCgigKeqFPp2tbGT
https://insight.bitpay.com/address/3DDwf8CeGGc6Y39oMZzCgigKeqFPp2tbGT
0.0272 BTC (U)
3MeDmWHD3HNuryRvCgxAnfBT4d8V3GH6pQ
https://insight.bitpay.com/address/3MeDmWHD3HNuryRvCgxAnfBT4d8V3GH6pQ
FEE: 0.00133402 BTC
UNCONFIRMED TRANSACTION! 0.3222914 BTC
On Sun, Nov 12, 2017 at 11:42 PM, Jyoti kumar Sahoo <
<EMAIL_ADDRESS>wrote:

Sir exactly what problem.can explain it.Thank you
On Sun, Nov 12, 2017 at 11:38 PM, David8377<EMAIL_ADDRESS>wrote:

I will I'm sorry.
On Nov 12, 2017 11:59 AM, "jyoti1977"<EMAIL_ADDRESS>wrote:

Sir i sent Bitcoin 24hour ago still Unconfirmed my Transaction.kindly
solve my problem as soon as possible.Thank you. Details ---
Size 371 (bytes)
Fee Rate 0.00359574 BTC per kB
Received Time Nov 12, 2017 11:24:40 PM
Mined Time N/A
Included in Block Unconfirmed
0.0272 BTC (U)
3MeDmWHD3HNuryRvCgxAnfBT4d8V3GH6pQ
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/insight/issues/823, or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AgAr7Iqrw2sc-226zKQi4GkDuYCR1s4Zks5s1zIOgaJpZM4Qa-it>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/insight/issues/823#issuecomment-343755524,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AgDCshOtVKSgqerzJz2WGbYO6HHsvoSFks5s1zQagaJpZM4Qa-it
.


Plugin API implementation

Implements #5
Changes

plugins.src - implementation for plugins
examples - example plugins
marilib.src - added new variables to Var

TODO

[ ] Translations
[ ] Testing
[x] Better naming
[ ] Implementations for all Permissions

Future

[ ] Command to manage plugins
[x] List of plugins to import at startup
[ ] More APIs (Callbacks?)

Please pull origin before pull requesting so it won't change the stuff you didn't mean to change

These PR had issues


Added Sidekick in the Monitoring section

I haven't seen any interaction with containers while looking through the documentation.
@ismailegilmez4 could you explain to us how this relates to docker containers ?

hi @veggiemonk, Sidekick allows you to get real time data from your running applications. It is pretty useful for your containerized applications as it lets you put non breaking breakpoints and logpoints to your apps without stopping & redeploying.
You can see an example docker config here: https://docs.runsidekick.com/installation/agents/python/installation-1

@boroskoyo Thanks for the explanation.
From what you've explained, it looks more related to developing application.
Also, it seems like a paying services since it requires an API key to start.
The documentation and the readme of the product is a bit confusing.
I would be ok to merge it if you add 💲  (heavy_dollar_sign) next to it.


cleanup

exceptions: use throw enum.ToString()
enums: set explicit enum types

ApplyMeshToMeshFilter is no longer correct. should just be ApplyMesh()


Error occur during running

I believed I have install all the requirements  but when I trying to runs the following code "from mmdet.apis import inference_detector, init_detector, show_result_pyplot". It raise an error
Traceback (most recent call last):
File "", line 1, in
File "/home/senter/mmdetection/mmdet/apis/init.py", line 1, in
from .inference import (async_inference_detector, inference_detector,
File "/home/senter/mmdetection/mmdet/apis/inference.py", line 10, in
from mmdet.core import get_classes
File "/home/senter/mmdetection/mmdet/core/init.py", line 4, in
from .mask import *  # noqa: F401, F403
File "/home/senter/mmdetection/mmdet/core/mask/init.py", line 2, in
from .structures import BaseInstanceMasks, BitmapMasks, PolygonMasks
File "/home/senter/mmdetection/mmdet/core/mask/structures.py", line 6, in
import pycocotools.mask as maskUtils
File "/home/senter/miniconda3/envs/yolo/lib/python3.7/site-packages/pycocotools/mask.py", line 3, in
import pycocotools._mask as _mask
File "pycocotools/_mask.pyx", line 1, in init pycocotools._mask
ValueError: numpy.ndarray size changed, may indicate binary incompatibility. Expected 88 from C header, got 80 from PyObject
Does anyone know what might cause it and how to fix it?

pip install numpy==1.20.1 should help

pip install numpy==1.20.1 should help

Thank you!

I have the problem too, can we add this in FAQ or requirements @ZwwWayne ?


Selected State on Navigation

@alohaas pointed out that the current navigation does not provide a way for folks to know what page they are viewing. Here are some steps that might be useful in resolving this issue:

[ ] Create a simple layout with the new indication
[ ] Add the new HTML/CSS to the site

I was thinking the simplest solution would be to mirror the hover state.

:+1: on this solution @alohaas!

I'm gonna work on this this afternoon!

Right on @AndyLampert! :dango:

Worked on with @AndyLampert, submitted pull request https://github.com/girldevelopit/gdi-new-site/pull/134

w00t! Done and closing <3


core dump on Ubuntu 22.04

master branch code, built on Ubuntu 22.04, both customized example application and the tool will core dump, Coudl you help to check?

Thanks your report.
I haven't test in Ubuntu 22. So it may cost some time to solve problems

I add github action to check example now. Currently it is work to me. So how about in your system?

Hi, webbery:
Thanks for checking.
My System environment is:

Ubuntu 22.04.1 LTS Server(Not Desktop),
gcc : gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
bison: bison (GNU Bison) 3.8.2

Below are my source code:

CMakeLists.txt
`
cmake_minimum_required(VERSION 3.0)

project(GQLITE_EXAMPLE)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_STANDARD 17)
add_definitions("-Wall -g")
include_directories(../include)
link_directories(../)
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} gqlite)
3. main.cpp
#include <sys/types.h>
#include
#include "gqlite.h"
int gqlite_exec_callback(gqlite_result* params)
{
if (params) {
switch (params->type)
{
case gqlite_result_type_node:
{
gqlite_node* node = params->nodes;
while (node) {
switch (node->_type)
{
case gqlite_node_type_vertex:
{
gqlite_vertex* v = node->_vertex;
if (v->type == gqlite_id_type::integer) {
printf("[%d, %s]\n", v->uid, v->properties);
}
else {
printf("[%s, %s]\n", v->cid, v->properties);
}
}
break;
case gqlite_node_type_edge:
break;
default:
break;
}
node = node->_next;
}
}
break;
case gqlite_result_type_cmd:
for (size_t idx = 0; idx < params->count; ++idx) {
printf("%s\n", params->infos[idx]);
}
break;
default:
break;
}
}
return 0;
}
int main() {
gqlite* pHandle = 0;
gqlite_open(&pHandle, "testdb");
char* ptr = nullptr;
// gqlite_exec(pHandle,
//   "{create: 'example_db'};",
//   gqlite_exec_callback, nullptr, &ptr);
// gqlite_free(ptr);
// gqlite_close(pHandle);
}
`
when opening, it's core dump
below are the gdb core dump information:
`
(gdb) run
Starting program: /home/work/workspace/gqlite/build/example/GQLITE_EXAMPLE
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
std::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_construct<char const*> (__end=, __beg=, this=0x5555556ea7a0 gql::base64_chars) at /usr/include/c++/11/bits/basic_string.tcc:225
225               { this->_S_copy_chars(_M_data(), __beg, __end); }
(gdb) bt
#0  std::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_construct<char const*> (__end=, __beg=, this=0x5555556ea7a0 gql::base64_chars) at /usr/include/c++/11/bits/basic_string.tcc:225
#1  std::__cxx11::basic_string<char, std::char_traits, std::allocator >::basic_string<std::allocator > (__a=..., __s=, this=0x5555556ea7a0 gql::base64_chars) at /usr/include/c++/11/bits/basic_string.h:539
#2  __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/work/workspace/gqlite/src/Type/Binary.cpp:10
#3  _GLOBAL__sub_I_Binary.cpp(void) () at /home/work/workspace/gqlite/src/Type/Binary.cpp:140
#4  0x00007ffff7a83ebb in call_init (env=, argv=0x7fffffffe438, argc=1) at ../csu/libc-start.c:145
#5  __libc_start_main_impl (main=0x5555555b7a70 <main()>, argc=1, argv=0x7fffffffe438, init=, fini=, rtld_fini=, stack_end=0x7fffffffe428) at ../csu/libc-start.c:379
#6  0x00005555555c5345 in _start ()
`
I suspect I did't configure it as right way.

It seems that global string init fail here in base64_chars of Binary.cpp :
#2  __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/work/workspace/gqlite/src/Type/Binary.cpp:10

I remember initialize a global string may crash in multithread or some enverioment. So you can try to change base64_chars to type const char* or char base64_chars[] and try again.


Task log enhancement and fix intermittent test failures

Purpose

Fix intermittent test failures in stdlib/streams due to task initializing failure.
Fix logging issues in following modules:

Auth
Cache
H2
Http
Streams
Task
Ballerina unit tests

Fixes #14794
Approach

The intermittent test failure occurred due to duplicate scheduler exception from Quartz. Since we used default properties for creating quartz scheduler, this exception occurred when we try to create new scheduler while one scheduler is already existing. Now the scheduler properties are explicitly defined and hence the issue will be fixed.

Check List

[x] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

@pubudu91 at the present stdlib is not a module. It is only a directory

@pubudu91 Yes, stdlib-test-common is a common module. Let's change this that way then.


lit-html and lit-element detection not working

Platform
Which platform does the bug apply to?

WebExtension (Google Chrome, Mozilla Firefox)
Website

Describe the bug
Sites that definitely use lit-html and lit-element are not reporting that they do.
To Reproduce
Steps to reproduce the behavior:

Go to 'lit.dev
Click on Wappalzer extension
See that lit-html and lit-element are not listed

Expected behavior
lit-html and lit-element are listed
Additional context
The JS detection is here: https://github.com/AliasIO/wappalyzer/blob/master/src/technologies/l.json#L1305
We put our versions in an array, since a page can use more than one version. I'm not sure if the 0 in litElementVersions.0 is problematic or not.

It's working for me on master, possibly it wasn't working before fb7eee340c57934ab33f2a348a65ea75594f7cce.

I wonder if that commit could actually be related, since lit detection should use the DOM at all. Unless that was throwing before the JS properties were checked.

Turns out lit-html and lit-element were added in https://github.com/AliasIO/wappalyzer/pull/5600 only 11 days ago. Closing!


Kekulization issues post successful smiles parsing

This was reported by Peter Gedeck.
Wildcards are parseable in smiles, but sometimes can't be kekulized
Fails:
<EMAIL_ADDRESS>

from rdkit import Chem
s = 'C2*c1ccccc1C2'
mol = Chem.MolFromSmiles(s)
Chem.MolToMolBlock(mol)
[09:50:35] Can't kekulize mol

Traceback (most recent call last):
File "", line 1, in
ValueError: Sanitization error: Can't kekulize mol
This works:

s = 'C2*Cc1ccccc12'

And writing the aromatic ring as single/double bonds too:

s = 'C2*C1=CC=CC=C1C2'
mol = Chem.MolFromSmiles(s)
Chem.MolToMolBlock(mol)

Breakdown:

Looks like the problem here is that the first one ends up kekulizing to a bogus structure:
In [20]: s = 'C2*c1ccccc1C2'

In [21]: mol = Chem.MolFromSmiles(s)

In [22]: Chem.MolToSmiles(mol)
Out[22]: '[*]1=c2ccccc2CC1'


move codeblock to kongponents

Description
This would be useful to many and it makes sense to upstream it

xref https://github.com/Kong/kongponents/pull/819

Blocked on design


added both LB IP and hostname to sans

Issue
the current logic in server_cert_sans_dns returns the external host provided by metallb if it is a hostname, else, if it's an IP, returns the "true hostname" returned by socket.gethostbyaddr(IP).
On certain environments (such as my local development one) that means that ``server_cert_sans_dns` returns the name of my computer, and none of the cos-lite components will be able to use TLS over traefik because traefik's IP address has nothing to do with my computer's name.
Solution
Solution is adding the true hostname to the SANS instead of replacing the IP with it.
Traefik will get a cert valid for both the IP and the hostname.

@sed-i I'm going to need you to double-check this, and help clarify that this isn't breaking anything important.
Advice on how to test this on top of the existing tls integration tests is also appreciated.

I think setting a sans_ip when external_hostname isn't given is correct behavior, and it's also great that real CAs would reject this. We probably just need to make sure that sans_ip is not populated when external_hostname is set? @gruyaume
Apart from being a valid use case (cf. <IP_ADDRESS>), it makes testing much simpler, as we won't need to update the CI machine's /etc/hosts (or equivalent).

I would generally discourage from using IP addresses in your certificates, especially in Kubernetes

OK. How do we test TLS when doing development locally? Issue is traefik provides ingress at its metallb-provided IP address, so units will try to talk to one another (over https) using traefik's IP and get a TLS error because that IP address is not in the SANS. Is the only solution for local development to set traefik's hostname to X and update your resolv.conf to point X to traefik's IP? Will that also make the hostname resolvable for all ingressed charms?

Plus if you want to use IP addresses, you should likely use the sans_ip field instead of sans_dns.

The conversion is done in CertHandler.

For local development, I think sans_ip's are fine. You would likely need to be careful in how users can impact what ends up in their certificate.s


[Replaceable] attribute is not implemented

Problem in brief

Attempting to set the value of Window.length and couple of other properties of Window throws Cannot set property [Window].X that has only a getter to value Y.
The cause of this appears to be because the extended attribute [Replaceable] for JavaScript bindings is not implemented in HtmlUnit/Rhino.
For example, this page shows the properties of Window that should have the [Replaceable] attribute.

Example
console.log(window.length); // 0
window.length = 100;

// Expected: 100
// HtmlUnit: Cannot set property [Window].length that has only a getter to value 100
console.log(window.length);

Notes

This issue was previously posted in the comment together with three other issues in the below sf ticket (which can be closed). The three others issues have already been resolved

https://sourceforge.net/p/htmlunit/bugs/1956/#a90f

@duonglaiquang have done a first hack, looks to me like the browsers are not really following that spec - at least the tests are passing. Please have a look, if you agree i will implement the other window properties the same way.

finally implemented

@rbri Thanks a lot for your fixes 😄
I looked into the specs and found out this attribute is only used in 2 other properties beside Window's, which are
DedicatedWorkerGlobalScope.name and SharedWorkerGlobalScope.name.
But i think HtmlUnit 's WorkerGlobalScope doesn't support name property at the moment ?

But i think HtmlUnit 's WorkerGlobalScope doesn't support name property at the moment ?

Now it does ;-)
@duonglaiquang if you like, you can have a look at the new tests - maybe there is room for improvements


Cross Compiling sdr-transceiver.c

Hello,
I am currently attempting to expand your repo to incorporate the second ADC on the eclypse board. My issue lies in how you compiled the C code to generate the sdr-transceiver file the is in your SD card image files. I tried to use a cross compiler but had no luck. Additionally I tried to build and run the code in Vitis to no avail. If you could provide what you used to compile your code and generate your sdr-transceiver file that would be great.

I use the alpine.sh script to build the SD card image files and all the compilation is done by this script. It uses the GCC compiler provided by Alpine Linux.
I think the easiest would be to compile sdr-transceiver.c directly on the Eclypse Z7 board. At least, that is how I do when I need to test some changes.
The build tools can be installed with the following command:
apk add make gcc

If you prefer to keep them installed by default, then write the changes to the SD card with the following command:
lbu commit -d

The commands to compile sdr-transceiver.c are
cd apps/sdr_tranceiver
rw
make


Add pyupgrade

Add pyupgrade to automatically update to current Python language idioms
Contributor Checklist:

[x] I have added or updated my entry in the creators.json file
[N/A] I have added a changelog entry for my contribution
[x] I have added/updated documentation for all user-facing changes
[N/A] I have added/updated test cases
[N/A] I have included the rebuilt production build of the client (only if changes were made to the GUI)

Reviewer Checklist:

[ ] /azp run libertem.libertem-data passed

/azp run libertem.libertem-data

/azp run libertem.libertem-data


TPU Error: Unable to destroy remote tensor handles. If you are running a tf.function, it usually indicates some op in the graph gets an error: Socket closed

Please make sure that this is a bug. As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
https://www.kaggle.com/ratthachat/flickr-image-captioning-tpu-tf2-glove

TensorFlow installed from (source or binary): installed source

TensorFlow version (use command below): 2.2

Python version: 3.7

Describe the current behavior
I was running the provided code from Kaggle on a Google cloud TPU.
Hardware: v3-8
It was training fine till when I had 500000 Images. but the moment I increase the amount of data to 1 million. at almost the end of 1st epoch, I am getting the following error. I am new to TPUs so any help will be appreciated.
Traceback (most recent call last):
File "flickr-image-captioning-tpu-tf2-glove.py", line 178, in
for (batch, inputs) in tqdm_notebook(enumerate(train_dist_dataset)): # by .repeat() this will indefinitely run
File "/usr/local/lib/python3.7/dist-packages/tqdm/notebook.py", line 218, in iter
for obj in super(tqdm_notebook, self).iter(*args, **kwargs):
File "/usr/local/lib/python3.7/dist-packages/tqdm/std.py", line 1129, in iter
for obj in iterable:
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/distribute/input_lib.py", line 296, in next
return self.get_next()
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/distribute/input_lib.py", line 328, in get_next
global_has_value, replicas = _get_next_as_optional(self, self._strategy)
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/distribute/input_lib.py", line 192, in _get_next_as_optional
iterator._iterators[i].get_next_as_list(new_name))  # pylint: disable=protected-access
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/distribute/input_lib.py", line 1150, in get_next_as_list
strict=True,
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/util/deprecation.py", line 507, in new_func
return func(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/ops/control_flow_ops.py", line 1204, in cond
if pred:
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/framework/ops.py", line 884, in bool
return bool(self._numpy())
File "/usr/local/lib/python3.7/dist-packages/tensorflow/python/framework/ops.py", line 929, in _numpy
six.raise_from(core._status_to_exception(e.code, e.message), None)
File "", line 3, in raise_from
tensorflow.python.framework.errors_impl.UnavailableError: Socket closed
Additional GRPC error information:
{"created":"@1595426699.706157313","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}
2020-07-22 14:05:01.237755: W tensorflow/core/distributed_runtime/eager/remote_tensor_handle_data.cc:76] Unable to destroy remote tensor handles. If you are running a tf.function, it usually indicates some op in the graph gets an error: Socket closed
Additional GRPC error information:
{"created":"@1595426699.706157313","description":"Error received from peer ipv4:<IP_ADDRESS>:8470","file":"external/com_github_grpc_grpc/src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Socket closed","grpc_status":14}
Describe the expected behavior
Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

@caffeine-lab
Cold you please share stand alone code with dependencies to replicate this issue or if possible share a colab gist with the error faced.
With respect to the error faced please find similar issues below:
link link1


feat: Add imageIndex field to imageData

Related issue
https://github.com/kyverno/kyverno/pull/9883

Resolve conflicts in https://github.com/kyverno/website/pull/1182.


Getting the current location

Getting the current location from google maps API, save the longitude and latitude in 2 double variables to be sent later on to the server side.


Add types and keyword suggestions at top level typedesc

Purpose

With this add the auto-completion support for types and the keywords at the top-level type descriptor context.

Fixes #20305
Approach

With this following contexts are covered

public type typeName <cursor>
public type typeName moduleName:<cursor>
public type typeName client <cursor>
public type typeName client abstract <cursor>

Remarks

Related PR #20941

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[x] Added necessary tests

[x] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[x] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #20943 into ballerina-1.1.x will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           ballerina-1.1.x   #20943   +/-   ##
================================================
  Coverage            15.21%   15.21%
================================================
  Files                   50       50
  Lines                 1341     1341
  Branches               208      208
================================================
  Hits                   204      204
  Misses                1121     1121
  Partials                16       16

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 de646bf...ba414ce. Read the comment docs.


[CELEBORN-959] Use Java API to obtain disk capacity information instead of df command

What changes were proposed in this pull request?
Use Java API to obtain disk capacity information.
https://github.com/apache/hadoop/blob/bf605c8accbf1ad714ff8cb4d0cea89bfb981762/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/DF.java#L84-L104
https://github.com/openjdk/jdk8u/blob/599bb77c451274bacdb38cb7fd2d8fe658846ab3/jdk/src/solaris/native/java/io/UnixFileSystem_md.c#L439-L467
Why are the changes needed?
Some OS does not support the df -B1 command, and the worker will throw an ArrayIndexOutOfBoundsException exception.
We can replace the df command with the Java API, which is more general.
23/09/08 22:03:25,522 ERROR [worker-disk-checker] LocalDeviceMonitor: Device check failed.
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException: -4
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:206)
	at org.apache.celeborn.common.util.Utils$.tryWithTimeoutAndCallback(Utils.scala:858)
	at org.apache.celeborn.service.deploy.worker.storage.DeviceMonitor$.highDiskUsage(DeviceMonitor.scala:258)
	at org.apache.celeborn.service.deploy.worker.storage.LocalDeviceMonitor$$anon$1.$anonfun$run$9(DeviceMonitor.scala:136)
	at org.apache.celeborn.service.deploy.worker.storage.LocalDeviceMonitor$$anon$1.$anonfun$run$9$adapted(DeviceMonitor.scala:135)
	at scala.collection.Iterator.foreach(Iterator.scala:943)
	at scala.collection.Iterator.foreach$(Iterator.scala:943)
	at scala.collection.AbstractIterator.foreach(Iterator.scala:1431)
	at scala.collection.IterableLike.foreach(IterableLike.scala:74)
	at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
	at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
	at org.apache.celeborn.service.deploy.worker.storage.LocalDeviceMonitor$$anon$1.$anonfun$run$2(DeviceMonitor.scala:135)
	at org.apache.celeborn.service.deploy.worker.storage.LocalDeviceMonitor$$anon$1.$anonfun$run$2$adapted(DeviceMonitor.scala:110)
	at scala.collection.Iterator.foreach(Iterator.scala:943)
	at scala.collection.Iterator.foreach$(Iterator.scala:943)
	at scala.collection.AbstractIterator.foreach(Iterator.scala:1431)
	at scala.collection.IterableLike.foreach(IterableLike.scala:74)
	at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
	at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
	at org.apache.celeborn.service.deploy.worker.storage.LocalDeviceMonitor$$anon$1.run(DeviceMonitor.scala:110)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:750)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -4
	at org.apache.celeborn.service.deploy.worker.storage.DeviceMonitor$.$anonfun$highDiskUsage$1(DeviceMonitor.scala:240)
	at scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
	at org.apache.celeborn.common.util.Utils$$anon$3.call(Utils.scala:851)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	... 3 more

Does this PR introduce any user-facing change?
How was this patch tested?

Thanks for proposing this change, there also are some issues with df command inside the container, moving to Java API should fix it too.

Thanks for proposing this change, there also are some issues with df command inside the container, moving to Java API should fix it too.

DeviceInfo#getDeviceAndDiskInfos also uses df -ah, is this OK with container?

StorageManager#updateDiskInfos uses FileStore#getUsableSpace, I think they should be unified.

The output of df(no matter which options are used) inside the container is always problematic.
ref: https://github.com/moby/moby/issues/27191

The output of df(no matter which options are used) inside the container is always problematic.

ref: moby/moby#27191

Maybe we should change to mount ?

Maybe we should change to mount?

@waitinfuture the first output comes from kubectl describe pod <pod-name>, we can not get the result inside the Pod. In short, the command df does work properly inside the container, if possible, we should always use Java API.


AsyncAPI support

User story.
I would like to host AsyncAPIs alongside my OpenAPI schemas.
Is your feature request related to a problem?
Otherwise, I have to have two different web apps open.

Any news on this?

Hello, Team!
Recently we have grown interest in implementing AsyncAPI schemas rendering and do have the capacity to help you develop this functionality.
What we suggest is to discuss the possible implementation according to your vision of how this should be done. It would be perfect if we can arrange a meeting to negotiate the changes we need to make in the product to suit the feature requirement mentioned above.
Perhaps, you have already drafted the solution and we can help you finalize it. We would be delighted to receive any guidance, milestones, roadmaps concerning this feature so that we will know how to proceed from your standpoint.
We believe this collaboration would benefit both us and your product, so, please, let me know if you're interested in this informal partnership.
cc @aerialist7, @P0lip, @Amjcraft, @lottamus, @mallachari, @paulatulis, @marbemac, @mmiask

I saw on the other thread that you had a prototype for AsyncAPI rendering back in November 22, @porotkin.
Has there been any further discussion around getting this into the main project?

Hi, @willosborne, no, there was no further discussion. I haven't got any answer


Added release 2.7.1 of Trusted QSL

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

It's not clear to me which URL is problematic or what the exact error is. The last two releases did not have an issue with downloads and I can't find any URLs that are broken with the new version.

If the question is whether the website, https://www.arrl.org/ is run by the American Radio Relay League, it can be seen in a copyright at the bottom of the page.

OK, I found the path by looking through other PRs. Not sure why this PR doesn't seem to include a link to the pipeline. It looks like I just need to wait for a moderator to approve this:
https://dev.azure.com/ms/winget-pkgs/_build/results?buildId=513471&view=logs&j=c8020aa5-4aab-5881-691f-21986e02afd0&t=bade86d6-d2be-5ddd-c1b9-7d8db9c4a60d&l=33

@wingetbot waivers Add Validation-Domain


Zookeeper backend "Datastore sync error", https fails to fetch certificates

Do you want to request a feature or report a bug?
Bug
What did you do?

Configure traefik with http/https (acme) against an empty zookeeper cluster within Kubernetes
Remove /traefik/acme/storagefile key from zookeeper
Start traefik with zookeeper backend

What did you expect to see?
A reverse proxy fetching certificates from LetsEncrypt and serving https traffic.
What did you see instead?
A reverse proxy incapable of presenting https certificates, only serving http traffic.
Output of traefik version: (What version of Traefik are you using?)
Version:      v1.5.0-rc2
Codename:     cancoillotte
Go version:   go1.9.2
Built:        2017-12-06_03:07:42PM
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
defaultEntryPoints = ["http", "https"]
logLevel = "ERROR"

[web]
address = ":8080"

[entryPoints]
  [entryPoints.http]
  address = ":80"
  [entryPoints.https]
  address = ":443"
    [entryPoints.https.tls]

[zookeeper]
prefix = "traefik"
endpoint = "zk-svc.zoo.svc.cluster.local:2181"

[acme]
acmelogging = true
email =<EMAIL_ADDRESS>storage = "traefik/acme/account"
entryPoint = "https"
OnHostRule = true

If applicable, please paste the log output in debug mode (--debug switch)
2017/12/16 14:32:27 Connected to <IP_ADDRESS>:2181
2017/12/16 14:32:27 Authenticated: id=171218898434523140, timeout=30000
2017/12/16 14:32:27 Re-submitting `0` credentials after reconnect
2017/12/16 14:32:29 structs.go:21: Connected to <IP_ADDRESS>:2181
2017/12/16 14:32:29 structs.go:21: Authenticated: id=99161304399151114, timeout=30000
2017/12/16 14:32:29 structs.go:21: Re-submitting `0` credentials after reconnect
time="2017-12-16T14:32:29Z" level=error msg="Error in watch datastore: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}', retrying in 275.180674ms"
time="2017-12-16T14:32:52Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 622.310789ms"
time="2017-12-16T14:32:52Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:32:52Z" level=error msg="Error in watch datastore: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}', retrying in 944.68671ms"
time="2017-12-16T14:32:52Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 813.336721ms"
time="2017-12-16T14:32:52Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:32:53Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 1.428848423s"
time="2017-12-16T14:32:53Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:32:54Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 1.293795923s"
time="2017-12-16T14:32:54Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:32:56Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 2.001361005s"
time="2017-12-16T14:32:56Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:32:58Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 3.608725988s"
time="2017-12-16T14:32:58Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:33:01Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 4.110356531s"
time="2017-12-16T14:33:01Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:33:06Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 6.627829011s"
time="2017-12-16T14:33:06Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:33:12Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 17.656291998s"
time="2017-12-16T14:33:12Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:33:30Z" level=error msg="Datastore sync error: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad, retrying in 23.350973386s"
time="2017-12-16T14:33:30Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2017-12-16T14:33:37Z" level=error msg="Error in watch datastore: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}', retrying in 704.597817ms"

time="2017-12-16T14:33:53Z" level=error msg="Error calling Leadership listener: Datastore cannot sync: Object lock value: expected dac71c66-ed7e-469d-b665-cfe75928f1fc, got d2f20a7e-4ceb-4ecc-8154-d0ab4fd291ad"

Hello @Overbryd,
The PR #2598 fixed this kind of behavior by creating ACME keys which are missing.
Can you try to use the new Træfik version (1.5-rc3)?
I close this issue but you contact us on Slack if the PR does not solve your problem.

Ok, I found some time to continue working on this.
I am now running the latest version, as suggested, 1.5.3 with more than 1 instance of Traefik running simultaneously.
This is a fresh Zookeeper, it has not been used for Traefik or other services before.
This is the Traefik configuration.
But the problem persists.
Instance No 1
2018/03/05 18:12:25 Connected to <IP_ADDRESS>:2181
2018/03/05 18:12:25 Authenticated: id=243719032139218947, timeout=30000
2018/03/05 18:12:25 Re-submitting `0` credentials after reconnect
2018/03/05 18:12:26 structs.go:21: Connected to <IP_ADDRESS>:2181
2018/03/05 18:12:26 structs.go:21: Authenticated: id=315776629039890436, timeout=30000
2018/03/05 18:12:26 structs.go:21: Re-submitting `0` credentials after reconnect
time="2018-03-05T18:12:26Z" level=error msg="Error in watch datastore: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}', retrying in 520.040374ms"

Instance No 2
2018/03/05 18:12:25 Connected to <IP_ADDRESS>:2181
2018/03/05 18:12:25 Authenticated: id=243719032139218946, timeout=30000
2018/03/05 18:12:25 Re-submitting `0` credentials after reconnect
2018/03/05 18:12:26 structs.go:21: Connected to <IP_ADDRESS>:2181
2018/03/05 18:12:26 structs.go:21: Authenticated: id=315776629039890435, timeout=30000
2018/03/05 18:12:26 structs.go:21: Re-submitting `0` credentials after reconnect
time="2018-03-05T18:12:26Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 614.604501ms"
time="2018-03-05T18:12:26Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:26Z" level=error msg="Error in watch datastore: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}', retrying in 256.289381ms"
time="2018-03-05T18:12:26Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 706.190511ms"
time="2018-03-05T18:12:26Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:27Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 1.028297729s"
time="2018-03-05T18:12:27Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:28Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 2.122543444s"
time="2018-03-05T18:12:28Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:30Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 3.107033672s"
time="2018-03-05T18:12:30Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:33Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 3.245704339s"
time="2018-03-05T18:12:33Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:37Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 4.094416523s"
time="2018-03-05T18:12:37Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:41Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 12.507466351s"
time="2018-03-05T18:12:41Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:12:53Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 13.218871889s"
time="2018-03-05T18:12:53Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:13:06Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 17.184589429s"
time="2018-03-05T18:13:06Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:13:24Z" level=error msg="Datastore sync error: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9, retrying in 25.305033045s"
time="2018-03-05T18:13:24Z" level=error msg="Error reloading: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}'"
time="2018-03-05T18:13:49Z" level=error msg="Error calling Leadership listener: Datastore cannot sync: Object lock value: expected 60f19f33-01fd-4234-a22d-86e0c214de99, got 56332413-f6c4-4ba9-bc82-a2fbc606a7c9"

Instance No 3
2018/03/05 18:12:26 Connected to <IP_ADDRESS>:2181
2018/03/05 18:12:26 Authenticated: id=171661438101553153, timeout=30000
2018/03/05 18:12:26 Re-submitting `0` credentials after reconnect
2018/03/05 18:12:26 structs.go:21: Connected to <IP_ADDRESS>:2181
2018/03/05 18:12:26 structs.go:21: Authenticated: id=387834225410965507, timeout=30000
2018/03/05 18:12:26 structs.go:21: Re-submitting `0` credentials after reconnect
time="2018-03-05T18:12:26Z" level=error msg="Error in watch datastore: 1 error(s) decoding:

* 'Lock' expected type 'string', got unconvertible type 'map[string]interface {}', retrying in 412.730197ms"

We tested with 2 and 1 instances running, we still have this issue. Traefik version: v1.6.2

I am also able to reproduce this error using Traefik 1.7.9 with a fresh Zookeeper installation.
Same error occurs in the issue referenced above with Consul.

This issue impacted Traefik v1 which is not maintained anymore.
I close the issue.


Can't import and use your library in another library :) Why? If it is .h file, there is no problem but .hpp seems can't be used

I have another library and want to use your library in my library. But seems, it is not possible:
C:\RH\Sources\RH\RemoteHomeArduinoSketches\WiFi_ESP32\libraries\RemoteHome\src/RemoteHome.h:32:5: error: 'HTTPSServer' does not name a type
HTTPSServer * secureServer;
^
C:\RH\Sources\RH\RemoteHomeArduinoSketches\WiFi_ESP32\libraries\RemoteHome\src/RemoteHome.h:33:5: error: 'HTTPServer' does not name a type
HTTPServer * server;
^
C:\RH\Sources\RH\RemoteHomeArduinoSketches\WiFi_ESP32\libraries\RemoteHome\src/RemoteHome.h:129:23: error: 'HTTPRequest' has not been declared
void handleSPIFFS(HTTPRequest * req, HTTPResponse * res);
^
C:\RH\Sources\RH\RemoteHomeArduinoSketches\WiFi_ESP32\libraries\RemoteHome\src/RemoteHome.h:129:42: error: 'HTTPResponse' has not been declared
void handleSPIFFS(HTTPRequest * req, HTTPResponse * res);
Do you have an idea why?

Did you use the namespace? After the imports, write:
// Easier access to the classes of the server
using namespace httpsserver;

Otherwise, you'd need to prefix every class name with it, like this:
httpsserver::HTTPServer * server;

void handleSPIFFS(httpsserver::HTTPRequest *req, HTTPResponse *res) {
   // ...
}

I see that it's an easy pitfall, but it allows isolating the class names and preventing collisions with other libraries.

 Thanks! I didn't spot that, that you use it 👍


fix: Adding css-loader v4 support

What is it for?
Currently, the library only supports css-loader up to version 3. From version 4, the local export becomes CSS_LOADER_EXPORT.locals instead of exports.locals. I would like to add the support for version 4. This is the fix for issue number 39: https://github.com/seek-oss/css-modules-typescript-loader/issues/39
What have I done?
Added the function to split content with CSS_LOADER_EXPORT.locals if splitting with exports.local fails. Then use the function instead.
Updated the css-loader version for testing.

Before merging, just wondering why you committed with a breaking change message? From my perspective this change is backwards compatible?

Before merging, just wondering why you committed with a breaking change message? From my perspective this change is backwards compatible?

Oops, I think I made a mistake... No this is not a breaking change. Thanks for reviewing PR, I will merge it.


Add network attachment methods to cluster provider

Signed-off-by: Jana Radhakrishnan<EMAIL_ADDRESS>

LGTM.


MissingMappingFileError

via @BannersSecret in #2:
Thanks for coming back to me so quickly. When I run that, I get:
Traceback (most recent call last):
  File "samples/list.py", line 29, in <module>
    main(*sys.argv[1:])
  File "samples/list.py", line 22, in main
    tree = Tree(c)
  File "/usr/local/lib/python2.7/dist-packages/cim/objects.py", line 1577, in __init__
    self._object_resolver = ObjectResolver(cim, Index(cim.cim_type, cim.logical_index_store))
  File "/usr/local/lib/python2.7/dist-packages/funcy/objects.py", line 25, in __get__
    res = instance.__dict__[self.fget.__name__] = self.fget(instance)
  File "/usr/local/lib/python2.7/dist-packages/cim/cim.py", line 774, in logical_index_store
    return LogicalIndexStore(self, self._index_file_path, self.index_mapping)
  File "/usr/local/lib/python2.7/dist-packages/cim/cim.py", line 765, in index_mapping
    _, current_index_mapping = self.mappings
  File "/usr/local/lib/python2.7/dist-packages/funcy/objects.py", line 25, in __get__
    res = instance.__dict__[self.fget.__name__] = self.fget(instance)
  File "/usr/local/lib/python2.7/dist-packages/cim/cim.py", line 746, in mappings
    fp = self._current_mapping_file
  File "/usr/local/lib/python2.7/dist-packages/funcy/objects.py", line 25, in __get__
    res = instance.__dict__[self.fget.__name__] = self.fget(instance)
  File "/usr/local/lib/python2.7/dist-packages/cim/cim.py", line 739, in _current_mapping_file
    raise MissingMappingFileError()
cim.cim.MissingMappingFileError

The 'wbem' folder contains all the files extracted from that folder on the suspect machine. Have I done that right.....?
Thanks again for your help.

Could you share the list of files in the wbem directory? I'm mostly looking to confirm the existence of files like "MAPPING1.MAP" and friends.

Thanks again, and I'm happy (and ashamed) to report that this is totally user idiotness. I wasn't specifying the Repository folder, just straight up wbem. Working without error now. Sorry....

Great! We'll keep reporting any issues you encounter and we'll be happy to help.

Thanks a lot!


Atom Hydrogen error "unexpected EOF while parsing" for python if statement!? (but not other statements)

Seems to be a problem w/ how Atom / Hydrogen interprets the code when using Shift+Enter on and cursor on a single line of an if statement/block of code. Highlighting the whole if statement executes correctly. Putting cursor on the first line of an if statements produces the EOF error.
## this works:
for i in range(10):
    print( i)

## this doesn't:
if not False:
    print("test worked")

## this example doesn't throw an error, but only executes the "if" and not the else parts:
x= False
if x == True:
    print("test")
elif x == None:
    print ('test anyway')
else:
    print('test again')

How often:
100%
Versions
Editor name and version:
Atom 1.35.1
hydrogen 2.9.0
apm 2.1.3
npm 6.2.0
node 8.9.3 x64
atom 1.35.1
python 2.7.15
git 2.14.3
Platform: Mac OS Sierra 10.12.6
Color scheme: One Dark/Solarized Dark
seems related to this folding issue
Plugins:
Do you have any Hydrogen plugins installed and active?

[no ] hydrogen-python
[no  ] Hydrogen Launcher
[no  ] Data Explorer

also see https://github.com/atom/language-python/pull/300 (folding of python if statements) now fixed

I believe the solution will be to upgrade once versions are rolled up.

Yep, you've got it.
Anyone looking for a workaround in the meantime, see the stackoverflow discussion

FYSA: upgraded to Atom 1.36, but folding of python if statement (w/ no else) still fails and execution of python if statements w/o highlighting the whole if statement is still executing w/ an error (no else) or improperly (if/else)--no change yet or it's still persisting


Rewrite KFP code generation

This PR:

rewrites code generation for Kubeflow Pipelines v1 (v2 is still not supported)
adds a new (previously removed) export option to the pipeline editor, enabling output of Python DSL in addition to the already supported YAML output (YAML remains the pre-selected option)

adds a new optional format parameter to the elyra-pipeline export CLI command:

if the parameter is not specified, the export format defaults to YAML for Kubeflow Pipelines and PY for Apache Airflow
if the parameter is specified, it must be one of  YAML / PY (Kubeflow Pipelines) or PY (Airflow)
The value is processed in a case insensitive manner, e.g. YAML = yAML = yaml

$ elyra-pipeline export one-custom-node.pipeline --runtime-config cloning1 --format py

Fixes an existing pipeline export bug (image pull secret information is not exported, rendering the pipeline unusable)

Closes #2986
TODO:

[ ] Implement missing tests, marked with @pytest.mark.skip("TODO: implement test")

What changes were proposed in this pull request?
The Kubeflow Pipelines processor now always generates Python DSL code as intermediary output when a pipeline is submitted or exported:

Submit: Internal Elyra pipeline representation -> Python DSL (generated by processor) -> YAML (generated by KFP argo/tekton compiler)
Export: Internal Elyra pipeline representation -> Python DSL (generated by processor)
Export: Internal Elyra pipeline representation -> Python DSL (generated by processor) -> YAML (generated by KFP argo/tekton compiler)
The pipeline documentation was updated to list the new output format.

How was this pull request tested?

Updated existing CLI tests
Added new server tests that validate that code generation yields the expected results. There are now dedicated tests for all code generation aspects:

generates expected code for the configured workflow engine
generates expected code for CRIO environments
generates expected code for a plain generic component
generates expected code for a plain generic component that utilizes a runtime image, which is protected by a pull secret
generates expected code for a generic component configured with all supported elyra-owned properties
generates expected code for a plain custom component
generates expected code for data exchange between generic components

Reviewed the output of make docs

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

Based on a discussion we've had during today's dev meeting, I've updated code generation to "unload" the generated Python DSL module after it was compiled. This change should address the potential concern that over time module artifacts might accumulate, which could lead to increased memory consumption over long periods of time.

To address offline review feedback I've updated the Python DSL template to render a comment that identifies the node name:

    # Task for node 'Download File'
    task_8ee5ee17_1222_434e_bcf4_fd12f43e2510 = factory_8e4384f422a088e4814024df7955e952c1488bd091fa0d4873d5f611d741ceb4(
        url="https://raw.gith...",
    )

This is similar to what is done for Apache Airflow


warning<EMAIL_ADDRESS>This project has been deprecated for "npm install es-module-loader" based on the newer loader spec.

Hi there! I was using es6-module-loader when I notice this message in npm installation:
warning<EMAIL_ADDRESS>This project has been deprecated for "npm install es-module-loader" based on the newer loader spec.

Can you recommend another way to load modules? I tried with 'es-module-loader' but I don't know which script I should include in script tag in HTML. Thanks!

SystemJS is the most popular loader to use based on this project (http://github.com/systemjs/systemjs).


Added typescript definitions to the project

Added full typescript definitions for the Editor and Toolbar
One issue with this PR is that in index.js,  actions are also exported but for some reason, typescript won't let me do this, on the ground that I cannot import from a .js file and also I cannot redeclare actions in index.d.ts. Any help with this is welcome

Tested the definitions in personal project and they work as expected, also ran project and everything behaves normally


[sphinx] Set version using pkg_resources

Based on the latest recommendation from setuptools_scm, but using the
full version, as before:
https://github.com/pypa/setuptools_scm/issues/84
I removed the variable comments because they are no longer up to date.
They can be seen in the official documentation.

@xoltar Does this look good to you?


chore: remove deprecated ProtobufSerializer

ProtobufSerializer has been deprecated for a while, replaced by the generic Serializer interface.
This removes the class and the few places where it was still mentioned in tests.
I figured I could do this split out from the gestalt-v7 branch, but it looks like these tests skip themselves in develop, so :shrug:

this seems pretty straightforward.

@keturn I updated the branch did I do anything incorrectly else I think this could be merged.


Background compaction may cause unnecessary 1s sleep during shutdown

If background compaction has already started when the database is shutting down
(i.e. the DBImpl object destructor is called),

Here's the sequence of events:

* Somewhere: bg_compaction_scheduled_ is set
* BG Thread: BackgroundCall is invoked
* BG Thread: BackgroundCall acquires mutex
* BG Thread: BackgroundCall proceeds as shutting_down_ is false, invokes
BackgroundCompaction
* Main thread: ~DBImpl invoked
* Main thread: ~DBImpl blocks on mutex
* BG Thread: DoCompactionWork releases mutex ("Release mutex while we're
actually doing the compaction work")
* Main thread: ~DBImpl proceeds, sets shutting_down_
* Main thread: ~DBImpl blocks on bg_cv_ since bg_compaction_scheduled_
* BG Thread: DoCompactionWork tests shutting_down_, sets status to IOError
* BG Thread: BackgroundCall sees !s.ok()
* BG Thread: BackgroundCall signals bg_cv_
* Main thread: ~DBImpl wakes up, but since bg_compaction_scheduled_ blocks on
bg_cv_ again
* BG Thread: BackgroundCall sleeps for 1000000 microseconds (fearing transient
I/O error)
* BG Thread: BackgroundCall clears bg_compaction_scheduled_, calls
MaybeScheduleCompaction
* BG Thread: MaybeScheduleCompaction exits since shutting_down_ is set
* Main thread: ~DBImpl completes

Possible patch:

+++ b/db/db_impl.cc
@@ -609,7 +609,7 @@ void DBImpl::BackgroundCall() {
   assert(bg_compaction_scheduled_);
   if (!shutting_down_.Acquire_Load()) {
     Status s = BackgroundCompaction();
-    if (!s.ok()) {
+    if (!s.ok() && !shutting_down_.Acquire_Load()) {
       // Wait a little bit before retrying background compaction in
       // case this is an environmental problem and we do not want to
       // chew up resources for failed compactions for the duration of

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 8 Oct 2012 at 4:14

This is causing test timeouts in Chrome and WebKit:

https://bugs.webkit.org/show_bug.cgi?id=65862

Original comment by<EMAIL_ADDRESS>on 8 Oct 2012 at 4:18

Fixed in 1.6.0.

Original comment by<EMAIL_ADDRESS>on 12 Oct 2012 at 7:53

Changed state: Fixed


add new runtime status code

Motivation
Trying to add a hard limit on size of items going to persistent storage, and there is no proper status code for that.
Have you read the Contributing Guidelines on pull requests?
(Write your answer here.)
Test Plan
(Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)

this needs to go into aptos not (or maybe and) main


2016-03-19-wierd instanceof.md

Looks good to me.
Make sure you view it on a local server b/c it may not be formatted exactly as you'd expect.


Delete composer.lock

[RuntimeException]
The lock file does not contain require-dev information, run install with the --no-dev option or run update to install those packages.

composer.lock should always be checked in to a repository, it ensures that you use the same library versions across the board when in dev and in production.
The correct solution for the error you see is to run composer update to update the lock file with the requirements

@aicoutodasilva could you please close this PR?


Fix Android RNTester debug build

Summary
The Flipper dependency draws in a second C++ runtime library, so it
needs a pickFirst. This was not caught by CI because it only tests the
release build.
Changelog
[ANDROID] [Fixed] - RNTester now successfully builds in debug mode
Test Plan
Before:
willholen@willholen-mbp ~/extern/react-native $ ./gradlew RNTester:android:app:assembleDebug
> Task :RNTester:android:app:mergeHermesDebugNativeLibs FAILED
> Task :RNTester:android:app:mergeJscDebugNativeLibs FAILED

FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':RNTester:android:app:mergeHermesDebugNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
   > More than one file was found with OS independent path 'lib/x86/libc++_shared.so'

After:
willholen@willholen-mbp ~/extern/react-native $ ./gradlew RNTester:android:app:assembleDebug

BUILD SUCCESSFUL in 2s
81 actionable tasks: 1 executed, 80 up-to-date
willholen@willholen-mbp ~/extern/react-native $

Closing this PR since this was already fixed internally at FB


Add account verification link

Adding the account verification link when the user has registered and we want to email the account verification link
In which layer should we do this? userbus or userapp!

You want to send email to user ,do it in userbus

It depends. I believe Auth is an app layer concern. The business layer shouldn't know anything about Auth. It should trust the App layer to not call into it unless it's ok. For sure you don't want to have Auth concerns in both layers. Account verification sounds like Auth to me so I would put it in the app layer.

Thank you, I believed that it should be done in the app layer
But I said to consult


[Improvement] Provide kyuubiServerPrincipal as alias for principal in JDBC parameter

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

What would you like to be improved?
Kyuubi JDBC Driver introduced new parameters kyuubiClientPrincipal and kyuubiClientKeytabin https://github.com/apache/incubator-kyuubi/pull/3023, and it had a parameter principal which is inherited from Hive JDBC Driver, it's quite confusing, so we'd better to add an alias  kyuubiServerPrincipal for principal to make it clear and consistent.
How should we improve?
Provide kyuubiServerPrincipal as alias for principal in JDBC parameter
Are you willing to submit PR?

[ ] Yes. I can submit a PR independently to improve.
[ ] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve.
[ ] No. I cannot submit a PR at this time.

I am interested in this task. Please assign it to me.

Thanks @lightning-L


[Request] update information about "Cooking a Deliveroo clone with Next.js (React), GraphQL, Strapi and Stripe"

Hello i want to ask if are there any updates about new version of this "Cooking a Deliveroo clone with Next.js (React), GraphQL, Strapi and Stripe".
It will be very nice through those hard times to have this updated and workable.
I will be thankful for any information about this.

Yes, it's possible I've missed something, but the current tutorial appears to stop working by the time it gets to the end of part-2 https://strapi.io/blog/strapi-next-restaurants/
Specifically even when I try to clone this repo I am getting this output from yarn dev:
This dependency was not found:

* next-server/dist/lib/utils in ./node_modules/next-apollo/dist/link.js

Which I  found a way to alleviate from https://github.com/adamsoffer/next-apollo/issues/25 by updating next to ^8.0.2 and next-apollo to ^2.0.9 but then just ran into other errors.
I would target a base minimum of having a freshly cloned repo example/tutorial folder run without issues.  More ideally, have tagged tagged checkpoints for each section of the tutorial in a working state.
I think these tutorials should really be either: fully updated every 6 months, or marked archived.  I'd argue that  in its current state this broken example tutorial hurts strapi more than it helps it since it ,appears to, lead users down a frustrating dead-end.

More information here - https://github.com/strapi/community-content/issues/28

Any new update on how to solve this? I'm encountering the same problem.


Point Cloud _ Region of Interest

Dear all,
Is there an option in k4aviewer to show point cloud and save it for example as a ply file?
Also is it possible to limit the region of interest and save data (color, depth, point cloud) only for that region?
Best

The viewer application does not output files or allow ROI cropping, but with a combination of the point cloud and green screen examples you shouldn't have much trouble developing this.


Added full screen feature (#issuecomment-93967821)

Added fullscreen feature done by LinoBarreca on Apr 17, 2015 #issuecomment-93967821.
Also, I have not made any changes in Vlc.DotNet.Forms.VlcControl.cs as suggested by LinoBarreca; I have added a method - FullScreen() in VlcMediaPlayer.cs as my requirement is to make it full screen from code and not by using a button.

Replaced by #516


KOGITO-5748 - Public API: Straight-Through Process Modules (Incubatio…

…n) - fix modules organization
FYI @evacchi we need to have a way to exclude IT modules from the build. IT modules were included to default modules by #1547 probably by a mistake.

jenkins rerun examples tests

The (build) Examples check has failed. Please check the logs.

Jenkins rerun examples tests

Jenkins rerun examples tests

The (build) Apps check has failed. Please check the logs.

Jenkins rerun apps tests

The (build) Examples check has failed. Please check the logs.

Jenkins rerun examples tests

The (build) Examples check has failed. Please check the logs.

Examples fails are unrelated, they are failing also on other PRs.


Support base images stored in internal registry

If we want to use this to build an image based on this Dockerfile:
FROM registry.speag.com/osparc/base/ubuntu-focal/matlab-runtime:R2020b as base

The pipeline cannot pull the base image (access denied to that registry).

To achieve something like this, we need to extend the RepoModel to add additional keywords supporting before_STAGE_commands like: before_build_commands, before_test_commands and ``before_publish_commands`. These will allow to run a docker losing and then run the usual commands like docker build.

This was fixed I think, we're able to use images that are on the internal registry.


Set the target deployment to main during dispatched documentation deployments

I believe this will resolve #7276

Testing with dispatch at https://github.com/astral-sh/ruff/actions/runs/6161239564

Confirmed that this deployed to production successfully!
We got the confusing output
npx wrangler pages deploy site --project-name=ruff-docs --branch main --commit-hash ${GITHUB_SHA}
  Uploading... (728/730)
  Uploading... (729/730)
  Uploading... (730/730)
  ✨ Success! Uploaded 2 files (728 already uploaded) (1.39 sec)

  ✨ Deployment complete! Take a peek over at https://02459792.ruff-docs.pages.dev/

  Error: fatal: bad object 0181c74ed05496287668a263116ceef6a93f582a

but it worked 🤷♀

Tracking at https://github.com/cloudflare/wrangler-action/issues/169


Automated cherry pick of #9528 on release-6.2

Automated cherry pick of #9528 on release-6.2
Cherry pick of #9528 on release-6.2.
/cc  @weblate
NONE

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

Trying to auto merge this PR.

Pull Request successfully merged
SHA: 20e9f15b7f525384bbbf626ec30e0513de21c221


Typo/Clarification on Ch02.ipynb

There is an Additional Note (1) section where it says: " If all the weights are initialized to 0, only the scale of the weight vector, not the direction."
Seems there is some missing meaning in that sentence.  Was wondering if you could correct it please.  Thank you very much!

Thanks for the note. It should say "If all the weights are initialized to 0, the learning rate parameter eta affects only the scale of the weight vector but not its direction." Just fixed it.