Problems connecting nmea_topic_driver or nmea_serial_driver with Velodyne GPS

Intro
Hi,
I am using the ROS nmea_navsat_driver in combination with the Velodyne gps_imu_driver. The latter is still in development on their github page (https://github.com/ros-drivers/velodyne/tree/gps_imu). I tried connecting directly via nmea_serial_driver and also with nmea_topic_driver. Each approach returns different problems.
I am using Ubuntu 20.04 with ROS noetic and Velodyne VLP16 Puck Lite with its GPS receiver. The frame of the Velodyne data is "vlp201". gps_imu_driver publishes the topics:
/vlp1/gpsimu_driver/gpstime,
/vlp1/gpsimu_driver/imu_data
/vlp1/gpsimu_driver/nmea_sentence
/vlp1/gpsimu_driver/temperature.
It would be great if the solution with nmea_serial_driver works. But if the detour with nmea_topic_driver works, that is also fine.
Problems
nmea_topic_driver
When starting the nmea_topic_driver the following warning comes:
[WARN] [1645014343.272357]: Value error, likely due to missing fields in the NMEA message. Error was: invalid literal for int() with base 10: ''. Please report this issue at github.com/ros-drivers/nmea_navsat_driver, including a bag file with the NMEA sentences that caused it.
Here are 5 example of GPS information that are returned by the  Velodyne gps_imu_driver:
rostopic echo -n5 /vlp1/gpsimu_driver/nmea_sentence
header:
 seq: 5211
 stamp:
   secs:<PHONE_NUMBER>
   nsecs: 377551132
 frame_id: "vlp201"
sentence: "$GPRMC,122604,A,4951.7258,N,00840.7584,E,000.0,253.1,160222,001.8,E,D*17"
---
header:
 seq: 5212
 stamp:
   secs:<PHONE_NUMBER>
   nsecs: 379002107
 frame_id: "vlp201"
sentence: "$GPRMC,122604,A,4951.7258,N,00840.7584,E,000.0,253.1,160222,001.8,E,D*17"
---
header:
 seq: 5213
 stamp:
   secs:<PHONE_NUMBER>
   nsecs: 388485598
 frame_id: "vlp201"
sentence: "$GPRMC,122604,A,4951.7258,N,00840.7584,E,000.0,253.1,160222,001.8,E,D*17"
---
header:
 seq: 5214
 stamp:
   secs:<PHONE_NUMBER>
   nsecs: 398776555
 frame_id: "vlp201"
sentence: "$GPRMC,122604,A,4951.7258,N,00840.7584,E,000.0,253.1,160222,001.8,E,D*17"
---
header:
 seq: 5215
 stamp:
   secs:<PHONE_NUMBER>
   nsecs: 400211660
 frame_id: "vlp201"
sentence: "$GPRMC,122604,A,4951.7258,N,00840.7584,E,000.0,253.1,160222,001.8,E,D*17"

nmea_serial_driver
When starting the nmea_serial_driver the following fatal error comes:
started roslaunch server http://localhost:32865/

SUMMARY
========

PARAMETERS
 * /nmea_serial_driver_node/baud: 19200
 * /nmea_serial_driver_node/frame_id: gps_velo
 * /nmea_serial_driver_node/port: /dev/ttyS1
 * /nmea_serial_driver_node/time_ref_source: gps_velo
 * /nmea_serial_driver_node/useRMC: False
 * /nmea_serial_driver_node/use_GNSS_time: False
 * /rosdistro: noetic
 * /rosversion: 1.15.14

NODES
  /
    nmea_serial_driver_node (nmea_navsat_driver/nmea_serial_driver)

auto-starting new master
process[master]: started with pid [20618]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 9edd4b22-8f34-11ec-8d55-711616ef9e18
process[rosout-1]: started with pid [20628]
started core service [/rosout]
process[nmea_serial_driver_node-2]: started with pid [20635]
[FATAL] [1645021671.616954]: Could not open serial port: I/O error(None): None
[nmea_serial_driver_node-2] process has finished cleanly
log file: /home/deepforest/.ros/log/9edd4b22-8f34-11ec-8d55-711616ef9e18/nmea_serial_driver_node-2*.log
^C[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Further information
The launch file for the nmea_serial_driver is written as follows. For the nmea_topic_driver is written below within the commenting tags.
<launch>

  <!-- Adjusted from default nmea_serial_driver.launch file +++ in development +++ -->

  <arg name="port" default="/dev/ttyS1" />
  <arg name="baud" default="19200" />
  <arg name="frame_id" default="gps_velo" />
  <arg name="use_GNSS_time" default="False" />
  <arg name="time_ref_source" default="gps_velo" />
  <arg name="useRMC" default="False" />

  <node name="nmea_serial_driver_node" pkg="nmea_navsat_driver" type="nmea_serial_driver" output="screen">
    <param name="port" value="$(arg port)"/>
    <param name="baud" value="$(arg baud)" />
    <param name="frame_id" value="$(arg frame_id)" />
    <param name="use_GNSS_time" value="$(arg use_GNSS_time)" />
    <param name="time_ref_source" value="$(arg time_ref_source)" />
    <param name="useRMC" value="$(arg useRMC)" />
  </node>
<!--

  <arg name="time_ref_source" default="/vlp1/gpsimu_driver/gpstime" />
  <arg name="useRMC" default="True" />

  <node name="nmea_topic_driver" pkg="nmea_navsat_driver" type="nmea_topic_driver" output="screen">
    <param name="time_ref_source" value="$(arg time_ref_source)" />
    <param name="useRMC" value="$(arg useRMC)" />
  </node>

-->

</launch>

What I tried
I changed the port name and baud number. I gave access to the port 2368/tcp of the velodyne and change owner of the /dev/ttyS0 and /dev/ttyS1.
I am very grateful for any idea of what the problem could be. Forgive me, if I forgot some important information.
Many thanks in advance for your help!

Hi,
thank you for your response.
I don't think the problem is with the device connected, because the ROS Velodyne topics work fine.
I figured, that I should rather use nmea_socket_driver when the connection is via ethernat and not USB, which is not in the ros.org documentation.
The log I get is the following now:

started roslaunch server http://localhost:39423/

SUMMARY
========

PARAMETERS
 * /nmea_socket_driver/ip: <IP_ADDRESS>
 * /nmea_socket_driver/port: 2368
 * /rosdistro: noetic
 * /rosversion: 1.15.14

NODES
  /
    nmea_socket_driver (nmea_navsat_driver/nmea_socket_driver)

auto-starting new master
process[master]: started with pid [20714]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to be6df530-9002-11ec-bcb0-b7a3bcf93d6b
process[rosout-1]: started with pid [20724]
started core service [/rosout]
process[nmea_socket_driver-2]: started with pid [20727]
Traceback (most recent call last):
  File "/home/deepforest/catkin_ws/src/nmea_navsat_driver/scripts/nmea_socket_driver", line 37, in <module>
    libnmea_navsat_driver.nodes.nmea_socket_driver.main()
  File "/home/deepforest/catkin_ws/src/nmea_navsat_driver/src/libnmea_navsat_driver/nodes/nmea_socket_driver.py", line 105, in main
    server.server_bind()
  File "/usr/lib/python3.8/socketserver.py", line 466, in server_bind
    self.socket.bind(self.server_address)
OSError: [Errno 99] Cannot assign requested address
[nmea_socket_driver-2] process has died [pid 20727, exit code 1, cmd /home/deepforest/catkin_ws/src/nmea_navsat_driver/scripts/nmea_socket_driver __name:=nmea_socket_driver __log:=/home/deepforest/.ros/log/be6df530-9002-11ec-bcb0-b7a3bcf93d6b/nmea_socket_driver-2.log].
log file: /home/deepforest/.ros/log/be6df530-9002-11ec-bcb0-b7a3bcf93d6b/nmea_socket_driver-2*.log
^C[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

The launch file:
 <arg name="time_ref_source" default="/vlp1/gpsimu_driver/gpstime" />
  <arg name="useRMC" default="True" />

  <node name="nmea_topic_driver" pkg="nmea_navsat_driver" type="nmea_topic_driver" output="screen">
    <param name="time_ref_source" value="$(arg time_ref_source)" />
    <param name="useRMC" value="$(arg useRMC)" />
  </node>


Styling: make overall web app attractive to users

Leverage Figma

React MUI templates

Migrated to MVP req, see #65


⚠ Processors has degraded performance

In ed294c7, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 47 ms

Resolved: Processors performance has improved in 05638a3.


collapse uses display:none vs display:block, shouldn't it be using visibility:visible/hidden/collapse

I have an issue with a <table> which should be set to width:100%.
When I use the collapse component, the width:100% is lost during collapsing.
I would assume that setting display:table would be a solution, but since collapse uses display for showing and hiding I cannot use display:table.
Shouldn't Bootstrap use visibility anyway.

Approximate duplicate of #18060.


Introduce date filter for transactions

References https://saidler.atlassian.net/projects/BAN/issues/BAN-103

Asking for one more review.


Improve Fuse with custom melt conditions

Issue #351
This PR also makes Fuse return the original response if the circuit is closed (fuse is not melted)

It seems we do have a backwards compatibility issue in tests v1.0.0 :(
I guess this is running current tests against v1.0.0, isn't it?
What am I supposed to do here?

After sleeping on it, I think it would be better if we keep the backwards compatibility.
We can however add a opt-in param to the middleware to return original error and document that this will be the default in tesla 2.0.0.

After sleeping on it, I think it would be better if we keep the backwards compatibility.
We can however add a opt-in param to the middleware to return original error and document that this will be the default in tesla 2.0.0.

I think this is the best solution too :)
So, is it enough if this param is something like keep_orig_resp: true | false (default: false, but true in 2.0.0)? Or what works best for you?
Thanks!

Thanks @teamon! 🙇


Import for text, audio, video pipelines

Finishing all tasks in the import pipeline for whole project. Tags, Codes, Annotations, Metadata, project_details, links etc.

@bigabig This is the finished export and import pipeline with transcripts attached to audio and video without generating sdocs for transcript

@bigabig I just noticed some bug with keywords in video import and I also make it so that the transcript lands in data instead of metadata.


npm i node-sass --save 404 error

Cannot download "https://github.com/sass/node-sass/releases/download/v3.2.0/darwin-x64-45_binding.node": HTTP error 404 Not Found

Where is darwin-x64-45_binding.node ? Why npm install will download the not exist release ?
Mac OS X 10.10.4  npm 2.13.3 iojs 3.0.0
Thank you all !

Please search before opening an issue in the future. We currently do not
support iojs 3.
On 14 Aug 2015 18:11, "Vanilla"<EMAIL_ADDRESS>wrote:

Cannot download "https://github.com/sass/node-sass/releases/download/v3.2.0/darwin-x64-45_binding.node": HTTP error 404 Not Found
Where is darwin-x64-45_binding.node ? Why npm install will download the
not exist release ?
—
Reply to this email directly or view it on GitHub
https://github.com/sass/node-sass/issues/1071.


JWT generation failed: failed to load key: bio read failed

What happened?
I am trying to create an Apple Login mechanism using Qt and C++.
I read that that, unlike Google, with Apple the secret key must be in JWT format so I tried to do it using the jwt-cpp library.
I installed jwt-cpp using vcpkg
vcpkg install jwt-cpp
My .p8 file content is:
-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQg6xMHDwAqe0dn4myO
mrkVRZLNTr39MK9nOzFz5b55uaWgCgYIKoZIzj0DAQehRANCAAQKY4KrSI6xxVaB
A5Cdm9/GXfC+obbw/8uFu3y4HZa6NxGTuT+dNhc0EXB5EkEPSY3iUinBn5XqCJke
4wHd8uUV
-----END PRIVATE KEY-----
My code throws the following exception:
JWT generation failed: failed to load key: bio read failed
I need a help in understanding why I am getting such error and if there is a way to solve it
How To Reproduce?
QString AppleLogin::generateClientSecret()
{
    // 1. Read private key from file
    std::string privateKeyPath = "AuthKey_HUC29345UK.p8";

    QFile keyFile(QString::fromStdString(privateKeyPath));
    if (!keyFile.open(QIODevice::ReadOnly | QIODevice::Text))
    {
        qWarning() << "Failed to open private key file";
        return QString();
    }

    QByteArray keyData = keyFile.readAll();
    keyFile.close();

    std::string privateKey = keyData.toStdString();

    try {
        // 2. Get current time and calculate expiration (6 months)
        auto now = std::chrono::system_clock::now();
        auto exp = now + std::chrono::seconds(15777000);

        // 3. Create the JWT
        const std::string KEY_ID = "HUC29345UK";
        const std::string TEAM_ID = "JDC2Z4S2GN";
        const std::string CLIENT_ID = "com.bb.launcher.service";

        auto token = jwt::create()
                         .set_issuer(TEAM_ID) // Team ID
                         .set_type("JWT")
                         .set_subject(CLIENT_ID) // Client ID
                         .set_audience("https://appleid.apple.com") // Apple audience
                         .set_issued_at(now)
                         .set_expires_at(exp)
                         .set_header_claim("kid", jwt::claim(KEY_ID)) // Key ID
                         .sign(jwt::algorithm::es256(privateKey, "", "", ""));

        return QString::fromStdString(token);
    }
    catch (const std::exception &e)
    {
        qWarning() << "JWT generation failed:" << e.what();
        return QString();
    }
}

Version
0.7.0
What OS are you seeing the problem on?
Windows
What compiler are you seeing the problem on?
MSVC
Relevant log output
JWT generation failed: failed to load key: bio read failed

Code of Conduct

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

OpenSSL works with PEM format. Seems like Apple exporting the pubkey pair in .P8 is normal... you just need to convert it to pem.
https://github.com/lcobucci/jwt/issues/244
https://forums.developer.apple.com/forums/thread/689212


Add FHIR repository connection

Purpose

$subject

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Need to have vscode based screenshots and also try out steps should reflect to use vscode


Command to generate self-signed certificate does not work.

The PoSH command used here to generate a self-signed certificate, which is then promoted to a trust root CA did not work for me.
$rootCert = New-SelfSignedCertificate -CertStoreLocation cert:\CurrentUser\My -DnsName "RootCA" -TextExtension @("<IP_ADDRESS>.4.1.311.21.10={text}<IP_ADDRESS>.<IP_ADDRESS>.1,<IP_ADDRESS>.<IP_ADDRESS>.2")
Certificates signed with the above certificate will show a warning "The certificate is not valid for the selected purpose".  If you try to use these certificates, you will get invalid certificate errors from clients.
The way I was able to fix this is to provide a -KeyUsage that includes "Certificate Signing" and change the OIDs to use the extended key usage rather than application policies.   Once this was done for the root CA certificate, new certificates worked like a charm.
I suggest the command be changed to be like below.
$rootcert = New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -DnsName "RootCA" -TextExtension @("<IP_ADDRESS>={text}<IP_ADDRESS>.<IP_ADDRESS>.1,<IP_ADDRESS>.<IP_ADDRESS>.2") -KeyUsage CertSign,DigitalSignature,KeyEncipherment

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 416d3d78-0e61-097b-0bbe-c6cd331aa986
Version Independent ID: 87242506-6036-9469-0166-0ae8890a96f8
Content: How to: Create Temporary Certificates for Use During Development
Content Source: docs/framework/wcf/feature-details/how-to-create-temporary-certificates-for-use-during-development.md
Product: dotnet-framework
GitHub Login: @Lxiamail
Microsoft Alias: wcfsrvt

I'm not even sure why the TextExtension is necessary at all, as long as the KeyUsage is done properly - but I'm not really a pro with certificates. It took me an hour to end up with the line below, that also worked:
$rootCert = New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -DnsName "RootCA" -KeyUsage CertSign,CRLSign -KeyUsageProperty Sign
It'd be great if this site that pops up pretty far in searches doesn't suggest non-working script arguments


Question: Placeholders for Dropzone

Hi!
I found http://ghosditor.herokuapp.com/ for an angular 1 app. It´s really useful to be able to upload images with an image placeholder and a dropzone element. Is it possible to add this feature to your component?

It's a very good idea let's do it.

I'm currently trying to pick an editor for a blog I'm writing I really like the look of this editor.
The lack of image upload is one of the aspects which is holding me back.
Ideally, I'd like an angular version of the stack overflow 'pagedown' editor for angular but this looks like it gets me most of the way there :)

Drag drop implementation from simplemde looks good.
https://github.com/sparksuite/simplemde-markdown-editor/issues/328
https://github.com/gautiermichelin/simplemde-markdown-editor


Improve documentation in Microsoft Fakes

I am a member of the Visual Studio Unit Testing team, and I have noticed that the current content may be difficult for new developers to understand how to quickly get started with Microsoft Fakes.
To address this, I have made several improvements:

Added new content that includes a detailed tutorial for using Stubs and Shims. These tutorials aim to guide new developers through the process of using Microsoft Fakes and help them understand its functionalities better.

Included sample projects StubsTutorial.zip and ShimsTutorial.zip. These zip files contain the source code for the tutorials. Please note that I have removed all binaries to keep the project clean and focused on the code.

Revised the existing content to improve clarity. I have reworded some sections to make them more straightforward and easier to understand.

These changes aim to make the Microsoft Fakes documentation more accessible to new developers and help them get started with it more efficiently.

/azp run


Nuxt

How to run nuxt with this package?
Thanks

Damm, did'nt noticed the issue.
Did you get it working @bajki-ib or do you still need help ?


[BUG] error 500 useMagicKeys is not defined

D:\ShortsGenerator>docker compose up -d
time="2024-12-19T20:43:19+03:00" level=warning msg="The "GOOGLE_CLIENT_ID" variable is not set. Defaulting to a blank string."
time="2024-12-19T20:43:19+03:00" level=warning msg="The "GOOGLE_CLIENT_SECRET" variable is not set. Defaulting to a blank string."
time="2024-12-19T20:43:19+03:00" level=warning msg="The "GOOGLE_REFRESH_TOKEN" variable is not set. Defaulting to a blank string."
[+] Building 133.5s (15/28)                                                                                docker:desktop-linux
=> [nuxt internal] load build definition from Dockerfile.FE.Nuxt                                                                                0.1s
=> => transferring dockerfile: 842B                                                                                0.0s
=> [api internal] load build definition from Dockerfile                                                                                0.1s
=> => transferring dockerfile: 1.07kB                                                                                0.0s
=> [api internal] load metadata for docker.io/library/python:3.10                                                                                2.6s
=> [nuxt internal] load metadata for docker.io/library/node:18.19-slim                                                                                2.8s
=> [api internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> [api  1/10] FROM docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a35f3f42c16                                                                                80.1s
=> => resolve docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a35f3f42c16                                                                                0.0s
=> => sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77 252B / 252B                                                                                0.3s
=> => sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b 21.39MB / 21.39MB                                                                                4.6s
=> => sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d 6.16MB / 6.16MB                                                                                3.5s
=> => sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0 64.39MB / 64.39MB                                                                                16.6s
=> => sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b 211.31MB / 211.31MB                                                                                42.4s
=> => sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b 23.87MB / 23.87MB                                                                                11.7s
=> => sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488 48.50MB / 48.50MB                                                                                19.1s
=> => extracting sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488                                                                                2.0s
=> => extracting sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b                                                                                0.7s
=> => extracting sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0                                                                                2.9s
=> => extracting sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b                                                                                36.4s
=> => extracting sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d                                                                                0.2s
=> => extracting sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b                                                                                0.6s
=> => extracting sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77                                                                                0.0s
=> [api internal] load build context                                                                                0.1s
=> => transferring context: 412.42kB                                                                                0.0s
=> [nuxt internal] load .dockerignore                                                                                0.1s
=> => transferring context: 2B                                                                                0.0s
=> [nuxt  1/10] FROM docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df1645f1bd20b0352                                                                                35.4s
=> => resolve docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df1645f1bd20b0352                                                                                0.1s
=> => sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85 451B / 451B                                                                                1.3s
=> => sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55 2.67MB / 2.67MB                                                                                3.9s
=> => sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30 3.35kB / 3.35kB                                                                                0.6s
=> => sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c 38.57MB / 38.57MB                                                                                16.4s
=> => sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345 29.12MB / 29.12MB                                                                                7.7s
=> => extracting sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345                                                                                1.7s
=> => extracting sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30                                                                                0.0s
=> => extracting sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c                                                                                1.6s
=> => extracting sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55                                                                                0.1s
=> => extracting sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85                                                                                0.0s
=> [nuxt internal] load build context                                                                                [+] Building 133.6s (15/28)                                                                                docker:desktop-linux
=> [nuxt internal] load build definition from Dockerfile.FE.Nuxt                                                                                0.1srf / => => transferring dockerfile: 842B                                                                                0.0s   p => [api internal] load build definition from Dockerfile                                                                                0.1s
=> => transferring dockerfile: 1.07kB                                                                                0.0s
=> [api internal] load metadata for docker.io/library/python:3.10                                                                                2.6s
=> [nuxt internal] load metadata for docker.io/library/node:18.19-slim                                                                                2.8s
=> [api internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> [api  1/10] FROM docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a35f3f42c16                                                                                80.1s
=> => resolve docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a35f3f42c16                                                                                0.0s
=> => sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77 252B / 252B                                                                                0.3s
=> => sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b 21.39MB / 21.39MB                                                                                4.6s
=> => sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d 6.16MB / 6.16MB                                                                                3.5s
=> => sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0 64.39MB / 64.39MB                                                                                16.6s
=> => sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b 211.31MB / 211.31MB                                                                                42.4s
=> => sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b 23.87MB / 23.87MB                                                                                11.7s
=> => sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488 48.50MB / 48.50MB                                                                                19.1s
=> => extracting sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488                                                                                2.0s
=> => extracting sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b                                                                                0.7s
=> => extracting sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0                                                                                2.9s
=> => extracting sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b                                                                                36.4s
=> => extracting sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d                                                                                0.2s
=> => extracting sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b                                                                                0.6s
=> => extracting sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77                                                                                0.0s
=> [api internal] load build context                                                                                0.1s
=> => transferring context: 412.42kB                                                                                0.0s
=> [nuxt internal] load .dockerignore                                                                                0.1s
=> => transferring context: 2B                                                                                0.0s
=> [nuxt  1/10] FROM docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df1645f1bd20b0352                                                                                35.4s
=> => resolve docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df1645f1bd20b0352                                                                                0.1s
=> => sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85 451B / 451B                                                                                1.3s
=> => sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55 2.67MB / 2.67MB                                                                                3.9s
=> => sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30 3.35kB / 3.35kB                                                                                0.6s
=> => sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c 38.57MB / 38.57MB                                                                                16.4s
=> => sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345 29.12MB / 29.12MB                                                                                7.7s
=> => extracting sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345                                                                                1.7s
=> => extracting sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30                                                                                0.0s
=> => extracting sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c                                                                                1.6s
=> => extracting sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55                                                                                0.1s
=> => extracting sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85                                                                                0.0s
=> [nuxt internal] load build context                                                                                0.1s
=> => transferring context: 437.79kB                                                                                0.0s
=> [nuxt  2/10] RUN apt-get update &&     apt-get install -y --no-install-recommends     git     procps     && rm -rf /var/lib/apt/lists/*                                                                                57.5s
=> [api  2/10] RUN apt-get -y update &&     apt-get -y install --no-install-recommends     ffmpeg     imagemagick     procps     fonts-liberation &&     apt-get clean &&     rm -rf /var/lib/apt/lists/*                             50.8s
=> => # Get:56 http://deb.debian.org/debian bookworm/main amd64 libpgm-5.3-0 amd64 5.3.128~dfsg-2 [161 kB]
=> => # Get:57 http://deb.debian.org/debian bookworm/main amd64 libsodium23 amd64 1.0.18-1 [161 kB]
=> => # Get:58 http://deb.debian.org/debian bookworm/main amd64 libzmq5 amd64 4.3.4-6 [273 kB]                         [+] Building 133.8s (15/28)                                                                                docker:desktop-linux
=> [nuxt internal] load build definition from Dockerfile.FE.Nuxt                                                                                0.1s
=> => transferring dockerfile: 842B                                                                                0.0s
=> [api internal] load build definition from Dockerfile                                                                                0.1s
=> => transferring dockerfile: 1.07kB                                                                                0.0s
=> [api internal] load metadata for docker.io/library/python:3.10                                                                                2.6s
=> [nuxt internal] load metadata for docker.io/library/node:18.19-slim                                                                                2.8s
=> [api internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> [api  1/10] FROM docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a35f3f42c16                                                                                80.1s
=> => resolve docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a35f3f42c16                                                                                0.0s
=> => sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77 252B / 252B                                                                                0.3s
=> => sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b 21.39MB / 21.39MB                                                                                4.6s
=> => sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d 6.16MB / 6.16MB                                                                                3.5s
=> => sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0 64.39MB / 64.39MB                                                                                16.6s
=> => sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b 211.31MB / 211.31MB                                                                                42.4s
=> => sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b 23.87MB / 23.87MB                                                                                11.7s
=> => sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488 48.50MB / 48.50MB                                                                                19.1s
=> => extracting sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488                                                                                2.0s
=> => extracting sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b                                                                                0.7s
=> => extracting sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0                                                                                2.9s
=> => extracting sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b                                                                                36.4s
=> => extracting sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d                                                                                0.2s
=> => extracting sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b                                                                                0.6s
=> => extracting sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77                                                                                0.0s
=> [api internal] load build context                                                                                0.1s
=> => transferring context: 412.42kB                                                                                0.0s
=> [nuxt internal] load .dockerignore                                                                                0.1s
=> => transferring context: 2B                                                                                0.0s
=> [nuxt  1/10] FROM docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df1645f1bd20b0352                                                                                35.4s
=> => resolve docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df1645f1bd20b0352                                                                                0.1s
=> => sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85 451B / 451B                                                                                1.3s
=> => sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55 2.67MB / 2.67MB                                                                                3.9s
=> => sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30 3.35kB / 3.35kB                                                                                0.6s
=> => sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c 38.57MB / 38.57MB                                                                                16.4s
=> => sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345 29.12MB / 29.12MB                                                                                7.7s
=> => extracting sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345                                                                                1.7s
=> => extracting sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30                                                                                0.0s
=> => extracting sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c                                                                                1.6s
=> => extracting sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55                                                                                0.1s
=> => extracting sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85                                                                                0.0s
=> [nuxt internal] load build context                                                                                0.1s
=> => transferring context: 437.79kB                                                                                0.0s
=> [nuxt  2/10] RUN apt-get update &&     apt-get install -y --no-install-recommends     git     procps     && rm -rf /var/lib/apt/lists/*                                                                                57.5s
=> [api  2/10] RUN apt-get -y update &&     apt-get -y install --no-install-recommends     ffmpeg     imagemagick     procps     fonts-liberation &&     apt-get clean &&     rm -rf /var/lib/apt/lists/*                             50.9s
=> => # Get:56 http://deb.debian.org/debian bookworm/main amd64 libpgm-5.3-0 amd64 5.3.128~dfsg-2 [161 kB]
=> => # Get:57 http://deb.debian.org/debian bookworm/main amd64 libsodium23 amd64 1.0.18-1 [161 kB]
=> => # Get:58 http://deb.debian.org/debian bookworm/main amd64 libzmq5 amd64 4.3.4-6 [273 kB]                         [+] Building 133.8s (15/28)                                                                        docker:desktop-linux
=> => sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c 38.57MB / 38.57MB                  16.4s
=> => sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345 29.12MB / 29.12MB                   7.7s
=> => extracting sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345                          1.7s
=> => extracting sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30                          0.0s
=> => extracting sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c                          1.6s
=> => extracting sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55                          0.1s
=> => extracting sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85                          0.0s
=> [nuxt internal] load build context                                                                             0.1s
=> => transferring context: 437.79kB                                                                              0.0s
=> [nuxt  2/10] RUN apt-get update &&     apt-get install -y --no-install-recommends     git     procps     &&   57.5s
=> [api  2/10] RUN apt-get -y update &&     apt-get -y install --no-install-recommends     ffmpeg     imagemagi  50.9s
=> => # Get:56 http://deb.debian.org/debian bookworm/main amd64 libpgm-5.3-0 amd64 5.3.128~dfsg-2 [161 kB]
=> => # Get:57 http://deb.debian.org/debian bookworm/main amd64 libsodium23 amd64 1.0.18-1 [161 kB]
=> => # Get:58 http://deb.debian.org/debian bookworm/main amd64 libzmq5 amd64 4.3.4-6 [273 kB]
=> => # Get:59 http://deb.debian.org/debian bookworm/main amd64 libavformat59 amd64 7:5.1.6-0+deb12u1 [1104 kB]
=> => # Get:60 http://deb.debian.org/debian bookworm/main amd64 libbs2b0 amd64 3.1.0+dfsg-7 [11.5 kB]
=> => # Get:61 http://deb.debian.org/debian bookworm/main amd64 libflite1 amd64 2.2-5 [12.8 MB]
=> [nuxt  3/10] RUN corepack enable && corepack prepare pnpm@latest --activate                                    3.4s
=> [nuxt  4/10] WORKDIR /app                                                                                0.1s
=> [nuxt  5/10] COPY ./UI/package.json ./                                                                         0.1s
=> [nuxt  6/10] RUN npm config set registry https://registry.npmjs.org/                                           0.8s
=> [nuxt  7/10] RUN pnpm i                                                                                33.5s
=> => # .../node_modules/@parcel/watcher install: Done
=> => #<EMAIL_ADDRESS>postinstall: Done
=> => # .../node_modules/vue-demi postinstall: Done
=> => # > nuxt-app@ postinstall /app
=> => # > nuxt prepare
=> => # ℹ Using 2024-04-03 as fallback compatibility date.
[+] Building 343.4s (32/32) FINISHED                                                               docker:desktop-linux
=> [nuxt internal] load build definition from Dockerfile.FE.Nuxt                                                  0.1s
=> => transferring dockerfile: 842B                                                                               0.0s
=> [api internal] load build definition from Dockerfile                                                           0.1s
=> => transferring dockerfile: 1.07kB                                                                             0.0s
=> [api internal] load metadata for docker.io/library/python:3.10                                                 2.6s
=> [nuxt internal] load metadata for docker.io/library/node:18.19-slim                                            2.8s
=> [api internal] load .dockerignore                                                                              0.0s
=> => transferring context: 2B                                                                                0.0s
=> [api  1/10] FROM docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a  80.1s
=> => resolve docker.io/library/python:3.10@sha256:3ba2e48b887586835af6a0c35fc6fc6086fb4881e963082330ab0a35f3f42  0.0s
=> => sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77 252B / 252B                         0.3s
=> => sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b 21.39MB / 21.39MB                   4.6s
=> => sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d 6.16MB / 6.16MB                     3.5s
=> => sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0 64.39MB / 64.39MB                  16.6s
=> => sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b 211.31MB / 211.31MB                42.4s
=> => sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b 23.87MB / 23.87MB                  11.7s
=> => sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488 48.50MB / 48.50MB                  19.1s
=> => extracting sha256:fdf894e782a221820acf469d425b802be26aedb5e5d26ea80a650ff6a974d488                          2.0s
=> => extracting sha256:5bd71677db44bb63b94de61b6f1f95d5540b4ba2d6a8a6bc4d19f422b25e0c2b                          0.7s
=> => extracting sha256:551df7f94f9c131f2fec0e8063142411365f0a1c88b935b9fac22be91af227e0                          2.9s
=> => extracting sha256:ce82e98d553dd62ca6a12bebfe83992ae9f9ae2748275e74b66a68cc094f868b                         36.4s
=> => extracting sha256:bd84c4462442a429384ef1dcf397efef5040c5a8f5a8a4185fed33042e3e097d                          0.2s
=> => extracting sha256:4936f42e964c6491e905ae0ed24020ac0c44431bbb4e41b046d3959e3b1ccb8b                          0.6s
=> => extracting sha256:5ddbee3ba41ed154eca0cc0a31678e908eebb93daaf5105d8baf69766cf22e77                          0.0s
=> [api internal] load build context                                                                              0.1s
=> => transferring context: 412.42kB                                                                              0.0s
=> [nuxt internal] load .dockerignore                                                                             0.1s
=> => transferring context: 2B                                                                                0.0s
=> [nuxt  1/10] FROM docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df  35.4s
=> => resolve docker.io/library/node:18.19-slim@sha256:246bf34b0c7cf8d9ff7cbe0c1ff44b178051f06c432c8e7df1645f1bd  0.1s
=> => sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85 451B / 451B                         1.3s
=> => sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55 2.67MB / 2.67MB                     3.9s
=> => sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30 3.35kB / 3.35kB                     0.6s
=> => sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c 38.57MB / 38.57MB                  16.4s
=> => sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345 29.12MB / 29.12MB                   7.7s
=> => extracting sha256:8a1e25ce7c4f75e372e9884f8f7b1bedcfe4a7a7d452eb4b0a1c7477c9a90345                          1.7s
=> => extracting sha256:503fbb4f74dfc223fa7df9ea3a583f85ae96f7c16c55b77d692ffa77d56a8b30                          0.0s
=> => extracting sha256:5bda067187dc9c01b0e0efd4b950cfacc6eaae370ffdeda008c63fa2ab0c1c1c                          1.6s
=> => extracting sha256:beea218e05540c8adf498aa8ad808353e40500aaccb17724144666e3a3a39f55                          0.1s
=> => extracting sha256:373e0876a2881f4c5d1d96d0ad1d97861a1275b350c7cd78e91ddd54f0e7db85                          0.0s
=> [nuxt internal] load build context                                                                             0.1s
=> => transferring context: 437.79kB                                                                              0.0s
=> [nuxt  2/10] RUN apt-get update &&     apt-get install -y --no-install-recommends     git     procps     &&   57.5s
=> [api  2/10] RUN apt-get -y update &&     apt-get -y install --no-install-recommends     ffmpeg     imagemag  110.8s
=> [nuxt  3/10] RUN corepack enable && corepack prepare pnpm@latest --activate                                    3.4s
=> [nuxt  4/10] WORKDIR /app                                                                                0.1s
=> [nuxt  5/10] COPY ./UI/package.json ./                                                                         0.1s
=> [nuxt  6/10] RUN npm config set registry https://registry.npmjs.org/                                           0.8s
=> [nuxt  7/10] RUN pnpm i                                                                                75.6s
=> [nuxt  8/10] COPY ./UI .                                                                                0.7s
=> [nuxt  9/10] COPY .env .                                                                                0.1s
=> [nuxt 10/10] RUN pnpm build                                                                                39.7s
=> [api  3/10] RUN apt-get update && apt-get install -y locales &&     locale-gen C.UTF-8 &&     /usr/sbin/updat  7.9s
=> [api  4/10] RUN sed -i 's/none/read,write/g' /etc/ImageMagick-6/policy.xml                                     0.4s
=> [api  5/10] WORKDIR /home/app                                                                                0.0s
=> [api  6/10] COPY requirements.txt .                                                                            0.1s
=> [api  7/10] COPY Backend/ Backend/                                                                             0.1s
=> [api  8/10] RUN pip install --no-cache-dir --upgrade pip &&     pip install --no-cache-dir -r requirements.  118.0s
=> [nuxt] exporting to image                                                                                40.2s
=> => exporting layers                                                                                21.1s
=> => exporting manifest sha256:f4eeb80d856f3a45712c5d10bcf1ed37797d3120c1e2c0d57148fc93bfce7fb0                  0.0s
=> => exporting config sha256:3789dd3106bf7d3501dec71e54c10ed92c07a68943f310be1dbef1c343259fcf                    0.0s
=> => exporting attestation manifest sha256:69b12592dfff05802c4a87a48d850351e51b69f9008900e7161a00d312bba874      0.0s
=> => exporting manifest list sha256:89e922face533cb89c6cfb0d919cddda52a2c41cfc1009a7b3767bc5b933ea30             0.0s
=> => naming to docker.io/library/shortsgenerator-nuxt:latest                                                     0.0s
=> => unpacking to docker.io/library/shortsgenerator-nuxt:latest                                                 18.9s
=> [nuxt] resolving provenance for metadata file                                                                  0.0s
=> [api  9/10] WORKDIR /home/app/Backend                                                                          0.1s
=> [api 10/10] COPY .env .                                                                                0.0s
=> [api] exporting to image                                                                                22.9s
=> => exporting layers                                                                                16.4s
=> => exporting manifest sha256:c05fddb0543a200d8c438935c5ec38e0b11567bc251fac06ed07ff923ee1b4f3                  0.0s
=> => exporting config sha256:256e96f3cb80b3017349ff33a6cf894bd8dcc81910b43d2c59e2c0a9f7808e3c                    0.0s
=> => exporting attestation manifest sha256:53164f576c007697eca59c45913e2b8554debe138a4287bef81c1a74ece05af5      0.0s
=> => exporting manifest list sha256:6fbb82314c93f7c52ce7b405cdcd15a0e1121c6d55df8b95e9f5f0f9fc282e4c             0.0s
=> => naming to docker.io/library/shortsgenerator-api:latest                                                      0.0s
=> => unpacking to docker.io/library/shortsgenerator-api:latest                                                   6.3s
=> [api] resolving provenance for metadata file                                                                   0.0s
[+] Running 3/3
✔ Network shortsgenerator_default   Created                                                                       0.1s
✔ Container shortsgenerator-api-1   Started                                                                       6.0s
✔ Container shortsgenerator-nuxt-1  Started                                                                       6.0s
D:\ShortsGenerator>

Working on it now, fix in a couple minutes


CreateOffer only works with promises in Safari 11.1.2

[ X ] I have provided steps to reproduce
Jsfiddle
[ X ] I have provided browser name, version and adapter.js version
Safari 11.1.2 on MacOs Sierra 10.12.6 / adapterjs 6.1.3
[ X ] This issue only happens when adapter.js is used
Not really, with adapter, promise based createOffer works, without both of them fails.

Description
When creating an offer with constraints { offerToReceiveAudio: true, offerToReceiveVideo: true } with a callback style createoffer, the sdps generated are only:
{sdp: "v=0
↵o=-<PHONE_NUMBER>703606396 2 IN IP4 <IP_ADDRESS>
↵s=-
↵t=0 0
↵a=msid-semantic: WMS
↵", type: "offer"}

when using promise based createOffer, everything works fine.
Shouldn't adapter shim the legacy callback style in Safari and produce the same result?

this looks like a conflict in the order of shims... shimCreateOfferLegacy is called after shimCallbackAPI and only does promises.

Thanks for reporting and :clap: @dagingaa for fixing it.
I'll publish a new patch release shortly.
Also cc @youennf in case you have people running into this.

do you plan to release 6.3.2 soon on npm?

done now


SCS solver import error

Describe the bug
I install cvxpy with conda including the scs package. While the SCS solver can not be properly imported.
To Reproduce
print(cp.installed_solvers()
Expected behavior
output all the supported solver with SCS included
Output
(CVXPY) Dec 13 11:26:03 PM: Encountered unexpected exception importing solver SCS:
ImportError("dlopen(/Users/ree/miniconda3/envs/py/lib/python3.11/site-packages/_scs_direct.cpython-311-darwin.so, 0x0002): Library not loaded: @rpath/liblapack.3.dylib\n  Referenced from:  /Users/ree/miniconda3/envs/py/lib/python3.11/site-packages/_scs_direct.cpython-311-darwin.so\n  Reason: tried: '/Users/ree/miniconda3/envs/py/lib/python3.11/site-packages/../../liblapack.3.dylib' (no such file), '/Users/ree/miniconda3/envs/py/lib/python3.11/site-packages/../../liblapack.3.dylib' (no such file), '/Users/ree/miniconda3/envs/py/bin/../lib/liblapack.3.dylib' (no such file), '/Users/ree/miniconda3/envs/py/bin/../lib/liblapack.3.dylib' (no such file), '/usr/local/lib/liblapack.3.dylib' (no such file), '/usr/lib/liblapack.3.dylib' (no such file, not in dyld cache)")
['CLARABEL', 'ECOS', 'ECOS_BB', 'OSQP', 'SCIPY']
Version

OS: Mac OS Ventura 13.5 (M2 chip)
CVXPY Version: 1.4.1

** Additional info **
All the dependencies meet the version requirements.

I get this same error when trying to run my code
Check the installation
(NCH) njjensen@Nicks-MacBook-Air 2023-11 Three_N-Cornered Hat % conda update -c conda-forge cvxpy
Channels:
 - conda-forge
 - defaults
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: done

# All requested packages already installed.

Run my script
(NCH) njjensen@Nicks-MacBook-Air 2023-11 Three_N-Cornered Hat % python threeCH_feasibility_20240122.py
(CVXPY) Jan 22 09:01:32 AM: Encountered unexpected exception importing solver SCS:
ImportError("dlopen(/Users/njjensen/miniconda3/envs/NCH/lib/python3.11/site-packages/_scs_direct.cpython-311-darwin.so, 0x0002): Library not loaded: @rpath/liblapack.3.dylib\n  Referenced from: <A08A2CF9-B9A1-393C-A32E-68987F02C61E> /Users/njjensen/miniconda3/envs/NCH/lib/python3.11/site-packages/_scs_direct.cpython-311-darwin.so\n  Reason: tried: '/Users/njjensen/miniconda3/envs/NCH/lib/python3.11/site-packages/../../liblapack.3.dylib' (no such file), '/Users/njjensen/miniconda3/envs/NCH/lib/python3.11/site-packages/../../liblapack.3.dylib' (no such file), '/Users/njjensen/miniconda3/envs/NCH/bin/../lib/liblapack.3.dylib' (no such file), '/Users/njjensen/miniconda3/envs/NCH/bin/../lib/liblapack.3.dylib' (no such file), '/usr/local/lib/liblapack.3.dylib' (no such file), '/usr/lib/liblapack.3.dylib' (no such file, not in dyld cache)")

@zhongruiw I installed separately and then my code worked. Please try this
conda install conda-forge::liblapack

Thanks for the suggestion @nikkujensen, marking this issue as resolved.


RegexExtract - Multiple Matches

The explanation for RegexExtract reads

Index 0 returns all matches.

I don't believe this to be true.  I have a simple regex that matches word characters and spaces between two delimiters and if multiple matches are found in the column only the first result is returned when I have 0 specified as the resulting index.
I would like to return all the results found in the string and then use perhaps a flatten operation to turn one row into multiple rows where multiple matches exist.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: d30c6730-6586-5347-dc1b-43e6c930bbbe
Version Independent ID: e6dbc313-46e3-1361-7d46-32eada2af476
Content: Details and usage for all mapping data flow functions - Azure Data Factory & Azure Synapse
Content Source: articles/data-factory/data-flow-expressions-usage.md
Service: data-factory
Sub-service: data-flows
GitHub Login: @kromerm
Microsoft Alias: makromer

Here is an example of what is returned.  While I see that it returns everything for the given match (and not just what is in the specific match group) that is not the same as returning all matches.  In this case where multiple names are matches in the same column for the same regex, I expected/hoped to return an array of matches.

While this is a work-around, I think I'm close to solving this problem.  I first start off by adding additional delimiters and then splitting on those delimiters using the regex included previously.  Screenshot
mapIf(regexSplit(replace(replace(Body, '@', 'BEGINREGEX@'), '?', '?ENDREGEX'), `\b(BEGIN|END)REGEX\b`), regexMatch(#item, `@([\w ]+)\?`), regexExtract(#item, `@([\w ]+)\?`, 1))
However, when I drag in the flatten transformation, it doesn't show the column as a flattenable column despite it appearing as an array in the previous step.  Any ideas for this?

@pelowski
Thanks for your feedback! We will investigate and update as appropriate.

@pelowski
It seems like the flatten transformation is not recognizing the column as an array. One possible reason for this could be that the data type of the column is not recognized as an array data type.
You can try explicitly casting the column to an array data type using the as operator. For example, you can modify your expression as follows:
mapIf(regexSplit(replace(replace(Body, '@', 'BEGINREGEX@'), '?', '?ENDREGEX'), \b(BEGIN|END)REGEX\b), regexMatch(#item, @([\w ]+)\?), regexExtract(#item, @([\w ]+)\?, 1)) as myArray
This will cast the result of the mapIf function to an array data type with the name myArray. You can then use myArray as the input to the flatten transformation.
If this does not work, I'd recommend you create a support ticket since the support team will be able to respond much more quickly and have a conversation with you to figure out what could be going on.


Move all examples to the pyopenxr_examples project

at https://github.com/cmbruns/pyopenxr_examples

Fixed for 1.0.2401


feat(due date): implement due date for tasks

Added date selector and due date display for tasks
Feature Preview

I will take a look tmr morning.

Just checked the preview. Since this is a mobile app, we should keep the add button for users to click instead of using enter on keyboard only.


Fix Python wordcount benchmark by specifying beam_it_module

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Run Seed Job

Run Python Performance Test

+R: @yifanzou


.Net 5.0 support

Due to NET 5.0 release need to update library to support it.
Required:

Investigate what changes made in NET 5.0 Identity and define the scope of work to be done.
Way of managing multiple package versions for different Net Core versions.

Re 1:
Looks like no changes for ASP.NET Core Identity was made in .NET 5.0, at least any breaking changes.
So, I hope, what needs to be done is just to update packages references.
List of breaking changes.
Re 2:
We should create separate branch for .NET Core 3.1 version (currently our master branch).
Master branch will be for .Net 5.0 as the newest version.
@matteofabbri what your thoughts around it?


Add CI release action using Trusted Publisher model

https://docs.pypi.org/trusted-publishers/
https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-pypi


Implement order of operations for updates

See the order in  #132
Ensure we follow this order for update operations.

This has been implemented earlier, following description in #132 such that

Individual updates within operation (all $sets) are executed in alphabetic order of path
Updates ($set vs $unset) are executed in document order of the request (as specified by caller)


Pages showing DNN Error and Site Assets like images use root folder favicon.ico for Browser Fav Icons

Description of bug
I have noticed that when selected some pages or images the fav icon the browser detects is the root ico file instead of the portal uploaded ico file.
Steps to reproduce
List the precise steps to reproduce the bug:

Install DNN
Create Site
Upload A Favicon in Site Settings
Navigate to PERSONA BAR > MANAGE > SITE ASSETS and upload an image to a folder
View the image you uploaded.
Notice there is the DNN fav ico instead of your portal fav ico file you uploaded showing in the browser.  Firefox best demonstrates the issue.
You can also then edit the link in your browser and add a character to the URL to create an Error page which will also use the root folder favicon.ico file instead of the portal fav icon uploaded in site settings.

Current behavior
Favicon.ico in DNN Installation Root Folder is being used instead of Site Settings > Fav Icon uploaded when viewing error pages and site assets.
Expected behavior
Use the uploaded fav icon file set in PERSONA BAR > SITE SETTINGS
Screenshots
If applicable, provide screenshots to help explain the bug.

Error information
No errors.
Additional context
Maybe there is no way around this, then those icons need removed or a way to remove them from within the PERSONA BAR.
Affected version

[ ] 10.0.0 alpha build
[x ] 9.5.0 alpha build
[ x] 9.4.4 latest supported release

Affected browser

[x ] Chrome
[ x] Firefox
[ x] Safari
[ x] Internet Explorer 11
[x ] Microsoft Edge (Classic)
[x ] Microsoft Edge Chromium

Hmm, I am guessing the portal specific icon needs to go through some code that the error pages do not go thru by design and thus the root icon get's served as a static file...

I assume, the file is delivered by IIS and not passing the ASP.Net queue.
AFAIK, IIS always uses the favicon.ico in the root of the website.

Yeah, I am going to close this issue as this is by design, trying to run more code in the error page could create more errors and make debugging hell. If anyone disagrees and has a solution feel free to comment and we can reopen


Azure lighthouse

With azure lighthouse announced. I believe this document could be updated? Activity logs can be connected directly as a datasource

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4b70bc73-e0ce-a558-bf66-c02577859f3e
Version Independent ID: 1d80eb59-7698-8faa-e514-cac47eca799b
Content: Collect Azure Activity logs into a Log Analytics workspace across Azure tenants
Content Source: articles/azure-monitor/platform/activity-log-collect-tenants.md
Service: log-analytics
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

Thanks for your comment. The feedback has been shared with the content owner for further review. Thanks for your patience.


[BUG] Put shared Databricks test script together for ease of maintenance

Describe the bug
Put the shared Databricks together for test.sh and run_it.sh.
Then it is ease to maintain the test script, need not to update both test.sh and run_it.sh if we change the shared script .
Follow up the issue:  https://github.com/NVIDIA/spark-rapids/issues/8636#issuecomment-1614100698
Expected behavior
Only change one place/file for the shared part of test.sh and run_it.sh

https://github.com/NVIDIA/spark-rapids/pull/8777 get merged
Will continue to put shared test scripts together for test.sh and run_it.sh in the following change.


Add Remote Desktop to context menu actions

It be nice to launch Remote Desktop from the context menu actions.

time for a new Plugin ?! just copy plugin.collctr.sccmclictr :-)

I was thinking new plugin. When I was looking at how to do this when I found the issue with why plugin.collctr.sccmclictr was greyed out.
I use Collection Commander every day at work so anything I contribute helps me and my coworkers,


Support for Swedish

Kungliga Biblioteket is currently creating Swedish models from corpus data from Språkbanken. See https://github.com/explosion/spaCy/issues/3056#issuecomment-702045211 and https://github.com/Kungbib . Definitely something we should keep us updated on


[KOGITO-5500] fix in memory compilation under Windows

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


DCO is intrusive anddoes not work with github online edit

The fact that DCO requires the added line at each comment makes it very annoying to use and also prevents using the edit functionality in GitHub which auto opens a pull request. Once this pull request was created it will not have the signature on it and it will not be able to fix it.
Instead DCO should only require acceptance the first time when someone contributes, not on each request.
Sidenote, if someone knows a working alternative that does not annoy contributors on each request please let me know. I am looking for bot that would require only one time action on the first commit/PR.

You are missing the point of the DCO. This is a per-commit signoff, so DCO (and this bot implementing it) is not what you want.

The DCO is based on some legal text (mainly used by corporations working in open source), so I don't think it really fits your needs.
I'm gonna close since there's no action here.

@hiimbex

The DCO is based on some legal text (mainly used by corporations working in open source), so I don't think it really fits your needs.

Sorry to nit pick on you!... actually this is not exactly mainly used by corporations working in open source but rather mainly started by Linux and related projects and adopted by other open source projects that like to have a CLA-less, lighter weight way to track and accept contributions like this is done in Linux, the kernel ;)

As some repos are starting to use this bot, contribution is becoming harder, since the DCO bot does not support GitHub.
Could you add support for GitHub please?


Speed up _match function [run_process_replay]

Prevent extra checks when pat.name is None
Exit early on mismatch

Before:
UOPS_REWRITE=1 PROFILE=0 python3 test/external/external_benchmark_schedule.py
***** model forward in  42.78 ms
***** model schedule in  13.86 ms
***** model lower in 1664.71 ms

After:
UOPS_REWRITE=1 PROFILE=0 python3 test/external/external_benchmark_schedule.py
***** model forward in  42.40 ms
***** model schedule in  13.99 ms
***** model lower in 1523.17 ms

Minor speedup for more lines/complexity isn't worth it. The whole algorithm is wrong.


Incorporate Ray into simple shape intersection detector

https://github.com/Godlike/Arion/projects/1 Migration.


Provide multiple versions of documentation

This is so that users can look up docs for the version that they're using even if it isn't the most recent version.

Docusaurus supports documentation versioning: https://docusaurus.io/docs/en/versioning.

Awesome!

https://github.com/Khan/KaTeX/issues/1505#issuecomment-408504458 by @edemaine

When we publish to gh-pages (which I guess we do every release, not every commit, so that we document the release not the master branch?),

Another question is should we document the master branch, i.e., publish the website(gh-pages) every commit?

I think there can be two workflows:

Publish website every commit to master and every release

Use CircleCI to build and deploy the website using GitHub token or SSH deploy key
Run deploy job on master branch commit builds and Git tag build
Commit and use local built CSS and fonts or use CircleCI build artifacts for master documentation

CORS is not enabled for CircleCI build artifacts, so it needs a proxy

Use CSS and fonts from CDN for release version documentation
Latest release version documentation is shown by default
master documentation can be accessed by selecting next
May bloat the repo

Publish website every release

Publish the website manually in the release script
Use CSS and fonts from CDN

Or we can switch to netlify, which provides with following limitations:

Network Bandwidth: 100GB/month - Soft
Storage: 100GB - Soft
API requests: 500 requests/minute, 3 deploys/minute* - Hard

Use netlify to build and deploy the website
Use local built CSS and fonts
Use CSS and fonts from CDN for release version documentation
Latest release version documentation is shown by default
master documentation can be accessed by selecting next
PR preview is available through #1510

Publish website every release

The function support page has been updated on that schedule for 1½ years. It works fine. I'm not sure about the other pages. We may find a problem and wish to get new docs out in between releases.

I think we're currently in Plan 2 (though adding to release script sounds nice), but with this issue completed, Plan 1 makes sense. This is why I was thinking it might be good for the published compiled documentation (not the doc source) to live in a separate repo, to avoid any bloat.
A small issue regarding the function support page: in the past, @ronkok has done the work immediately after a release. If we continue this workflow, we'll need to be able to update a past release's documentation. (This is also an issue if we want to publish the docs on NPM.) The alternative would be to prepare the doc update before release.

@edemaine I think documentations should be updated in the PR that adds a new feature.

Perhaps we should start requiring updates to the document for each PR that affects it.

That may be more easily said than done. The original KaTeX Contributing page instructed contributors to update the wiki's function support page. But I found in December 2015 that the function support page was missing several hundred functions. And so began my involvement here.

in the past, @ronkok has done the work immediately after a release.

Give me a few days notice before a release occurs and I can write up every function added since the previous release.  I expect the velocity of new functions to decrease.
Now I certainly would not mind if others updated the function support page. But that is less easy to do now than it was in the wiki days, and even then, people quite often didn't do it. Also, a requirement like that may discourage new contributors just by adding another burden.
I also have reservations about showing functions in the documentation that are not yet released. They should at least be flagged as such. Which means that the function support page must then be edited twice for each new function, once with the flag, and once to remove the flag.
If you can get contributors to do all that, great. If not, I'll follow up and keep the page current.

@ronkok All good points. We already generally require people to write tests for new features, so I think requiring documentation writing to be good practice. We can modify the contributing document, but also PR templates (essentially #1468) would help here: we could add checkboxes like

[ ] Tests for new functionality or checking for old bug
[ ] New functionality documented in docs, if applicable

Nonetheless, some mistakes will creep through (cli.js has often fallen behind on settings, for example), and I like the idea of a review of the new features and possibly a cleaning up of documentation before each release.  I suggest a process of something like: open an issue "Preparing for 0.11.0", and everyone who wants to can review what they care about, probably especially as regards documentation, but also things like "I'd like to finish PR #n first".  Maybe the issue includes a draft of the release notes.
I definitely agree that the master documentation (next) should not be the default view.  But it could be nice to have things there as an option, especially given that we're currently pretty slow to release.  (Not an ideal state, but the truth for now.)  I think we can add a general warning in the next documentation (probably Docusaurus can do this for us) that says "Warning: these features are available only on the master branch of Github, and are subject to change."

(moving over from https://github.com/Khan/KaTeX/pull/1520#issuecomment-409001490)
I'd like to reraise the question of whether we should have a separate repo for the documentation/website publication (not the source files).  We could move the website to http://katex.github.io/ which would be served from a repository called katex.github.io within the KaTeX project.  (See https://help.github.com/articles/user-organization-and-project-pages/#user-and-organization-pages-sites)  Then we wouldn't have to worry about repo size, and we would be free to put all the versions of documentation there (which really wants to have the CSS/JS/fonts copied).

It seems it comes down to three questions:
1. Where we should we publish the website?

KaTeX repo GitHub Pages, gh-pages branch (https://khan.github.io/KaTeX/)
KaTeX organization GitHub Pages (https://KaTeX.github.io)
netlify (https://katex.netlify.com/)

2. If we choose to use GitHub Pages, should we publish master(next) documentation to GitHub Pages? (Currently, it is published to netlify) Or should we have a link to netlify?
3. If we choose to publish master documentation to GitHub Pages, where should we serve KaTeX from?

Commit to GitHub Pages
CircleCI build artifacts
netlify

@edemaine

gh-pages means possible repo bloat, so should probably aim for CircleCI build artifacts. I'm not an expert on how easy this is to do. Two questions: for released versions, and for master branch?

For released versions, we can use KaTeX from CDN.
For master branch, CircleCI doesn't have CORS header set, i.e., doesn't allow accessing the artifacts from another site. Therefore, we should use (CORS) proxy, but I'm not sure there is free and reliable one. So probably we will have to use another object storage like AWS S3.

KaTeX organization GitHub Pages avoids the bloat issue, so we can do whatever we want (so it's my leaning).

KaTeX organization GitHub Pages is still a GitHub repo, which has size limits. I guess we can prune old histories regularly. I wonder how quickly the repo bloats.

netlify has its limits on network bandwidth etc. that I'm slightly worried about, but maybe shouldn't be.

It turns out that GitHub Pages also has similar limitations:

Usage
GitHub Pages
netlify

Storage
1GB (hard, recommended 1GB for repo)
100GB (soft, total)

Network Bandwidth
100GB/month (soft)
100GB/month (soft)

Build
10 builds/hour(soft)
180 builds/hour(hard)

I think before we make any change to where the site lives it would be nice if we could secure a stable domain name for katex and switch to that first before changing where files are served from.  Also, since people are worried about bloat let's hold off on having multiple versions of the docs until we have a stable domain.

@kevinbarabash

I think before we make any change to where the site lives it would be nice if we could secure a stable domain name for katex and switch to that first before changing where files are served from.

Some ideas:

katex.io
katexjs.org

Also, since people are worried about bloat let's hold off on having multiple versions of the docs until we have a stable domain.

Versioning (#1521) itself will not bloat the repo as it uses KaTeX from CDN.

I can buy those domains (and possibly transfer ownership) if that would speed things up here (but also don't want to complicate things).  @kevinbarabash What's best from KA's perspective?

I can ask our IT dept about buying a domain.

js.org seems to provide free subdomains for GitHub pages. So if we decide to publish at GitHub pages, another option is katex.js.org.

Nice find! katex.js.org is another reasonable choice, especially if KA doesn't want to buy one.

I think we can use CircleCI build artifacts using CORS proxy on now.sh and Cloudflare to cache/deliver files. I've created a demo at https://katex.ylem.kim and build artifacts are available in https://katex.ylem.kim/:build_num/:path.

I've opened several PRs, as I think it'd be easier to understand and decide with actual codes.
If we publish the main website to netlify, we can use local built CSS as it provides 100 GB storage. (#1584 [1])
If we publish the main website to GitHub pages (gh-pages branch or organization repo), we can commit local built CSS. (#1584 [1])
But this may bloat the repo, so we can remove master (next) documentation from GitHub pages. (#1585 [2-1]) And maybe we can link to netlify (https://katex.netlify.com/).
Alternatively, we can serve KaTeX from another source. (#1586 [2-2])

Another question is should we use release (stable) version or master (latest) version for the main page.

I think the main page should get the release (stable) version. Otherwise we can count on seeing issues raised asking, "Why doesn't my page render a ____?".

I think the simplest starting point, roughly where we are now, is to publish documentation only during release, and use CDN for JS/CSS/fonts.  We should do what's necessary for that first.  I believe #1584 is good for that, too, because it enables local testing.
To me, the main options are:

Publish to GitHub pages in organization repo. Ideally linked from a domain name, though I also think katex.github.io is also a fine URL (better than the current one).  [my preference]
Publish to Netlify [1]. Main downside is reliance on another tool (whereas our current reliance on netlify is nonessential, just for testing). Also needs a domain name.
We can also do a hybrid that uses GitHub pages in gh-pages but stores the built master files elsewhere (Netlify is probably the neatest idea there), but these seem overly complicated.

We can also do a hybrid that uses GitHub pages in gh-pages but stores the built master files elsewhere (Netlify is probably the neatest idea there), but these seem overly complicated.

I'm thinking of adding the ability to run previous versions or test a PR on the REPL, so it is eventually needed.

I think we should wait on getting a domain name that is independent of which tool we're using before making changes to where the docs live.

Do you have to serve files from github.com to use js.org?

Now I'm against using js.org as we don't have control over DNS and subdomains.

Not having control over DNS would limit us to keeping files in Khan/KaTeX or KaTeX/katex.github.io, right?  @ylemkimon how were you thinking we'd use subdomains?

@kevinbarabash Yes, it would limit us to GitHub pages or only production deploy of netlify. netlify uses subdomain for deploy previews, e.g., https://deploy-preview-1569--katex.netlify.com. Also if we choose to publish only release docs on the main website, we can serve latest docs on the next.katex.io, for example.

@rustylife You seem to own katex.org (apologies if you just happen to have the same name as the WHOIS entry). Would you consider transferring ownership? Please email me if so!

Now we've secured domain, restating the question:
Where we should we publish the (main) website?

KaTeX repo GitHub Pages, gh-pages branch (https://khan.github.io/KaTeX/)
KaTeX organization GitHub Pages (https://KaTeX.github.io)
netlify (https://katex.netlify.com/)

@rustylife That's great! Could you unlock the domain (if locked) and email me an authorization code / EPP code / transfer code?  Email to<EMAIL_ADDRESS>not this public thread.

@rustylife and @edemaine thank you both.

@edemaine We need a DNS to point to the website. If we decide to use Netlify, we can use Netlify DNS. If we use GitHub Pages, I think we can use Cloudflare.

@ylemkimon Just to add to the list of options, we can also use Namecheap's free DNS, given that I'm moving it to Namecheap (at least for the duration that I hold it, before it transfers to KA). I can give you (and others) access to that DNS system once it's moved. But I'm happy to use anything else. I guess Netlify makes sense if we want it to manage our subdomains.

@edemaine Unfortunately, domain registrar's DNSes usually don't have uptime guarantees, many POPs, and an option for setting root domain CNAME (e.g., ALIAS/ANAME record, CNAME flattening). Cloudflare also has a free plan and it provides CDN (caching).

It seems the domain has successfully been transferred.

Now I think we can close this issue now. Thank you all for the great work!


Add book-* icons

book-a is dictionary, but could also be fonts/library
book-type is fonts/library, but also can be thesaurus
book-check is already read/finished, or purchased (e.g reading list/shopping/cart)
book-heart is diary/journal, but also favourite (again list/review etc)
book-image is photos/album
book-tabs/user is contacts/address book (can also be diary/journal)
book-spine variant can be hardback (vs just book as paperback… again use case is reading list/shopping/cart)
book-audio/volume/headphones are obviously audiobook variants (again for reading list/shopping/cart)

@danielbayley Can you provide some usecases for the icons?

@danielbayley Can you provide some usecases for the icons?

@ericfennis I would have thought most of these would be fairly self-explanatory (especially with the comprehensive metadata…)
We only currently have https://lucide.dev/icons/sticky-note and a few useful book variants…
I didn’t think we should probably add them all, but preview bot is so useful to get a proper look!

How about splitting this up into 3 PRs, book, notebook, notepad?

@jguddas Nice, yeah will break it down a bit… Although I think notebook/pad can be the same PR.

@danielbayley Thanks for providing the use cases.
Sorry for constantly asking you for use cases.
Yes, sometimes the use cases are self-explanatory. But sometimes it can be self-explanatory for you but not always for others because everyone lives somewhere else on earth and grows up with different symbols, icons and signs for things (in general, not for this PR).
It helps if we can directly see what use cases are, it speeds up reviewing PRs. Also helps in understanding your design process, sometimes other icons can fulfill those use cases as well.

Ok let's priotize some icons.
Let's go for:

[x] book-a
[x] book-audio
[x] book-check
[x] book-dashed
[ ] book-elastic, Usecase feels not really solid
[ ] book-git-commit, The commit icon is to small and not really regognisable
[x] book-headphones
[x] book-heart
[x] book-image
[x] book-open-2
[x] book-open-text
[ ] book-spine,  Looks a bit weird to me on 100%
[ ] book-tabs, Looks a bit weird to me on 100%
[x] book-text
[x] book-type
[x] book-user
[ ] book-volume, I still see a book with wifi icon, I know we use this as well on file-volumde, we need to change that one as well.
[x] library-big
[x] library-square

I'm also against adding book-open-2, for several reasons:

bad naming scheme
lack of unique use case as compared to book-open
this one would again make it look like we can't make up our mind about what a Lucide style open book icon should look like. We should either stick with the current one or replace it, not add various alts.


Update dependencies

Any update on resolving this PR? Currently this module is suffering from multiple moderate to critical vulnerabilities.

Replaced by #107


Fix scrolling page when mouse is over monaco container

Description
Fixes scrolling page when mouse is over a monaco container and removes the scrollbars from the main iframe container to disallow double scrolls.
Related issue(s)

/retest tide

/test pre-busola-integration-test-k3s

/test pre-busola-integration-test-k3s

/retest


visual + home/end of line motion

I know this is not very vim-hacker feature but with macvim i was used to put the cursor in the middle of the line (somewhere interesting), hit "v", and move to the end of the line with CMD+Right (end-of-line on macs). In this case the cursor would correctly move to the end of the line while enlarging the visual selection.
If i do this with atom vim-mode the cursor moves but i loose selection. Same goes for moving with CMD+Up/Down and i think its wrong.

As stated in the README, this package is no longer maintained and is deprecated. We recommend that people use the vim-mode-plus package instead. Because of this, we are archiving this repository and closing all issues and pull requests. Thanks very much for your support and contributions!


Different width of segments

Hello everyone,
Is there a possible way to customize the width of each particular segment? For example, I have a bar that has 3 segments and I would like the left segment to have, let's say 5dp, the middle one 12 and the right one 10. Is there a feature that implements this functionallity or if not, is there a possibillity to integrate it
(The 'solution' of adding 3 seperate bars, does not fit me :/ ) ?
Thanks in advance!! :)

Sorry, it's not possible with this lib.
Width is automatically calculated roughly as view_width / segments_count.


refresh_token request to /oauth/token not possible

Describe the bug
According to RFC 6749, a refresh of an access token only requires the grant_type and the refresh_token. However, an incoming request fails with the message [validation error]: key <code> => expected <[object Object]>, got <undefined>.
To Reproduce
Steps to reproduce the behavior:

Setup a oauth2 according to the docs, enable debug.
request an access token (eg. via postman)
place a refresh token request, with a body like {refresh_token: "12345xyz", grant_type: "refresh_token"}
check the logs

Expected behavior
Refresh request should provide a fresh access token

Thank you @bratelefant this is indeed missing 😵 maybe I can add this in the next days

I already did some work on this on a local copy, maybe if we can fix https://github.com/leaonline/oauth2-server/issues/17 I could contribute a PR. Ran across several other issues and possible improvements (eg. implement a meteor 3.0 compatible model). Would also really like to address this enhancement.


fix: Add "type": "module" to package.json

Fixes #495

Any updates?
The suggested change is ok and works fine locally. Also, the build error doesn't seem to be relevant to the update by @greypants.

Currently having to disable some tests due to this issue, would be great if the fix could be added

It looks like the test fails not because of the code failing to build, but because of size-limit failing:
"size-limit": [
    {
      "path": "dist/index.js",
      "limit": "6 kB"
    }
  ],

I see the error Size Limit can’t find files at dist/index.js, is this perhaps an issue with the test itself, given that the code is successfully building (given that the actual yarn build command return Done in 17.55s.)?

It looks like changing type to module affects the build command, such that index.js is no longer output, but index.cjs (for common) and index.module.js (for ES), which in turn affects the size-limit config in package.json (since the output file index.js that the test--npm run size--builds on no longer exists. I updated this test in https://github.com/probablyup/markdown-to-jsx/pull/500, and @greypants original suggestion now passes all tests successfully!


Create UILang.it-IT.xaml

Hi i created an Italian translation for anyone to use

Thanks, I forgot to comment here but your translation was added to the project!


edit in client

for source code, open using some web-based editor in a new tab

we could also have an edit snippet mode which pops up a really simple editor to edit the specific snippet that the error highlights for quick edits

edit snippet is done - quick edit from the right-click menu


1fichier

https://1fichier.com/

1fichier.com was present in the USOM list, but this list was removed in the previous version, so the domain is no longer blocked.


Ensuring class_getter runs exactly once under concurrent access

A class_getter with a block usually runs exactly once:
module Foo
  class_getter(x : Int32) { 1 }

  # same as:
  def self.x : Int32
    if (x = @@x).nil?
      @@x = 1
    else
      x
    end
  end
end

However, if the current fiber is ever suspended, the block might be run multiple times:
module Foo
  class_getter x : Int32 do
    puts "Foo.x" # this runs 5 times
    Fiber.yield
    1
  end
end

ch = Channel(Int32).new
5.times { spawn { ch.send Foo.x } }
5.times { ch.receive }

And if -Dpreview_mt is in effect, the block also gets run more than once, even without the Fiber.yield.
Often, Foo.x represents some kind of cached object that might be expensive to compute, like #14891 and the Unicode data tables; if we also disregard the block's return value, then this would include the various interrupt handlers guarded by Atomic::Flags too. There should be an easier way in the standard library to ensure this block is really run exactly once, regardless of the degree of concurrent access.
Constants are one alternative, but whether they run at program startup or on first access is rather opaque, and also they are slightly broken, such as in #13054.
This could apply to class_property as well, and less likely to the instance variants getter and property.

Perhaps we can jerry rig an atomic compare and set on the type id? Then we'll just need an otherwise unused type to signal that someone else is already in the process of calculating.

Wouldn't that only work for mixed unions?

I suppose we could force a mixed union using an appropriate type to signal work in progress?
The value of the class variable would effectively be typeof(block) | WorkInProgress | Nil.


The "Architecture" in "Image Details" isn't displayed correctly

API response:
{
  "digest": "sha256:82009546cb8d393e1cc4bdd7a854bbda87dcf503cda9d8782b5467895bce5d7e",
  "name": "docker_1.9_signed",
  "architecture": "",
  "os": "",
  "docker_version": "",
  "author": "",
  "created": "0001-01-01T00:00:00Z",
  "signature": {
    "tag": "docker_1.9_signed",
    "hashes": {
      "sha256": "ggCVRsuNOT4cxL3XqFS72ofc9QPNqdh4K1RniVvOXX4="
    }
  },
  "scan_overview": {
    "image_digest": "sha256:82009546cb8d393e1cc4bdd7a854bbda87dcf503cda9d8782b5467895bce5d7e",
    "scan_status": "error",
    "job_id": 3,
    "severity": 0,
    "details_key": "",
    "creation_time": "2017-08-09T10:58:32Z",
    "update_time": "2017-08-10T00:00:08Z"
  }
}

@ywk253100

"architecture": "",
"os": "",
"docker_version": "",
"author": "",

Seems API does not return the data.

Yes, but if the API returns null, I think UI should display null either rather than the date.

As issue is fixed in<EMAIL_ADDRESS>close this issue


[v1.2] Add package patch, add retry on integration test

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Problem:

Auto backport the original v1.3.0 PR https://github.com/harvester/harvester/pull/5413 failed due to golang lint
Solution:

Manual backport https://github.com/harvester/harvester/pull/5152, and bump golanglint version to same as v1.3.0
Related Issue:
https://github.com/harvester/security/issues/46, we need package patch to patch upstream charts when build-iso.
https://github.com/harvester/harvester/issues/5416, caused CI to fail randomly, this PR also added a fix
Test plan:

There are a lot of failure linting checks in the CI, there might be some missing backports.

@bk201 Seems the failure in https://github.com/harvester/harvester/pull/5413 was random;  I changed the golang lint back to original v1.49.0 and the CI looks to be fine till now.

CI hits issue https://github.com/harvester/harvester/issues/5416 again.

@bk201 now the PR is ready for v1.2.2


chore(apple): Clean up certs in Swift CI

Our provisioning profiles / distribution certs expire in a month. I've regenerated them and noted the instructions for doing so.

The actual diff just updates some identifiers but the PR description says you wanted to clean up something?

Updated


[WIP] add custom colormaps

This PR refactor how tiles endpoint parameters are defined and use dependencies to register custom colormaps

Codecov Report

Merging #24 into master will increase coverage by 7.80%.
The diff coverage is 98.18%.

@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
+ Coverage   84.54%   92.35%   +7.80%
==========================================
  Files          14       16       +2
  Lines         343      340       -3
==========================================
+ Hits          290      314      +24
+ Misses         53       26      -27

Impacted Files
Coverage Δ

titiler/api/api_v1/endpoints/tiles.py
90.76% <96.42%> (-0.62%)
:arrow_down:

titiler/api/api_v1/endpoints/metadata.py
96.87% <100.00%> (-0.05%)
:arrow_down:

titiler/api/deps.py
100.00% <100.00%> (ø)

titiler/api/utils.py
97.14% <100.00%> (+44.68%)
:arrow_up:

titiler/custom/cmap.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

Question to answer:
Registering custom colormap needs to happen only once (at app startup) or rio-tiler will raise an error (you cannot re-register the same cmap).
Is deps the best way to do: maybe not ;-)