Time Out when creating a docker host on Digital Ocean, command never returns

Hi, I have installed Docker Toolbox 1.8.1b  (machine 0.4.1) on Mac OS X (10.10.4) and launched a shell using Docker Quickstart Terminal.
I launched a VM on Digital Ocean with the following command (where $DO_TOKEN is my auth token for Digital Ocean)
docker-machine -D create --driver digitalocean --digitalocean-access-token  $DO_TOKEN  --digitalocean-region "sgp1"  staging

The VM is created on Digital Ocean but the command above never return.
The output on the terminal eventually is a non-stopping repeat of this:
Daemon not responding yet: dial tcp <IP_ADDRESS>:2376: operation timed out
Daemon not responding yet: dial tcp <IP_ADDRESS>:2376: operation timed out
Daemon not responding yet: dial tcp <IP_ADDRESS>:2376: operation timed out

After Ctrl-C the process, running docker-machine -D env staging also fails to return and shows the same output as above.
No such errors when working with a local Virtualbox host.

Same issue. Finally gives up with Error creating machine: Maximum number of retries (60) exceeded

Also having this issue. Maybe the Digital Ocean API has changed and docker-machine has not updated?

Actually I found my problem. There isn't a command line flag to choose an SSH key when spinning up the instance. The output could definitely be more informative here.

Hm, it should be automatically created for you.

@nathanleclaire I now see the new ssh key in the DigitalOcean UI but was still getting that message with the command line tool.

These days "digitalocean create droplet forever" is a hot topic on the Internets. Is there a way to wait longer without the Maximum number of retries (60) exceeded error raised?

Hi!
I have also the same issue.
Could it be really so, that the Droplet is not yet ready...

Hi all, this is not an uncommon issue (I just ran into it yesterday), however it is a little bit tricky to solve since an "irreconcilable" failure (such as the network dropping and never coming back up during create) could potentially be difficult to distinguish from the type of failure where nothing is actually wrong (and consequently the droplet is just taking a long time to boot).  The "easy" / hacky fix is to just kick the timeout up to ~12-15 minutes.
For first steps I think introducing a docker-machine provision command will at least allow users to salvage instances that have timed out at this stage (since provisioning is the remaining step after this one).  In the future, maybe the running detection could evolve to be a bit more robust.

I observed this when trying to create 7 instances, and it got stuck on the 7th.

This is still happening for me with docker-machine version 0.5.1 and Docker version 1.9.1 build a34a1d5
When sshing into the VM I see that the Docker service is indeed running. Not sure why I'm getting these messages:
$ docker-machine env deploy
Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "<IP_ADDRESS>:2376": dial tcp <IP_ADDRESS>:2376: getsockopt: connection refused
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

$ docker-machine regenerate-certs deploy
Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Detecting the provisioner...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Unable to verify the Docker daemon is listening: Maximum number of retries (5) exceeded

@dalanmiller Can you paste the contents of sudo journalctl -u docker.service on the b0rked instance please?

@nathanleclaire
-- Logs begin at Wed 2015-12-16 15:31:33 EST, end at Wed 2015-12-16 15:33:31 EST. -
Dec 16 15:32:23 deploy2 systemd[1]: Starting Docker Application Container Engine...
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.688647577-05:00" le
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.716067093-05:00" le
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.751397872-05:00" le
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.797639095-05:00" le
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.838325116-05:00" le
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.838912190-05:00" le
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.839213448-05:00" le
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.839461804-05:00" le
Dec 16 15:32:23 deploy2 systemd[1]: Started Docker Application Container Engine.
Dec 16 15:32:24 deploy2 docker[2955]: time="2015-12-16T15:32:24.344669084-05:00" le
Dec 16 15:32:24 deploy2 docker[2955]: time="2015-12-16T15:32:24.868008134-05:00" le
Dec 16 15:32:26 deploy2 docker[2955]: time="2015-12-16T15:32:26.513427887-05:00" le
Dec 16 15:32:26 deploy2 systemd[1]: Stopping Docker Application Container Engine...
Dec 16 15:32:26 deploy2 systemd[1]: Stopped Docker Application Container Engine.
Dec 16 15:32:26 deploy2 systemd[1]: Stopped Docker Application Container Engine.
Dec 16 15:32:29 deploy2 systemd[1]: Starting Docker Application Container Engine...
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.123393174-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.126298877-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.130452083-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.147155455-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.168464558-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.209968920-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.210490245-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.210843859-05:00" le
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.211118952-05:00" le
Dec 16 15:32:29 deploy2 systemd[1]: Started Docker Application Container Engine.

@dalanmiller I can't see the actual log messages, can you post the full contents please? docker-machine ssh deploy journalctl --no-pager -u docker.service will spit them out to local terminal (and can be piped to pbcopy if on a Mac).

-- Logs begin at Wed 2015-12-16 15:31:33 EST, end at Wed 2015-12-16 16:02:10 EST. --
Dec 16 15:32:23 deploy2 systemd[1]: Starting Docker Application Container Engine...
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.688647577-05:00" level=info msg="API listen on /var/run/docker.sock"
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.716067093-05:00" level=info msg="Firewalld running: false"
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.751397872-05:00" level=info msg="Default bridge (docker0) is assigned with an IP address <IP_ADDRESS>/16. Daemon option --bip can be used to set a preferred IP address"
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.797639095-05:00" level=warning msg="Your kernel does not support swap memory limit."
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.838325116-05:00" level=info msg="Loading containers: start."
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.838912190-05:00" level=info msg="Loading containers: done."
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.839213448-05:00" level=info msg="Daemon has completed initialization"
Dec 16 15:32:23 deploy2 docker[2955]: time="2015-12-16T15:32:23.839461804-05:00" level=info msg="Docker daemon" commit=a34a1d5 execdriver=native-0.2 graphdriver=aufs version=1.9.1
Dec 16 15:32:23 deploy2 systemd[1]: Started Docker Application Container Engine.
Dec 16 15:32:24 deploy2 docker[2955]: time="2015-12-16T15:32:24.344669084-05:00" level=info msg="GET /v1.21/version"
Dec 16 15:32:24 deploy2 docker[2955]: time="2015-12-16T15:32:24.868008134-05:00" level=info msg="GET /v1.21/version"
Dec 16 15:32:26 deploy2 docker[2955]: time="2015-12-16T15:32:26.513427887-05:00" level=info msg="Processing signal 'terminated'"
Dec 16 15:32:26 deploy2 systemd[1]: Stopping Docker Application Container Engine...
Dec 16 15:32:26 deploy2 systemd[1]: Stopped Docker Application Container Engine.
Dec 16 15:32:26 deploy2 systemd[1]: Stopped Docker Application Container Engine.
Dec 16 15:32:29 deploy2 systemd[1]: Starting Docker Application Container Engine...
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.123393174-05:00" level=info msg="API listen on /var/run/docker.sock"
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.126298877-05:00" level=info msg="[graphdriver] using prior storage driver \"aufs\""
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.130452083-05:00" level=info msg="Firewalld running: false"
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.147155455-05:00" level=info msg="Default bridge (docker0) is assigned with an IP address <IP_ADDRESS>/16. Daemon option --bip can be used to set a preferred IP address"
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.168464558-05:00" level=warning msg="Your kernel does not support swap memory limit."
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.209968920-05:00" level=info msg="Loading containers: start."
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.210490245-05:00" level=info msg="Loading containers: done."
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.210843859-05:00" level=info msg="Daemon has completed initialization"
Dec 16 15:32:29 deploy2 docker[3369]: time="2015-12-16T15:32:29.211118952-05:00" level=info msg="Docker daemon" commit=a34a1d5 execdriver=native-0.2 graphdriver=aufs version=1.9.1
Dec 16 15:32:29 deploy2 systemd[1]: Started Docker Application Container Engine.
Dec 16 15:55:40 deploy2 docker[3369]: time="2015-12-16T15:55:40.043284947-05:00" level=info msg="GET /v1.21/version"
Dec 16 15:55:41 deploy2 docker[3369]: time="2015-12-16T15:55:41.271048135-05:00" level=info msg="Processing signal 'terminated'"
Dec 16 15:55:41 deploy2 systemd[1]: Stopping Docker Application Container Engine...
Dec 16 15:55:41 deploy2 systemd[1]: Stopped Docker Application Container Engine.
Dec 16 15:55:41 deploy2 systemd[1]: Stopped Docker Application Container Engine.
Dec 16 15:55:43 deploy2 systemd[1]: Starting Docker Application Container Engine...
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.852192395-05:00" level=info msg="API listen on /var/run/docker.sock"
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.855028160-05:00" level=info msg="[graphdriver] using prior storage driver \"aufs\""
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.858967136-05:00" level=info msg="Firewalld running: false"
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.875899404-05:00" level=info msg="Default bridge (docker0) is assigned with an IP address <IP_ADDRESS>/16. Daemon option --bip can be used to set a preferred IP address"
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.897409458-05:00" level=warning msg="Your kernel does not support swap memory limit."
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.935850869-05:00" level=info msg="Loading containers: start."
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.936387084-05:00" level=info msg="Loading containers: done."
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.936652185-05:00" level=info msg="Daemon has completed initialization"
Dec 16 15:55:43 deploy2 docker[4128]: time="2015-12-16T15:55:43.936910211-05:00" level=info msg="Docker daemon" commit=a34a1d5 execdriver=native-0.2 graphdriver=aufs version=1.9.1
Dec 16 15:55:43 deploy2 systemd[1]: Started Docker Application Container Engine.

Looking at /lib/systemd/system/docker.service:
root@deploy2:~# cat /lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
Type=notify
ExecStart=/usr/bin/docker daemon -H fd://
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

Shouldn't the -H have something like <IP_ADDRESS>:2376 ?

Actually reading this StackOverflow post pointed me to /lib/systemd/system/docker.socket:
root@deploy2:~# cat /lib/systemd/system/docker.socket
[Unit]
Description=Docker Socket for the API
PartOf=docker.service

[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

I think the ListenStream might need to be 2375 versus the internal socket?

Just started a new docker-machine instance on DO and it works fine this time with Ubuntu 14.04. I'm assuming this is something related to systemd. The OP of this issue @rija probably had this issue because the default image is Ubuntu 15.04:
$ docker-machine create deploy3 \
--driver digitalocean \
--digitalocean-access-token TOKEN \
--digitalocean-image "ubuntu-14-04-x64" \
--digitalocean-size "1GB" \
--digitalocean-region sfo1
Running pre-create checks...
Creating machine...
(deploy3) OUT | Creating SSH key...
(deploy3) OUT | Creating Digital Ocean droplet...
(deploy3) OUT | Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: docker-machine env deploy3

Try Machine 0.5.3 to see if it helps.  There have been some changes with Ubuntu / systemd related provisioning lately.
The actual file used for the daemon startup (which Machine uses today) is at /etc/systemd/system/docker.service.  I'm not sure the reason for the disconnect.  Maybe docker-engine package installs that other file, but the file that actually gets used is at /etc/systemd/system/docker.service.

I'm having the same trouble today, only it gives up after 10 attempts.

On my side, I encountered a timeout after stopping a DigitalOcean VM:
> docker-machine ls
NAME        ACTIVE   DRIVER         STATE     URL                         SWARM   DOCKER    ERRORS
digital-2   -        digitalocean   Running   tcp://45.55.xxx.xxx:2376             v1.10.3

> docker-machine stop digital-2

> docker-machine ls
NAME        ACTIVE   DRIVER         STATE     URL                         SWARM   DOCKER    ERRORS
digital-2            digitalocean   Timeout

However, the status command returns the correct state: Stopped.

Any updates on this? I am seeing similar issues during create but also during ls: With the default timeout of 10 docker-machine ls will sometimes show digitalocean machines with a Timeout State. Calling docker-machine ls -t 20 seems to fix the problem.
But create is not where this is a problem, its far more annoying when one needs to reprovision an instance because it did timeout the first time. I guess a timeout flag for the create command would already help a lot here :+1:


Istio auth should report certificate identity to mixer

When Istio auth is enabled, Istio proxy should extract peer identity from certificates and forward the identity to Mixer.

https://github.com/istio/proxy/commit/9d10adc1099769ed2097d91314fa8089393f9210, server side is already done, but client-side filter is not supported by envoy yet.


v1.15.0 breaks cache clearing

Q
A

Bug?
yes

New Feature?
no

Version
1.15.0

PHP Version: 7.3.3
Symfony Version: 4.2.4
Actual Behavior
What is the actual behavior?
composer update installed 1.15.0 whereas 1.14.0 was there before, then red error message of
Warning: file_get_contents(/var/www/current/vendor/php-http/httplug-bundle/Resources/views/webprofiler.html.twig): failed to open stream: No such file or directory

This is caused by changes in 1.15.0, proved by downgrading again to 1.14.0
Expected Behavior
What is the behavior you expect?
Cache clears with no errors, like it does with 1.14.0
Steps to Reproduce

that file does exist in 1.15.0 https://github.com/php-http/HttplugBundle/tree/1.15.0/src/Resources/views
i also checked the .zip and .tar.gz files. can you check if the file really is not there in the filesystem or if somehow your system did not pick it up.
the path to the file looks odd, i'd expected a src somewhere there. we moved files into src/ and test/ between 1.14 and 1.15. can you try deleting var/cache right before running the composer update? maybe something is confused with that?

Before a composer update (1.14.0 installed)

running composer update (note there is no src in the path!):

seems like symfony flex is not correctly clearing the cache after composer update...
if I then manually clear the symfony cache (with the symfon cache:clear command) everything is fine...
I dont think this is a httplug issue after all... I'll debug further and raise an issue upstream.

yep, looks like. glad if you can find out where it needs to be fix, i think this has hit me in the past too...

@PhilETaylor is there anything you found out? Any related issues?

I was unable to get to the bottom of this, sorry.

@robob4him i think the issue really is that symfony or flex chokes up when directories move on such an update when the templates were already cached. if you want to follow up on it, please open an issue at symfony/flex or symfony/symfony as its not a bug of httplug.


Vimeo videos don't work on mobile

I am using react-player to render videos on my app, and vimeo videos sometimes won't work on mobile devices. I didn't have any issues with youtube videos or vimeo videos on desktop, but on mobile if I keep refreshing the page, sometimes it works just fine and sometimes it doesn't. I have no console errors when the video doesn't work, so I have no idea what might be the issue.
This is what I have for my react player:
          <ReactPlayer
            config={{ vimeo: { preload: true } }}
            url="https://vimeo.com/76979871" // random video url that sometimes does't work as well
            width="100%"
            height="100%"
            controls
          />

And this is what I got when the video doesn't work:

I tried with multiple vimeo videos, and they all have this behavior. I got this happening on my android device (chrome) and on an iphone device (safari) as well. I can also reproduce this on responsive design mode on safari desktop
Have anyone gone through this before? I found some issues about this, but they all had errors showing up, which I don't.

This might be more suited for https://github.com/vimeo/player.js/issues
I can't reproduce this issue myself. Is there something specific about your implementation that might be causing this?


mozjpeg bin source offline

Our source for mozjpeg binaries is offline:
https://github.com/lukesampson/scoop/blob/f4af32ad460e00a8af98915468456582d39fa47a/bucket/mozjpeg.json#L20-L23
$ curl mozjpeg.codelove.de
curl: (7) Failed to connect to mozjpeg.codelove.de port 80: Connection refused

We'll need to find a new binary source and/or consider adding it to binary-mirror.

Why don't we simply use "checkver": "github"?

Was able to compile it, but I don't know if the result matches anything from mozjpeg_3.1_x86.zip. Maybe I can provide builds via AppVeyor or something. But C and C++ are definitely not my thing 😁

What about this? :)
https://github.com/garyzyg/mozjpeg-windows


feat(User): add .weappLogin() and #linkWithWeapp()

Current coverage is 65.57% (diff: 44.44%)

No coverage report found for next at 95dce0d.

Powered by Codecov. Last update 95dce0d...379f81a


Default image used in PipelinedSpriteBundle to be able to render without loading a texture

Objective

Fix #3188
Allow creating a PipelinedSpriteBundle without an image, just a plain color

PipelinedSpriteBundle {
    sprite: Sprite {
        color: Color::rgba(0.8, 0.0, 0.0, 0.3),
        custom_size: Some(Vec2::new(500.0, 500.0)),
        ..Default::default()
    },
    ..Default::default()
}

Solution

The default impl for Image was creating a one pixel image with all values at 1. I changed it to 255 as picking 1 for it doesn't really make sense, it should be either 0 or 255
I created a static handle and added the default image to the assets with this handle
I changed the default impl for PipelinedSpriteBundle to use this handle

Good call. Love that this is a simple solution without any changes to the pipeline!

bors r+


Update Go version to 1.22.1

This PR updates Go version to 1.22.1 to resolve a few vulnerabilities.
This PR also updates google.golang.org/protobuf to 1.33.0 for the same purpose.

@michaelkedar I know we don't routinely build the ci Docker image because it takes a while, but would it be feasible to automatically build it only when content under https://github.com/google/osv.dev/tree/master/docker/ci changes? Otherwise there's the risk of us failing to do that step and our testing environment diverges from our runtime environment.

@michaelkedar I know we don't routinely build the ci Docker image because it takes a while, but would it be feasible to automatically build it only when content under https://github.com/google/osv.dev/tree/master/docker/ci changes? Otherwise there's the risk of us failing to do that step and our testing environment diverges from our runtime environment.

We could have a job that builds and pushes the ci image when it changes.
The thing I don't know is how the order of operations would work.
I think we'd want something like:
On PR:

If ci image changes -> rebuild and temporarily tag it for PR -> use new image to run tests.
Otherwise, use existing ci image to run tests

Then on merge:

If ci image had changed -> rebuild or re-label PR image to 'latest' -> use that to run tests.
Otherwise, continue using existing ci image

But I don't really have an idea on how possible/feasible this kind of workflow is in Cloud Build.


Better slot syntax with v-slot and v-fallback

What problem does this feature solve?
I want to write a component that wraps or doesn't wrap one piece of HTML using another piece of HTML depending on a condition supplied by a prop. Usage would look like this:
<my-conditional-wrap-component :condition="is_selected">

        content

        <v-slot />

</my-conditional-wrap-component>

It would render as either (in case is_selected is true) this:

 content

or (in case is_selected is false) this:

 content

As far as I know with current <slot> syntax this is impossible because the children of <slot> are used as a fallback. (Which, if I understand the rationale correctly, is done to be consistent with web-components' slots. Unfortunately it's also inconsistent with Vue's components, whose children are used as content for their slots.)
With <v-slot> the component's source would look like this:
<template id="my-conditional-wrap-component-template">
    <template v-if="condition">
        <v-slot name="wrapper">
            <v-slot name="content" />
        </v-slot>
    </template>
    <template v-else>
        <v-slot name="content" />
    </template>
</template>

What does the proposed API look like?
The proposed API is the same as the current API for <slot>, with two differences:

Currently <slot>'s children are used as a fallback. <v-slot>'s children will be used to fill nested slots instead, as if the piece of HTML inserted in place of ` was a component with it's own slots.
v-fallback directive will be used similar to v-else to provide a fallback instead of <slot>'s children.

Component:
<template id="my-component">
    <v-slot name="first">
        <v-slot name="second">

 Hello world!

        </v-slot>
    </v-slot>
</template>

Usage:
<my-component>
    <template v-slot="first">

 first begins

        <v-slot />

 first ends

    </template>
    <template v-slot="second">

 second begins

        <v-slot />

 second ends

    </template>
</my-component>

Rendered:

 first begins

 second begins

 Hello world!

 second ends

 first ends

v-fallback example:
<template id="my-component">
    <v-slot />

 Empty slot! </v-fallback>
</template>

v-fallback could also be used in other situations where an element might fail in any way, like <component>:
<component :is="my_component" />

 {{my_component}} is not a valid component name! </v-fallback>

If you want to wrap a slot, it's better to let the component user do so because the intention is clearer:
// foo.vue
<template>
     <slot >

               <slot name="content">

Content

               </slot>

    </slot>
</template>

so the user can write
<foo>
    <wrapper>
        <content/>
    </wrapper>
</foo>
<foo>
    <content slot="content"/>
</foo>

which clearly shows how things are put together.
Related: #5401 and #6811

If I understood your approach correctly, your solution to the problem I described would be this:
<my-conditional-wrap-component>

        content

            content

</my-conditional-wrap-component>

Which means I have to either repeat myself or create a separate component and write extra boilerplate. Both seem suboptimal.
And I might as well just write this instead:

        content

    content

I took a look at the other two issues and I'm not sure in what way they are related. Please expand?

Thanks for the suggestion - however, having parallel mechanisms that solve similar problems, but each with its own complexity is a big no-go in terms of API consistency. So this will not be something that we can consider in core, but you are welcome to try to implement this in userland.

All right, thanks for the answer.
Is this something you can consider as a replacement for <slot> for Vue 3.x?


FIX: Fxmaster v1.1.4 compatibility

Due to FXMaster new folder organization, FilterManager is not found by PerfectVision.
This update use the exported FilterManager in FXMASTER.filters.

Thanks!


Sort the whitelist

Expected Behavior
Add an optional parameter to the @ rule to sort it.
change @*://prefix.domain_name.suffix/* to @*://prefix.domain_name.suffix/*, number
The higher the number, the lower the ranking.

I won't implement this feature because it is hard work and I don't think it is necessary at all.
You should create a pull request if you want it.


Loss is decreasing and predicting data but Accuracy not increasing.

Loss in LSTM network is decreasing and predicting time series data closer to existing data but Accuracy is increased to some value like acc - 0.784 and constantly repeating for all the Epochs
or else
There is another possibility will be like accuracy will be 0 for all the epochs neither it's increasing nor it's decreasing.

Try increasing the batch size and reduce the learning rate while training. Please let me know.

Yup, done it. But now entirely different as it changed accuracy into fluctuating form (increasing and decreasing) for "N" set of epochs performing the training.
Though this is weird as the existing data (Historical data) and predicted data is closer to each other in the graph and loss is decreasing in the console.
One more detail is I am using "ModelCheckpoint"  from keras to save the best model and reload it if training restarts.

Can you post the screen-shot of the training process.

Yup,
Images are in order wide placed.
I figured out using dropout increases the fluctuations.

You don't need to consider accuracy as a metric, as this is a regression problem. A decrease in loss function is what you need to consider in the best model.  Also, use a lower learning rate to start with (just a suggestion)

Okay, I'll try that and thank you for your suggestion.

same issue for me

I faced the same issue


CI: Split tests into groups to speed them up

Mark some slow tests as advanced
Split tests into 4 shards in CI

Good question on the advanced tests - I'll look into setting up a nightly cron job

Okay, I just added a nightly cron job that runs the full test suite

Looks good to me. Thanks for adding the nightly job @darthtrevino

test advanced

test advanced

Did this actually run the advanced tests?

@emrekiciman No, it doesn't appear to have. It may need to be in the main branch before it will work. I'll test it out in a fork

@emrekiciman I verified that the advanced tests kick off in my fork. However, workflows that use the comment trigger must be defined on the main branch.

Thank you for validating the "test advanced" trigger, @darthtrevino .  I'll go ahead and approve/merge the PR.   I expect we'll still end up adjusting exactly which tests run in the core vs other groups over time now that this is setup, but this is a great place to start.  It's nice to have the critical tests completing faster.


SetValue auto converter

Is your feature request related to a problem? Please describe.
When using SetValue I would like to auto-convert string values to the target property primitive data type
Describe the solution you'd like
It should be a new NavigatorOption::SetValueAutoConvert, if it is specified then before setting the value the system should check the target property datatype and convert the value using the Convert class, for example: Convert.ToDateTime()
Describe alternatives you've considered
N/A
Additional context
It can be useful for CSV file processing

this is partially implemented already, no need to add an option flag for it


subDomains working as not expected from docs

According to subDomains -> matches table at docs, I thought the next configuration
(
  let
    rootZone = "example.org";
  in
  {
    networking.domains = {
      enable = true;
      defaultTTL = 86400; # 24h
      baseDomains."nodes.${rootZone}" = { };
      baseDomains."${rootZone}" = { };
      subDomains."xxx.nodes.${rootZone}".a.data = [ "<IP_ADDRESS>" ];
      subDomains."yyy.${rootZone}".cname.data = [ "xxx.nodes.${rootZone}" ];
    };
  }
)

will evaluate to something like that
{
  "nodes.example.org" = {
    "xxx.nodes.example.org" = {
      a = {
        data = [ "<IP_ADDRESS>" ];
        ttl = 86400;
      };
    };
  };
  "example.org" = {
    "yyy.example.org" = {
      cname = {
        data = [ "xxx.nodes.example.org" ];
        ttl = 86400;
      };
    };
  };
}

But in real on the latest master this evaluates to:
{
  "example.org" = {
    "xxx.nodes.example.org" = {
      a = {
        data = [ "<IP_ADDRESS>" ];
        ttl = 86400;
      };
    };
    "yyy.example.org" = {
      cname = {
        data = [ "xxx.nodes.example.org" ];
        ttl = 86400;
      };
    };
  };
}

So, the baseDomains."nodes.${rootZone}" = { }; line makes no changes whenever it exists or not.
As how Im traced, this happens due to reducedBaseDomains.
Is this intended?
Also there is an error in code block before table, networking.domains.baseDomains should be replaced with networking.domains.subDomains, otherwise this sample makes no sense.

I'll look into this in a bit once I have more time, thank you very much for the report, but yes you are right, this seems like a bug.


Recording time left incorrect

We have noticed that the variable recording time does not display the correct time that is left to record on the disk. The minutes and seconds seem to be correct but the hours are not correct. on the hyperdeck it shows we have 52:45:21 left to record but on the streamdeck it says only 04:45:21. Another hyperdeck has 72:43:07 but on the streamdeck it shows we have 00:43:07.
Would love to hear if there is a solution for this.

The code converting seconds to readable time didn't allow for there being over 24 hours available.
This is fixed now.

I am still having issues with this on Companion 3.2.2. Am I missing something?

The fix is not in 3.2.2. Try the 3.3.0 beta and that should fix the problem (a 3.3.0 stable release is not far off).


Plugin error in Logstash 8.15

Hi @cameronkerrnz
I got error since upgrade logstash from 7.17 to 8.15, the plugin not working anymore.
I dont now to resolve this issue, can i get help? thank you
In the logs, I got fatal error:
[2024-10-24T17:02:08,744][FATAL][org.logstash.Logstash    ] uncaught error (in thread [es-enrichment]>worker6)
java.lang.NoSuchMethodError: 'com.fasterxml.jackson.databind.JsonNode com.maxmind.db.Reader.get(java.net.InetAddress)'
        at org.logstashplugins.MMDB.filter(MMDB.java:157) ~[logstash-filter-mmdb-1.0.1.jar:?]
        at org.logstash.config.ir.compiler.JavaFilterDelegatorExt.doMultiFilter(JavaFilterDelegatorExt.java:81) ~[logstash-core.jar:?]
        at org.logstash.config.ir.compiler.AbstractFilterDelegatorExt.lambda$multiFilter$0(AbstractFilterDelegatorExt.java:133) ~[logstash-core.jar:?]
        at org.logstash.instrument.metrics.timer.ConcurrentLiveTimerMetric.time(ConcurrentLiveTimerMetric.java:47) ~[logstash-core.jar:?]
        at org.logstash.config.ir.compiler.AbstractFilterDelegatorExt.multiFilter(AbstractFilterDelegatorExt.java:133) ~[logstash-core.jar:?]
        at org.logstash.generated.CompiledDataset10.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset4.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset11.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset10.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset4.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset11.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset5.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
        at org.logstash.generated.CompiledDataset13.compute(Unknown Source) ~[?:?]
        at org.logstash.config.ir.CompiledPipeline$CompiledUnorderedExecution.compute(CompiledPipeline.java:347) ~[logstash-core.jar:?]
        at org.logstash.config.ir.CompiledPipeline$CompiledUnorderedExecution.compute(CompiledPipeline.java:341) ~[logstash-core.jar:?]
        at org.logstash.execution.ObservedExecution.lambda$compute$0(ObservedExecution.java:17) ~[logstash-core.jar:?]
        at org.logstash.execution.WorkerObserver.lambda$observeExecutionComputation$0(WorkerObserver.java:39) ~[logstash-core.jar:?]
        at org.logstash.instrument.metrics.timer.ConcurrentLiveTimerMetric.time(ConcurrentLiveTimerMetric.java:47) ~[logstash-core.jar:?]
        at org.logstash.execution.WorkerObserver.lambda$executeWithTimers$1(WorkerObserver.java:50) ~[logstash-core.jar:?]
        at org.logstash.instrument.metrics.timer.ConcurrentLiveTimerMetric.time(ConcurrentLiveTimerMetric.java:47) ~[logstash-core.jar:?]
        at org.logstash.execution.WorkerObserver.executeWithTimers(WorkerObserver.java:50) ~[logstash-core.jar:?]
        at org.logstash.execution.WorkerObserver.observeExecutionComputation(WorkerObserver.java:38) ~[logstash-core.jar:?]
        at org.logstash.execution.ObservedExecution.compute(ObservedExecution.java:17) ~[logstash-core.jar:?]
        at org.logstash.execution.WorkerLoop.abortableCompute(WorkerLoop.java:113) ~[logstash-core.jar:?]
        at org.logstash.execution.WorkerLoop.run(WorkerLoop.java:86) ~[logstash-core.jar:?]
        at usr.share.logstash.logstash_minus_core.lib.logstash.java_pipeline.RUBY$block$start_workers$5(/usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:304) ~[?:?]
        at org.jruby.runtime.CompiledIRBlockBody.callDirect(CompiledIRBlockBody.java:141) ~[jruby.jar:?]
        at org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:64) ~[jruby.jar:?]
        at org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:58) ~[jruby.jar:?]
        at org.jruby.runtime.Block.call(Block.java:144) ~[jruby.jar:?]
        at org.jruby.RubyProc.call(RubyProc.java:354) ~[jruby.jar:?]
        at org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:111) ~[jruby.jar:?]
        at java.lang.Thread.run(Thread.java:1583) ~[?:?]

Hi, I haven’t updated the project to work with Logstash 8.x yet. I made a
start on it last night and now I’m trying to solve some Ruby (bundler)
issues.

This particular error will be because the version of Jackson has changed
between Logstash 7 and 8… at least that’s my assumption from what I’ve seen.
--
Cameron Kerr @.***>
On Mon, 28 Oct 2024 at 9:10 PM, kpi-nourman @.***>
wrote:

Hi @cameronkerrnz https://github.com/cameronkerrnz
I got error since upgrade logstash from 7.17 to 8.15, the plugin not
working anymore.
I dont now to resolve this issue, can i get help? thank you
In the logs, I got fatal error:
[2024-10-24T17:02:08,744][FATAL][org.logstash.Logstash    ] uncaught error (in thread [es-enrichment]>worker6)
java.lang.NoSuchMethodError: 'com.fasterxml.jackson.databind.JsonNode com.maxmind.db.Reader.get(java.net.InetAddress)'
at org.logstashplugins.MMDB.filter(MMDB.java:157) ~[logstash-filter-mmdb-1.0.1.jar:?]
at org.logstash.config.ir.compiler.JavaFilterDelegatorExt.doMultiFilter(JavaFilterDelegatorExt.java:81) ~[logstash-core.jar:?]
at org.logstash.config.ir.compiler.AbstractFilterDelegatorExt.lambda$multiFilter$0(AbstractFilterDelegatorExt.java:133) ~[logstash-core.jar:?]
at org.logstash.instrument.metrics.timer.ConcurrentLiveTimerMetric.time(ConcurrentLiveTimerMetric.java:47) ~[logstash-core.jar:?]
at org.logstash.config.ir.compiler.AbstractFilterDelegatorExt.multiFilter(AbstractFilterDelegatorExt.java:133) ~[logstash-core.jar:?]
at org.logstash.generated.CompiledDataset10.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset4.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset11.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset10.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset4.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset11.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset5.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset3.compute(Unknown Source) ~[?:?]
at org.logstash.generated.CompiledDataset13.compute(Unknown Source) ~[?:?]
at org.logstash.config.ir.CompiledPipeline$CompiledUnorderedExecution.compute(CompiledPipeline.java:347) ~[logstash-core.jar:?]
at org.logstash.config.ir.CompiledPipeline$CompiledUnorderedExecution.compute(CompiledPipeline.java:341) ~[logstash-core.jar:?]
at org.logstash.execution.ObservedExecution.lambda$compute$0(ObservedExecution.java:17) ~[logstash-core.jar:?]
at org.logstash.execution.WorkerObserver.lambda$observeExecutionComputation$0(WorkerObserver.java:39) ~[logstash-core.jar:?]
at org.logstash.instrument.metrics.timer.ConcurrentLiveTimerMetric.time(ConcurrentLiveTimerMetric.java:47) ~[logstash-core.jar:?]
at org.logstash.execution.WorkerObserver.lambda$executeWithTimers$1(WorkerObserver.java:50) ~[logstash-core.jar:?]
at org.logstash.instrument.metrics.timer.ConcurrentLiveTimerMetric.time(ConcurrentLiveTimerMetric.java:47) ~[logstash-core.jar:?]
at org.logstash.execution.WorkerObserver.executeWithTimers(WorkerObserver.java:50) ~[logstash-core.jar:?]
at org.logstash.execution.WorkerObserver.observeExecutionComputation(WorkerObserver.java:38) ~[logstash-core.jar:?]
at org.logstash.execution.ObservedExecution.compute(ObservedExecution.java:17) ~[logstash-core.jar:?]
at org.logstash.execution.WorkerLoop.abortableCompute(WorkerLoop.java:113) ~[logstash-core.jar:?]
at org.logstash.execution.WorkerLoop.run(WorkerLoop.java:86) ~[logstash-core.jar:?]
at usr.share.logstash.logstash_minus_core.lib.logstash.java_pipeline.RUBY$block$start_workers$5(/usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:304) ~[?:?]
at org.jruby.runtime.CompiledIRBlockBody.callDirect(CompiledIRBlockBody.java:141) ~[jruby.jar:?]
at org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:64) ~[jruby.jar:?]
at org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:58) ~[jruby.jar:?]
at org.jruby.runtime.Block.call(Block.java:144) ~[jruby.jar:?]
at org.jruby.RubyProc.call(RubyProc.java:354) ~[jruby.jar:?]
at org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:111) ~[jruby.jar:?]
at java.lang.Thread.run(Thread.java:1583) ~[?:?]
—
Reply to this email directly, view it on GitHub
https://github.com/cameronkerrnz/logstash-filter-mmdb/issues/1, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHFFTWSQLRZDYBMG7Z4ETLZ5XWN5AVCNFSM6AAAAABQW2QS22VHI2DSMVQWIX3LMV43ASLTON2WKOZSGYYTONRTHA3TINY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi, I haven’t updated the project to work with Logstash 8.x yet. I made a start on it last night and now I’m trying to solve some Ruby (bundler) issues.  This particular error will be because the version of Jackson has changed between Logstash 7 and 8… at least that’s my assumption from what I’ve seen.

Hi @cameronkerrnz, thank you for helping me, I will wait for the good news


fix(deps): update fastify to v3

See Migration-Guide-V3

Codecov Report

Merging #731 (861e75f) into master (a3f0b07) will decrease coverage by 0.04%.
The diff coverage is 9.67%.

@@            Coverage Diff             @@
##           master     #731      +/-   ##
==========================================
- Coverage   50.24%   50.19%   -0.05%
==========================================
  Files          24       24
  Lines        1041     1042       +1
  Branches      199      201       +2
==========================================
  Hits          523      523
- Misses        471      472       +1
  Partials       47       47

Impacted Files
Coverage Δ

src/commands/serve.ts
11.76% <9.67%> (-0.09%)
:arrow_down:


Update StagingDeployCash for manual cherry-picks

Details
If the cherryPick.yml workflow was run manually (i.e: by a user other than OSBotify), then we need to update the deploy checklist to include the newly deployed PR.
Fixed Issues
$ https://github.com/Expensify/App/issues/4379
Tests

Merge this PR with the deploy checklist locked.
Manually CP this PR.
Verify that, once the CP workflow completes, the checklist is updated to include this PR.

QA Steps
None.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

Manually CPing this to test if it works!

JK, it's already been added to the checklist. So I'll have to remember to test this with another PR.

This did not work as expected. I forgot that the createOrUpdateStagingDeploy action relies on the new tag having been created in the runner. Will create a follow-up PR to fix.

This failure was fortuitous, as it maybe led me to a revelation of how to fix a related bug that has been marring me for months now. In case you're curious....
But that means that the fix for this is maybe actually a bit greater in scope than a quick follow-up, so we should revert this. It's not actually breaking anything, just causing red herring CP workflow failures.

Revert PR is ready: https://github.com/Expensify/App/pull/4815

🚀 Deployed to production by @roryabraham in version: 1.0.88-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Move project to OWASP organization?

I'm wondering if this project should be moved to the GitHub OWASP organization. Besides making it easier for people to find, that provides some security in case you're hit by a falling piano or something. I guess I don't feel strongly about it, but thought I'd mention it.

@Neil-Smithline I'm not necessarily opposed to it, but would like to see a plan from the community on how that should look. I'm fine to do it going forward if people are interested. From my perspective, I'd want to see all flagship projects handled the same way if possible. There have been a couple false starts before, so I'd like to see the plan before making changes.


Canvas rotation error, black screen

Hello all,
I have a problem with io.skyway.Peer.Browser.Canvas. I would like to rotate video stream on this canvas by 90 degrees but it did not execute rotation.
Setting "android:rotation='90'" in layout xml rotates but yields black surface - no camera preview.
How can I do it?
Please help me,
Thanks for all

have u got the answer? @hoangchuongmozart .
I got the same problem but now i'm stuck.
Could u please share the solution with me?
Thanks alot


Add onDidChangeModelMarkers to IEditor interface

Similar methods such as setModelLanguage have emitters:
setModelLanguage
onDidChangeModelLanguage
It would be useful to have the same for modelMarkers:
setModelMarkers
onDidChangeModelMarkers

Closed for https://github.com/Microsoft/vscode/issues/18465

Let's keep the issue in the monaco-editor repository as it is about the standalone editor and has no impact on vscode.

Will this feature be added some time?

@alexandrudima hello!
I would like to implement this feature. Can I start working on it?


fix: this usage adopt to<EMAIL_ADDRESS>

fix: https://github.com/vitejs/vite/issues/10031
fix: https://github.com/brillout/vite-plugin-mdx/issues/51
fix: https://github.com/vitejs/vite-plugin-react-pages/issues/83

Seems like TS doesn't like the changes:
src/viteMdxTransclusion/index.ts:44:14 - error TS2339: Property 'configureServer' does not exist on type '{ name: string; configResolved({ root, logger }: { root: any; logger: any; }): void; }'.

44       plugin.configureServer = (server) => {

Seems like TS doesn't like the changes:
src/viteMdxTransclusion/index.ts:44:14 - error TS2339: Property 'configureServer' does not exist on type '{ name: string; configResolved({ root, logger }: { root: any; logger: any; }): void; }'.

44       plugin.configureServer = (server) => {

Fixed in https://github.com/brillout/vite-plugin-mdx/pull/53


fix(sbb-card): change sbb-card-badge order

Preflight Checklist

[x] I have read the Contributing Guidelines for this project.
[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the pull request tracker for a Pull Request (PR) that matches the one I want to submit, without success.

Issue
This PR Closes #
Pull request checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)

See Review Guidelines for more information what is checked during review process.
Changes
Changes in this pull request:

Browsers
I tested the build on the following browsers:

[ ] Firefox Desktop
[ ] Chrome Desktop
[ ] Edge Desktop
[ ] Safari Desktop
[ ] Chrome Mobile
[ ] Safari Mobile

Screen readers
I tested the build on the following browsers:

[ ] JAWS Firefox Desktop
[ ] JAWS Chrome Desktop
[ ] NVDA Firefox Desktop
[ ] NVDA Chrome Desktop
[ ] VoiceOver Safari Desktop
[ ] VoiceOver Chrome Desktop
[ ] VoiceOver Safari Mobile
[ ] Android Accessibility Suite Chrome Mobile

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Does this introduce a breaking change?

[ ] Yes
[ ] No

Other information

Codecov Report

Merging #1687 (bb10dcc) into master (ab917b0) will decrease coverage by 3.61%.
The diff coverage is 50.90%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##           master    #1687      +/-   ##
==========================================
- Coverage   54.85%   51.24%   -3.61%
==========================================
  Files          49      135      +86
  Lines        1659     4826    +3167
  Branches      406     1325     +919
==========================================
+ Hits          910     2473    +1563
- Misses        671     2178    +1507
- Partials       78      175      +97

Impacted Files
Coverage Δ

...ts/sbb-accordion-item/sbb-accordion-item.events.ts
100.00% <ø> (ø)

...mponents/sbb-accordion-item/sbb-accordion-item.tsx
0.00% <0.00%> (-37.21%)
:arrow_down:

src/components/sbb-checkbox/sbb-checkbox.events.ts
0.00% <ø> (ø)

src/components/sbb-icon/sbb-icon-request.ts
70.00% <ø> (ø)

src/components/sbb-icon/sbb-icon-validate.ts
45.16% <ø> (ø)

src/components/sbb-icon/sbb-icon.tsx
92.30% <ø> (ø)

src/components/sbb-image/sbb-image.helper.tsx
0.00% <ø> (-64.52%)
:arrow_down:

src/components/sbb-image/sbb-image.tsx
0.00% <ø> (-62.97%)
:arrow_down:

...mponents/sbb-journey-header/sbb-journey-header.tsx
88.23% <ø> (+1.27%)
:arrow_up:

...onents/sbb-journey-summary/sbb-journey-summary.tsx
81.08% <ø> (ø)

... and 23 more

... and 112 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


404 Page when app request

Describe the bug
when i try to request to add an application i get a 404 page
To Reproduce
Steps to reproduce the behavior:
on windows 11 click on the app store, then click the download icon, then click Add your own app
Expected behavior
the thing that shows up for me to request an app to add
Screenshots

Desktop (please complete the following information):

OS: Chrome OS 97
Browser Chrome
Version 97

Additional context
Add any other context about the problem here.

Hey that button should normally take you here.
https://github.com/win11bot/win11bot
I will get it fixed.


Add module Loading screen

Running on RasPi 3B+ connected to 4 GCal feeds, as expected the module takes a while to load but nothing is displayed while waiting.
Loading text element similar to newsfeed & weather could be useful in informing what's going on.

I'll consider it on next update. Thanks.


Convert Yolo to XML

Is there some tool or script for importing existing annotations into CVAT from other formats (Yolo)
I have some annotated data in Yolo format that I would like to adjust in cvat.

@LukeAI , please ask your questions next time on our gitter channel. Please review the link below:
https://github.com/opencv/cvat#supported-annotation-formats


Replace deprecated instagram legacy API by instagram basic display API

Hi Kévin
I am not pressed ;)
That would be nice
Thx
Greeting
Thomas
Am Mi., 24. Juni 2020 um 19:42 Uhr schrieb Kévin Marcachi <
<EMAIL_ADDRESS>
@moduleon commented on this pull request.
Hi Thomas, thank you for this interesting PR, I test more deeply as soon
as possible. Great Job, I would like you to add a section in the README,
for Contributors, and add your name in it, if it's okay for you.
In README.md
https://github.com/moduleon/grav-plugin-social-feed/pull/21#discussion_r445060100
:

@@ -164,6 +164,21 @@ class CustomPlugin extends Plugin
}

+## Nwtworks

Typo: Networks
------------------------------

In blueprints.yaml
<https://github.com/moduleon/grav-plugin-social-feed/pull/21#discussion_r445060728>
:

>                type: text
-              label: Username
+              label: User ID
+            .access_token:
+              type: text
+              label: Access token
+            .avatar:
+              type: file
+              label: Avatar
+              help: Fallback image if no user image aviable by api

Typo: available I guess, not aviable

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/moduleon/grav-plugin-social-feed/pull/21#pullrequestreview-436864061>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AELOOE344UTY2YDYKVVRYJ3RYI3JPANCNFSM4OGUQVKA>
.


Prediction masks for test images

Might it be possible to share some code for visualization of anomaly regions through heat map/masks from the trained model, on test images ?

well, I don't have that part of the code. But I suppose you can render the color map from the output feature map in this line for example https://github.com/gathierry/FastFlow/blob/37c99ae33b8db0e5cb534fd0d197b0bc44817a03/main.py#L97 which shares the same size as input image (256x256).


Generational ZGC Support

Generational ZGC adds 'Minor' and 'Major' to the label causing the (?:Garbage Collection) group not to match:
[2022-11-22T04:18:09.618+0000][1583.644s][5085][info ][gc               ] GC(163) Minor Garbage Collection (High Usage) 42238M(95%)->16152M(36%) 0.641s

It's also not aware of generations, so the heap filled metrics get confused when a major collection happens. Log attached for convenience:
GenZGC.log.zip

I think this was addressed recently with https://github.com/apple/GCGC/commit/9e15caab3ee3f346abb78bf72712df8ed9dabd3d

Let's close this issue since Gen ZGC support is now implemented. If it does not work as expected, please file another issue!


Pip failed to install maya on Windows

Tried to install, failed with a UnicodeDecodeError. Changed the terminal encoding to UTF-8, problem persisted. Am I doing something wrong? I'm using Windows 10, 64 bits, with Python 3.5.
C:\Windows\system32>pip install maya
Collecting maya
  Downloading maya-0.1.0.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\BoppreH\AppData\Local\Temp\pip-build-cuz437_p\maya\setup.py", line 26, in <module>
        long_description=open('README.rst').read(),
      File "c:\program files\python35\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 2172: character maps to <undefined>

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\BoppreH\AppData\Local\Temp\pip-build-cuz437_p\maya\

C:\Windows\system32>chcp 65001
Active code page: 65001

C:\Windows\system32>pip install maya
Collecting maya
  Using cached maya-0.1.0.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\BoppreH\AppData\Local\Temp\pip-build-044jp0hk\maya\setup.py", line 26, in <module>
        long_description=open('README.rst').read(),
      File "c:\program files\python35\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 2172: character maps to <undefined>

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\BoppreH\AppData\Local\Temp\pip-build-044jp0hk\maya\

I am facing the same issue as you are

Can you try again?

P.S. Maya has only been tested on Python 2.7 so far.

Version 1.1 still has the same problem on Python 3.
C:\Windows\system32>pip install maya
Collecting maya
  Downloading maya-0.1.1.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\BoppreH\AppData\Local\Temp\pip-build-oztje553\maya\setup.py", line 26, in <module>
        long_description=open('README.rst').read(),
      File "c:\program files\python35\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 2170: character maps to <undefined>

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\BoppreH\AppData\Local\Temp\pip-build-oztje553\maya\

Installation on Python 2.7 worked flawlessly, however.

Python 3 compatibility will be added soon, thanks for bringing this issue up.

Oh, ok. I'll leave the issue open in case you want to track it, but feel free to close/rename or do as you see fit.
Thank you for your attention.

I've seen this type of issues before, it cause you are using emojis in your readme, change the open to be open with Unicode support...

The issue isn't with readme I believe. It's most likely with the setup.py file. I don't think it has anything to do with the readme file.
If you see above example, Python's not able to parse setup.py and an issue with the function egg_info

As @fruch said, it's because of the README.
It might seem a bit overkill but you can use this snippet from pip's own setup.py:
# setup.py
import codecs

here = os.path.abspath(os.path.dirname(__file__))

def read(*parts):
    return codecs.open(os.path.join(here, *parts), 'r').read()

long_description = '\n' + read('README.rst')

This sould fix it

@joaoleveiga up for a pull request?

I saw that @joaoleveiga's fix was implemented in 89a54abf1f4c0c169287cfd47ecf23e35881a29a, but I'm still having issues with installing maya 0.1.4 via pip.
I'm running pip-9.0.1 with Python 3.5.2 on Windows 10 (already did a chcp 65001 in cmd):
Collecting maya
  Using cached maya-0.1.4.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Joshua\AppData\Local\Temp\pip-build-i4kj_bou\maya\setup.py", line 40, in <module>
        long_description= '\n' + read('README.rst'),
      File "C:\Users\Joshua\AppData\Local\Temp\pip-build-i4kj_bou\maya\setup.py", line 20, in read
        return codecs.open(os.path.join(here, *parts), 'r').read()
      File "c:\users\joshua\appdata\local\programs\python\python35-32\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 3332: character maps to <undefined>
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\Joshua\AppData\Local\Temp\pip-build-i4kj_bou\maya\

Seems to be the same issue.

There have been some fixes around this. Can you verify if it's working now @JoshuaRLi ?

@timofurrer Ah, I don't use Windows anymore. It's been quite a while.

Okay, @boppreh do you have any news on this?

I can confirm Windows installation on Python 3 is working as expected.

Thanks for the confirmation :tada:

This issue may need to be reopened.  My environment is using Python 3.6.5 on Windows 10, 64 bits. I just attempted to pip install maya 0.6.1 and 0.6.0 and I was getting the same sort of UTF-8 issue:
ERROR: Exception: Traceback (most recent call last):   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\cli\base_command.py", line 178, in main     status = self.run(options, args)   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\commands\install.py", line 352, in run     resolver.resolve(requirement_set)   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\resolve.py", line 131, in resolve     self._resolve_one(requirement_set, req)   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\resolve.py", line 294, in _resolve_one     abstract_dist = self._get_abstract_dist_for(req_to_install)   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\resolve.py", line 242, in _get_abstract_dist_for     self.require_hashes   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\operations\prepare.py", line 362, in prepare_linked_requirement     abstract_dist.prep_for_dist(finder, self.build_isolation)   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\operations\prepare.py", line 171, in prep_for_dist     self.req.prepare_metadata()   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\req\req_install.py", line 553, in prepare_metadata     metadata_name = canonicalize_name(self.metadata["Name"])   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\req\req_install.py", line 674, in metadata     self._metadata = get_metadata(self.get_dist())   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_internal\utils\packaging.py", line 48, in get_metadata     metadata = dist.get_metadata('METADATA')   File "c:\users\rahosbach\anaconda3\lib\site-packages\pip\_vendor\pkg_resources\__init__.py", line 1420, in get_metadata     return value.decode('utf-8') if six.PY3 else value UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 185: invalid continuation byte
I was able to install version 0.5.0 properly, though.


Add a configuration to control the visibility of subgizmos per axis

Closes #57

This functionality is actually already implemented in branch: https://github.com/urholaukkarinen/transform-gizmo/tree/more-modes, but not yet merged to main. I should've created an issue for it to let people know it is being implemented.. sorry about that.


chore(deps): update ruff to v0.7.3

This PR contains the following updates:

Package
Type
Update
Change

astral-sh/ruff-pre-commit
repository
patch
v0.7.2 -> v0.7.3

ruff (source, changelog)
tool.pdm.dev-dependencies
patch
==0.7.2 -> ==0.7.3

[!WARNING]
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Note: The pre-commit manager in Renovate is not supported by the pre-commit maintainers or community. Please do not report any problems there, instead create a Discussion in the Renovate repository if you have any questions.

Release Notes

astral-sh/ruff-pre-commit (astral-sh/ruff-pre-commit)
v0.7.3
Compare Source
See: https://github.com/astral-sh/ruff/releases/tag/0.7.3

astral-sh/ruff (ruff)
v0.7.3
Compare Source
Preview features

Formatter: Disallow single-line implicit concatenated strings (#13928)
[flake8-pyi] Include all Python file types for PYI006 and PYI066 (#14059)
[flake8-simplify] Implement split-of-static-string (SIM905) (#14008)
[refurb] Implement subclass-builtin (FURB189) (#14105)
[ruff] Improve diagnostic messages and docs (RUF031, RUF032, RUF034) (#14068)

Rule changes

Detect items that hash to same value in duplicate sets (B033, PLC0208) (#14064)
[eradicate] Better detection of IntelliJ language injection comments (ERA001) (#14094)
[flake8-pyi] Add autofix for docstring-in-stub (PYI021) (#14150)
[flake8-pyi] Update duplicate-literal-member (PYI062) to alawys provide an autofix (#14188)
[pyflakes] Detect items that hash to same value in duplicate dictionaries (F601) (#14065)
[ruff] Fix false positive for decorators (RUF028) (#14061)

Bug fixes

Avoid parsing joint rule codes as distinct codes in # noqa (#12809)
[eradicate] ignore # language= in commented-out-code rule (ERA001) (#14069)
[flake8-bugbear] - do not run mutable-argument-default on stubs (B006) (#14058)
[flake8-builtins] Skip lambda expressions in builtin-argument-shadowing (A002) (#14144)
[flake8-comprehension] Also remove trailing comma while fixing C409 and C419 (#14097)
[flake8-simplify] Allow open without context manager in return statement (SIM115) (#14066)
[pylint] Respect hash-equivalent literals in iteration-over-set (PLC0208) (#14063)
[pylint] Update known dunder methods for Python 3.13 (PLW3201) (#14146)
[pyupgrade] - ignore kwarg unpacking for UP044 (#14053)
[refurb] Parse more exotic decimal strings in verbose-decimal-constructor (FURB157) (#14098)

Documentation

Add links to missing related options within rule documentations (#13971)
Add rule short code to mkdocs tags to allow searching via rule codes (#14040)

Configuration
📅 Schedule: Branch creation - "before 4am on Monday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: pdm.lock
Command failed: pdm update --no-sync --update-eager -dG dev ruff
[FileNotFoundError]: [Errno 2] No such file or directory: '/home/ubuntu/.local/state'
WARNING: Add '-v' to see the detailed traceback


Update caab-api version to 0.0.7

Automatic PR raised by GitHub Actions to update caab-api version to 0.0.7

Will be done as part of ccls-1734


RecordBatch conversion from pyarrow loses Schema's metadata

Describe the bug
When importing a pyarrow RecordBatch, we instantiate a StructArray, then convert it to a RecordBatch.
This loses the metadata from the original schema. This is not seen in the current tests, because pyarrow's
tests for equality on schemas ignores metadata.
https://github.com/apache/arrow-rs/blob/31cf5ce23febf076104f064358a24fe8af09ee4b/arrow/src/pyarrow.rs#L357-L358
To Reproduce
# In arrow-pyarrow-integration-testing/tests/test_sql.py:470
batch = pa.record_batch([f32_array], ["tensor"], metadata={b'key1': b'value1'})
    b = rust.round_trip_record_batch(batch)
    assert b == batch  # OK
    assert b.schema == batch.schema  # OK
    assert b.schema.metadata == batch.schema.metadata  # Fails

Expected behavior
Imported RecordBatch's schema should keep its metadata.

This looks to have been introduced by https://github.com/apache/arrow-rs/pull/5070 perhaps @kylebarron you might be able to take a look. Also tagging @pitrou for some pyarrow knowledge

That's correct, I think #5070 introduced it, by transforming from a StructArray in the capsule case. The code for non-capsule conversion will work fine, because it keeps the schema around.
On the pyarrow side, I was surprised that a.schema == b.schema would work when fields match, but metadata is different (which is how tests were green).

On the pyarrow side, I was surprised that a.schema == b.schema would work when fields match, but metadata is different (which is how tests were green).

Sorry for that. Indeed, by default Schema equality doesn't check the metadata. You would have to change the code to a.equals(b, check_metadata=True).
(see https://arrow.apache.org/docs/python/generated/pyarrow.Schema.html#pyarrow.Schema.equals)

IMHO that would be a good idea, since it would make the tests stricter :-)

The source of that additional metadata seems to come from arrow's code, which is called by pyarrow to export the array and schema. pyarrow calls arrow's ExportArray, which itself exports the schema and adds metadata to the field to handle its extension type.
https://github.com/apache/arrow/blob/787afa1594586d2d556d21471647f9cd2c55b18f/cpp/src/arrow/c/bridge.cc#L283C1-L292C6

That is similar to how things are done for Arrow IPC. Knowledge of the extension type is serialized as metadata fields, and then extracted from the metadata on deserialization.

... it still means that schema.equals fails when there are extension fields, because the original pyarrow schema does not have it, yet exports it to the rust object, and it is still present when it comes back from its round-trip.
A few solutions come to mind:

Either we just test that the schema metadata is the same, and ignore fields metadata.
Or we allow the returned schema to be different, but ensure that any metadata in the original schema/fields comes back unharmed (and we allow for new metadata keys)

Ok, I opened https://github.com/apache/arrow/issues/39865 for Arrow C++.

I believe I also hit this recently but hadn't debugged where the conversion was failing. Thanks for the issue and PR!
I've also hit related pyarrow issues around extension types and schema metadata. Not sure what the right solution is to those (personally I wish the schema metadata were always accessible on the Field even when an extension type is registered, because it's possible that a third party has registered an extension and you don't know what attributes are guaranteed to exist on that class).


[WIP] Email Redesign finishup

Leftover of #5592

[X] Replace server_uri with email_images_base_uri (see #6262).
[X] Remove any context or content changes.
[X] Separate out the CSS into its own file, and use the premailer package to do CSS inlining
[X] Run inilining during provision

Not ready for a review yet.

@rishig Please check :)

@rishig This is ready for a review. :)
Also the style of subject and template name eg(Test for notify_change_in_email
Subject: Zulip email changed for Acme Corporation) is different because it gets the style from the internal CSS which is absent in this case.

I merged the first commit, thanks @hackerkid!  The second commit has a few small issues (basically we need to run the tooling in production as well), which I'll take care of and then merge.
I'm posting a few comments on the rest.

A few other thoughts:

I think it might be cleaner structurally to have separate directories for the source templates and the rendered templates.  E.g. templates/zerver/emails/source for the source templates and templates/zerver/emails/compiled/ for the compiled templates.  Then we wouldn't need to do any per-file work in .gitignore (etc.); we could just gitignore the whole directory.
We should update /devtools to document the fact you need to run the new tool before looking at /emails for the fast iterative development cycle.

@rishig the emails look good in testing, so I'd be happy to merge this once those issues are resolved, but I figured I'd ping you in case you have further TODO items here.
Huge thanks for all your work on this @hackerkid and @vaidap!

Merged, after adding code to bump PROVISION_VERSIOn and Rishi adding d0a9e92f1ddaa3543deaf5762c7fef3f4e108818.  Huge thanks for doing this @hackerkid and @vaidap!  Not only do all of our emails look a lot better, but we have a reasonable infrastructure for editing.
@hackerkid I have 3 follow-up projects related to this for you:

I think we should change the /generate endpoint to run the tools/inline-email-css command automatically (but still leave it documented in /devtools, since you need to do it manually if you're just using the logs).  I think that'll make this a lot less error-prone.
We should make the /emails page have a little UI widget for each email where you can put in your email address and it'll send you the email, so that one can do end-to-end testing without deploying to production.
We should update https://zulip.readthedocs.io/en/latest/email.html to explain some of the new infrastructure.


Update calendar.directive.coffee

Pass the new date as part of the emitted event.  This enables the consumer to react to the new value, not just any change.  For example, the consumer might do something like this:
    $scope.$on('aa:calendar:set-date', valueChanged);
    function valueChanged(event, data) {
            if (data && data instanceof Date) $scope.internalValue = data;
    }

(I needed this on my site.)

no response from @adamalbrecht in years?


You might be interested in Grisu-Exact

Hello, I'm also the author of yet another floating-point format algorithm which I call Grisu-Exact (https://github.com/jk-jeon/Grisu-Exact), which originally started as a variant of Grisu but eventually evolved into something more than that.
It seems your implementations are super fast and I'm very impressed. Especially, I didn't know there already was an algorithm with the shortest and correct rounding guarantees, yet is faster than Grisu-Exact (Schubfach! I have no idea why Ryu got much more attention when Schubfach already have existed).  I've run a dtoa benchmark of your implementation of Schubfach and Ulf's implementation of Ryu together with my implementation of Grisu-Exact, and the result looks like the following.

(The benchmark might be not fair in the sense that Ryu and Grisu-Exact's string outputs are always in scientific format while yours seem to generate the shorter one between the fixed-point and scientific formats, though I'm not sure how much it might affect. My string generation routine is actually a copy of that of Ryu.)
So Schubfach is indeed faster than Grisu-Exact!
I would be very happy if you take a look at my algorithm and possibly add it into your benchmark.
I'm curious of several things:

Is there any key idea that enables your Grisu2 to be that crazy fast? Or is that a result of lots of small but cute tricks?
Does your implementation of Schubfach do something more than what the paper explains (in terms of performance optimizations), or does it pretty much just follow the paper in a straightforward manner?

Thanks!

This looks great! Thanks for letting me know!
Actually, this repository started out as an implementation of the Girsu2 algorithm. I have since tried to modify Grisu2 such that it always produces the shortest and correctly rounded output. But I failed miserably... Great to know someone else succeeded! =) So now this repository is intended to collect some other implementations and provide some benchmarks.
I will definitely have a look at your implementation! And I will definitely add Grisu-Exact to the benchmarks!
That being said, as you might have noticed, the bench directory currently does not contain the actual code I have used to produce the benchmarks... (And the Grisu2 implementation I have used for the benchmark, is a slightly modified version of the one in the src directory...) I'll try to find some time this weekend to work on this, so that anyone else can verify the results and compare different implementation. And to get the code up to date.

My Grisu2 implementation (the one which was used for the benchmarks) differs from the "usual" implementations in so far that the digits are generated as an unsigned integer, instead of ASCII digits. It then uses uses the same formatting procedure as the Ryu and Schubfach implementations. Another difference is the digit generation loop. It tries to generate 4, 3, 2, or 1, digit per loop. (I need to take a closer look into your implementation, but it seems that you're doing something very similar?) And it uses a slightly greater table to do so.

Schubfach indeed is amazing! The Schubfach implementation pretty much follows the paper. I'm using different constants though and slightly different approximations for the logarithms. The different constants enable some minor optimizations compares to the Java implementation in the paper. (Warning: all tests pass, but I don't have a complete proof that the different constants always work. The same is true for the Ryu implementation actually: Using slightly different constants allows to merge two code-paths in Ryu.)

The formatting procedure is actually cheating a little bit :-) I have chosen an output format specifically to print small integers as quickly as possible. So, for small integers the digit generation procedures might output integers which are divisible by 10. The digit generation procedure then does not need to remove these trailing zeros which the formatting procedure would need to add back.  Another optimization makes use of the buffer size. Using a somewhat larger buffer removes the need to call memcpy with a variable length. So all the dtoa implementations currently require an output buffer with a length >= 64 and up to 64 characters might actually be (temorarily) written to that buffer.

I have found that the header-only implementations usually result in slower code. Even if only used in a single .cpp file to generate the dtoa implementation. I'll try to update the implementations this weekend and provide the non-header-only version of Grisu2 which I have used for the benchmark.
I would be very happy if you could provide a PR with your Grisu-Exact implementation, which uses the same formatting procedures as the Ryu and Schubfach implementations.
Thanks again for letting me know! Great work!
PS:
I have found that always generating the output in scientific format doesn't really make much of difference. So I think that your benchmarks are fair. But because my formatting procedure is cheating a little bit, it is quite possible that your Grisu-Exact implementation is actually somewhat faster than Schubfach =)

I would be very happy if you could provide a PR with your Grisu-Exact implementation, which uses the same formatting procedures as the Ryu and Schubfach implementations.

No prob. It will not take too long to modify my implementation, except that I've never committed a PR and I'm not familiar with how things work so maybe I need some trial and errors.
Also, I'm actually planning to re-work on a new implementation of (maybe a variant of) Grisu2 based on lots of optimization tricks I came up with when working on Grisu-Exact. It currently is a low-priority thing to do for me right now, though. It would be interesting to compare it with your Grisu2 implementation if I somehow get to do it :)
FYI: there is another very fast Grisu2 implementation here: https://erthink.github.io/dtoa-benchmark/
I didn't compare it with mine, but according to what the author advertises, it seems the performance is comparable to that of Grisu-Exact. So I think your implementation should be faster than this, but might be worth running a benchmark with yours.

That being said, as you might have noticed, the bench directory currently does not contain the actual code I have used to produce the benchmarks... (And the Grisu2 implementation I have used for the benchmark, is a slightly modified version of the one in the src directory...) I'll try to find some time this weekend to work on this, so that anyone else can verify the results and compare different implementation. And to get the code up to date.

So maybe it is better for me to wait for you to work out before making a PR?

My Grisu2 implementation (the one which was used for the benchmarks) differs from the "usual" implementations in so far that the digits are generated as an unsigned integer, instead of ASCII digits. It then uses uses the same formatting procedure as the Ryu and Schubfach implementations. Another difference is the digit generation loop. It tries to generate 4, 3, 2, or 1, digit per loop. (I need to take a closer look into your implementation, but it seems that you're doing something very similar?) And it uses a slightly greater table to do so.

I skimmed over your implementation of Grisu2 and wow, the main idea looks quite similar indeed. Probably the biggest difference is that I chose alpha and gamma to be very close to each other in order to confine the search range of kappa (which of course unfortunately is the reason why I need a huge cache table). Thanks to that, I could completely remove the loop because the maximum number of required comparisons is small (5, for the case of double). Also, because of this, all integer divisions can be eliminated as all the divisors are now compile-time constants.
Another big difference is that I choose alpha and gamma to be fairly large in order to work mostly with integers rather than fractions. But it is interesting that with small alpha and gamma it is still possible to implement a trick (that 4, 3, 2, 1 thing) similar to what I did. Probably I need to look at yours more closely. Might be possible to find out some ideas that can be helpful to me.

Schubfach indeed is amazing! The Schubfach implementation pretty much follows the paper. I'm using different constants though and slightly different approximations for the logarithms. The different constants enable some minor optimizations compares to the Java implementation in the paper. (Warning: all tests pass, but I don't have a complete proof that the different constants always work. The same is true for the Ryu implementation actually: Using slightly different constants allows to merge two code-paths in Ryu.)

Let me ask you to clarify a bit more. So, by constants, do you mean the constants used for the approximations of the logarithms, or something else?

The formatting procedure is actually cheating a little bit :-) I have chosen an output format specifically to print small integers as quickly as possible. So, for small integers the digit generation procedures might output integers which are divisible by 10. The digit generation procedure then does not need to remove these trailing zeros which the formatting procedure would need to add back. Another optimization makes use of the buffer size. Using a somewhat larger buffer removes the need to call memcpy with a variable length. So all the dtoa implementations currently require an output buffer with a length >= 64 and up to 64 characters might actually be (temorarily) written to that buffer.

I honestly didn't clearly understand this. Could you elaborate more?
Also, I think by "formatting procedure" you mean generation of a human-readable string, and by "digit generation procedure" you mean finding a decimal representation of the floating-point number. Am I correct? (I guess perhaps these terminologies are coming from that once upon a time your implementation of Grisu2 actually did generate some sort of human-readable string directly, and then an additional "formatting procedure" polished it?)

I have found that the header-only implementations usually result in slower code. Even if only used in a single .cpp file to generate the dtoa implementation. I'll try to update the implementations this weekend and provide the non-header-only version of Grisu2 which I have used for the benchmark.

That sounds weird to me. I think header-only version should be usually faster (except when it isn't) because the compiler has more information for optimization.
Thanks for having a look at my work, and thanks for your great work as well!

The formatting procedure is actually cheating a little bit :-) I have chosen an output format specifically to print small integers as quickly as possible. So, for small integers the digit generation procedures might output integers which are divisible by 10. The digit generation procedure then does not need to remove these trailing zeros which the formatting procedure would need to add back. Another optimization makes use of the buffer size. Using a somewhat larger buffer removes the need to call memcpy with a variable length. So all the dtoa implementations currently require an output buffer with a length >= 64 and up to 64 characters might actually be (temorarily) written to that buffer.

I honestly didn't clearly understand this. Could you elaborate more?

Yeah, "digit generation procedure" is a very bad name to describe to core routine which converts from binary floating-point to decimal floating-point. Ryu, Schubfach, and Grisu-Exact, all compute a decimal floating-point in the form significand * 10^exponent and output the two integers significand and exponent. The "formatting procedure" then takes the pair (significand, exponent) as an input and converts it to the final output string, either in fixed or scientific form. (I hope this clarifies the unfortunate terminology a bit...)
Now, the algorithms detect if the input is a small integer in the range [1, 2^53] and in this case (the "fast path") simply return the significand and an exponent = 0. The significand here might contain trailing (decimal) zeros, though. E.g. for the input "1e+3" the output without the fast path would be (significand, exponent) = (1,3). With this optimization the output will be (1000, 0). This of course violates the "shortest output" condition. But it is ok if the "formatting procedure" will print all these small integers in fixed-point notation. Otherwise one would need to remove these trailing 0s in the "fast path", making the "fast path" somewhat slower.
The other thing is that the "formatting procedure" sometimes needs to insert a decimal point somewhere between the digits. Using a somewhat larger buffer, this functionality can be implemented slightly more efficiently.
Does this make more sense now?

Yub. Thanks for the explanation. It does not really look like a cheating to me though. If I really need to call it a cheating, I would say the digit generation procedure is a bit cheating rather than the formatting procedure :)

Let me ask you to clarify a bit more. So, by constants, do you mean the constants used for the approximations of the logarithms, or something else?

Yes, the constants used for the approximations of the logarithms. But also (and probably more importantly) the cached powers-of-ten. As you know, these are approximated in the form 10^k ~= f * 10^e, where 2^bits <= f < 2^(bits+1) is an integer. The difference is how f is obtained. Write 10^k == x * 10^e, where x is a real number 2^bits <= x < 2^(bits+1). The paper then uses f = floor(x) + 1 (Ryu also uses f = floor(x) if k < 0 - or if k > 0 - I don't remember right now...). My implementation always uses f = ceil(x).
This allows to merge two different code paths in the Ryu implementation.
For the Schubfach implementation this is used only because I once wanted to reuse the cache from the Ryu implementation. But I should probably use the constants as defined in Schubfach paper, since the implementations currently are completely independent.
The problem is: I do not have a complete proof, whether it is actually allowed to always use f = ceil(x) ;-)
I just quickly skimmed through your Grisu-Exact paper and, of course, you know the details already. Proving that ceiling always works should be a (minor?) modification to the proof in section 4 of your paper?

That being said, as you might have noticed, the bench directory currently does not contain the actual code I have used to produce the benchmarks... (And the Grisu2 implementation I have used for the benchmark, is a slightly modified version of the one in the src directory...) I'll try to find some time this weekend to work on this, so that anyone else can verify the results and compare different implementation. And to get the code up to date.

So maybe it is better for me to wait for you to work out before making a PR?

I just started to import your Grisu-Exact version. I have removed some C++20 constructs, to get the code running. I have some failing tests, though. This is because Grisu-Exact seems to generate a decimal significand with 18 decimal digits in some cases. (I need to double check that my modifications are correct...)
Here is a number which generates 18 decimal digits (using my modified implementation): 1.4411518807585586e+17.
Can you verify this? Or am I doing something wrong?

I just started to import your Grisu-Exact version. I have removed some C++20 constructs, to get the code running.

Oh god, I just realized that std::remove_cvref_t<T> is a C++20 constructs. I'll replace it with std::remove_cv_t<std::remove_reference_t<T>>. Is there anything else?

As you know, these are approximated in the form 10^k ~= f * 10^e, where 2^bits <= f < 2^(bits+1) is an integer.

I think you mean 10^k ~= f * 2^e.

The problem is: I do not have a complete proof, whether it is actually allowed to always use f = ceil(x) ;-)

Could you elaborate on how you can possibly merge two paths by doing that? (Frankly, I did not look at Ryu so carefully except for the min-max Euclid algorithm which is also relevant to mine, so this might be a dumb question; please forgive me if it is😏)
My first impression is that it should not be a surprise if f = ceil(x) would fail. Anyway, I can imagine an algorithm to verify the validity, applying the min-max Euclid algorithm.
Since your x is always a non-integer (except for some trivial cases), floor and ceil should differ by 1. Hence, the case e2>=0 is never a problem. (Lemma 3.3 in Ulf's paper; Lemma 4.1 in my paper). So we only need to look at the case e2<0. (Lemma 3.4 in Ulf's paper; Lemma 4.2 in my paper). Now, following the notation of Lemma 3.4 in Ulf's paper, let us write
w * floor(5^(-e2-q)/2^k) = s * 2^(q-k) + t

for some 0 <= t < 2^(q-k).
(I believe q=floor(-e2 * log5(2)) in the paper should be a typo. I think q=floor(-e2 * log10(5)) should be the correct one.)
Now, by construction, the maximum possible value of w is (maybe) 2^55-2. Hence, we need to check if the remainder t cannot exceed 2^(q-k) - 2^55 + 1 when w varies from 0 to 2^55-2. The min-max Euclid algorithm can be used here. Technically speaking the algorithm itself only works when floor(5^(-e2-q)/2^k) is an odd number, but it is not a big problem because we can factor out all powers of 2 from floor(5^(-e2-q)/2^k) before running the algorithm and modify the bound on t appropriately. A proper modification of min-max Euclid algorithm should also give us a way to compute a counterexample if any. Then we can directly test those counterexamples if the whole algorithm still works for them. (But I think it will be more difficult to come up with a way to compute all counterexamples, so even if the test passes it would not mean that the whole algorithm is correct, if there is at least one counterexample.)

@jk-jeon Nevermind... Grisu-Exact is working fine... was my mistake.

Phew! it was a close call!

First of all, sorry for the delay, but I have been quite busy the last weeks...

Could you elaborate on how you can possibly merge two paths by doing that? (Frankly, I did not look at Ryu so carefully except for the min-max Euclid algorithm which is also relevant to mine, so this might be a dumb question; please forgive me if it is😏)

That's not a dumb question at all. I had in mind that adjusting the constants was neccessary to merge the two code paths (there are two paths in the upstream implementation where similar products of the form x * 5^m / 2^n are computed, one for e2 >= 0, one for e2 < 0). But I was wrong. The constants now match the ones defined in the Ryu paper. And I have a much better feeling now ;-) So thanks for asking. (Maybe it didn't matter because I was using 128 bits for the constants, instead of the minimum of 125 bits... But I don't know.)
I have found a bug in the Schubfach implementation (in previously unused code, though) and have commited a few other minor improvements.
I will add a Grisu-Exact benchmark as soon as possible. Here are some preliminary results. The benchmark only measures the binary to decimal conversion (no to-string conversion, no formatting) for numbers of the form N * 10^E, where N is an integer with len(N) decimal digits.
Grisu-Exact:

Ryu:

Grisu-Exact and Ryu look quite similar in this particular benchmark. Grisu-Exact looks slightly better, though, because it has a smaller worst-case runtime than Ryu and seems to be slightly faster for small integers. (The benchmark has been run without the "small integer optimization" we talked about earlier.)
Thanks again for letting me know! Great work!

Grisu-Exact and Ryu look quite similar in this particular benchmark. Grisu-Exact looks slightly better, though, because it has a smaller worst-case runtime than Ryu and seems to be slightly faster for small integers. (The benchmark has been run without the "small integer optimization" we talked about earlier.)

It seems Ryu performs better for long digits cases, though? Given your picture, it seems Ryu might have better performance for uniformly random data.
I made some improvement in last several weeks, so please update to the recent one.
I've also run a new benchmark against your recent Schubfach implementation. This time I used your to-string implementation, so I guess it is more fair than the previous benchmark. Here is the result:
Uniformly random data (binary32):

Random data with given number of digits (binary32):

Uniformly random data (binary64):

Random data with given number of digits (binary64):

So, for binary32, your Schubfach clearly wins. For binary64, Grisu-Exact seems to perform better for some small digit cases, but overall Schubfach wins.
Scubfach is great, and your work is great!

Wow, you implemented Dragonbox!
Your optimization is really impressive, I couldn't expect it can be made 5-10ns faster! Yeah, I remember you said your digit formatting routine is a bit of cheating, but it's still great:) Thanks for working on it.
Small question: it seems you didn't implement optimized divisions by 1000 and 100. Did you have a benchmark and concluded that it doesn't worth implementing them, or just skipped them for other reasons?

Wow, you implemented Dragonbox!

Well, it is still your implementation. I have just removed a bit of code :-) And possibly introduced some bugs ;-)

it seems you didn't implement optimized divisions by 1000 and 100

Any decent compiler already optimizes divisions by compile-time constants quite well. And I wanted the code to be as clean as possible, because I didn't even read your paper yet ;-) I do not have any actual benchmarks.
Now Dragonbox really is amazing! Formatting double-precision floating-point numbers in JavaScript-style in ~15-25ns is just... wow! Thanks for your great work!!
I ran out of time the last weekend, but I hope to find some more time the next weekend to open a PR in your repository with the optimized formatting-procedure. (I understand that you're focused on the binary->decimal part, but I think it would still be a nice addition to your library.)

Any decent compiler already optimizes divisions by compile-time constants quite well. And I wanted the code to be as clean as possible, because I didn't even read your paper yet ;-) I do not have any actual benchmarks.

It is simply impossible to implement division-by-1000 as one multiplication plus one shift, but in our case it is possible because we are not using the full range of 64-bit integers. Compilers these days can't figure out such a thing.
For the case of division-by-100, what I've done is to compute the quotient and check divisibility with one multiplication (rather than two, which is the usual case if we compute both the quotient and the remainder). This was also possible because we are only using very limited range of numbers. I'm pretty sure compilers can never do that. But this also introduces some branches and some logical operations so it might end up being slower. When I first came up with this optimization, I got some nice speed-up, but I don't know it will still be the case for the final code we have now.
Note that in modern x86 machines 32-bit multiplication is indeed very fast (but it's still slower than additions, for example), but that's only the case for what I call half multiplication in my paper; that is, computing the lower 32-bits only and discard the high 32-bits.. But in order to perform the division it is usually necessary to perform full multiplication, that is, it is necessary to compute the high 32-bits, thus it just ends up performing a 64-bit multiplication, which is horribly slow. So I believe manual optimization of the division will certainly be beneficial here. What's I'm not sure about is if what I've done is optimal. It can be that checking the divisibility by just performing a plain 32-bit multiplication is indeed not a big deal.

I ran out of time the last weekend, but I hope to find some more time the next weekend to open a PR in your repository with the optimized formatting-procedure. (I understand that you're focused on the binary->decimal part, but I think it would still be a nice addition to your library.)

Such a PR would be great!!
If you have time, I want you to consider contributing on optimizing fmt's floating-point formatting routine. fmt has adapted Dragonbox recently, and it is currently cutting out trailing zeros at the binary-to-decimal conversion stage with my method, which seems to be a lot slower than your method ;) fmt's string generation procedure is indeed intertwined with lots of other higher-level formatting stuffs so it should be harder than just writing your own, but it would be a valuable contribution.

It is simply impossible to implement division-by-1000 as one multiplication plus one shift, but in our case it is possible because we are not using the full range of 64-bit integers. Compilers these days can't figure out such a thing.

You're right. The usual technique uses two shifts and one multiplication. So your technique might indeed be a little bit fast.

For the case of division-by-100, ...

I've tried your approach, but it seems to be slightly slower (at least in my slightly modified implementation). Since we're working with 32-bit integers here, the standard method only uses one 64-bit and one 32-bit multiplication. Both operations are fast on 64-bit platforms. I have not tested this, but I suspect your method to be (much) faster on 32-bit platforms.

Such a PR would be great!!

This is still on my to-do list, but it may take while. Now if you have the time, you could just copy the FormatDigits implementation from the schubfach.cpp's into your to_chars implementation. It is probably easier for you to do this, than for me, since you certainly know your code better ;-)

I've tried your approach, but it seems to be slightly slower (at least in my slightly modified implementation). Since we're working with 32-bit integers here, the standard method only uses one 64-bit and one 32-bit multiplication. Both operations are fast on 64-bit platforms.

Well, that's interesting, because my impression is that 64-bit multiplication is indeed slow, in a way that the overall performance is mainly determined by the number of 64-bit multiplications the whole procedure performs. If I recall correctly, it was indeed about 2 times slower than the 32-bit counterpart in modern x86-64 machines. The thing is, we can at least replace the 64-bit multiplication into a 32-bit one because the range of numbers is very limited (which is something the compiler has no idea about), and I believe it will certainly boost the performance. What I was not sure about is whether it is worth or not introducing a branch and bunch of other operations in order to eliminate yet another 32-bit multiplication for the remainder calculation.
Anyway, I was just curious if you have measured the time difference. There is nothing wrong about your code I believe. Thanks for answering!


Add and fire player destroying events

This allows consumers to know when the player is beginning teardown.

destroy() is not an async function, either it won't be called internally inside mpegts.js. I don't think this is necessary.

I don't understand why destroy being synchronous affects whether or not an event should be emitted?
This allows a consumer to do something like this.
const loadSourceOnPlay = () => this.mpegtsInstance.load();

this.nativeElement.addEventListener('play', loadSourceOnPlay, {
  once: true,
});

// clean up listener if something causes the instance to teardown before
// the user clicks on the play button
this.mpegtsInstance.on(Mpegts.Events.DESTROYING, () => {
  this.nativeElement.removeEventListener('play', loadSourceOnPlay);
});

It would be useful for my custom element so I can cleanup my events.

@evoactivity
Oh, it sounds meaningful.
It has been merged. Thanks!
Sorry for my late reply.