CNV-41232: cloud-init form inputs cursor jumps to end of line

📝 Description
The cloud init input are working differently since we can toggle from form view to YAML view.
When changing any input on cloud-init form, the onChange event is editing the YAML object, and on each yaml object change we have an effect listening to the changes and changing the state for the inputs. This causes re-renders on the input component which causes the cursor to return to end of line on every change.
🎥 Demo
Before
https://github.com/user-attachments/assets/e3e1c1d3-dc31-4d7d-b939-de2001e84162
After
https://github.com/user-attachments/assets/d8e18ff9-7982-4f83-9d2f-5c600651ee83

/hold

/unhold


Solve Daily problem "959. Regions Cut By Slashes"

959. Regions Cut By Slashes
Link
Medium
An n x n grid is composed of 1 x 1 squares where each 1 x 1 square consists of a '/', '', or blank space ' '. These characters divide the square into contiguous regions.
Given the grid grid represented as a string array, return the number of regions.
Note that backslash characters are escaped, so a '' is represented as '\'.
Example 1:
Input: grid = [" /","/ "]
Output: 2
Example 2:

Input: grid = [" /","  "]
Output: 1
Example 3:

Input: grid = ["/\\","\\/"]
Output: 5
Explanation: Recall that because \ characters are escaped, "\\/" refers to \/, and "/\\" refers to /\.

Constraints:

n == grid.length == grid[i].length
1 <= n <= 30
grid[i][j] is either '/', '', or ' '.

Solved
class Solution:
    def regionsBySlashes(self, grid: List[str]) -> int:
        def find(x):
            if p[x] != x:
                p[x] = find(p[x])
            return p[x]

        def union(a, b):
            pa, pb = find(a), find(b)
            if pa != pb:
                p[pa] = pb
                nonlocal size
                size -= 1

        n = len(grid)
        size = n * n * 4
        p = list(range(size))
        for i, row in enumerate(grid):
            for j, v in enumerate(row):
                k = i * n + j
                if i < n - 1:
                    union(4 * k + 2, (k + n) * 4)
                if j < n - 1:
                    union(4 * k + 1, (k + 1) * 4 + 3)
                if v == '/':
                    union(4 * k, 4 * k + 3)
                    union(4 * k + 1, 4 * k + 2)
                elif v == '\\':
                    union(4 * k, 4 * k + 1)
                    union(4 * k + 2, 4 * k + 3)
                else:
                    union(4 * k, 4 * k + 1)
                    union(4 * k + 1, 4 * k + 2)
                    union(4 * k + 2, 4 * k + 3)
        return size


New version: IdealistaAPIClient v0.2.1

Registering package: IdealistaAPIClient
Repository: https://github.com/rogersamso/IdealistaAPIClient.jl
Created by: @rogersamso
Version: v0.2.1
Commit: 39a8617644e82ad8c1169da63e0002a2652e0ae1
Reviewed by: @rogersamso
Reference: https://github.com/rogersamso/IdealistaAPIClient.jl/commit/39a8617644e82ad8c1169da63e0002a2652e0ae1#commitcomment-81330479
Description: A simple client for the idealista Search API written in julia

This PR can be closed, as a new one was created with the fix, and will be automerged.


Reload running polybar instance in-place

i3 has a nice feature of reloading it's config without killing / launching it back.
It would be nice to have the same functionality with polybar, so it won't blink while being reconfigured. (:
EDIT: similar to this, but a command-line parameter instead of a signal.

+1 a must have

Any idea if anyone is working on this?

I don't see a problem with killing it and launching again... I have a script that does this (kills if exists and launches polybar) and I execute it at i3 startup with exec_always, so that everytime I reload i3 polybar also reloads.

@gabrielsimoes I'm doing the same thing (kill and start again), but I don't think scripting out every missing functionality is a way to go...

I think it is a work in progres issue 17

@Deomkan the issue you've linked to is marked as closed but it is still present in version 3.0.5

There is this command:
polybar -r bar
You have to launch polybar in that way, and every time config file is changed, bar will reaload automatically

@Deomkan How did I miss it :O
My apologies!

I'd like to reopen this issue for a slightly different reason.
Let's say the configuration contains .Xresources references, example here.
If the resource is changed in the .Xresources file, polybar does not reload its' config. It means it has to be restarted manually.
I'd like to be able to send a signal or perhaps run polybar with some parameter that would send a signal to currently running instance so it knows the config should be reloaded.

You can issue the command polybar-msg cmd restart, which will restart all the bars. So you can call the command whenver you change the .Xresources file.
You'll need to enable ipc in the bar though:
enable-ipc = true

@patrick96 it works, thank you!


rubico/x/thunkify

/**
 * @name thunkify
 *
 * @synopsis
 * <T any>thunkify(
 *   func (...T)=>any,
 *   args ...T,
 * ) -> thunk ()=>any
 *
 * @catchphrase
 * Fix a computation
 *
 * @description
 * **thunkify** takes a function `func` and arguments `args` and returns a `thunk` function that always calls `func` with `args`. `thunk` always returns the result of the computation `func(args)`. Any effects of `func` will be rerun by `thunk`.
 *
 * @example
 * const thunkified = thunkify((a, b) => a + b, 8, 9)
 *
 * console.log(thunkified()) // 17
 * console.log(thunkified()) // 17
 */

This was upgraded directly in the core API https://github.com/a-synchronous/rubico/commit/dc60a327937b5fcd51e2e75683af73cd7d12f368


'lxd init' fails to set up ZFS on ARM

Required information

Distribution: Ubuntu Server 16.04 ARM
Kernel version: 4.4.0-1012-raspi2
LXD version: 2.0.2-0ubuntu1~16.04.1

Issue description
Using a clean install of the new "classic" server image for Raspberry Pi.
I'm trying to initialize LXD with a ZFS loopback file, but it fails with an error complaining about the size of the ZFS device.
Steps to reproduce
ubuntu@ubuntu:~$ sudo lxd init
Name of the storage backend to use (dir or zfs): zfs
Create a new ZFS pool (yes/no)? yes
Name of the new ZFS pool: lxd
Would you like to use an existing block device (yes/no)? no
Size in GB of the new loop device (1GB minimum): 8
Would you like LXD to be available over the network (yes/no)? no
Do you want to configure the LXD bridge (yes/no)? no
error: Failed to create the ZFS pool: cannot create 'lxd': one or more devices is less than the minimum size (64M)

Information to attach

The /var/lib/lxd/zfs.img file has the correct permissions but is 0 bytes long. I guess the f.Truncate() call is not working correctly.
Running "zpool create ..." on that file fails with the previous error.

Workaround:
ubuntu@ubuntu:~$ sudo truncate -s 8G /var/lib/lxd/zfs.img
ubuntu@ubuntu:~$ sudo zpool create lxd /var/lib/lxd/zfs.img -f -m none
ubuntu@ubuntu:~$ sudo lxd init
Name of the storage backend to use (dir or zfs): zfs
Create a new ZFS pool (yes/no)? no
Name of the existing ZFS pool or dataset: lxd
Would you like LXD to be available over the network (yes/no)? no
Do you want to configure the LXD bridge (yes/no)? no
LXD has been successfully configured.

EDIT: better to create the ZFS loopback file somewhere else for the workaround. /var/lib/lxd/zfs.img gets deleted after lxd init, so everything appears to work fine until the kernel panics a while later (found out the hard way) or you reboot the machine.

So a simple Truncate test with Go 1.6 on ARM appears to work fine for me, creating a 16.04 system now to test again.


VG doesn't properly load paths that contain cycles.

(discussed in #127, but worthy of its own issue)
When loading a graph from, say, json, paths get copied in with Paths::append_mapping().   This method uses Paths::has_mapping() to strip out any mapping its seen before.  The result is that paths with cycles are silently corrupted.

There are a number of problems with path ordering in serialization. Looking into it now.

Here's a graph with a cycle in a path. Things don't go very well for it.
{"node":[{"sequence":"TCAGATTCTCATCCCTCCTCAAGGGCTTCT","id":1},{"sequence":"AACTACTCCACATCAAAGCTAC","id":2},{"sequence":"CCAGGCCATTTTAAGTTTCCTG","id":3},{"sequence":"T","id":4},{"sequence":"GGACTAAGGACAAAGGTGCGGGGAG","id":5}],"path":[{"mapping":[{"position":{"node_id":1},"edit":[{"from_length":15,"to_length":15}]},{"position":{"node_id":2},"edit":[{"from_length":5,"to_length":5}]},{"position":{"node_id":3},"edit":[{"from_length":3,"to_length":3}]},{"position":{"node_id":4},"edit":[{"from_length":1,"to_length":1}]},{"position":{"node_id":5},"edit":[{"from_length":10,"to_length":10}]}],"name":"s1"},{"mapping":[{"position":{"node_id":1},"edit":[{"from_length":15,"to_length":15}]},{"position":{"node_id":5},"edit":[{"from_length":5,"to_length":5}]},{"position":{"node_id":1},"edit":[{"from_length":15,"to_length":15}]},{"position":{"node_id":2},"edit":[{"from_length":5,"to_length":5}]},{"position":{"node_id":3},"edit":[{"from_length":3,"to_length":3}]},{"position":{"node_id":4},"edit":[{"from_length":1,"to_length":1}]},{"position":{"node_id":5},"edit":[{"from_length":10,"to_length":10}]}],"name":"s2"}],"edge":[{"from":1,"to":5},{"from":1,"to":2},{"from":2,"to":3},{"from":3,"to":4},{"from":4,"to":5},{"from":5,"to":1}]}

Now, to generate a cyclic path via alignment.

When we serialize the graph, it gets broken into chunks. Paths get crushed at this point because they're passed through a simplistic model I implemented early in vg's life when it only worked on DAGs. We retain information in paths.hpp about the relative order of the mapping in the path, but this is not serialized along with the paths.
Paths with multiple crossings of a given node pose a problem here. What if our path loops through the region multiple times, but we can't see it "turning around" as it reverses outside of the subgraph. Then we won't know how to recombine the paths out of their components. The information is unavailable when we restore the paths from a stream using functionality in paths.cpp. The same problem is there when we're reading from an arbitrary stream of protobuf objects, which is how the above test runs.
What we need to do is maintain the relationship between mapping and paths in a way that allows us to subset the paths but still understand how multiple mappings of a path across a node relate to the whole path. The simplest way I can think of is to record the path order within the path in each mapping in the serialized format. This will allow us to reconstruct the paths correctly no matter the order the chunks come in.
There are some additional things we might want to do, such as caching the total path length (in terms of nodes) in every reference to the path, but I don't think this is strictly necessary at first pass.
At least these need to happen:

Mappings must be extended to (optionally) retain their rank in their containing Path.
In Path, map<int64_t, set<pair<string, Mapping*> > > node_mapping; should be changed to map<int64_t, map<string, set<Mapping*>>> node_mapping

Progress. I've added ranks to mappings and this seems to be working.

However, I had to manually generate the test case. I need to see if this can be done via alignment.

@ekg is what you call ranks similar to what I called step in the RDF serialization?

The rank is the position of the mapping in the larger path. This will allow the paths to be serialized in an non ordered way. I'm not sure this is what you're referring to in the RDF serialization. It adds a field to the protobuf for Mapping. I need to resolve some problems before pushing, see:

@ekg,  then yes its the same. I had to make the implicit ordering in explicit for the RDF just as you are now doing for the JSON. Makes my life easier.

@JervenBolleman sorry for the mistake on my end. I should have resolved this up-front.

I've nearly finished resolving this. Something interesting came up and I'm trying to understand the cleanest representation.
When querying a larger graph we can end up with information about a subset of a path. In the current system the path is concatenated and there is an implication in some commands (vg view, vg validate) that the path is contiguous. However it isn't, and with the path ranks on the mappings we can check to see if the path is discontinuous and handle this sensibly.
These discontinuous paths could be used in a lot of ways. We could compress a graph mapping into one. There are two possible ways to do this sensibly.

Paths can be redefined as sets of contiguous mappings. This would necessitate a lot of code changes wherever paths are touched. The concept of rank would become confusing. Path = collection if mapping vectors seems like a confusing definition.

We can introduce a mapping value that serves as a sentinel for "end of subpath". This mapping would be empty but would have a rank. Its neighbors would then have discontinuous ranks.

I like the second way because we can use the ranks in graph validation. For included paths, mappings that have consecutive ranks should match to nodes that have edges between them. Otherwise we need not impose this constraint.

Progress.
vg construct -r small/x.fa -v small/x.vcf.gz >x.vg
vg index -x t.xg -gd t.gcsa -k 11 t.vg
vg find -S AGGGCTTTTAACTACTCCACATCCAAAGCTACCCAGGCCATTTTAAGTTTCCTGT -z 7 x.vg | vg view -dpn - ...

In this example the point is that we can represent and visualize dispersed paths on the graph without considering the graph invalid or generating weird artifacts in the visualization.

The GFA output has no mechanism for this. It will need to be extended to match the protobuf/RDF specs.

Dispersed paths are working. Although, here their genesis is accidental.

Now the problem is that xg doesn't handle the ranks. This isn't an issue for the rocksdb index, as it's storing the literal mapping objects.

Gah, I need to test xg on some actual cyclic-path having graphs. Opening until I can re-resolve.

Cool, thanks for fixing this up so quickly!  I'll add support for "rank" to
our various converters today.
On Fri, Oct 30, 2015 at 12:18 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

Closed #130 https://github.com/ekg/vg/issues/130 via c10dbeb
https://github.com/ekg/vg/commit/c10dbebdb566cf62272a03ae09b37a1778da96e8
.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/130#event-450563329.

Great :)
Now what generalization are we missing? I can't think of anything.
On Oct 30, 2015 5:32 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Cool, thanks for fixing this up so quickly! I'll add support for "rank" to
our various converters today.
On Fri, Oct 30, 2015 at 12:18 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

Closed #130 https://github.com/ekg/vg/issues/130 via c10dbeb
<
https://github.com/ekg/vg/commit/c10dbebdb566cf62272a03ae09b37a1778da96e8>
.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/130#event-450563329.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/130#issuecomment-152595416.

It looks like Paths::append_mapping(const string& name, const Mapping& m) is still only adding mappings to paths that don't already contain a mapping to that node. Is that desirable? If not I can change it.

No that's not correct, so change is welcome.
I haven't tested alignment generated cyclic paths. That probably would
uncover this.
On Oct 30, 2015 9:28 PM, "adamnovak"<EMAIL_ADDRESS>wrote:

It looks like Paths::append_mapping(const string& name, const Mapping& m)
is still only adding mappings to paths that don't already contain a mapping
to that node. Is that desirable? If not I can change it.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/130#issuecomment-152655495.


Verify certificates by default (see #8)

See #8.

Yes, remove the if branch completely, falling back to the default.

Codecov Report

Merging #10 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #10   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          10     10
  Lines         557    556    -1
=====================================
- Hits          557    556    -1

Impacted Files
Coverage Δ

src/pycdstar/api.py
100% <ø> (ø)
:arrow_up:

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 b445f15...871b6ec. Read the comment docs.


Error while adding a concern to a non-leaf goal

Just pushed some changes which fixes this problem.

The issue seems to be fixed now. Thank you!


Consolidate REST response messages into a message catalog file

Description
The REST package currently has all of its response messages hardcoded directly into the responses. It is desired to consolidate all of these messages into a single organized message catalog file. That would enable easier editing of these messages in one place as well as easier formatting of these messages within the code, without having to copy/paste the same string multiple times.
@binhn please assign to me. Thanks!

this will certainly be needed for i18n.


Remove storage location to match other code samples

All other languages do not set a location for the bucket metadata. We shouldn't do so here.
See other languages:
https://cloud.google.com/storage/docs/reference/libraries

This change is

Thanks for submitting this patch. As you probably noticed, the build fails for two reasons:

With your patch the example is not executable (it compiles, but fails at runtime). If you set the storage class to "regional" then the default location ("US") does not work, do you mind also removing the set_storage_class() call?

You need to reformat the code, I would use BUILD_NAME=shared ./ci/kokoro/docker/build.sh on a Linux machine that has Docker installed to do the reformatting.  Or you could run clang-format, though if you do not use the same version the build does you might get different output from what we require.

@coryan Yes, sorry for the back-and-forth. I was not able to run the command on my OSX.
BUILD_NAME=shared ./ci/kokoro/docker/build.sh
================================================================
./ci/kokoro/docker/build.sh: line 118: nproc: command not found

Will ssh to my gubuntu, clone my fork, and try applying changes there.

@coryan I guess you'll have to approve on the other tool too?

Thanks a lot for working through the build issues!


Fix tests

See PyTest docs:
https://docs.pytest.org/en/4.6-maintenance/deprecations.html#message-parameter-of-pytest-raises
And NumPy bug:
https://github.com/numpy/numpy/issues/14189

@brainiak/committers, please review.
The changes are unrelated to each other, but all necessary to have the tests pass again.

A couple of references for the conda-build changes:
https://conda.io/projects/conda-build/en/latest/resources/compiler-tools.html#macos-sdk
https://conda.io/projects/conda-build/en/latest/resources/variants.html#conda-variables-and-command-line-arguments-to-conda-build
The SciPy pinning is the same as in setup.py.

@danielsuo, @gdoubleyew, any chance you could review?


Skip w-dream-html example on build

@aantron: closes #355.

Thank you!
I learned about opam lint --recursive from this!
Please note https://github.com/aantron/dream/pull/358/commits/6685c684243ef584e6ea4f2ce758b74ab68a3ce5


feat: Add CONTRIBUTE SECTION to readme.md

Coverage remained the same at 100.0% when pulling 1188fb06f92009184e5b4e479136a449411e25d1 on minerado:add-contribute-section into 0c3bd2decf369bb68ac37d06f597fe7ea3434eff on dleitee:master.

Thanks man!!!


Split crash reproducer data

If the recorded FuzzedDataProvider invocation data gets too long it can not be assigned to one String variable in the crash reproducer template anymore. More concretely one constant pool CONSTANT_Utf8_info entry can only hold data of
a size up to uint16.
This PR splits up the recorded data into multiple chunks to always generate valid crash reproducers.
Furthermore, a tests directory is introduced to hold an explicit Jazzer integration test to verify this issue (#269).
The integration test compiles and executes the generated crash reproducer to verify it's functionality.

@bertschneider dd appears to have a different syntax on macOS (see the pipeline). Maybe there is a common subset of the dd arguments among all platforms that we could use here.

@bertschneider dd appears to have a different syntax on macOS (see the pipeline). Maybe there is a common subset of the dd arguments among all platforms that we could use here.

AFAIK dd is not available on Windows, so I checked in an appropriate input file. It's not ideal but in this case the file is small enough and should not blow up the repository too much.

Added a mapping of all parameters not starting with - to their actual locations using rlocation. With this change all tests are successful.

Thanks, this looks pretty good now!
One last nit: Could we drop the Example prefix from the files and targets under test? The names get pretty long and now that this doesn't live under examples any more, the prefix has lost its purpose.

Ah, yes, good point. I removed the Example prefix. Thank you very much for the review(s)!


Bindable property

Are possible properties "TopColor" and "BottomColor" to be bindable.
Error type: Position 72:53. No property, bindable property, or event found for 'TopColor', or mismatching type between value and property.

Sure, it's possible. Actually, it'd imply just a little bit of effort: create the bindable properties and setting incoming colors into the current renderers.
Would it be possible you make those and send us a PR? I promise to take some time to review it :-)
Thanks in advance!


Fixed weird contributor page styling

Not sure what was going on - seems to be fixed now though.

Great work one again <3


How to compile rtl version?

Hello.
I'm just getting started and i dont know about npm or yarn, i know for compiling uikit can use yarn compile-rtl but i want to know how can i set rtl version of uiki in this template?

You can try to set dir="rtl" on html tag in layout.
This is located at src/templates/layouts/_index.pug. You need to alter line 11 and set it to something like html(lang="en" dir="rtl")
You may alternatively check uikit official docs about rtl support


Add info about dedicated args/convars for listen server

Just added some lines regarding using dedicated args and convars etc for a listen server.
This is my first PR, lmk if there's a process I need to follow or anything more to add.

Looks good to me, thanks <3


[View/edit observation] Improved toolbar header and breadcrumb

Header currently shows the name of the current layer. Some improvements:

[x] Vertically center toolbar header
[ ] Show "Add/view/edit observation" for context
[ ] Better treatment of layer name (show marker as well?)
[ ] For View/edit, show creator and creation timestamp?

This is how toolbar header looks today:

That's actually the feature details sheet; this issue referred to what's shown when you're viewing or editing an individual observation.

@gino-m thanks for correcting me. Updated screenshot:

@gino-m

It seems that the Toolbar header is already centered
User is already viewing observation and we have "Edit" in the ellipsis
Point marker is not necessary at this stage

Suggestion:

Show Creator name and timestamp at the bottom of the sheet

Thanks for the comments!

It seems that the Toolbar header is already centered

Good catch!

User is already viewing observation and we have "Edit" in the ellipsis

"Edit" is an action to allow the user to switch from "View" to "Edit" screens; the point of this Issue was that it might not really be clear what the user is looking when they're in View mode - i.e. that they're viewing a single observation associated with a feature in a particular layer. I was fishing for better ways of providing clear context.

Point marker is not necessary at this stage

Sgtm.

User is already viewing observation and we have "Edit" in the ellipsis

"Edit" is an action to allow the user to switch from "View" to "Edit" screens; the point of this Issue was that it might not really be clear what the user is looking when they're in View mode - i.e. that they're viewing a single observation associated with a feature in a particular layer. I was fishing for better ways of providing clear context.

Ok, I see. "Breadcrumb" can be a potential way to show users where they are. Perhaps we can add this question to the list of things we are going to test/validate, no actual Eng work at this stage?

Sgtm! Created #535 to track. Please add other open qs there as well!


gollvm: can't find some C std pthread_xxx  functions

What version of Go are you using (go version)?

$ go version
go version go1.16 gollvm LLVM 13.0.0git linux/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN="/home/jxzhang/workspace/gowork/bin"
GOCACHE="/home/jxzhang/.cache/go-build"
GOENV="/home/jxzhang/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jxzhang/workspace/gowork/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jxzhang/workspace/gowork"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/home/jxzhang/.local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/jxzhang/.local/gollvm/tools"
GOVCS=""
GOVERSION="go1.16 gollvm LLVM 13.0.0git"
GCCGO="/home/jxzhang/.local/gollvm/bin/llvm-goc"
AR="ar"
CC="/home/jxzhang/workspace/llvm_area/llvm-project/build/bin/clang"
CXX="/home/jxzhang/workspace/llvm_area/llvm-project/build/bin/clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4207555597=/tmp/go-build -gno-record-gcc-switches -funwind-tables"

What did you do?

I wrote a cgo demo which call pthread std functions and tried to compile it with gollvm
Here is a link on play.golang- https://play.golang.org/p/PiaY0AIGprl
Though the code can't run on play.golang for some reason...
What did you expect to see?
Compile succeed with gollvm
What did you see instead?
An error caused by an undefined reference occured
ccode.c:11: error: undefined reference to 'pthread_join'

In addition to this function, there are some other functions that also have this error:
pthread_once, pthread_mutexattr_init, pthread_mutexattr_settype, pthread_key_create, pthread_getspecific, pthread_mutexattr_destroy ...
Some extra observations
These functions above seems different between pthread_create which can be referenced normally
jx $  nm /home/jx/.local/gollvm/lib64/libgo.so.13git | grep pthread_create
00000000010831e0 t __wrap_pthread_create
                 w pthread_create
jx $ nm /home/jx/.local/gollvm/lib64/libgo.so.13git | grep pthread_join
jx $ nm /home/jx/.local/gollvm/lib64/libgo.so.13git | grep pthread_once
                 w pthread_once

Is there a reason why you don't add "-lpthread" to your cgo linker flags? e.g.
#cgo LDFLAGS: -L./ -lpthread
That is the normal thing to do when linking C code that uses functions from the pthread library.

The main reason  I dropped -lpthread" here is that the code in issue can be compiled successfully by original Go compiler.
And gollvm can also succeed when only the pthread_create function is called.
In fact, I have tried to add "-lpthread" to #cgo，and add it to args when compiling middle files with llvm-goc manually
But another error appeared:
# pthread
/home/jxzhang/.local/gollvm/bin/../lib64/libgo.so: error: undefined reference to 'ffi_tramp_is_supported'
/home/jxzhang/.local/gollvm/bin/../lib64/libgo.so: error: undefined reference to 'ffi_tramp_alloc'
/home/jxzhang/.local/gollvm/bin/../lib64/libgo.so: error: undefined reference to 'ffi_tramp_get_addr'
/home/jxzhang/.local/gollvm/bin/../lib64/libgo.so: error: undefined reference to 'ffi_tramp_free'

It seems more difficult...
This error appeared even if I didn't call pthread_join, but I have pulled the latest libffi.
I got nothing about this error on google..

Ok, this part looks actionable. I'll send a CL, thanks.
For the pthread issue, I think this is arising due to differences in the cgo implementations for the main go compiler and gccgo/gollvm. In particular it looks as though we get "-lpthread" vua
https://go.googlesource.com/go/+/1c9e587b90172e7654db897d8c938ffc665e1673/src/runtime/cgo/cgo.go#19
which is not part of the gofrontend version of cgo. I'll ask around about this.

The gccgo driver program automatically adds -lpthread when linking statically against libgo.  When libgo is linked dynamically, it depends on libpthread.so anyhow.  So with gccgo programs always have an implicit -lpthread.

Appreciate your help. The latest version works well with such scenario.
I think this issue can be closed, right?

The gccgo driver program automatically adds -lpthread when linking
statically against libgo. When libgo is linked dynamically, it depends
on libpthread.so anyhow. So with gccgo programs always have an
implicit -lpthread.

From what I am seeing gccgo shows the same behavior:
$ which go
/ssd/gcc-trunk/cross/bin/go
# ptgollvm
ccode.c:11: error: undefined reference to 'pthread_join'
collect2: error: ld returned 1 exit status
$ go build -x -gccgoflags=-v . |& fgrep lpthread
$ ldd `which go` | fgrep libgo
	libgo.so.19 => /ssd/gcc-trunk/cross/lib64/libgo.so.19 (0x00007f0d5dcd3000)
$ nm /ssd/gcc-trunk/cross/lib64/libgo.so.19 | fgrep pthread_create
                 w pthread_create
00000000011c0860 t __wrap_pthread_create
$ nm /ssd/gcc-trunk/cross/lib64/libgo.so.19 | fgrep pthread_join
$

It's true that libgo.so depends on libpthread, but this doesn't help resolve the reference to pthread_join at link time.

Ah, interesting.  Thanks.
So perhaps the question is whether we should always link against -lpthread, not because we normally need to, but because that is in effect what happens with the gc compiler.

go build -gccgoflags="-lpthread"


Lazily decode docMap and argMap

These are only used in case of a doc reexport so most of the time
decoding these is wasted work.

I tried a few packages with lots of modules for example Agda: It loads ~500 InstalledInterfaces but and accesses ~30 their docMaps and argMaps (c.f. https://gist.github.com/alexbiehl/8f8d6637a39154c36925984139de065f). So I think this is worthwhile.


Change minimal Go version to 1.21 and removed unnecessary test

Changed minimal go version to 1.21 (stable version), so other libraries does not need to bump their Go versions to use it.
Considering this library is not using (and probably won't use in the future) Goroutines, we can safety remove the package_test Goroutines leakage checks and avoid adding unneeded external decencies to the library.

There is no reason given in the PR or the commit for the go version downgrade and removal of the test, can we add that to the commit message?

Hey @jsvd, I've added it on the PR description! thanks for reviewing :)

Overall LGTM, I noticed you bumped .go-version again, maybe we could also bump versions in .golangci.yml so the library is tested with the most recent golang, even if it supports an older one.

I've adapted the .golangci.yml from another Elastic project, but it seems those go: ... versions on the linters have no effect, it should be on the run section instead. When it's empty, it defaults to the go.mod version and/or  GOVERSION env var, which I think is the optimal behaviour for the linters. It also had a few invalid/deprecate settings that I fixed on the last commit.


[BUG] Error when syncing to guild without app.cmds scope with disable_sync

Describe the bug.
Everything I describe is based off other people's reports and theoretical guesswork. This may be inaccurate.
Many big bots are in a large number of guilds, and so it makes sense for them to turn off disable_sync. Besides for the obvious, this has another behavior, however.
Instead of erroring out if a guild has the bot without the application.commands scope (which is possible under certain contexts, and happens especially often for bigger bots), having disable_sync will instead simply warn the user - we don't need to sync to the bot so not having application commands isn't needed, but it is a thing to note.
However, in 4.3.1 at least, the bot has been erroring out when seeing a guild without the scope instead of simply warning.
List the steps.

Have a bot be in a server (at least one) where it doesn't have the application.commands scope.
Start a bot with disable_sync=True.

What you expected.
For interactions.py to warn the user, but not necessarily stop them.
What you saw.
interactions.api.error.LibraryException: An error occurred:
Missing Access, with code '50001' and severity '40'
Could not prepare the client:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/interactions/ext/autosharder/dummy.py", line 47, in _ready
    await self._Client__get_all_commands()
  File "/usr/local/lib/python3.8/dist-packages/interactions/client/bot.py", line 426, in __get_all_commands
    _cmds = await self._http.get_application_commands(
  File "/usr/local/lib/python3.8/dist-packages/interactions/api/http/interaction.py", line 45, in get_application_commands
    return await self._req.request(
  File "/usr/local/lib/python3.8/dist-packages/interactions/api/http/request.py", line 174, in request
    raise LibraryException(
interactions.api.error.LibraryException: An error occurred:

What version of the library did you use?
stable
Version specification
4.3.1
Code of Conduct

[X] I agree to follow the contribution requirements.

As for what causes it, my theory is that we now detect and throw an error in our HTTP requests when we previously didn't.
Take a look at these lines that get invoked with disable_sync=True.. You can clearly see that triggering the warning depends on the response being a dict with a field for the "code", which represents the response returning an error.
However, as of lately, the HTTP handler has been throwing proper errors instead of returning the dict with said errors, as a part of improving the error UX of interactions.py. I believe #973 has caused this particular bug, as it detects the same condition that the disable_sync code was relying on, but throws an error instead of passing the response down (as it should).
This likely can be solved by changing that whole section of code to try-except the LibraryException and propagating the warning from there while still suppressing the actual error.

Fun fact: #868 does the fix needed, but for syncing, not for here.


ESC to remove popups?

I wrote a too-long sentence and harper tells me so.  The problem is that harper's message comes inside a popup that prevents me from shortening that long sentence.  In the screenshots below, I want to create a sentence break at "i.e." but when I put my cursor on "i.e.", the popup blocks it.
There must be a software convention that the escape key removes popups; I automatically hit ESC, and was surprised that the popup didn't disappear.  Adding "ESC removes popups" functionality could be a way to to handle this.

Would you mind providing more information about which editing environment you are working from (Zed, Web, VSCode, Neovim, etc)?

This looks like Obsidian

Right.  Obsidian.


⚠ Bofrost.at has degraded performance

In 4edd650, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1039 ms

Resolved: Bofrost.at performance has improved in bf93030 after 307 days, 16 hours, 4 minutes.


[SPARK-15923][YARN] Spark Application rest api returns 'no such app: …

What changes were proposed in this pull request?
Update monitoring.md.
…'

Can one of the admins verify this patch?

Updated the doc based on the feedback.

@steveloughran does that look right?

LGTM. Clarifies that it is yarn-cluster mode only, not in client.


Refactor grading dashboard and reduce API overhead

Description

Mainly refactored code, but also added new custom components to support minimal dropdowns, and also restored the old behaviour of allowing staff to toggle between viewing only submissions from their own group (now the default) or all groups. This was previously removed in #2437.
With over 100 groups, this would result in a >100x performance improvement.
Type of change

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

Checklist

[x] I have tested this code
[ ] I have updated the documentation

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 47 (0.0%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.03%) to 37.367%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/commons/SimpleDropdown.tsx
0
10
0.0%

src/pages/academy/grading/Grading.tsx
0
15
0.0%

src/features/grading/GradingUtils.ts
0
22
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/pages/academy/grading/Grading.tsx
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
5740

Relevant Lines:
14441

💛  - Coveralls


Debounce so that there's only one pending promise

async function action() {
	delay(3000);
	alert('Done')!
}

button.onclick = action;

If the user double-clicks the button, action is run twice. This usually debounced/throttled with timeouts, but how would you throttle this so that action calls don't pile up instead?
This is different from p-debounce since that's timeout-based and completely ignores the state of the promise.

I'm assuming you want to execute a promise-returning function unless it is already running.
Since I can't add a module, here's how it would work:
const pStateThrottle = async function_ => {
	let isRunning = false

	return (...arguments_) => {
		if (!isRunning) {
			isRunning = true
			await function_(...arguments_)
			isRunning = false
		}
	}
}

const action = pStateThrottle(async () => {
	await delay(3000)
	alert("Waited 3 seconds")
})

button.onclick = action

I'm assuming you want to execute a promise-returning function unless it is already running.
Since I can't add a module, here's how it would work:
const pStateThrottle = async function_ => {
	let isRunning = false

	return (...arguments_) => {
		if (!isRunning) {
			isRunning = true
			await function_(...arguments_)
			isRunning = false
		}
	}
}

const action = pStateThrottle(async () => {
	await delay(3000)
	alert("Waited 3 seconds")
})

button.onclick = action

Looks good. I'd use try/finally to return the value and ensure that the state is always updated
		try {
			isRunning = true
			return await function_(…arguments_)
		} finally {
			isRunning = false
		}

Looks good. I'd use try/finally to return the value and ensure that the state is always updated
		try {
			isRunning = true
			return await function_(…arguments_)
		} finally {
			isRunning = false
		}

I wonder if this could be an option or separate method to https://github.com/sindresorhus/p-debounce

I wonder if this could be an option or separate method to https://github.com/sindresorhus/p-debounce

Alternative names:

p-dedupe
p-deduplicate
p-ensure-one

Alternative names:

p-dedupe
p-deduplicate
p-ensure-one

Just nitpick, I would make it return early:
const pStateThrottle = async function_ => {
	let isRunning = false

	return (...arguments_) => {
		if (isRunning) {
			return
		}

		try {
			isRunning = true
			return await function_(…arguments_)
		} finally {
			isRunning = false
		}
	}
}

const action = pStateThrottle(async () => {
	await delay(3000)
	alert("Waited 3 seconds")
})

button.onclick = action

Just nitpick, I would make it return early:
const pStateThrottle = async function_ => {
	let isRunning = false

	return (...arguments_) => {
		if (isRunning) {
			return
		}

		try {
			isRunning = true
			return await function_(…arguments_)
		} finally {
			isRunning = false
		}
	}
}

const action = pStateThrottle(async () => {
	await delay(3000)
	alert("Waited 3 seconds")
})

button.onclick = action

Currently, when called a second time, it will just resolve the promise right away. That's fine for this specific use-case, but I think it might be better to store the promise and return that instead. That way the second call would wait for the original delay to finish too.

Currently, when called a second time, it will just resolve the promise right away. That's fine for this specific use-case, but I think it might be better to store the promise and return that instead. That way the second call would wait for the original delay to finish too.

I think it might be better to store the promise and return that instead.

const pStateThrottle = async function_ => {
	let isRunning = false
	let currentPromise

	return (...arguments_) => {
		if (isRunning) {
			return currentPromise
		}

		try {
			isRunning = true
			currentPromise = function_(…arguments_)
			return await currentPromise
		} finally {
			isRunning = false
		}
	}
}

const action = pStateThrottle(async () => {
	await delay(3000)
	alert("Waited 3 seconds")
})

button.onclick = action

I think it might be better to store the promise and return that instead.

const pStateThrottle = async function_ => {
	let isRunning = false
	let currentPromise

	return (...arguments_) => {
		if (isRunning) {
			return currentPromise
		}

		try {
			isRunning = true
			currentPromise = function_(…arguments_)
			return await currentPromise
		} finally {
			isRunning = false
		}
	}
}

const action = pStateThrottle(async () => {
	await delay(3000)
	alert("Waited 3 seconds")
})

button.onclick = action

@Richienb You don't need the boolean then.

@Richienb You don't need the boolean then.

I wonder if this could be an option or separate method to sindresorhus/p-debounce

Only if it's an alternative to the timer rather than an addition (i.e. just "wait for the promise", never "wait for the promise and the timer")
Given that none of the options apply to this behavior, the signature can become:
function debounce(fn, [wait, [options]])

No wait means it just waits for the Promise.

I wonder if this could be an option or separate method to sindresorhus/p-debounce

Only if it's an alternative to the timer rather than an addition (i.e. just "wait for the promise", never "wait for the promise and the timer")
Given that none of the options apply to this behavior, the signature can become:
function debounce(fn, [wait, [options]])

No wait means it just waits for the Promise.

@fregante Or a separate method? debounce.single/debounce.wait/debounce.one.
Also, related issue: https://github.com/sindresorhus/p-debounce/issues/3

@fregante Or a separate method? debounce.single/debounce.wait/debounce.one.
Also, related issue: https://github.com/sindresorhus/p-debounce/issues/3

debounce.promise would make the most sense to me

debounce.promise would make the most sense to me

Debouncing queues extra calls to be run after a delay whereas throttling dumps extra calls without ever executing them. We are actually debouncing function calls.

Debouncing queues extra calls to be run after a delay whereas throttling dumps extra calls without ever executing them. We are actually debouncing function calls.

Debouncing queues extra calls to be run after a delay

No, debouncing does not queue calls. Only p-debounce returns the same promise for all the calls, but usually debouncers drop calls. In fact they're often used to in event listeners like window.onresize = debounce(callback, 300) so that they're only called once the resize events stop.
Throttling calls the function "at most every X milliseconds", so I don't think it applies here.

Debouncing queues extra calls to be run after a delay

No, debouncing does not queue calls. Only p-debounce returns the same promise for all the calls, but usually debouncers drop calls. In fact they're often used to in event listeners like window.onresize = debounce(callback, 300) so that they're only called once the resize events stop.
Throttling calls the function "at most every X milliseconds", so I don't think it applies here.

Therefore, this should result in one alert:
const action = debounce.promise(async () => {
	delay(3000);
	alert('Done')!
})

action();
action();

Therefore, this should result in one alert:
const action = debounce.promise(async () => {
	delay(3000);
	alert('Done')!
})

action();
action();

I've begun implementing this in p-debounce and I've come to this realisation: What is this supposed to do?
const action = debounce.promise(async value => {
	delay(3000);
	return value
})

action("a");
action("b");

Right now, it throws away "b" which leads to unpredictable results as the second call will resolve with b.
Do we want to queue up calls instead of discarding them in a separate implementation in p-throttle?

I've begun implementing this in p-debounce and I've come to this realisation: What is this supposed to do?
const action = debounce.promise(async value => {
	delay(3000);
	return value
})

action("a");
action("b");

Right now, it throws away "b" which leads to unpredictable results as the second call will resolve with b.
Do we want to queue up calls instead of discarding them in a separate implementation in p-throttle?

Right now, it throws away "b" which leads to unpredictable results as the second call will resolve with a.

That's what debounce does, it discards calls:
https://github.com/sindresorhus/p-debounce/blob/46ed3aab5974c2ced01a166233965bfa129de9ce/test.js#L49-L50

Right now, it throws away "b" which leads to unpredictable results as the second call will resolve with a.

That's what debounce does, it discards calls:
https://github.com/sindresorhus/p-debounce/blob/46ed3aab5974c2ced01a166233965bfa129de9ce/test.js#L49-L50

Throttle discards calls too. You're thinking of queues, which neither debounce nor throttle are.

p-throttle defines queue:
https://github.com/sindresorhus/p-throttle/blob/004bcd3d837bc24ca55a88f8c4c8896a95545c91/index.js#L19

Throttle discards calls too. You're thinking of queues, which neither debounce nor throttle are.

p-throttle defines queue:
https://github.com/sindresorhus/p-throttle/blob/004bcd3d837bc24ca55a88f8c4c8896a95545c91/index.js#L19

Indeed.

How's p-throttle different from p-limit? It appears the same down to the concurrency option.
p-throttle is the only "throttle" module that behaves this way. See this example, none of them execute the calls 2, and 3 except p-throttle.
https://runkit.com/bfred-it/5ffe7a7977172c001b32528f

Indeed.

How's p-throttle different from p-limit? It appears the same down to the concurrency option.
p-throttle is the only "throttle" module that behaves this way. See this example, none of them execute the calls 2, and 3 except p-throttle.
https://runkit.com/bfred-it/5ffe7a7977172c001b32528f

p-throttle is the only "throttle" module that behaves this way. See this example, none of them execute the calls 2, and 3 except p-throttle.

Yeah, I don't remember why I made it like that. Seems you're not the only confused one: https://github.com/sindresorhus/p-throttle/issues/15 Maybe we should add a discard option and make it default to true? That way the default behavior is the expected one and users can set it to false to get the old behavior.

p-throttle is the only "throttle" module that behaves this way. See this example, none of them execute the calls 2, and 3 except p-throttle.

Yeah, I don't remember why I made it like that. Seems you're not the only confused one: https://github.com/sindresorhus/p-throttle/issues/15 Maybe we should add a discard option and make it default to true? That way the default behavior is the expected one and users can set it to false to get the old behavior.

Since this new function also discards calls, does it still make sense for it to be added to p-debounce?

Since this new function also discards calls, does it still make sense for it to be added to p-debounce?

Yeah, I don't remember why I made it like that

If I think about it it does make sense as it does throttle calls; the only issue is that it doesn't match the meaning throttle has in the JS community.

How's p-throttle different from p-limit?

Answering myself: p-limit doesn't have an interval parameter

Yeah, I don't remember why I made it like that

If I think about it it does make sense as it does throttle calls; the only issue is that it doesn't match the meaning throttle has in the JS community.

How's p-throttle different from p-limit?

Answering myself: p-limit doesn't have an interval parameter

I think this should/could be part of p-memoize:

it supports multiple calls at once, as long as the parameters are different
can support "one call at once regardless of parameters" by just passing cacheKey: () => {} probably

Implementation-wise it would be identical to how cachePromiseRejection is implemented:
if (!cachePromiseResolution && cacheItem && cacheItem.then) {
	  cacheItem.then(() => {
		  cache.delete(cacheKey(arguments_));
	  });
}

Alternative names:

p-dedupe
p-deduplicate
p-ensure-one

I suggest the name p-collapse, as the behavior is similar to request collapsing on CDNs.
Request collapsing is the practice of combining multiple requests for the same object into a single request to origin, and then using the resulting response to satisfy all pending requests.

Closing in favor of https://github.com/sindresorhus/p-memoize/issues/20

@fregante you may be interested in https://github.com/TehShrike/gate-keeper


Need help phrasing some json

I have some json from Konachan ( )
I would like to get the values for the key1,key2,key3 or key 4 but i can only figure how to get the values for the first key like:
apiurl := " https://konachan.net/post.json?limit=4&tags=foxgirl" 	res, err := http.Get(apiurl) 	if err != nil { 		fmt.Println(err.Error()) 	} 	defer res.Body.Close() 	thing, err := ioutil.ReadAll(res.Body) 	if err != nil { 		fmt.Println(err.Error()) 	} 	cut1 := bytes.TrimPrefix(thing , []byte("[")) 	cut2 := bytes.TrimSuffix(cut1  , []byte("]"))         ans := gjson.ParseBytes(cut2)         id := ans.Get("*id")         fmt.Println(id)
My idea was geting the value of id in x key stored in a variable

Hi @insomnyawolf,
You can get a specified array item by using it's index as the path, for example:
item := gjson.GetBytes(thing, "0")
item
fmt.Println()

Hi @insomnyawolf,
You can get a specified array item by using it's index as the path, for example:
item := gjson.GetBytes(thing, "0")
println(item.String())

... will get the first item, and gjson.GetBytes(thing, "1") will get the second item.
Other examples:
println(gjson.GetBytes(thing, "2.id").Int())

will print 248833
println(gjson.GetBytes(thing, "2.author").String())

will print mattiasc02
Does this help answer you question?

Thanks for the help.
Its exactly what i needed.
Thanks

You're welcome. I'm closing this issue for now. Thanks for using GJSON!


Change how we print installed Elixir version

Before this patch we printed:
Using Elixir / -otp- version v1.12.0-otp-24

The  / -otp- part looks a bit out of place.
After this patch, it is simply:
Using Elixir v1.12.0-otp-24

Another idea would be to print:
Using Elixir v1.12.0 (built for OTP 24)

Another idea would be to print:
Using Elixir v1.12.0 (built for OTP 24)

👍

Another idea would be to print:
Using Elixir v1.12.0 (built for OTP 24)

I like this better 😄; can't actually remember why the -otp- got left there, in the description.
Would you be so kind as to adapt it, @wojtekmach? Otherwise I can also do it later, if you prefer not to spend more time on this now.


Multiple Answer

Good night
I want to make a bot answer my 3 messages and at the end of the answer will combine the message I'm delivering.
Example

me> / unlock
bot> what is your account?
me> drow-ranger
bot> what is your computer name?
me> PC-99
bot> what's your ticket number?
me> TICKET-001
bot> admin pls unlock drow-ranger on PC-99 with TICKET-001

Is this possible? Please help.
Give me clue to make session. Thank You.

My Script Sir.. Maybe u can give me clue.

step=1
def handle(unlockuser):
content_type, chat_type, chat_id = telepot.glance(unlockuser)
chat = unlockuser['text']
source = unlockuser['from']['first_name']+' '+unlockuser['from']['last_name']
print(content_type, chat_type, chat_id, source, chat)

if step==1:
    if chat == '/unlockuser':
        response = 'User?'
        bot.sendMessage(chat_id, response)
        step=2

elif step==2:
    if content_type == 'text':
        user1=chat
        response = 'Computer?'
        bot.sendMessage(chat_id, response)
        step=3

elif step==3:
    if content_type == 'text':
        computer1=chat
        response = user1+'Computer?'
        bot.sendMessage(chat_id, response)
        step=4

you can append each and every message depending on step to a dictionary or list and at the end add those contents to your end message


Infinite-loop in AdjustHue

Click to expand!
Issue Type
Bug
Source
binary
Tensorflow Version
tf 2.9 and 2.11.0-dev20220828
Custom Code
No
OS Platform and Distribution
Linux Ubuntu 20.04
Mobile device
No response
Python version
3.10
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
CUDA 11.5
GPU model and memory
No response
Current Behaviour?
In the CPU implementation of AdjustHue, an infinite loop can be triggered.
Given a large `delta`, it will take forever to compute the `delta%6`, which may cause a DoS.
Although delta is supposed to be a small value, the code dose not check it.

Standalone code to reproduce the issue
import tensorflow as tf

with tf.device("CPU"):
    res = tf.raw_ops.AdjustHue(
    	images=tf.random.uniform([2, 2, 2, 3]),
        delta=1e100,
    )

Relevant log output
It won't stop in years.

The issue is acctually caused by a optimization, which uses loops of add/sub to calculate delta%6 to avoid float mul. The code can be found  here.
I hope this can help you identify and fix this issue.

Could you please use the updated op under tf.imgae.adjust_hue, which does the check for delta which has to be in the limit of [-1,1].
Below is the updated code and the error message.
import tensorflow as tf

with tf.device("CPU"):
    res = tf.image.adjust_hue(
    	image=tf.random.uniform([2, 2, 2, 3]),
        delta=1e100,
    )

ValueError: delta must be in the interval [-1, 1]

@sachinprasadhs
Thanks for your response!
This is a solution. But isn't it a potential security issue?

This is a solution. But isn't it a potential security issue?

Why is this a security issue?  We often fail with these python exceptions for invalid inputs.

This is a solution. But isn't it a potential security issue?

Why is this a security issue? We often fail with these python exceptions for invalid inputs.

Python exceptions can be catched with a catch sentence. But an  infinite-loop can lead to DoS. This security issue can be found at https://cwe.mitre.org/data/definitions/834.html.

But an infinite-loop can lead to DoS. This security issue can be found at https://cwe.mitre.org/data/definitions/834.html.

I thought the infinite loop issue was solved by the restriction on delta - so it now throws an exception instead of looping indefinitely.  So my question was why the current solution is a security issue.
And if you wanted to create an infinite loop, you could just do so in python (or using something like tf.while_loop).  You don't need to obfuscate it behind a call to AdjustHue.


[1.10.2 <IP_ADDRESS>2] Teleporter immediately ports back to original location

I made a webm of the weirdness, but what happens is when I walk through one teleporter, I appear on the other end, long enough to see several chunks load, then get sent back to my starting location.  Server logs are apparently empty of any reasoning for this, per the server admin.
We're running All The Mods 1.10.2v1.22.

Apparently fixed in 1.11.


Allow semicolon-separated statements, empty statements and labeled statements.

test? :D

They are in the other branch.


Create Color Scheme and place the colors used in a global variables file: FE

AC1: Come up with a color scheme for the application using our themes. From there, place the colors in a global variable file on the FE so that it may be used by the entire application and we can maintain consistent color schemes throughout the application.
AC2: Come up with some font suggestions that fit the overall theme of the application, and insert them into the global styling file as well.
AC3: Attach screen shots in your PR of the colors to be used and the font to be used.

This will go ideally go into our tailwind.config.ts file once we merge in our Next.js scaffolding.

Hey all - do we have any existing documentation on our color scheme for me to work off of?

@chelseaharris137 Agreed; I think it's best to hold off until Monday until we can all sync together and get status updates from all parts of the group. Plus, I'm sure some in the group won't be around for the long weekend to collab on this.

As of right now, we do not have a color theme well defined. There are a few people working in the UX-design channel, I would reach out there as there is likely someone working on a theme.


Nightly toolchain for stabilized features

Is nightly still required for this crate? The features used were stabilized in 1.64.0. Are there other reasons for nightly or can the nightly toolchain requirement be dropped and the #![feature] used in lib.rs be removed?

It can be removed if the features are stable, but the code would need to be updated.


Auto fill 'method、body、head ......' when select a url from url_combox

When  I using the rest-client tools, I found it's not convince when I want to rerun a rest,

I need re fill the method/ header/body etc.  hand by hand, even if I did not need to change any field.
So, I commit this pull request to make up it.
when select a url from url combox,  It's will search the historyManager to find the history operation.
when found one, It will use it to re fill.

@subwiz please  review this PR, thank you.

Will do this week!


REP-38: transition to Review

We should wait to see how REP-33 progresses before moving forward with this.


convox init generates .dockerignore

This should be deployed when https://github.com/convox/rack/pull/657 is released.

 convox init generates .dockerignore


matplotlib Linestyle 'None' does not get transformed

Hello,
trying this:
import tikzplotlib
import numpy
from matplotlib.figure import Figure
fig = Figure((5,5))
ax = fig.add_subplot(111)
t = numpy.asarray([1,2,3,4])
ax.errorbar(t, t, yerr=t)
tikzplotlib.save("test.tikz", fig)

Gives:
/tikzplotlib/_path.py in mpl_linestyle2pgfplots_linestyle(data, line_style, line)
    370             return None
    371
--> 372         if len(line_style[1]) == 2:
    373             return (
    374                 "dash pattern="

TypeError: object of type 'NoneType' has no len()

I also tried changing the linestyle manually, the result stays the same.
I guess this is a bug or am I just stupid?

Which version of matplotlib are you using?
For me, your example works well with 3.2.2 but fails with 3.3.0.
Btw: this error look similar to the ones I encountered during the check of my latest pull request.

Fixed now.


Implement multipart/form uploads

Clients/Users should be able to upload images via a multipart/form request.
The images should be stored to a directory specified by the CALENDAGO_WORK_DIR environment variable.

I will also need to create a server right?

In a way, initially you just have to modify the HandleFunc at https://github.com/zikani03/calendago/blob/7e84c7a54177447ca78d0a7b886b91e92732fae1/main.go#L12-L15

Understood


Add Word Frequency Calculator

Description
This tool will allow users to input their location (latitude and longitude) and the date, and it will provide them with the times of sunrise and sunset for that particular day.
Screenshots

Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

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

@Rakesh9100
Kindly assign me this issue

We already have a Word Count Calculator @Aditi22Bansal


Time „last updated“ is 2 hours behind

In the homebridge Log the „last updated“ Time is 2 hours behind my local Time.
Sep 02 13:09:04 raspberrypi homebridge[7147]: [2017-9-2 13:09:04] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 0 to 1 on Sat Sep 02 2017 11:09:04
Also the Home App is showing this wrong Time.

My guess is timezone settings.  The time reported by the Hue bridge should be in UTC, which homebridge-hue converts to local time.  You might want to check the output of homebridge -D:
[9/2/2017, 2:14:52 PM] [Hue] Living Room Temperature: sensor temperature changed from 2093 to 2107 on 2017-09-02T12:14:52
[9/2/2017, 2:14:52 PM] [Hue] Living Room Temperature: set homekit temperature from 20.9°C to 21.1°C on Sat Sep 02 2017 14:14:52

The first (debug) message (only shown for -D) shows the bridge (UTC) time; the second (info) message shows the (HomeKit) local time.

My timezone is set to Europe/Berlin. The local Time is correct. The debug output is the same. The Sensor Time is still 2 hours behind.

The debug output is the same.

The same as what?  Could you please post the messages?  And the messages with the versions (one for homebridge-hue and one for the Hue bridge)?

What message do you mean?
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Philips hue: BSB002 bridge v1707040932, api v1.20.0
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] deCONZ-GW: deCONZ bridge v2.04.73, api v1.0.2
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] deCONZ-GW: 9 accessories
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Philips hue: 6 accessories
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Philips hue'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Philips hue: 3 services
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Pauls Lala'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Mikrowelle'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Abzug'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Fernsehsteckdose'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Vitrine'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'deCONZ-GW'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] deCONZ-GW: 2 services
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Stehlampe'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Badlampe'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Fernsehlampe'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Nachttischlampe'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Flurlampe'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Küchenlampe'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Bewegungsmelder Flur'...
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Initializing platform accessory 'Bewegungsmelder Küche'...

Sep 02 20:36:17 raspberrypi homebridge[8381]: [2017-9-2 20:36:17] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 0 to 1 on Sat Sep 02 2017 18:36:17
Sep 02 20:36:17 raspberrypi homebridge[8381]: [2017-9-2 20:36:17] [Philips Hue] Flurlampe: homekit power changed from 0 to 1
Sep 02 20:36:21 raspberrypi homebridge[8381]: [2017-9-2 20:36:21] [Philips Hue] Bewegungsmelder Küche: set homekit motion from 0 to 1 on Sat Sep 02 2017 18:36:21
Sep 02 20:36:22 raspberrypi homebridge[8381]: [2017-9-2 20:36:22] [Philips Hue] Küchenlampe: homekit power changed from 0 to 1Sep 02 20:36:31 raspberrypi homebridge[8381]: [2017-9-2 20:36:31] [Philips Hue] Bewegungsmelder Küche: set homekit motion from 1 to 0 on Sat Sep 02 2017 18:36:31Sep 02 20:36:39 raspberrypi homebridge[8381]: [2017-9-2 20:36:39] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 1 to 0 on Sat Sep 02 2017 18:36:39
Sep 02 20:37:21 raspberrypi homebridge[8381]: [2017-9-2 20:37:21] [Philips Hue] Küchenlampe: homekit power changed from 1 to 0
Sep 02 20:37:21 raspberrypi homebridge[8381]: [2017-9-2 20:37:21] [Philips Hue] Bewegungsmelder Flur: set homekit light level from 0.0001 lux to 1.4328 lux on Sat Sep 02 2017 18:37:21Sep 02 20:38:13 raspberrypi homebridge[8381]: [2017-9-2 20:38:13] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 0 to 1 on Sat Sep 02 2017 18:38:13
Sep 02 20:38:23 raspberrypi homebridge[8381]: [2017-9-2 20:38:23] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 1 to 0 on Sat Sep 02 2017 18:38:23
Sep 02 20:38:24 raspberrypi homebridge[8381]: [2017-9-2 20:38:24] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 0 to 1 on Sat Sep 02 2017 18:38:24

What message do you mean?

These two, thanks
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] Philips hue: BSB002 bridge v1707040932, api v1.20.0
Sep 02 20:35:28 raspberrypi homebridge[8381]: [2017-9-2 20:35:28] [Philips Hue] deCONZ-GW: deCONZ bridge v2.04.73, api v1.0.2

And the message for homebridge-hue's version, a bit earlier in the log.  It looks like:
[9/2/2017, 8:45:08 PM] Loading 1 platforms...
[9/2/2017, 8:45:08 PM] [Hue] Initializing Hue platform...
[9/2/2017, 8:45:08 PM] [Hue] homebridge-hue v0.5.26, node v6.11.2, homebridge v0.4.27

So you have both a Hue bridge and a deCONZ gateway connected to homebridge-hue.  And it's the  sensors connected to deCONZ that show the wrong time?

My timezone is set to Europe/Berlin.

Both in deCONZ and on the Raspberry?  For deCONZ, check Show Advanced Settings  under Settings in the webapp (or check /config/timezone through the API).  For the Raspberry, run sudo raspi-config and check option 4 (Localisation Options), I2 (Change Timezone).

The debug output is the same.

Looks like you're starting homebridge automatically.  In that case you need to add the -D flag to the script that starts  homebridge.  Alternatively, temporary disable the service (which should stop homebridge) and run homebridge -D from the command line.  You'll get an EADDRINUSE error if you try to run homebridge when it already running.

And the message for homebridge-hue's version, a bit earlier in the log. It looks like:

Sep  2 20:35:21 raspberrypi homebridge[8381]: [2017-9-2 20:35:21] [Philips Hue] Initializing Hue platform...
Sep  2 20:35:21 raspberrypi homebridge[8381]: [2017-9-2 20:35:21] [Philips Hue] homebridge-hue v0.5.26, node v8.4.0, homebridge v0.4.27

So you have both a Hue bridge and a deCONZ gateway connected to homebridge-hue. And it's the sensors connected to deCONZ that show the wrong time?

Yes, right.
Before the sensors were connected to the hue bridge and the time was also wrong.

Both in deCONZ and on the Raspberry?
Yes.

What part of the debug output do you need?
[2017-9-2 21:13:48] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 0 to 1 on Sat Sep 02 2017 19:13:48[2017-9-2 21:14:06] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 1 to 0 on Sat Sep 02 2017 19:14:06

What part of the debug output do you need?
I need the debug messages where homebridge-hue reports the lastupdated value on the bridge/gateway, like:
[9/2/2017, 2:14:52 PM] [Hue] Living Room Temperature: sensor temperature changed from 2093 to 2107 on 2017-09-02T12:14:52

I need the debug messages where homebridge-hue reports the lastupdated value on the bridge/gateway, like:

Yes, this i have posted:[2017-9-2 21:13:48] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 0 to 1 on Sat Sep 02 2017 19:13:48[2017-9-2 21:14:06] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 1 to 0 on Sat Sep 02 2017 19:14:06

No, these are the regular info messages that homebridge-hue sets the HomeKit values.  I need the debug messages without 'homekit" in them that show the bridge/gateway values.

[2017-9-2 21:54:06] [Philips Hue] deCONZ-GW: hue bridge request #33: ok
[2017-9-2 21:54:06] [Philips Hue] Philips hue: hue bridge request #32: ok
[2017-9-2 21:54:07] [Philips Hue] Bewegungsmelder Küche: event: sensor presence changed from false to true on 2017-09-02T19:54:07
[2017-9-2 21:54:07] [Philips Hue] Bewegungsmelder Küche: set homekit motion from 0 to 1 on Sat Sep 02 2017 19:54:07
[2017-9-2 21:54:07] [Philips Hue] Küchenlampe: homekit power changed from 0 to 1
[2017-9-2 21:54:07] [Philips Hue] deCONZ-GW: hue bridge request #34: put /lights/6/state {"on":true}
[2017-9-2 21:54:07] [Philips Hue] deCONZ-GW: hue bridge request #34: ok
[2017-9-2 21:54:07] [Philips Hue] Philips hue: hue bridge request #33: get /config
[2017-9-2 21:54:07] [Philips Hue] deCONZ-GW: hue bridge request #35: get /config
[2017-9-2 21:54:08] [Philips Hue] deCONZ-GW: hue bridge request #35: ok
[2017-9-2 21:54:08] [Philips Hue] deCONZ-GW: hue bridge request #36: get /sensors
[2017-9-2 21:54:08] [Philips Hue] Philips hue: hue bridge request #33: ok
[2017-9-2 21:54:08] [Philips Hue] Philips hue: hue bridge request #34: get /sensors
[2017-9-2 21:54:08] [Philips Hue] deCONZ-GW: hue bridge request #36: ok
[2017-9-2 21:54:08] [Philips Hue] deCONZ-GW: hue bridge request #37: get /lights
[2017-9-2 21:54:08] [Philips Hue] deCONZ-GW: hue bridge request #37: ok
[2017-9-2 21:54:08] [Philips Hue] Philips hue: hue bridge request #34: ok
[2017-9-2 21:54:08] [Philips Hue] Philips hue: hue bridge request #35: get /lights
[2017-9-2 21:54:08] [Philips Hue] Philips hue: hue bridge request #35: ok
[2017-9-2 21:54:08] [Harmony Hub Wohnzimmer] debug Refreshing current activity
[2017-9-2 21:54:09] [Philips Hue] Philips hue: hue bridge request #36: get /config
[2017-9-2 21:54:09] [Philips Hue] deCONZ-GW: hue bridge request #38: get /config
[2017-9-2 21:54:10] [Philips Hue] deCONZ-GW: hue bridge request #38: ok
[2017-9-2 21:54:10] [Philips Hue] deCONZ-GW: hue bridge request #39: get /sensors
[2017-9-2 21:54:10] [Philips Hue] Philips hue: hue bridge request #36: ok
[2017-9-2 21:54:10] [Philips Hue] Philips hue: hue bridge request #37: get /sensors
[2017-9-2 21:54:10] [Philips Hue] deCONZ-GW: hue bridge request #39: ok
[2017-9-2 21:54:10] [Philips Hue] deCONZ-GW: hue bridge request #40: get /lights
[2017-9-2 21:54:10] [Philips Hue] Philips hue: hue bridge request #37: ok
[2017-9-2 21:54:10] [Philips Hue] Philips hue: hue bridge request #38: get /lights
[2017-9-2 21:54:10] [Philips Hue] deCONZ-GW: hue bridge request #40: ok
[2017-9-2 21:54:10] [Philips Hue] Philips hue: hue bridge request #38: ok
[2017-9-2 21:54:11] [Philips Hue] Bewegungsmelder Küche: event: sensor lightlevel changed from 0 to 0 on 2017-09-02T19:54:11
[2017-9-2 21:54:11] [Philips Hue] Philips hue: hue bridge request #39: get /config
[2017-9-2 21:54:11] [Philips Hue] deCONZ-GW: hue bridge request #41: get /config
[2017-9-2 21:54:12] [Philips Hue] deCONZ-GW: hue bridge request #41: ok
[2017-9-2 21:54:12] [Philips Hue] deCONZ-GW: hue bridge request #42: get /sensors
[2017-9-2 21:54:12] [Philips Hue] Philips hue: hue bridge request #39: ok
[2017-9-2 21:54:12] [Philips Hue] Philips hue: hue bridge request #40: get /sensors
[2017-9-2 21:54:12] [Philips Hue] deCONZ-GW: hue bridge request #42: ok
[2017-9-2 21:54:12] [Philips Hue] deCONZ-GW: hue bridge request #43: get /lights
[2017-9-2 21:54:12] [Philips Hue] Philips hue: hue bridge request #40: ok
[2017-9-2 21:54:12] [Philips Hue] Philips hue: hue bridge request #41: get /lights
[2017-9-2 21:54:12] [Philips Hue] deCONZ-GW: hue bridge request #43: ok
[2017-9-2 21:54:12] [Philips Hue] Philips hue: hue bridge request #41: ok
[2017-9-2 21:54:13] [Philips Hue] Philips hue: hue bridge request #42: get /config
[2017-9-2 21:54:14] [Philips Hue] deCONZ-GW: hue bridge request #44: get /config
[2017-9-2 21:54:14] [Philips Hue] deCONZ-GW: hue bridge request #44: ok
[2017-9-2 21:54:14] [Philips Hue] deCONZ-GW: hue bridge request #45: get /sensors
[2017-9-2 21:54:14] [Philips Hue] Philips hue: hue bridge request #42: ok
[2017-9-2 21:54:14] [Philips Hue] Philips hue: hue bridge request #43: get /sensors
[2017-9-2 21:54:14] [Philips Hue] deCONZ-GW: hue bridge request #45: ok
[2017-9-2 21:54:14] [Philips Hue] deCONZ-GW: hue bridge request #46: get /lights
[2017-9-2 21:54:14] [Philips Hue] Philips hue: hue bridge request #43: ok
[2017-9-2 21:54:14] [Philips Hue] Philips hue: hue bridge request #44: get /lights
[2017-9-2 21:54:14] [Philips Hue] deCONZ-GW: hue bridge request #46: ok
[2017-9-2 21:54:14] [Philips Hue] Philips hue: hue bridge request #44: ok
[2017-9-2 21:54:16] [Philips Hue] Philips hue: hue bridge request #45: get /config
[2017-9-2 21:54:16] [Philips Hue] deCONZ-GW: hue bridge request #47: get /config
[2017-9-2 21:54:16] [Philips Hue] deCONZ-GW: hue bridge request #47: ok
[2017-9-2 21:54:16] [Philips Hue] deCONZ-GW: hue bridge request #48: get /sensors
[2017-9-2 21:54:16] [Philips Hue] Philips hue: hue bridge request #45: ok
[2017-9-2 21:54:16] [Philips Hue] Philips hue: hue bridge request #46: get /sensors
[2017-9-2 21:54:16] [Philips Hue] deCONZ-GW: hue bridge request #48: ok
[2017-9-2 21:54:16] [Philips Hue] deCONZ-GW: hue bridge request #49: get /lights
[2017-9-2 21:54:16] [Philips Hue] Philips hue: hue bridge request #46: ok
[2017-9-2 21:54:16] [Philips Hue] Philips hue: hue bridge request #47: get /lights
[2017-9-2 21:54:16] [Philips Hue] deCONZ-GW: hue bridge request #49: ok
[2017-9-2 21:54:16] [Philips Hue] Philips hue: hue bridge request #47: ok
[2017-9-2 21:54:17] [Philips Hue] Bewegungsmelder Küche: event: sensor presence changed from true to false on 2017-09-02T19:54:17
[2017-9-2 21:54:17] [Philips Hue] Bewegungsmelder Küche: set homekit motion from 1 to 0 on Sat Sep 02 2017 19:54:17
[2017-9-2 21:54:18] [Philips Hue] Philips hue: hue bridge request #48: get /config
[2017-9-2 21:54:18] [Philips Hue] deCONZ-GW: hue bridge request #50: get /config
[2017-9-2 21:54:18] [Philips Hue] deCONZ-GW: hue bridge request #50: ok
[2017-9-2 21:54:18] [Philips Hue] deCONZ-GW: hue bridge request #51: get /sensors
[2017-9-2 21:54:18] [Philips Hue] Philips hue: hue bridge request #48: ok
[2017-9-2 21:54:18] [Philips Hue] Philips hue: hue bridge request #49: get /sensors
[2017-9-2 21:54:18] [Philips Hue] deCONZ-GW: hue bridge request #51: ok
[2017-9-2 21:54:18] [Philips Hue] deCONZ-GW: hue bridge request #52: get /lights
[2017-9-2 21:54:18] [Philips Hue] deCONZ-GW: hue bridge request #52: ok
[2017-9-2 21:54:18] [Philips Hue] Philips hue: hue bridge request #49: ok
[2017-9-2 21:54:18] [Philips Hue] Philips hue: hue bridge request #50: get /lights
[2017-9-2 21:54:18] [Philips Hue] Philips hue: hue bridge request #50: ok
[2017-9-2 21:54:20] [Philips Hue] Philips hue: hue bridge request #51: get /config
[2017-9-2 21:54:20] [Philips Hue] deCONZ-GW: hue bridge request #53: get /config
[2017-9-2 21:54:20] [Philips Hue] deCONZ-GW: hue bridge request #53: ok
[2017-9-2 21:54:20] [Philips Hue] deCONZ-GW: hue bridge request #54: get /sensors
[2017-9-2 21:54:20] [Philips Hue] Philips hue: hue bridge request #51: ok
[2017-9-2 21:54:20] [Philips Hue] Philips hue: hue bridge request #52: get /sensors
[2017-9-2 21:54:20] [Philips Hue] deCONZ-GW: hue bridge request #54: ok
[2017-9-2 21:54:20] [Philips Hue] deCONZ-GW: hue bridge request #55: get /lights
[2017-9-2 21:54:20] [Philips Hue] Philips hue: hue bridge request #52: ok
[2017-9-2 21:54:20] [Philips Hue] Philips hue: hue bridge request #53: get /lights
[2017-9-2 21:54:20] [Philips Hue] deCONZ-GW: hue bridge request #55: ok
[2017-9-2 21:54:20] [Philips Hue] Philips hue: hue bridge request #53: ok
[2017-9-2 21:54:22] [Philips Hue] Philips hue: hue bridge request #54: get /config
[2017-9-2 21:54:22] [Philips Hue] deCONZ-GW: hue bridge request #56: get /config
[2017-9-2 21:54:22] [Philips Hue] deCONZ-GW: hue bridge request #56: ok
[2017-9-2 21:54:22] [Philips Hue] deCONZ-GW: hue bridge request #57: get /sensors
[2017-9-2 21:54:22] [Philips Hue] Philips hue: hue bridge request #54: ok
[2017-9-2 21:54:22] [Philips Hue] Philips hue: hue bridge request #55: get /sensors
[2017-9-2 21:54:22] [Philips Hue] deCONZ-GW: hue bridge request #57: ok
[2017-9-2 21:54:22] [Philips Hue] deCONZ-GW: hue bridge request #58: get /lights
[2017-9-2 21:54:22] [Philips Hue] deCONZ-GW: hue bridge request #58: ok
[2017-9-2 21:54:22] [Philips Hue] Philips hue: hue bridge request #55: ok
[2017-9-2 21:54:22] [Philips Hue] Philips hue: hue bridge request #56: get /lights
[2017-9-2 21:54:22] [Philips Hue] Philips hue: hue bridge request #56: ok
[2017-9-2 21:54:24] [Philips Hue] Philips hue: hue bridge request #57: get /config
[2017-9-2 21:54:24] [Philips Hue] deCONZ-GW: hue bridge request #59: get /config
[2017-9-2 21:54:24] [Philips Hue] deCONZ-GW: hue bridge request #59: ok
[2017-9-2 21:54:24] [Philips Hue] deCONZ-GW: hue bridge request #60: get /sensors
[2017-9-2 21:54:24] [Philips Hue] Philips hue: hue bridge request #57: ok
[2017-9-2 21:54:24] [Philips Hue] Philips hue: hue bridge request #58: get /sensors
[2017-9-2 21:54:24] [Philips Hue] deCONZ-GW: hue bridge request #60: ok
[2017-9-2 21:54:24] [Philips Hue] deCONZ-GW: hue bridge request #61: get /lights
[2017-9-2 21:54:24] [Philips Hue] Philips hue: hue bridge request #58: ok
[2017-9-2 21:54:24] [Philips Hue] Philips hue: hue bridge request #59: get /lights
[2017-9-2 21:54:24] [Philips Hue] deCONZ-GW: hue bridge request #61: ok
[2017-9-2 21:54:24] [Philips Hue] Philips hue: hue bridge request #59: ok
[2017-9-2 21:54:26] [Philips Hue] Bewegungsmelder Flur: event: sensor presence changed from true to false on 2017-09-02T19:54:26
[2017-9-2 21:54:26] [Philips Hue] Bewegungsmelder Flur: set homekit motion from 1 to 0 on Sat Sep 02 2017 19:54:26
[2017-9-2 21:54:26] [Philips Hue] Philips hue: hue bridge request #60: get /config
[2017-9-2 21:54:26] [Philips Hue] deCONZ-GW: hue bridge request #62: get /config
[2017-9-2 21:54:26] [Philips Hue] deCONZ-GW: hue bridge request #62: ok
[2017-9-2 21:54:26] [Philips Hue] deCONZ-GW: hue bridge request #63: get /sensors
[2017-9-2 21:54:26] [Philips Hue] Philips hue: hue bridge request #60: ok
[2017-9-2 21:54:26] [Philips Hue] Philips hue: hue bridge request #61: get /sensors
[2017-9-2 21:54:26] [Philips Hue] deCONZ-GW: hue bridge request #63: ok
[2017-9-2 21:54:26] [Philips Hue] deCONZ-GW: hue bridge request #64: get /lights
[2017-9-2 21:54:26] [Philips Hue] Philips hue: hue bridge request #61: ok
[2017-9-2 21:54:26] [Philips Hue] Philips hue: hue bridge request #62: get /lights
[2017-9-2 21:54:26] [Philips Hue] deCONZ-GW: hue bridge request #64: ok
[2017-9-2 21:54:26] [Philips Hue] Philips hue: hue bridge request #62: ok
[2017-9-2 21:54:28] [Philips Hue] Philips hue: hue bridge request #63: get /config
[2017-9-2 21:54:28] [Philips Hue] deCONZ-GW: hue bridge request #65: get /config
[2017-9-2 21:54:28] [Philips Hue] deCONZ-GW: hue bridge request #65: ok
[2017-9-2 21:54:28] [Philips Hue] deCONZ-GW: hue bridge request #66: get /sensors
[2017-9-2 21:54:28] [Philips Hue] Philips hue: hue bridge request #63: ok
[2017-9-2 21:54:28] [Philips Hue] Philips hue: hue bridge request #64: get /sensors
[2017-9-2 21:54:28] [Philips Hue] Philips hue: hue bridge request #64: ok
[2017-9-2 21:54:28] [Philips Hue] Philips hue: hue bridge request #65: get /lights
[2017-9-2 21:54:28] [Philips Hue] deCONZ-GW: hue bridge request #66: ok
[2017-9-2 21:54:28] [Philips Hue] deCONZ-GW: hue bridge request #67: get /lights
[2017-9-2 21:54:28] [Philips Hue] deCONZ-GW: hue bridge request #67: ok
[2017-9-2 21:54:28] [Philips Hue] Philips hue: hue bridge request #65: ok
[2017-9-2 21:54:28] [Harmony Hub Wohnzimmer] debug Refreshing current activity
[2017-9-2 21:54:30] [Philips Hue] Philips hue: hue bridge request #66: get /config
[2017-9-2 21:54:30] [Philips Hue] deCONZ-GW: hue bridge request #68: get /config
[2017-9-2 21:54:30] [Philips Hue] deCONZ-GW: hue bridge request #68: ok
[2017-9-2 21:54:30] [Philips Hue] deCONZ-GW: hue bridge request #69: get /sensors
[2017-9-2 21:54:30] [Philips Hue] Philips hue: hue bridge request #66: ok
[2017-9-2 21:54:30] [Philips Hue] Philips hue: hue bridge request #67: get /sensors
[2017-9-2 21:54:30] [Philips Hue] deCONZ-GW: hue bridge request #69: ok
[2017-9-2 21:54:30] [Philips Hue] deCONZ-GW: hue bridge request #70: get /lights
[2017-9-2 21:54:30] [Philips Hue] Philips hue: hue bridge request #67: ok
[2017-9-2 21:54:30] [Philips Hue] Philips hue: hue bridge request #68: get /lights
[2017-9-2 21:54:30] [Philips Hue] deCONZ-GW: hue bridge request #70: ok
[2017-9-2 21:54:30] [Philips Hue] Philips hue: hue bridge request #68: ok
[2017-9-2 21:54:32] [Philips Hue] Philips hue: hue bridge request #69: get /config
[2017-9-2 21:54:32] [Philips Hue] deCONZ-GW: hue bridge request #71: get /config
[2017-9-2 21:54:32] [Philips Hue] deCONZ-GW: hue bridge request #71: ok
[2017-9-2 21:54:32] [Philips Hue] deCONZ-GW: hue bridge request #72: get /sensors
[2017-9-2 21:54:32] [Philips Hue] Philips hue: hue bridge request #69: ok
[2017-9-2 21:54:32] [Philips Hue] Philips hue: hue bridge request #70: get /sensors
[2017-9-2 21:54:32] [Philips Hue] deCONZ-GW: hue bridge request #72: ok
[2017-9-2 21:54:32] [Philips Hue] deCONZ-GW: hue bridge request #73: get /lights
[2017-9-2 21:54:32] [Philips Hue] Philips hue: hue bridge request #70: ok
[2017-9-2 21:54:32] [Philips Hue] Philips hue: hue bridge request #71: get /lights
[2017-9-2 21:54:32] [Philips Hue] deCONZ-GW: hue bridge request #73: ok
[2017-9-2 21:54:32] [Philips Hue] Philips hue: hue bridge request #71: ok
[2017-9-2 21:54:34] [Philips Hue] Philips hue: hue bridge request #72: get /config
[2017-9-2 21:54:34] [Philips Hue] deCONZ-GW: hue bridge request #74: get /config
[2017-9-2 21:54:34] [Philips Hue] deCONZ-GW: hue bridge request #74: ok
[2017-9-2 21:54:34] [Philips Hue] deCONZ-GW: hue bridge request #75: get /sensors
[2017-9-2 21:54:34] [Philips Hue] Philips hue: hue bridge request #72: ok
[2017-9-2 21:54:34] [Philips Hue] Philips hue: hue bridge request #73: get /sensors
[2017-9-2 21:54:34] [Philips Hue] deCONZ-GW: hue bridge request #75: ok
[2017-9-2 21:54:34] [Philips Hue] deCONZ-GW: hue bridge request #76: get /lights
[2017-9-2 21:54:34] [Philips Hue] Philips hue: hue bridge request #73: ok

Should be fixed in v0.5.27.

Yes. Perfect! Thank you.


chore: remove unnecessary role grant from GKE terraform example

Problem Statement
roles/iam.workloadIdentityUser already grants access to Kubernetes Service Account. Thus makes serviceAccountTokenCreator redundant? Unless I'm missing something, this role doesn't do anything.
Related Issue
Fixes #...
Proposed Changes
How do you like to solve the issue and why?
Checklist

[x] I have read the contribution guidelines
[x] All commits are signed with git commit --signoff
[ ] My changes have reasonable test coverage
[ ] All tests pass with make test
[ ] I ensured my PR is ready for review with make reviewable

Do you have any runs showing that that cred is truly unrequired? I'm not sure. I'm sure it was added for a reason. :) I'll check it out when I'm at a comp.

IIRC eso uses the gcp oauth2 endpoint to impersonate a k8s service account (workload identity of a different sa)

Yeah but we have only 1 google service account and we're granting roles/iam.serviceAccountTokenCreator on it. There is no other google service account we're impersonating here.
Here is a complete example that I used to bootstrap my argocd installation.
variable "project_id" {
  type        = string
  description = "Google Cloud Project ID"
}

# Create a secret in Secret Manager
# Assuming someone else will put the actual secret value in the secret
resource "google_secret_manager_secret" "argocd" {
  secret_id = "argocd"
  replication {
    auto {}
  }
}

# Create a Google Service Account to access the secret
resource "google_service_account" "external_secrets_argocd" {
  account_id = "external-secrets-argocd"
}

# Grant the Google Service Account secretmanager.secretAccessor role
# so it can access the secret
resource "google_secret_manager_secret_iam_member" "external_secrets_argocd_secret_accessor" {
  secret_id = google_secret_manager_secret.argocd.secret_id
  role      = "roles/secretmanager.secretAccessor"
  member    = google_service_account.external_secrets_argocd.member
}

# Grant the Kubernetes service account 'external-secrets-argocd' in the 'argocd' namespace
# iam.workloadIdentityUser role on the Google Service Account associated with accessing the secret
resource "google_service_account_iam_member" "external_secrets_argocd_workload_identity_user" {
  service_account_id = google_service_account.external_secrets_argocd.name
  role               = "roles/iam.workloadIdentityUser"
  # This Google Service Account doesn't exist, but provided by GKE workload identity platform.
  member = "serviceAccount:${var.project_id}.svc.id.goog[argocd/external-secrets-argocd]"
}

resource "kubernetes_service_account_v1" "external_secrets_argocd" {
  metadata {
    name      = "external-secrets-argocd"
    namespace = "argocd"
    annotations = {
      # This annotation should contain the email of the Google Service Account
      # to which the Workload Identity User role is granted
      "iam.gke.io/gcp-service-account" : google_service_account.external_secrets_argocd.email
    }
  }
}

# This syntax could be wrong, I converted it from the plain yaml
resource "kubernetes_manifest" "secret_store_argocd" {
  manifest = {
    apiVersion = "external-secrets.io/v1beta1"
    kind       = "SecretStore"
    metadata = {
      name      = "argocd"
      namespace = "argocd"
    }
    spec = {
      provider = {
        gcpsm = {
          projectID = "<PROJECT_ID>"
          auth = {
            workloadIdentity = {
              clusterLocation  = "us-central1"
              clusterName      = "my-cluster"
              clusterProjectID = "<PROJECT_ID>"
              serviceAccountRef = {
                # This should match the name of the Kubernetes service account
                name = "external-secrets-argocd"
              }
            }
          }
        }
      }
    }
  }
}

resource "kubernetes_manifest" "external_secret_argocd" {
  manifest = {
    apiVersion = "external-secrets.io/v1beta1"
    kind       = "ExternalSecret"
    metadata = {
      name      = "argocd"
      namespace = "argocd"
    }
    spec = {
      secretStoreRef = {
        kind = "SecretStore"
        name = "argocd"
      }
      dataFrom = [{
        extract = {
          key     = "argocd"
          version = "latest"
        }
      }]
    }
  }
}

One thing that I didn't fully understand is how ESO is able to assume the identity of different Kubernetes Service Accounts. I always thought KSA is tied to specific pods. But EKS docs explains it a bit. I guess GKE does similar thing.
But, at any point I don't see how serviceAccountTokenCreator is being used here. Please correct me if I'm wrong.

Maybe a bit more context: we use the terraform code to set up our e2e tests. We test integration with workload identity. Specifically we test two cases:

Eso runs with a workload identity attached to the sa ESO runs with
ESO impersonates a different Kubernetes SA and leverages its workload identity

There is a big difference with these two approaches:
The first exchanges a token with the GKE metadata server using the mounted Kubernetes SA. Afaik the Metadata verifies the source IP of the requestor to prevent identity theft.
The latter approach does not go through metadata server, instead it talks directly to the oauth2 endpoint (that, that the gke metadata server would do on behalf).
So, even if there is just one GCP SA, there are different ways to acquire a oauth2 token.
See: https://github.com/external-secrets/external-secrets/blob/main/e2e/suites/provider/cases/gcp/gcp_managed.go

Right, thanks for the explanation.

ESO impersonates a different Kubernetes SA and leverages its workload identity

I think my previous example falls under the second authentication method as you described.
In this case, if roles/iam.serviceAccountTokenCreator is required, how it's working for me only using the roles/iam.workloadIdentityUser role? I guess I got lucky since their permissions overlapped quite a bit.
roles/iam.workloadIdentityUser
4 assigned permissions
iam.serviceAccounts.get
iam.serviceAccounts.getAccessToken
iam.serviceAccounts.getOpenIdToken
iam.serviceAccounts.list
roles/iam.serviceAccountTokenCreator
9 assigned permissions
iam.serviceAccounts.get
iam.serviceAccounts.getAccessToken
iam.serviceAccounts.getOpenIdToken
iam.serviceAccounts.implicitDelegation
iam.serviceAccounts.list
iam.serviceAccounts.signBlob
iam.serviceAccounts.signJwt
resourcemanager.projects.get
resourcemanager.projects.list

Could be that it's unnecessary i'd be happy to remove it if that's the case.
Lets try this: let me run the e2e tests, merge this PR and open another PR to verify that the change does not have an impact on the e2e tests (it tests them from the main branch).
Then you don't need to get into the nitty gritty details of our e2e tests and i don't have to take the time to manually test this PR :)


replay: extend last fec set check for 32+ retransmitter signed shreds

Problem
When the feature flag is turned on, we need to verify that the last fec set uses the new shred format.
Because the last fec set is not known when receiving shreds, and the new shred format is only used for the last set, we cannot perform this check until replay has completed.
Summary of Changes
Extend the check which compares the merkle roots of the last fec set to additionally check that they are all of the retransmitter shred variant.

Do we already observe this in the metrics?
Wondering how much load this is adding to the metrics server.

Just to confirm, this is not currently spamming metrics server because last FEC set is already 32+ data shreds on mainnet, right?

The replay check that introduced this metric:
https://github.com/anza-xyz/agave/pull/1410
was never approved for backport to 1.18 so it is not observed on mainnet apart from master canaries.
On testnet however we do observe it quite frequently:

It seems that something is wrong with the check. I will investigate it and get back to you.

False alarm, I checked the block producer for blocks that have been failing the check on testnet today and they are all running firedancer:
3Rdnk6ZSGbPbwGiSEDkTs12oK5VcX8YWuQPaYtqcnYW6
4qrtRWHiJm4YCTsGmdWThngntekKZXrF9nGHJCEoRTrC
5qzgRKGnpZs27aqR3tkZp2HJ8ZXoxTBjYoayqVG1QKbs
ARhax8ZwKr4xTkRB4HcU5ncWtGoVXCbCa2x98QhTpihw
F1REirtRdV1famCks1tLZ8ZpxKWxPzT8Ky7d19cA1K1N
Hwvxg5dacM8SbpwPDiZyxNNLpAid9v7BQZDef1Fhug2P
jfireruobS6UzNLqixjraT4URA73fSj4cWYankBsQpV
puMPKindCwo2b279wFUTHZbR3CncfEWX5ySk2ibqQ3U

It seems that FD is not padding the last fec set, so this is to be expected.


How can I submit only form elements?

I have a form page and I use it for both create and update
My form fields are like this;
myForm: {
name: (...)
email: (...)
password: (...)
}
I can successfully submit a request.
When we come to the update process, I get the data in this way (this.myForm = response.data)
When I send an update request I just want the form fields to go but it goes like this
myForm: {
name: (...)
email: (...)
password: (...)
createdAt: (...)
updatedAt: (...)
_id: (...)
}
I don't want to send createdAt, updatedAt, _id fields
How can I submit only form fields in Element-ui? (I am using Vue.js)
Is there something like this.$refs.myForm.fields or this.$refs.myForm.values I couldn't find it

Maybe find your target...

Maybe find your target...

I guess it doesn't work well or I couldn't find it


update graphql-subscriptions to the latest version 🚀

this package uses the oldest graphql-subscriptions package(0.5.x). but the latest version is 1.1.x.

there is a related pull request(#18) with this issue.


[FLINK-16821][e2e] Use constant minikube version instead of latest

What is the purpose of the change
The Kubernetes e2e test suddenly started failing.
The cause was that there's a new minikube version, which has a changed behavior.
Brief change log

Use a fixed minikube version instead of latest

Thanks a lot for your review.
Actually, the latest stable version is v.1.9.0.
I will wait until all K8s related tests have passed and then merge this PR!

Yes, i believe 1.8.2 is more stable. Since the v1.9.0 is just released, we may have risks when using it. I agree with you to set the version to 1.8.2.


feat: adds IP address configuration for default bridge network

Adds an option in nerdctl.toml to configure the the default bridge network IP
Fixes: https://github.com/containerd/nerdctl/issues/3625

Docker CI failure: #3652

Just for note, I'm not sure if --bridge-ip is equal with bip in Docker daemon or not. If two flag is equal, I think we need change the network create behavior at the same time.

Can you please elaborate? I don't think network create has a --bridge-ip  option. You provide --subnet, --ip-range and --gateway. bip is defined in the daemon level.

This option in docker will have an implicit behavior, it will change the network start range. For example, for the the same command docker network create abc. The abc IP range will be <IP_ADDRESS>/24(for example) and will be <IP_ADDRESS>/24 if we set the bip to <IP_ADDRESS>/24

I could not reproduce this behavior in my local testing:
% sudo cat /etc/docker/daemon.json
{
  "bip": "<IP_ADDRESS>/24",
  "data-root": "/local/docker",
  "dns": ["<IP_ADDRESS>"]
}

dev-dsk-sbora-2c-4ee7e306 % docker network inspect bridge | jq '.[0].IPAM.Config'
[
  {
    "Subnet": "<IP_ADDRESS>/24",
    "Gateway": "<IP_ADDRESS>"
  }
]

% docker network create -d bridge test-net
10e34d98783d9562f27f4248f970745d53357e9fd2d0c0488422258c2243a586

% docker network inspect test-net | jq '.[0].IPAM.Config'
[
  {
    "Subnet": "<IP_ADDRESS>/16",
    "Gateway": "<IP_ADDRESS>"
  }
]

For new bridge network (without a subnet range specified), docker still picks the 172.18/16 range. I found these ranges are defined here https://github.com/moby/moby/blob/master/libnetwork/ipamutils/utils.go#L12-L25, so this is still from a predefined range of non-conflicting network ranges and not implicitly set from bip

}
]

For new bridge network (without a subnet range specified), docker still picks the 172.18/16 range. I found these ranges are defined here https://github.com/moby/moby/blob/master/libnetwork/ipamutils/utils.go#L12-L25, so this is still from a predefined range of non-conflicting network ranges and not implicitly set from bip.
Docker actually provides a daemon level option default-address-pools to specify custom network ranges for user defined networks. But that can be a follow up feature if needed, since have the option to pass --subnet with network create to do exactly that.

You are right. I mix bip and default-address-pools together


Standardize on widget instead of element as way of accessing underlying widget

Also change class Element to class Widget to be consistent with Tkinter lingo


STORM-3090 - Fix bug when different topics use the same offset for a partition

This pull request contains the same changes from https://github.com/apache/storm/pull/2726 that was merged in 1.x branch. As there are some conflicts during cherry-picking of these changes into 1.0.x/1.1.x branch this pull request is created for 1.0.x branch.

Could you please point this to at least 1.1.x-branch? We are trying to maintain 3 version lines and due to this, 1.0.x version is no longer supported.

base branch is changed to 1.1.x-branch. Am i understand correctly that the last release version of 1.0.x-branch was 1.0.6 and newer version will never be released?

+1
Yes, likely. There's no reason people can't just upgrade to 1.1.x/1.2.x instead, and it's adding a bunch of work for us to have to keep backporting to old branches.

Thanks @choojoyq, merged.


updated vpc volume lib for volume expansion error message

Coverage remained the same at 85.846% when pulling cd3590717ae5aec6eeefdf6c70d1ca83dbc9827d on exp into a211fbccd61431d6126984687c6861ff7a7d16b9 on master.

/lgtm


[LYFT] [STRM-1433] Support setting the worker command (with virtualenv) via environment variable.

Please add a meaningful description for your change here

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.
Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---
---

There will be a corresponding change in the deployment to provide the environment variable. It will be something like service_venv python -m apache_beam.runners.worker.sdk_worker_main

👍


Remove brackets from ttrigger placeholder

who wants to create a trigger without brackets?

I actually did that because intellisense would add it automatically - but now you can just type as well .. works better indeed!
Thanks!


Remove UMD builds

It doesn't appear the UMD builds are working correctly, they take a long time to build, and with hosted es module solutions it seems less beneficial to include. Both common js and es module options are included and this covers the majority of use-cases. This can always be revisited in the future.

This was completed in #111.


Enhancement to ESP_GETMOUSE

Add byte to end of ESP_GETMOUSE data with mouse wheel delta value.
ESP_GETMOUSE sends the result before the mouse data, so existing code should still work without error.

Implemented.


Update focus-trap.ts

Conditionally calls define of the attribute.
We have a case where we load weightless into lit elements and then using them in an angular project, when loading different elements using weightless this library causes a conflict by trying to define the same custom element more than once

Any chance this could get merged @andreasbm?