Actually, I accidentally set the mode to ECHO above which was why it seemed to work, my apologies

Naively peeking does't work properly since the next() call to the stdin bytes iterator seems to block, so I'm peeking an empty buffer and then missing all the events until a key is in the input buffer. Pherhaps it could block before peeking until a key is found to try to ensure we don't miss any events

I bumped it to 1.36 which seems to be what parking_lot uses in its CI https://github.com/Amanieu/parking_lot/blob/master/.github/workflows/rust.yml#L19

Oh, it seems smallvec is now breaking on cosnt generics https://travis-ci.org/github/Amanieu/seqlock/jobs/738652796#L240

Done! I skimmed the readme and didn't see any explicit mention of a MSRV to update

I used 1.31 which I think is the first rust 2018 edition which I think is required for smallvec since it's using use crate:: (2018 edition mentions use changes here and this was the travis run that broke despite having the AtomicUsize method that was previously crashing)

I've got a proof of concept of the peeking approach here: https://github.com/nico-abram/kibi/commit/434b355e798030efa2354931765e3e2c6e401962

Would have to dig around std to make sure a buffer of 1024 events is enough to ensure we never peek less events than std reads, but the bigger issue is it seems setting the mode to ENABLE_WINDOW_INPUT broke the way kibi was detecting ctrl

I'm no expert on windows console APIs, but after a bit of googling this is what I found:

According to https://docs.microsoft.com/en-us/windows/console/console-input-buffer#buffer-resizing-events

Buffer-resizing events are placed in the input buffer if the console's input mode is set to ENABLE_WINDOW_INPUT (that is, the default mode is disabled).

If the input event is a buffer-resizing event, the Event member of INPUT_RECORD is a WINDOW_BUFFER_SIZE_RECORD structure containing the new size of the console screen buffer, expressed in character-cell columns and rows.

If the user reduces the size of the console screen buffer, any data in the discarded portion of the buffer is lost.

Changes to the console screen buffer size as a result of application calls to the SetConsoleScreenBufferSize function are not generated as buffer-resizing events.

When we look at that mode in https://docs.microsoft.com/en-us/windows/console/setconsolemode it says:

Information about these events can be read from the input buffer by applications using the ReadConsoleInput function, but not by those using ReadFile or ReadConsole.

And a cursory glance at std seems to indicate it is using ReadConsoleW (https://github.com/rust-lang/rust/blob/ebc03f7c80a7ab8cdf95c0ddc31b57e065906a13/library/std/src/sys/windows/stdio.rs#L220)

By briefly looking at kibi, it seems to be reading stdin using std (https://github.com/ilai-deutel/kibi/blob/master/src/editor.rs#L216) so we might have to replicate the std behaviour here using ReadConsoleInput instead for windows which involves utf16->utf8, and it is also "fixing up surrogates"

I have not really actually tested any of this much yet, if/when I do I will comment here

CI seems to fail for the same reason as https://github.com/Amanieu/seqlock/pull/1#issuecomment-322674372

Force pushed trailing newline and missing type declaration in non windows because of the if cfg!

Yup! That seemed to do it, just updating the parking_lot in seqlock to 0.11 and patching the benchmark crate to use that fixed it (seqlock itself required no changes to compile, at least on windows)

Opened a pull request https://github.com/Amanieu/seqlock/pull/5

Fixes https://github.com/Amanieu/parking_lot/issues/255

Thanks! Solved

Here's the output from

cargo tree

tree.txt

Seems to actually come from SeqLock, not std, you're right

I ran it using the master branch, I think the older version is from std

Since I saw you had pthreads in the benchmarks I figured it would make sense to add windows slim rwlocks to it too

It seems std uses srwlocks internally, but it might still make sense to add this since

1. std could change in the future
2. It has a fallback for windows xp which looks like it would possibly have some runtime overhead (Even if perfectly predicted the branch could still degrade performance since it would take a spot in the branch predictor right?)
3. I see you also have pthread implementations in the benchmarks despite std using pthreads internally

With regards to point (2), I see non trivial differences between srwlock and std in an uncontended case:

Running the benchmark with the following command on windows

cargo run --release --bin rwlock -- 2 1 1 0 1 2 2>&1 > bt.txt

Panics within what seems to be the parking_lot inside std with the message "Could not get module handle for ntdll.dll"

I'm attaching the RUST_BACKTRACE=full output

bt.txt

Buenas!

1. plato_listo: comanda debe pasar a swap todas las paginas del pedido que vaya iterando mientras busca el nombre del plato? Esa lectura actualiza el timestamp de ultimo uso para el cache LRU? Cuando el plato llega a la cantidad total, y se itera a ver si estan todos los platos del pedido listos para cambiar el estado del pedido, se actualiza el timestmap de los platos?

2. obtener_pedido: Que hace comanda si no encuentra el pedido? (Estoy devolviendo un estado extra "INVALIDO")

3. obtener_pedido: Comanda actualiza el timestamp de todos los platos en el pedido?

4. guardar_plato: Se puede hacer si el estado es PENDIENTE? (Osea, no confirmado)

5. finalizar_pedido: Comanda debe verificar que el estado sea TERMINADO?

6. Hay algun requerimiento en como resolvemos temas de concurrencia en comanda? O seria valido tener un gran mutex para todo que se lockie y deslockie cuando se maneja cada mensaje?

Buenas! Gracias, cierro issue

Hola Damian! Gracias por las respuestas

Creo que pregunte mal la pregunta 1: Quize decir pasar a memoria principal desde swap de ser necesario, ya que para leer el nombre del plato tiene que acceder a los datos de la pagina, un caso similar al de la pregunta 3 que necesitaria leer

Sobre la 4, entonces habria que validar que este en estado pendiente el pedido?

Sobre la 6: Si, pasa que estuve viendo masomenos como encarar ese tema y agregaba mucha complejidad. Era mas que nada para saber si llegamos a tener una solucion que masomenos funciona si hacer algo asi era razon como para desaprobrar el TP

Saludos!

Hola Damian! Gracias por las respuestas

Creo que pregunte mal la pregunta 1: Quize decir pasar a memoria principal desde swap de ser necesario, ya que para leer el nombre del plato tiene que acceder a los datos de la pagina, un caso similar al de la pregunta 3 que necesitaria leer

Sobre la 4, entonces habria que validar que este en estado pendiente el pedido?

Sobre la 6: Si, pasa que estuve viendo masomenos como encarar ese tema y agregaba mucha complejidad. Era mas que nada para saber si llegamos a tener una solucion que masomenos funciona si hacer algo asi era razon como para desaprobrar el TP

Saludos!

1. plato_listo: comanda debe pasar a swap todas las paginas del pedido que vaya iterando mientras busca el nombre del plato? Esa lectura actualiza el timestamp de ultimo uso para el cache LRU? Cuando el plato llega a la cantidad total, y se itera a ver si estan todos los platos del pedido listos para cambiar el estado del pedido, se actualiza el timestmap de los platos?

2. obtener_pedido: Que hace comanda si no encuentra el pedido? (Estoy devolviendo un estado extra "INVALIDO")

3. obtener_pedido: Comanda actualiza el timestamp de todos los platos en el pedido?

4. guardar_plato: Se puede hacer si el estado es PENDIENTE? (Osea, no confirmado)

5. finalizar_pedido: Comanda debe verificar que el estado sea TERMINADO?

6. Hay algun requerimiento en como resolvemos temas de concurrencia en comanda? O seria valido tener un gran mutex para todo que se lockie y deslockie cuando se maneja cada mensaje?

Puede ser que al declarar la variable en el .h incluido de ambos archivos se esten declarando 2 variables globales separadas con el mismo nombre?

Capaz hay que declararla como "extern list_t* lista_pbcs;" y en un solo .c definir la variable "list_t* lista_pcbs;"

No estoy seguro igual, disculpa si estoy diciendo cualquiera

Suerte!

Buenas!

Venia a hacer la misma consulta, abro otro issue ya que este esta cerrado?

Buenas!

Tenia un par de dudas sobre algunos mensajes

1. Seleccionar restaurante: Que seria el "cliente" que recibe? Se podria identificar a un cliente como la conexion por la que llega el mensaje y no tener ese campo?
2. Consultar pedido: Que seria "estado"? Pendiente (Agregando platos), Confirmado (En progeso) y Terminado (Todos los platos listos)? Para estar seguro porque tambien hay "estados" de la planificación
3. Obtener Pedido: No deberia retornar el estado? Creo que la app podria inferir si esta cocinado el pedido con las cantidades, pero no tendria manera de saber si esta Pendiente o Confirmado si no lo recibe de comanda, si es que entendi bien

Gracias y que tengan un buen domingo!

Muchas gracias! Cierro issue, buena semana!

Buenas!

Tenia un par de dudas sobre algunos mensajes

1. Seleccionar restaurante: Que seria el "cliente" que recibe? Se podria identificar a un cliente como la conexion por la que llega el mensaje y no tener ese campo?
2. Consultar pedido: Que seria "estado"? Pendiente (Agregando platos), Confirmado (En progeso) y Terminado (Todos los platos listos)? Para estar seguro porque tambien hay "estados" de la planificación
3. Obtener Pedido: No deberia retornar el estado? Creo que la app podria inferir si esta cocinado el pedido con las cantidades, pero no tendria manera de saber si esta Pendiente o Confirmado si no lo recibe de comanda, si es que entendi bien

Gracias y que tengan un buen domingo!

Buenas!

Queria dejar comentado que el intellisense me da un error cuando uso extensiones de GCC como "nested functions" que estan buenas para algunas cosas (Especialmente para las funciones de iterar/etc de las common para colecciones que reciben punteros a funcion, no solo para tenerlas en el lugar de uso sino tambien por el "lexical scoping")

Entiendo que incluso con el vscode mas reciente no hay solucion (Por lo que vi en este issue https://github.com/Microsoft/vscode-cpptools/issues/1035 ), pero capaz alguien sabia algo

Por ahora me estuve manejando usando C estandar sin la extension porque son muy molestos los errores

Does virtualbox work side-by-side with WSL2 in the latest test versions, on windows 10 HOME (Which if I recall correctly cannot use hyper-v or something) ?

Me parece que lo que comente arriba me anduvo, fue esto lo que hice:

sudo apt install glibc-source
cd /usr/src/glibc
sudo tar xvf glibc-2.23.tar.xz

Y en el launch.json de cada modulo:

            "sourceFileMap": {
                "/build/glibc-ViVLyQ": "/usr/src/glibc"
            },

No se si el hash y la version seran los mismos para todos, me imagino que si al usar la misma vm, si no la actualizaron

Tampoco estoy seguro de que me lo arreglo, pero ya debugie y modifique archivos y no vi el cartelito que veia antes

Looks good to me

That seems perfect to me, it's behind and more or less explains both -i and --stage

Maybe. I'm not sure skipping ahead to the next chapter would be better, and this is certainly better than the broken link. Anyone curious will probably keep on reading and reach the next chapter

This fixes the broken link, but it still seems slightly confusing to me

The paragraph says:

As documented above, this will build a functional stage1 compiler as part of running all stage0 commands (which include building a std compatible with the stage1 compiler) as well as the first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1) builds std".

But there is no mention of stage1 or 0 in the linked-to section, and also no mention of "-i"

Buenas!

A mi tambien me estuvo tirando errores simialres pero no tuve problema ignorandolos, me parece que es que el intellisense/debugger buscan el codigo fuente de las bibliotecas estandar (especificamente glibc) de C y no lo encuentran

Capaz se puede hacer algo parecido a lo que recomienda este comentario: https://github.com/microsoft/vscode-cpptools/issues/811#issuecomment-521187568 Pero con la version y el path que te muestra. Pero no lo probe

1. Que tan unico debe ser el id de pedido generado cuando no hay restaurantes? Osea, solo debe ser unico durante una ejecucion o tiene que mantenerse unico a traves de multiples ejecuciones? De necesitar mantenerse unico a traves de multiples ejecuciones, donde tendriamos permitido almacenar algo de estado para hacerlo?

2. Estaria permitido que Consultar Pedido del modulo App reciba el id de pedido?

3. En el ejemplo de archivo de configuracion de este modulo me resulto raro lo siguiente: ejemplo configuracion app: PLATOS_DEFAULT, TIEMPO_DE_DESCANSO, FRECUENCIA_DE_DESCANSO, REPARTIDORES figuran como listas en los tipos pero no son listas en el ejemplo. Porque seria esto?

1. Habria 1 solo cliente en el sistema? Nunca va a haber mas de uno? Esto es lo que me dio a entender el enunciado pero me parecio raro que haya un solo "cliente"

2. En la configuracion del modulo cliente veo solo 1 ip/puerto de restaurante. Pero segun entiendo habria N procesos restaurantes en el sistema. Como seria la conexion?

Buenas!

Muchas gracias Dami, abrazo

Buenas!

Es lo que comente en el issue del foro

Muchisimas gracias!

Yo tuve algunos problemas, pero con hacer dos cosas parece que me anda todo joya ahora:

• Actualizar el vscode a la version mas reciente (La mas mas reciente no se puede porque ya no soporta 32bit, la que paso es la ultima de 32bit) https://code.visualstudio.com/updates/v1_35 (Es el .deb, es nomas abrirlo con el package manager y se actualiza)
• Cambiar "intelliSenseMode": "clang-x64" por clang-86 (Para que sea de 32bits en vez de 64) en los archivos c_cpp_properties.json de las carpetas .vscode

Tuve que cerrarlo y abrirlo un par de veces y me parece que actualizo unas cosas de la extension de C++

Otra cosa es que pueden hacer que compile automaticamente cuando debugean, es nada mas agregar esta linea en los launch.json

"preLaunchTask": "Make",

Y este objeto en el array en los archivos tasks.json:

        {
            "label": "Make",
            "type": "shell",
            "command": "make",
            "problemMatcher": [
                "$gcc"
            ]
        },

Y un tip mas: Si quieren que se formatien automaticamente los archivos cuando los guardan, pueden apretar ctrl+shift+p, se abre una barra, buscan preferences UI se abre una ventana, ahi buscan "format" y tildan "format on save" O pueden abrir el JSON de preferences y agregar esta linea:

"editor.formatOnSave": true

Just ran into this same problem

Thank you @abcping123 that fixed it!

I ran into this, spent a good while trying to find out what it was, had to reboot to get it to work and now wsl2 doesn't work

I'm also running windows 10 home so I don't think I can use "Windows Hypervisor Platform"

This is annoying because the reason I initially got wsl2 was because I needed it for docker, since I couldnt use hyper-v because of windows 10 home

1. Que tan unico debe ser el id de pedido generado cuando no hay restaurantes? Osea, solo debe ser unico durante una ejecucion o tiene que mantenerse unico a traves de multiples ejecuciones? De necesitar mantenerse unico a traves de multiples ejecuciones, donde tendriamos permitido almacenar algo de estado para hacerlo?

2. Estaria permitido que Consultar Pedido del modulo App reciba el id de pedido?

3. En el ejemplo de archivo de configuracion de este modulo me resulto raro lo siguiente: ejemplo configuracion app: PLATOS_DEFAULT, TIEMPO_DE_DESCANSO, FRECUENCIA_DE_DESCANSO, REPARTIDORES figuran como listas en los tipos pero no son listas en el ejemplo. Porque seria esto?

1. Habria 1 solo cliente en el sistema? Nunca va a haber mas de uno? Esto es lo que me dio a entender el enunciado pero me parecio raro que haya un solo "cliente"

2. En la configuracion del modulo cliente veo solo 1 ip/puerto de restaurante. Pero segun entiendo habria N procesos restaurantes en el sistema. Como seria la conexion?

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Bumps bcrypt from 4.0.1 to 5.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/kelektiv/node.bcrypt.js/releases">bcrypt's releases</a>.</em></p> <blockquote> <h2>v5.0.0</h2> <ul> <li>Fix the bcrypt "wrap-around" bug. It affects passwords with lengths >= 255. It is uncommon but it's a bug nevertheless. Previous attempts to fix the bug was unsuccessful.</li> <li>Experimental support for z/OS</li> <li>Fix a bug related to NUL in password input</li> <li>Update <code>node-pre-gyp</code> to 0.15.0</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/kelektiv/node.bcrypt.js/blob/master/CHANGELOG.md">bcrypt's changelog</a>.</em></p> <blockquote> <h1>5.0.0 (2020-06-02)</h1> <ul> <li>Fix the bcrypt "wrap-around" bug. It affects passwords with lengths >= 255. It is uncommon but it's a bug nevertheless. Previous attempts to fix the bug was unsuccessful.</li> <li>Experimental support for z/OS</li> <li>Fix a bug related to NUL in password input</li> <li>Update <code>node-pre-gyp</code> to 0.15.0</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/61139e6bbe6afe9c2c2a0dbdfe8f5e6a7b746a67"><code>61139e6</code></a> v5.0.0</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/1bde62c241ac42642b3adf3b94e980fc5f0aff1a"><code>1bde62c</code></a> Update node-pre-gyp to 0.15.0</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/40770d62814d29a3204d7efa85c05774b3a274cf"><code>40770d6</code></a> Add NodeJS 14 to appveyor CI</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/5916a468f32e8d56518c0f222cf5581f37aea825"><code>5916a46</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/kelektiv/node.bcrypt.js/issues/807">#807</a> from techhead/known_length</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/f28e916fc4de51bf7afcd9d5e48c9c6ff2659eac"><code>f28e916</code></a> Reword comment</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/ca1e43b6fcba5376276293fedbf1731806936d70"><code>ca1e43b</code></a> Add test for embedded NULs</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/1a8185828b70ed5f3bbf83846d4a05e6dc589b83"><code>1a81858</code></a> Pass key_len to bcrypt(). Fix for issues <a href="https://github-redirect.dependabot.com/kelektiv/node.bcrypt.js/issues/774">#774</a>, <a href="https://github-redirect.dependabot.com/kelektiv/node.bcrypt.js/issues/776">#776</a></li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/cf4efd9b3bfdb2b1c15fe9669d74a77db153f6ca"><code>cf4efd9</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/kelektiv/node.bcrypt.js/issues/647">#647</a> from ilatypov/master</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/15febd13b2b4cefbed9c45f6a863bdfcaca8b58d"><code>15febd1</code></a> Allow using an enterprise artifactory.</li> <li><a href="https://github.com/kelektiv/node.bcrypt.js/commit/96c41e2ce1ae9ac7d5451d991eff7270803c74f2"><code>96c41e2</code></a> Mark z/OS compatibility code as such</li> <li>Additional commits viewable in <a href="https://github.com/kelektiv/node.bcrypt.js/compare/v4.0.1...v5.0.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

If I recall correctly, if something somehow panics inbetween, ManuallyDrop wont run drop but the forget alternative would